| 29 May 2025 |
K900 | Generally higher frequencies means lower range | 12:00:39 |
K900 | But this is not frequency | 12:00:42 |
K900 | This is bandwidth | 12:00:44 |
emily | I think what I read was "it means that if you have trouble getting signal on any of the channels it screws things up". but I guess the only reason that would happen is if there's an interfering AP. | 12:02:04 |
emily | also, what I read could have just been wrong, on account of the internet. | 12:02:31 |
emily | (meanwhile my laptop thinks that the 80 MHz AP I already have set up is actually 40 MHz. no idea why. pretty sure it supports 80 MHz.) | 12:04:21 |
K900 | Regdomain? | 12:09:11 |
K900 | Probably | 12:09:12 |
K900 | You need to set it explicitly on most hardware | 12:09:20 |
antifuchs | Something something interlacing | 12:09:36 |
emily | I set the regdomain for the APs. | 12:11:33 |
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 |