In your opinion, has 22.03.5 a bug with dhcp?
2 Likes
I don’t have the problem. 22.03.5 works fine for me. If you found a bug in 22.03 and you need to have it fixed, please analyze the root cause and help finding a solution for 22.03. Helping is not pointing to a package version. Analyze, provide code, create a GitHub issue, test etc.
1 Like
It does not matter what I think about a bug. Attaching funny pictures won’t help either. Why do you not start fixing your experienced bug? Complaining alone does not help.
My Openwrt router is running in dumb AP mode. It isn't running dnsmasq at all, so that can't be the problem. The ipv4 address gets assigned by my the router attached to my cable modem (Ubiquitu EdgeRouter Lite v2.0.9-hotfix.6). The problem in my case is something was preventing the dhcp packets from making it from my phone to that main router. The fact that ntpd is also having problems might help narrow the location of the problem.
Ive noticed this in my system logs of my MR8300
What does it mean as i have been having issues with wifi devices being booted off the network for some reason on snapshot builds requiring them to manually reconnect
There's no consensus yet, but it's being discussed here. I don't think anyone has mentioned needing to manually reconnect yet though. A key for you is going to be whether it started with 22.03.4 or existed before.
i only noticed it happening in the past month or so but ill make sure to post in that thread about the issue
OpenWrt has been really neutering radio transmit power of late.
22.03.5 installed on Linksys EA8500 (ipq8064):
- 5 GHz txpower is now limited to 23 dBm on U-NII-1 with country code set to US. Previously txpower up to 30 dBm was supported on this device (30 dBm is allowed in US for U-NII-1 and U-NII-3).
Same issue with Askey RT4230W (ipq8065).
Same issue with Belkin RT3200 (mediatek). The Belkin RT3200 was FCC certified for 27 dBm on 5GHz, but OpenWrt limits U-NII-1 to 23 dBm anyway.
This is getting to be a widespread performance hit....hope it gets fixed soon.
2 Likes
Thank you for this, managed to fix this bug issue ("Sudden obtaining ip address after some time") by replacing dnsmasq with odhcpd + unbound.
1 Like
Try looking at the Updates, after updating the lists, of course. I saw a wireless-regdb update earlier this month. I wasn't looking closely at this, but after updating that, I believe I now see higher power levels than before.
When will version 22.03.6 be released ???
1 Like
Whenever there are sufficient security updates to warrant a new release. Maybe next week, maybe next month, maybe next year, it's hard to predict the future...
1 Like
Updating wireless-regdb to 2023.05.03-1 does not help. U-NII-1 transmit power is still neutered down to 23 dBm, when 30 dBm is supported by hardware (and permitted in US).
There subsequently has been more jettisoning of custom OpenWrt board data files for upstream linux versions in the 22.03 git head, but that won't be in a stable release until 22.03.6. I hope that eventually resolves some issues, but I'm suspicious that recent migration of board data files to whatever is in upstream is actually causing the problem.
You could update the package if there is a newer revision available.
For example for ARM Cortex-A53:
https://downloads.openwrt.org/releases/22.03.5/packages/aarch64_cortex-a53/base/
wireless-regdb_2023.05.03-1_all.ipk
Packages can be updated without a new base release.
Thank you for the suggestion, but that is exactly what I already did (I was aware packages are updated before the next base release)...
And it did not resolve the issue.
It is commits like ipq-wifi: drop custom board-2.bins that will not be available in a stable release until 22.03.6.
Aside, I used firmware selector to rebuild a 22.03.05 sysupgrade image, which incorporates all available updated packages since my last install, including wireless-regdb 2023.05.03-1, into a new image.
Picking and choosing individual package updates works out fine in many cases (e.g., developers recommend it to resolve a security issue), until it doesn't. There can be dependencies between updated packages that cause trouble if all package updates are not incorporated together into a new image.
Okay. Good to know.
If this issue really bothers you and you don't want to wait for future stable releases, you could try installing OpenWrt 23.05-SNAPSHOT images: https://downloads.openwrt.org/releases/23.05-SNAPSHOT/targets/
I run 23.05-Snapshot for testing newer mt76 code. It's quite stable for my Linksys E8450, but this must not be the case for other devices and other use cases. Luci is included in these branch snapshot images by default, but all other warnings apply: https://openwrt.org/releases/snapshot
The development branch can contain experimental code that is under active development and should not be used for production environments. Snapshot images may support additional hardware; however, it is experimental, considered unstable, and sometimes won't compile.
- snapshots are completely untested. Just automatic builds of the most recent source code and packages. Although snapshots are usually ok, they may sometimes contain serious bugs that prevent booting the device correctly or even prevent easy sysupgrading to new versions.
- snapshots are built daily, and that sets time limits to installing new packages with opkg. Due to kernel version checksums, you can only install “kmod” kernel modules and other kernel version dependent modules from the exactly same snapshot build. So, a few hours after flashing the firmware you may not be able to install new modules with opkg any more (as the next snapshot has been built into the download repo and has different checksums). See below for package availability time limits.
If you try 23.05-snapshot at this time before RC1, I would prepare to know how to unbrick your device.
2 Likes
Did you manage to resolve the issue eginnc?
I'm dubious about being on an unstable release.
The good news (if you want to avoid an unstable release) is that snapshot and 23.05 rc3 do not fix the limitation on UNII-1 tx power, so you might as well stay on 22.03 stable. The bad news - the issue isn't fixed.
ahhh rats 
What about rolling back to a previous stable release?
I haven't done it myself. The latest point releases of prior stable versions might have incorporated the same issues, but perhaps not. I would not want to use other than the latest point releases for security reasons, so for me that would rule out going back to older point releases.
If you try it, I would NOT retain your settings. It would be best to instead reconfigure from scratch. Also, depending on your hardware, you may find this takes you from DSA back to swconfig- another configuration difference to deal with, especially with vlans.