That screenshot is utterly useless in this format. Get a copy of your UCI network and wireless configs instead (run the commands uci show network and uci show wireless in CLI and paste the result here - make sure you remove the sensitive details like SSID, MAC adress, WiFi PSK).
1 Like
root@OpenWrt:~# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.path='platform/18000000.wmac'
wireless.radio0.channel='1'
wireless.radio0.band='2g'
wireless.radio0.cell_density='0'
wireless.radio0.htmode='HT20'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='*******'
wireless.default_radio0.encryption='********'
wireless.default_radio0.key='*****'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.path='1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
wireless.radio1.channel='36'
wireless.radio1.band='5g'
wireless.radio1.htmode='HE80'
wireless.radio1.cell_density='0'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid='*****'
wireless.default_radio1.encryption='****'
wireless.default_radio1.key='****'
hello everybody my wifi 2.4 disconnect sometimes the night , i don't know why ? @daniel
i lost the network and reconnect after many minutes, thanks
Hey all,
Picked up a couple Linksys E8450s on sale with the intention of installing OpenWRT and using them in "dumb" AP mode, eventually in 802.11s mesh mode. Tested with the factory-compatible snapshot, and things worked very well for a few days.
Went ahead and did the UBI install from the prebuilt images on github, but saw the same problems with the network quitting that a couple of people seem to have mentioned above. Installed the latest snapshot via Attended Sysupgrade yesterday to see if that would help, and it did. BUT...
It randomized the ethernet macs and, not realizing this, I thought I had locked myself out. Ended up doing a full reset before figuring out what it had done. Is that normal? I generally set up my DHCP server configured so MAC addresses get "static" IPs. This is very useful after a factory reset on APs, switches, etc.
The sysupgrade also re-activated odhcpd and possibly the firewall, which I had disabled, and I am wondering what the proper OpenWRT way is to avoid this when doing a sysupgrade. Or is the proper upgrade procedure to backup, sysupgrade, reset to defaults, and restore? I'd like to be able to upgrade devices in-place, especially with the one probably going in the attic.
Many thanks to all the devs.
Usually, across stable maintenance updates, one can easily sysupgrade with leaving the configuration in place. However, even then I usually do back it up just in case. With snapshots, this is a little bit a different story and such rather unpleasant surprises are somewhat expected. One could now investigate what exactly went wrong and ultimately fix this I guess.
I'm seeing the randomized MAC's as well. I reverted back to a firmware I generated with ImageBuilder from a couple days back and it cleared up the problem. Not sure what changed in the past couple days in the snapshot that appears to be causing this. I have two RT3200 running a BATMAN mesh.
what are random macs macs that appear on wifi because i have the same?
I'm seeing this in Luci, Network -> Interfaces -> Devices tab. eth0, lan1-4, wan were all showing MAC addresses not programmed into my router. i reverted back to a snapshot that had kernel 5.10.50, and it was back to my router's MACs.
2 Likes
It might be related to the recent change by @Ansuel to read MAC addresses via nvmem implementation.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=1e6f330ccfa91f8a6860cfc768299490e3c08603
@ynezz has already fixed a few targets for missing nvmem kernel config definition. Might be that something similar is needed for mediatek target (or the 7622 subtarget)
2 Likes
I've also (UBI) other macs assigned, starting with 1A:86:1D:xx:xx:xx, which is an unknown UOI https://www.cleancss.com/mac-lookup/1A-86-1D
I've updated from 17119 to 17181 today - MAC was properly assigned on the former, but latter started assigning 82:E0:A2:5A:16:35 to every interface.
The mac changes every reboot, which may confuse your switch or devices
1 Like
I compiled r17181-b309248730 for RT3200 and
- WAN and LAN get identical random MAC address, but
- wlan interfaces get the original values of the correct LAN MAC+1 and +2
The WAN/LAN MAC changes at every reboot, so likely it is not read from flash, but is just random.
I then reverted commit 1e6f330cc from @Ansuel
and that fixed things. LAN and WAN MACs are again the normal ones.
So, the bug is in the "MAC via NVMEM" implementation for mt7622.
3 Likes
Just to make sure, can you check if you have the NVMEM flags enabled in the kernel config?
You mean these?
perus@ub2104:/Openwrt/e8450$ grep -i nvmem target/linux/mediatek/mt7622/config-5.10
CONFIG_NVMEM=y
CONFIG_NVMEM_SYSFS=y
and build_dir
perus@ub2104:/Openwrt/e8450/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/linux-5.10.51$ grep -i nvmem .config
# CONFIG_NVMEM_REBOOT_MODE is not set
# CONFIG_RTC_NVMEM is not set
CONFIG_NVMEM=y
CONFIG_NVMEM_SYSFS=y
also can you confirm that you have this in the logs?
generated random MAC address
@hnyman you reverted also the other patch or only that specific commit?
Yes... random.
[ 0.538463] Creating 4 MTD partitions on "spi2.0":
[ 0.543248] 0x000000000000-0x000000080000 : "bl2"
[ 0.548952] 0x000000080000-0x0000001c0000 : "fip"
[ 0.555574] 0x0000001c0000-0x0000002c0000 : "factory"
[ 0.562193] 0x000000300000-0x000008000000 : "ubi"
[ 0.600436] random: fast init done
[ 0.721837] libphy: Fixed MDIO Bus: probed
[ 0.749889] libphy: mdio: probed
[ 0.753938] mtk_soc_eth 1b100000.ethernet: generated random MAC address 1e:ff:43:02:90:cd
[ 0.762462] mtk_soc_eth 1b100000.ethernet eth0: mediatek frame engine at 0xffffffc011a40000, irq 36
And the code in DTS seems ok at the first glance. My normal MACs are in the specified place
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00020000 "bl2"
mtd1: 00140000 00020000 "fip"
mtd2: 00100000 00020000 "factory"
mtd3: 07d00000 00020000 "ubi"
root@OpenWrt:~# hexdump -s 0x7fff4 -n 12 -C /dev/mtd2
0007fff4 c4 41 1e f8 a5 1f c4 41 1e f8 a5 1e |.A.....A....|
00080000
I reverted only that commit 1e6f330cc modifying the DTS. Otherwise up-to-date OpenWrt HEAD.
can you check what you have in
cat /sys/bus/nvmem/devices/mtd2/of_node/
wait you shouldn't have anything....
can you restore only this part?
&factory {
compatible = "nvmem-cells";
#address-cells = <1>;
#size-cells = <1>;
macaddr_factory_7fff4: macaddr@7fff4 {
reg = <0x7fff4 0x6>;
};
macaddr_factory_7fffa: macaddr@7fffa {
reg = <0x7fffa 0x6>;
};
};
Here.
name is ok, but wrong contents for "reg". Or actually, it shows the address.
root@OpenWrt:~# cat /sys/bus/nvmem/devices/mtd2/of_node/
cat: read error: Is a directory
root@OpenWrt:~# ls /sys/bus/nvmem/devices/mtd2/of_node/
#address-cells compatible macaddr@7fff4 name read-only
#size-cells label macaddr@7fffa phandle reg
root@OpenWrt:~# cat /sys/bus/nvmem/devices/mtd2/of_node/macaddr@7fff4/name
macaddr
root@OpenWrt:~# cat /sys/bus/nvmem/devices/mtd2/of_node/macaddr@7fff4/phandle
4
root@OpenWrt:~# hexdump -C /sys/bus/nvmem/devices/mtd2/of_node/macaddr@7fff4/reg
00000000 00 07 ff f4 00 00 00 06 |........|
00000008
root@OpenWrt:~# hexdump -C /sys/bus/nvmem/devices/mtd2/of_node/macaddr@7fffa/reg
00000000 00 07 ff fa 00 00 00 06 |........|
00000008
Note, this is values from the faulty firmware for your debugging. I flashed it back.
1 Like
ok so the cells are actually correctly created and all...
about the wrong reg... they doesn't contain the value of the cell...