I have updated from 19.07.7 to 21.02rc2 and the third radio (phy2/wlan2) is not coming up.
Just wondering if there's a package missing or something else? This is what I get:
kern.info kernel: [ 2130.775646] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0xb1 error, result=0x1
kern.info kernel: [ 2130.782649] mwifiex_sdio mmc0:0001:1: Failed to start the BSS
kern.info kernel: [ 2130.788432] mwifiex_sdio mmc0:0001:1: Failed to start AP
WD My Net N750 works fine after the initial flash but goes infinite bootloop if you reboot/coldreboot it. Maybe some issues with squashfs or nand read/write which were mentioned at [PATCH] SQUASHFS: data probably corrupt. Fortunately you can use emergency flash to go back..
Could you get VHT 160 mhz working?
I have not tried. I do not have any 160mhz clients.
I try prepering image
make image PROFILE=linksys_ea7500-v2 PACKAGES="luci adblock luci-app-adblock"
but I recived
Collected errors:
* pkg_hash_fetch_best_installation_candidate: Packages for libiwinfo20210106 found, but incompatible with the architectures configured
* satisfy_dependencies_for: Cannot satisfy the following dependencies for luci:
* libubus20210215
* opkg_install_cmd: Cannot install package luci.
make[2]: *** [Makefile:167: package_install] Error 255
make[1]: *** [Makefile:122: _call_image] Error 2
make: *** [Makefile:240: image] Error 2
what the reason of that?
Hi guys, I'm super happy for the progress on the DSA thing but you should really consider renaming the DSA switch ports to something meaningful like "swethX", or "swportX", or "dsaportX", or "dsaethX" or whatever different from "lanX".
The use of lanX creates enormous ambiguity with the l3 interface names and makes difficult to explain advanced switch configuration scenarios where the switch ports are not being used for "lan" purposes.
For instance, it's far better to have a "wan" l3 interface on l2 device "eth4" and a "lan" l3 interface on l2 bridge of ports "sweth0/1/2/3". This seems quite consitent to me.
Does anyone know if this release fixes the bug in the last rc that caused Linksys devices to randomly lose connectivity (that was introduced in rc1)?
One side of the coin is the business class units. For example the painted port numbers on the chassi on EdgeRouter4 is eth0-eth3 (WAN doesn’t even exist, use whatever port you want). And these ports where given the names LAN0-LAN3 in OpenWRT.
But on the other side of the coin we have the trillions of home use devices that has the chassi port names WAN (camouflaged LAN0) and LAN1 to LANn.
I guess if the firmware would call these port anything else than LANn or WAN as it says on the chassi. Guess how many trillions of notations it would be on this forum about the wrong name then?
And “LAN” is LocalAreaNetwork, it isn’t even a connector port. It is a complete network system. So it shouldn’t have been painted on the routers in the first place in the 90’.
RC2 is working without issues for two days now on my Archer C7 v4 (I am only using it as AP).
Great job.
Those home devices use LAN or WAN labels on sockets depending on the hardcoded feature that socket is intended for in their stock firmwares. For instance, there are devices where such label would show as "LAN4/WAN" on a dual-feature socket because the firmware supports assigning that same switch port to WAN or LAN networks depending on settings. We will end up configuring a wan interface on lan4 device in openwrt 21, which makes no sense.
If we really intend to use the names printed on the actual RJ45 sockets (which is bad IMHO), then we should use the exact same labels (ie. LAN1, WAN, SFP, LAN4/WAN and so on. However, this doesn't work on home devices where the same switch port is assigned to both an RJ45 socket and an SFP one in mutual exclusion. There are other devices/SoCs where the same "LAN4/WAN" labeled RJ45 socket is dynamically wired either to the switch or to a dedicated eth SoC port in mutual exclusion, and this same socket will be referred as either lan4 or eth1 respectively in openwrt 21, which is weird at least.
Also, if switch ports use socket labels as names then the non-switch ethernet ports should do the same.
In my opinion one thing is the actual socket, another different one is the switch/SoC port names, that's why ethX and swethX is both consistent and unambigous.
On the left side is my original network config from 17.07.7 and on the right side the new not working config (after open menu "interface" in 21.02_rc2).
I used the newest snapshot from today: openwrt-21.02-snapshot-r16130-1b27d89d40-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin
Uwe
I get the same error with the imagebuilder configured for Edgerouter 4 with
libiwinfo20210106
“found but wrong architecture”.
And this is with only the luci package as add-on package.
I tried first with all of my standard packages with the same fault.
I tried a standard build without any packages add-ons at all and it worked.
So the fault is concentrated to the luci package.
The Kernel docs calls them "swpX" which is nice too
DSA Architecture — The Linux Kernel documentation
It is not LuCI itself, but the underlying iwlinfo (libiwinfo) which can't find the correct libubus.
I am proposing (for master) a more permanent fix for the problem with
Not maybe luci itself but luci or anything else with luci in its name isn’t installing on rc2 so this is very much a partymood cooler for the rc2 release.
On Totolink x5000r configuration autogenerated with "wifi config" doesn't work correctly with LUCI (unable to set frequency, channel analysis shows only radio0 with incorrect frequency):
wifi down;rm /etc/config/wireless;wifi config;wifi up;sleep 5;echo radio0;iwinfo radio0 info; echo radio1;iwinfo radio1 info
'radio0' is disabled
'radio1' is disabled
'radio0' is disabled
'radio1' is disabled
radio0
radio0 ESSID: unknown
Access Point: 00:00:00:00:00:00
Mode: Unknown Channel: unknown (unknown)
Center Channel 1: unknown 2: unknown
Tx-Power: unknown Link Quality: unknown/70
Signal: unknown Noise: unknown
Bit Rate: unknown
Encryption: unknown
Type: nl80211 HW Mode(s): 802.11nac
Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy1
radio1
No such wireless device: radio1
Generated device sections:
config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
option htmode 'HT20'
option disabled '1'
config wifi-device 'radio1'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
option htmode 'VHT80'
option disabled '1'
Removing path and forcing correct phy makes luci/iwinfo happy:
config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option disabled_path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0
option phy 'phy0'
option htmode 'HT20'
option disabled '1'
config wifi-device 'radio1'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option disabled_path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0
option phy 'phy1'
option htmode 'VHT80'
option disabled '1'
root@ap01:~# echo radio0;iwinfo radio0 info; echo radio1;iwinfo radio1 info
radio0
radio0 ESSID: unknown
Access Point: 00:00:00:00:00:00
Mode: Unknown Channel: unknown (unknown)
Center Channel 1: unknown 2: unknown
Tx-Power: unknown Link Quality: unknown/70
Signal: unknown Noise: unknown
Bit Rate: unknown
Encryption: unknown
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
radio1
radio1 ESSID: unknown
Access Point: 00:00:00:00:00:00
Mode: Unknown Channel: unknown (unknown)
Center Channel 1: unknown 2: unknown
Tx-Power: unknown Link Quality: unknown/70
Signal: unknown Noise: unknown
Bit Rate: unknown
Encryption: unknown
Type: nl80211 HW Mode(s): 802.11nac
Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy1
Next strange thing: I have two such devices - both have same MAC on phy1:
root@ap01:~# cat /sys/class/ieee80211/phy1/macaddress
00:0c:43:4a:21:4e
root@ap11:~# cat /sys/class/ieee80211/phy1/macaddress
00:0c:43:4a:21:4e
OpenWrt devs, thank u all.
Very cool to be up 2 date with OpenWrt.
Hi,
I updated my X86_64 router (thanks to the UEFI image !!) with 21.02.0-rc2 and I want to declare a bug (or a strange behaviour) about DHCPv6.
All is working fine if I choose a 12h (or more) lease time.
If I configure a shorter lease time (2m, 15m, 1h or even 11h) no DHCPv6 lease is granted (to any host), only SLAAC is working.
However, I thought that the lease time parameter only concerned DHCPv4 but it seems to also impact DHCPv6 server.
I had to put my old WD N750 back into service under OpenWRT 19.07.7 which does not have this problem of lease time (because 19.07.7 has no X86_64 UEFI capable image to deploy it on my X86_64 router)
Regards
Herve
For those using WRT1900ACSv2 wanting to run 21.02.0-rc2: Reporting that WiFi, Samba4, OpenVPN, BlockMount, SQM, WPA3, and separate bridge networks (not necessary VLAN) seem to be working extremely well on uptime Day 1. Formally used David 19.07 builds. Briefly experimented with Divested Builds, left for Samba4 support.
5GHz performance significantly improved with irqbalance. Change 'enabled' from '0' to '1' in '/etc/config/irqbalance'. I would argue this performance gain to be essential. Simultaneously disabled 802.11w which was known to provide issues on mwlwifi and enabled SQM, which may be confounding variables.
UPDATE: Also required a patch to fixed high latencies for the mwlwifi driver. Disable tx_amsdu.
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu