Device: openwrtorg/rootfs:armvirt-32-19.07.2 Docker image
Version: OpenWrt 19.07

Hi- I hope everyone is doing well.

We’ve got some builds that use the openwrtorg/rootfs:armvirt-32-19.07.2 Docker image; they run around 1600 UTC each day as well as any time somebody amends a related pull request (normally between 0000 UTC to 1000 UTC, our working day for Perth, Australia).

Occasionally, we get failures due to packages missing in OpenWrt (curiously, it’s usually GCC)- more commonly during our morning.

I _think_ this may be a byproduct of the OpenWrt nightly builds happening and the packages being rebuilt, it may be that https://downloads.openwrt.org/releases/19.07.2/packages/arm_cortex-a15_neon-vfpv4/packages/ is the actual build output folder (and so during a build, the contents may change).

I’ve had a look at the timestamps at that URL, I’m not sure what timezone they’re in, but they’re mostly around the 0100 to 0500 range- if this is UTC and my suspicions are correct, then that would definitely cause an increase of this issue during our morning (which is what we see).

I don’t think it’s related to any Docker build cache funniness- we wipe that at 1900 UTC each day.

While you won’t reliably be able to reproduce, here’s a simple test case (requiring Docker for Mac/Windows, or Docker for Linux with docker buildx configured):

- docker run –rm -it openwrtorg/rootfs:armvirt-32-19.07.2 sh
- mkdir /var/lock
- opkg update && opkg install gcc

I’ve attached a log excerpts from our CI system of one such failure.

Thanks and regards,

Ed

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

X86_64 arch, kernel fails to insert XFRM states with AES-GCM as transform.
Testable with
ip x s add proto esp dst 14.0.0.70 src 14.0.0.52 spi 0×07 mode transport reqid 0×07 replay-window 32 aead ‘rfc4106(gcm(aes))’ 0x44434241343332312423222114131211f4f3f2f1 128 sel src 14.0.0.52/24 dst 14.0.0.70/24 proto tcp

Works on Arch.
Result on X86_64 OpenWRT 19.07.3:
RTNETLINK answers: No such file or directory

On Arch 5.6.15-arch1-1, works (no output, ip x s shows the state).
Also fails 100% of the time when tested using an IKE keying daemon, e.g. strongSwan

Device: TP-Link Archer C6v2
OpenWrt: 19.07.3

When stateless mode enabled with 6in4 tunnel, kernel always spamming this errors. Anyway IPv6 working fine.

[  552.992200] sit: non-ECT from 193.0.203.203 with TOS=0xc1
[  553.672272] sit: non-ECT from 193.0.203.203 with TOS=0xc1
[  555.673655] sit: non-ECT from 193.0.203.203 with TOS=0xc1
[  559.668806] sit: non-ECT from 193.0.203.203 with TOS=0xc1
[  561.802355] sit: non-ECT from 193.0.203.203 with TOS=0xc1
[  561.803238] sit: non-ECT from 193.0.203.203 with TOS=0xc1
[  563.850841] sit: non-ECT from 193.0.203.203 with TOS=0xc1
[  565.898359] sit: non-ECT from 193.0.203.203 with TOS=0xc1
[  565.898456] sit: non-ECT from 193.0.203.203 with TOS=0xc1
[  565.899107] sit: non-ECT from 193.0.203.203 with TOS=0xc1

I have a connection problem between PS4 slim in the 5.8 Ghz band
I am using a TpLink C59 OpenWrt router 19.07.3 r11063-85e04e9f46
All the devices work well in the 5.8GHz band but the PS4 does not link in the 5.8Hz band instead the PS4 works well in the 2.8Ghz band. I have this problem since I migrated to 19.07 with the previous version 18.06 the PS4 worked fine in band 5.8 Ghz
With all three versions of 19.07 the problem is the same.
I am using the Ar71xx driver but the problem repeats with Ath79
The PS4 works OK with other Access Points in band 5.8 Ghz
The failure also occurs without encryption and with a fixed IP.
From another device the ping fails when I ping against the PS4 in band 5.8 Ghz
Using the 2.4 GHz radio all OK
Someone had a similar problem.
Very good OpenWrt
Greetings and thanks

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

- Software versions of OpenWrt/LEDE release, packages, etc.
tag 19.07.3
- Steps to reproduce
make fails:

export CROSS="arm-openwrt-linux-muslgnueabi-"  NO_RENAME=1 ; NM="arm-openwrt-linux-muslgnueabi-nm" STRIP="/home/oli/openwrt/staging_dir/host/bin/sstrip" STRIP_KMOD="/home/oli/openwrt/scripts/strip-kmod.sh" PATCHELF="/home/oli/openwrt/staging_dir/host/bin/patchelf" /home/oli/openwrt/scripts/rstrip.sh /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools
rstrip.sh: /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/usr/sbin/fw_printenv: executable
(cd /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/CONTROL; ( echo "$CONTROL"; printf "Description: "; echo "$DESCRIPTION" | sed -e 's,^[[:space:]]*, ,g'; ) > control; chmod 644 control; ( echo "#!/bin/sh"; echo "[ \"\${IPKG_NO_SCRIPT}\" = \"1\" ] && exit 0"; echo "[ -x "\${IPKG_INSTROOT}/lib/functions.sh" ] || exit 0"; echo ". \${IPKG_INSTROOT}/lib/functions.sh"; echo "default_postinst \$0 \$@"; ) > postinst; ( echo "#!/bin/sh"; echo "[ -x "\${IPKG_INSTROOT}/lib/functions.sh" ] || exit 0"; echo ". \${IPKG_INSTROOT}/lib/functions.sh"; echo "default_prerm \$0 \$@"; ) > prerm; chmod 0755 postinst prerm; echo "$V_Package_uboot_envtools_conffiles" > conffiles;  )
install -d -m0755 /home/oli/openwrt/bin/targets/mvebu/cortexa9/packages
/home/oli/openwrt/scripts/ipkg-build -c -o 0 -g 0 /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools /home/oli/openwrt/bin/targets/mvebu/cortexa9/packages
/home/oli/openwrt/staging_dir/host/bin/find: '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/etc/config/ubootenv': No such file or directory
/home/oli/openwrt/staging_dir/host/bin/find: '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/etc/fw_env.config': No such file or directory
Packaged contents of /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools into /home/oli/openwrt/bin/targets/mvebu/cortexa9/packages/uboot-envtools_2018.03-3_arm_cortex-a9_vfpv3-d16.ipk
echo "uboot-envtools" >> /home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/pkginfo/uboot-envtools.default.install
make[3]: Leaving directory '/home/oli/openwrt/package/boot/uboot-envtools'
time: package/boot/uboot-envtools/compile#1.27#0.68#1.71
make[3]: Entering directory '/home/oli/openwrt/package/boot/uboot-mvebu'
rm -f /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03/.built
touch /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03/.built_check
make  -C /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03 CROSS_COMPILE=arm-openwrt-linux-muslgnueabi- DTC="/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linux-4.14.180/scripts/dtc/dtc" HOSTCC="gcc" HOSTCFLAGS="-O2 -I/home/oli/openwrt/staging_dir/host/include -I/home/oli/openwrt/staging_dir/hostpkg/include -I/home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/host/include -I/home/oli/openwrt/staging_dir/host/include -I/home/oli/openwrt/staging_dir/hostpkg/include -I/home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/host/include -std=gnu11" HOSTLDFLAGS="-L/home/oli/openwrt/staging_dir/host/lib -L/home/oli/openwrt/staging_dir/hostpkg/lib -L/home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/host/lib"
make[4]: Entering directory '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03'
  CHK     include/config/uboot.release
  CHK     include/generated/version_autogenerated.h
  CHK     include/generated/timestamp_autogenerated.h
  CC      lib/asm-offsets.s
  CHK     include/generated/generic-asm-offsets.h
  UPD     include/generated/generic-asm-offsets.h
  CC      arch/arm/lib/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  UPD     include/generated/asm-offsets.h
  HOSTLD  scripts/dtc/dtc
/usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
make[6]: *** [scripts/Makefile.host:108: scripts/dtc/dtc] Error 1
make[5]: *** [scripts/Makefile.build:425: scripts/dtc] Error 2
make[4]: *** [Makefile:491: scripts] Error 2
make[4]: Leaving directory '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03'
make[3]: *** [Makefile:53: /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03/.built] Error 2
make[3]: Leaving directory '/home/oli/openwrt/package/boot/uboot-mvebu'
time: package/boot/uboot-mvebu/clearfog/compile#0.32#0.20#0.51
make[2]: *** [package/Makefile:113: package/boot/uboot-mvebu/compile] Error 2
make[2]: Leaving directory '/home/oli/openwrt'
make[1]: *** [package/Makefile:107: /home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/oli/openwrt'
make: *** [/home/oli/openwrt/include/toplevel.mk:227: world] Fehler 2

I was upgraded to my LinkSys WRT-1900ACS from LEDE 17.01.6 to OpenWRT 19.07.3.

With LEDE 17.01.6 I can set up 5GHz WLAN to use N and AC at the same time with two different SSID and with this setup some old devices can connect to this 5GHz WLAN with 802.11n correctly while my notebook can connect to 802.11AC on 5GHz network too (I used two different SSID setup both setting used 5GHz network).

After I upgraded to OpenWrt I found there is no option to set up both 802.11N and 802.11AC with 5GHz at the same time and my old WiFi devices need to use 2.4GHz network only.

With the OpenWrt 19.07.3 the ‘require_mode’ option can set globally so need to decide to use AC or N only for all 5GHz SSID.

Is there any way to set 5GHz with both N and AC at the same time or there is no option by technical reason?

Hi all,

I am running bird2 on Netgear R7800 for OSPF routing but it doesn’t start. Following are error messages I got:

# bird -c /etc/bird.conf -d
Bus error

# logread
Sat Jun 20 12:24:09 2020 daemon.info bird: Started
Sat Jun 20 12:24:09 2020 kern.err kernel: [572809.062848] Alignment trap: not handling instruction f44c0a1f at [<0006bb88>]
Sat Jun 20 12:24:09 2020 kern.alert kernel: [572809.062907] Unhandled fault: alignment exception (0x801) at 0x017c9634
Sat Jun 20 12:24:09 2020 kern.alert kernel: [572809.069111] pgd = d7668000
Sat Jun 20 12:24:09 2020 kern.alert kernel: [572809.075597] [017c9634] *pgd=5c0c6835, *pte=5ad3475f, *ppte=5ad34c7f


# dmesg
[571421.877597] Alignment trap: not handling instruction f44c0a1f at [<0006bb88>]
[571421.877645] Unhandled fault: alignment exception (0x801) at 0x0111b624
[571421.883832] pgd = dc258000
[571421.890385] [0111b624] *pgd=5e63a835, *pte=5c72975f, *ppte=5c729c7f

Environment
- OpenWrt 19.07.3, r11063-85e04e9f46
- bird2 - 2.0.7-2
- target ipq806x
- model Netgear R7800

# /etc/bird.conf
log syslog all;
router id 192.168.1.1;                                                                                                                                        
protocol device {                                                                                                                                       
}                                                                                                                                                       
protocol bfd {                                                                                                                                          
}                                                                                                                                                       
protocol direct {                                                                                                                                      
        interface "br-lan";                                                                                                                             
        ipv4;                   # Connect to default IPv4 table                                                                                         
        ipv6;                   # ... and to default IPv6 table                                                                                         
}                                                                                                                                                       
                                                                                                                                                        
# The Kernel protocol is not a real routing protocol. Instead of communicating                                                                          
# with other routers in the network, it performs synchronization of BIRD                                                                                
# routing tables with the OS kernel. One instance per table.                                                                                            
protocol kernel {                                                                                                                                       
        scan time 10;                                                                                                                                   
        merge paths;                                                                                                                                    
        ipv4 {                  # Connect protocol to IPv4 table by channel                                                                             
#             table master4;    # Default IPv4 table is master4                                                                                         
#             import all;       # Import to table, default is import all                                                                                
              export all;       # Export to protocol. default is export none                                                                            
        };                                                                                                                                              
#       learn;                  # Learn alien routes from the kernel                                                                                    
#       kernel table 10;        # Kernel table to synchronize with (default: main)                                                                      
}                                                                                                                                                       
                                                                                                                                                        
# Another instance for IPv6, skipping default options                                                                                                   
protocol kernel {                                                                                                                                       
        scan time 10;                                                                                                                                   
        merge paths;                                                                                                                                    
        ipv6 { export all; };                                                                                                                           
}                                                                                                                                                       
                                                                                                                                                        
# OSPF example, both OSPFv2 and OSPFv3 are supported                                                                                                    
protocol ospf v2 ospf4 {                                                                                                                                
        ipv4 {                                                                                                                                          
        };                                                                                                                                              
        area 0 {                                                                                                                                        
                interface "br-lan" {bfd;};                                                                                                              
        };                                                                                                                                              
}

This issue can be reproduced with the latest OpenWrt release 19.07.3, but it has been there for a long time.
A custom build of bird2 package with OpenWRT SDK doesn’t have this issue.

I am not sure this is the right place to report this issue. Could anyone help with this?

I have an x86_64 system with an Atheros AR9565 mini-pcie which is not recognized by Openwrt unless I recompile with the following options:
CONFIG_PACKAGE_kmod-ath9k=y
CONFIG_ATH9K_SUPPORT_PCOEM=y

I’m using Openwrt 19.07.3. In the prebuilt images I believe kmod-ath9k is being compiled with CONFIG_ATH9K_SUPPORT_PCOEM defaulting to =n. Is it possible to get this changed to CONFIG_ATH9K_SUPPORT_PCOEM=y in future prebuilt releases?

Thanks!

I’m trying to run OpenWRT on a P2020RDB board, I managed to fetch the release mpc85xx initramfs.bin from here (I failed to get the snapshot one for Freescale over here as I received a 403 error), and then I pulled it into uboot using tftpboot, and placed it at address “0×1000000“, and ran “bootm 0×1000000” the kernel starts and then I get a call trace and some stuff get dumped:

XTM-330_P2020(FAILSAFE) => bootm 0x1000000                                                                                                                      [165/195]
WARNING: adjusting available memory to 30000000                                                                                                                          
## Booting kernel from FIT Image at 01000000 ...                                                                                                                         
   Using 'config@1' configuration                                                                                                                                        
   Trying 'kernel@1' kernel subimage                                                                                                                                     
     Description:  POWERPC OpenWrt Linux-4.14.180                                                                                                                        
     Type:         Kernel Image                                                                                                                                          
     Compression:  gzip compressed                                                                                                                                       
     Data Start:   0x010000ec                                                                                                                                            
     Data Size:    5128735 Bytes = 4.9 MiB                                                                                                                               
     Architecture: PowerPC                                                                                                                                               
     OS:           Linux                                                                                                                                                 
     Load Address: 0x00000000
     Entry Point:  0x00000000
     Hash algo:    crc32
     Hash value:   7754597c
     Hash algo:    sha1
     Hash value:   bd433c824dc74e015b759f3ab53ffe996b130f2e
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Flattened Device Tree from FIT Image at 01000000
   Using 'config@1' configuration
   Trying 'fdt@1' FDT blob subimage
     Description:  POWERPC OpenWrt p2020rdb device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x014e4448
     Data Size:    12550 Bytes = 12.3 KiB
     Architecture: PowerPC
     Hash algo:    crc32
     Hash value:   0d1ae91a
     Hash algo:    sha1
     Hash value:   fdbac0f412982769bdef3ba414fc6716b8a855d4
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x14e4448 
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 00ff9000, end 00fff105 ... OK
[    0.000000] Memory CAM mapping: 256/256/256 Mb, residual: 256Mb
[    0.000000] Linux version 4.14.180 (builder@buildhost) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r11063-85e04e9f46)) #0 SMP Sat May 16 18:32:20 2020
[    0.000000] Using P2020 RDB machine description
[    0.000000] bootconsole [udbg0] enabled
[    0.000000] CPU maps initialized for 1 thread per core
[    0.000000] -----------------------------------------------------
[    0.000000] phys_mem_size     = 0x30000000
[    0.000000] dcache_bsize      = 0x20
[    0.000000] icache_bsize      = 0x20
[    0.000000] cpu_features      = 0x0000000012100460
[    0.000000]   possible        = 0x0000000012120460
[    0.000000]   always          = 0x0000000000100000
[    0.000000] cpu_user_features = 0x84e08000 0x08000000
[    0.000000] mmu_features      = 0x00020010
[    0.000000] -----------------------------------------------------
mpc85xx_rdb_setup_arch()
[    0.000000] mpc85xx_qe_init: Could not find Quicc Engine node
[    0.000000] MPC85xx RDB board from Freescale Semiconductor
[    0.000000] barrier-nospec: using isync; sync as speculation barrier
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts
[    0.000000] percpu: Embedded 12 pages/cpu s18380 r8192 d22580 u49152
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 195072
[    0.000000] Kernel command line: root=/dev/sda1 rw rootdelay=30 console=ttyS0,115200 ramdisk_size=600000
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 705444K/786432K available (4400K kernel code, 176K rwdata, 548K rodata, 2620K init, 216K bss, 80988K reserved, 0K cma-reserved)
[    0.000000] Kernel virtual memory layout:
[    0.000000]   * 0xfffdf000..0xfffff000  : fixmap
[    0.000000]   * 0xfdffe000..0xfe000000  : early ioremap
[    0.000000]   * 0xf1000000..0xfdffe000  : vmalloc & ioremap
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
[    0.000000] mpic: Setting up MPIC " OpenPIC  " version 1.2 at ffe40000, max 2 CPUs
[    0.000000] mpic: ISU size: 256, shift: 8, mask: ff
[    0.000000] mpic: Initializing for 256 sources
[    0.000000] mpc85xx_rdb_pic_init: Could not find qe-ic node
[    0.000010] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0xf6018975a, max_idle_ns: 440795204712 ns
[    0.010162] clocksource: timebase mult[f000003] shift[24] registered
[    0.016543] pid_max: default: 32768 minimum: 301
[    0.021182] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.027710] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.035198] mpic: requesting IPIs...
[    0.039003] Hierarchical SRCU implementation.
[    0.043596] smp: Bringing up secondary CPUs ...
[    0.048509] smp: Brought up 1 node, 2 CPUs
[    0.052518] Using shared cache scheduler topology
[    0.058928] random: get_random_u32 called from 0xc0201c80 with crng_init=0
[    0.065843] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.075502] futex hash table entries: 512 (order: 2, 16384 bytes)
[    0.081889] NET: Registered protocol family 16
[    0.094212] Found FSL PCI host bridge at 0x00000000ffe0a000. Firmware bus number: 0->0
[    0.102052] PCI host bridge /pcie@ffe0a000 (primary) ranges:
[    0.107677]  MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000 
[    0.114869]   IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
[    0.121993] /pcie@ffe0a000: PCICSRBAR @ 0xfff00000
[    0.126746] setup_pci_atmu: end of DRAM 30000000
[    0.131344] /pcie@ffe0a000: Setting PCI inbound window greater than memory size
[    0.146042] PCI: Probing PCI hardware
[    0.149766] fsl-pci ffe0a000.pcie: PCI host bridge to bus a000:00
[    0.155778] pci_bus a000:00: root bus resource [io  0x0000-0xffff]
[    0.161927] pci_bus a000:00: root bus resource [mem 0x80000000-0x9fffffff]
[    0.168774] pci_bus a000:00: root bus resource [bus 00-ff]
[    0.174535] pci a000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    0.182529] pci a000:00:00.0: PCI bridge to [bus 01-ff]
[    0.187722] PCI: Cannot allocate resource region 0 of device a000:00:00.0, will remap
[    0.195494] pci a000:00:00.0: BAR 0: no space for [mem size 0x00100000]
[    0.202057] pci a000:00:00.0: BAR 0: failed to assign [mem size 0x00100000]
[    0.208993] pci a000:00:00.0: PCI bridge to [bus 01]
[    0.213933] pci a000:00:00.0:   bridge window [io  0x0000-0xffff]
[    0.220002] pci a000:00:00.0:   bridge window [mem 0x80000000-0x9fffffff]
[    0.226764] pci_bus a000:00: Some PCI device resources are unassigned, try booting with pci=realloc
[    0.235925] /soc@ffe00000/timer@41100: cannot get timer frequency.
[    0.242059] /soc@ffe00000/timer@42100: cannot get timer frequency.
[    0.254462] clocksource: Switched to clocksource timebase
[    0.260493] NET: Registered protocol family 2
[    0.265162] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.272178] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[    0.278670] TCP: Hash tables configured (established 8192 bind 8192)
[    0.285022] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.290884] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.297300] NET: Registered protocol family 1
[    2.607509] Crashlog allocated RAM at address 0x3f00000
[    2.612901] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[    2.622935] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    2.628700] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    2.639761] io scheduler noop registered
[    2.643605] io scheduler deadline registered (default)
[    2.649567] pcieport a000:00:00.0: enabling device (0106 -> 0107)
[    2.655875] pcieport a000:00:00.0: AER enabled with IRQ 24
[    2.661445] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
rserial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42, base_baud = 33333333) is a 16550A
[    2.681148] console [ttyS0] enabled
[    2.681148] console [ttyS0] enabled
[    2.688069] bootconsole [udbg0] disabled
[    2.688069] bootconsole [udbg0] disabled
[    2.696040] serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 42, base_baud = 33333333) is a 16550A
[    2.705190] console [ttyS0] disabled
[    2.708811] console [ttyS0] enabled
[    2.712565] ffe04600.serial: ttyS1 at MMIO 0xffe04600 (irq = 42, base_baud = 33333333) is a 16550
[    2.722481] Disabling lock debugging due to kernel taint
[    2.722487] fsl-lbc ffe05000.localbus: Chip select error: LTESR 0x00080000
[    2.734643] Machine check in kernel mode.
[    2.738637] Caused by (from MCSR=10008): 
[    2.738640] Bus - Read Data Bus Error
[    2.746282] Oops: Machine check, sig: 7 [#1]
[    2.750535] BE SMP NR_CPUS=2 P2020 RDB
[    2.754272] Modules linked in:
[    2.757319] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G   M            4.14.180 #0
[    2.764610] task: ef448000 task.stack: ef450000
[    2.769125] NIP:  c02995d0 LR: c028f240 CTR: c02995b0
[    2.774161] REGS: effe3f10 TRAP: 0204   Tainted: G   M             (4.14.180)
[    2.781276] MSR:  00029000 <CE,EE,ME>  CR: 24000282  XER: 00000000
[    2.787449] DEAR: f1200000 ESR: 00800000 
[    2.787449] GPR00: c028f524 ef451c20 ef448000 ef451c34 ef49c91c 00000020 ef451cc8 ef451cc8 
[    2.787449] GPR08: 00000002 00000002 f1200000 00000002 24000282 00000000 c049ae20 c049a00c 
[    2.787449] GPR16: c049ad84 c049adc0 c049add8 ef48f158 00000000 c049ad50 ef49c910 01000000 
[    2.787449] GPR24: c049a000 00000000 00000000 00000000 00000000 00000022 00000002 ef49c91c 
[    2.824804] Call Trace:
[    2.827240] [ef451c20] [ef451cd0] 0xef451cd0 (unreliable)
[    2.832625] [ef451c60] [c028f524] 0xc028f524
[    2.836882] [ef451c80] [c028e3dc] 0xc028e3dc
[    2.841138] [ef451cc0] [c02991a8] 0xc02991a8
[    2.845394] [ef451d40] [c028e2b8] 0xc028e2b8
[    2.849651] [ef451d60] [c029993c] 0xc029993c
[    2.853907] [ef451de0] [c0273138] 0xc0273138
[    2.858164] [ef451df0] [c02715b8] 0xc02715b8
[    2.862420] [ef451e20] [c02717f4] 0xc02717f4
[    2.866676] [ef451e40] [c026f634] 0xc026f634
[    2.870933] [ef451e70] [c0270a88] 0xc0270a88
[    2.875189] [ef451e90] [c0272158] 0xc0272158
[    2.879446] [ef451ea0] [c0003140] 0xc0003140
[    2.883702] [ef451f00] [c04d8b40] 0xc04d8b40
[    2.887959] [ef451f30] [c00032d0] 0xc00032d0
[    2.892215] [ef451f40] [c00103b0] 0xc00103b0
[    2.896470] Instruction dump:
[    2.899427] 48000008 0fe00000 7c0004ac 4e800020 81240018 8144000c 2f890001 40be000c 
[    2.907163] 7d2a28ae 48000028 2f890002 40be000c <7d2a2a2e> 48000018 2f890004 409e000c 
[    2.915079] ---[ end trace c9ea2fa8a0ac4ace ]---
[    2.920341] 
[    3.911837] Kernel panic - not syncing: Fatal exception
[    3.917450] Rebooting in 1 seconds..

Is there something wrong I’m doing? Or is this a bug upstream?

Software offload doesn’t work when custom routing table used:
How to examine:

# create ipset
ipset create IPNET hash:net
ipset add IPNET 139.59.209.225/32
# check ipset
ipset list IPNET
...
Number of entries: 1
Members:
139.59.209.225

# mark packets with dst to IPNET
iptables -t mangle -A PREROUTING -i br-lan -m set –match-set IPNET dst -j MARK –set-mark 0×1111 iptables -t mangle -A OUTPUT -m set –match-set IPNET dst -j MARK –set-mark 0×1111

# add custom routing table for marked packets
ip ru add fwmark 0×1111 lookup 8888 prio 10000

# add route for custom table 8888
ip route add default via 192.168.30.1 table 8888

# enable flow offload in /etc/config/firewall
config defaults

....
option flow_offloading '1'

/etc/init.d/firewall reload

check iptables:
Chain FORWARD (policy DROP 0 packets, 0 bytes)

  pkts      bytes target     prot opt in     out     source               destination         
    24     1947 forwarding_rule  all  --  any    any     anywhere             anywhere             /* !fw3: Custom forwarding rule chain */
    22     1819 FLOWOFFLOAD  all  --  any    any     anywhere             anywhere             /* !fw3: Traffic offloading */ ctstate RELATED,ESTABLISHED FLOWOFFLOAD
    22     1819 ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED /* !fw3 */
     2      128 zone_lan_forward  all  --  br-lan any     anywhere             anywhere             /* !fw3 */
     0        0 zone_wan_forward  all  --  pppoe-wan any     anywhere             anywhere             /* !fw3 */
     0        0 zone_wan_forward  all  --  l2tpv3-hetzner any     anywhere             anywhere             /* !fw3 */
     0        0 zone_wan_forward  all  --  wg0    any     anywhere             anywhere             /* !fw3 */
     0        0 reject     all  --  any    any     anywhere             anywhere             /* !fw3 */

But packets with RELATED,ESTABLISHED don’t use custom routing (it seems what flowoffload don’t remember custom routing and try to send packets on table main). When I add manually custom route to main table - flow offload work again

- Device problem occurs on - x86
- Software versions of OpenWrt/LEDE release, packages, etc. - 19.07.3

I think it’s a bug/overlooked use case, but when you have interfaces bridged in the UCI config, the MTU setting does not get applied to the member interfaces (physical or VLAN).

config interface 'lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.1.1'
        option type 'bridge'
        option mtu '9000'
        option ifname 'eth1 eth4.10'

When I boot using this config I have connectivity issues with devices using Jumbo frames. ifconfig confirms that MTUs on the members interfaces are still at default 1500.

eth1      Link encap:Ethernet  HWaddr 0C:C4:7A:AB:39:3D
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:df440000-df45ffff

eth4      Link encap:Ethernet  HWaddr 3C:FD:FE:BB:01:50
          inet6 addr: fe80::3efd:feff:febb:150/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500 Metric:1
          RX packets:50176 errors:0 dropped:1 overruns:0 frame:0
          TX packets:37468 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:15692679 (14.9 MiB)  TX bytes:29263711 (27.9 MiB)

eth4.10   Link encap:Ethernet  HWaddr 3C:FD:FE:BB:01:50
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:36728 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20850 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9314410 (8.8 MiB)  TX bytes:26473088 (25.2 MiB)

I have to manually use the ifconfig tool to set the MTU (i.e. ifconfig eth4.10 mtu 9000) to get the network back up and running correctly.

Obviously these commands could be scritped, however it was my understanding the UCI network config should be doing this .

Model: TP-Link Archer C7 v2
Architecture: Qualcomm Atheros QCA9558 ver 1 rev 0
Firmware Version :OpenWrt 19.07.2 r10947-65030d81f3 / LuCI openwrt-19.07 branch git-20.155.55664-f35803e
Kernel Version: 4.14.171

root@router:/tmp/run# uci show wireless | grep log
wireless.radio0.log_level='3'
wireless.radio1.log_level='3'
root@router:/tmp/run# cat hostapd-phy* | grep log
logger_syslog=127
logger_syslog_level=3
logger_stdout=127
logger_stdout_level=3
logger_syslog=127
logger_syslog_level=3
logger_stdout=127
logger_stdout_level=3
root@router:/tmp/run# hostapd_cli -i wlan0 log_level
Current level: INFO
Timestamp: 0
root@router:/tmp/run# hostapd_cli -i wlan1 log_level
Current level: INFO
Timestamp: 0
root@router:/tmp/run# hostapd_cli -i wlan1-1 log_level
Current level: INFO
Timestamp: 0
root@router:/tmp/run# hostapd_cli -i wlan1-1 log_level 2
FAIL
root@router:/tmp/run# opkg list-installed | grep hostapd
hostapd-common - 2019-08-08-ca8c2bd2-4
hostapd-utils - 2019-08-08-ca8c2bd2-4
root@router:/tmp/run# opkg list-installed | grep wpad
wpad - 2019-08-08-ca8c2bd2-4

Hello, I have a problem with the loglevel of hostapd. However the loglevel get ignored by the daemon and even the direct manipulation over hostapd_cli failed. Because of this the syslog get spammed by all the info messages.
It is predefined here: https://github.com/openwrt/openwrt/blob/openwrt-19.07/package/network/services/hostapd/Config.in But I don’t know why it is unchangeable at all

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

Hostname OpenWrt
Model Linksys WRT1900ACS
Architecture ARMv7 Processor rev 1 (v7l)
Firmware Version OpenWrt 19.07.3 r11063-85e04e9f46 / LuCI openwrt-19.07 branch git-20.136.49537-fb2f363
Kernel Version 4.14.180

At the outset, there are two VLANs pre-existing: 1 (LAN) and 2 (WAN)
In LuCi, create the following VLANs: 10, 20, 21, 2200, 2204, 2208, 3000.

At that point, I created a new VLAN on the Network/Switch page in LuCi. The new VLAN had an initial default VID of 10, which I changed to 11. I set the tagging to my need (Tagged on CPU and LAN port 3, off on all other ports) without touching the other nine VLANs.

As soon as I hit Save & apply, VLAN 10 stopped working entirely.

Examining the configuration files, I find these two stanzas:

config switch_vlan

option device 'switch0'
option vlan '3'
option ports '5t 1t'
option vid '10'

. . .

config switch_vlan

option device 'switch0'
option vlan '10'
option ports '5t 1t'
option vid '11'

This leads me to the hypothesis that the “vlan” option of 10 is colliding with the “vid” option of 10 on another VLAN, though it seems like these should be separate, unrelated concepts.

My workaround was to redo my VLAN scheme so that former VLANs 10, 11, 20 and 21 are now 1000, 1100, 2000 and 2100 respectively, which was enough to prevent this collision, and it all works, but it seems like it should not have had the collision in the first place.

Imagebuilder is unable to detect gcc/g++ on my system running gcc 10.1 FORCE=1 makes no difference, and seems to be ignored.

[naguz@blaptop openwrt-imagebuilder-19.07.2]$ make image FORCE=1 PROFILE=tplink_archer-c7-v2 FILES=files/
Checking 'working-make'... ok.
Checking 'case-sensitive-fs'... ok.
Checking 'proper-umask'... ok.
Checking 'gcc'... failed.
Checking 'working-gcc'... ok.
Checking 'g++'... failed.
Checking 'working-g++'... ok.
Checking 'ncurses'... ok.
Checking 'perl-thread-queue'... ok.
Checking 'tar'... ok.
Checking 'find'... ok.
Checking 'bash'... ok.
Checking 'patch'... ok.
Checking 'diff'... ok.
Checking 'cp'... ok.
Checking 'seq'... ok.
Checking 'awk'... ok.
Checking 'grep'... ok.
Checking 'getopt'... ok.
Checking 'stat'... ok.
Checking 'unzip'... ok.
Checking 'bzip2'... ok.
Checking 'wget'... ok.
Checking 'perl'... ok.
Checking 'python3-cleanup'... ok.
Checking 'python'... ok.
Checking 'git'... ok.
Checking 'file'... ok.
Checking 'ldconfig-stub'... ok.

Build dependency: Please install the GNU C Compiler (gcc) 4.8 or later
Build dependency: Please install the GNU C++ Compiler (g++) 4.8 or later

Prerequisite check failed. Use FORCE=1 to override.
make[1]: *** [Makefile:87: staging_dir/host/.prereq-build] Error 1
make: *** [Makefile:197: image] Error 2
[gert@blad openwrt-imagebuilder-19.07.2]$ 

Device is Dlink DIR615C1 running 19.07 doesn’t respond to pings. Device has been reset to factory defaults, but doesn’t respond to pings.

ifconfig shows no RX packets and no RX bytes on eth0 interface.

root@OpenWrt:/# ifconfig
br-lan Link encap:Ethernet HWaddr 00:22:B0:BA:50:1F

        inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:0 errors:0 dropped:0 overruns:0 frame:0
        TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000
        RX bytes:0 (0.0 B)  TX bytes:378 (378.0 B)

eth0 Link encap:Ethernet HWaddr 00:22:B0:BA:50:1F

        UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
        RX packets:0 errors:0 dropped:0 overruns:0 frame:0
        TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000
        RX bytes:0 (0.0 B)  TX bytes:1475 (1.4 KiB)
        Interrupt:4

Same DIR615C1 running 18.06.08 works fine.

If I compile the current snapshot with the 18.06.8 code from ar8216.c, ar8216.h, ar8327.c and ar8327.h (the last two were required because of compilation errors), the snapshot image with the older 18.06.8 ar8216 drivers works fine.

There are significant changes in the way the ar8216 is initialized and setup from 18.06.8 to 19.07.1 and the latter code is not reading incoming packets because RX packets and RX bytes are always 0.

Code found in

target/linux/generic/files/drivers/net/phy

Details at

https://forum.openwrt.org/t/lan-doesnt-work-in-19-07-2-custom-build/61945/

I’m using Linksys wrt3200 as router behind cable modem with a dslite configuration and Devolo 1200+ DinRail connected to one of the LAN ports.

Previuos configuration was provider cable modem connected to Devolo and it was working fine (up to 50-100 mbit up and download to all DLAN devices.

After swiching to Linksys and OpenWRT I noticed that download speed for IPv4 dropped to 2-3 MBit for all devices. Upload and IPv6 work fine.

Thought it was dslite problem but provider router works fine and if I connect to Linksys directly via WLAN the download speed is as expected...

Repatched with Linksys stock firmware without changing anything else stable up and download speeds in expected range for ip4/ip6.

Patched openwrt back - ipv4 download drop to 2Mbit, back to stock back to normal speed...

Assume it’s potentially an MTU setting for LAN interface but all values I tried did not change much...

Would appreciate any help. Would be pity to fall back to stock but if it’s the only option...

I have two devices that show the same problem - both TP-Link, but different models.
The problem is that the devices/clients connected to any of the wlans are always isolated no matter what the config “isolate clients” is set to.
These devices cannot ping and see each other but they can be pinged and they can ping devices from/to devices in lan.

Further more the generated /var/run/hostapd-phy0.conf and /var/run/hostapd-phy1.conf always have the ap_isolate=1

The tested devices are:

root@OpenWrt:~# ubus call system board
{
        "kernel": "4.14.180",
        "hostname": "OpenWrt",
        "system": "Qualcomm Atheros QCA9558 ver 1 rev 0",
        "model": "TP-Link Archer C7 v2",
        "board_name": "tplink,archer-c7-v2",
        "release": {
                "distribution": "OpenWrt",
                "version": "19.07.3",
                "revision": "r11063-85e04e9f46",
                "target": "ath79/generic",
                "description": "OpenWrt 19.07.3 r11063-85e04e9f46"
        }
}

root@OpenWrt:~# ubus call system board
{
        "kernel": "4.14.180",
        "hostname": "OpenWrt",
        "system": "Atheros AR9344 rev 2",
        "model": "TP-Link TL-WDR4300 v1",
        "board_name": "tplink,tl-wdr4300-v1",
        "release": {
                "distribution": "OpenWrt",
                "version": "19.07.3",
                "revision": "r11063-85e04e9f46",
                "target": "ath79/generic",
                "description": "OpenWrt 19.07.3 r11063-85e04e9f46"
        }
}

No packages have been updated manually on both devices.
Both devices has defaults sets coming with the default factory OpenWrt 19.07.3 image.
Both devices were set for their Network → Wireless → wlan0 (and wlan1) → Interface configuration → Advanced settings → Isolate clients UNCHECKED

Here is the config of one of the devices (/etc/config/wireless) and the respective generated /var/run/hostapd-phy0.conf

config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/ahb/18100000.wmac'
	option channel 'auto'
	option country 'BG'
	option htmode 'HT20'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option key 'XXXXXX'
	option ssid 'YYYYYYYY'
	option encryption 'psk2'

Even when option isolate ‘0’ is added manually using uci not luci, and restarting the device the respective hostapd-phy0.conf remains with ap_isolate=1

driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=BG
ieee80211d=1
hw_mode=g
beacon_int=100
channel=acs_survey



ieee80211n=1
ht_coex=0
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]

interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
wpa_passphrase=XXXXXX
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=YYYYYYYY
bridge=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=xx:xx:xx:xx:xx:xx

My guess is that hostapd/wpad doesn’t set properly the ap_isolate according to the config.

Please let me know if you need further info.

Thanks

Edimax 3G-6200n OpenWrt 19.07.2, r10947-65030d81f3

Steps:
1. Download the latest version OpenWrt 19.07.2 to Edimax 3G-6200n.
2. Set e.g. the password to the router and/or turn on the WiFi.
3. Reboot the router with the reboot option in OpenWrt.
4. The router has no settings previously saved - the status is as right after installing fresh OpenWRT - no password, no WiFi enabled, default settings.

Problem with JFFS.

root@OpenWrt:~# mount
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /tmp/root type tmpfs (rw,noatime,mode=755)
overlayfs:/tmp/root on / type overlay (rw,noatime,lowerdir=/,upperdir=/tmp/root/upper,workdir=/tmp/root/work)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.0M      3.0M         0 100% /rom
tmpfs                    13.8M    284.0K     13.5M   2% /tmp
tmpfs                    13.8M     60.0K     13.7M   0% /tmp/root
overlayfs:/tmp/root      13.8M     60.0K     13.7M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev

root@OpenWrt:~# free
              total        used        free      shared  buff/cache   available
Mem:          28276       14008        5224         344        9044       11872
Swap:             0           0           0
#here I added the password and turned on the WiFi network - the free RAM decreased
root@OpenWrt:~# free
              total        used        free      shared  buff/cache   available
Mem:          28276       15632        3496         368        9148       10236
Swap:             0           0           0
root@OpenWrt:~#

One example is iptables-mod-tproxy. It is available in 19.07.0, but not in 19.07.1. This causes dependency issue when installing some packages.
How to reproduce:

# opkg install shadowsocks-libev-ss-rules
Installing shadowsocks-libev-ss-rules (3.2.5-5) to root...
Downloading http://downloads.openwrt.org/releases/19.07.1/packages/aarch64_cortex-a53/packages/shadowsocks-libev-ss-rules_3.2.5-5_aarch64_cortex-a53.ipk
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for shadowsocks-libev-ss-rules:
 *      iptables-mod-tproxy
 * opkg_install_cmd: Cannot install package shadowsocks-libev-ss-rules.

I reproduced it on aarch64_coretex_a53, but I see it’s missing for other platforms like a72 and x86_64, too.

It was reported here: https://github.com/openwrt/packages/issues/11457 But was closed and the maintainer said it belongs here.

RTL8723BU USB module ID 0bda:b720 does not work with kmod-rtl8xxxu driver and rtl8723bu-firmware
Bluetooth scanning does not see any device.
Module cannot be loaded.

[ 8893.763180] usb 1-1.4: This Realtek USB WiFi dongle (0x0bda:0xb720) is untested!
[ 8894.291851] usb 1-1.4: Firmware revision 35.0 (signature 0×5301)
[ 8894.564319] usb 1-1.4: Firmware failed to start
[ 8894.568980] rtl8xxxu: probe of 1-1.4:1.2 failed with error -11
[ 8894.575434] usbcore: registered new interface driver rtl8xxxu

In both openwrt-15.05.1-ar71xx-generic-wzr-600dhp-squashfs-tftp.bin and openwrt-19.07.3-ar71xx-generic-wzr-600dhp-squashfs-sysupgrade.bin USB did not work. Power was available at the USB port, but plugging in various USB devices did absolutely nothing. I had to install kmod-usb-ohci to make USB start working.

I feel this is a bug because in 19.07.3 kmod-usb-ehci is already installed. So, one might think that required USB modules are there and something is wrong.

I tried both USB 1.1 and 2.0 high speed devices before. The ohci module is required even to use USB 2.0 high speed devices.

Device: Linksys WRT32X
OpenWRT version: OpenWrt 19.07.3 r11063-85e04e9f46

The LAN/WAN link LEDs seem to be incorrectly assigned in OpenWRT (offset by 1):

- LAN Port 1 link results in no LED lighting
- LAN Ports 2-4 light LAN link LEDs 1-3 respectively
- WAN port lights LAN LED 4

The WAN LED is assigned to the correct (and default) interface (eth1) in LUCI. The rest of the LEDs are not configurable, leading me to believe the issue is with indexing of the LEDs themselves, as opposed to LED-Port assignment.

Supply the following if possible:
- Device problem occurs on TP-Link Archer C7 v5
- Software versions of OpenWrt/LEDE release, packages, etc.

OpenWrt 19.07.3 r11063-85e04e9f46 / LuCI openwrt-19.07 branch git-20.136.49537-fb2f363
ds-lite 7-4

- Steps to reproduce: install system, install ds-lite, the mtu for all dslite connections will be [1280|https://github.com/openwrt/openwrt/blob/master/package/network/ipv6/ds-lite/files/dslite.sh#L66] by default.

Because of it, if a VPN with ipv6 is used over ipv4, it’s completely broken.

tun0 w/ ipv6 -> [vpn client -> [dslite with mtu 1280] -> vpn server] -> private network

As far as I see, it should be relatively easy to make default MTU autoconfigurable with parent’s MTU-x (where 30 is 30, if I’m right)

I am using default build of OpenWRT 19.07.4 for TL-WR841N v13 without any additional packages. I have Ethernet PPPoE from provider, some ethernet and WiFi WPA2 clients. WiFi and Ethernet are unstable: they can disappear for 30-60 seconds without any serious reason. On 18.06.8 there wasn’t those problems. I attached system log. Thanks for help.

Hi,

I am using the following with the latest update of openwrt:

Model Netgear R6220
Architecture MediaTek MT7621 ver:1 eco:3
Firmware Version OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.260.30581-915a64c
Kernel Version 4.14.195

The problem occured already with 19.07.3 several times, so I upgraded to 19.07.4, but the problem remains.
The wifi module kept crashing and in consequence a part of the wifi devices cannot connect anymore. Sometimes the router
recovers by itself, sometimes not and a reboot is necessary to get wifi working again. It mostly affects the 2,4 GHz band
and not the 5 GHz band, but that might be related which device is renewing DHCP or which ones are not (I am not sure).
A reboot solves the problem, but after some time, the problem occurs again. After the below warning, the router runs without
further problems for 2 days now. So it seems pretty rare. Nevertheless, the same hardware was working fine with 18.x
openwrt for a year at least. No kernel warning at the time. I cannot completely rule out that the HW is broken as it is
of age, as you can see. Any hint on what I should report or test myself is welcome! I can help debug and even install
updates that should fix the problem, if necessary. The router ist just used as an access point - routing is taking
place elsewhere.

Here is the korresponding kernel warning, where I included the immediate log entries before and after:

Thu Sep 17 22:02:05 2020 daemon.notice hostapd: wlan1: DFS-RADAR-DETECTED freq=5680 ht_enabled=1 chan_offset=-1 chan_width=2 cf1=5670 cf2=0
Thu Sep 17 22:02:05 2020 daemon.notice hostapd: wlan1: DFS-NEW-CHANNEL freq=5220 chan=44 sec_chan=1
Thu Sep 17 22:02:05 2020 daemon.info hostapd: wlan1: IEEE 802.11 driver starting channel switch: freq=5220, ht=1, vht_ch=0×0, offset=1, width=2 (40 MHz), cf1=5230, cf2=0
Thu Sep 17 22:02:05 2020 daemon.notice hostapd: wlan1: CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5220 ht_enabled=1 ch_offset=1 ch_width=40 MHz cf1=5230 cf2=0 dfs=0
Thu Sep 17 22:02:06 2020 daemon.info hostapd: wlan1: IEEE 802.11 driver had channel switch: freq=5220, ht=1, vht_ch=0×0, offset=1, width=2 (40 MHz), cf1=5230, cf2=0
Thu Sep 17 22:02:06 2020 daemon.notice hostapd: wlan1: CTRL-EVENT-CHANNEL-SWITCH freq=5220 ht_enabled=1 ch_offset=1 ch_width=40 MHz cf1=5230 cf2=0 dfs=0
Thu Sep 17 22:02:06 2020 daemon.notice hostapd: wlan1: AP-CSA-FINISHED freq=5220 dfs=0
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.685439] ————[ cut here ]———— Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.694747] WARNING: CPU: 1 PID: 14 at backports-4.19.137-1/net/mac80211/tx.c:4292 0x877acbc4 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.716632] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_netlink nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT slhc nfnetlink 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_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport 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
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.858467] usbcore nls_base usb_common
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.866285] CPU: 1 PID: 14 Comm: ksoftirqd/1 Not tainted 4.14.195 #0
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.878915] Stack : 00000000 00000000 00000000 86dae9b0 00000000 00000000 00000000 00000000
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.895548] 00000000 00000000 00000000 00000000 00000000 00000001 87c67b70 53261622
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.912178] 87c67c08 00000000 00000000 00006298 00000038 8049c858 00000008 00000000
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.928810] 00000000 80550000 000d37ed 00000000 87c67b50 00000000 00000000 877e7fd0
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.945442] 877acbc4 000010c4 86f0a480 86dae9b0 00000003 802ad210 00000004 806b0004
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.962073] ...
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.966931] Call Trace:
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.966973] [<8049c858>] 0x8049c858
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.978757] [<877acbc4>] 0x877acbc4 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.990532] [<802ad210>] 0x802ad210
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7457.997462] [<8000c1a0>] 0x8000c1a0
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.004393] [<8000c1a8>] 0x8000c1a8
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.011325] [<804856b4>] 0x804856b4
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.018260] [<877acbc4>] 0x877acbc4 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.030029] [<80072a84>] 0x80072a84
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.036956] [<8002e608>] 0x8002e608
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.043892] [<877acbc4>] 0x877acbc4 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.055668] [<8002e6f0>] 0x8002e6f0
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.062600] [<80053b7c>] 0x80053b7c
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.069536] [<877acbc4>] 0x877acbc4 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.081310] [<877af408>] 0x877af408 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.093086] [<80067ca8>] 0x80067ca8
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.100018] [<80017f6c>] 0x80017f6c
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.106957] [<87777b90>] 0x87777b90 [mt76x02_lib@87770000+0×9700]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.119081] [<877af86c>] 0x877af86c [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.130870] [<87777bd0>] 0x87777bd0 [mt76x02_lib@87770000+0×9700]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.142999] [<877b65e0>] 0x877b65e0 [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.154789] [<877b66bc>] 0x877b66bc [mac80211@87780000+0x6cca0]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.166573] [<87774a94>] 0x87774a94 [mt76x02_lib@87770000+0×9700]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.178702] [<800329f4>] 0x800329f4
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.185630] [<804a3658>] 0x804a3658
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.192561] [<8004fd10>] 0x8004fd10
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.199494] [<8004fd10>] 0x8004fd10
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.206420] [<80032cc8>] 0x80032cc8
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.213348] [<8004feb8>] 0x8004feb8
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.220280] [<8049ebd8>] 0x8049ebd8
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.227208] [<8004bf38>] 0x8004bf38
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.234139] [<8004be08>] 0x8004be08
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.241070] [<8004be08>] 0x8004be08
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.248002] [<8004be08>] 0x8004be08
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.254933] [<80006f78>] 0x80006f78
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.261870]
Thu Sep 17 22:02:06 2020 kern.warn kernel: [ 7458.265166] —[ end trace 9a8b15fbb768cb19 ]— Thu Sep 17 22:02:06 2020 daemon.notice hostapd: wlan1: STA 6c:ad:f8:f1:5a:4b IEEE 802.11: did not acknowledge authentication response
Thu Sep 17 22:02:06 2020 daemon.notice hostapd: wlan1: STA 6c:ad:f8:f1:5a:4b IEEE 802.11: did not acknowledge authentication response

When you edit `/etc/config/https-dns-proxy` and set a custom server, not known to Luci HTML interface, the Luci UI at /cgi-bin/luci/admin/services/https-dns-proxy will display “CIRA Canadian Shield (Family)” as the selected resolver. This, by itself is not a problem yet, as the Proxy will function as expected.

However, the moment one makes any changes in the UI, e.g. changing listen port, `/etc/config/https-dns-proxy` will get rewritten and an actual resolver for CIRA Canadian Shield (Family) will be used.

Luci interface for HTTPS DNS Proxy should:

1. Bare minimum: indicate a custom resolver is used, and not lose the resolver after making changes to listen port and other stuff.
1. Nice to have: Allow a user to define a custom resolver in the UI - by specifying `resolver_url`, `bootstrap_dns`, `user` and `group` properties

The problem applies on any device as it’s not device-specific.

Reproduction instruction:

1. Edit `/etc/config/https-dns-proxy` and make it look like this:

```
config main ‘config’

      option update_dnsmasq_config '-'

config https-dns-proxy

      option listen_addr '127.0.0.1'
      option listen_port '5054'
      option user 'nobody'
      option group 'nogroup'
      option bootstrap_dns '1.1.1.1,1.0.0.1,2606:4700:4700::1111,2606:4700:4700::1001'
      option resolver_url 'https://1.1.1.1/dns-query'

```
2. Go to http://192.168.10.1/cgi-bin/luci/admin/services/https-dns-proxy and observe “CIRA Canadian Shield (Family)” as the selected resolver.
3. Change listen port and click Save & Apply.
4. Observe `/etc/config/https-dns-proxy` lose `resolver_url` setting.

Supply the following if possible:
- Device problem occurs on
netgear r6350
- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01
I installed ocserv too but I don’t think its the problem
- Steps to reproduce
Just let router run, maybe will stay up for a week and then at some point gui tells me can’t fork, I can’t login to router with ssh and I have to power cycle it.

I added swap space on a USB stick to try to keep it from locking up.
I’ve ssh’ed into and run the following to try to figure out what’s going on.

I expected to find a process growing but nothing looks obvious to me. I just see free memory keep going down, and I see a bit of swap space used.

Any suggestions on what else I could do to figure out what’s going on with the memory usage?

looking at meminfo it shows about ~100M used but the numbers don’t seem to add up to that.

while sleep 60
do
  date
  uptime
  top -b -n 1 | head -n 10
  ps w | awk '$3 > 4000'
  free -m
  cat /proc/meminfo
  printf "\n"
done

Here’s what 10 days looks like:

Wed Sep 30 00:56:16 EDT 2020
 00:56:16 up 10 days,  2:38,  load average: 0.00, 0.02, 0.00
Mem: 100276K used, 23496K free, 1076K shrd, 1832K buff, 4600K cached
CPU:   0% usr   0% sys   0% nic 100% idle   0% io   0% irq   0% sirq
Load average: 0.01 0.02 0.00 2/71 27832
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
27831  7096 root     R     1224   1%   0% top -b -n 1
 2175  2174 root     S     4912   4%   0% ocserv-sm
 2174     1 root     S     4740   4%   0% ocserv-main
  931     1 root     S     2324   2%   0% /sbin/rpcd -s /var/run/ubus.sock -t 30
 2001     1 root     S     1784   1%   0% /usr/sbin/hostapd -s -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
 1077     1 root     S     1748   1%   0% /sbin/netifd
  PID USER       VSZ STAT COMMAND
 2174 root      4740 S    ocserv-main
 2175 root      4912 S    ocserv-sm
              total        used        free      shared  buff/cache   available
Mem:         123772       93796       23544        1076        6432        2604
Swap:        262140        1024      261116
MemTotal:         123772 kB
MemFree:           23500 kB
MemAvailable:       2560 kB
Buffers:            1832 kB
Cached:             4600 kB
SwapCached:          232 kB
Active:             5184 kB
Inactive:           3364 kB
Active(anon):       1120 kB
Inactive(anon):     2072 kB
Active(file):       4064 kB
Inactive(file):     1292 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         123772 kB
LowFree:           23500 kB
SwapTotal:        262140 kB
SwapFree:         261116 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          1960 kB
Mapped:             2136 kB
Shmem:              1076 kB
Slab:              11756 kB
SReclaimable:       1912 kB
SUnreclaim:         9844 kB
KernelStack:         624 kB
PageTables:          308 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      324024 kB
Committed_AS:       6680 kB
VmallocTotal:    1040376 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB

Hi,

I would like to submit a feature/enhancement request more than a bug request.

Supply the following if possible:
- Device problem occurs on
tested on xiaomi mi wifi 3G v1 (https://openwrt.org/toh/hwdata/xiaomi/xiaomi_miwifi_3g)
but probably occuring for all devices
- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt 19.07.4
- Steps to reproduce
1/ upgrade to last stable firmware, so currently 19.07.4
2/ try to download the sysupgrade image
cd /tmp; wget –no-check-certificate “https://downloads.openwrt.org/releases/19.07.4/targets/ramips/mt7621/openwrt-19.07.4-ramips-mt7621-xiaomi_mir3g-squashfs-sysupgrade.bin” wget: SSL support not available, please install one of the libustream-.*[ssl|tls] packages as well as the ca-bundle and ca-certificates packages.

Since a few month, upgrade images have to be downloaded with https, because http requests are now redirected to https.
I also think that redirecting to https, can be a good idea.

Extract of https://openwrt.org/docs/guide-user/installation/sysupgrade.cli :
Download and check the firmware checksum with:
cd /tmp;wget $DOWNLOAD_LINK;wget $SHA256SUMS;sha256sum -c sha256sums 2>/dev/null|grep OK

When applied to my device and last stable release :
cd /tmp; wget –no-check-certificate “https://downloads.openwrt.org/releases/19.07.4/targets/ramips/mt7621/openwrt-19.07.4-ramips-mt7621-xiaomi_mir3g-squashfs-sysupgrade.bin” wget: SSL support not available, please install one of the libustream-.*[ssl|tls] packages as well as the ca-bundle and ca-certificates packages.

As discussed in forum (https://forum.openwrt.org/t/problem-downloading-openwrt-release-to-router-using-wget/63805), there are alternatives.

But, it’s a pain (at least not user friendly) to install a package, in order to download a new image to flash.
Can you add an ssl package to the default packages list ?

Another option is to permit download on http, but may not be the best idea.

I agree about the fact, that adding a package to all images is not so easy and maybe impossible due to space disk considerations.

As an openwrt user, I appreciate all the work, you are doing. Thank you for that project.

Regards,
Serge

Just flashed 19.07.4 on Kingston MLWG2.

Followed online procedure found (copy image to SD card, touch special file, login via telnet on stock firmware, write image, reboot device) to flash OpenWRT.

After flash, device “seems” stuck dead (all leds are on, wired network irresponsive, no WiFi AP detected).

I have opened the device, soldered the serial console pins and accessere via serial console.

Device is actually booting perfectly, but both wired and wifi are not accessible.

1. I have WiFi enabled by setting “disabled = 0” in /etc/config/wireless to OpenWrt AP

2. I have Wired enabled by adding “option iface “eth0”” to the “lan” interface in /etc/config/network

3. Device now works great

Without these two changes, the device is as good as dead.

This is a peculiar device: only 1 ethernet port and 2.4Ghz Wifi. My guess something is wrong in the vlan/bridge/switch settings?

I hope a fix can be commited somehow so that future users do not end up with a dead-like device.

Supply the following if possible:
- Device problem occurs on: TP-Link WDR3600
- Software versions of OpenWrt/LEDE release, packages, etc.: OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01

LEDs of switch0 are missing in board definition thus missing in LuCi web interface on ath79 target.

Booting openwrt-19.07.4-ar71xx-mikrotik-rb-nor-flash-16M-ac-initramfs-kernel.bin via tftp. Relevant dmesg chunk at driver load demonstrating that only 2.4GHz interface is detected:

Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257636] ath: EEPROM regdomain: 0×0 Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257643] ath: EEPROM indicates default country code should be used
Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257646] ath: doing EEPROM country→regdmn map search
Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257659] ath: country maps to regdmn code: 0x3a
Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257663] ath: Country alpha2 being used: US
Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.257666] ath: Regpair used: 0x3a
Tue Sep 8 07:29:00 2020 kern.debug kernel: [ 10.274863] ieee80211 phy0: Selected rate control algorithm ‘minstrel_ht’ Tue Sep 8 07:29:00 2020 kern.info kernel: [ 10.276460] ieee80211 phy0: Atheros AR9550 Rev:0 mem=0xb8100000, irq=47

Supply the following if possible:
- Device problem occurs on mt7621
- Software versions of OpenWrt 19.07.03 19.07.04
- Steps to reproduce
first: select map-e support on menuconfig Network→map
select luci support on menuconfig Luci
second: update firmware, and then loggin to 192.168.1.1, network - interface - proto MAP/LW4over6
and error occur when click config apply

- Happens on all x86 targets
- Happens with trunk and 19.07.4
- To reproduce, run ip a in any x86 machine with an ath9k-compatible (mini-)PCIE wifi card installed. You will note that no relevant wireless interface is found.

Although this issue concerns the kmod-ath9k driver, it is not about the code itself; rather, the build system and the packaged modules.

Recently I tried to run OpenWRT on x86_64 machine that has an AR9462 mini-pcie wifi card installed.
Although lspci detected the card, no drivers were loaded for it, and the wireless interface does not show up with the ip command, even with the ath9k drivers installed.

I have found out that this is because support for PC OEM cards are not enabled by default. As a result, I had to build my own copy of OpenWRT from scratch with that option specifically turned on.
And even then, with matching versions (19.07.4), my install of OpenWRT complained that the package built had a different kernel version. I was unsure why, but I wasn’t interested in finding out and I simply forced the install.

I believe that the support for PC OEM cards for ath9k should be turned on by default for the x86 builds of the driver. People running OpenWRT on x86 are unlikely to run into serious space constraints.
Kindly consider my suggestion.

I have a BT Humehub 5A with a Huawei E3372 dongle, used purely for a backup for my VDSL connection, so only tested every few months, I noticed with 19.07.03 it wasn’t working, so I upgraded to 19.07.04 and it’s still not working.

It seems to initially “see” the dongle, then fail to talk to it

root@hh5a:~# dmesg|grep -i usb
[    0.374109] usbcore: registered new interface driver usbfs
[    0.379680] usbcore: registered new interface driver hub
[    0.385095] usbcore: registered new device driver usb
[    1.651958] USB_VBUS: disabling
[    3.779353] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found, using dummy regulator
[    3.786491] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found, using dummy regulator
[    3.794916] dwc2 1e101000.usb: dwc2_core_reset() HANG! AHB Idle GRSTCTL=0
[    4.001788] dwc2 1e101000.usb: DWC OTG Controller
[    4.005122] dwc2 1e101000.usb: new USB bus registered, assigned bus number 1
[    4.012215] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[    4.018987] hub 1-0:1.0: USB hub found
[   11.543311] usbcore: registered new interface driver cdc_wdm
[   11.902165] usbcore: registered new interface driver usbserial
[   11.906895] usbcore: registered new interface driver usbserial_generic
[   11.913296] usbserial: USB Serial support registered for generic
[   11.994648] usbcore: registered new interface driver cdc_ncm
[   12.039432] usbcore: registered new interface driver huawei_cdc_ncm
[   15.249532] usb 1-1: new high-speed USB device number 2 using dwc2
[   16.453533] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[   16.645469] usb 1-1: new high-speed USB device number 3 using dwc2
[   16.650389] dwc2 1e101000.usb: NYET/NAK/ACK/other in non-error case, 0x00000002
[   16.657632] dwc2 1e101000.usb: NYET/NAK/ACK/other in non-error case, 0x00000002
[   16.664934] dwc2 1e101000.usb: NYET/NAK/ACK/other in non-error case, 0x00000002
[   16.672397] dwc2 1e101000.usb: NYET/NAK/ACK/other in non-error case, 0x00000002
[   16.679561] dwc2 1e101000.usb: NYET/NAK/ACK/other in non-error case, 0x00000002
[   16.686865] dwc2 1e101000.usb: NYET/NAK/ACK/other in non-error case, 0x00000002
[   16.694339] dwc2 1e101000.usb: NYET/NAK/ACK/other in non-error case, 0x00000002
[   16.701495] dwc2 1e101000.usb: NYET/NAK/ACK/other in non-error case, 0x00000002
[   16.708802] dwc2 1e101000.usb: NYET/NAK/ACK/other in non-error case, 0x00000002
[   17.366922] usbcore: registered new interface driver option
[   17.371364] usbserial: USB Serial support registered for GSM modem (1-port)
[   17.925693] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
[   17.931060] usb usb1-port1: attempt power cycle

Normally it would use /dev/ttyUSB0 but as a result of the above erros, no USB tty devices exist

root@hh5a:~# ls /dev/tty*
/dev/tty      /dev/ttyLTQ0

In OpenWrt 19.07.4, ip from busybox can modify IPv6 routes in any table but it cannot show them. ip-full does not have any issues any issues:

# busybox ip -6 route add fdac:9818:b256:fe::6 dev wireguard table 22
# busybox ip -6 route show table 22
# ip -6 route show table 22 # ip form ip-full
fdac:9818:b256:fe::6 dev wireguard metric 1024 pref medium

It is not target specific. Tested with x86_64 and ath79

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

And the DHCP Server doesn’t work any more!

My route is below:

主机名 OpenWrt
型号 UBNT-ERX
架构 MediaTek MT7621 ver:1 eco:3
固件版本 OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01
内核版本 4.14.195
本地时间 2020-10-27 10:04:52

Model Xiaomi Mi Router 3G
Architecture MediaTek MT7621 ver:1 eco:3
Firmware Version OpenWrt 19.07.3 r11063-85e04e9f46 / LuCI openwrt-19.07 branch git-20.136.49537-fb2f363

2 wireguard tunnels, average load 0.7, constantly transferring around 50Mbps. What to do?

[11093.040136] ————[ cut here ]———— [11093.044786] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:320 0x8038ba10
[11093.051827] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
[11093.058754] 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 wireguard 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
[11093.130344] 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 ip_gre gre ip6_udp_tunnel udp_tunnel ipip tunnel4 ip_tunnel leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd gpio_button_hotplug usbcore nls_base usb_common
[11093.177365] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.180 #0
[11093.183431] Stack : 00000000 00000000 00000000 8fe9f540 00000000 00000000 00000000 00000000
[11093.191767] 00000000 00000000 00000000 00000000 00000000 00000001 8fc0bd60 1cc28254
[11093.200102] 8fc0bdf8 00000000 00000000 00006480 00000038 8049c0d8 00000008 00000000
[11093.208454] 00000000 80550000 0002b4d5 00000000 8fc0bd40 00000000 00000000 8050ae44
[11093.216791] 8038ba10 00000140 00000001 8fe9f540 00000000 802accb0 00000004 806b0004
[11093.225127] ...
[11093.227562] Call Trace:
[11093.227577] [<8049c0d8>] 0x8049c0d8
[11093.233476] [<8038ba10>] 0x8038ba10
[11093.236946] [<802accb0>] 0x802accb0
[11093.240418] [<8000c1a0>] 0x8000c1a0
[11093.243889] [<8000c1a8>] 0x8000c1a8
[11093.247357] [<80484f34>] 0x80484f34
[11093.250830] [<80071a90>] 0x80071a90
[11093.254301] [<8002e608>] 0x8002e608
[11093.257770] [<8038ba10>] 0x8038ba10
[11093.261244] [<8002e690>] 0x8002e690
[11093.264714] [<800550e8>] 0x800550e8
[11093.268183] [<8038ba10>] 0x8038ba10
[11093.271656] [<80099940>] 0×80099940 [11093.275127] [<8038b864>] 0x8038b864
[11093.278596] [<8008850c>] 0x8008850c
[11093.282067] [<8005f1fc>] 0x8005f1fc
[11093.285536] [<800887c8>] 0x800887c8
[11093.289004] [<800790f8>] 0x800790f8
[11093.292481] [<804a2ed8>] 0x804a2ed8
[11093.295955] [<80032fb4>] 0x80032fb4
[11093.299422] [<8025a2f0>] 0x8025a2f0
[11093.302894] [<80007488>] 0×80007488 [11093.306362]
[11093.307906] —[ end trace 1eeab0d01990d637 ]— [11093.312528] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[11093.318683] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[11093.324685] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=0ebc0000, max=0, ctx=639, dtx=639, fdx=638, next=639
[11093.335184] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=0df60000, max=0, calc=1798, drx=1799
[11093.347900] mtk_soc_eth 1e100000.ethernet: 0×100 = 0x6060000c, 0x10c = 0×80818 [11093.360558] mtk_soc_eth 1e100000.ethernet: PPE started
[36804.131736] conntrack: generic helper won’t handle protocol 47. Please consider loading the specific helper module.
[51119.838502] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[51119.844705] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[51119.850717] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=0de70000, max=0, ctx=2403, dtx=2403, fdx=2402, next=2403
[51119.861557] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=0bc40000, max=0, calc=2683, drx=2684
[51119.874059] mtk_soc_eth 1e100000.ethernet: 0×100 = 0x6060000c, 0x10c = 0×80818 [51119.886726] mtk_soc_eth 1e100000.ethernet: PPE started
[89229.695179] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[89229.701380] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[89229.707395] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=0ed30000, max=0, ctx=836, dtx=836, fdx=835, next=836
[89229.717886] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=0bf30000, max=0, calc=3466, drx=3467
[89229.730663] mtk_soc_eth 1e100000.ethernet: 0×100 = 0x6060000c, 0x10c = 0×80818 [89229.743335] mtk_soc_eth 1e100000.ethernet: PPE started
[113529.605540] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[113529.611808] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[113529.617908] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=0bf30000, max=0, ctx=2724, dtx=2724, fdx=2723, next=2724
[113529.628843] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=0bde0000, max=0, calc=3154, drx=3155
[113529.641841] mtk_soc_eth 1e100000.ethernet: 0×100 = 0x6060000c, 0x10c = 0×80818 [113529.654635] mtk_soc_eth 1e100000.ethernet: PPE started

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

OpenWRT 19.07.4 on xRX200 rev 1.2 (BT Home Hub 5A) with all packages up to date.
After running the router for a while I’ll try to login to the page and get this error:
/usr/lib/lua/luci/dispatcher.lua:426: /etc/config/luci seems to be corrupt, unable to find section ‘main’

This would normally be accompanied with the 5GHz channel set to 149 (which is a paid-for channel in the UK).
Checking /etc/config/luci looks fine to me and sometimes service rcpd restart works but other times it leaves Luci in an unusable state.

Supply the following if possible:
- Device problem occurs on

Ubiquiti EdgeRouterX

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

Linux OpenWrt 4.14.195 #0 SMP Sun Sep 6 16:19:39 2020 mips GNU/Linux

- Steps to reproduce

I’m not doing anything specific. This reported instance happend over night when
I was sleeping. I do have the flow offload (the HW variant) enabled.

Here is output from logread:

Sat Nov  7 03:26:00 2020 [1604719560.750] kern.alert kernel: [30317.854831] CPU 3 Unable to handle kernel paging request at virtual address 002dd990, epc == 8ef60384, ra == 8ef603ac
Sat Nov  7 03:26:00 2020 [1604719560.750] kern.warn kernel: [30317.875985] Oops[#1]:
Sat Nov  7 03:26:00 2020 [1604719560.750] kern.warn kernel: [30317.880503] CPU: 3 PID: 25 Comm: kworker/3:0 Not tainted 4.14.195 #0
Sat Nov  7 03:26:00 2020 [1604719560.750] kern.warn kernel: [30317.893151] Workqueue: events_power_efficient 0x8ef27304 [xt_FLOWOFFLOAD@8ef27000+0xc10]
Sat Nov  7 03:26:00 2020 [1604719560.750] kern.warn kernel: [30317.909245] task: 8fc7aca0 task.stack: 8fc96000
Sat Nov  7 03:26:00 2020 [1604719560.750] kern.warn kernel: [30317.918246] $ 0   : 00000000 00000001 002dd962 00000001
Sat Nov  7 03:26:00 2020 [1604719560.750] kern.warn kernel: [30317.928644] $ 4   : 002dd962 8fc97e4f 8fc97e4f ffff00fe
Sat Nov  7 03:26:00 2020 [1604719560.751] kern.warn kernel: [30317.939044] $ 8   : 8fc97fe0 00007c00 00001b92 00000001
Sat Nov  7 03:26:00 2020 [1604719560.751] kern.warn kernel: [30317.949443] $12   : 00000154 8f2e9c80 ffffffff 00001844
Sat Nov  7 03:26:00 2020 [1604719560.751] kern.warn kernel: [30317.959843] $16   : 8fc97e4f 8ef27000 00000000 fffffff5
Sat Nov  7 03:26:00 2020 [1604719560.751] kern.warn kernel: [30317.970243] $20   : 8056bba0 00000001 000000c0 fffffffe
Sat Nov  7 03:26:00 2020 [1604719560.751] kern.warn kernel: [30317.980643] $24   : 3b9aca00 80008e34
Sat Nov  7 03:26:00 2020 [1604719560.751] kern.warn kernel: [30317.991042] $28   : 8fc96000 8fc97df0 80550000 8ef603ac
Sat Nov  7 03:26:00 2020 [1604719560.751] kern.warn kernel: [30318.001441] Hi    : 0000000a
Sat Nov  7 03:26:00 2020 [1604719560.751] kern.warn kernel: [30318.007159] Lo    : 66666669
Sat Nov  7 03:26:00 2020 [1604719560.751] kern.warn kernel: [30318.012885] epc   : 8ef60384 0x8ef60384 [nf_flow_table@8ef60000+0x3350]
Sat Nov  7 03:26:00 2020 [1604719560.751] kern.warn kernel: [30318.026051] ra    : 8ef603ac 0x8ef603ac [nf_flow_table@8ef60000+0x3350]
Sat Nov  7 03:26:00 2020 [1604719560.752] kern.warn kernel: [30318.039203] Status: 11007c03     KERNEL EXL IE
Sat Nov  7 03:26:00 2020 [1604719560.752] kern.warn kernel: [30318.047529] Cause : 40800008 (ExcCode 02)
Sat Nov  7 03:26:00 2020 [1604719560.752] kern.warn kernel: [30318.055495] BadVA : 002dd990
Sat Nov  7 03:26:00 2020 [1604719560.752] kern.warn kernel: [30318.061211] PrId  : 0001992f (MIPS 1004Kc)
Sat Nov  7 03:26:00 2020 [1604719560.752] kern.warn kernel: [30318.069346] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT 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_mangle iptable_filter ip_tables crc_ccitt nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 leds_gpio gpio_button_hotplug
client_loop: send disconnect: Broken pipe

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

Device problem occurs on

Software versions of OpenWrt/LEDE release, packages, etc

  option type 'mac80211'
  option channel '36'
  option hwmode '11a'
  option path 'pci0000:00/0000:00:00.0'
  option htmode 'HT20'
  option country 'PL'

  option device 'radio1'
  option network 'lan'
  option mode 'ap'
  option auth_server '192.168.1.X'
  option auth_port '1812'
  option auth_secret password
  option ssid 'name'
  option encryption 'wpa2+ccmp'
  option wpa_disable_eapol_key_retries '1'
  option ieee80211w '2'
  option disassoc_low_ack '0'

Steps to reproduce

Hi !

I’m using a Huwei E160E 3G dongle with Openwrt 19.07.4. I configured 3G connexion following this guide : https://openwrt.org/docs/guide-user/network/wan/wwan/3gdongle

All works OK as long as I do not reboot the router. After reboot 3g interface says “Error : network device is not present”

I have to ssh and do network restart to get it working again. As a workaround I added sleep 30; /etc/init.d/network restart to /etc/rc.local

According to dmesg I would think the 3g stick is detected after networking start. The log is in attachment.

I tested on two routers : Gl.inet AR-150 and TP-Link Tl-WR3600. Both had the same behavior.

Please let me know if I can help.

Kind Regards,

Ed.

Premise:

Getting there:

Issue:

[identical part removed]
VARIANT:=wpad-basic

[identical part removed]
DEPENDS+=@PACKAGE_kmod-cfg80211 @(!TARGET_uml||BROKEN)
PROVIDES+=wpa-supplicant-mesh wpad-mesh
DEPENDS+=+libopenssl
VARIANT:=wpad-mesh-openssl

[identical part removed]
DEPENDS+=@PACKAGE_kmod-cfg80211 @(!TARGET_uml||BROKEN)
PROVIDES+=wpa-supplicant-mesh wpad-mesh
DEPENDS+=+libwolfssl
VARIANT:=wpad-mesh-wolfssl

Upgrading OpenWRT from 18.06 to 19.07 on a couple of Alfa wireless devices (N2Q and Tube2H) and on Ubiquiti PicoStation M2, observed the following behavior in arp-scan:

Before upgrade (in 18.06):

# arp-scan -I br-lan -l
Interface: br-lan, datalink type: EN10MB (Ethernet)
WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/ieee-oui.txt: No such file or directory
WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/ieee-iab.txt: No such file or directory
WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/mac-vendor.txt: No such file or directory
Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan)
172.22.47.1 de:9f:db:05:46:5d (Unknown)
172.22.47.53 00:24:8c:9d:1d:92 (Unknown)
172.22.47.77 0c:ef:af:c4:f5:b5 (Unknown)
172.22.47.111 3c:2a:f4:b8:25:c2 (Unknown)
172.22.47.116 00:02:d1:43:e8:5b (Unknown)
172.22.47.102 5c:e0:c5:67:1a:e2 (Unknown)
172.22.47.186 00:c0:ca:8d:4d:2c (Unknown)
172.22.47.108 00:40:8c:a5:e8:03 (Unknown)
172.22.47.130 00:40:8c:be:b0:73 (Unknown)
172.22.47.161 d8:c4:97:e0:30:d1 (Unknown)
172.22.47.108 00:40:8c:a5:e8:03 (Unknown) (DUP: 2)
172.22.47.130 00:40:8c:be:b0:73 (Unknown) (DUP: 2)
172.22.47.132 2c:aa:8e:9a:3a:94 (Unknown) (DUP: 1)
172.22.47.161 d8:c4:97:e0:30:d1 (Unknown) (DUP: 2)

14 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.5: 256 hosts scanned in 1.804 seconds (141.91 hosts/sec). 14 responded

After upgrade (in 19.07):

# arp-scan -I br-lan -l
Interface: br-lan, datalink type: EN10MB (Ethernet)
WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/ieee-oui.txt: No such file or directory
WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/ieee-iab.txt: No such file or directory
WARNING: Cannot open MAC/Vendor file /usr/share/arp-scan/mac-vendor.txt: No such file or directory
Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan)

20 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.5: 256 hosts scanned in 1.823 seconds (140.43 hosts/sec). 0 responded

Note that, while arp-scan has not changed version, libpcap1 has rev’ed from libpcap1 - 1.9.0-2 to libpcap1 - 1.9.1-2.1

To reproduce:

Connect a device running one of the 18.06 releases (I’m specifically using r9137-0465e41) and run arp-scan on an active network. Then connect a device running 19.07.4 and run arp-scan on the same network.

Model Xiaomi Mi Router AC2100
Architecture MediaTek MT7621 ver:1 eco:3
Firmware Version OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01
Kernel Version 4.14.195

Random BUG, no step to reproduce it exactly
Impact : Outage for few seconds, connectivity lost
Full log attached.

Regards

Hello. Let me explain because i I could not explain myself better in the summary.

The router is a Cisco LinkSys E3000 https://openwrt.org/toh/linksys/e3000 It have installed the build 19.07.4, made to this target, but i have this issue with older ones.

First to make some context:

I want the router for simple task, mainly to make it work with OpenWRT and not much else, as it’s an old router. But i found some issue i didn’t have with other routers i have with OpenWRT (Two AR5381u and one HG556a). Compared with these other ones i have with the same configuration (as a repeater), i only have 0.5Mb/s when with the other ones i have easily between 5-10 or more, depending how crowded the wifi spectrum are.
But this is not the main issue, the main issue is if i try to use the 5Ghz radio, it suddenly reboots. In fact the first time i use it, i config the 5Ghz radio and it kept in a reboot cycle which you can’t reset or do anything unless you inject via serial or doing a shortcircuit. All of this is explained in the forums to add that OpenWRT wiki, as it’s is an issue with this router AND the driver b43 (Possibly this issue has been reported already here but it was closed), and that’s what i did (I added two motherboard photos too to the wiki). Also i have other issue when i bring back it to life but i can’t reproduce it anymore so i don’t want to bother with it.

To summarizing the tests i made with the router: With b43 driver, radio0 is detected as “b/g” and it works, radio1 is detected as “a” but if i made a scan or i try to do something with it, the router reboots (if i save any config it keeps in the reboot cycle forever). With the brcmsmac driver, radio0 is labeled as b/g/n and works (but i used it to make an access point and seems a bit slow), and radio1 as b/g but it doesn’t find anything if i search access points. With broadcom-wl, it creates wl0 and wl1, both labeled as b/g, but both doesn’t find all the access points which found the other drivers, wl1 only finds one what is one meter from the router (and it doesn’t show channel numbers), but suddenly both radios didn’t find anymore access points (i don’t know why).

Getting to the point:

Doing the documentation, i found something, but i don’t know it’s wrong or not. The documentation says that this router have a Broadcom BCM4718 (b/g/n) and a Broadcom BCM4322 (a/n), which i asume these are radio0 and radio1 (i don’t know what is each one, and i don’t know how to see that).

However, looking for information, i did some research, and the LuCI overview said Broadcom 4716. Also a lspci shows this:

# lspci -nn
00:00.0 Host bridge [0600]: Broadcom Inc. and subsidiaries BCM47xx Sentry5 USB Host Controller [14e4:4716] (rev 01)
00:00.1 Host bridge [0600]: Broadcom Inc. and subsidiaries Device [14e4:0000] (rev 01)
00:01.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4322 802.11bgn Wireless Network Controller [14e4:4322] (rev 01)

If you look the photos you can see the BCM4322 near the three ANT5Gx connectors, and there is other one in the other side near the ANT2Gx connectors below the heat, sink but is impossible to remove it without breaking the board, so i can’t see the number.

Also, in the System Log and the Kernel Log, there isn’t any reference to any 4718 (attached files).

I see this important, because the features for 4716 and 4718 are very different regarding to the 2.4Ghz/5Ghz, and the 4322 is detected as bgn (as seen in the lspci).

I want to point this out to be sure because maybe the issues this router have are related to a misinformation when building the target, or maybe the documentation is wrong and only need to be fixed and any of the issues is related to this. I have little knowledge about this in general, but maybe all of these triggers some of you something.

Thanks in advance.

Can’t connect to dropbear after upgrading to Fedora 33

Using: OpenSSH_8.4p1, OpenSSL 1.1.1h FIPS 22 Sep 2020

Adding “PubkeyAcceptedKeyTypes=+ssh-dss” to $.ssh/config Hosts section solves the issue.

May be related to this: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication

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

With the latest release of OpenWrt (19.07.4) using a VLAN > 16 fails. It’s rather strange as this was a problem years ago with the RTL8366s switch on these devices. I verified the firmware is reporting itself as 19.07.4 (I wondered if the files got mixed up and I was using some 18.xx version due to issues with the download site, but that is not the case).

As long as the VLAN/VID are below 16 everything works properly, but for a VLAN > 16 (regardless of whether one keeps the VLAN ⇐ 16 and only sets the VID to the actual VLAN (e.g. to match a switch into which the WNDR3800 is plugged).
For now I’ve just been disabling the switch and configuring software VLAN and letting the other switch sort out tagging/untagging.

I did some experimenting and it looks like the switch config has had some kind of weird regression.

I don’t have a spare device (and am not set up for developing / building OpenWrt at the moment), so this is more of placeholder bug until someone with resources (device / time / etc) can work on it.

On a separate note: is GitHub login deliberately disabled, or is it only me that’s having logging in with GitHub – basically is this deliberate/known or should I file a separate bug for that?

The listed config below is running fine on 19.07 till 19.07.3. From 19.07.4 on the throughput to peers on the tagged VLANs falls below 10Mbit/s. Seems there is some regression introduced on 19.07.4.

Sample config:

config interface 'ff_dhcp'
	option proto 'static'
	option ifname 'eth0.30'
	option ipaddr '10.36.164.65/27'

config interface 'mgmt'
	option proto 'static'
	option ifname 'eth0.42'
	option ipaddr '10.36.190.177/28'

config switch_vlan
	option device 'switch0'
	option vlan '30'
	option ports '0t 3 4'

config switch_vlan
	option device 'switch0'
	option vlan '42'
	option ports '0t 3t 4t'

* Note:
As essedma has some bugs i cannot use switchport, which is hardcoded to VLAN2. But i’m fine with just leaving it as it is.

Description:

I have 3 WIFI access points (2x Netgear WNDR4300, 1x Netgear WNDR3700v2) running 19.07.4 r11208-ce6496d796. Each of those APs has a 2.4 and a 5 GHz band. For each of the 2 radios I have defined 2 SSIDs: Home-net and Guest-net.

So each AP has a total of 4 WIFI interfaces:

• Home-net @ 2.4 GHz
• Home-net @ 5 GHz
• Guest-net @ 2.4 GHz
• Guest-net @ 5 GHz

All the WIFI interfaces of the same SSID are bridged together into a separate VLAN.

802.11r is configured identically on all 4 WIFI interfaces. I'm using a very simple FT config that generates the keys locally based on the pre-shared key and I let most of the required settings to be generated automatically.

Now, my problem is that fast-transitioning works for the Home-net, but not for the Guest-net.
Home-net roaming is really working great and as expected. I can fast-transition between the radio cells of the same AP (2.4GHz ⇔ 5GHz) as well as fast-transition between the cells of the different APs.

However fast-transitioning of the Guest-net on the other hand is not working at all. Even though it is essentially using the same configuration as the Home-net.
I already tried to provide explicit values for some of the relevant, generated 802.11r settings like NASID and Mobility-Domain, but that does not seem to make any difference.
I also did a test to see what happens, if I delete the 2 working Home-net interfaces. Well, once they are deleted, fast transitioning via the 2 remaining Guest-net interfaces started to work. I could easily roam between the 2.4 and 5 GHz networks of the modified AP.
Given the fact that the previously defunct Guest-net network becomes functional tells me that my network configuration and my 802.11r configuration are not the problem here.

How to reproduce:

precondition: a dual band AP with 19.07.04
1. set up 2 wifi networks for each radio
2. enable hostapd debug mode for both radios
3. connect with a mobile device to the first SSID and try to roam between the bands
4. check the systemlog for FT messages
result: fast transitioning is working for the first SSID
5. connect with a mobile device to the second SSID and try to roam between the bands
6. check the systemlog for FT messages
result: fast transitioning is not working for the second SSID
expected result: fast transitioning is working for both/all SSIDs.

wireless config

config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11g'
	option path 'platform/ar934x_wmac'
	option country 'DE'
	option legacy_rates '0'
	option htmode 'HT20'
	option log_level '1'
	option channel '11'
	option txpower '17'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11a'
	option path 'pci0000:00/0000:00:00.0'
	option country 'DE'
	option legacy_rates '0'
	option htmode 'HT40'
	option log_level '1'
	option channel '36'    

## home-net 2.4 GHz
config wifi-iface 'default_radio0'
	option device 'radio0'
	option mode 'ap'
	option network 'WIFI-HOME'
	option encryption 'psk2+ccmp'
	option key '***redacted***'
	option ssid 'home-net'
	option macfilter 'allow'
	list maclist '***redacted***'
	option wpa_disable_eapol_key_retries '1'
	option ieee80211r '1'
	option ft_psk_generate_local '1'
	option ft_over_ds '0'
	option max_inactivity '30'

## home-net 5 GHz
config wifi-iface 'default_radio1'
	option device 'radio1'
	option mode 'ap'
	option network 'WIFI-HOME'
	option encryption 'psk2+ccmp'
	option key '***redacted***'
	option ssid 'home-net'
	option macfilter 'allow'
	list maclist '***redacted***'
	option wpa_disable_eapol_key_retries '1'
	option ieee80211r '1'
	option ft_psk_generate_local '1'
	option ft_over_ds '0'
	option max_inactivity '30'

## guest-net 2.4 GHz
config wifi-iface 'wifinet2'
	option device 'radio0'
	option mode 'ap'
	option network 'WIFI-GUEST'
	option encryption 'psk2+ccmp'
	option key '***redacted***'
	option ssid 'guest-net'
	option wpa_disable_eapol_key_retries '1'
	option ieee80211r '1'
	option ft_psk_generate_local '1'
	option ft_over_ds '0'
	option max_inactivity '30'

## guest-net 5 GHz
config wifi-iface 'wifinet3'
	option device 'radio1'
	option mode 'ap'
	option network 'WIFI-GUEST'
	option encryption 'psk2+ccmp'
	option key '***redacted***'
	option ssid 'guest-net'
	option wpa_disable_eapol_key_retries '1'
	option ieee80211r '1'
	option ft_psk_generate_local '1'
	option ft_over_ds '0'
	option max_inactivity '30'

Issue occurs on WNDR3700 v1
Image used openwrt-19.07.4-ath79-generic-netgear_wndr3700-squashfs-sysupgrade.bin

Steps:

1, Flash the above sysupgrade image.
2, Configure luci as required, all settings are saved as expected and survive any number of reboots as expected.
3, Use luci System/Backup Flash Firmware/Reset to Defaults (Perform Reset) to clear the current configuration.
4, Post reset any changes applied to config/settings within luci no longer survive a reboot. The luci configuration returns to the default post-flash position after each reboot.

Issue is reproducible.

Workaround is to reflash and avoid using the reset functionality.