All Projects

IDCategoryTask TypePrioritySeveritySummaryReported InStatus
 1597 Base systemBug ReportVery LowMedium Missing FLOWOFFLOAD target in iptables packages TrunkClosed Task Description

Affected package


Affected architectures, maybe not exclusive:


mipsel_mips32 was used for testing this issue.

Issue description

The iptables command as shipped in *.ipk packages does not support the FLOWOFFLOAD target.
This target should be contained in the library, but is not there.
I can only reproduce this issue with the provided ipk‘s, not by building them myself.
Complete firmware images are not affected either.

Steps to reproduce (alternatives)

  1. use existing firmware image
    • install trunk firmware image
    • reinstall the libxtables package from an ipk
    • iptables -A FORWARD -j FLOWOFFLOAD
    • error output: iptables v1.6.2: Couldn’t load target `FLOWOFFLOAD’:No such file or directory
  2. imagebuilder
    • use the imagebuilder to create a firmware image
    • install it
    • iptables -A FORWARD -j FLOWOFFLOAD
    • error output as above
  3. binary inspection
    • extract files: tar xzf libxtables_1.6.2-2_mipsel_mips32.ipk ./data.tar.gz -O | tar xzv
    • strings usr/lib/ | grep FLOWOFFLOAD
    • error case: no output
    • good output would be:
      FLOWOFFLOAD target options:

Previous attempts to fix the issue

I submitted a patch to increment the iptables package version, which was accepted into master as commit c84ef1f. As a result, the buildbots rebuilt the packages with the new version, but still containing the same binary without FLOWOFFLOAD support.

 1576 Base systemBug ReportVery LowLow Regression: device model reported as "unknown" TrunkClosed Task Description


18.06 and trunk


  • tested on Asus WL500W (brcm47xx)
  • other devices may be affected

Problem description

The device model is now reported as “unknown”, while LEDE 17.01 still showed “Asus WL500W”.

Steps to reproduce

  • in LuCI, navigate to the start page (Status→Overview), or
  • in the shell, execute
    ubus call system board

The problem was introduced with

commit 78cf5eed6edaa38561e9c9c3ff14a36c1eedfadd
Author:     Mathias Kresin <>
AuthorDate: Fri Apr 7 18:01:17 2017 +0200

    treewide: do board detection during preinit
 793 Base systemBug ReportVery LowLow Power LED flickers on Linksys WRT54GSv1, making it unsu ...AllClosed Task Description

This devices’ Power LED has two states: solid on, or flickering (when it should be off), which makes it hard to tell when to press the Reset button for failsafe mode.
I verified this again by toggling GPIO 1 with the leds_gpio module unloaded.

Please use the DMZ LED instead, where both on and off states are solid.


 792 Base systemBug ReportVery LowLow Reset button not working on Linksys WRT54GSv1 AllClosed Task Description

Pressing the Reset button has no effect on the Linksys WRT54GSv1.

A short press should cause the device to reboot, and a long press should cause a factory reset. With the following script added, there should be a log entry for each button press and release:

root@LEDE:~# cat /etc/hotplug.d/button/buttons
logger "button $BUTTON $ACTION"

None of these effects can be observed on the Linksys WRT54GSv1, running either the LEDE master branch or the 17.01.1 release.

This is caused by a resource conflict for GPIO 6, which is claimed by both the adm6996 switch driver and the gpio_button_hotplug kernel module.

gpio-keys gpio-keys.0: unable to claim gpio 6, err=-16
gpio-keys: probe of gpio-keys.0 failed with error -16

After unbinding the switch driver:

echo adm6996_gpio > /sys/bus/platform/drivers/adm6996_gpio/unbind

the gpio_button_hotplug module can be loaded without error, and the Reset button works.

The switch driver requests this GPIO for the switch chip’s RC pin, but never uses it, so it can be safely disabled.

I could come up with two possible solutions: replace the nvram entry gpio6=adm_rc to point to an unused GPIO, or patch the switch driver to not request the adm_eerc GPIO. I consider the nvram modification more risky and prefer the latter solution. What do you think?


 790 Base systemBug ReportVery LowLow Failsafe mode networking is broken on Linksys WRT54GSv1 TrunkClosed Task Description

Networking in failsafe mode is currently broken on the Linksys WRT54GSv1. The UDP message about entering failsafe mode is missing, and the device does not answer ping or SSH connection attempts to while in failsafe mode. This issue exists both in the LEDE master branch and in the 17.01.1 release.

It can be fixed by removing the following files:


and rebuilding the firmware. This fix was tested on the master branch.

Do these files still have a purpose? They seem to be obsoleted by


and the device works fine without them.

How to reproduce:
The easiest way to trigger failsafe mode on this device is probably through a serial console.
There are unrelated issues with both the Power LED and the Reset button which I had to fix before I was able to enter failsafe mode. I’ll report these separately.


 484 OtherBug ReportVery LowLow Image Builder generates broken image for ASUS WL500W lede-17.01Closed Task Description

Software Revision

LEDE 17.01.0-rc2



Issue description

An image generated with the Image Builder can be booted only once after flashing it. On the second and further boot attempts, the device stays in the bootloader.

The OpenWrt 15.05.1 Image Builder is not affected. The official 17.01.0-rc2 image also works fine.

I wonder if the following Image Builder message hints at the problem:

WARNING: maxlen exceeds default maximum!  Beware of overwriting nvram!

The Image Builder result is actually smaller than the official image, 3608576 vs. 4001792 bytes.

Steps to reproduce

  • Use Debian Jessie amd64 or another suitable host system
  • Unpack lede-imagebuilder-17.01.0-rc2-brcm47xx-legacy.Linux-x86_64.tar.xz
  • Within the Image Builder directory: make image PROFILE=asus-wl-500w
  • Copy this resulting image to the device:
  • sysupgrade -n -v *.trx
  • Wait for automatic reboot, wait another 3 minutes
  • ssh root@
  • Check dmesg for “jffs2 [...] complete” message, or wait until it appears
  • reboot

The device is now stuck in the bootloader, power-cycling does not help.

I can do further tests if necessary.


 31 Base systemBug ReportVery LowLow firewall3 fails to reload iptables policy extension TrunkClosed Task Description

* Source revision:
LEDE Reboot (HEAD, r607)

* Affected device:
Tested on TP-LINK TD-W8980 and on a x86 VM. This issue is likely device-independent.

* Issue description:
In firewall3, the iptables extension only works for the first (address family; table) combination and fails for all subsequent ones. Where it fails, the firewall rules containing the policy match are missing, and a warning is printed instead.
This is a regression from OpenWrt CHAOS CALMER (15.05.1).

* Steps to reproduce:

###download and install firmware image lede-lantiq-xrx200-TDW8980-squashfs-sysupgrade.bin
# fw3 -d restart
Result: firewall rules as expected

# opkg install iptables-mod-ipsec
# uci set “firewall.@zone[0].extra_src=-m policy –dir in –pol none” # uci set “firewall.@zone[0].extra_dest=-m policy –dir out –pol none” # fw3 -d restart
- firewall rules with “-m policy” are missing in all tables except IPv4 filter.
- repeated output: Warning: fw3_ipt_rule_append(): Can’t find match ‘policy’

* What you have already done to fix the problem / Any additional info you think is important

My experiments seem to confirm that this is caused by missing dlclose support in musl libc.
firewall3 uses dlclose/dlopen to reload iptables extensions for each address family and table,
and it expects the extensions’ constructor functions to be called each time.
In musl, dlclose does nothing, and unloading/reloading of a shared library does not call its constructor function again.
To check my theory, I added explicit calls to the extensions’ _init() functions via dlsym.
This made the policy match work again in all tables, but then firewall3 hangs on exit (tested with LEDE r289).
I don’t now if it is actually allowed to call dynamic library constructor functions explicitly.

Then I considered a more complex solution, but have no code for it yet.
In short:
- split off xtables/iptc-related functions from iptables.c to run in a child process
- an RPC-like mechanism based on pipes, to call these functions
- terminate and recreate the child process at each fw3_ipt_close/fw3_ipt_open

However, I would like to hear your opinion first how this bug should best be solved.
If you want to work on this yourself, I’ll step back and watch.


Showing tasks 1 - 7 of 7 Page 1 of 1

Available keyboard shortcuts


Task Details

Task Editing