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
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 
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
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?