314

No worries, I think this should cover it:

For the Unifi 6 LR:

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/18000000.wmac'
        option band '2g'
        option htmode 'HT20'
        option cell_density '0'
        option country 'GB'
        option channel '11'
        option txpower '6'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option band '5g'
        option cell_density '0'
        option country 'GB'
        option channel '48'
        option htmode 'VHT40'
        option txpower '15'

And for the Netgear WAX202:

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option band '2g'
        option cell_density '0'
        option htmode 'HT20'
        option channel 'auto'
        option country 'GB'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
        option band '5g'
        option htmode 'VHT40'
        option channel 'auto'
        option country 'GB'
        option cell_density '0'

ta

Happy

1 Like
315

Hi all, will there be 23.05 for RT-N13U b1? I know the original RT-N13U was 4/32 and would not fit 23.05 anymore; I am asking the 8/64 b1 variant.

316

@oreo

It's been like this for a long time.

I opened up an issue and found the cause and the fix with some community input. Now... See this post for more info.

Hint: @stangri I see you merged the 030 patch file, until the upstream https-dns-proxy actually merges the patch.

I just upgraded my https-dns-proxy package to -v7 and it works fine now. Thanks for the fix, @stangri

1 Like
317

It has been intentionally disabled with

presumably because the author missed the b1 revision. While you may lobby for the RT-N13U (b1) to be enabled again for 23.05.x, https://openwrt.org/supported_devices/864_warning looms and kills the prospect for main/ 24.yz.x.

Support for this device has just disabled from being built by default, you can still build a custom image for your device - but the writing is on the wall, plan ahead to replace it with a device superseding minimum system requirements soon.

2 Likes
318

Thanks for pointing out the specific commit; I did search for RT-N13U in this forum and Github since 23.05-rc debut but did not found the build config. I am aware of its obsolescence (10+ years old hardware with only FE PHY), but since device of comparable config (eg. Fonera 2.0n) still gets 23.05, I guess RT-N13U b1 should be able to receive 23.05 as well.

Should I post issue in Github? I don't know if devs would read this thread...

319

You can, better would be a patch/ PR with the revert against openwrt-23.05 (just for this device, not all others) - depends on how far you want to go.

321

I attempted to upgrade one of my Netgear (Orbi) RBR50 devices to 23.05.0 but it went immediately into a boot loop. It isn't listed here, but it is an ipq40xx device... Should I attempt the u-boot tweak from one of these devices? Should I open an issue or a new thread in "Installing and Using..."?
I'm new to the forum, apologies if I'm starting off on the wrong foot here :slight_smile:
Thanks!

1 Like
322

I can't help much but some steps to get you in the right direction would be getting a log from the device. You can try to see if you can get into failsafe mode and adjust the settings for network logs, and that might be a step to adjusting the environment variables but it seems more likely you'll need to go through the serial port. Succeeding with that would go a long way to directing you to the appropriate actions. You can use a ttl uart to usb adapter or if you have a raspberri pi or similar device you can try that instead.

There is also seems to be V1 and V2 RBR50 devices and they have different partition layouts, which could be an issue. Also I may be misremembering the device, but I believe they have A/B partitions and that flashing the wrong one might cause issues.

If you do get into the the serial console, while there you can press a key to interrupt u-boot and getting the output of printenv and mmcinfo would probably helpful as well.

2 Likes
323

I have 5 v1 devices and 1 v2 (the v2 is on a shelf, the v1's are in use). I did run into the A/B partition issue for one of them during the 22.03 installation, but once they were all booting from A I had no trouble. I used sysupgrade to push 23.05 onto one of them (since I was flashing them all from voxel/factory firmware this week anyways, I figured why not try it out). There isn't access to a uart from the outside of the case so I'll need to crack one open to attempt that. I am betting I'll need to do that to get anywhere with the V2 device regardless.
On 22.03 I do see the standard fast, faster, slower flashing startup sequence of blinking... on the unit where I installed the 23.05 update it never starts the flashing sequence at all. since the first stage of the flashing is the failsafe mode prompt i doubt i'll have much luck getting into it.

324

At least you won't need soldering as it seems populated with a header. Just some jumper cables, or any kind of insulated wire that is rigged to only contact the pin.

There is a ticket on the SRS60 which is an ipq40xx that is having issues with sysupgrade as well, if you have a similar error perhaps chime in or reference it in a new ticket.

Hopefully with the logs somebody more familiar will let you know if changing the env variable will fix it or they will lead you to finding a solution, good luck.

325

After upgrading to OpenWRT 23.05, my access points could not ping or discover its IPv6 neighbors until I disabled IGMP snooping on the bridge device (with VLANs) associated with the Ethernet port. The problem is reproducible and does not exist in OpenWRT 21.x or 22.x when using the same configuration.

It appears that IGMP snooping interferes with the IPv6 neighbor discovery protocol in some manner and prevents the access point from sending neighbor solicitation requests over the bridge. I observed this behavior by pinging IPv6 hosts upstream and watching traffic upstream using tcpdump. These pings failed and tcpdump did not show any ICMP6 packets. Moreover, the ip neigh show command showed that probes for those hosts had FAILED and the Luci IPv6 routing page indicated that there were no IPv6 neighbors.

Curiously, the same access point could still route IPv6 traffic from the wifi interfaces through the bridge device over Ethernet even though the access point itself couldn't ping those same hosts.

I have confirmed this problem is unique to OpenWRT 23.05. It manifested on both of my Ubiquiti Unifi Lite devices and on my Ubiquiti LR and it went away immediately on each of them after disabling IGMP snooping or downgrading to an earlier version of OpenWRT.

Here's the bridge configuration from those devices (they're all configured the same). To fix the IPv6 neighbor discovery problem, I just removed the igmp_snooping option (via Luci).

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0'
	option igmp_snooping '1'

I tried (and reverted) many other changes before landing on this solution. Hope it helps!

4 Likes
326

I know I've read about this before. Just searched, found a (new to me) article that sounds like it describes the details: https://networkengineering.stackexchange.com/questions/77069/ipv6-neighbour-discovery-blocked-by-mld-snooping-switch

Does this sound to you like the same root-ish cause?

2 Likes
327

It certainly sounds plausible!

For what it’s worth, a couple of years ago I noted similar network discovery problems involving some cheap TP-Link switches (running stock firmware) which I eventually narrowed down to their IGMP snooping implementation. I concluded that it was buggy and disabled the feature which fixed the issue.

What surprises me is that prior versions of OpenWRT didn’t have this problem. I’d guess there’s some difference / regression in the kernel bridge code.

328

Or (wild guessing here) DSA vs swconfig internals? Does that apply to your devices?

329

Hmm… I didn’t need to perform any configuration changes when upgrading to 23.05 and the device has only one Ethernet port so I don’t think DSA/swconfig is relevant in this case.

330

Hello. The problem with the transmission is still relevant. Some torrents are displayed with a red cross and cannot be rehash. A new downloaded torrent is also not hashed. Downloading torrents does not work. This is a bug in torrents: "No data found! Ensure your drives are connected or use "Set Location". To re-download, remove the torrent and re-add it". The drive is connected and the location is correct. My device is PC Engines APU2.

331

TP-LINK Archer C2600 v1 (which still shows links to 22.03.3 which it did back when 22.03.5 was released) and two Archer A7s updated using Luci from 22.03.5 with settings kept, missing packages installed and devices rebooted. So far all appear to be working normally. Thanks again to all who do the work to make this possible.

332

Hello, I'm on 22.05 on the Netgear RBK50 V1. I want to update,
but i had to reset the settings. Is it possible to made an backup of the settings (22.05) and reload them to the new Version 23.05? or should i setup complete new?

333

I'm not sure if it's already fully supported by 23.05?
At least the tech page states 22.03.5 still...

334

Those techdata pages don't seem to be updating automatically not sure why, but you can get the latest release at the usual place:
[https://firmware-selector.openwrt.org/?version=23.05.0&target=ipq40xx%2Fgeneric&id=netgear_rbr50]

1 Like