OpenWrt/LEDE Project

Welcome to the OpenWrt Project bug reporting and issue tracking system

Problems to be reported here are for the current OpenWrt and legacy LEDE Project’s targets, sources, toolchain, core packages, build procedures, distribution and infrastructure. Guidelines for submitting a good bug report can be found at the OpenWrt Project website. Problems related to LuCI or OpenWrt packages need to be reported in their repositories:

Notifications of all submissions and task changes are sent to openwrt-bugs@infradead.org.

OpenedIDCategoryTask TypePrioritySeverity  descSummaryReported InStatus
18.03.20213689KernelBug ReportVery LowLowBPI R64 MT7622 I2S audio supportTrunkUnconfirmed Task Description

Supply the following if possible:

- Device problem occurs on
Bananapi BPI R64

- Software versions of OpenWrt/LEDE release, packages, etc.
Latest OpenWrt snapshot

- Steps to reproduce
according to forumExternal Link and wikiExternal Link

I have edited the dts file and flash it to emmc, but got error, no alsa device

[    0.723692] i2c-core: driver [wm8960] registered; 
[    0.729266] mt2701-wm8960 sound: ASoC: failed to init link wm8960-codec: -517 
[    0.736405] mt2701-wm8960 sound: mt2701_wm8960_machine_probe snd_soc_register_card fail -517
 


19.03.20213691Base systemBug ReportVery LowLowopkg_download_pkg: Package luci is not available from a...openwrt-19.07Unconfirmed Task Description

Software versions: openwrt-19.07.7-brcm63xx-generic-HG553-squashfs-cfe.bin
Device: Huawei EchoLife HG553

I flashed OpenWrt from vertion 18.06 to 19.07.7 while keeping the configuration.
LuCI stopped working.
When I tried to reinstall it, I saw this message:

# opkg install luci
Collected errors:
 * opkg_download_pkg: Package luci is not available from any configured src.
 * opkg_install_pkg: Failed to download luci. Perhaps you need to run 'opkg update'?
 * opkg_install_cmd: Cannot install package luci.

After flashing to 19.07.7 with clean configuration the problem was gone.

But it is still easily reproducible with:

# opkg update
# opkg install --force-reinstall luci
Removing package luci from root...
[...]
Collected errors:
 * opkg_download_pkg: Package luci is not available from any configured src.
 * opkg_install_pkg: Failed to download luci. Perhaps you need to run 'opkg update'?
 * opkg_install_cmd: Cannot install package luci.

and luci package stays broken after this (which should not happen).

19.03.20213692Base systemBug ReportVery LowLowReduce fw3 warnings when both IPv4 and IPv6 are in useTrunkUnconfirmed Task Description

When the same rule uses both IPv4 and IPv6 addresses, fw3 shows a bunch of warnings.

 * Populating IPv4 filter table
   * Rule 'xxx-UDP'
     ! Skipping due to different family of ip address
     ! Skipping due to different family of ip address
 * Populating IPv6 filter table
   * Rule 'xxx-UDP'
     ! Skipping due to different family of ip address
     ! Skipping due to different family of ip address

I suggest to remove that warning or only show it when the family is specified and it does not match.
There is no reason to show that when family is ‘any’.

With too much noise, an important warning messaged might be missed.

20.03.20213696Base systemBug ReportVery LowLowWindows devices can't get IPv6 from DHCPv6 TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on:

   WRT2300ACM

- Software versions of OpenWrt/LEDE release, packages, etc.

   All the latest versions from trunk.

- Steps to reproduce

  1. Add a Windows device to lan
  2. Set the Lease Time to 4h in Luci
  3. Renew the IPv6 lease in the windows device
  4. The device can’t get an IPv6 (trough DHCP) anymore

More useful information:

  • If you restore the lease time to 12h Windows can get an IPv6 address again.
  • My LG webos TV can get an IPv6 address with the short lease, but my ubuntu machine cannot, same as windows.
  • The information we get from the windows logs is:
    1. Solicit is sent from the interface 11. Status code is 0×0
    2. Message is Invalid and it is discarded
  • The windows device still gets an IPv6 address via RA.
  • In the logs odhcpd shows that it receives the solicitation and responds adequately.
21.03.20213698ToolchainBug ReportVery LowLowx86 EFI image GUID Partition Table (GPT) is corruptTrunkUnconfirmed Task Description

If you use `fdisk` to check an OpenWrt image of x86_64 EFI, you will get an error message:

$ fdisk -l openwrt-x86-64-generic-ext4-combined-efi.img
GPT PMBR size mismatch (246303 != 246334) will be corrected by write.
The backup GPT table is corrupt, but the primary appears OK, so that will be used.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
...
  • No matter what size the image are, the PMBR size is always 31 less than real value.
  • There is no secondary partition table at the end of the image.
  • The Backup LBA (offset of image file: 0×220) and Last usable LBA (0×230) values are wrong.

This doesn’t hurt the boot or the usage of OpenWrt x86. However this is NOT a correct way.

According the git history, these EFI support is introduced in this commit 1963bba. And it disabled the secondary partition table.
In the commit message, this incorret operation is ‘to reduce size’. However, this secondary partition table, which has 33 LBAs, takes only 16.5 KiB. I don’t think 16.5 KiB is worth to ‘save’ for an x86_64 device.
Besides, in the commit message the author said ‘This may cause problems when generate vmdk images or vdi images. We have to pad enough sectors when generate these images.’ So, this ‘reduce size’ operation also has side effects, and is not a good tradeoff.

As a conclusion, I hope this problem can be fixed.

21.03.20213699Base systemBug ReportVery LowLow MT7620 platform with spi flash has very low read & wri...TrunkUnconfirmed Task Description

Device: Youku YK-L1(in fact I believe in all mt7620, rt3883, rt305x devices)
Software versions: v19.07
Problem: YK-L1 has a 32 MB flash chip and device has very poor flash read and write performance. It will need 10 minutes to format filesystem after install OpenWrt.
Reason: In kernel config file(/target/linux/ramips/mt7620/config-xxx) it defined CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y. But MT7621 and MT7628 do not has this define. So one block is only 4 KB in MT7620 but 64 KB in MT7628/MT7621. MT7628 is much faster than MT7620 in the same spi frequency.
I do not know why we use 4K sectors in these platform because it seems like won’t waste storage space by set block size to 64 KB.

Here is a rt5350 device and we can see erasesize is 4 KB, same as mt7620.
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00001000 “u-boot” mtd1: 00010000 00001000 “factory” mtd2: 003d0000 00001000 “firmware” mtd3: 0013891e 00001000 “kernel” mtd4: 002976e2 00001000 “rootfs” mtd5: 00039000 00001000 “rootfs_data”

24.03.20213705Base systemBug ReportVery LowLowTrunk: WAN via NCM fails silently every 24 hours after ...TrunkUnconfirmed Task Description

Device: BTHH5a - Lantiq XRX200
Build: Trunk 23.03.21
Reproduce: Occurs every 24 hours

I build trunk to help find regressions.

In the last week I noticed NCM fails silently every 24 hours after flashing on a BTHH5a. Lease time is several days. This is new behavior.

I made a shell script to do a ping check on 3 nameservers to detect and restart WAN>

I predict it will fail again tomorrow at 16:36.

Any clues to more debugging from the NCM subsystem?

Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.524923] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.546637] 1e100c00.serial: ttyLTQ0 at MMIO 0x1e100c00 (irq = 112, base_baud = 0) is a lantiq,asc
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.555560] printk: console [ttyLTQ0] enabled
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.564285] printk: bootconsole [early0] disabled
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.577617] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.582607] nand: AMD/Spansion S34ML01G1
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.586556] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.594819] Bad block table found at page 65472, version 0x01
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.600883] Bad block table found at page 65408, version 0x01
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    0.605938] 4 fixed-partitions partitions found on MTD device 14000000.flash
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    0.612599] Creating 4 MTD partitions on "14000000.flash":
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    0.618093] 0x000000000000-0x0000000a0000 : "u-boot"
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    0.624987] 0x0000000a0000-0x0000000c0000 : "u-boot-env"
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    0.630969] 0x0000000c0000-0x000000100000 : "unused"
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    0.636457] 0x000000100000-0x000007f80000 : "ubi"
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.645077] libphy: Fixed MDIO Bus: probed
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.659563] NET: Registered protocol family 10
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.667008] Segment Routing with IPv6
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.669336] NET: Registered protocol family 17
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.673908] 8021q: 802.1Q VLAN Support v1.8
Tue Mar 23 15:04:05 2021 kern.err kernel: [    0.683515] pcie-xrx200 1d900000.pcie: failed to get the PCIe PHY
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.795893] libphy: lantiq,xrx200-mdio: probed
Tue Mar 23 15:04:05 2021 kern.warn kernel: [    0.805972] net-xrx200: invalid MAC, using random
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.809940] Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.5 / v1.6 0:00: attached PHY driver [Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.5 / v1.6] (mii_bus:phy_addr=0:00, irq=POLL)
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.825543] Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.5 / v1.6 0:01: attached PHY driver [Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.5 / v1.6] (mii_bus:phy_addr=0:01, irq=POLL)
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.840996] Intel XWAY PHY11G (xRX v1.2 integrated) 0:11: attached PHY driver [Intel XWAY PHY11G (xRX v1.2 integrated)] (mii_bus:phy_addr=0:11, irq=POLL)
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.854746] Intel XWAY PHY11G (xRX v1.2 integrated) 0:13: attached PHY driver [Intel XWAY PHY11G (xRX v1.2 integrated)] (mii_bus:phy_addr=0:13, irq=POLL)
Tue Mar 23 15:04:05 2021 kern.info kernel: [    0.868503] Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.5 / v1.6 0:05: attached PHY driver [Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.5 / v1.6] (mii_bus:phy_addr=0:05, irq=POLL)
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.014189] PCI host bridge /fpi@10000000/pcie@d900000 ranges:
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.018835] PCI host bridge to bus 0000:01
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.022731] pci_bus 0000:01: root bus resource [mem 0x1c000000-0x1cffffff]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.029597] pci_bus 0000:01: root bus resource [io  0x1d800000-0x1d8fffff]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.036462] pci_bus 0000:01: root bus resource [??? 0x00000000 flags 0x0]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.043247] pci_bus 0000:01: No busn resource found for root bus, will use [bus 01-ff]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.051218] pci 0000:01:00.0: [1bef:0011] type 01 class 0x060000
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.057191] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to pci-pci bridge
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.075009] pci 0000:01:00.0: ifx_pcie_rc_class_early_fixup+0x0/0x7c took 17350 usecs
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.081558] pci 0000:01:00.0: PME# supported from D0 D3hot
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.090116] pci 0000:01:00.0: bridge configuration invalid ([bus 02-00]), reconfiguring
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.097044] pci 0000:02:00.0: [168c:003c] type 00 class 0x028000
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.102817] pci 0000:02:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.109583] pci 0000:02:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.116354] pci 0000:02:00.0: supports D1 D2
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.123637] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.128881] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 02
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.135500] pci 0000:01:00.0: BAR 8: assigned [mem 0x1c000000-0x1c1fffff]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.142270] pci 0000:01:00.0: BAR 9: assigned [mem 0x1c200000-0x1c2fffff pref]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.149488] pci 0000:02:00.0: BAR 0: assigned [mem 0x1c000000-0x1c1fffff 64bit]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.156820] pci 0000:02:00.0: BAR 6: assigned [mem 0x1c200000-0x1c20ffff pref]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.164012] pci 0000:01:00.0: PCI bridge to [bus 02]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.168989] pci 0000:01:00.0:   bridge window [mem 0x1c000000-0x1c1fffff]
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.175777] pci 0000:01:00.0:   bridge window [mem 0x1c200000-0x1c2fffff pref]
Tue Mar 23 15:04:05 2021 kern.warn kernel: [    1.183147] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1
Tue Mar 23 15:04:05 2021 kern.warn kernel: [    1.189584] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.195879] pcieport 0000:01:00.0: enabling device (0000 -> 0002)
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.203464] UBI: auto-attach mtd3
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.205354] ubi0: attaching mtd3
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.357514] ubi0: scanning is finished
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.374033] ubi0: attached mtd3 (name "ubi", size 126 MiB)
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.378136] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.385029] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.391699] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.398488] ubi0: good PEBs: 1012, bad PEBs: 0, corrupted PEBs: 0
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.404563] ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.411813] ubi0: max/mean erase counter: 1092/814, WL threshold: 4096, image sequence number: 228104625
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.421283] ubi0: available PEBs: 0, total reserved PEBs: 1012, PEBs reserved for bad PEB handling: 20
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.430682] ubi0: background thread "ubi_bgt0d" started, PID 471
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.438869] block ubiblock0_1: created from ubi0:1(rootfs)
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    1.443017] ubiblock: device ubiblock0_1 (rootfs) set to be root filesystem
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.457274] VFS: Mounted root (squashfs filesystem) readonly on device 259:0.
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.466953] Freeing unused kernel memory: 1244K
Tue Mar 23 15:04:05 2021 kern.warn kernel: [    1.470098] This architecture does not have kernel memory protection.
Tue Mar 23 15:04:05 2021 kern.info kernel: [    1.476515] Run /sbin/init as init process
Tue Mar 23 15:04:05 2021 user.info kernel: [    2.113559] init: Console is alive
Tue Mar 23 15:04:05 2021 user.info kernel: [    2.115960] init: - watchdog -
Tue Mar 23 15:04:05 2021 user.info kernel: [    3.754070] kmodloader: loading kernel modules from /etc/modules-boot.d/*
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    3.829501] SCSI subsystem initialized
Tue Mar 23 15:04:05 2021 kern.warn kernel: [    3.842821] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found, using dummy regulator
Tue Mar 23 15:04:05 2021 kern.warn kernel: [    3.849870] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found, using dummy regulator
Tue Mar 23 15:04:05 2021 kern.info kernel: [    3.959564] dwc2 1e101000.usb: DWC OTG Controller
Tue Mar 23 15:04:05 2021 kern.info kernel: [    3.962941] dwc2 1e101000.usb: new USB bus registered, assigned bus number 1
Tue Mar 23 15:04:05 2021 kern.info kernel: [    3.969986] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
Tue Mar 23 15:04:05 2021 kern.info kernel: [    3.977039] hub 1-0:1.0: USB hub found
Tue Mar 23 15:04:05 2021 kern.info kernel: [    3.979562] hub 1-0:1.0: 1 port detected
Tue Mar 23 15:04:05 2021 kern.info kernel: [    3.989718] usbcore: registered new interface driver usb-storage
Tue Mar 23 15:04:05 2021 user.info kernel: [    3.995061] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
Tue Mar 23 15:04:05 2021 user.info kernel: [    4.012149] init: - preinit -
Tue Mar 23 15:04:05 2021 kern.notice kernel: [    5.519932] random: procd: uninitialized urandom read (4 bytes read)
Tue Mar 23 15:04:05 2021 user.info kernel: [    9.824350] mount_root: loading kmods from internal overlay
Tue Mar 23 15:04:05 2021 user.info kernel: [    9.879272] kmodloader: loading kernel modules from //etc/modules-boot.d/*
Tue Mar 23 15:04:05 2021 user.info kernel: [    9.887320] kmodloader: done loading kernel modules from //etc/modules-boot.d/*
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.236622] UBIFS (ubi0:2): Mounting in unauthenticated mode
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.241278] UBIFS (ubi0:2): background thread "ubifs_bgt0_2" started, PID 569
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.367666] UBIFS (ubi0:2): UBIFS: mounted UBI device 0, volume 2, name "rootfs_data"
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.374123] UBIFS (ubi0:2): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.384034] UBIFS (ubi0:2): FS size: 117411840 bytes (111 MiB, 910 LEBs), journal size 5935104 bytes (5 MiB, 46 LEBs)
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.394632] UBIFS (ubi0:2): reserved for root: 4952683 bytes (4836 KiB)
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.401263] UBIFS (ubi0:2): media format: w5/r0 (latest is w5/r0), UUID 2E577506-86FB-47CB-851E-14AE2AB00D76, small LPT model
Tue Mar 23 15:04:05 2021 user.info kernel: [   10.413135] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
Tue Mar 23 15:04:05 2021 user.err kernel: [   10.419837] block: unable to load configuration (fstab: Entry not found)
Tue Mar 23 15:04:05 2021 user.info kernel: [   10.426431] block: attempting to load /tmp/ubifs_cfg/etc/config/fstab
Tue Mar 23 15:04:05 2021 user.err kernel: [   10.432978] block: unable to load configuration (fstab: Entry not found)
Tue Mar 23 15:04:05 2021 user.info kernel: [   10.439565] block: attempting to load /etc/config/fstab
Tue Mar 23 15:04:05 2021 user.err kernel: [   10.451154] block: unable to load configuration (fstab: Entry not found)
Tue Mar 23 15:04:05 2021 user.err kernel: [   10.456712] block: no usable configuration
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.464797] UBIFS (ubi0:2): un-mount UBI device 0
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.468207] UBIFS (ubi0:2): background thread "ubifs_bgt0_2" stops
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.480193] UBIFS (ubi0:2): Mounting in unauthenticated mode
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.484850] UBIFS (ubi0:2): background thread "ubifs_bgt0_2" started, PID 572
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.611041] UBIFS (ubi0:2): UBIFS: mounted UBI device 0, volume 2, name "rootfs_data"
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.617582] UBIFS (ubi0:2): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.627408] UBIFS (ubi0:2): FS size: 117411840 bytes (111 MiB, 910 LEBs), journal size 5935104 bytes (5 MiB, 46 LEBs)
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.638017] UBIFS (ubi0:2): reserved for root: 4952683 bytes (4836 KiB)
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   10.644639] UBIFS (ubi0:2): media format: w5/r0 (latest is w5/r0), UUID 2E577506-86FB-47CB-851E-14AE2AB00D76, small LPT model
Tue Mar 23 15:04:05 2021 user.info kernel: [   10.813961] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
Tue Mar 23 15:04:05 2021 user.err kernel: [   10.819840] block: unable to load configuration (fstab: Entry not found)
Tue Mar 23 15:04:05 2021 user.info kernel: [   10.826434] block: attempting to load /tmp/ubifs_cfg/etc/config/fstab
Tue Mar 23 15:04:05 2021 user.err kernel: [   10.832964] block: unable to load configuration (fstab: Entry not found)
Tue Mar 23 15:04:05 2021 user.info kernel: [   10.839551] block: attempting to load /etc/config/fstab
Tue Mar 23 15:04:05 2021 user.err kernel: [   10.844854] block: unable to load configuration (fstab: Entry not found)
Tue Mar 23 15:04:05 2021 user.err kernel: [   10.851466] block: no usable configuration
Tue Mar 23 15:04:05 2021 user.info kernel: [   10.857203] mount_root: overlay filesystem has not been fully initialized yet
Tue Mar 23 15:04:05 2021 user.info kernel: [   10.864157] mount_root: switching to ubifs overlay
Tue Mar 23 15:04:05 2021 user.warn kernel: [   11.415875] urandom-seed: Seed file not found (/etc/urandom.seed)
Tue Mar 23 15:04:05 2021 user.info kernel: [   11.556254] procd: - early -
Tue Mar 23 15:04:05 2021 user.info kernel: [   11.558063] procd: - watchdog -
Tue Mar 23 15:04:05 2021 user.info kernel: [   12.157149] procd: - watchdog -
Tue Mar 23 15:04:05 2021 user.info kernel: [   12.160252] procd: - ubus -
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   12.418847] random: ubusd: uninitialized urandom read (4 bytes read)
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   12.427687] random: ubusd: uninitialized urandom read (4 bytes read)
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   12.541381] random: ubusd: uninitialized urandom read (4 bytes read)
Tue Mar 23 15:04:05 2021 user.info kernel: [   12.555210] procd: - init -
Tue Mar 23 15:04:05 2021 user.info kernel: [   13.746957] kmodloader: loading kernel modules from /etc/modules.d/*
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.040327] usbcore: registered new interface driver cdc_wdm
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.046552] Loading modules backported from Linux version v5.10.16-0-gde53befa79cf
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.052743] Backport generated by backports.git v5.10.16-1-0-g21d2a1d2
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.097157] Infineon Technologies DEU driver version 2.0.0
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   14.103850] IFX DEU DES initialized (multiblock).
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   14.109222] IFX DEU AES initialized (multiblock).
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   14.113396] IFX DEU ARC4 initialized (multiblock).
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   14.117772] IFX DEU SHA1 initialized.
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   14.121372] IFX DEU MD5 initialized.
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   14.124987] IFX DEU SHA1_HMAC initialized.
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   14.129133] IFX DEU MD5_HMAC initialized.
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.144055] usbcore: registered new interface driver ums-alauda
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.151211] usbcore: registered new interface driver ums-cypress
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.158922] usbcore: registered new interface driver ums-datafab
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.166597] usbcore: registered new interface driver ums-freecom
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.173959] usbcore: registered new interface driver ums-isd200
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.181636] usbcore: registered new interface driver ums-jumpshot
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.189448] usbcore: registered new interface driver ums-karma
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.197117] usbcore: registered new interface driver ums-sddr09
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.206962] usbcore: registered new interface driver ums-sddr55
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.215819] usbcore: registered new interface driver ums-usbat
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.234713] usbcore: registered new interface driver usbserial_generic
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.240120] usbserial: USB Serial support registered for generic
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.268689] xt_time: kernel timezone is -0000
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.274568] ath9k_pci_owl_loader 0000:00:0e.0: enabling device (0000 -> 0002)
Tue Mar 23 15:04:05 2021 kern.warn kernel: [   14.290630] ath9k_pci_owl_loader 0000:00:0e.0: Direct firmware load for ath9k-eeprom-pci-0000:00:0e.0.bin failed with error -2
Tue Mar 23 15:04:05 2021 kern.warn kernel: [   14.300675] ath9k_pci_owl_loader 0000:00:0e.0: Falling back to sysfs fallback for: ath9k-eeprom-pci-0000:00:0e.0.bin
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.316437] usbcore: registered new interface driver cdc_eem
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.326150] usbcore: registered new interface driver cdc_ether
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.336612] usbcore: registered new interface driver cdc_ncm
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.344135] usbcore: registered new interface driver cdc_subset
Tue Mar 23 15:04:05 2021 user.info kernel: [   14.595585] urngd: v1.0.2 started.
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.660686] usbcore: registered new interface driver dm9601
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.668101] usbcore: registered new interface driver huawei_cdc_ncm
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.760747] usbcore: registered new interface driver qmi_wwan
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.770211] usbcore: registered new interface driver rndis_host
Tue Mar 23 15:04:05 2021 kern.warn kernel: [   14.839776] ifx_pcie_bios_map_irq port 0 dev 0000:02:00.0 slot 0 pin 1
Tue Mar 23 15:04:05 2021 kern.warn kernel: [   14.845037] ifx_pcie_bios_map_irq dev 0000:02:00.0 irq 144 assigned
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.851345] ath10k 5.10 driver, optimized for CT firmware, probing pci device: 0x3c.
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.860934] ath10k_pci 0000:02:00.0: enabling device (0000 -> 0002)
Tue Mar 23 15:04:05 2021 kern.info kernel: [   14.866193] ath10k_pci 0000:02:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.117981] usb 1-1: new high-speed USB device number 2 using dwc2
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   15.225687] random: crng init done
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   15.227868] random: 6 urandom warning(s) missed due to ratelimiting
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.363300] huawei_cdc_ncm 1-1:1.3: MAC-Address: 0c:5b:8f:27:9a:64
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.368205] huawei_cdc_ncm 1-1:1.3: setting rx_max = 16384
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.377896] huawei_cdc_ncm 1-1:1.3: setting tx_max = 16384
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.385744] huawei_cdc_ncm 1-1:1.3: NDP will be placed at end of frame for this device.
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.392918] huawei_cdc_ncm 1-1:1.3: cdc-wdm0: USB WDM device
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.400019] huawei_cdc_ncm 1-1:1.3 wwan0: register 'huawei_cdc_ncm' at usb-1e101000.usb-1, Huawei CDC NCM device, 0c:5b:8f:27:9a:64
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.411264] usb-storage 1-1:1.4: USB Mass Storage device detected
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.418201] scsi host0: usb-storage 1-1:1.4
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.568599] ath9k_pci_owl_loader 0000:00:0e.0: fixup device configuration
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.587360] pci 0000:00:0e.0: [168c:002d] type 00 class 0x028000
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.592080] pci 0000:00:0e.0: reg 0x10: [mem 0x18000000-0x1800ffff]
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.598448] pci 0000:00:0e.0: PME# supported from D0 D3hot
Tue Mar 23 15:04:05 2021 kern.info kernel: [   15.607041] pci 0000:00:0e.0: BAR 0: assigned [mem 0x18000000-0x1800ffff]
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   16.443600] scsi 0:0:0:0: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   16.633508] sd 0:0:0:0: [sda] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB)
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   16.642534] sd 0:0:0:0: [sda] Write Protect is off
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   16.646059] sd 0:0:0:0: [sda] Mode Sense: 0f 00 00 00
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   16.647179] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Tue Mar 23 15:04:05 2021 kern.info kernel: [   16.677518]  sda: sda1
Tue Mar 23 15:04:05 2021 kern.notice kernel: [   16.687139] sd 0:0:0:0: [sda] Attached SCSI removable disk
Tue Mar 23 15:04:05 2021 kern.info kernel: [   18.862665] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
Tue Mar 23 15:04:05 2021 kern.info kernel: [   18.870614] ath10k_pci 0000:02:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 1 testmode 0
Tue Mar 23 15:04:05 2021 kern.info kernel: [   18.884330] ath10k_pci 0000:02:00.0: firmware ver 10.1-ct-8x-__fH-022-ecad3248 api 2 features wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,txrate-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 1b2a161c
Tue Mar 23 15:04:05 2021 kern.info kernel: [   19.084124] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
Tue Mar 23 15:04:05 2021 kern.warn kernel: [   19.910149] ath10k_pci 0000:02:00.0: 10.1 wmi init: vdevs: 16  peers: 127  tid: 256
Tue Mar 23 15:04:05 2021 kern.info kernel: [   19.926171] ath10k_pci 0000:02:00.0: wmi print 'P 128 V 8 T 410'
Tue Mar 23 15:04:05 2021 kern.info kernel: [   19.930797] ath10k_pci 0000:02:00.0: wmi print 'msdu-desc: 1424  sw-crypt: 0 ct-sta: 0'
Tue Mar 23 15:04:05 2021 kern.info kernel: [   19.939190] ath10k_pci 0000:02:00.0: wmi print 'alloc rem: 25000 iram: 38944'
Tue Mar 23 15:04:05 2021 kern.info kernel: [   19.992725] ath10k_pci 0000:02:00.0: htt-ver 2.2 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.006953] ath10k_pci 0000:02:00.0: NOTE:  Firmware DBGLOG output disabled in debug_mask: 0x10000000
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.126420] ath: EEPROM regdomain: 0x833a
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.126431] ath: EEPROM indicates we should expect a country code
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.126447] ath: doing EEPROM country->regdmn map search
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.126456] ath: country maps to regdmn code: 0x37
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.126463] ath: Country alpha2 being used: GB
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.126468] ath: Regpair used: 0x37
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.169539] usbcore: registered new interface driver cdc_mbim
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.196975] usbcore: registered new interface driver option
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.201375] usbserial: USB Serial support registered for GSM modem (1-port)
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.208709] option 1-1:1.0: GSM modem (1-port) converter detected
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.214789] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.221505] option 1-1:1.1: GSM modem (1-port) converter detected
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.227689] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.234373] option 1-1:1.2: GSM modem (1-port) converter detected
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.240580] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.267341] ath9k 0000:00:0e.0: enabling device (0000 -> 0002)
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.278171] ath: phy1: Ignoring endianness difference in EEPROM magic bytes.
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.285640] ath: EEPROM regdomain: 0x833a
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.285652] ath: EEPROM indicates we should expect a country code
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.285674] ath: doing EEPROM country->regdmn map search
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.285688] ath: country maps to regdmn code: 0x37
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.285699] ath: Country alpha2 being used: GB
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.285708] ath: Regpair used: 0x37
Tue Mar 23 15:04:05 2021 kern.debug kernel: [   20.306476] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
Tue Mar 23 15:04:05 2021 kern.info kernel: [   20.309393] ieee80211 phy1: Atheros AR9287 Rev:2 mem=0xb8000000, irq=30
Tue Mar 23 15:04:05 2021 user.info kernel: [   20.318838] kmodloader: done loading kernel modules from /etc/modules.d/*
Tue Mar 23 15:04:07 2021 user.notice dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Tue Mar 23 15:04:07 2021 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: Connected to system UBus
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: started, version 2.84 cachesize 150
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: DNS service limited to local subnets
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: UBus support enabled: connected to system bus
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: using only locally-known addresses for domain test
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: using only locally-known addresses for domain onion
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: using only locally-known addresses for domain localhost
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: using only locally-known addresses for domain local
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: using only locally-known addresses for domain invalid
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: using only locally-known addresses for domain bind
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: using only locally-known addresses for domain lan
Tue Mar 23 15:04:08 2021 daemon.warn dnsmasq[1825]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: read /etc/hosts - 4 addresses
Tue Mar 23 15:04:08 2021 daemon.info dnsmasq[1825]: read /tmp/hosts/dhcp.cfg01411c - 0 addresses
Tue Mar 23 15:04:09 2021 authpriv.info dropbear[1887]: Not backgrounding
Tue Mar 23 15:04:11 2021 daemon.notice wpa_supplicant[1986]: Successfully initialized wpa_supplicant
Tue Mar 23 15:04:11 2021 user.notice : Added device handler type: 8021ad
Tue Mar 23 15:04:11 2021 user.notice : Added device handler type: 8021q
Tue Mar 23 15:04:11 2021 user.notice : Added device handler type: macvlan
Tue Mar 23 15:04:11 2021 user.notice : Added device handler type: veth
Tue Mar 23 15:04:11 2021 user.notice : Added device handler type: bridge
Tue Mar 23 15:04:11 2021 user.notice : Added device handler type: Network device
Tue Mar 23 15:04:11 2021 user.notice : Added device handler type: tunnel
Tue Mar 23 15:04:14 2021 daemon.err block: /dev/ubi0_2 is already mounted on /overlay
Tue Mar 23 15:04:17 2021 user.notice ucitrack: Setting up /etc/config/network reload dependency on /etc/config/dhcp
Tue Mar 23 15:04:17 2021 user.notice ucitrack: Setting up /etc/config/network reload dependency on /etc/config/radvd
Tue Mar 23 15:04:17 2021 user.notice ucitrack: Setting up /etc/config/wireless reload dependency on /etc/config/network
Tue Mar 23 15:04:17 2021 user.notice ucitrack: Setting up /etc/config/firewall reload dependency on /etc/config/luci-splash
Tue Mar 23 15:04:17 2021 user.notice ucitrack: Setting up /etc/config/firewall reload dependency on /etc/config/qos
Tue Mar 23 15:04:17 2021 user.notice ucitrack: Setting up /etc/config/firewall reload dependency on /etc/config/miniupnpd
Tue Mar 23 15:04:18 2021 user.notice ucitrack: Setting up /etc/config/dhcp reload dependency on /etc/config/odhcpd
Tue Mar 23 15:04:18 2021 kern.info kernel: [   38.517357] device eth0 entered promiscuous mode
Tue Mar 23 15:04:18 2021 kern.info kernel: [   38.523607] br-lan: port 1(eth0.1) entered blocking state
Tue Mar 23 15:04:18 2021 kern.info kernel: [   38.527689] br-lan: port 1(eth0.1) entered disabled state
Tue Mar 23 15:04:18 2021 kern.info kernel: [   38.533706] device eth0.1 entered promiscuous mode
Tue Mar 23 15:04:18 2021 daemon.notice netifd: Interface 'lan' is enabled
Tue Mar 23 15:04:18 2021 daemon.notice netifd: Interface 'lan' is setting up now
Tue Mar 23 15:04:18 2021 daemon.debug dnsmasq[1825]: listening on br-lan(#6): 192.168.9.1 port 53
Tue Mar 23 15:04:18 2021 daemon.notice netifd: Interface 'lan' is now up
Tue Mar 23 15:04:18 2021 daemon.debug dnsmasq[1825]: listening on lo(#1): 127.0.0.1 port 53
Tue Mar 23 15:04:18 2021 daemon.debug dnsmasq[1825]: listening on lo(#1): ::1 port 53
Tue Mar 23 15:04:18 2021 daemon.notice netifd: Interface 'loopback' is enabled
Tue Mar 23 15:04:18 2021 daemon.notice netifd: Interface 'loopback' is setting up now
Tue Mar 23 15:04:18 2021 daemon.notice netifd: Interface 'loopback' is now up
Tue Mar 23 15:04:18 2021 daemon.notice netifd: Interface 'wan' is setting up now
Tue Mar 23 15:04:18 2021 daemon.notice netifd: Network device 'lo' link is up
Tue Mar 23 15:04:18 2021 daemon.notice netifd: Interface 'loopback' has link connectivity
Tue Mar 23 15:04:19 2021 daemon.err odhcpd[2208]: Failed to send to ff02::1%lan@br-lan (Permission denied)
Tue Mar 23 15:04:19 2021 user.notice ucitrack: Setting up non-init /etc/config/fstab reload handler: /sbin/block mount
Tue Mar 23 15:04:20 2021 user.notice ucitrack: Setting up /etc/config/system reload trigger for non-procd /etc/init.d/led
Tue Mar 23 15:04:20 2021 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878132] ath: EEPROM regdomain: 0x8174
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878196] ath: EEPROM indicates we should expect a country code
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878212] ath: doing EEPROM country->regdmn map search
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878251] ath: country maps to regdmn code: 0x37
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878262] ath: Country alpha2 being used: IE
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878268] ath: Regpair used: 0x37
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878280] ath: regdomain 0x8174 dynamically updated by user
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878538] ath: EEPROM regdomain: 0x8174
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878560] ath: EEPROM indicates we should expect a country code
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878586] ath: doing EEPROM country->regdmn map search
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878657] ath: country maps to regdmn code: 0x37
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878668] ath: Country alpha2 being used: IE
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878674] ath: Regpair used: 0x37
Tue Mar 23 15:04:20 2021 kern.debug kernel: [   40.878686] ath: regdomain 0x8174 dynamically updated by user
Tue Mar 23 15:04:21 2021 user.notice ucitrack: Setting up /etc/config/system reload dependency on /etc/config/luci_statistics
Tue Mar 23 15:04:21 2021 user.notice ucitrack: Setting up /etc/config/system reload dependency on /etc/config/dhcp
Tue Mar 23 15:04:23 2021 daemon.notice netifd: wan (2527): sending -> AT
Tue Mar 23 15:04:23 2021 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy1.conf (phy wlan1) --> new PHY
Tue Mar 23 15:04:24 2021 kern.info kernel: [   44.120562] br-lan: port 2(wlan1) entered blocking state
Tue Mar 23 15:04:24 2021 kern.info kernel: [   44.124694] br-lan: port 2(wlan1) entered disabled state
Tue Mar 23 15:04:24 2021 kern.info kernel: [   44.130939] device wlan1 entered promiscuous mode
Tue Mar 23 15:04:24 2021 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
Tue Mar 23 15:04:24 2021 daemon.notice netifd: wan (2527): sending -> ATZ
Tue Mar 23 15:04:24 2021 kern.info kernel: [   44.494055] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Tue Mar 23 15:04:24 2021 kern.info kernel: [   44.499500] br-lan: port 2(wlan1) entered blocking state
Tue Mar 23 15:04:24 2021 kern.info kernel: [   44.504420] br-lan: port 2(wlan1) entered forwarding state
Tue Mar 23 15:04:24 2021 daemon.notice netifd: bridge 'br-lan' link is up
Tue Mar 23 15:04:24 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Tue Mar 23 15:04:24 2021 kern.info kernel: [   44.526090] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
Tue Mar 23 15:04:24 2021 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) --> new PHY
Tue Mar 23 15:04:24 2021 daemon.notice procd: /etc/rc.d/S96led: setting up led wifi
Tue Mar 23 15:04:24 2021 daemon.notice procd: /etc/rc.d/S96led: setting up led dsl
Tue Mar 23 15:04:24 2021 daemon.notice netifd: wan (2527): sending -> ATQ0
Tue Mar 23 15:04:25 2021 daemon.notice netifd: wan (2527): sending -> ATV1
Tue Mar 23 15:04:25 2021 kern.warn kernel: [   45.516706] ath10k_pci 0000:02:00.0: 10.1 wmi init: vdevs: 16  peers: 127  tid: 256
Tue Mar 23 15:04:25 2021 kern.info kernel: [   45.532563] ath10k_pci 0000:02:00.0: wmi print 'P 128 V 8 T 410'
Tue Mar 23 15:04:25 2021 kern.info kernel: [   45.537788] ath10k_pci 0000:02:00.0: wmi print 'msdu-desc: 1424  sw-crypt: 0 ct-sta: 0'
Tue Mar 23 15:04:25 2021 kern.info kernel: [   45.545295] ath10k_pci 0000:02:00.0: wmi print 'alloc rem: 25000 iram: 38944'
Tue Mar 23 15:04:25 2021 kern.warn kernel: [   45.615705] ath10k_pci 0000:02:00.0: pdev param 0 not supported by firmware
Tue Mar 23 15:04:25 2021 kern.info kernel: [   45.630004] ath10k_pci 0000:02:00.0: rts threshold -1
Tue Mar 23 15:04:25 2021 kern.warn kernel: [   45.633786] ath10k_pci 0000:02:00.0: set-coverage-class, phyclk: 88  value: 1
Tue Mar 23 15:04:25 2021 daemon.err odhcpd[2208]: Failed to send to ff02::1%lan@br-lan (Address not available)
Tue Mar 23 15:04:25 2021 kern.info kernel: [   45.656565] br-lan: port 3(wlan0) entered blocking state
Tue Mar 23 15:04:25 2021 kern.info kernel: [   45.660628] br-lan: port 3(wlan0) entered disabled state
Tue Mar 23 15:04:25 2021 kern.info kernel: [   45.666544] device wlan0 entered promiscuous mode
Tue Mar 23 15:04:25 2021 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Tue Mar 23 15:04:25 2021 daemon.notice hostapd: ACS: Automatic channel selection started, this may take a bit
Tue Mar 23 15:04:25 2021 daemon.notice hostapd: wlan0: interface state COUNTRY_UPDATE->ACS
Tue Mar 23 15:04:25 2021 daemon.notice hostapd: wlan0: ACS-STARTED
Tue Mar 23 15:04:25 2021 daemon.notice procd: /etc/rc.d/S96led: setting up led dimmed
Tue Mar 23 15:04:25 2021 daemon.notice hostapd: wlan1: interface state COUNTRY_UPDATE->ENABLED
Tue Mar 23 15:04:25 2021 daemon.notice hostapd: wlan1: AP-ENABLED
Tue Mar 23 15:04:26 2021 daemon.notice netifd: wan (2527): sending -> ATE1
Tue Mar 23 15:04:26 2021 daemon.debug dnsmasq[1825]: listening on wlan1(#8): fe80::1a62:2cff:fe27:244a%wlan1 port 53
Tue Mar 23 15:04:26 2021 daemon.debug dnsmasq[1825]: listening on br-lan(#6): fe80::a21b:29ff:fe5b:7faa%br-lan port 53
Tue Mar 23 15:04:26 2021 daemon.notice netifd: wan (2527): sending -> ATS0=0
Tue Mar 23 15:04:26 2021 daemon.info procd: - init complete -
Tue Mar 23 15:04:27 2021 daemon.notice netifd: wan (2527): sending -> AT+CGDCONT=1,"IP","broadband.mymeteor.ie"
Tue Mar 23 15:04:27 2021 daemon.info urandom_seed[3256]: Seed saved (/etc/urandom.seed)
Tue Mar 23 15:04:27 2021 daemon.notice netifd: Network device 'wlan1' link is up
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[1825]: exiting on receipt of SIGTERM
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: Connected to system UBus
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: started, version 2.84 cachesize 150
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: DNS service limited to local subnets
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: UBus support enabled: connected to system bus
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq-dhcp[3330]: DHCP, IP range 192.168.9.100 -- 192.168.9.249, lease time 12h
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain test
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain onion
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain localhost
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain local
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain invalid
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain bind
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain lan
Tue Mar 23 15:04:28 2021 daemon.warn dnsmasq[3330]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: read /etc/hosts - 4 addresses
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: read /tmp/hosts/dhcp.cfg01411c - 1 addresses
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq-dhcp[3330]: read /etc/ethers - 0 addresses
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: read /etc/hosts - 4 addresses
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq[3330]: read /tmp/hosts/dhcp.cfg01411c - 1 addresses
Tue Mar 23 15:04:28 2021 daemon.info dnsmasq-dhcp[3330]: read /etc/ethers - 0 addresses
Tue Mar 23 15:04:28 2021 daemon.notice netifd: wan (2527): Configuring modem
Tue Mar 23 15:04:28 2021 daemon.notice netifd: wan (2527): Starting network wan
Tue Mar 23 15:04:28 2021 daemon.notice netifd: wan (2527): Connecting modem
Tue Mar 23 15:04:28 2021 daemon.notice netifd: wan (2527): sending -> AT^NDISDUP=1,1,"broadband.mymeteor.ie"
Tue Mar 23 15:04:29 2021 daemon.notice netifd: wan (2527): Setting up wwan0
Tue Mar 23 15:04:29 2021 daemon.notice netifd: Interface 'wan' is now up
Tue Mar 23 15:04:29 2021 daemon.notice netifd: Network device 'wwan0' link is up
Tue Mar 23 15:04:29 2021 daemon.notice netifd: Network alias 'wwan0' link is up
Tue Mar 23 15:04:29 2021 daemon.notice netifd: Interface 'wan_4' is enabled
Tue Mar 23 15:04:29 2021 daemon.notice netifd: Interface 'wan_4' has link connectivity
Tue Mar 23 15:04:29 2021 daemon.notice netifd: Interface 'wan_4' is setting up now
Tue Mar 23 15:04:30 2021 daemon.info dnsmasq[3330]: read /etc/hosts - 4 addresses
Tue Mar 23 15:04:30 2021 daemon.info dnsmasq[3330]: read /tmp/hosts/dhcp.cfg01411c - 1 addresses
Tue Mar 23 15:04:30 2021 daemon.info dnsmasq-dhcp[3330]: read /etc/ethers - 0 addresses
Tue Mar 23 15:04:30 2021 daemon.notice netifd: wan_4 (3534): udhcpc: started, v1.33.0
Tue Mar 23 15:04:30 2021 user.notice firewall: Reloading firewall due to ifup of wan (wwan0)
Tue Mar 23 15:04:30 2021 daemon.notice netifd: wan_4 (3534): udhcpc: sending discover
Tue Mar 23 15:04:30 2021 daemon.notice netifd: wan_4 (3534): udhcpc: sending select for 100.70.78.141
Tue Mar 23 15:04:30 2021 daemon.notice netifd: wan_4 (3534): udhcpc: lease of 100.70.78.141 obtained, lease time 518400
Tue Mar 23 15:04:31 2021 daemon.debug dnsmasq[3330]: listening on wwan0(#3): 100.70.78.141 port 53
Tue Mar 23 15:04:31 2021 daemon.notice netifd: Interface 'wan_4' is now up
Tue Mar 23 15:04:31 2021 daemon.info dnsmasq[3330]: reading /tmp/resolv.conf.d/resolv.conf.auto
Tue Mar 23 15:04:31 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain test
Tue Mar 23 15:04:31 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain onion
Tue Mar 23 15:04:31 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain localhost
Tue Mar 23 15:04:31 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain local
Tue Mar 23 15:04:31 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain invalid
Tue Mar 23 15:04:31 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain bind
Tue Mar 23 15:04:31 2021 daemon.info dnsmasq[3330]: using only locally-known addresses for domain lan
Tue Mar 23 15:04:31 2021 daemon.info dnsmasq[3330]: using nameserver 159.134.0.11#53
Tue Mar 23 15:04:31 2021 daemon.info dnsmasq[3330]: using nameserver 159.134.0.12#53
Tue Mar 23 15:04:31 2021 daemon.debug dnsmasq[3330]: listening on wwan0(#3): fe80::e5b:8fff:fe27:9a64%wwan0 port 53
Tue Mar 23 15:04:32 2021 user.notice firewall: Reloading firewall due to ifup of wan_4 (wwan0)
Tue Mar 23 16:35:41 2021 daemon.info hostapd: wlan1: STA d8:9c:67:ac:c4:b3 IEEE 802.11: authenticated
Tue Mar 23 16:35:41 2021 daemon.info hostapd: wlan1: STA d8:9c:67:ac:c4:b3 IEEE 802.11: associated (aid 1)
Tue Mar 23 16:35:41 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED d8:9c:67:ac:c4:b3
Tue Mar 23 16:35:41 2021 daemon.info hostapd: wlan1: STA d8:9c:67:ac:c4:b3 WPA: pairwise key handshake completed (RSN)
Tue Mar 23 16:35:41 2021 user.info banIP-0.7.5[4021]: start banIP processing (refresh)
Tue Mar 23 16:35:41 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.186 d8:9c:67:ac:c4:b3
Tue Mar 23 16:35:41 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.186 d8:9c:67:ac:c4:b3 JDonnell
Tue Mar 23 16:35:42 2021 daemon.info dnsmasq[3330]: read /etc/hosts - 4 addresses
Tue Mar 23 16:35:42 2021 daemon.info dnsmasq[3330]: read /tmp/hosts/odhcpd - 0 addresses
Tue Mar 23 16:35:42 2021 daemon.info dnsmasq[3330]: read /tmp/hosts/dhcp.cfg01411c - 1 addresses
Tue Mar 23 16:35:42 2021 daemon.info dnsmasq-dhcp[3330]: read /etc/ethers - 0 addresses
Tue Mar 23 16:35:42 2021 user.info banIP-0.7.5[4021]: IP address '100.70.78.141/30' added to whitelist
Tue Mar 23 16:35:47 2021 daemon.notice hostapd: wlan0: ACS-COMPLETED freq=5500 channel=100
Tue Mar 23 16:35:47 2021 daemon.notice hostapd: wlan0: interface state ACS->HT_SCAN
Tue Mar 23 16:35:50 2021 daemon.notice hostapd: wlan0: interface state HT_SCAN->DFS
Tue Mar 23 16:35:50 2021 daemon.notice hostapd: wlan0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=1, seg0=106, seg1=0, cac_time=60s
Tue Mar 23 16:36:07 2021 cron.err crond[2278]: time disparity of 91 minutes detected
Tue Mar 23 16:36:47 2021 daemon.info hostapd: wlan1: STA a4:71:74:e9:90:33 IEEE 802.11: authenticated
Tue Mar 23 16:36:47 2021 daemon.info hostapd: wlan1: STA a4:71:74:e9:90:33 IEEE 802.11: associated (aid 2)
Tue Mar 23 16:36:47 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED a4:71:74:e9:90:33
Tue Mar 23 16:36:47 2021 daemon.info hostapd: wlan1: STA a4:71:74:e9:90:33 WPA: pairwise key handshake completed (RSN)
Tue Mar 23 16:36:47 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.157 a4:71:74:e9:90:33
Tue Mar 23 16:36:47 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.157 a4:71:74:e9:90:33 HUAWEI_P9
Tue Mar 23 16:36:47 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.157 a4:71:74:e9:90:33
Tue Mar 23 16:36:47 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.157 a4:71:74:e9:90:33 HUAWEI_P9
Tue Mar 23 16:36:50 2021 kern.info kernel: [  123.929810] ath10k_pci 0000:02:00.0: mac flush null vif, drop 0 queues 0xffff
Tue Mar 23 16:36:50 2021 daemon.notice hostapd: wlan0: DFS-CAC-COMPLETED success=1 freq=5500 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0
Tue Mar 23 16:36:51 2021 kern.info kernel: [  124.246614] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Tue Mar 23 16:36:51 2021 kern.info kernel: [  124.252192] br-lan: port 3(wlan0) entered blocking state
Tue Mar 23 16:36:51 2021 kern.info kernel: [  124.256935] br-lan: port 3(wlan0) entered forwarding state
Tue Mar 23 16:36:51 2021 daemon.notice hostapd: wlan0: interface state DFS->ENABLED
Tue Mar 23 16:36:51 2021 daemon.notice hostapd: wlan0: AP-ENABLED
Tue Mar 23 16:36:51 2021 daemon.notice netifd: Network device 'wlan0' link is up
Tue Mar 23 16:36:52 2021 daemon.debug dnsmasq[3330]: listening on wlan0(#9): fe80::1a62:2cff:fe27:244b%wlan0 port 53
Tue Mar 23 16:36:59 2021 daemon.warn dnsmasq[3330]: nameserver 159.134.0.11 refused to do a recursive query
Tue Mar 23 16:39:36 2021 user.info banIP-0.7.5[4021]: 20 IPSets with overall 341200 IPs/Prefixes loaded successfully (BT Home Hub 5A, OpenWrt SNAPSHOT r16313-851dadc257)
Tue Mar 23 16:53:54 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED a4:71:74:e9:90:33
Tue Mar 23 16:53:54 2021 daemon.info hostapd: wlan1: STA a4:71:74:e9:90:33 IEEE 802.11: disassociated
Tue Mar 23 16:53:55 2021 daemon.info hostapd: wlan1: STA a4:71:74:e9:90:33 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Mar 23 20:07:26 2021 daemon.info hostapd: wlan0: STA a4:71:74:e9:90:33 IEEE 802.11: authenticated
Tue Mar 23 20:07:26 2021 daemon.info hostapd: wlan0: STA a4:71:74:e9:90:33 IEEE 802.11: associated (aid 1)
Tue Mar 23 20:07:26 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED a4:71:74:e9:90:33
Tue Mar 23 20:07:26 2021 daemon.info hostapd: wlan0: STA a4:71:74:e9:90:33 WPA: pairwise key handshake completed (RSN)
Tue Mar 23 20:07:26 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.157 a4:71:74:e9:90:33
Tue Mar 23 20:07:26 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.157 a4:71:74:e9:90:33 HUAWEI_P9
Tue Mar 23 20:07:26 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.157 a4:71:74:e9:90:33
Tue Mar 23 20:07:26 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.157 a4:71:74:e9:90:33 HUAWEI_P9
Tue Mar 23 20:32:40 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: authenticated
Tue Mar 23 20:32:40 2021 daemon.notice hostapd: wlan0: STA-OPMODE-N_SS-CHANGED 8c:f5:a3:a5:78:02 2
Tue Mar 23 20:32:40 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: associated (aid 2)
Tue Mar 23 20:32:40 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 8c:f5:a3:a5:78:02
Tue Mar 23 20:32:40 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 WPA: pairwise key handshake completed (RSN)
Tue Mar 23 20:32:44 2021 daemon.info dnsmasq-dhcp[3330]: DHCPDISCOVER(br-lan) 8c:f5:a3:a5:78:02
Tue Mar 23 20:32:44 2021 daemon.info dnsmasq-dhcp[3330]: DHCPOFFER(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Tue Mar 23 20:32:44 2021 daemon.info dnsmasq-dhcp[3330]: DHCPDISCOVER(br-lan) 8c:f5:a3:a5:78:02
Tue Mar 23 20:32:44 2021 daemon.info dnsmasq-dhcp[3330]: DHCPOFFER(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Tue Mar 23 20:32:44 2021 daemon.info dnsmasq-dhcp[3330]: DHCPDISCOVER(br-lan) 8c:f5:a3:a5:78:02
Tue Mar 23 20:32:44 2021 daemon.info dnsmasq-dhcp[3330]: DHCPOFFER(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Tue Mar 23 20:32:44 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Tue Mar 23 20:32:44 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02 Galaxy-S7
Tue Mar 23 21:07:34 2021 daemon.notice hostapd: wlan1: STA-OPMODE-MAX-BW-CHANGED d8:9c:67:ac:c4:b3 20
Tue Mar 23 21:08:12 2021 daemon.notice hostapd: wlan1: STA-OPMODE-MAX-BW-CHANGED d8:9c:67:ac:c4:b3 40
Tue Mar 23 21:08:14 2021 daemon.notice hostapd: wlan1: STA-OPMODE-MAX-BW-CHANGED d8:9c:67:ac:c4:b3 20
Tue Mar 23 21:09:34 2021 daemon.notice hostapd: wlan1: STA-OPMODE-MAX-BW-CHANGED d8:9c:67:ac:c4:b3 40
Tue Mar 23 21:09:36 2021 daemon.notice hostapd: wlan1: STA-OPMODE-MAX-BW-CHANGED d8:9c:67:ac:c4:b3 20
Tue Mar 23 21:10:34 2021 daemon.notice hostapd: wlan1: STA-OPMODE-MAX-BW-CHANGED d8:9c:67:ac:c4:b3 40
Tue Mar 23 21:56:43 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 8c:f5:a3:a5:78:02
Tue Mar 23 21:56:43 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: disassociated due to inactivity
Tue Mar 23 21:56:44 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Mar 23 22:05:59 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: authenticated
Tue Mar 23 22:05:59 2021 daemon.notice hostapd: wlan0: STA-OPMODE-N_SS-CHANGED 8c:f5:a3:a5:78:02 2
Tue Mar 23 22:05:59 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: associated (aid 2)
Tue Mar 23 22:05:59 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 8c:f5:a3:a5:78:02
Tue Mar 23 22:05:59 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 WPA: pairwise key handshake completed (RSN)
Tue Mar 23 22:06:00 2021 daemon.info dnsmasq-dhcp[3330]: DHCPDISCOVER(br-lan) 8c:f5:a3:a5:78:02
Tue Mar 23 22:06:00 2021 daemon.info dnsmasq-dhcp[3330]: DHCPOFFER(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Tue Mar 23 22:06:00 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Tue Mar 23 22:06:00 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02 Galaxy-S7
Tue Mar 23 22:35:41 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.186 d8:9c:67:ac:c4:b3
Tue Mar 23 22:35:41 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.186 d8:9c:67:ac:c4:b3 JDonnell
Wed Mar 24 00:06:56 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED a4:71:74:e9:90:33
Wed Mar 24 00:06:56 2021 daemon.info hostapd: wlan0: STA a4:71:74:e9:90:33 IEEE 802.11: disassociated
Wed Mar 24 00:06:57 2021 daemon.info hostapd: wlan0: STA a4:71:74:e9:90:33 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Mar 24 01:15:07 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 8c:f5:a3:a5:78:02
Wed Mar 24 01:15:07 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: disassociated due to inactivity
Wed Mar 24 01:15:08 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Mar 24 04:08:01 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.186 d8:9c:67:ac:c4:b3
Wed Mar 24 04:08:01 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.186 d8:9c:67:ac:c4:b3 JDonnell
Wed Mar 24 09:39:15 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.186 d8:9c:67:ac:c4:b3
Wed Mar 24 09:39:15 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.186 d8:9c:67:ac:c4:b3 JDonnell
Wed Mar 24 11:53:18 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: authenticated
Wed Mar 24 11:53:18 2021 daemon.notice hostapd: wlan0: STA-OPMODE-N_SS-CHANGED 8c:f5:a3:a5:78:02 2
Wed Mar 24 11:53:18 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: associated (aid 1)
Wed Mar 24 11:53:18 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 8c:f5:a3:a5:78:02
Wed Mar 24 11:53:18 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 WPA: pairwise key handshake completed (RSN)
Wed Mar 24 11:53:22 2021 daemon.info dnsmasq-dhcp[3330]: DHCPDISCOVER(br-lan) 8c:f5:a3:a5:78:02
Wed Mar 24 11:53:22 2021 daemon.info dnsmasq-dhcp[3330]: DHCPOFFER(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Wed Mar 24 11:53:22 2021 daemon.info dnsmasq-dhcp[3330]: DHCPDISCOVER(br-lan) 8c:f5:a3:a5:78:02
Wed Mar 24 11:53:22 2021 daemon.info dnsmasq-dhcp[3330]: DHCPOFFER(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Wed Mar 24 11:53:22 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Wed Mar 24 11:53:22 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02 Galaxy-S7
Wed Mar 24 11:53:47 2021 daemon.info hostapd: wlan0: STA a4:71:74:e9:90:33 IEEE 802.11: authenticated
Wed Mar 24 11:53:47 2021 daemon.info hostapd: wlan0: STA a4:71:74:e9:90:33 IEEE 802.11: associated (aid 2)
Wed Mar 24 11:53:47 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED a4:71:74:e9:90:33
Wed Mar 24 11:53:47 2021 daemon.info hostapd: wlan0: STA a4:71:74:e9:90:33 WPA: pairwise key handshake completed (RSN)
Wed Mar 24 11:53:47 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.157 a4:71:74:e9:90:33
Wed Mar 24 11:53:47 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.157 a4:71:74:e9:90:33 HUAWEI_P9
Wed Mar 24 11:53:47 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.157 a4:71:74:e9:90:33
Wed Mar 24 11:53:47 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.157 a4:71:74:e9:90:33 HUAWEI_P9
Wed Mar 24 13:31:24 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED a4:71:74:e9:90:33
Wed Mar 24 13:31:24 2021 daemon.info hostapd: wlan0: STA a4:71:74:e9:90:33 IEEE 802.11: disassociated
Wed Mar 24 13:31:25 2021 daemon.info hostapd: wlan0: STA a4:71:74:e9:90:33 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Mar 24 13:31:33 2021 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED d8:9c:67:ac:c4:b3
Wed Mar 24 13:31:33 2021 daemon.info hostapd: wlan1: STA d8:9c:67:ac:c4:b3 IEEE 802.11: disassociated
Wed Mar 24 13:31:34 2021 daemon.info hostapd: wlan1: STA d8:9c:67:ac:c4:b3 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Mar 24 14:03:29 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 8c:f5:a3:a5:78:02
Wed Mar 24 14:03:29 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: disassociated due to inactivity
Wed Mar 24 14:03:30 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Wed Mar 24 14:08:57 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: authenticated
Wed Mar 24 14:08:57 2021 daemon.notice hostapd: wlan0: STA-OPMODE-N_SS-CHANGED 8c:f5:a3:a5:78:02 2
Wed Mar 24 14:08:57 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 IEEE 802.11: associated (aid 1)
Wed Mar 24 14:08:57 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 8c:f5:a3:a5:78:02
Wed Mar 24 14:08:57 2021 daemon.info hostapd: wlan0: STA 8c:f5:a3:a5:78:02 WPA: pairwise key handshake completed (RSN)
Wed Mar 24 14:08:58 2021 daemon.info dnsmasq-dhcp[3330]: DHCPDISCOVER(br-lan) 8c:f5:a3:a5:78:02
Wed Mar 24 14:08:58 2021 daemon.info dnsmasq-dhcp[3330]: DHCPOFFER(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Wed Mar 24 14:08:58 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02
Wed Mar 24 14:08:58 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.117 8c:f5:a3:a5:78:02 Galaxy-S7
Wed Mar 24 16:25:29 2021 daemon.info hostapd: wlan1: STA d8:9c:67:ac:c4:b3 IEEE 802.11: authenticated
Wed Mar 24 16:25:29 2021 daemon.info hostapd: wlan1: STA d8:9c:67:ac:c4:b3 IEEE 802.11: associated (aid 1)
Wed Mar 24 16:25:29 2021 daemon.notice hostapd: wlan1: AP-STA-CONNECTED d8:9c:67:ac:c4:b3
Wed Mar 24 16:25:29 2021 daemon.info hostapd: wlan1: STA d8:9c:67:ac:c4:b3 WPA: pairwise key handshake completed (RSN)
Wed Mar 24 16:25:32 2021 daemon.info dnsmasq-dhcp[3330]: DHCPREQUEST(br-lan) 192.168.9.186 d8:9c:67:ac:c4:b3
Wed Mar 24 16:25:32 2021 daemon.info dnsmasq-dhcp[3330]: DHCPACK(br-lan) 192.168.9.186 d8:9c:67:ac:c4:b3 JDonnell
Wed Mar 24 16:35:31 2021 daemon.info hostapd: wlan1: STA d8:9c:67:ac:c4:b3 WPA: group key handshake completed (RSN)
Wed Mar 24 16:36:36 2021 user.notice wan-check:: WAN interface failed. Restarting it.....
Wed Mar 24 16:36:37 2021 daemon.notice netifd: wan (14027): Stopping network wan
Wed Mar 24 16:36:37 2021 daemon.notice netifd: wan_4 (3534): udhcpc: received SIGTERM
Wed Mar 24 16:36:37 2021 daemon.notice netifd: wan_4 (3534): udhcpc: unicasting a release of 100.70.78.141 to 100.70.78.142
Wed Mar 24 16:36:37 2021 daemon.notice netifd: wan_4 (3534): udhcpc: sending release
Wed Mar 24 16:36:37 2021 daemon.notice netifd: wan_4 (3534): udhcpc: entering released state
Wed Mar 24 16:36:37 2021 daemon.notice netifd: wan_4 (3534): Command failed: Permission denied
Wed Mar 24 16:36:38 2021 daemon.notice netifd: Interface 'wan_4' is now down
Wed Mar 24 16:36:38 2021 daemon.debug dnsmasq[3330]: stopped listening on wwan0(#3): 100.70.78.141 port 53
Wed Mar 24 16:36:38 2021 daemon.notice netifd: Network alias '' link is down
Wed Mar 24 16:36:38 2021 daemon.notice netifd: Interface 'wan_4' has link connectivity loss
Wed Mar 24 16:36:38 2021 daemon.notice netifd: Interface 'wan_4' is disabled
Wed Mar 24 16:36:38 2021 daemon.warn dnsmasq[3330]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Wed Mar 24 16:36:39 2021 daemon.notice netifd: wan (14027): sending -> AT^NDISDUP=1,0
29.03.20213710Base systemBug ReportVery LowLowatlantic.ko (Marvell/Aqtion/Aqantia AQC107/108) 10Gbit ...TrunkUnconfirmed Task Description

I have Several ASUS branded PCIe 10Gbit Cards based on the Aquantia Gen2 silicon, Some AQC107 based SFP+ modules and several ipq8074 boards with them. These work fine with the atlantic kernel driver which has been in mainline for some time.

Test build is x86_64 against the 21.02 tagged branch.

The 21.02 tagged branch (and the master, and 19.07) menuconfig for these cards do not appear despite the driver being present in the kernel source tree.

The lspci ID output of the card:

04:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] [1d6a:d107] (rev 02)
        Subsystem: ASUSTeK Computer Inc. XG-C100C [1043:8741]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at ed440000 (64-bit, non-prefetchable) [size=64K]
        Region 2: Memory at ed450000 (64-bit, non-prefetchable) [size=4K]
        Region 4: Memory at ed000000 (64-bit, non-prefetchable) [size=4M]
        Expansion ROM at ed400000 [disabled] [size=256K]
        Capabilities: [40] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 75.000W
                DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
                        MaxPayload 256 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L0s L1, Exit Latency L0s unlimited, L1 unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 8GT/s (ok), Width x4 (ok)
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis+ NROPrPrP- LTR-
                         10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
                         EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
                         FRS- TPHComp- ExtTPHComp-
                         AtomicOpsCap: 32bit- 64bit- 128bitCAS-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled,
                         AtomicOpsCtl: ReqEn-
                LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink+ Retimer- 2Retimers- DRS-
                LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ EqualizationPhase1+
                         EqualizationPhase2+ EqualizationPhase3+ LinkEqualizationRequest-
                         Retimer- 2Retimers- CrosslinkRes: unsupported
        Capabilities: [80] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [90] MSI-X: Enable+ Count=32 Masked-
                Vector table: BAR=2 offset=00000000
                PBA: BAR=2 offset=00000200
        Capabilities: [a0] MSI: Enable- Count=1/32 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [c0] Vital Product Data
                Product Name: AQtion
                Read-only fields:
                        [PN] Part number: AquantiaPartNumber
                        [EC] Engineering changes: AquantiaEngineeringChangeLevel
                        [FG] Unknown: 41 71 75 61 6e 74 69 61 46 61 62 72 69 63 47 65 6f 67 72 61 70 68 79
                        [LC] Unknown: 41 71 75 61 6e 74 69 61 4c 6f 63 61 74 69 6f 6e
                        [MN] Manufacture ID: AquantiaManufacturingId
                        [PG] Unknown: 41 71 75 61 6e 74 69 61 50 63 69 47 65 6f 67 72 61 70 68 79
                        [SN] Serial number: AquantiaSerialNumber
                        [V0] Vendor specific: AquantiaVendorSpecificReadOnlyItem0
                        [V1] Vendor specific: AquantiaVendorSpecificReadOnlyItem1
                        [RV] Reserved: checksum good, 0 byte(s) reserved
                Read/write fields:
                        [YA] Asset tag: AquantiaAssetTagIdentifier
                        [V0] Vendor specific: AquantiaVendorSpecificWritableItem0
                        [V1] Vendor specific: AquantiaVendorSpecificWritableItem1
                        [Y0] System specific: AquantiaSystemSpecificWritableItem0
                        [Y1] System specific: AquantiaSystemSpecificWritableItem1
                        [RW] Read-write area: 9 byte(s) free
                End
        Capabilities: [100 v2] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr+ BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
                HeaderLog: 00000000 00000000 00000000 00000000
        Capabilities: [150 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
        Capabilities: [180 v1] Secondary PCI Express
                LnkCtl3: LnkEquIntrruptEn- PerformEqu-
                LaneErrStat: 0
        Kernel driver in use: atlantic
        Kernel modules: atlantic


[aenertia@fedora build]$ lsmod |grep atlantic
atlantic              229376  0
macsec                 61440  1 atlantic

Within the make kernel_menuconfig selection it is shown as a Y default, tristate flag when the x86_64 target is selected but never appears to get built into the resultant image.

On my comparison systems running RHEL8.3 and Fedora Rawhide - the atlantic kernel module has a dependency on the macsec kernel module - this is mentioned the 5.4 kernel source in the openwrt build tree for 21.02 tag - but seems to be silently dropped/skipped.

I tried several manual .config edits in the kernel build tree to force inclusion of the atlantic and macsec modules without success in the resultant images.
I note that there is a main kmod-macsec config entry in the primary .config buildroot ; but enabling that results in an architecture invalid for target error during kernel compilation. Is there perhaps a double up of the macsec name inside the build tree?

tl;dr Summary of required actions:

*Expose the Atlantic module/option in the main menuconfig buildroot
*Confirm why the atlantic module is set to Y by default, but not resulting in a usable driver in the kernel
*Check that the macsec module which appears to be a dependency for the atlantic driver does not have a naming conflict and/or why selecting it in the main buildroot results in an invalid arch error for x86_64 build target.

Severity ; the atlantic module is increasingly commonly deployed both in server, enthusiast and OEM embedded appliances (ipq80xx is a common pairing) as well as NBaseT SFP+ modules (rebadged by several vendors i.e Mikrotik) to supply NBaseT 10Gbit functionality. It has not been working in the last 2 openwrt releases and should be fixed before 21.02 goes out the door.

 


29.03.20213711PackagesBuild FailureVery LowLowuqmi documentation errata? pdh on stop-networkTrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
- Software versions of OpenWrt/LEDE release, packages, etc.
- Steps to reproduce

 

So, i was trying to understand how-to disable –autoconnect because i made a mistake, using the wrong APN.

I was following this tutorial:

https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle

And there is no place where it explains how-to disable autoconnect... I tried to edit the wiki, to add some informations, and to remove that option.. and I couldn’t login using github as a service (error on the openwrt website!

Anyway.. trying to read the documentation of uqmi.. i get this text:

–stop-network <pdh>: Stop network connection (use with option below)

  1. -autoconnect: Disable automatic connect/reconnect

Which makes me wonder, what is pdh?
Well, pdh is not documented.. at least on the whole openwrt website:

https://openwrt.org/docs/guide-user/network/wan/wwan/ltedongle?q=pdh&do=search

i mean this is not a rant, is really, can all this be fixed, so we have better software? :D

thank you guyz, awesome stuff!

30.03.20213712Base systemBug ReportVery LowLowLinksys E8450 mt7915e failureTrunkUnconfirmed Task Description

Supply the following if possible:
- Linksys E8450 / Belking AX3200
- Latest snapshot as of 29.03.2021
- Flash firmware, boot

Looking at `readlog` I see the following:

```
Sun Mar 28 10:16:29 2021 kern.debug kernel: [ 8.144261] ieee80211 phy0: Selected rate control algorithm ‘minstrel_ht’ Sun Mar 28 10:16:29 2021 kern.debug kernel: [ 8.155943] mt7915e 0000:01:00.0: assign IRQ: got 144
Sun Mar 28 10:16:29 2021 kern.debug kernel: [ 8.161082] pci 0000:00:00.0: enabling bus mastering
Sun Mar 28 10:16:29 2021 kern.info kernel: [ 8.166067] mt7915e 0000:01:00.0: enabling device (0000 → 0002)
Sun Mar 28 10:16:29 2021 kern.debug kernel: [ 8.172151] mt7915e 0000:01:00.0: enabling bus mastering
Sun Mar 28 10:16:29 2021 kern.info kernel: [ 8.209817] mt7622-wmac 18000000.wmac: HW/SW Version: 0x8a108a10, Build Time: 20190801210006a
Sun Mar 28 10:16:29 2021 kern.info kernel: [ 8.209817]
Sun Mar 28 10:16:29 2021 kern.info kernel: [ 8.286383] mt7622-wmac 18000000.wmac: N9 Firmware Version: 2.0, Build Time: 20200131180931
Sun Mar 28 10:16:29 2021 kern.err kernel: [ 12.176986] mt7915e 0000:01:00.0: Firmware is not ready for download
Sun Mar 28 10:16:29 2021 kern.warn kernel: [ 12.183510] mt7915e: probe of 0000:01:00.0 failed with error -5
```

 


02.04.20213719DocumentationBug ReportVery LowLowOpenwrt image builder instructions for FILES_REMOVE par...openwrt-19.07Unconfirmed Task Description

I’m attempting to use the x86 image builder for 19.07.7
https://downloads.openwrt.org/releases/19.07.7/targets/x86/64/openwrt-imagebuilder-19.07.7-x86-64.Linux-x86_64.tar.xz

There are some instructions in the documentation at:
https://openwrt.org/docs/guide-user/additional-software/imagebuilder

They say to patch the makefile:

 ifneq ($(USER_FILES),)
 	$(MAKE) copy_files
 endif
+
+ifneq ($(FILES_REMOVE),)
+	@echo
+	@echo Remove useless files
+
+	while read filename; do				\
+	    rm -rfv "$(TARGET_DIR)$$filename";	\
+	done < $(FILES_REMOVE);
+endif
+
 	$(MAKE) package_postinst
 	$(MAKE) build_image

But the Makefile layout seems to have changed since the instructions were written so it isn’t clear where to add this.

This is a really handy feature, so I hope the developers will eventually include this to avoid the need to patch the makefile.


04.04.20213722KernelBug ReportVery LowLowSoftware flow offloading breaks ECMP routingopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

 x86_64 Router

- Software versions of OpenWrt/LEDE release, packages, etc.

 OpenWrt 19.07.7 r11306-c4a6851c72, Linux 4.14.221 #0 SMP Mon Feb 15 15:22:37 2021 x86_64 GNU/Linux

- Steps to reproduce

Hey guys,

I met this issue when I was using ECMP (Equal Cost Multi-Path) routing with software flow offload enabled.

Suppose we have topology:

LAN 1 (192.168.1.0/24) ←—> (eth1: 192.168.1.1/24) OpenWRT (eth2: 192.168.2.1/24) ←—> (192.168.2.51-53/24) Other routers ←—> (192.168.150.0/24) LAN 2

1. Add ECMP routes:

$ ip route add 192.168.150.0/24 nexthop via 192.168.2.51 dev eth2 \
                                nexthop via 192.168.2.52 dev eth2 \
                                nexthop via 192.168.2.53 dev eth2

$ ip route
192.168.150.0/24 
	nexthop via 192.168.2.51 dev eth2 weight 1 
	nexthop via 192.168.2.52 dev eth2 weight 1 
	nexthop via 192.168.2.53 dev eth2 weight 1 

2. Setting multipatch hash policy:

sysctl net.ipv4.fib_multipath_hash_policy=1

3. Initiate TCP connections from LAN 1 (192.168.1.0/24) to LAN 2 (192.168.150.0/24) should succeed. Connections are balanced over 3 next hop routers (192.168.2.51-53).
4. Enable software flow offloading on LuCI.
5. Open a TCP connection from LAN 1 (192.168.1.0/24) to LAN 2 (192.168.150.0/24) will likely be broken because each packet for a single TCP connection could use a different next hop router to get to the destination.

I’m not sure if this is an OpenWRT issue or upstream kernel issue. Any help would be greatly appreciated.

06.04.20213728Base systemBug ReportVery LowLowIPv6 Connectivity Lost When ISP Router is Restartedopenwrt-19.07Unconfirmed Task Description

I am running OpenWrt 19.07.7 on a TpLink Archer C7 (v5). The OpenWrt router is connected to a Router that is provided by my ISP. The ISP router connects to the Internet using DS-Lite.

    ------------     -----------     ----------     ------------
    | Local    |     | OpenWrt |     |  ISP   |     | Internet |
    | Network  |-----| Router  |-----| Router |-----|          |
    ------------     -----------     ----------     ------------

The OpenWrt router receives a delegated prefix using DHCPv6, which provides global addresses to the network connected to the OpenWrt router. This works perfectly fine, until the ISP router is restarted, which sometimes happens when it upgrades its firmware. In this situation, the IPv6 connectivity is lost and is not automatically restored. To get IPv6 connectivity, I have to restart the WAN6 interface, which estabilshes the IPv6 connection again. The IPv4 connectivity is restored automatically.

After the IPS router has been restarted, the OpenWrt router cannot ping IPv6 hosts via global addresses. Even the global address of the ISP router cannot be reached via ping. Pings via link-local addresses work fine.

When the IPv6 connection is gone, restarting the WAN6 interface, seems to change nothing on the side of the OpenWrt router. The output before and after the restart of ip -6 addr, ip -6 route, and ip6tables -L are identical (except for the IP address life-times). Also the information displayed by LuCI on the Interface page stays the same. However, the connectivity is restored after the interface is restarted.

My guess for explaining this behavior is as follows. When the ISP router is restarted, it receives the same IPv6 address lease and prefix from my ISP as earlier. (The IPv6 address lease is valid for a few days.) The ISP router, however, has “forgotten” that it had delegated a prefix to the OpenWrt router. Hence, the ISP router is not routing any traffic to the prefix the OpenWrt router is using. Since the IPv6 address of the ISP router does not change, the OpenWrt router does not detect this change. The RAs that the OpenWrt router receives are the same as before. When I restart the WAN6 interface, however, it asks for a new IPv6 address and a new IPv6 prefix, which in turn leads to the ISP router creating the proper route for the delegated prefix, which restores the IPv6 connectivity.

Unfortunately, I do not have access to the routing table of the ISP router, and hence, I cannot verify my hypothesis. (The reason for using OpenWrt is, that the ISP router is severely limited. I have to use the ISP router, however.)

Is there a way to force odhcp6c to probe whether the current delegated prefix is valid? Maybe sending some sort of renew/refresh message via DHCPv6? Is there a way to ask odhcp6c to regularly update/renew the delegated prefix, say every 5 minutes?

I currently have a cron job, which pings an IPv6 host on the internet and restarts the WAN6 interface when the ping fails. This workaround does the trick, but is rather ugly.

08.04.20213730Base systemBug ReportVery LowLowresolve_conffiles reports spurious errorsopenwrt-19.07Unconfirmed Task Description
When I run upgrades

<code>
root@router:~# opkg update && opkg list-upgradable | awk '{print $1}' | xargs opkg upgrade

I usually end up with some messages like

Collected errors:
 * resolve_conffiles: Existing conffile /etc/config/luci_statistics is different from the conffile in the new package. The new conffile will be placed at /etc/config/luci_statistics-opkg.
 * resolve_conffiles: Existing conffile /etc/config/luci is different from the conffile in the new package. The new conffile will be placed at /etc/config/luci-opkg.
 * resolve_conffiles: Existing conffile /etc/config/ucitrack is different from the conffile in the new package. The new conffile will be placed at /etc/config/ucitrack-opkg.

Sometimes the conflicts are genuine – because I’ve configured the router – but most of them are because uci doesn’t force a canonical output format. For example

root@router:~# diff -u /etc/config/luci-opkg /etc/config/luci
--- /etc/config/luci-opkg	2021-03-27 02:44:43.000000000 -0400
+++ /etc/config/luci	2021-01-30 05:15:01.000000000 -0500
@@ -1,31 +1,39 @@
-config core main
-	option lang auto
-	option mediaurlbase /luci-static/bootstrap
-	option resourcebase /luci-static/resources
-	option ubuspath /ubus/
-	
-config extern flash_keep
-	option uci 		"/etc/config/"
-	option dropbear "/etc/dropbear/"
-	option openvpn	"/etc/openvpn/"
-	option passwd	"/etc/passwd"
-	option opkg		"/etc/opkg.conf"
-	option firewall	"/etc/firewall.user"
-	option uploads	"/lib/uci/upload/"
-	
-config internal languages
-	
-config internal sauth
-	option sessionpath "/tmp/luci-sessions"
-	option sessiontime 3600
-	
-config internal ccache
-	option enable 1
-		
-config internal themes
-
-config internal apply
-	option rollback 90
-	option holdoff 4
-	option timeout 5
-	option display 1.5
+
+config core 'main'
+	option lang 'auto'
+	option mediaurlbase '/luci-static/bootstrap'
+	option resourcebase '/luci-static/resources'
+	option ubuspath '/ubus/'
+
+config extern 'flash_keep'
+	option uci '/etc/config/'
+	option dropbear '/etc/dropbear/'
+	option openvpn '/etc/openvpn/'
+	option passwd '/etc/passwd'
+	option opkg '/etc/opkg.conf'
+	option firewall '/etc/firewall.user'
+	option uploads '/lib/uci/upload/'
+
+config internal 'languages'
+
+config internal 'sauth'
+	option sessionpath '/tmp/luci-sessions'
+	option sessiontime '3600'
+
+config internal 'ccache'
+	option enable '1'
+
+config internal 'themes'
+	option Bootstrap '/luci-static/bootstrap'
+
+config internal 'apply'
+	option rollback '90'
+	option holdoff '4'
+	option timeout '5'
+	option display '1.5'
+
+config internal 'diag'
+	option dns 'openwrt.org'
+	option ping 'openwrt.org'
+	option route 'openwrt.org'
+

Except for `luci.diag` and `luci.themes.Bootstrap`, these are identical config files, and I don’t think even configured luci.diag so that’s probably just from a previous change.

It can be hard to separate out what I’ve configured from what the packagers have changed, but it is much more tedious when I also need to separate out what’s spurious changes from the quotes and indentation changing.

It would save users a lot of time if either:

* `resolve_conffiles` called `uci` to check differences instead of comparing entire files, *or*
* `uci` had a canonical format that both it and `luci` agreed to stick to, strictly so that running `diff` (or whatever `resolve_conffiles` does) would only report genuine conflicts

Don’t get me wrong, I do like openwrt a lot. It’s way better than using an unfixable vendor firmware. The fact that I can upgrade packages on it at all is marvelous. Thank you for your work.


Model: TP-Link Archer C50 v4 https://openwrt.org/toh/tp-link/archer-c50

Build: OpenWrt 19.07.7 r11306-c4a6851c72 / LuCI openwrt-19.07 branch git-21.096.73306-254083c

Kernel: 4.14.221

Packages:

root@router:~# opkg list-installed
base-files - 204.2-r11306-c4a6851c72
busybox - 1.30.1-6
cgi-io - 19
collectd - 5.12.0-1
collectd-mod-conntrack - 5.12.0-1
collectd-mod-cpu - 5.12.0-1
collectd-mod-interface - 5.12.0-1
collectd-mod-iwinfo - 5.12.0-1
collectd-mod-load - 5.12.0-1
collectd-mod-memory - 5.12.0-1
collectd-mod-network - 5.12.0-1
collectd-mod-ping - 5.12.0-1
collectd-mod-rrdtool - 5.12.0-1
collectd-mod-uptime - 5.12.0-1
collectd-mod-wireless - 5.12.0-1
conntrack - 2018-05-01-88610abe-1
diffutils - 3.7-2
dnsmasq - 2.80-16.3
dropbear - 2019.78-2
firewall - 2019-11-22-8174814a-3
fstools - 2020-05-12-84269037-1
fwtool - 2
getrandom - 2019-06-16-4df34a4d-3
hostapd-common - 2019-08-08-ca8c2bd2-7
ip6tables - 1.8.3-1
iptables - 1.8.3-1
iptables-mod-conntrack-extra - 1.8.3-1
iptables-mod-ipopt - 1.8.3-1
iw - 5.0.1-1
iwinfo - 2019-10-16-07315b6f-1
jshn - 2020-05-25-66195aee-1
jsonfilter - 2018-02-04-c7e938d6-1
kernel - 4.14.221-1-d92769dc5268e102503ae83fe968a56c
kmod-cfg80211 - 4.14.221+4.19.161-1-1
kmod-gpio-button-hotplug - 4.14.221-3
kmod-ifb - 4.14.221-1
kmod-ip6tables - 4.14.221-1
kmod-ipt-conntrack - 4.14.221-1
kmod-ipt-conntrack-extra - 4.14.221-1
kmod-ipt-core - 4.14.221-1
kmod-ipt-ipopt - 4.14.221-1
kmod-ipt-nat - 4.14.221-1
kmod-ipt-offload - 4.14.221-1
kmod-ipt-raw - 4.14.221-1
kmod-leds-gpio - 4.14.221-1
kmod-lib-crc-ccitt - 4.14.221-1
kmod-mac80211 - 4.14.221+4.19.161-1-1
kmod-mt76-core - 4.14.221+2021-02-15-5c768dec-1
kmod-mt7603 - 4.14.221+2021-02-15-5c768dec-1
kmod-mt76x02-common - 4.14.221+2021-02-15-5c768dec-1
kmod-mt76x2 - 4.14.221+2021-02-15-5c768dec-1
kmod-mt76x2-common - 4.14.221+2021-02-15-5c768dec-1
kmod-nf-conntrack - 4.14.221-1
kmod-nf-conntrack-netlink - 4.14.221-1
kmod-nf-conntrack6 - 4.14.221-1
kmod-nf-flow - 4.14.221-1
kmod-nf-ipt - 4.14.221-1
kmod-nf-ipt6 - 4.14.221-1
kmod-nf-nat - 4.14.221-1
kmod-nf-reject - 4.14.221-1
kmod-nf-reject6 - 4.14.221-1
kmod-nfnetlink - 4.14.221-1
kmod-ppp - 4.14.221-1
kmod-pppoe - 4.14.221-1
kmod-pppox - 4.14.221-1
kmod-sched-cake - 4.14.221+2019-03-12-057c7388-1
kmod-sched-core - 4.14.221-1
kmod-slhc - 4.14.221-1
libblobmsg-json - 2020-05-25-66195aee-1
libc - 1.1.24-2
libcap - 2.27-1
libelf1 - 0.177-1
libgcc1 - 7.5.0-2
libip4tc2 - 1.8.3-1
libip6tc2 - 1.8.3-1
libiwinfo-lua - 2019-10-16-07315b6f-1
libiwinfo20181126 - 2019-10-16-07315b6f-1
libjson-c2 - 0.12.1-3.1
libjson-script - 2020-05-25-66195aee-1
libltdl7 - 2.4.6-2
liblua5.1.5 - 5.1.5-3
liblucihttp-lua - 2019-07-05-a34a17d5-1
liblucihttp0 - 2019-07-05-a34a17d5-1
libmbedtls12 - 2.16.10-1
libmnl0 - 1.0.4-2
libnetfilter-conntrack3 - 2018-05-01-3ccae9f5-2
libnetfilter-cthelper0 - 1.0.0-2
libnetfilter-cttimeout1 - 1.0.0-2
libnetfilter-queue1 - 2017-06-27-601abd1c-2
libnfnetlink0 - 1.0.1-3
libnl-tiny - 0.1-5
liboping - 1.10.0-2
libpthread - 1.1.24-2
librrd1 - 1.0.50-3
libubox20191228 - 2020-05-25-66195aee-1
libubus-lua - 2019-12-27-041c9d1c-1
libubus20191227 - 2019-12-27-041c9d1c-1
libuci20130104 - 2019-09-01-415f9e48-4
libuclient20160123 - 2020-06-17-51e16ebf-1
libustream-mbedtls20150806 - 2020-03-13-40b563b1-1
libxtables12 - 1.8.3-1
logd - 2019-06-16-4df34a4d-3
lua - 5.1.5-3
luci - git-21.096.73306-254083c-1
luci-app-firewall - git-21.096.73306-254083c-1
luci-app-openvpn - git-21.096.73306-254083c-1
luci-app-opkg - git-21.096.73306-254083c-1
luci-app-simple-adblock - git-21.050.37945-c33df8f-1
luci-app-sqm - 1.4.0-2
luci-app-statistics - git-21.096.73306-254083c-1
luci-base - git-21.096.73306-254083c-1
luci-compat - git-21.096.73306-254083c-1
luci-lib-ip - git-21.096.73306-254083c-1
luci-lib-iptparser - git-21.096.73306-254083c-1
luci-lib-jsonc - git-21.096.73306-254083c-1
luci-lib-nixio - git-21.096.73306-254083c-1
luci-mod-admin-full - git-21.096.73306-254083c-1
luci-mod-network - git-21.096.73306-254083c-1
luci-mod-status - git-21.096.73306-254083c-1
luci-mod-system - git-21.096.73306-254083c-1
luci-proto-ipv6 - git-21.096.73306-254083c-1
luci-proto-ppp - git-21.096.73306-254083c-1
luci-theme-bootstrap - git-21.096.73306-254083c-1
mtd - 24
netifd - 2021-01-09-753c351b-1
odhcp6c - 2021-01-09-64e1b4e7-16
odhcpd-ipv6only - 2020-05-03-49e4949c-3
openwrt-keyring - 2019-07-25-8080ef34-1
opkg - 2021-01-31-c5dccea9-1
ppp - 2.4.7.git-2019-05-25-3
ppp-mod-pppoe - 2.4.7.git-2019-05-25-3
procd - 2020-03-07-09b9bd82-1
rpcd - 2020-05-26-67c8a3fd-1
rpcd-mod-file - 2020-05-26-67c8a3fd-1
rpcd-mod-iwinfo - 2020-05-26-67c8a3fd-1
rpcd-mod-luci - 20201107
rpcd-mod-rrdns - 20170710
rrdtool1 - 1.0.50-3
simple-adblock - 1.8.4-10
sqm-scripts - 1.4.0-2
swconfig - 12
tc - 5.0.0-2.1
ubox - 2019-06-16-4df34a4d-3
ubus - 2019-12-27-041c9d1c-1
ubusd - 2019-12-27-041c9d1c-1
uci - 2019-09-01-415f9e48-4
uclient-fetch - 2020-06-17-51e16ebf-1
uhttpd - 2020-10-01-3abcc891-1
urandom-seed - 1.0-1
urngd - 2020-01-21-c7f7b6b6-1
usign - 2020-05-23-f1f65026-1
wireless-regdb - 2020.11.20-1
wpad-basic - 2019-08-08-ca8c2bd2-7
zlib - 1.2.11-3
09.04.20213732Base systemBug ReportVery LowLowhostapd: VLAN-assignment via sae_password sometimes fai...TrunkUnconfirmed Task Description

Device: Ubiquiti UniFi AC LR (OpenWrt SNAPSHOT r16382-209c5918b5)

For some time I successfully run a per-device WPA2-PSK setup using the following options:

	option network 'dummy'
	option dynamic_vlan '2'
	option vlan_file '/root/ogb-hostapd-vlans-phy0'
	option wpa_psk_file '/root/ogb-hostapd-psks'
	option key 'invalid-fallback-psk-used-by-no-device-at-all'

This setup forces all devices to use a MAC-PSK combination from the wpa_psk_file, where they are reassigned to a working VLAN that is mapped to a specific bridge via the vlan_file. Meaning: If a device were to use the PSK from the key-option they would be bridged into br-dummy, a bridge that uses a VLAN not present on the upstream switchport.

To reiterate: This works absolutely perfectly and rock stable - until I switch a device over to WPA3. I comment out the MAC from the wpa_psk_file and add it via the sae_password option:

	list hostapd_bss_options 'sae_password=device-psk|mac=xx:xx:xx:xx:xx:xx|vlanid=8'

This works for some of the time only. Sometimes the device is assigned to the br-dummy bridge as if hostapd correctly uses the per-device-PSK, but ignores the vlanid-option. Usually a reconnect or two solves the problem. Using tcpdump I can clearly see the clients DHCP-requests in the br-dummy bridge when the issue occurs.

In the past I already tried to troubleshoot this issue by using the newest upstream hostapd but failed due to all the custom openwrt patches. I am really not a developer, but only a network engineer. Can someone please help me troubleshoot this? I would like to retry this with the newest hostapd before investing any time into troubleshooting something that might be already solved upstream (there were a couple of sae-patches).

12.04.20213737Base systemBug ReportVery LowLowNew Warning with latest masterTrunkUnconfirmed Task Description

Supply the following if possible:
- ubuntu 20.04
- clone the latest master repository, and run quick image build procedure

Warnings indicating that ‘Makefile ‘package/boot/uboot-sunxi/Makefile’ has a dependency on ‘arm-trusted-firmware-sunxt’

This is a new warning. This occurs during the ./scripts/feeds install -a step and make menuconfig step.

Was not doing it a few days ago prior to update of master repository.

DL’d new master, now experiencing these warnings.

Thanks,


13.04.20213738Base systemBug ReportVery LowLowFritz 1200 no network on luci-21.02-snapshot-r15866-17a...openwrt-21.02Unconfirmed Task Description

- Device: AVM FRITZ!Repeater 1200

- Software versions: luci-21.02-snapshot-r15866-17a627ec82-ipq40xx-generic-avm_fritzrepeater-1200-squashfs-sysupgrade

- Steps to reproduce: there is no LAN connection after upload this firmware to Fritz 1200, after back to luci-19.07-snapshot-r11328-81266d9001-ipq40xx-generic-avm_fritzrepeater-1200-squashfs-sysupgrade, everything works: Lan connection return.

 


13.04.20213739Base systemBug ReportVery LowLowOpkg return err when removing a package required multip...TrunkUnconfirmed Task Description

This is still an issue (from barrier breaker era).

https://dev.archive.openwrt.org/ticket/18320

It is breaking packages CI
https://github.com/openwrt/packages/pull/15412

15.04.20213741ToolchainBug ReportVery LowLowBus error on musl tzset TrunkUnconfirmed Task Description

toolchain/musl/patches/110-read_timezone_from_fs.patch - Adds support for reading timezone from /etc/TZ.
It does mmap of the file. There is a possible race condition here. If /etc/TZ is truncated between mmap and read, read can cause bus error (SIGBUS).

19.04.20213745Base systemBug ReportVery LowLowWireless 'isolate' option not working in brcmfmac drive...openwrt-21.02Unconfirmed Task Description

Device: BCM4356 WiFi chip + brcmfmac
OpenWRT Version: 21.02 (commit 50f2f25d58 [4 days ago])

I experienced the problem using OpenWrt 21.02 on a device using the brcmfmac driver for the BCM4356 chip.

I’ve only been able to test this on an InvizBox 2 (not supported by OpenWRT) but I suspect it to also be a problem for other devices using brcmfmac.

Steps to reproduce:

On a device running OpenWRT 21.02 and with a WiFi chip using the brcmfmac driver:

Set wireless.<wifi-iface>.isolate=’1’ on the WiFi interface that uses the brcmfmac driver.

Devices connected to the WiFi interface should be isolated from each other, but are not.

Notes / Potential fixes:

I was able to fix this issue by building with a specific patch for brcmfmac from the latest Cypress Linux WiFi Driver Release (FMAC)(https://community.cypress.com/t5/Wi-Fi-Bluetooth-for-Linux/Cypress-Linux-WiFi-Driver-Release-FMAC-2021-01-14/m-p/268899). The particular patch that fixed the issue can be found in the .zip file linked in the latest Cypress driver release. cypress-fmac-v5.4.18-2021_0114.zip > cypress-patch-v5.4.18-2021_0114.tar.gz > cypress-patch > 0004-brcmfmac-support-AP-isolation.patch.

The patch has not been accepted into linux-wireless yet. But there are details about it here: https://patchwork.kernel.org/project/linux-wireless/patch/20200901063237.15549-2-wright.feng@cypress.com/.

Let me know if you need any more information or there’s anything I can do to help sort this out. Thanks.

20.04.20213746Base systemBug ReportVery LowLowx86_64 EFI image fails to boot when USB device is plugg...openwrt-21.02Unconfirmed Task Description

Snapshot OR 21.02.0-rc1-x86_64 will not boot EFI

System: AsRock J5005-ITX (EFI only boot), 4GB ram, Intel Dual 1000PT server adapter

 

Steps used to typically install snapshot:

Boot SystemRescueCD to prompt
issue dd if=openwrt-xxx of=/dev/sda
partitions are copied over, reboot
Error on Snapshot: “error: disk ‘hd0,gpt1’ not found

on RC1 file copies over as above but it does not boot in any fashion just returns to the bios screen.

It’s been a long time since I tested the EFI snapshots, but at one point they worked fine. Given that the EFI support was added to master, I decided to wait on 2021.02 for full implementation.

The original pull on github was https://github.com/openwrt/openwrt/pull/1968, but it has since been closed, and I saw there was some work on the EFI stack for dual booting. That image may in fact boot on a non-EFI system, but I do not have any way to test.

At this point I would say both snapshot and RC1 are broken for x86_64 EFI systems.

22.04.20213749Base systemBug ReportVery LowLowbusybox-ntp failing on specific ISP but ntpd works.openwrt-21.02Unconfirmed Task Description

- Device: glinet B1300 router
- Running 21.02

Attached are two pcap files you can open in wireshark.

This issue seems to only affect one Danish ISP, however I think it is worth reporting to see if it can be fixed.
The built in busybox-ntpd does not work (see packet in sysntpd.pcap)

However, if I install ntpdate instead then ntp is able to update (using the same ntp server).
You can see difference in the packets by comparing the two pcap files.

My best bet is that the ISP is blocking specific data in NTPv4 Packets that busybox-ntp is sending.

25.04.20213752Base systemBug ReportVery LowLownetifd defaults an invalid bridge STP value for forward...TrunkUnconfirmed Task Description

netifd defaults the STP forward_delay lower than the minimum allowed by the protocol, causing the BPDU packets to be ignored by conforming implementations, risking bridge loops.

The relevant limits are set in IEEE 802.1D-1998 section 8.10.2 Table 8-3: the allowable forward_delay range is 4 - 30 seconds. netifd sets the initial default to 2 seconds.

I tested this with several of my Netgear managed switches; they ignore the invalid “2 second” STP packets. Correcting the forward_delay to within limits (4s) results in the router accepting the OpenWRT STP as the root bridge (since it has a lower bridge-id).

netifd should definitely not be defaulting to invalid values (even if it, and the kernel, allow the values to be set).

Here’s a patch to fix the default:

--- a/bridge.c                                                                  
+++ b/bridge.c                                                                  
@@ -875,7 +875,7 @@ bridge_apply_settings(struct bridge_state *bst, struct blob\
_attr **tb)                                                                     
                                                                                
        /* defaults */                                                          
        cfg->stp = false;                                                       
-       cfg->forward_delay = 2;                                                 
+       cfg->forward_delay = 4;                                                 
        cfg->robustness = 2;                                                    
        cfg->igmp_snoop = false;                                                

Specifically, the packet is invalid as it fails the Spanning Tree Algorithm in section A.9, step 17c.

NOTE: Since the 1998 version of the standard requires subscribing to IEEE, you can also find the limits in the “free to download” updated 802.1D-2004 standard, section 17.14, Table 17-1 for the RSTP (which has the same forward delay limits as STP).


On the subject of “additional possible fixes”.... (only suggestions)

The very low Forward Delay of 4 seconds still results in “non-conforming” behavior by OpenWRT, but at least no longer “breaking” behavior. Section 8.10.2 of 802.1D-1998 states:

A Bridge shall enforce the following relationships:
   2 × (Bridge_Forward_Delay – 1.0 seconds) >= Bridge_Max_Age

... so even if the default Forward Delay is increased to 4 seconds, the default Max Age should also also be reduced to 6 seconds (kernel currently defaults to 20 seconds).

Also the minimum value for Forward Delay of 4 seconds is calculated (in section B.4.5) based on a Hello Time of 1 second, so that value should also be set (kernel currently defaults to 2 seconds).

Neither of these updates are critical (they work at their current defaults), but would just create “sensible” timers for STP.


29.04.20213763Base systemBug ReportVery LowLowOpenwrt 19.07 Wifi MT76x2E unstableTrunkUnconfirmed Task Description

Device : Newifi D2 with MT7621,MT7603E (2.4 ghz wifi) and MT76x2E.
Version installed : Openwrt 19.07.07

On System log :
Thu Apr 29 05:58:09 2021 kern.info kernel: [27563.371343] ieee80211 phy1: Hardware restart was requested
Thu Apr 29 06:04:09 2021 kern.info kernel: [27923.427600] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
Thu Apr 29 06:04:09 2021 kern.info kernel: [27923.433086] mt76x2e 0000:01:00.0: Build: 1
Thu Apr 29 06:04:09 2021 kern.info kernel: [27923.437240] mt76x2e 0000:01:00.0: Build Time: 201507311614 Thu Apr 29 06:04:09 2021 kern.info kernel: [27923.465964] mt76x2e 0000:01:00.0: Firmware running!

Test Ping :
ping google.it
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=190 ttl=116 time=31.7 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=191 ttl=116 time=31.4 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=192 ttl=116 time=31.6 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=193 ttl=116 time=31.6 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=194 ttl=116 time=31.7 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=195 ttl=116 time=31.9 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=196 ttl=116 time=31.7 ms
From n-batnic (192.168.1.131) icmp_seq=198 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=199 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=200 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=201 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=202 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=203 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=204 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=205 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=206 Destination Host Unreachable
64 bytes from mad01s26-in-f3.1e100.net (216.58.214.163): icmp_seq=207 ttl=116 time=31.8 ms
64 bytes from mad01s26-in-f163.1e100.net (216.58.214.163): icmp_seq=208 ttl=116 time=32.2 ms
64 bytes from mad01s26-in-f163.1e100.net (216.58.214.163): icmp_seq=209 ttl=116 time=31.7 ms
64 bytes from mad01s26-in-f163.1e100.net (216.58.214.163): icmp_seq=210 ttl=116 time=32.3 ms

Wifi 5ghz settings :
config wifi-device ‘radio1’ option type ‘mac80211’ option hwmode ‘11a’ option path ‘pci0000:00/0000:00:00.0/0000:01:00.0’ option htmode ‘VHT80’ option country ‘IT’ option channel ‘100’

With wifi 2.4ghz i don’t have problem.

Could you help me for to fix the problem?

Regards

29.04.20213767Base systemBug ReportVery LowLowAP/master + STA/client don't work in almost all casesopenwrt-19.07Unconfirmed Task Description

I have GL-Inet GL-AR150 (Atheros 933x, single radio) configured with three WiFi interfaces/networks: two APs (main+guest) and one client (WWAN). I would like to use them as a wireless repeater, but in most cases is able to use as pure AP or pure client only.

If client interface is disabled, both APs work perfectly. If the client is enabled, it successfully connects to the specified external AP and routing between LAN and WWAN works perfectly, but none of the APs are visible/accessible in most cases.

There was only a single case of dozens experiments when I saw all three interfaces working. In that case, both APs were visible and accessible, the client was connected to the external AP, and packet routing was established between LAN (RJ-45 and APs) and WWAN (the client). It means that this SoC is technically capable of running mixed mode interfaces on a single radio. Unfortunately, in that case I didn't think to save the logs.

In most cases, when AP networks are not exposed, system log contains repeated error messages from hostapd:

daemon.err hostapd: Failed to set beacon parameters
daemon.notice hostapd: handle_probe_req: send failed

I'm afraid that client initialization is performed first, and some beacon parameters are set for the radio driver. When hostapd tries to set its own parameters, the driver fails the request. But in the case where all three interfaces worked, initialization sequence most probably was slightly different, so there was no conflict. Unfortunately, I cannot reproduce that successful case, but at that time, I carefully checked all the functionality to ensure that it really worked as expected.

I tried to change AP channel from Auto to a particular number, as suggested in FS#3114, but this didn't help.


The problem occurs in many stable OpenWRT releases. The latest are 19.07.3 and 19.07.7 (both are generic).


Steps to reproduce:

 
* Create at least two wireless interfaces: one client/STA, one or more master/AP.
* When client/STA is enabled, AP(s) is(are) not exposed.
29.04.20213768Base systemBug ReportVery LowLowAP/master + STA/client doesn't work in almost all casesopenwrt-19.07Unconfirmed Task Description

I have GL-Inet GL-AR150 (Atheros 933x, single radio) configured with three WiFi interfaces/networks: two APs (main+guest) and one client (WWAN). I would like to use them as a wireless repeater, but in most cases is able to use as pure AP or pure client only.

If client interface is disabled, both APs work perfectly. If the client is enabled, it successfully connects to the specified external AP and routing between LAN and WWAN works perfectly, but none of the APs are visible/accessible in most cases.

There was only a single case of dozens experiments when I saw all three interfaces working. In that case, both APs were visible and accessible, the client was connected to the external AP, and packet routing was established between LAN (RJ-45 and APs) and WWAN (the client). It means that this SoC is technically capable of running mixed mode interfaces on a single radio. Unfortunately, in that case I didn’t think to save the logs.

In most cases, when AP networks are not exposed, system log contains repeated error messages from hostapd:

daemon.err hostapd: Failed to set beacon parameters
daemon.notice hostapd: handle_probe_req: send failed

I’m afraid that client initialization is performed first, and some beacon parameters are set for the radio driver. When hostapd tries to set its own parameters, the driver fails the request. But in the case where all three interfaces worked, initialization sequence most probably was slightly different, so there was no conflict. Unfortunately, I cannot reproduce that successful case, but at that time, I carefully checked all the functionality to ensure that it really worked as expected.

I tried to change AP channel from Auto to a particular number, as suggested in FS#3114, but this didn’t help.


The problem occurs in many stable OpenWRT releases. The latest are 19.07.3 and 19.07.7 (both are generic).


Steps to reproduce:

 
* Create at least two wireless interfaces: one client/STA, one or more master/AP.
* When client/STA is enabled, AP(s) is(are) not exposed.
01.05.20213771Base systemBug ReportVery LowLowodhcpd fails to send Router AdvertisementsTrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
Linksys EA3500

- Software versions of OpenWrt/LEDE release, packages, etc.
21.02.0rc1

- Steps to reproduce
1. Install 21.02.0rc1 on device
2. After successful install, note that your ethernet connected laptop has only a link-local address (no ULA, or GUA).
3. Log into router and run logread command looking for odhcpd errors. Note the following:

logread | grep odhcp
Sun Apr 18 03:07:34 2021 user.notice ucitrack: Setting up /etc/config/dhcp reload dependency on /etc/config/odhcpd
Sun Apr 18 03:07:38 2021 daemon.err odhcpd[1799]: Failed to send to ff02::1%lan@br-lan (Address not available)
Sun Apr 18 03:07:41 2021 daemon.err odhcpd[1799]: Failed to send to fe80::9ed6:43ff:feae:1915%lan@br-lan (Address not available)
Sun Apr 18 03:07:41 2021 daemon.err odhcp6c[2528]: Failed to send RS (Address not available)
Sun Apr 18 03:07:42 2021 daemon.err odhcpd[1799]: Failed to send to ff02::1%lan@br-lan (Address not available)
Sun Apr 18 03:07:42 2021 daemon.err odhcp6c[2528]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Sun Apr 18 03:07:48 2021 daemon.info dnsmasq[2569]: read /tmp/hosts/odhcpd - 0 addresses

The router does NOT, in fact, have the interface ff02::1%lan@br-lan

After installing ip-full, it is possible to see ‘ip maddr’ and see the correct interfaces on the router:

# ip maddr
1: lo

inet  224.0.0.1
inet6 ff02::1
inet6 ff01::1

...
13: br-lan

link  33:33:00:00:00:01
link  33:33:00:00:00:02
link  01:00:5e:00:00:01
link  33:33:ff:01:70:f1
link  33:33:ff:00:00:01
link  33:33:ff:00:00:00
link  33:33:00:00:00:09
inet  224.0.0.1
inet6 ff02::9
inet6 ff02::1:ff00:0 users 3
inet6 ff02::1:ff00:1 users 2
inet6 ff02::1:ff01:70f1
inet6 ff02::2
inet6 ff02::1
inet6 ff01::1

IMPACT: No attached device can receive an IPv6 address from the router

 


03.05.20213779Base systemBug ReportVery LowLowPossible less space on Netgear D7800 on 21.02TrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
- Software versions of OpenWrt/LEDE release, packages, etc.
- Steps to reproduce

 

Netgear D7800

/dev/root 3.8M 3.8M 0 100% /rom
tmpfs 106.6M 1.1M 105.4M 1% /tmp
/dev/ubi0_1 17.2M 11.5M 4.9M 70% /overlay
overlayfs:/overlay 17.2M 11.5M 4.9M 70% /
tmpfs 512.0K 0 512.0K 0% /dev

I usually have transmission, minidlna and samba set up (OpenWRT 19.07)

Now samba4 libs are too big to install, is there simply more in a base install of 21.02-rc1 so there isn’t room, or are the partitions misconfigured?

This is a clean install of OpenWRT 21.02-rc1

Commands on OpenWRT 19.07:

opkg update
opkg install libblkid luci-app-samba block-mount kmod-fs-exfat kmod-fs-ext4 kmod-usb-storage kmod-usb-storage-uas transmission-daemon-mbedtls luci-app-transmission luci-app-minidlna

Commands on OpenWRT 21.02:

opkg update
opkg install libblkid luci-app-samba4 block-mount kmod-fs-exfat kmod-fs-ext4 kmod-usb-storage kmod-usb-storage-uas transmission-daemon luci-app-transmission luci-app-minidlna

03.05.20213780Base systemBug ReportVery LowLowuhttpd error "Request Entity Too Large" on luci page af...TrunkUnconfirmed Task Description

Router: WRT1900AC v1 (mamba)
Openwrt: my build, r16521, includes luci-ssl, tvheadend server and dvb driver

Luci page ok at first.
After configuring tvheadend, including accounts, dvb muxes, channels, etc., luci page won’t open anymore. uhttpd error: Request Entity Too Large.
Starts working again after clearing browser cookies. Some of those cookies are set by tvheadend.

05.05.20213784Base systemBug ReportVery LowLowwifi cannot be turned offopenwrt-21.02Unconfirmed Task Description
  1. Hardware: netgear, wndr3700-v4 (ath79 ath9k ar9344 ar9582)
  2. Versions of OpenWrt where bug occurs: 21.02.0-rc1, snapshot (ath79)
  3. Versions of OpenWrt where bug does not occur : 19.07.7, 18.06 (ar71xx)
  4. **Duplicates: #3236

Steps to reproduce

We should be able to turn wifi on/off via any of the following methods:

  1. The wifi button in luci
  2. The wifi button on the router
  3. uci set wireless.radio0.disabled=$x && uci commit && wifi up

    (where x=0 to turn on wifi, x=1 to turn off wifi)

All three methods work to turn on wifi, but none of them work to turn off wifi. (Wifi continues running, the wifi LED on the router remains illuminated, and a client can connect to wifi). The problem occurs every time, on every boot.

The only way I have found to turn off wifi is,

/etc/init.d/wpad restart

Syslog when wifi is turned on via uci:

Mon May 3 20:21:46 2021 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) –> new PHY
Mon May 3 20:21:46 2021 kern.info kernel: [ 233.225694] br-lan: port 2(wlan0) entered blocking state
Mon May 3 20:21:46 2021 kern.info kernel: [ 233.231259] br-lan: port 2(wlan0) entered disabled state
Mon May 3 20:21:46 2021 kern.info kernel: [ 233.237081] device wlan0 entered promiscuous mode
Mon May 3 20:21:46 2021 daemon.notice hostapd: wlan0: interface state UNINITIALIZED→COUNTRY_UPDATE
Mon May 3 20:21:47 2021 kern.info kernel: [ 233.455640] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Mon May 3 20:21:47 2021 kern.info kernel: [ 233.462390] br-lan: port 2(wlan0) entered blocking state
Mon May 3 20:21:47 2021 kern.info kernel: [ 233.467836] br-lan: port 2(wlan0) entered forwarding state
Mon May 3 20:21:47 2021 daemon.notice hostapd: wlan0: interface state COUNTRY_UPDATE→ENABLED
Mon May 3 20:21:47 2021 daemon.notice hostapd: wlan0: AP-ENABLED
Mon May 3 20:21:48 2021 daemon.debug dnsmasq[2287]: listening on wlan0(#9): fe80::e6f4:c6ff:fee9:e1a%wlan0 port 53
Mon May 3 20:22:00 2021 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0)
Mon May 3 20:22:00 2021 daemon.err hostapd: Interface name wlan0 already in use
Mon May 3 20:22:00 2021 daemon.notice netifd: radio0 (2487): Command failed: Invalid argument
Mon May 3 20:22:00 2021 daemon.notice netifd: radio0 (2487): Device setup failed: HOSTAPD_START_FAILED
Mon May 3 20:22:00 2021 daemon.notice netifd: radio0 (2564): WARNING: Variable ‘data’ does not exist or is not an array/object

Syslog when wifi is turned off via uci

no output

Syslog when wifi is turned off via luci

Mon May 3 20:24:12 2021 kern.info kernel: [10819.214832] device wlan0 left promiscuous mode
Mon May 3 20:24:12 2021 kern.info kernel: [10819.219546] br-lan: port 2(wlan0) entered disabled state
Mon May 3 20:24:13 2021 daemon.notice netifd: radio0 (23114): WARNING: Variable ‘data’ does not exist or is not an array/object

Syslog when wifi is forced off via "/etc/init.d/wpad restart"

Mon May 3 20:27:37 2021 daemon.notice hostapd: wlan0: interface state ENABLED→DISABLED
Mon May 3 20:27:37 2021 daemon.notice hostapd: wlan0: AP-DISABLED
Mon May 3 20:27:37 2021 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Mon May 3 20:27:37 2021 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Mon May 3 20:27:37 2021 kern.info kernel: [ 583.724899] device wlan0 left promiscuous mode
Mon May 3 20:27:37 2021 kern.info kernel: [ 583.729643] br-lan: port 2(wlan0) entered disabled state
Mon May 3 20:27:37 2021 daemon.debug dnsmasq[2287]: stopped listening on wlan0(#9): fe80::e6f4:c6ff:fee9:e1a%wlan0 port 53
Mon May 3 20:27:37 2021 daemon.notice wpa_supplicant[2624]: Successfully initialized wpa_supplicant
 


08.05.20213789Base systemBug ReportVery LowLowodhcpd: ra_mtu default value '0' causes error on config...AllUnconfirmed Task Description

Name the tree/revision/version
from 9dd5316deae6402de68ddc8a08d1a6b496101828

Currently the default value of ra_mtu is 0, but it causes an error in parsing the config file.

      int config_parse_interface(void *data, size_t len, const char *name, bool overwrite)
      ~ To line number 780~
      if ((c = tb[IFACE_ATTR_RA_MTU])) {
              uint32_t ra_mtu = blobmsg_get_u32(c);
              if (ra_mtu < 1280 || ra_mtu > 65535)
                      goto err;
              iface->ra_mtu = ra_mtu;
      }

ra_mtu is checked with the following and it looks fine.

      static int send_router_advert(struct interface *iface, const struct in6_addr *from)
      ~to line number 477~
      if (mtu == 0)
              mtu = odhcpd_get_interface_config(iface->ifname, "mtu");
      if (mtu < 1280)
              mtu = 1280;

To fix this issue, my suggest is

1. Add write to syslog on parse error detail in config_parse_interface.
2. Fix README.md ra_mtu default value is not zero, It’s 1280.
3. Remove detailed error check on parse, if always checked at the time of use.
4. Or set to default value on error.

Thanks.

08.05.20213790Base systemBug ReportVery LowLowGrub2: Failed to build with GCC 10.30, glibc and binuti...TrunkUnconfirmed Task Description

I am trying to compile x64 builds up to commit:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b607e7df34031738b18582aaa1f4f93505d06734 with toolchain options GCC 10.30, glibc and binutils 2.36.1 selected
and ran into this bug:
a very large lzma_decompress.img file is output. (e.g. 134479600 bytes instead of 2864.) This causes grub-mkimage to fail with: “error: Decompressor is too big.”

There’s already a fix upstream
build: Fix GRUB i386-pc build with Ubuntu gcc
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=6643507ce30f775008e093580f0c9499dfb2c485

However, this upstreamed patch does not work well in OpenWRT buildroot, as it brings in python dependency and will triger an error of “‘automake-1.15’ is probably too old.”

Another patch works in my case, even it’s superseded by a newer version from the summiter:
https://patchwork.ozlabs.org/project/buildroot/patch/20200527071932.2307442-1-fontaine.fabrice@gmail.com/

Build went fine before https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b1ac59ed13926807289344cb0486ac077fc55023 with previous toolchain options of GCC 10.30, glibc and binutils 2.35.1 selected


12.05.20213802KernelBug ReportVery LowLowDFS channel change causes 5GHz WiFi to failopenwrt-19.07Unconfirmed Task Description

My TP-Link AC1750 Archer C7 v5 just detected another WiFi on the same 5GHz channel. Thus it tried to switch to a different channel, which apparently succeeded. Afterwards the kernel experienced a bug causing the 5GHz WiFi to fail indefinitely.

I’ve attached a list of installed packages and the relevant syslog:
Lines 1 - 7 show the change to a different channel
Lines 8 - 10 show a device disconnecting and reconnecting (probably because of the channel switch)
Lines 11 - 82 are SWBA overrun warnings
Lines 90 - 190 are kernel traces
Lines 255 - 261 show a device connecting to the 2.4GHz WiFi, because the 5GHz is no longer available
Lines 271 - 278 show other devices being disassociated as they are also unable to connect again

 


12.05.20213804Base systemBug ReportVery LowLowrpcd file Plugin ACLs can be bypassed when used via uht...TrunkUnconfirmed Task Description

Hi,

I’ve configured the rcpd file plugin together with the uhttpd ubus plugin to put the ubus on the network and to me there seems to be a security problem when used in this combination.
I think it is some quite exotic experiment by myself and I hope nobody had done this on a live field system on the internet.

Let me elaborate the situation little bit.

The uhttpd will first check the ACLs of the call. In this case whether the user is allowed to call the ubus file object and the read/write/... methods. Lets assume it is allowed.
Further down the call hierarchy the rpcd file plugin will then check its file ACLs if the given session contains the permissions to execute, read, write or list the specified file or directory path.

To accomplish this task the rpcd file plugin needs a session id and as the primary session id was not passed down by uhttpd together with the call it is now not there any more. That’s why there is a secondary session id within the ubus file methods payload parameters. The content can be either the same sid or another one, that doesn’t mater in this example.

Now if we call a file.exec() via JSON/RPC (uhttpd/ubus) we have to specify the SID two times.
The Problem: If I leave out the inner secondary sid completely I get passed all file ACLs!
The function rpc_file_access() in rpcd will return true at file.c:180 if the sid is NULL!

There is no enforcement of the ubus file methods policy field “ubus_rpc_session”. On none of the methods! Only the “path” parameter is enforced.

Either the “return true” should be removed or the methods should enforce a sid. Otherwise one can not use this rpcd file plugin securely as a authenticated users can bypass all file rpcd file ACLs easily by simply dropping the parameter field.

Regards,
Steffen

09.05.2017772PackagesFeature RequestVery LowVery LowAllowing Snort to also block possibly using SnortSamTrunkUnconfirmed Task Description

I noticed that Snort is available from the packages. I wanted to inquire if it would be possible to intergrate dynamic blocking through software such as SnortSam (http://www.snortsam.net/).

pfSence implements a blocking feature with Snort, I’m curious if others may be likewise be interested in this feature being added in to a future release of LEDE.

Thanks

06.03.20181414ToolchainBuild FailureVery LowVery Lowmbedtls: building with ccache: /staging_dir/host/bin/cc...TrunkUnconfirmed Task Description

I am currently trying to compile OpenWRT for

CONFIG_TARGET_LANTIQ=Y
CONFIG_TARGET_LANTIQ_XWAY=Y
CONFIG_TARGET_lantiq_xway_DEVICE_arcadyan_arv752dpw22=y

I am using

CONFIG_DEVEL=y
CONFIG_CCACHE=y

I am building in the following way:

The build was carried out on a git clone git://github.com/openwrt/openwrt.git, later brought up to date with a git pull, with latest commit from 2018-03-05T10:44:20+01:00, commit hash 5cbd22bb0f.

Into this git clone a previously generated .config seed, made previously by make menuconfig and ./scripts/diffconfig.sh, was copied over to ./.config.

From there on, the following commands were issued:

./scripts/feeds update -a
./scripts/feeds install -a
make -j1 V=s defconfig
make -j1 V=s download
make -j1 V=s IGNORE_ERRORS=m | tee make.log

When it comed to building mbedtls, there are the following lines of output which indicate something is wrong:

[...]
make[3]: [Makefile:75: /home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/2018-02-26_12-04-45_-_custom-wo-pie_feeds-rooter-custom/build_dir/target-mips_24kc_musl/mbedtls-2.7.0/.configured_68b329da9893e34099c7d8ad5cb9c940] Error 123 (ignored)
[...]
/home/felics/download/router/OS/OpenWRT/source_build/source/batch_builds/2018-02-26_12-04-45_-_custom-wo-pie_feeds-rooter-custom/staging_dir/host/bin/ccache: invalid option -- 'd'
Usage:
    ccache [options]
[...]

Build continues, (seemingliy) successfully: Indicated by the further output of make, and issuing later a make -j1 V=s (i.e. without IGNORE_ERRORS=m), does not bring this up again.

The toolchain (./staging_dir/toolchain-*) is mips_24kc_gcc-5.5.0_musl.

Build is carried out on an x86_64 Arch Linux machine.

Attached are the following files:

  • .config-diffconfig-seed: The .config-seed used for make defconfig,
  • .config: The .config created by the make defconfig and used for the build,
  • mbedtls.log: The pa[.config-diffconfig-seed.txt](https://github.com/openwrt/packages/files/1782373/default.config-diffconfig-rt of the output of make -j1 V=s IGNORE_ERRORS=m regarding building mbedtls,
  • make.log.stdout.xz: For your interest, the full output of make -j1 V=s IGNORE_ERRORS=m (.xz compressed; decompresses to about 29 MB) (Note that at the end another build error occurs, which seems not to be related to embedtls),
  • feeds.conf: The feeds.conf used.

(Note that I just forgot to capture stderr too, but the error messages seem to be present in stdout. Since a full rebuild takes a day on my machine, I won’t do that if not necessary.)

07.03.20181415Base systemFeature RequestVery LowVery Low[Enhancement] Consider shorter interface-name prefixesTrunkUnconfirmed Task Description

Given that `IFNAMSIZ` is typically 16, there are 15 characters available for an interface name.

OpenWRT prepends a prefix that can be at least 6 characters `gre4t-` as an example.

If one then creates pseudo/virtual-interfaces using VLAN notation, there are only 4 characters available for configuration

`gre4t-ABCD.1234`

As long as this limitation is known, there is no loss of functionality, only utility in the naming. I would have ideally been able to name my tunnels with a more readable indication of where the other endpoint was, for example `portal1` rather than `gt99`.

At some time in the future, shortening these generated prefixes would be welcome. I acknowledge that this likely impacts only a small fraction of advanced users and a change may impact scripts that rely on the generated name.

 


25.01.20192083Base systemBug ReportVery LowVery LowRemove last references to the lede-project.org URLTrunkUnconfirmed Task Description

git grep -i “lede-project\.org” | grep -vi Copyright
There are still some references to the old project.

Thanks.

06.05.20192269PackagesBug ReportVery LowVery Lowiwinfo_lib.c does not correlate it's list with kernelTrunkUnconfirmed Task Description

The following issue occurs on all devices across all OpenWRT versions as it is partly a problem derived from the Linux Kernel.

It is explained in detail here: https://forum.openwrt.org/t/wifi-regulatory-country-database/35775

Prerequisites:

1) You need to have set up a working Wireless access point.
2) The set country has to not be one of the ones patched out here: https://pastebin.com/M2qTQFT5

Steps to reproduce:

1) Type ‘iw reg get’ in the terminal. This will give you a list of all available channels in the regulatory zone (country).
2) Change country to one of the patched out ones: https://pastebin.com/M2qTQFT5 (Eg. Angola, Antarctica)
3) [opt - Disregard this step if you used the WebUI] Type ‘/etc/init.d/network restart’ 4) Type ‘iw reg get’ in the terminal. You will notice that it has not changed.

Problem:

You can, unknown to you, set up a channel which is prohibited in your country. This is very hard to *check* because there is no way to pre-query whether you can set such a country or not.

More detailed explanation and argumentation can be found here: https://forum.openwrt.org/t/wifi-regulatory-country-database/35775


11.05.20192278Base systemFeature RequestVery LowVery LowRFE: Replace iptables(legacy) with iptables(nf_tables)TrunkUnconfirmed Task Description

Supported since iptables 1.8: https://marc.info/?l=netfilter-devel&m=153086953903487

31.07.20192418Base systemBuild FailureVery LowVery LowBuild failure - Netgear 6220 (mt7621)TrunkUnconfirmed Task Description


14.09.20192494Base systemFeature RequestVery LowVery LowImplement system to allow LuCI to display messages prio...AllUnconfirmed Task Description

Currently there is no system to alert users to possible issues they may encounter when flashing a new image. This has led to certain features being delayed or even withheld (the switch from swconfig → DSA is a good example). Simply put there is no way to alert the average user to configuration breaking changes a new image might make.

A short header that contains important information could be inserted into OpenWrt images. The header is parsed and displayed via LuCI if certain criteria are/aren’t met. This could be something as simple as a image version check or something more complex like configuration and package comparisons.

This is really more of a forward looking feature, but it would allow more drastic changes (changes that cannot be migrated) be made between OpenWrt versions.

18.12.20192687Base systemBug ReportVery LowVery LowWiFi LED does not dynamically track state of radio on Z...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
- Software versions of OpenWrt/LEDE release, packages, etc.
- Steps to reproduce

 

Occurs on ZBT-WE3526 (16M) an MT76 unit with 512MB Ram

Stock 19.07, but has been this way since 18.06.xx

Steps to reproduce:
Log into to LuCi and disable a wifi radio, LED remains on.

reboot, radiox LED is now off, so LED is only set at boot

Log back into luci, turn radio on, radio becomes operational (STAs can connect) but LED remains off.

Desired behavior: LED tracks state of radio without requiring a reboot.

03.02.20202803KernelBug ReportVery LowVery Lowmt76 kernel spam log with ingnoring tx power message openwrt-19.07Unconfirmed Task Description

ASUS RT-AC51U

Official build OpenWRT 19.07.1 without installed any add-ons packages.

System and kernel log all time are spammed by information about ignoring default 2.4G tx power even when in its set to default driver. This issue appears right after fresh installation and rebooting or changing wireless setting doesn’t fix it.

04.04.20202962Base systemBug ReportVery LowVery LowGlobal section not createdTrunkWaiting on reporter Task Description

If I build on masters by disabling IPv6 support, the Globals section in “network” config file is not created.

- The problem occurs on Linksys WRT3200ACM (Rango), but I suppose it is independent of the hardware.
- I am currently building on master and this is where I noticed the problem.
- Download the code, update and install the packages, access menuconfig. Disable IPv6 support. Save the configuration, build and flash the

 firmware on the device. Check the file /etc/config/network.

Although the Globals section contains ula_prefix, it also contains packet_steering, which is not related to IPv6 support.
The workaround is to manually create the Globals section and add the option for packet_steering.

30.06.20203210Base systemBug ReportVery LowVery Lowdo not hard-code IS_TTY in script scripts/feedsTrunkUnconfirmed Task Description

Tool “scripts/feeds” assumes you are always outputting to a terminal, so it will fill your log files with terminal control codes. That comes up as rubbish, or as very long lines, or both, in many text editors.

I have jumped through all the hoops and provided a patch to fix it:

build: do not hard-code IS_TTY in script scripts/feeds

https://patchwork.ozlabs.org/project/openwrt/patch/mailman.22006.1591783382.2542.openwrt-devel@lists.openwrt.org/

This bug is somehow related to bug FS#2086.

31.07.20203261Base systemBug ReportVery LowVery LowDHCP IP conflict and the whole DHCP stops workingTrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on Linksys WRT3200ACM - Software versions of OpenWrt/LEDE release, packages, etc. - dnsmasq

- Problem: If there is an IP conflict between two devices to LAN interface the whole DHCP stops working for the whole LAN subnet.

- Steps to reproduce

    1. Set two devices/with different MAC-addresses (or more) on static leases with the same IP

- My opinion: Have the the devices trying to connect (that has a conflict) to get the error conflict IP message (on receiving end) as soon as a conflict happens; DHCP continue working despite a conflict has occurred.

19.12.20203524KernelBug ReportVery LowVery LowTP-Link Archer C7 v2, missing tp-link:green:lan* and tp...openwrt-19.07Unconfirmed Task Description

Hardware is TP-Link Archer C7 v2.

I’ve just upgraded to 19.07.5 using prebuilt image “openwrt-19.07.5-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin” from some version of LEDE 17, and found that it’s not possible to control LAN/WAN leds anymore. There are tp-link:green:{qss,system,usb1,usb2,wlan2g,wlan5g} leds listed in /sys/class/leds, but there are no mentions of lan1, lan2, lan3, lan4 or wan. I don’t remember which particular version of LEDE it was before. Something from 2017.

Next is just a guess. I’ve tried to bisect code, but without trying to build and run it on the hardware, and found that last time string “tp-link:green:wan” was in the source that was somehow related to Archer C7 v2 was just before 4e4ee4649553ab536225060a27fc320bf54e458c (ar71xx: drop target). In target/linux/ar71xx/files/arch/mips/ath79/mach-archer-c7.c there were two sets of leds. One, registered with mdiobus_register_board_info(), these are now missing. And another, registered with ath79_register_leds_gpio(), these are now present.

Haven’t had a chance to test various versions from bisecting on the actual hardware yet.

23.03.20213702KernelBug ReportVery LowVery LowRansmit queue 0 timed out on Netgear R6220openwrt-19.07Unconfirmed Task Description

Device: Netgear R6220
OpenWRT version: 19.07.7 r11306-c4a6851c72
User installed packages: mwan3
Steps to reproduce: unknown, spotted error stack in kernel logs, so I share them.

[22934.015218] ------------[ cut here ]------------
[22934.024448] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:320 0x8038d700
[22934.038516] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
[22934.052393] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt compat ledtrig_usbport xt_set ip_set_list_set ip_set_hash_netportnet
[22934.193603]  ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd gpio_button_hotplug usbcore nls_base usb_common
[22934.277184] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.221 #0
[22934.289304] Stack : 00000000 00000000 00000000 87f65240 00000000 00000000 00000000 00000000
[22934.305940]         00000000 00000000 00000000 00000000 00000000 00000001 87c09d60 5326163c
[22934.322575]         87c09df8 00000000 00000000 00006358 00000038 8049e2b8 00000008 00000000
[22934.339205]         00000000 80550000 00043ac0 00000000 87c09d40 00000000 00000000 8050d500
[22934.355830]         8038d700 00000140 00000000 87f65240 00000000 802ae4c0 00000000 806b0000
[22934.372460]         ...
[22934.377324] Call Trace:
[22934.377402] [<8049e2b8>] 0x8049e2b8
[22934.389221] [<8038d700>] 0x8038d700
[22934.396160] [<802ae4c0>] 0x802ae4c0
[22934.403094] [<8000c1a0>] 0x8000c1a0
[22934.410030] [<8000c1a8>] 0x8000c1a8
[22934.416965] [<804870f4>] 0x804870f4
[22934.423891] [<80071e00>] 0x80071e00
[22934.430856] [<8002e798>] 0x8002e798
[22934.437794] [<8038d700>] 0x8038d700
[22934.444739] [<8002e820>] 0x8002e820
[22934.451679] [<8038d700>] 0x8038d700
[22934.458605] [<80099da0>] 0x80099da0
[22934.465544] [<8038d554>] 0x8038d554
[22934.472472] [<80088948>] 0x80088948
[22934.479418] [<80088c04>] 0x80088c04
[22934.486354] [<800794a8>] 0x800794a8
[22934.493285] [<804a50b8>] 0x804a50b8
[22934.500218] [<80033164>] 0x80033164
[22934.507148] [<8025b710>] 0x8025b710
[22934.514086] [<80007488>] 0x80007488
[22934.521012] 
[22934.524149] ---[ end trace f60c0fe92d06a467 ]---
[22934.533372] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[22934.545708] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[22934.557699] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=070d0000, max=0, ctx=183, dtx=183, fdx=182, next=183
[22934.578691] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=06060000, max=0, calc=1456, drx=1502
[22934.601287] mtk_soc_eth 1e100000.ethernet: 0x100 = 0x45600f0c, 0x10c = 0x80818
[22934.615760] mtk_soc_eth 1e100000.ethernet: reset pse
[22934.631131] mtk_soc_eth 1e100000.ethernet: PPE started
02.05.20213775Base systemBug ReportVery LowVery LowR7800 & 21.02.0-rc1 : no client connected to Wifi 5GHzopenwrt-21.02Unconfirmed Task Description

Environment : - Netgear R7800 (Nighthawk X4S AC2600)
- OpenWrt 21.02.0-rc1 (sysupgraded from OpenWrt 19.07.7 with some basic configuration)

Problem encountered : After doing a sysupgrade from OpenWrt 19.07.7 to OpenWrt 21.02.0-rc1, everything looked fine at first sight, but I have noticed that none of the WiFi clients were connected to the 5GHz WiFi, they were all connected to the 2.4GHz WiFi, which leaded to a bandwidth diminution and my printer was not anymore accessible.
Now, I am back to OpenWrt 19.07.7 and the printer is working fine again.

Sorry I don’t have more details on that problem, I am creating that bug ticket to see if I am the only one concerned by that bug.
I don’t even know if the 5GHz WiFi was emitting for real or not.

Showing tasks 1101 - 1150 of 1150 Page 23 of 23<<First - 19 - 20 - 21 - 22 - 23

Available keyboard shortcuts

Tasklist

Task Details

Task Editing