| 29 May 2025 |
 emily | and my MacBook of course autodetects it | 12:11:39 |
| emily | oh, it seems like clients may fall back to using smaller widths if there's a signal problem | 12:14:06 |
| emily | which in this case there very much is because it's 5 GHz with the busted txpower | 12:14:14 |
| emily | https://community.arubanetworks.com/community-home/digestviewer/viewthread?MID=9618#MainCopy_ctl09_ucMessageList_rptMessageList_upMessageListItemRating_6 is the kind of thing I have seen implying that effective range is reduced by the wider channels fwiw. | 12:16:40 |
| emily | because of the increased noise | 12:16:53 |
| emily | but if ^ then perhaps there's no issue anyway | 12:17:03 |
| emily | anyway I know nothing about RF so I don't trust anything I think or remembe rreading :) | 12:20:04 |
| emily | the whole thing where DFS channels take ages to appear is really annoying though, I'll say that. | 12:20:14 |
 adamcstephens | clients can definitely renegotiate a smaller width | 12:22:20 |
| emily | yeah. I just saw that happen with my laptop after fiddling with the channel settings a bit in fact :) | 12:23:02 |
| emily | so I guess there is no disadvantage to going as high as you can | 12:23:14 |
| emily | well, I guess maybe if you have exactly 40 MHz free and the second 40 MHz is awfully congested but stuff is failing to negotiate for it etc. | 12:23:34 |
| adamcstephens | and APs have to support the smaller widths, because not all clients support 40+ | 12:23:53 |
| emily | but in this case the spectrum is very clean and I just want to make sure there's a fallback if I'm far away | 12:23:59 |
| emily | K900: do you know if there anything I can do to override a specific regdomain rule without just rebuilding the file? it's listed as a maximum of 160 MHz in the 6 GHz range, but I've read the Ofcom publications and done all the searching about the regulations I can etc. etc., and the range specified is already ≥ 320 MHz and I'm pretty sure that there is no specific rule that talks about bandwidth at all, so I'd like to force-enable 320 MHz. | 12:47:00 |
| emily | (I guess I should probably send a patch, also?) | 12:47:07 |
| emily | in fact the commit that added the seemingly-incorrect information for 6 GHz says "Regulatory update for 6 GHz operation in FI" and cites an EU regulation for the FI update without changing the citations in the GB section at all 😆 | 12:49:47 |
| emily | I guess this is motivation to get NixOS on the thing ASAP, because then it would be trivial to patch :) | 12:50:00 |
| emily | aha, and https://git.kernel.org/pub/scm/linux/kernel/git/wens/wireless-regdb.git/commit/?id=6c7cbccaee121772a23fa0efdfefcdd8a2369985 fixed a similar issue for other countries. ok, that makes me confident enough to send something | 12:54:44 |
| emily | https://lore.kernel.org/linux-wireless/20250529135706.31269-1-linux@emily.moe/T/#u first patch I've ever sent to kernel lists 🎉 | 14:02:11 |
 K900 | Hm | 14:03:41 |
| K900 | Now I'm wondering what the source is for 160MHz being the limit in Russia | 14:03:49 |
| emily | my guess: they set it in WiFi 6E days | 14:06:07 |
 magic_rb | I dont eben know where i would look for accurate numbers for the NL. Doesn't help i dont speak dutch | 14:06:12 |
| emily | there was no reason to say 320 MHz because it wasn't a thing | 14:06:14 |
| emily | going by 6c7cbccaee121772a23fa0efdfefcdd8a2369985 it seems like most countries don't actually specify anything about bandwidth because why would you if you have overall power limits and a restricted range? | 14:06:36 |
| emily | idk, maybe it's different in 2.4 GHz because it's so congested | 14:06:45 |
| K900 | You know what | 14:06:47 |
| K900 | YOU KNOW WHAT | 14:06:49 |
| emily | I'm actually unsure why they set an upper limit at all for those cases | 14:07:06 |
