OpenWrt 21.02.0 third release candidate

I had the same issue, The problem is the br-lan looses the wlan* interfaces on the migration ans as a consequence wifi clients are isolated.. Add the wlan* interface to the bridge and you will gain lan access.

Thanks to hauke and the rest of the OpenWrt developers.

No issues encountered, such as random reboots.
Nothing noticed in the system log during the 6 days of uptime test.
Archer C2600 rev. 1.1 with irqbalance installed, enabled and running as standard WiFi router.

Moving on to test D-Link (DIR-878, 882, 2640) routers now.

2 Likes

@RaylynnKnight

Could You check if current snapshot work fine?

The Pi4 has incredible potential for OpenWrt given it's strong CPUs, with tons storage (64GB 10-speed microSDs are dirt cheap) and RAM (8GB max now?), but it's wifi isn't good enough to serve as an AP other than maybe for 1 user next to it. Think about it there isn't an antenna array. You're always going to need a seperate AP and gigabit switch for that device.

1 Like

The only thing I'd ask for from the LuCI devs is for a light/dark theme option with the same color scheme just like what's in Preferences > Interface on this forum. It would be nice to have a dark theme. Hell, even the top bar with the OpenWrt icon isn't in LuCI which is a little awkward at this point. Unless you install material theme, but then the color scheme and iconography doesn't match this forum either.

Yes, what did you expect from a HDTV multimedia hub?

By the way, 8GB ram is only meaningful if you run a 64-bit version of O/S. Not even Pi Foundation has managed to make that work on their own device.
If no 64-bit you only get 4,7GB ram.

Yes I know, and I've had the Pi4 2GB since release and it's plenty of ram for this. I just play with it though, mostly run RetroPie with it for a fun emulator box, but doing another microSD with OpenWrt 21.02 to tinker with once it's released. Performance should be exellent even though the WRT32X will probably remain my router.

Timmo.. had you been seeing a problem on non 21 FW, or have you not noticed on 19/18 FW versions?

You might very well be not noticing, since typically theres little to no log evidence, especially as an AP.

@phinn with the chrome extension "Dark Reader" all of the themes have great color scheme

for something that can be handled on the client side fairly easily now, probably there would not be a lot of focus for "dark mode" in luci themes

As I suspected.. either way, the full gigabit NIC is still a sweet enabler for the pi4b to be a much more useful device for openwrt installations versus its predecessors :slight_smile: I'm liking it a lot so far and won't mind at all using a dedicated wireless piece as an AP

Noted that there's a lot of weird things in the implementations of the Pi's integrated controllers and I've heard similarly things about the 8gb model and 64bit support just not quite being there in general for the Pi4b8gb (that basically nullify any supposed benefit of the extra ram, but I could just be repeating false rhetoric, as I'm using the 4gb model so I'm a little less concerned in that arena)

Would it be possible to compile LuCI oneself? or are there config files outside of the binaries/packages that can be changed? I'd imagine that it's just some CSS code or something that would need changing for a custom color scheme

No, I haven't been seeing issues on versions priror to 21.02.0. But I should note that I haven't used this device for over a year just until rc1 came out. So, if the issue you described was introduced some time last year, I couldn't have noticed it on previous releases.
How exactly does the "2.4GHz wifi goes deaf" issue manifest itself for you? Does the 2.4GHz radio stop broadcasting completely? Or can you still connect to the BSSID, but then there's no connectivity?

Yes of course, you can compile all or any part of OpenWrt with imagebuilder. There is a whole tutorial on the doc pages. However to edit all the CSS and add in the color scheme/dark themes would be better just to add the commit to the luci github and help everyone out to get it submitted.

The WRT32x/3200 does not have a PCI Marvell ATA / SATA controller. The driver you reference is for PCI adapters. The Marvell device does have a SATA controller but not on the PCI bus. The only PCI devices are:

PCI bridge: Marvell Technology Group Ltd. 88F6820 [Armada 385] ARM SoC (rev 04)
Ethernet controller: Marvell Technology Group Ltd. 88W8964 [Avastar] 802.11ac Wireless

Also if you look closely at the kmod-ata-marvell-sata file you see that its just an empty shell, i.e., contains no binary. As far as I know there is no Marvell SATA driver for the SATA port on this ASIC.

More info:
https://lwn.net/Articles/585738/

1 Like

Ok, since WRT routers have the eSATA port I thought this driver was used for that, but never looked into it further, I'll just remove it from the list on my future installs. I only use the USB 3.0 port anyway. Thanks for the tip.

There is a ahci driver that operates the SATA port:

[    1.076673] ahci-mvebu f10a8000.sata: f10a8000.sata supply ahci not found, using dummy regulator
[    1.085545] ahci-mvebu f10a8000.sata: f10a8000.sata supply phy not found, using dummy regulator
[    1.094306] ahci-mvebu f10a8000.sata: f10a8000.sata supply target not found, using dummy regulator
[    1.103366] ahci-mvebu f10a8000.sata: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl platform mode
[    1.112455] ahci-mvebu f10a8000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs 
[    1.121558] scsi host0: ahci-mvebu
[    1.125187] scsi host1: ahci-mvebu
[    1.128677] ata1: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x100 irq 41
[    1.136653] ata2: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x180 irq 41

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/ata/ahci_mvebu.c?h=v5.4.127

1 Like

Hi @Mijzelf

I assume you already increased the kernel partition read in the U-Boot environment as described here:
https://git.openwrt.org/33727ecea5675b477986d0370cfd461495a41fd1
If not, please do this.

I assume that the kernel overwrites itself while uncompresing.
Could you change the loadaddr in U-Boot please.

printenv loadaddr
setenv loadaddr 0x80B00000
saveenv

Same issue with trunk as well as 21.02-rc1. The wan interface appears to function correctly as I can run opkg update and install ethtool. However the lan ports do not route traffic although they recognize the link.

root@OpenWrt:/# ifconfig br-lan
br-lan    Link encap:Ethernet  HWaddr 00:1C:7F:23:C8:85  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fdad:9947:2f34:4::1/62 Scope:Global
          inet6 addr: fd91:5a12:c87c::1/60 Scope:Global
          inet6 addr: fe80::21c:7fff:fe23:c885/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:16100 (15.7 KiB)

root@OpenWrt:/# ifconfig lan1
lan1      Link encap:Ethernet  HWaddr 00:1C:7F:23:C8:85  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:106 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:18380 (17.9 KiB)

root@OpenWrt:/# ethtool br-lan
Settings for br-lan:
        Link detected: yes
root@OpenWrt:/# ethtool lan1
Settings for lan1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Link detected: yes
root@OpenWrt:/# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=0.230 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=0.163 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.163/0.196/0.230 ms
root@OpenWrt:/# ping 192.168.1.50
PING 192.168.1.50 (192.168.1.50): 56 data bytes
[  711.759489] mv88e6085 f1072004.mdio-bus-mii:10 lan1: Link is Down
[  711.765673] br-lan: port 1(lan1) entered disabled state
[  722.175103] mv88e6085 f1072004.mdio-bus-mii:10 lan1: Link is Up - 1Gbps/Full - flow control rx/tx
[  722.184069] br-lan: port 1(lan1) entered blocking state
[  722.189343] br-lan: port 1(lan1) entered forwarding state
^C
--- 192.168.1.50 ping statistics ---
69 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:/# ethtool lan1
Settings for lan1:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
                                             1000baseT/Half 1000baseT/Full 
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: d
        Wake-on: d
        Link detected: yes
root@OpenWrt:/# 

root@OpenWrt:/# ifconfig lan1
lan1      Link encap:Ethernet  HWaddr 00:1C:7F:23:C8:85  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:198 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:29092 (28.4 KiB)


Please let me know if there is anything else I can check to help debug the issue.

Use 'brctl show' and ensure that the bridge is properly configured with your 'lan1' and wlan interfaces. I mean, just spitballing, but I'd presume that maybe being named lan1 instead of the typical eth0 might have broken a config somewhere?

My device works great with 21.02-rc3:

BusyBox v1.33.1 (2021-06-13 22:02:19 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 21.02.0-rc3, r16172-2aba3e9784
 -----------------------------------------------------
lan1      Link encap:Ethernet  HWaddr 00:1C:7F:24:A0:6C  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:387065 errors:0 dropped:0 overruns:0 frame:0
          TX packets:769288 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:81761843 (77.9 MiB)  TX bytes:146084156 (139.3 MiB)
root@OpenWrt:/# ping 192.168.1.160
PING 192.168.1.160 (192.168.1.160): 56 data bytes
64 bytes from 192.168.1.160: seq=0 ttl=64 time=0.424 ms
64 bytes from 192.168.1.160: seq=1 ttl=64 time=0.239 ms
64 bytes from 192.168.1.160: seq=2 ttl=64 time=0.224 ms
^C
--- 192.168.1.160 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.224/0.295/0.424 ms
root@OpenWrt:/# arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.1.160    0x1         0x2         00:11:22:de:ad:00     *        br-lan
root@OpenWrt:/# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:1C:7F:24:A0:6B  
          inet addr:192.168.74.13  Bcast:192.168.74.255  Mask:255.255.255.0
          inet6 addr: fe80::21c:7fff:fe24:a06b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1022 errors:0 dropped:0 overruns:0 frame:0
          TX packets:413 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1034259 (1010.0 KiB)  TX bytes:38110 (37.2 KiB)
          Interrupt:58 

root@OpenWrt:/# ping wp.pl
PING wp.pl (212.77.98.9): 56 data bytes
64 bytes from 212.77.98.9: seq=0 ttl=61 time=1.368 ms
64 bytes from 212.77.98.9: seq=1 ttl=61 time=1.221 ms
64 bytes from 212.77.98.9: seq=2 ttl=61 time=1.588 ms
^C
--- wp.pl ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.221/1.392/1.588 ms
root@OpenWrt:/# 

Did You configure all mac adresses in u-boot? Which u-boot You have? Is ethernet working in u-boot?