validate.c uses inet_pton for identifying IPv6 addresses [1], and this seems to not understand interface identifiers as used for Link-local IPv6 addresses.

Reproduce:

root@FFF-GW-Adrian:~# /sbin/validate_data host fdff::1
host - fdff::1 = true
root@FFF-GW-Adrian:~# /sbin/validate_data host fe80::1
host - fe80::1 = true
root@FFF-GW-Adrian:~# /sbin/validate_data host fe80::1%br-mesh
host - fe80::1%br-mesh = false

This is a problem practically whenever validata_data is used to check uci values.

For example, it is not possible to use a link-local address for specifying an NTP server:

https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/sysntpd#L33

If ‘server:list(host)’ is changed to ‘server:list(string)’ there, it obviously works fine, as it’s just the validation.

[1] https://git.openwrt.org/?p=project/ubox.git;a=blob;f=validate/validate.c;h=e72b8117ecd8b680778b0f5c7637ed6546a7736b;hb=HEAD#l402

uclient-fetch has support for downloading several files:

uclient-fetch URL1 URL2 URL3 ...

However, this only works for the first two URLs. The third and above URLs simply cause uclient-fetch to re-download the second URL again.

In addition, only the first URL is checked for validity. If a subsequent URL is invalid, then the previous URL is re-used:

uclient-fetch http://example.com invalid

This example will download http://example.com twice.

The target/install target does not produce the *squashfs-factory.bin and *squashfs-sysupgrade.bin binaries if the images are too big to fit the selected flash size.
However, make doesn’t say a word to the user but simply does not produce the files. The user has to either check the mtime of the files if they were created earlier or use

make target/install V=s

to derive what’s wrong.
According to jow on IRC this is just an artifact of no way to bypass silent mode. That might be the common explanation but it is still a bug from my POV.

When you set the MTU of a ppp interface with proto=pppoe and ifname=nas0 via the mtu option,
the configured mtu will not be set on the ppp interface (what you want), but on the
underlying interface named by ifname (what you normally don’t want to change).

This leeds to log messages like this:

pppd[5641]: Interface nas0 has MTU of 1448 – should be at least 1500.

and MTUs other than what you really want.

example:

desired PPPoE MTU: 1448
actual nas0 MTU: 1448
actual PPPoE MTU: 1440

This issue seems to be related to the commit 7ac29b75319fd69a8a7c0aeea7804d381ec07d3d of netifd.

Regards,
Martin

Bind-mounting /tmp/resolv.conf.auto apparently doesn’t forward inotify events arriving from the kernel when resolv.conf.auto was changed (e.g. upstream DNS servers were received by a DHCP client or pppd). Restarting dnsmasq or running it without ujail solves the issue.

This problem was reported by few Netgear R8000 users and I managed to reproduce it. It’s related to the following code:

		vht_cap=$(iw phy "$dev" info | grep -c 'VHT Capabilities')
		cap_5ghz=$(iw phy "$dev" info | grep -c "Band 2")
		[ "$vht_cap" -gt 0 -a "$cap_5ghz" -gt 0 ] && {
			mode_band="a";
			channel="36"
			htmode="VHT80"
		}

Default htmode

root@lede:/# iw phy phy2 info
Wiphy phy2
        max # scan SSIDs: 10
        max scan IEs length: 2048 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Device supports roaming.
        Available Antennas: TX 0 RX 0
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * P2P-client
                 * P2P-GO
                 * P2P-device
        Band 2:
                Capabilities: 0x1062
                        HT20/HT40
                        Static SM Power Save
                        RX HT20 SGI
                        RX HT40 SGI
                        No RX STBC
                        Max AMSDU length: 3839 bytes
                        DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 16 usec (0x07)
                HT TX/RX MCS rate indexes supported: 0-23
                VHT Capabilities (0x0c025820):
                        Max MPDU length: 3895
                        Supported Channel Width: neither 160 nor 80+80
                        short GI (80 MHz)
                        SU Beamformer
                        SU Beamformee
                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: MCS 0-9
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT RX highest supported: 0 Mbps
                VHT TX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: MCS 0-9
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT TX highest supported: 0 Mbps
                Frequencies:
                        * 5170 MHz [34] (disabled)
                        * 5180 MHz [36] (20.0 dBm)
                        * 5190 MHz [38] (disabled)
                        * 5200 MHz [40] (20.0 dBm)
                        * 5210 MHz [42] (disabled)
                        * 5220 MHz [44] (20.0 dBm)
                        * 5230 MHz [46] (disabled)
                        * 5240 MHz [48] (20.0 dBm)
                        * 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
                        * 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
                        * 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
                        * 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
                        * 5500 MHz [100] (20.0 dBm) (no IR, radar detection)
                        * 5520 MHz [104] (20.0 dBm) (no IR, radar detection)
                        * 5540 MHz [108] (20.0 dBm) (no IR, radar detection)
                        * 5560 MHz [112] (20.0 dBm) (no IR, radar detection)
                        * 5580 MHz [116] (20.0 dBm) (no IR, radar detection)
                        * 5600 MHz [120] (20.0 dBm) (no IR, radar detection)
                        * 5620 MHz [124] (20.0 dBm) (no IR, radar detection)
                        * 5640 MHz [128] (20.0 dBm) (no IR, radar detection)
                        * 5660 MHz [132] (20.0 dBm) (no IR, radar detection)
                        * 5680 MHz [136] (20.0 dBm) (no IR, radar detection)
                        * 5700 MHz [140] (20.0 dBm) (no IR, radar detection)
                        * 5720 MHz [144] (disabled)
                        * 5745 MHz [149] (disabled)
                        * 5765 MHz [153] (disabled)
                        * 5785 MHz [157] (disabled)
                        * 5805 MHz [161] (disabled)
                        * 5825 MHz [165] (disabled)
        valid interface combinations:
                 * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
                   total <= 3, #channels <= 1
                 * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
                   total <= 4, #channels <= 1
                 * #{ AP } <= 4,
                   total <= 4, #channels <= 1, STA/AP BI must match
root@lede:/# iw phy phy2 channels
Band 2:
        * 5170 MHz [34] (disabled)
        * 5180 MHz [36] 
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+
        * 5190 MHz [38] (disabled)
        * 5200 MHz [40] 
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40-
        * 5210 MHz [42] (disabled)
        * 5220 MHz [44] 
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+
        * 5230 MHz [46] (disabled)
        * 5240 MHz [48] 
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40-
        * 5260 MHz [52] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40+
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5280 MHz [56] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40-
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5300 MHz [60] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40+
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5320 MHz [64] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40-
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5500 MHz [100] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40+
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5520 MHz [104] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40-
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5540 MHz [108] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40+
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5560 MHz [112] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40-
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5580 MHz [116] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40+
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5600 MHz [120] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40-
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5620 MHz [124] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40+
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5640 MHz [128] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40-
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5660 MHz [132] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40+
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5680 MHz [136] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz HT40-
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5700 MHz [140] 
          Maximum TX power: 20.0 dBm
          No IR
          Radar detection
          Channel widths: 20MHz
          DFS state: usable (for 163 sec)
          DFS CAC time: 0 ms
        * 5720 MHz [144] (disabled)
        * 5745 MHz [149] (disabled)
        * 5765 MHz [153] (disabled)
        * 5785 MHz [157] (disabled)
        * 5805 MHz [161] (disabled)
        * 5825 MHz [165] (disabled)

Default channel

root@lede:/# iw phy phy0 info
Wiphy phy0
        max # scan SSIDs: 10
        max scan IEs length: 2048 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Device supports roaming.
        Available Antennas: TX 0 RX 0
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * P2P-client
                 * P2P-GO
                 * P2P-device
        Band 2:
                Capabilities: 0x1062
                        HT20/HT40
                        Static SM Power Save
                        RX HT20 SGI
                        RX HT40 SGI
                        No RX STBC
                        Max AMSDU length: 3839 bytes
                        DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 16 usec (0x07)
                HT TX/RX MCS rate indexes supported: 0-23
                VHT Capabilities (0x0c025820):
                        Max MPDU length: 3895
                        Supported Channel Width: neither 160 nor 80+80
                        short GI (80 MHz)
                        SU Beamformer
                        SU Beamformee
                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: MCS 0-9
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT RX highest supported: 0 Mbps
                VHT TX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: MCS 0-9
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT TX highest supported: 0 Mbps
                Frequencies:
                        * 5170 MHz [34] (disabled)
                        * 5180 MHz [36] (disabled)
                        * 5190 MHz [38] (disabled)
                        * 5200 MHz [40] (disabled)
                        * 5210 MHz [42] (disabled)
                        * 5220 MHz [44] (disabled)
                        * 5230 MHz [46] (disabled)
                        * 5240 MHz [48] (disabled)
                        * 5260 MHz [52] (disabled)
                        * 5280 MHz [56] (disabled)
                        * 5300 MHz [60] (disabled)
                        * 5320 MHz [64] (disabled)
                        * 5500 MHz [100] (disabled)
                        * 5520 MHz [104] (disabled)
                        * 5540 MHz [108] (disabled)
                        * 5560 MHz [112] (disabled)
                        * 5580 MHz [116] (disabled)
                        * 5600 MHz [120] (disabled)
                        * 5620 MHz [124] (disabled)
                        * 5640 MHz [128] (disabled)
                        * 5660 MHz [132] (disabled)
                        * 5680 MHz [136] (disabled)
                        * 5700 MHz [140] (disabled)
                        * 5720 MHz [144] (disabled)
                        * 5745 MHz [149] (20.0 dBm)
                        * 5765 MHz [153] (20.0 dBm)
                        * 5785 MHz [157] (20.0 dBm)
                        * 5805 MHz [161] (20.0 dBm)
                        * 5825 MHz [165] (20.0 dBm)
        valid interface combinations:
                 * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
                   total <= 3, #channels <= 1
                 * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
                   total <= 4, #channels <= 1
                 * #{ AP } <= 4,
                   total <= 4, #channels <= 1, STA/AP BI must match
root@lede:/# iw phy phy0 channels
Band 2:
        * 5170 MHz [34] (disabled)
        * 5180 MHz [36] (disabled)
        * 5190 MHz [38] (disabled)
        * 5200 MHz [40] (disabled)
        * 5210 MHz [42] (disabled)
        * 5220 MHz [44] (disabled)
        * 5230 MHz [46] (disabled)
        * 5240 MHz [48] (disabled)
        * 5260 MHz [52] (disabled)
        * 5280 MHz [56] (disabled)
        * 5300 MHz [60] (disabled)
        * 5320 MHz [64] (disabled)
        * 5500 MHz [100] (disabled)
        * 5520 MHz [104] (disabled)
        * 5540 MHz [108] (disabled)
        * 5560 MHz [112] (disabled)
        * 5580 MHz [116] (disabled)
        * 5600 MHz [120] (disabled)
        * 5620 MHz [124] (disabled)
        * 5640 MHz [128] (disabled)
        * 5660 MHz [132] (disabled)
        * 5680 MHz [136] (disabled)
        * 5700 MHz [140] (disabled)
        * 5720 MHz [144] (disabled)
        * 5745 MHz [149] 
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5765 MHz [153] 
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5785 MHz [157] 
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40+ VHT80
        * 5805 MHz [161] 
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz HT40- VHT80
        * 5825 MHz [165] 
          Maximum TX power: 20.0 dBm
          Channel widths: 20MHz

Sysupgrade currently kills processes with SIGKILL if they don’t shut down within 3 seconds after the SIGTERM signal. Some processes (e.g. domoticz) can take longer than 3 seconds to properly shut down. As this can potentially corrupt the sqlite database, it should be avoided.

While talking about this on IRC, it was suggested we should implement an “init 1” equivalent in procd. Adding this ticket as a reminder.

very bad performance for all neighbours on r3900

# cat /sys/kernel/debug/ieee80211/phy1/netdev:wlan1/stations/a0:f3:c1:ce:56:80/rc_stats
              best   ____________rate__________    ________statistics________    _____last____    ______sum-of________
mode guard #  rate  [name   idx airtime  max_tp]  [avg(tp) avg(prob) sd(prob)]  [retry|suc|att]  [#success | #attempts]
CCK    LP  1          1.0M  120   10548     0.0       0.0       0.0      0.0       0     0 0             0   0
CCK    LP  1          2.0M  121    5476     0.0       0.0       0.0      0.0       0     0 0             0   0
CCK    LP  1          5.5M  122    2411     2.4       0.0       0.0      0.0       0     0 0             0   0
CCK    LP  1         11.0M  123    1535     4.8       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  1  ABCDP  MCS0     0    1477     4.8       0.0       0.0      0.0       1     0 0             0   0
HT20  LGI  1         MCS1     1     739     9.7       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  1         MCS2     2     493    14.6       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  1         MCS3     3     369    17.0       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  1         MCS4     4     246    24.4       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  1         MCS5     5     185    29.2       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  1         MCS6     6     164    31.7       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  1         MCS7     7     148    34.1       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  2         MCS8    10     739     9.7       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  2         MCS9    11     369    17.0       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  2         MCS10   12     246    24.4       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  2         MCS11   13     185    29.2       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  2         MCS12   14     123    36.6       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  2         MCS13   15      93    43.9       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  2         MCS14   16      82    46.3       0.0       0.0      0.0       0     0 0             0   0
HT20  LGI  2         MCS15   17      74    48.8       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  1         MCS0    30    1329     4.8       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  1         MCS1    31     665     9.7       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  1         MCS2    32     443    14.6       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  1         MCS3    33     332    19.5       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  1         MCS4    34     222    26.8       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  1         MCS5    35     166    31.7       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  1         MCS6    36     148    34.1       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  1         MCS7    37     133    36.6       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  2         MCS8    40     665     9.7       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  2         MCS9    41     332    19.5       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  2         MCS10   42     222    26.8       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  2         MCS11   43     166    31.7       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  2         MCS12   44     111    39.0       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  2         MCS13   45      83    46.3       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  2         MCS14   46      74    48.8       0.0       0.0      0.0       0     0 0             0   0
HT20  SGI  2         MCS15   47      67    51.2       0.0       0.0      0.0       0     0 0             0   0

Total packet count::    ideal 7625      lookaround 407
Average # of aggregated frames per A-MPDU: 1.0

root@witi7:~ :) arping -I wlan1 10.63.102.195
ARPING to 10.63.102.195 from 10.63.140.195 via wlan1
Unicast reply from 10.63.102.195 [a0:f3:c1:ce:56:80] 491.552ms
Unicast reply from 10.63.102.195 [a0:f3:c1:ce:56:80] 600.276ms
Unicast reply from 10.63.102.195 [a0:f3:c1:ce:56:80] 747.811ms
Unicast reply from 10.63.102.195 [a0:f3:c1:ce:56:80] 748.426ms
Unicast reply from 10.63.102.195 [a0:f3:c1:ce:56:80] 511.603ms
Unicast reply from 10.63.102.195 [a0:f3:c1:ce:56:80] 403.993ms
Unicast reply from 10.63.102.195 [a0:f3:c1:ce:56:80] 601.602ms
Unicast reply from 10.63.102.195 [a0:f3:c1:ce:56:80] 371.090ms

root@witi7:~ :) ping -c1 10.63.102.195
PING 10.63.102.195 (10.63.102.195): 56 data bytes
64 bytes from 10.63.102.195: seq=0 ttl=64 time=2414.528 ms

--- 10.63.102.195 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 2414.528/2414.528/2414.528 ms

root@witi7:~ :) iw dev wlan1 station get a0:f3:c1:ce:56:80
Station a0:f3:c1:ce:56:80 (on wlan1)
        inactive time:  150 ms
        rx bytes:       32573998
        rx packets:     63413
        tx bytes:       1038834
        tx packets:     8318
        tx retries:     133088
        tx failed:      8318
        rx drop misc:   30946
        signal:         -60 [-67, -60] dBm
        signal avg:     -59 [-67, -59] dBm
        tx bitrate:     6.5 MBit/s MCS 0
        rx bitrate:     6.5 MBit/s MCS 0
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        DTIM period:    0
        beacon interval:250
        connected time: 8652 seconds

# uci show wireless (2.4ghz)
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.country='US'
wireless.radio1.frag='off'
wireless.radio1.path='pci0000:00/0000:00:01.0/0000:02:00.0'
wireless.radio1.chanbw='20'
wireless.radio1.channel='5'
wireless.radio1.distance='100'
wireless.radio1.beacon_int='250'
wireless.radio1.hwmode='11n'
wireless.radio1.htmode='HT20'
wireless.radio1.txpower='23'

wireless.@wifi-iface[2]=wifi-iface
wireless.@wifi-iface[2].device='radio1'
wireless.@wifi-iface[2].network='wlanadhocRADIO1'
wireless.@wifi-iface[2].mode='adhoc'
wireless.@wifi-iface[2].mcast_rate='6000'
wireless.@wifi-iface[2].macaddr='8c:bc:c0:43:c9:09'
wireless.@wifi-iface[2].bssid='02:ca:ff:ee:ba:be'
wireless.@wifi-iface[2].ssid='ffintern.2GHz'

wireless.@wifi-iface[3]=wifi-iface
wireless.@wifi-iface[3].device='radio1'
wireless.@wifi-iface[3].network='wlanRADIO1'
wireless.@wifi-iface[3].encryption='none'
wireless.@wifi-iface[3].mode='ap'
wireless.@wifi-iface[3].macaddr='8e:bc:c0:43:c9:0a'
wireless.@wifi-iface[3].max_inactivity='10'
wireless.@wifi-iface[3].ssid='weimar.freifunk.net'
wireless.@wifi-iface[3].disassoc_low_ack='1'

Currently, when running “make check” on a single package, it does not print any warning. V=s is needed to see the warnings. The build system should print the warnings in all cases, because that’s what the user asks for!

To reproduce:

$ make package/nlbwmon/check 
 make[1] package/nlbwmon/check
 make[2] -C feeds/packages/net/nlbwmon check

$ make package/nlbwmon/check V=s
make[1]: Entering directory '/tmp/lede'
make[2]: Entering directory '/tmp/lede/feeds/packages/net/nlbwmon'
WARNING: nlbwmon-2017-08-02-32fc0925.tar.xz is missing, please run make download before re-running this check
make[2]: Leaving directory '/tmp/lede/feeds/packages/net/nlbwmon'
make[1]: Leaving directory '/tmp/lede'

The main target make check (without specifying any package) works fine, because it seems to run in verbose mode by default:

$ make check
make[3]: Entering directory '/tmp/lede/tools/gmp'
make[3]: Leaving directory '/tmp/lede/tools/gmp'
...
make[3]: Entering directory '/tmp/lede/package/network/utils/iwinfo'
WARNING: PKG_MIRROR_HASH is missing, set to 7bd294f50f8ec8c0497c5fbe5527f3ae098814cdfeecf4ccf78a2a8937611664
make[3]: Leaving directory '/tmp/lede/package/network/utils/iwinfo'
...

I tried to fix the issue myself but this is way above my understanding of make.

Supply the following if possible:
- Device problem occurs on

Observed on an APU2

- Software versions of LEDE release, packages, etc.

DISTRIB_ID='LEDE'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r5244-f0c37f6ceb'
DISTRIB_CODENAME='reboot'
DISTRIB_TARGET='x86/64'
DISTRIB_ARCH='x86_64'
DISTRIB_DESCRIPTION='LEDE Reboot SNAPSHOT r5244-f0c37f6ceb'
DISTRIB_TAINTS='no-all busybox'

# opkg list_installed | grep dnsmasq
dnsmasq - 2.78-2

- Steps to reproduce

In my case, I have an upstream service provisioned with pppoe. Occasionally, the pppoe session dies as the ISP does some kind of unannounced maintenance. Since updating recently from a March 2016 build of OpenWrt, when this outage occurs, dnsmasq sends many messages, like this:

Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied
Nov 16 02:03:10 192.168.80.1 dnsmasq[27288]: failed to send packet: Permission denied

nearly 30 per second.

Supply the following if possible:
- Device problem occurs on all device
- Software versions of OpenWrt/LEDE: Trunk

If i select this option in menuconfig, At the boot procd mount the wrong size of ram. I have 512mb of ram and procd mount only 11mb of ram. More detail here.
http://lists.infradead.org/pipermail/lede-dev/2018-January/011008.html

https://forum.lede-project.org/t/no-space-left-in-tmp/11000/14

When using uqmi –get-message the message ends up truncated in case it contains unicode characters like german umlauts.

As IPv6 is being adopted, increasingly people are seeing dnsmasq log ‘spam’. See https://bugs.openwrt.org/index.php?do=details&task_id=1492&string=1492&search_name=&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

By default under openwrt, dhcpv4 leases are handled by dnsmasq whilst dhcpv6/RA is handled by openwrt’s odhcpd.

odhcpd could handle both v4 & v6 but does not yet have the same configuration flexibility for dhcp options as dnsmasq. I guess this is why no one has been brave enough to switch to odhcpd for ipv4 operations as well as ipv6.

dnsmasq can also handle dhcpv6/RA but not quite as flexibly as odhcpd. dnsmasq will automatically find IP6 prefixes on interfaces and start handling them, whilst openwrt’s strategy with odhcpd is to only handle stuff we tell you to handle, don’t do it automagically.

As dnsmasq is the default resolver for openwrt and the wider LAN, it needs to know about DHCP/hostname allocations. For DHCPv4 this is easy, dnsmasq is controlling them. For DHCPv6 a hosts file (called a statefile in the odhcpd code) is handed to dnsmasq.

By default this host file is not read dynamically, so odhcpd has to signal dnsmasq to re-read the host file (and clear caches etc etc) upon every ipv6 lease change.

This generates a lot of log spam and process startup overhead. There are also questions about service operability during this time.

Effort needs to be put into sorting this out.

Temporary workarounds:

Use ‘hostsdir’ dnsmasq option instead of ‘addn-hosts’ - dnsmasq will dynamically scan changes/additions to hosts in hostsdir whereas addn-hosts needs a SIGHUP. Host deletions cannot be handled by this method, so odhcpd would still need to SIGHUP on lease expiry. It might reduce some of the spam.

Longer term:

Teach dnsmasq to accept hostname updates over an IPC mechanism. ubus? and carry on using odhcpd for ipv6.

Teach dnsmasq to handle ipv6 prefix additions/deletions/handling via an IPC mechanism in the same way as odhcpd. Drop odhcpd and use dnsmasq for everything.

Use odhcpd for everything and use another dns resolver that interfaces nicely with odhcpd.

Why don’t I see this problem: I use dnsmasq to handle ipv6 but I’m lucky enough that this works for me.

This needs fixing/funding to sort it out though.

Using the 19.07-SNAPSHOT SDK build Sept 12 (last successful build by the buildbots it looks like), and current openwrt-19.07 branch on the feeds, if doing signed build, the build fails due to ucert segfaulting (this is on Debian 10).

ldd staging_dir/host/bin/ucert shows:

      linux-vdso.so.1 (0x00007ffd03d63000)
      libubox.so => /home/daniel/Build/sdk-19.07-ath79/staging_dir/host/lib/libubox.so (0x00007ff0db3b0000)
      libblobmsg_json.so => /home/daniel/Build/sdk-19.07-ath79/staging_dir/host/lib/libblobmsg_json.so (0x00007ff0db3a8000)
      libjson-c.so.2 => /home/daniel/Build/sdk-19.07-ath79/staging_dir/host/lib/libjson-c.so.2 (0x00007ff0db398000)
      libc.so.6 => /home/daniel/Build/sdk-19.07-ath79/staging_dir/host/lib/libc.so.6 (0x00007ff0daff8000)
      /lib64/ld-linux-x86-64.so.2 (0x00007ff0db3c8000)

I’m wondering if the problem is due to using host instead SDK libraries.

See https://github.com/openwrt/openwrt/pull/2483

without this patch the ghl-r-001 cannot be boot.

reproduct in both 19.7-rc2 and git master.

OpenWrt master r13174-73fa1aba94 on octeon with kernel 5.4

[   70.971145] 
[   70.972662] ======================================================
[   70.978843] WARNING: possible circular locking dependency detected
[   70.985029] 5.4.39 #0 Not tainted
[   70.988348] ------------------------------------------------------
[   70.994531] unbound/2895 is trying to acquire lock:
[   70.999414] 800000041baeb868 (&pcr->fcrypt.sem){+.+.}, at: crypto_get_session_by_sid+0x40/0x12b8 [cryptodev]
[   71.009267] 
[   71.009267] but task is already holding lock:
[   71.015103] 800000041b911468 (&ses_new->sem){+.+.}, at: crypto_get_session_by_sid+0xbc/0x12b8 [cryptodev]
[   71.024691] 
[   71.024691] which lock already depends on the new lock.
[   71.024691] 
[   71.032866] 
[   71.032866] the existing dependency chain (in reverse order) is:
[   71.040347] 
[   71.040347] -> #1 (&ses_new->sem){+.+.}:
[   71.045773]        lock_acquire+0xe0/0x220
[   71.049888]        __mutex_lock+0x94/0x628
[   71.054001]        crypto_get_session_by_sid+0xbc/0x12b8 [cryptodev]
[   71.060365]        crypto_get_session_by_sid+0x1e4/0x12b8 [cryptodev]
[   71.066806]
[   71.066806] -> #0 (&pcr->fcrypt.sem){+.+.}:
[   71.072485]        check_noncircular+0x1a8/0x260
[   71.077110]        __lock_acquire+0x12f8/0x19f8
[   71.081648]        lock_acquire+0xe0/0x220
[   71.085754]        __mutex_lock+0x94/0x628
[   71.089862]        crypto_get_session_by_sid+0x40/0x12b8 [cryptodev]
[   71.096226]        crypto_get_session_by_sid+0x6cc/0x12b8 [cryptodev]
[   71.102666]
[   71.102666] other info that might help us debug this:
[   71.102666]
[   71.110668]  Possible unsafe locking scenario:
[   71.110668]
[   71.116588]        CPU0                    CPU1
[   71.121119]        ----                    ----
[   71.125650]   lock(&ses_new->sem);
[   71.129058]                                lock(&pcr->fcrypt.sem);
[   71.135242]                                lock(&ses_new->sem);
[   71.141165]   lock(&pcr->fcrypt.sem);
[   71.144834]
[   71.144834]  *** DEADLOCK ***
[   71.144834]
[   71.150756] 1 lock held by unbound/2895:
[   71.154681]  #0: 800000041b911468 (&ses_new->sem){+.+.}, at: crypto_get_session_by_sid+0xbc/0x12b8 [cryptodev]
[   71.164700]
[   71.164700] stack backtrace:
[   71.169067] CPU: 1 PID: 2895 Comm: unbound Not tainted 5.4.39 #0
[   71.175075] Stack : ffffffff82790000 0000000000000000 0000000010108ce0 ed34220aed96997f
[   71.183091]         ed34220aed96997f 0000000000000000 800000041bb976f8 ffffffff837d0000
[   71.191106]         0000000000000000 0000000000000001 0000000000000000 ffffffff811ac4bc
[   71.199118]         6e626f756e64204e 0000000000000000 ffffffffffffffff 0000000000000010
[   71.207132]         0000000000000000 ffffffff81b40000 fffe000000000000 ffffffff81bc0000
[   71.215145]         0000000000000000 0000000000000000 ffffffff81b40000 0000000000000000
[   71.223158]         800000041f2e6200 0000000000000000 ffffffff81597628 1e00000010734ac7
[   71.231173]         0000000000000001 800000041bb94000 800000041bb976f0 47500c0a872e7996
[   71.239186]         ffffffff81865d8c 0000000000000000 800000041bb97828 ed34220aed96997f
[   71.247198]         ffffffff81b40bf7 ffffffff81865c54 ffffffff8111d4c8 ffffffff81a42a50
[   71.255213]         ...
[   71.257668] Call Trace:
[   71.260136] [<ffffffff8111d4c8>] show_stack+0x40/0x128
[   71.265288] [<ffffffff81865d8c>] dump_stack+0xe4/0x150
[   71.270444] [<ffffffff8119fb58>] check_noncircular+0x1a8/0x260
[   71.276289] [<ffffffff811a2d38>] __lock_acquire+0x12f8/0x19f8
[   71.282046] [<ffffffff811a3d80>] lock_acquire+0xe0/0x220
[   71.287374] [<ffffffff8188532c>] __mutex_lock+0x94/0x628
[   71.292706] [<ffffffffc02a7638>] crypto_get_session_by_sid+0x40/0x12b8 [cryptodev]
[   71.300290] [<ffffffffc02a7cc4>] crypto_get_session_by_sid+0x6cc/0x12b8 [cryptodev]

This is on an x86_64 build of master from last Monday (circa 6e8b689).

The exact hardware is a Supermicro SYS-5018D-FN8T, 32GB of DRAM, 512GB of NVMe.

I built a new master today (8d2c031f) and scp’d it onto /tmp/ of my router. Then did a “sysupgrade /tmp/...” of that:

root@OpenWrt:/# ifdown wan
root@OpenWrt:/# 
root@OpenWrt:/# 
root@OpenWrt:/# sysupgrade /tmp/openwrt-r13360\+64-4661b05390-x86-64-generic-squashfs-combined-efi.img 
Image metadata not found
Reading partition table from bootdisk...
cat: write error: Broken pipe
Reading partition table from image...
Saving config files...
Commencing upgrade. Closing all shell sessions.
Watchdog handover: fd=7
- watchdog -
killall: telnetd: no process killed
killall: dropbear: no process kiSending TERM to remaining processes ... ntpd sh snmpd dhcpd ipset-dns collectd lldpd lldpd smartd named sleep ubusd askfirst urngd netifd rngd crond lighttpd sshd syslog-ng 
Sending KILL to remaining processes ... 
Switching to ramdisk...
Performing system upgrade...
Reading partition table from bootdisk...
dd: warning: partial read (8192 bytes); suggest iflag=fullblock
0+63 records in
0+63 records out
1101824 bytes (1.1 MB, 1.1 MiB) copied, 0.00492347 s, 224 MB/s
Reading partition table from image...
Writing image to /dev/nvme0n1p1...
cat: write error: Broken pipe
40959+0 records in
19+1 records out
20971008 bytes (21 MB, 20 MiB) copied, 0.0963313 s, 218 MB/s
Writing image to /dev/nvme0n1p2...
462847+0 records in
225+1 records out
236977664 bytes (237 MB, 226 MiB) copied, 0.810288 s, 292 MB/s
Writing new UUID to /dev/nvme0n1...
4+0 records in
4+0 records out
cat: write error: Broken pipe
4 bytes copied, 0.00439713 s, 0.9 k[ 2308.927159] F2FS-fs (nvme0n1p1): Magic Mismatch, valid(0xf2f52010) - read(0x0)
B/s
[ 2308.945667] F2FS-fs (nvme0n1p1): Can't find valid F2FS filesystem in 1th superblock
[ 2308.963141] F2FS-fs (nvme0n1p1): Magic Mismatch, valid(0xf2f52010) - read(0x6020601)
[ 2308.980487] F2FS-fs (nvme0n1p1): Can't find valid F2FS filesystem in 2th superblock
Upgrading bootloader on /dev/nvme0n1...
touch: /tmp/boot/grub/upgraded: No such file or directory
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[ 2310.852582] ACPI Warning: \_SB.PCI0.BR2C._PRT: Return Package has no elements (empty) (20190816/nsprepkg-96)
[ 2310.881404] ACPI Warning: \_SB.PCI0.BR2C._PRT: Return Package has no elements (empty) (20190816/nsprepkg-96)
[ 2311.080235] reboot: Restarting system
[ 2311.093088] reboot: machine restart

Note that on reboot, dmesg says:

...
May 31 16:43:17 OpenWrt kernel: [    3.721825] Copyright (c) 1999-2008 LSI Corporation
May 31 16:43:17 OpenWrt kernel: [    3.724539] nvme nvme0: 7/0/0 default/read/poll queues
May 31 16:43:17 OpenWrt kernel: [    3.732035] Fusion MPT SPI Host driver 3.04.20
May 31 16:43:17 OpenWrt kernel: [    3.752418] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
May 31 16:43:17 OpenWrt kernel: [    3.753680] GPT:Primary header thinks Alt. header is not at the end of the disk.
May 31 16:43:17 OpenWrt kernel: [    3.764418] ehci-pci: EHCI PCI platform driver
May 31 16:43:17 OpenWrt kernel: [    3.777281] GPT:504894 != 1000215215
May 31 16:43:17 OpenWrt kernel: [    3.787218] ehci-pci 0000:00:1a.0: EHCI Host Controller
May 31 16:43:17 OpenWrt kernel: [    3.795949] GPT:Alternate GPT header not at the end of the disk.
May 31 16:43:17 OpenWrt kernel: [    3.795950] GPT:504894 != 1000215215
May 31 16:43:17 OpenWrt kernel: [    3.806441] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1
May 31 16:43:17 OpenWrt kernel: [    3.817622] GPT: Use GNU Parted to correct GPT errors.
May 31 16:43:17 OpenWrt kernel: [    3.817629]  nvme0n1: p1 p2 p128
...

but I don’t know if that’s related or not.

Building master:

files="e_bpf.c em_canid.c em_cmp.c em_ipset.c em_ipt.c em_meta.c em_nbyte.c em_u32.c f_basic.c f_bpf.c f_cgroup.c f_flow.c f_flower.c f_fw.c f_matchall.c f_route.c f_rsvp.c f_tcindex.c f_u32.c m_action.c m_bpf.c m_connmark.c m_csum.c
m_ct.c m_ctinfo.c m_ematch.c m_estimator.c m_gact.c m_gate.c m_ife.c m_ipt.c m_mirred.c m_mpls.c m_nat.c m_pedit.c m_police.c m_sample.c m_simple.c m_skbedit.c m_skbmod.c m_tunnel_key.c m_vlan.c m_xt_old.c p_eth.c p_icmp.c p_ip.c p_ip
6.c p_tcp.c p_udp.c q_atm.c q_cake.c q_cbq.c q_cbs.c q_choke.c q_clsact.c q_codel.c q_drr.c q_dsmark.c q_etf.c q_ets.c q_fifo.c q_fq.c q_fq_codel.c q_fq_pie.c q_gred.c q_hfsc.c q_hhf.c q_htb.c q_ingress.c q_mqprio.c q_multiq.c q_netem
.c q_pie.c q_plug.c q_prio.c q_qfq.c q_red.c q_rr.c q_sfb.c q_sfq.c q_skbprio.c q_taprio.c q_tbf.c static-syms.c tc.c tc_cbq.c tc_class.c tc_core.c tc_estimator.c tc_exec.c tc_filter.c tc_monitor.c tc_qdisc.c tc_red.c tc_stab.c tc_uti
l.c" ; \
echo "{" > dynsyms.list ; \
for s in `grep -B 3 '\<dlsym' $files | sed -n '/snprintf/{s:.*"\([^"]*\)".*:\1:;s:%s::;p}'` ; do \
        sed -n '/'$s'[^ ]* =/{s:.* \([^ ]*'$s'[^ ]*\) .*:\1;:;p}' $files ; \
done >> dynsyms.list ; \
echo "show_stats; print_nl; print_tm; parse_rtattr; parse_rtattr_flags; get_u32; matches; addattr_l; addattr_nest; addattr_nest_end; };" >> dynsyms.list
    CC       m_xt.so
In file included from ../include/uapi/linux/netfilter_ipv4/ip_tables.h:21,
                 from m_xt.c:19:
../include/uapi/linux/if.h:134: warning: "IFF_VOLATILE" redefined
 #define IFF_VOLATILE (IFF_LOOPBACK|IFF_POINTOPOINT|IFF_BROADCAST|IFF_ECHO|\

In file included from m_xt.c:16:
/home/user/dev/openwrt/staging_dir/toolchain-mips_24kc_gcc-8.4.0_musl/include/net/if.h:48: note: this is the location of the previous definition
 #define IFF_VOLATILE (IFF_LOOPBACK|IFF_POINTOPOINT|IFF_BROADCAST| \

    CC       emp_ematch.tab.o
/home/user/dev/openwrt/staging_dir/toolchain-mips_24kc_gcc-8.4.0_musl/lib/gcc/mips-openwrt-linux-musl/8.4.0/../../../../mips-openwrt-linux-musl/bin/ld:dynsyms.list:0: syntax error in dynamic list
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:174: m_xt.so] Error 1

The dynsyms file contains:

$ cat ./build_dir/target-mips_24kc_musl/linux-ath79_generic/iproute2-tc/iproute2-5.8.0/tc/dynsyms.list
{
bpf_action_util;
connmark_action_util;
csum_action_util;
ct_action_util;
ctinfo_action_util;
gact_action_util;
gate_action_util;
ife_action_util;
ipt_action_util;
mirred_action_util;
mpls_action_util;
nat_action_util;
pedit_action_util;
police_action_util;
sample_action_util;
simple_action_util;
skbedit_action_util;
skbmod_action_util;
tunnel_key_action_util;
vlan_action_util;
ipt_action_util;
canid_ematch_util;
cmp_ematch_util;
ipset_ematch_util;
ipt_ematch_util;
meta_ematch_util;
nbyte_ematch_util;
u32_ematch_util;
p_pedit_eth;
p_pedit_icmp;
p_pedit_ip;
p_pedit_ip6;
p_pedit_tcp;
p_pedit_udp;
atm_qdisc_util;
cake_qdisc_util;
cbq_qdisc_util;
cbs_qdisc_util;
choke_qdisc_util;
clsact_qdisc_util;
codel_qdisc_util;
drr_qdisc_util;
dsmark_qdisc_util;
etf_qdisc_util;
ets_qdisc_util;
bfifo_qdisc_util;
pfifo_qdisc_util;
pfifo_head_drop_qdisc_util;
pfifo_fast_qdisc_util;
fq_qdisc_util;
fq_codel_qdisc_util;
fq_pie_qdisc_util;
gred_qdisc_util;
hfsc_qdisc_util;
hhf_qdisc_util;
htb_qdisc_util;
ingress_qdisc_util;
mqprio_qdisc_util;
multiq_qdisc_util;
netem_qdisc_util;
pie_qdisc_util;
plug_qdisc_util;
prio_qdisc_util;
qfq_qdisc_util;
red_qdisc_util;
rr_qdisc_util;
sfb_qdisc_util;
sfq_qdisc_util;
skbprio_qdisc_util;
taprio_qdisc_util;
tbf_qdisc_util;
basic_filter_util;
bpf_filter_util;
cgroup_filter_util;
flow_filter_util;
flower_filter_util;
fw_filter_util;
matchall_filter_util;
route_filter_util;
rsvp_filter_util;
rsvp6_filter_util;
tcindex_filter_util;
u32_filter_util;
bpf_exec_util;
show_stats; print_nl; print_tm; parse_rtattr; parse_rtattr_flags; get_u32; matches; addattr_l; addattr_nest; addattr_nest_end; };

OpenWrt version: r14723-7f5f738466

Since some weeks/months, building an image floods my terminal with messages like this:

dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file
dlsym(acl_get_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /home/stijn/Development/OpenWrt/openwrt/staging_dir/host/lib/libfakeroot.so: undefined symbol: acl_set_file

This is extremely annoying and should be fixed.

The RE6500 was working fine on an old 19.07 snapshot: OpenWrt 19.07-SNAPSHOT r10578-b3d70f628b

I sysupgraded to latest snapshot and it does not come up. Judging from the LEDs, it seems to bootloop.

Booting the latest snapshot initramfs through TFTP works. I sysupgraded again from the initramfs, and it still bootloops.

Possibly related to FS#3539. I will try to get a serial output to see what happens.

Dynamic vlan config on ath10k seems not to work. Same config on ath9k works fine.

Config:

config wifi-device  radio0
        option type     mac80211
        option channel  36
        option hwmode   11a
        option path     'pci0000:01/0000:01:00.0'
        option htmode   VHT80
[...]

config wifi-iface
        option device   radio0
        option network  vlan1
        option mode     ap
[...]
        option dynamic_vlan     '1'
        option 'vlan_tagged_interface' 'eth1'
        option 'vlan_bridge' 'br-vlan'
        option 'vlan_naming' '0'

Log:

Thu Feb  9 15:54:37 2017 daemon.err hostapd: WPA initialization for VLAN 1 failed (-1)
Thu Feb  9 15:54:37 2017 daemon.err hostapd: WPA deinit of wlan0.1 failed
Thu Feb  9 15:54:37 2017 daemon.debug hostapd: wlan0: STA ac:22:0b:a1:c7:6b IEEE 802.11: could not add dynamic VLAN interface for vlan=1

Device: Turris Omnia
Version: OpenWRT-18.06-rc1

Steps to reproduce:

Network configuration:

config interface 'lan'
        option type 'bridge'
        option ifname 'lan0 lan1 lan2 lan3 lan4.1'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'

config interface 'dmz'
        option type 'bridge'
        option ifname 'lan4.2'
        option proto 'static'
        option ipaddr '192.168.2.1'
        option netmask '255.255.255.0'

From router, I have ping with the other device on both vlan:

# ping -c 3 192.168.1.5
PING 192.168.1.5 (192.168.1.5): 56 data bytes
64 bytes from 192.168.1.5: seq=0 ttl=64 time=0.434 ms
64 bytes from 192.168.1.5: seq=1 ttl=64 time=0.335 ms
64 bytes from 192.168.1.5: seq=2 ttl=64 time=0.333 ms

--- 192.168.1.5 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.333/0.367/0.434 ms

# ping -c 3 192.168.2.5
PING 192.168.2.5 (192.168.2.5): 56 data bytes
64 bytes from 192.168.2.5: seq=0 ttl=64 time=0.455 ms
64 bytes from 192.168.2.5: seq=1 ttl=64 time=0.341 ms
64 bytes from 192.168.2.5: seq=2 ttl=64 time=0.337 ms

--- 192.168.2.5 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.337/0.377/0.455 ms

But from other device connected to lan0 port I can’t do ping. More exactly, the situation is the next:

• All work as expected in the next cases:
  • movile → tun0 (openvpn) → br-lan → lan4.1 (part of br-lan) → remote device
  • tablet → wlan0 (part of br-lan) → lan4.1 (part of br-lan) → remote device
• It do not work as expected in the next case:
  • PC linux → lan0 (part of br-lan) → lan4.1 (part of br-lan) → remote device

DEVICE: TP-Link Archer C7 v2
SYSTEM: OpenWRT 18.06.1
PACKAGES: base + luci, ca-certificates, ddns-scripts_no-ip_com, luci-app-ddns, wget, ip, ppp, ppp-mod-pppoe, vim, nano, usbutils, usb-modeswitch, kmod-usb-core,

        kmod-usb-serial, kmod-usb-serial-option, kmod-usb-net-cdc-ncm, kmod-usb-net-huawei-cdc-ncm, picocom, sqm-scripts, luci-app-sqm, kmod-ledtrig-heartbeat, htop

If the USB Device (HUAWEI E3372 LTE Stick) is left connected to the router during a reboot/boot, the hotplug event is triggered too early and the device has not yet all interfaces mapped in the /dev directory.
More specifically, my hotplug script wants to find the name of the interface (which is “ttyUSB0” in my case) by looking at the $DEVPATH directory, but during the hotplug script execution the link does not yet exist. Adding a “sleep” inside the script does not help, but executing a subscript via “exec script &” shows that after 3 seconds the link is created.
Attached is a file showing the directory listing of $DEVPATH during the hotplug event, and 3 seconds after the hotplug event.

Note that the hotplug script works as intended during actual hotplugging. This bug only presents itself during boot/reboot.
Also note that this was working on OpenWRT 15.05.1 (same Router, Stick and hotplug script)

I’m running OpenWRT on an x86 machine running OpenWRT 18.06.2.

Steps to reproduce:

Configure dropbear to only listen on an interface such as ‘lan’

 
  config dropbear
    option Interface 'lan'

After rebooting, often dropbear will be bound to 192.168.1.1, but not fd00:2233:4455:1::1 (router’s ipv6 address). Restarting dropbear fixes the problem and it binds correctly to the ipv4 and ipv6 lan address.

wifi on lede 17.01.6, with the same config, works great
install openwrt 18.06
opkg remove kmod-b43 kmod-b43legacy kmod-mac80211 kmod-cfg80211 kmod-brcmsmac
opkg install kmod-brcm-wl nas wlc wl
wl -i wl0 chanspec -c 9 -b 2 -w 40 -s -1

config wifi-device ‘wl0’

      option type 'broadcom'
      option channel '9'
      option hwmode '11ng'
      option htmode 'HT40'
      option txpower '16'
      option txantenna '3'
      option rxantenna '3'

config wifi-iface

      option device 'wl0'
      option network 'lan'
      option mode 'ap'
      option ssid 'point'
      option encryption 'psk2'
      option key 'pass'
      option wmm '1'
      option disabled '0'

After, my laptop (windows) does not connect and the phone on the android
connects for 15-20 minutes, disconnects, manually connects from the third fourth attempt
and disconnects again after a while

ifconfig shows that the interface wl0-1 is automatically created with non-existent mac address E2:CB:4E:C0:18:14 (wl0 E0:CB:4E:C0:18:13)
Wi-Fi scanner shows two access points with the same name, channels, but different MAC addresses (E2:CB:4E:C0:18:14, E0:CB:4E:C0:18:13)

I compiled two firmware with
CONFIG_TARGET_brcm47xx=y
CONFIG_TARGET_brcm47xx_mips74k=y
CONFIG_TARGET_brcm47xx_mips74k_DEVICE_asus-rt-n16=y
and
CONFIG_TARGET_brcm47xx=y
CONFIG_TARGET_brcm47xx_mips74k=y
CONFIG_TARGET_brcm47xx_mips74k_Broadcom-mips74k-wl=y

but it did not help

I cannot install the 18.06.1 and 18.06.2 Images on my TP-Link WBS210. For the openwrt-18.06.x-ar71xx-generic-wbs210-v1-squashfs-sysupgrade.bin image I get the message:

“The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.”

Up to version 18.06.0 everything worked fine.

Steps to reproduce: Plug a USB 3.0 external HDD to USB 3.0 port of any openwrt 18.06 device and check speed when copying a file to the external HDD, it should be around 100+ MBps

Any needed additional info can be found at this forum question: https://forum.openwrt.org/t/usb3-0-hdd-issues/34031/13

Mikrotik RB750Gr3
LuCI openwrt-19.07 branch (git-19.267.59428-7b36dae) / OpenWrt 19.07-SNAPSHOT r10532-cf3b50377e

Router randomly reboots (it may be stable for hours or can reboot in a minute after power up). Seems like kernel problem.

Here are some logs I managed to fetch before the reboots:

Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.010562] ------------[ cut here ]------------
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.015202] WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_output.c:2509 0x803cc8bc
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.022158] invalid inflight: 1 state 1 cwnd 10 mss 1388
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.027441] Modules linked in: qcserial pppoe ppp_async option cdc_mbim usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm cdc_ncm cdc_ether 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 wireguard usbserial usbnet usblp ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.097872]  nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt cdc_wdm cdc_acm fuse ledtrig_usbport gpio_beeper input_core xt_set ip_set_list_set ip_set_hash_netportnet 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 ip6_udp_tunnel udp_tunnel tun vfat fat nls_utf8 nls_iso8859_1 nls_cp437 uas usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd ehci_platform
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.169233]  sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common mii crc32c_generic
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.180291] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.14.143 #0
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.186357] Stack : 00000000 00000000 00000000 81230398 00000000 00000000 00000000 00000000
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.194691]         00000000 00000000 00000000 00000000 00000000 00000001 8fc0dd30 ac07f596
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.203026]         8fc0ddc8 00000000 00000000 00004ea0 00000038 8049db58 00000007 00000000
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.211359]         00000000 80550000 0002c043 00000000 8fc0dd10 00000000 80570000 8050c6a0
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.219690]         803cc8bc 000009cd 812303d8 81230398 00000000 802af9e8 00000008 805b0008
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.228022]         ...
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.230459] Call Trace:
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.230475] [<8049db58>] 0x8049db58
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.236372] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.239840] [<802af9e8>] 0x802af9e8
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.243312] [<800101a0>] 0x800101a0
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.246782] [<800101a8>] 0x800101a8
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.250250] [<80486a9c>] 0x80486a9c
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.253722] [<800758a0>] 0x800758a0
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.257243] [<80032588>] 0x80032588
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.260714] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.264185] [<80032610>] 0x80032610
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.267654] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.271126] [<803cf3d0>] 0x803cf3d0
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.274596] [<8009d750>] 0x8009d750
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.278064] [<803cf7a8>] 0x803cf7a8
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.281537] [<8009dd80>] 0x8009dd80
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.285007] [<803cf770>] 0x803cf770
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.288474] [<8008c2cc>] 0x8008c2cc
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.291945] [<8008c588>] 0x8008c588
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.295413] [<8007cee8>] 0x8007cee8
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.298883] [<804a49b8>] 0x804a49b8
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.302357] [<80036f14>] 0x80036f14
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.305827] [<8025d440>] 0x8025d440
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.309296] [<8000b488>] 0x8000b488
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.312764]
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.314310] ---[ end trace a36c893f27b6a6f3 ]---

Sun Sep 29 18:56:25 2019 kern.alert kernel: [ 2442.525228] CPU 1 Unable to handle kernel paging request at virtual address 00000010, epc == 803be4a0, ra == 803c4104
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.535821] Oops[#1]:
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.538087] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W       4.14.143 #0
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.545363] task: 8fc3be80 task.stack: 8fc5c000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.549869] $ 0   : 00000000 00000001 0000004a 00000000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.555080] $ 4   : 8ea76f3c 00000001 0000d706 00000000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.560290] $ 8   : 00034501 00000321 811d7440 00000322
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.565501] $12   : 8ea22180 8ea22180 8e9a8e00 00000000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.570712] $16   : 8ea76e40 00001204 6375f4c6 ffffffff
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.575923] $20   : 00001204 00000001 00000000 00000002
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.581133] $24   : 00000000 8034b220
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.586344] $28   : 8fc5c000 8fc0bbb8 00000000 803c4104
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.591555] Hi    : 0000caa1
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.594419] Lo    : 47aec5c8
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.597285] epc   : 803be4a0 0x803be4a0
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.601098] ra    : 803c4104 0x803c4104
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.604912] Status: 11007c03      KERNEL EXL IE
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.609082] Cause : 40800008 (ExcCode 02)
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.613066] BadVA : 00000010
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.615931] PrId  : 0001992f (MIPS 1004Kc)
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.620003] Modules linked in: qcserial pppoe ppp_async option cdc_mbim usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm cdc_ncm cdc_ether 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 wireguard usbserial usbnet usblp ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.690391]  nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt cdc_wdm cdc_acm fuse ledtrig_usbport gpio_beeper input_core xt_set ip_set_list_set ip_set_hash_netportnet 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 ip6_udp_tunnel udp_tunnel tun vfat fat nls_utf8 nls_iso8859_1 nls_cp437 uas usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd ehci_platform
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.761710]  sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common mii crc32c_generic
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.772740] Process swapper/1 (pid: 0, threadinfo=8fc5c000, task=8fc3be80, tls=00000000)
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.780788] Stack : 00000204 8034def4 8ea76e40 00000000 8ea76e40 8ea76e40 00001204 803c4104
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.789123]         8f346480 8056ba00 00000000 8015000a 00018bc3 8fc0bc74 00000004 00000000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.797457]         80550000 8ea76f3c 00000002 00000001 91946e37 00000000 00000018 91946e37
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.805791]         00000000 91946e37 00000000 00000001 80570000 8050c458 00000000 00000002
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.814125]         00018bc3 00000018 8ee92564 8e9a0600 00000000 00000000 00000001 00000000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.822457]         ...
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.824891] Call Trace:
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.824903] [<8034def4>] 0x8034def4
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.830852] [<803c4104>] 0x803c4104
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.834335] [<8015000a>] 0x8015000a
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.837825] [<803c4efc>] 0x803c4efc
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.841318] [<803c6f34>] 0x803c6f34
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.844788] [<803a98a0>] 0x803a98a0
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.848313] [<803d1bc0>] 0x803d1bc0
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.851802] [<803d2f18>] 0x803d2f18
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.855307] [<8e86426c>] 0x8e86426c [nf_conntrack_ipv4@8e864000+0x1420]
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.861893] [<803a9da0>] 0x803a9da0
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.865406] [<803aa078>] 0x803aa078
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.868887] [<803a9940>] 0x803a9940
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.872360] [<803a9c10>] 0x803a9c10

Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.402270] ------------[ cut here ]------------
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.406908] WARNING: CPU: 1 PID: 0 at net/ipv4/tcp_output.c:2509 0x803cc8bc
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.413864] invalid inflight: 1 state 1 cwnd 10 mss 1388
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.419148] Modules linked in: qcserial pppoe ppp_async option cdc_mbim usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm cdc_ncm cdc_ether 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 wireguard usbserial usbnet usblp ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.489628]  nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt cdc_wdm cdc_acm fuse ledtrig_usbport gpio_beeper input_core xt_set ip_set_list_set ip_set_hash_netportnet 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 ip6_udp_tunnel udp_tunnel tun vfat fat nls_utf8 nls_iso8859_1 nls_cp437 uas usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd ehci_platform
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.561103]  sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common mii crc32c_generic
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.572189] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.143 #0
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.578264] Stack : 00000000 00000000 00000000 81222398 00000000 00000000 00000000 00000000
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.586600]         00000000 00000000 00000000 00000000 00000000 00000001 8fc0bd30 ac07f596
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.594938]         8fc0bdc8 00000000 00000000 00004f18 00000038 8049db58 00000007 00000000
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.603273]         00000000 80550000 0008bb1d 00000000 8fc0bd10 00000000 80570000 8050c6a0
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.611605]         803cc8bc 000009cd 812223d8 81222398 00000000 802af9e8 00000004 805b0004
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.619937]         ...
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.622376] Call Trace:
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.622394] [<8049db58>] 0x8049db58
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.628288] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.631755] [<802af9e8>] 0x802af9e8
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.635228] [<800101a0>] 0x800101a0
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.638699] [<800101a8>] 0x800101a8
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.642170] [<80486a9c>] 0x80486a9c
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.645638] [<800758a0>] 0x800758a0
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.649107] [<80032588>] 0x80032588
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.652580] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.656052] [<80032610>] 0x80032610
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.659528] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.663008] [<803cf3d0>] 0x803cf3d0
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.666478] [<8009d750>] 0x8009d750
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.669947] [<803cf7a8>] 0x803cf7a8
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.673420] [<8009dd80>] 0x8009dd80
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.676890] [<803cf770>] 0x803cf770
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.680358] [<8008c2cc>] 0x8008c2cc
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.683829] [<80063018>] 0x80063018
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.687300] [<8008c588>] 0x8008c588
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.690768] [<8007cee8>] 0x8007cee8
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.694244] [<804a49b8>] 0x804a49b8
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.697717] [<80036f14>] 0x80036f14
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.701185] [<8025d440>] 0x8025d440
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.704662] [<8000b488>] 0x8000b488
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.708131]
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.709665] ---[ end trace 0dde230055179878 ]---

Hello

Every few weeks I have to restart the 2.4 GHz radio or reboot my Archer C7 v2 router otherwise no client can connect to it.
All stations end up being “deauthenticated due to inactivity” and can’t reconnect.

Tested on OpenWRT 18.06.4. It is quite hard to reproduce for me as it doesn’t happen frequently.

Forum post: https://forum.openwrt.org/t/ath9k-on-archer-c7-v2-disassociated-due-to-inactivity/13328

When a static IPv4 lease is set up for a MAC address, odhcpd assigns that address even if it is outside the configured subnet of the relevant interface.

This is a problem if one wants to set a static lease for a host that may connect to one of multiple interfaces. It is also not possible to set separate static leases for each interface, as only the last one is used.

Software versions of OpenWrt/LEDE release, packages, etc:

Trunk and 19.07.
18.06 is unaffected.

It looks like this was introduced with https://git.openwrt.org/?p=project/odhcpd.git;a=commit;h=ca8ba91c757b1559bc6391707547d54477c8315a.

Steps to reproduce:

Steps based on fresh install of OpenWrt:

Replace odhcpd-ipv6only by odhcpd

Enable odhcpd for IPv4 and set static lease with IPv4 address outside the default lan subnet:

uci set dhcp.odhcp.maindhcp=1
uci set dhcp.lan.dhcpv4="server"

uci add dhcp host
uci set dhcp.@host[-1].mac="11:22:33:44:55:66"
uci set dhcp.@host[-1].ip="192.168.2.100"

uci commit dhcp

Expected result: IP address from 192.168.1.0/24 is assigned to host 11:22:33:44:55:66
Actual result: IP address 192.168.2.100 is assigned to host 11:22:33:44:55:66

I’ve encountered an issue with ntpd in OpenWrt where it cannot acquire the time on an IPv6 only network, it seems that the issue lies in dns resolution by ntpd as specifying an IPv6 address instead of a domain works as expected.

By the way, I believe only 2.pool.ntp.org returns IPv6 addresses in case anyone tries to reproduce my issue.

Possibly relevant: https://dev.archive.openwrt.org/attachment/ticket/12167/0001-busybox-make-ntpd-prefer-IPv6-addresses.patch

ip link set mtu 9000 dev eth0
RTNETLINK answers: Invalid argument

swconfig dev eth0 show

no sign of jumbo frames.

Only a payload of 1474 can be transmitted over a mtu 9000 core network, effectively.

Related issue:
https://dev.archive.openwrt.org/ticket/18296

I’m managing a network with 25 openwrt WLAN access points (mostly TL-WR1043ND v1, a few v2 and a few zbt-2626) and since updating to 19.07 some devices often have an incorrect time. All are configured to get their NTP server from DHCP and this happen on all models.

When this happen ntpd is simply not running and starting it restore the correct time right away. It is hard to says if ntpd crash or if it never started in the first place. Last time I checked all affected devices had been restarted recently so I would first suspect some race condition during boot.

GL-B1300
19.07-SNAPSHOT

Every time I run a sys upgrade I get “failed to sync jffs2 overlay” message in the log (log is configured during the setup by a custom script under /etc/uci-defaults). The error happens during execution of the command: “cp -a /tmp/root/upper/* / 2>/dev/null” in “libfstools/overlay.c”. By the time the copy command runs, the files under /etc/uci-defaults are already deleted and it looks like the “deletion marker” files cannot be copied in this case.

I re-run the command myself after a successful upgrade and got the following logs.

cp -a /tmp/root/upper/* /root/test/
cp: can’t create ‘/root/test/etc/uci-defaults/luci-sqm’: Operation not permitted
cp: can’t create ‘/root/test/etc/uci-defaults/ddns’: Operation not permitted
cp: can’t create ‘/root/test/etc/uci-defaults/bcp38’: Operation not permitted

ls -la /tmp/root/upper/etc/uci-defaults/
c——— 1 root root 0, 0 Nov 26 16:48 bcp38
c——— 1 root root 0, 0 Nov 26 16:48 ddns
c——— 1 root root 0, 0 Nov 26 16:48 luci-sqm

More details: https://forum.openwrt.org/t/getting-error-failed-to-sync-jffs2-overlay/47742

Device is Linksys EA6350v3

Issue occurs on 19.07 rc1, 19.07 rc2 and snapshot r11595 (snapshot version is by memory, but pretty sure that’s what I had on it).

Information for this bug report is based on 19.07 rc2 with the following packages installed for future potential use, but most not in use:
luci-app-sqm luci-proto-wireguard luci-app-wireguard ca-bundle curl https_dns_proxy luci-app-https_dns_proxy luci-app-statistics luci-app-samba kmod-usb-printer p910nd luci-app-p910nd diffutils minidlna luci-app-minidlna

Note: sqm, wireguard, https_dns_proxy, samba, usb printer, p910nd server, and minidlna are NOT in use. These are just the typical packages I add to my
router for future use.

Steps to reproduce:
Problem occurs after router runs for a few hours. EA6350v3 is set up as a wired access point for an EdgeRouter X (also on 19.07 rc2). The Edgerouter provides sqm and DNS and DHCP for LAN, guest and IOT VLANs. There are ~3 “Guest” 2.4 G wifi clients (a smart switch, an IP camera, a DEEBOT vacuum); the IOT VLAN is mapped to a physical port with an Ooma Telo plugged in (I know - I need to map the guest devices to IOT wifi someday...). The LAN is mapped to a physical port with a Roku 3 plugged in and to normal wifi. There are another ~4 or 5 5GHz wifi clients on the LAN wifi (a laptop, a couple Amazon Echo’s, a Google Home Mini, a Samsung Orbit Android phone) and a 2.4G LG Android phone on the 2.4 GHz wifi. CPU loading is quite low.

Memory usage starts out rather high (~100MB, climbs and climbs, eventually drops, climbs again, repeats. Eventually (a day or two) processes start getting killed to free up memory and things start dying. I have an EA8500 setup almost identically as a second AP in the house, and it’s memory usage sits around 50 MB versus 100MB to 200+MB for the EA6350v3. Something’s just not right...

The final message in the logs that repeats until processes begin to get killed is:

kern.warn kernel: [15897.905286] ath10k_ahb a000000.wifi: failed to increase tx pending count: -16, dropping

But the weird memory usage pattern precedes this message in the logs.

I’ve attached memory usage graphs and system and kernel logs from 19.07 rc2 to illustrate the problem. rc1 and snapshot behaved the same. This post also has logs showing processes getting killed if that helps diagnose: https://forum.openwrt.org/t/ipq4018-linksys-ea6350v3-wifi-dead-after-24-48-hrs/49080/3?u=eginnc

Probably, FAO "John Crispin" Lantiq maintainer, apparently!,

On OpenWRT 19.07.0rc2, both on TP-LINK TD-W8980 and also BT-Homehub-v5-type-A [lantiq xrx200 devices] ...

I am finding a consistent frustrating limitation, that the default config, and LuCI web interface, does not provide any way to expose the MTU capability of the built-in VDSL driver, which allows for full 1500 MTU to be carried on PPPoE on VDSL, as is commonplace in provided routers.

Specifically, the VDSL device "dsl0" (and, in my case, VLAN 101, "dsl0.101"), has an unhelpful default MTU restriction to 1500, such that PPPoE (as is common in UK!) does not work at the normally expected 1500MTU, requiring workarounds 1492MTU MSS-clamping hacks. Turns out this is fixable at the configuration-level, but not via anything exposed in web-interface (as underlying DSL MTU is wrong from the start...).

Example below, extra /etc/config/network lines to support the standard MTU:-

      option ifname 'dsl0.101'
      option proto 'pppoe'
      option password 'PASSWORD'
      option ipv6 'auto'
      option username 'USERNAME'
      option mtu '1500'           #exposed via web, still needs setting, to try to negotiate that MTU 1500 inside PPPoE...

      option name 'dsl0'
      option macaddr 'e8:11:22:33:44:4b'
      option mtu '1508'           #This line Had to be added manually

      option name 'dsl0.101'             #  MTU wrong for the dsl 0.101 link!
      option macaddr 'e8:11:22:33:44:4b' #  As in this case having to use VLAN101
      option mtu '1508'                  #  As per UK Openreach VDSL configuration...

Hi there!

I recently upgraded my TP-Link TL-WR1043 v2 device to the ath79 targeted 19.07-rc2 release using my custom build, which I have compiled with the image builder.

make image PROFILE=tplink_tl-wr1043nd-v2 PACKAGES="block-mount curl diffutils ethtool iperf3 iwinfo htop kmod-fs-ext4 kmod-usb-storage luci mailsend-nossl minidlna nfs-kernel-server ppp-mod-pppoe shadow-su transmission-daemon-mbedtls transmission-web vsftpd zram-swap -ip6tables -kmod-ip6tables -kmod-ipv6 -kmod-nf-conntrack6 -kmod-nf-ipt6 -libopenssl1.1 -odhcp6c -odhcpd-ipv6only -luci-proto-ipv6 -libip6tc2"

I just recently rolled back to an EXT4 partition, because of it's smaller memory footprint. (just mounting a ~50GB f2fs partition consumes around 10MBs of memory)
So in the very first attempt I wanted to copy back everything to my Transcend 790K. But after the first 500-1000 MBs(mix of archives, image, text and video files), the transaction speed has fallen down couple of times. I thought maybe the passive FTP connection was the problem, because after a few automatic reconnect attempts, the speed of the copy has been normalized again and in the end the device was connected. Later I found that the USB devices was reseted.
I had another try with a Sandisk Ultra Fit drive (SDCZ-43), but the result and the configuration was pretty sam. ~50GB EXT4 partition without journal and without barrier.
I force upgraded the machine to the ar71xx target and Filezilla so far copied back 16GBs without any problem.
Target ATH79 seem to be has so many problems with the USB subsystem, please see my other bugreport for the WDR4300 as well: FS#2567 - [ATH79] USB speed degradation on WDR4300.

Let me know if I can help the bughunting any way,
thanks and regards!

There is a problem with creating chrooted SFTP access using OpenSSH package. However, it seems that the problem isn’t with the package, rather with realpath function of OpenWRT. The whole description of the problem was already provided in forum, here I only copy the part of the log file:

Nov 29 10:06:27 OpenWrt internal-sftp[12557]: realpath "."
Nov 29 10:06:27 OpenWrt internal-sftp[12557]: debug3: request 46352: sent status 2
Nov 29 10:06:27 OpenWrt internal-sftp[12557]: sent status No such file

Tested on both 18.06.5 and 19.07.0-rc1 with the same result.

OpenWrt 19.07.0-rc2, latest openwrt-packages.

Occurs on at least ath79 but looking at the code this is not device-specific.

1. Have USB devices for which you have hotplug scripts (e.g. from p910d and sane-backends)
2. Boot (or reboot) with usb devices already plugged in.
3. Observe that the actions in the hotplug script (e.g. setting permissions / group ownership that don’t belong in the base system (i.e. hotplug.json)) as it’d be bloat to detect product:vendor ip pairs and take appropriate action for all the various packages and devices hotplug handles – if hotplug.json could have hotplug.json.d or somesuch it would alleviate most of this pain.

Looking at the procd code coldplug (udevtrigger) is called during ‘early’ init, which means that hotplug.d scripts are not yet present. Because /etc/init.d/boot (or any other initscript) no longer does a later call to udevtrigger, the events get missed).

If udevtrigger were called during regular init this wouldn’t be an issue (but probably the coldplug is needed earlier *as well* for devices needed to boot the system.

See also #1903 and #996 (they are likely the same root cause).

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

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

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

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

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

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

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

On my Clearfog Pro Rev 2.0 the interfaces map as follows:

eth0: switch
eth1: SFP
eth2: standalone ethernet

This does not match the current description in /etc/board.d/02_network:

# eth0 is standalone ethernet
# eth1 is switch (-pro) or standalone ethernet (-base)
# eth2 is SFP
ucidef_set_interfaces_lan_wan "eth1" "eth0 eth2"

While I don’t agree with the lan/wan decision made here, at least the comment should match reality.
So I suggest changing it to:

# eth2 is standalone ethernet
# eth0 is switch (-pro) or standalone ethernet (-base)
# eth1 is SFP
ucidef_set_interfaces_lan_wan "eth0 eth1" "eth2"

Please also see the attached patch file, which also changes the switch configuration accordingly.

Supply the following if possible:

- Device problem occurs on
Archer C7v2

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

[---] PACKAGES INSTALLED
echo [INFO] Downloading package information ...
opkg update
#
echo [INFO] Removing packages ...
opkg remove wpad-basic
#
echo [INFO] Installing packages ...
opkg install bash
opkg install block-mount
opkg install curl
opkg install e2fsprogs
opkg install htop
# opkg install igmpproxy
opkg install kmod-br-netfilter
opkg install kmod-fs-ext4
opkg install kmod-fs-msdos
opkg install kmod-fs-ntfs
opkg install kmod-scsi-core
opkg install kmod-usb-storage
opkg install libncurses
opkg install libpcre
opkg install lua luafilesystem
opkg install luci-mod-rpc
opkg install luci-proto-relay
opkg install mailsend
opkg install nano
opkg install relayd
opkg install rpcd
opkg install terminfo
opkg install tcpdump
opkg install uhttpd-mod-ubus
opkg install vsftpd
opkg install wget
opkg install wpad
#
# batman-adv
opkg install kmod-batman-adv
opkg install batctl-full
[---]

- Steps to reproduce
Today worked on batman-adv via ad-hoc between two devices. Device A has LAN to bat0, batman-adv works over ad-hoc wifi, Device B has bat0 to LAN. (Device B has only one wired client behind)
Both devices (Archer C7v2 with OpenWrt 19.07-rc.2) had multiple crashes of the below printed type resulting in only 10 MBit/s download speed on the computer attached via LAN to Device B. Before the kernel.warn log line appeared on one of the APs, the speed was full 100 MBit/s. As soon I reboot the “kernel.warn”ing AP, the speed is 100 MBit again. bat0 is bridged to eth0.101 on both ends.

Sat Dec 28 14:50:04 2019 daemon.notice hostapd: wlan0-1: AP-ENABLED
Sat Dec 28 14:50:05 2019 kern.info kernel: [ 2416.392454] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat Dec 28 14:50:05 2019 daemon.notice wpa_supplicant[16106]: Successfully initialized wpa_supplicant
Sat Dec 28 14:50:06 2019 kern.info kernel: [ 2417.755684] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat Dec 28 14:50:06 2019 daemon.notice wpa_supplicant[16106]: Note: nl80211 driver interface is not designed to be used with ap_scan=2; this can result in connection failures
Sat Dec 28 14:50:06 2019 daemon.notice wpa_supplicant[16176]: wlan0: Trying to associate with SSID 'Permakultur'
Sat Dec 28 14:50:06 2019 kern.info kernel: [ 2417.950938] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2417.991646] ------------[ cut here ]------------
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2417.996394] WARNING: CPU: 0 PID: 16176 at /builder/shared-workdir/build/build_dir/target-mips_24kc_musl/linux-ath79_generic/ath10k-ct-2019-09-09-5e8cd86f/ath10k-4.19/mac.c:6598 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.016231] Modules linked in: ath9k ath9k_common pppoe ppp_async batman_adv ath9k_hw ath10k_pci ath10k_core ath pppox ppp_generic nf_conntrack_ipv6 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 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 libcrc32c iptable_mangle iptable_filter ip_tables crc_ccitt compat br_netfilter ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 msdos vfat fat ntfs nls_utf8 nls_iso8859_1 nls_cp437
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.088204]  usb_storage sd_mod scsi_mod ext4 mbcache jbd2 crc16 crc32c_generic crypto_hash ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.103218] CPU: 0 PID: 16176 Comm: wpa_supplicant Tainted: G        W       4.14.156 #0
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.111503] Stack : 000000f8 800b2a94 80500000 804af544 00000000 00000000 00000000 00000000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.120128]         00000000 00000000 00000000 00000000 00000000 00000001 853c59d8 ebe9a33e
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.128783]         853c5a70 00000000 00000000 00009378 00000038 80447958 00000008 00000000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.137442]         000001c9 6e8dd5be 000001c8 00000000 853c59b8 80000000 00000000 8704e480
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.146036]         8700bd24 000019c6 86310d28 87428800 00000003 8027f944 00000000 80630000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.154570]         ...
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.157183] Call Trace:
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.157198] [<800b2a94>] 0x800b2a94
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.163293] [<80500000>] 0x80500000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.166873] [<80447958>] 0x80447958
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.170485] [<8700bd24>] 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.176813] [<8027f944>] 0x8027f944
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.180352] [<8006a56c>] 0x8006a56c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.184017] [<8006a574>] 0x8006a574
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.187559] [<80084c20>] 0x80084c20
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.191102] [<8700bd24>] 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.197583] [<80084d08>] 0x80084d08
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.201136] [<80318194>] 0x80318194
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.204714] [<8700bd24>] 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.211078] [<87795f70>] 0x87795f70 [mac80211@87780000+0x6c280]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.217204] [<8772d0d0>] 0x8772d0d0 [cfg80211@87700000+0x363f0]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.223313] [<8772941c>] 0x8772941c [cfg80211@87700000+0x363f0]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.229530] [<8771ddc0>] 0x8771ddc0 [cfg80211@87700000+0x363f0]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.235711] [<80134f00>] 0x80134f00
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.239316] [<80350498>] 0x80350498
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.243000] [<803501ac>] 0x803501ac
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.246630] [<8034eb44>] 0x8034eb44
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.250375] [<8034f410>] 0x8034f410
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.253980] [<8034c9bc>] 0x8034c9bc
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.257540] [<8034e208>] 0x8034e208
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.261197] [<8034e6e4>] 0x8034e6e4
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.264845] [<802f7c1c>] 0x802f7c1c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.268386] [<8034bcf8>] 0x8034bcf8
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.271988] [<8034e308>] 0x8034e308
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.275625] [<802f7e7c>] 0x802f7e7c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.279170] [<800ac680>] 0x800ac680
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.282723] [<802f5f34>] 0x802f5f34
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.286301] [<802f6718>] 0x802f6718
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.289840] [<8034bdec>] 0x8034bdec
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.293390] [<802f681c>] 0x802f681c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.297024] [<8013fd78>] 0x8013fd78
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.300656] [<802fd5c0>] 0x802fd5c0
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.304252] [<802f8704>] 0x802f8704
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.307808] [<802f6718>] 0x802f6718
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.311405] [<8006f72c>] 0x8006f72c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.314981] [<802f84a4>] 0x802f84a4
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.318624]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.320140] ---[ end trace b03503722668fd71 ]---
Sat Dec 28 14:50:07 2019 kern.info kernel: [ 2418.329016] wlan0: Selected IBSS BSSID [MAC] based on configured SSID
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0-1' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0-2' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0-3' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' is enabled
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' has link connectivity
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' is setting up now
Sat Dec 28 14:50:07 2019 kern.info kernel: [ 2418.899578] batman_adv: bat0: Adding interface: wlan0
Sat Dec 28 14:50:07 2019 kern.info kernel: [ 2418.904876] batman_adv: bat0: Interface activated: wlan0
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' is now up
Sat Dec 28 14:50:08 2019 daemon.notice wpa_supplicant[16176]: wlan0: Associated with [MAC]

- Device problem occurs on mvebu platform - Linksys wrt3200acm Marvell 88W8964 802.11bgn wifi while trying to connect by esp8266
- Software versions OpenWrt 19.07

esp8266 is not getting dhcp address and even when trying to communicate with static IP it is not possible to acquire connection. esp8266 is unable to get access to the router. Same problem exists in openwrt 18.06

Supply the following if possible:
- Device problem occurs on: Buffalo WBMR-HP-G300H
- Software versions of OpenWrt/LEDE release, packages, etc.: OpenWRT 19.07, kmod-ltq-adsl-ar9-fw-a 0.1-1, which shows up as 4.4.4.0.0.1 in dsl_control status.
- Steps to reproduce:

1. Get an ADSL line from Rostelecom.
2. Upgrade the router to OpenWRT 19.07.
3. Reboot.

Result: DSL does not connect. In /etc/init.d/dsl_control status, it goes through all phases, then briefly shows as “Up”, but then the “dsl0” interface is not created, and the following lines are logged in dmesg:

 [   56.597766] [DSL_BSP_Showtime 914]: Datarate US intl = 1024000, fast = 0
 [   56.603091] [DSL_BSP_Showtime 934]: no hookup from ATM driver to set cell rate

The error does not exist with the 4.5.4.9.1.1 firmware obtained from unofficial sources. The bug has been submitted through the affected ADSL line with the unofficial firmware.

Status:

# /etc/init.d/dsl_control status
ATU-C Vendor ID: Broadcom 161.149
ATU-C System Vendor ID: 00,00,00,00,00,00,00,00
Chipset: Ifx-AR9
Firmware Version: 4.5.4.9.1.1
API Version: 3.24.4.4
XTSE Capabilities: 0×4, 0×0, 0×0, 0×0, 0×0, 0×0, 0×0, 0×0 Annex: A
Line Mode: G.992.1 (ADSL)
Profile:
Line State: UP [0×801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 413342 / Far: 0
Errored seconds (ES): Near: 0 / Far: 0
Severely Errored Seconds (SES): Near: 0 / Far: 0
Loss of Signal Seconds (LOSS): Near: 0 / Far: 0
Unavailable Seconds (UAS): Near: 253 / Far: 253
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: / Far:
Pre-emtive CRC errors (CRCP_P): Near: / Far:
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 8.0 ms [Interleave] 8.0 ms [Interleave]
Data Rate: Down: 9.952 Mb/s / Up: 1.024 Mb/s
Line Attenuation (LATN): Down: 32.2 dB / Up: 19.5 dB
Signal Attenuation (SATN): Down: 32.6 dB / Up: 19.5 dB
Noise Margin (SNR): Down: 6.1 dB / Up: 13.0 dB
Aggregate Transmit Power (ACTATP): Down: 20.0 dB / Up: 12.3 dB
Max. Attainable Data Rate (ATTNDR): Down: 8.848 Mb/s / Up: 1.204 Mb/s
Line Uptime Seconds: 1164
Line Uptime: 19m 24s

(yes, very bad line)

Config:

config atm-bridge ‘atm’

option vpi '1'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
option vci '50'
option unit '0'
option atmdev '0'

config dsl ‘dsl’

option annex 'a'
option firmware '/lib/firmware/dsl_ar9_firmware_adsl_a-04.05.04.09.01.01.bin'

config interface ‘wan’

option ifname 'dsl0'
option proto 'pppoe'
option ipv6 '1'
option username 'censored'
list dns '8.8.8.8'
list dns '8.8.4.4'
option peerdns '0'
option keepalive '60 5'
option password 'censored'

19.07.0 running on WNDR3700v2, 32MB of memory. The machine is certainly not short on memory:

                total        used        free      shared  buff/cache   available
  Mem:          59560       26912       24108         956        8540       16564
  Swap:             0           0           0

Running “opkg update” a first time works fine. However, if I run “opkg update” a second time, it reports:

  Collected errors:
   * pkg_hash_add_from_file: Failed to open /var/opkg-lists/openwrt_routing: Out of memory.

After doing “rm /var/opkg-lists/openwrt_*”, everything works fine again.

After upgrading my Netgear WNDR3700 v2 to 19.07 (ath79 target), the WiFi cards aren’t detected.

Here are the outputs of dmesg, logread, lsmod | grep ath, ls /sys/bus/pci/*, lspci -vnn; at the recommendation of PaulFertser in #openwrt, I tried echo -n 168c ff1d > /sys/bus/pci/drivers/ath9k/new_id, which resulted in some error messages in dmesg, but the WiFi interfaces still aren’t detected (wifi config produces an empty file).

With ar71xx target, wifi works; the cards seem to have a different http://p.0au.de/3393221e/, too. dmesg, logread, ls /sys/bus/pci/*.

My device: TP-Link Archer C7 v2.0 (JP)
My software stack: OpenWrt 19.07

My router uses odhcpd’s relay mode to relay IPv6 neighbor discovery protocol and router advertisements from the uplink router.

My linux-based system connected to the router is able to get IPv6 connectivity through the router without problems.

However, my macOS-based system doesn’t get IPv6 connectivity. It gets a global IPv6 prefix, which suggests that it’s able to receive RA packets, but my router is also unable to ping6 the macOS system by it’s globally unique address, and doing ip -6 neigh on the router makes it clear that the router doesn’t know the MAC address of the macOS system, and all of it’s probes to find it, end up failing.

Inspecting the ICMPv6 traffic in the LAN shows that my macOS system doesn’t respond to the neighbor solicitation packets send by the router. Here’s an example of such a packet:

02:28:50.006540 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fd26:e9f1:e833::1 > ff02::1:ff65:88f8: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2404:7a80:9621:7100:404:978a:5765:88f8

  source link-address option (1), length 8 (1): 18:a6:f7:8d:c0:d3

Here, fd26:e9f1:e833::1 is the ULA of the LAN interface of the router.

According to Apple discussion board ( https://discussions.apple.com/thread/8620806 ) macOS seems to have a behaviour such that it ignores neighbor solicitation packets unless the source address of the packet is a link-local address.

Indeed, commenting out option ula_prefix in /etc/config/network makes odhcpd to use link-local addresses, and that makes macOS to respond to neighbor solicitation queries, and in my system, demonstrably restores IPv6 connectivity.

Since macOS is a very common operating system, it would be benefical if odhcpd’s default behaviour were to use LLA in NDP packets. The current situation of not being able to set ULA prefix without losing connectivity is unfortunate. (And I think that ULA prefix is set by default in OpenWRT, which makes macOS not play together with it by default.)

For reference, here’s a forum thread I documented my forays into inspecting this problem: https://forum.openwrt.org/t/how-to-send-icmp6-neighbor-solicitation-with-a-link-local-source-address/53220

Could the default source address of odhcpd’s NDP/RA packets be changed to LLA?

19.07-SNAPSHOT

I am trying to put together an image for gl-b1300 (ipq40xx) using the image builder and it is failing with the error below. I looked at the base packages for 19.07 and the htt variants are missing for all ath10k-firrmware-qca supported targets. I also checked ipq806x for 19.07 and the htt firmware is present there.
Looking at master: the ipq40xx target does include htt packages.

Are the htt firmware files excluded from ipq40xx in 19.07 for a reason?

Collected errors:
* opkg_install_cmd: Cannot install package ath10k-firmware-qca4019-ct-htt.
Makefile:153: recipe for target ‘package_install’ failed
make[2]: * [package_install] Error 255
Makefile:112: recipe for target ‘_call_image’ failed
make[1]: * [_call_image] Error 2
Makefile:196: recipe for target ‘image’ failed
make: *** [image] Error 2

I have a directory where I keep imagebuilder. I can sucessfully build custom images there for d-link/dir-825, xiaomi/mini, tp-link/wr842nd_v1 and linksys/wrt1900ac. But trying to create default image for ar71xx/mikrotik gives error:

...
Successfully writed 13 blocks and 1757184 bytes
Each block contain 64 chanks + 0 bytes tail hole.
Each chunk(2112 bytes) consists: data part(2048 bytes) + oob part(64 bytes).
mv: cannot stat '/mydir/openwrt/imagebuilder/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/tmp/openwrt-19.07.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin.new': No such file or directory
make[3]: *** [Makefile:71: /mydir/openwrt/imagebuilder/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/tmp/openwrt-19.07.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin] Error 1
make[2]: *** [Makefile:169: build_image] Error 2
make[1]: *** [Makefile:120: _call_image] Error 2
make: *** [Makefile:197: image] Error 2

It can be reproduced:

% mkdir /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
% cd /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
% wget https://downloads.openwrt.org/releases/19.07.0/targets/ar71xx/mikrotik/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64.tar.xz
% tar xf openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64.tar.xz
% cd openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64
% make image PROFILE=nand-large
...
1671656 bytes (1.7 MB, 1.6 MiB) copied, 0.00693055 s, 241 MB/s
Can't get lstat from kernel file!: No such file or directory
make[3]: *** [Makefile:71: /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/tmp/openwrt-19.07.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin] Error 255
make[2]: *** [Makefile:169: build_image] Error 2
make[1]: *** [Makefile:120: _call_image] Error 2
make: *** [Makefile:197: image] Error 2
zsh: exit 2     make image PROFILE=nand-large

Device: TP-Link Archer A7 (RU) Ver 5.0
Software: OpenWRT 19.07.0

I just bought this router. And I trying to flash it with openwrt-19.07.0-ath79-generic-tplink_archer-a7-v5-squashfs-factory.bin trough tftp.
In wireshark I clearly see that file was downloaded. But router didn’t flashed.
I tried to flash snapshot image wtih same result.
I checked sha256 sums and it matches.

When I reproduced same steps with original TP-Link update image it worked well. Seems like something prevents router from flashing OpenWRT image.