Anyone know if this target/ ipq807x uses DSA? Just curious because I know ipq806x has issues moving to it. I searched the forum but didn't see a clear answer.
See 'lan1'-'lan4' and 'wan':
root@router5:~# ifconfig |grep encap
br-lan Link encap:Ethernet HWaddr 2C:EA:DC:85:E3:3C
hn2wlan Link encap:Ethernet HWaddr 2C:EA:DC:85:E3:3E
hn5wpa2r Link encap:Ethernet HWaddr 2E:EA:DC:85:E3:3D
hn5wpa3 Link encap:Ethernet HWaddr 2C:EA:DC:85:E3:3D
ifb-dns Link encap:Ethernet HWaddr 4A:B5:F5:11:6B:BB
ifb4wan Link encap:Ethernet HWaddr D6:57:5D:97:F5:8B
lan1 Link encap:Ethernet HWaddr 2C:EA:DC:85:E3:3C
lan2 Link encap:Ethernet HWaddr 2C:EA:DC:85:E3:3C
lan3 Link encap:Ethernet HWaddr 2C:EA:DC:85:E3:3C
lan4 Link encap:Ethernet HWaddr 2C:EA:DC:85:E3:3C
lo Link encap:Local Loopback
unet Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
wan Link encap:Ethernet HWaddr 2C:EA:DC:85:E3:3B
Edit:
I got corrected that although it looks like DSA, the underlying driver is still not DSA based.
1 Like
Sadly it does not use DSA, it just looks that way little, given the way the interfaces are named in the DTS. ipq807x is using a very bare-bones switchdev driver, which fakes all switch ports to the kernel as independent ethernet cards (which they are not, they are part of a common switch) with consequences to MAC learning and other quirks resulting out of that. Contrary to the situation with real DSA based drivers, here the kernel does not get to know about these ports being part of a switch and can't account for the pesky little details that are important to that. While that 'works', it has consequences of stuff that doesn't work as it should be (and the driver itself lacks a lot of basic (checksum-) offloading features).
7 Likes
Any brave souls plan to test the newest firmware posted today by Qualcomm (at your own risk!)?
3 Likes
Thanks for correcting me. I got apparently mislead by everything looking like DSA at the first glance.
1 Like
Seems to work about as reliably as what was running before (1837) for me.
I don't really like this approach of attempting to load an initramfs image on every boot.
Maybe I'm being paranoid, but I think it could be a security risk.
Having said that, if other persons (users, developers) are Ok with it then I won't object it.
You are right in that instructions, both on commit and wiki, mention flashing both mtd18 and mtd20 with factory images.
However, they were only added as part of official device support.
I'm sure many early adopters, and maybe even developers like @robimarko , only have one of them flashed with OpenWrt and the other with OEM firmware.
So, I think just silently ignoring this and requiring USB recovery is not a good idea as it could break devices on production environments or on remote locations.
From your other proposals, identifying this and refusing to sysupgrade seems to be the one with less complexity.
I also can't think of a simple way to deal with this.
For now, ignoring it and hoping it doesn't happen seems to a good solution.
I think we can ignore it as long as we have the buy in from other persons (users, developers).
Finally, something related to methodology.
Current implementation creates and maintains a set of OpenWrt specific u-boot variables (with one having a version value so it can be updated in the future).
I don't think I've seen a similar usage, so it would be good to know from core developers whether there is a recommended methodology for implementing dual/multiple boot on OpenWrt, or each device is free to have its own implementation?
I don't think you are paranoid at all.
I also thought about that, but if an adversary have physical access to the device and the knowledge of the initramfs usb boot, they also know about the serial access, so we are only making it a bit harder without the usbboot for an adversary, but a lot harder to recover for a regular user.
About your comment regarding mtd18/20 formatting being new, fair enough. We can refuse with some comments to make the transition easier for early adopters, thanks for that. Should be easy enough to refuse the upgrade, we just need to write the logic to find the wrong UBI volumes, and stop the active partition transfer and the actual sysupgrade.
Your question about the uboot envs methodology is on point.
2 Likes
you need physical access to the device (to insert the flash drive) to make it happen,
but if you do have access, you could just use the serial console instead, if there's no initramfs loading configured ..
both are equally "unsecure", imho.
3 Likes
Gave it a try. Multicast issue still present so only god knows what they fixed or broke this time.
1 Like
Linksys mbvebu routers, popular wrt1900acv1/2/acs / wrt1200ac / wrt3200am and wrt32x and their siblings all have pretty similar dual boot: toggle variable/bootcmd in u-boot to reflect the current boot partition. And usually some automatic reversal after three failed boots, or similar. Usual is to also have sysupgrade modified so that it always writes to the other partition and curent remain as the safe fallback.
The approach needs to be compatible with the bootloader, so possibilities vary somewhat.
1 Like
For those with multicast/unicast issue try disabling packet-steering in System-Startup as well, not just unchecking it in Network-Interfaces. And reboot. (you should not see any trace of it when searching for 'steer' in the System Log)
I don't get any traces of that in my log regardless of enable/disable. As long as it's not enabled through Luci under Interfaces > Global Network Options... then it shouldn't show up anywhere I'd assume.
Just for giggles though I tried your method to see if it made any effect on my ipv6-over-wifi issues... it did not. Multicast-to-unicast is the only rock solid solution thus far.
1 Like
Gave 01890 a try, went back to 01862 which is stable for me.
Getting very, very high ping times and disconnects on 2.4G wifi
Ok, I think we should be fine then.
Now, implementation of logic to detect other slot and refuse sysupgrade if it doesn't have an OpenWrt image seems to be the next step.
Some other thing I was thinking today. We are adding a set of OpenWrt u-boot variables, and one of them help us with versioning so we can change it in the future if we need to.
However, we don't have any protection for their values (like a checksum), that is, if a user modifies one of them we could end up soft-bricking the device.
On the other side, if we have a way to detect modifications to variables and change them for proper values, it could be unexpected for an expert user that really wanted to modify them (to change behavior, develop, or something else).
Again, I could be overthinking things.
We don't want perfect to be the enemy of the good (enough 
)
Users can also set the boot command to 'I am batman' and we shouldn't take that into considartion. It all depends on where we draw the line.
Moving forward with refusing the upgrade if the second partition is not compatible, which I agree is the better option, represents sysupgrade functionality change. Users that could sysupgrade before this proposed change, and leave the second partition as is, will not be able to sysupgrade at all now. do we need to get a device maintainer to chime in?
Yes, I think we need an approval from a device maintainer.
I'm not sure whether we should ask before implementing anything or after having a working solution.
1 Like
I'm facing two issues with the wifi, that have been discussed in this forum before, but I couldn't find a resultion:
Edit: The wifi is now reliably stopping - Thanks @nbd for the flurry of netifd patches
1. Disabling the wifi, from luci, or wifi down, will not always stop the wifi, the clients will disconnet, but the radio will still transmit at least the beacons, as I can see that it still up in the ath11k debug messages, and scanning from other clients still show the bssid, even minutes after the wifi went down.
2. Something is still not right with the BDF and the regulatory domain, at least for AU and 2.4GHZ, I'm limited to 14db tx power.
With the updated BDF in board-2.bin (the current one)
#iw reg get
global
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5600 @ 80), (N/A, 27), (0 ms), DFS
(5650 - 5730 @ 80), (N/A, 27), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 36), (N/A)
(5925 - 6425 @ 160), (N/A, 24), (N/A), NO-OUTDOOR
(57000 - 66000 @ 2160), (N/A, 43), (N/A), NO-OUTDOOR
phy#1 (self-managed)
country AU: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5490 - 5590 @ 80), (N/A, 30), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (N/A, 30), (0 ms), DFS, AUTO-BW
(5735 - 5835 @ 80), (N/A, 36), (N/A), AUTO-BW
phy#0 (self-managed)
country AU: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5490 - 5590 @ 80), (N/A, 30), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (N/A, 30), (0 ms), DFS, AUTO-BW
(5735 - 5835 @ 80), (N/A, 36), (N/A), AUTO-BW
and ath11k debug
ath11k c000000.wifi: mac channel [0/13] freq 2412 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [1/13] freq 2417 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [2/13] freq 2422 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [3/13] freq 2427 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [4/13] freq 2432 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [5/13] freq 2437 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [6/13] freq 2442 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [7/13] freq 2447 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [8/13] freq 2452 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [9/13] freq 2457 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [10/13] freq 2462 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [11/13] freq 2467 maxpower 60 regpower 60 antenna 0 mode 1
ath11k c000000.wifi: mac channel [12/13] freq 2472 maxpower 60 regpower 60 antenna 0 mode 1
...
txpower from firmware 28, reported 14 dBm
The txpower stays on 14db, even after a few minutes.
With the original board-2.bin
#iw reg get
global
country AU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5600 @ 80), (N/A, 27), (0 ms), DFS
(5650 - 5730 @ 80), (N/A, 27), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 36), (N/A)
(5925 - 6425 @ 160), (N/A, 24), (N/A), NO-OUTDOOR
(57000 - 66000 @ 2160), (N/A, 43), (N/A), NO-OUTDOOR
phy#1 (self-managed)
country AU: DFS-FCC
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (6, 24), (N/A), AUTO-BW
(5250 - 5330 @ 80), (6, 24), (0 ms), DFS, AUTO-BW
(5490 - 5590 @ 80), (6, 24), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 24), (0 ms), DFS, AUTO-BW
(5735 - 5835 @ 80), (6, 30), (N/A), AUTO-BW
phy#0 (self-managed)
country AU: DFS-FCC
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (6, 24), (N/A), AUTO-BW
(5250 - 5330 @ 80), (6, 24), (0 ms), DFS, AUTO-BW
(5490 - 5590 @ 80), (6, 24), (0 ms), DFS, AUTO-BW
(5650 - 5730 @ 80), (6, 24), (0 ms), DFS, AUTO-BW
(5735 - 5835 @ 80), (6, 30), (N/A), AUTO-BW
and ath11k debug
ath11k c000000.wifi: mac channel [0/13] freq 2412 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [1/13] freq 2417 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [2/13] freq 2422 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [3/13] freq 2427 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [4/13] freq 2432 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [5/13] freq 2437 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [6/13] freq 2442 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [7/13] freq 2447 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [8/13] freq 2452 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [9/13] freq 2457 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [10/13] freq 2462 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [11/13] freq 2467 maxpower 40 regpower 40 antenna 0 mode 1
ath11k c000000.wifi: mac channel [12/13] freq 2472 maxpower 40 regpower 40 antenna 0 mode 1
...
txpower from firmware 28, reported 14 dBm
The txpower stays on 14db, even after a few minutes.
Notice that the txpower in the above texts is from the 2.4Ghz radio the other one was set to the same country (AU) and being enabled/disabled I saw the same results in the 2.4GHz radio.
I've tried firmware versions 2.7.0.1 to 2.9.0.1 (including 1890) and the same issue appers in all of them.
I think there exists a chance that issue #1 could be on the ath11k driver side, I'll look into that.
I'm not sure about #2, I know that we're limited by the lack of opensource BDF/firmware tooling. Any suggestions on how can I debug this further?
On vendor firmware dBm is reported correctly (ath11k firmware WLAN.HK.2.3-02932-QCAHKSWPL_SILICONZ-1.339214.2 v2). Ath11k firmware backup from Dynalink firmware v1.10.01.254 can be downloaded here: https://file.io/JODQPRHPapR2
For OpenWrt with the same ath11k firmware we have wrong dBm values.
You can check my previous posts: Dynalink DL-WRX36 Askey RT5010W IPQ8072A technical discussion - #1964 by lytr
3 Likes
Newbie question- how do you update the fw posted at quic github?
3 Likes