Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

Dear Mathias,

I can confirm your patch is working fine. I am able to set a mtu of
1508 on the switch, giving me a mtu of 1500 on the pppoe-wan
connection. I am now able to ping 1472 bytes with the DF flag set. The
patch in question:
https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commitdiff;h=cc5f1fe7aa02943f3b39ffbd9dc3b8fcad569c8f

Thank you very much for your work :)

@the rest

I was able to flash simply by disabling all my WiFi interfaces. It's a
dirty workaround and should be fixed before a 18.06 release IMO, but
at least we managed to track down what's causing the issue :)

Yours sincerely,

Jaap Buurman

On Sat, May 26, 2018 at 9:16 AM, Kristian Evensen
 wrote:
> Hi,
>
> (Accidentally hit send)
>
> On Fri, May 25, 2018 at 7:06 PM, Kristian Evensen
>  wrote:
>>> I know how to fix the issue by recovery, however, from the responses
>>> in the topic on the Lede forum it seems more people are running into
>>> this issue. This definitely needs to be fixed before a 18.06 release.
>>> Is there someone with a mt7621 device that can reproduce the problem,
>>> and that has serial access? We might be able to figure out what is
>>> going wrong.
>
> I kept looking into this and instrumented /lib/upgrade/stage2. I added
> some output showing which processes were left for each iteration of
> the loop, as well as when "Failed to kill ..." hits. It seems that
> hostapd, for some reason, takes unexpectedly long to die:
>
> Sending TERM to remaining processes ... loop limit 10
> logd
> rpcd
> netifd
> odhcpd
> crond
> ntpd
> nginx
> nginx
> ubusd
> dnsmasq
> sh
> sh
> sh
> sshd
> sleep
> sh
> hostapd
> hostapd
> rsync
> ssh
> sleep
>
> [  115.583843] device wlan0 left promiscuous mode
> [  115.588436] br-lan: port 3(wlan0) entered disabled state
> [  115.594261] device wlan1 left promiscuous mode
> [  115.598798] br-lan: port 2(wlan1) entered disabled state
> Sending KILL to remaining processes ... loop limit 10
> hostapd
> loop limit 9
> hostapd
> loop limit 8
> hostapd
> loop limit 7
> hostapd
> loop limit 6
> hostapd
> loop limit 5
> hostapd
> loop limit 4
> hostapd
> loop limit 3
> hostapd
> loop limit 2
> hostapd
> loop limit 1
>
> Failed to kill all processes.
>   PID USER   VSZ STAT COMMAND
> 1 root   992 S/sbin/upgraded /tmp/firmware.bin . /lib/functions.sh
> 2 root 0 SW   [kthreadd]
> 3 root 0 IW   [kworker/0:0]
> 4 root 0 IW<  [kworker/0:0H]
> 5 root 0 IW   [kworker/u8:0]
> 6 root 0 IW<  [mm_percpu_wq]
> 7 root 0 SW   [ksoftirqd/0]
> 8 root 0 IW   [rcu_sched]
> 9 root 0 IW   [rcu_bh]
>10 root 0 SW   [migration/0]
>11 root 0 SW   [cpuhp/0]
>12 root 0 SW   [cpuhp/1]
>13 root 0 SW   [migration/1]
>14 root 0 SW   [ksoftirqd/1]
>15 root 0 IW   [kworker/1:0]
>16 root 0 IW<  [kworker/1:0H]
>17 root 0 SW   [cpuhp/2]
>18 root 0 SW   [migration/2]
>19 root 0 SW   [ksoftirqd/2]
>20 root 0 IW   [kworker/2:0]
>21 root 0 IW<  [kworker/2:0H]
>22 root 0 SW   [cpuhp/3]
>23 root 0 SW   [migration/3]
>24 root 0 SW   [ksoftirqd/3]
>25 root 0 IW   [kworker/3:0]
>26 root 0 IW<  [kworker/3:0H]
>27 root 0 IW   [kworker/u8:1]
>34 root 0 IW   [kworker/u8:2]
>65 root 0 IW   [kworker/0:1]
>66 root 0 IW   [kworker/3:1]
>67 root 0 IW   [kworker/2:1]
>   136 root 0 IW   [kworker/1:1]
>   137 root 0 SW   [oom_reaper]
>   138 root 0 IW<  [writeback]
>   140 root 0 IW<  [crypto]
>   142 root 0 IW<  [kblockd]
>   157 root 0 IW   [kworker/u8:3]
>   177 root 0 IW<  [watchdogd]
>   201 root 0 SW   [kswapd0]
>   233 root 0 IW<  [pencrypt]
>   262 root 0 IW<  [pdecrypt]
>   295 root 0 SW   [spi0]
>   353 root 0 IW<  [ipv6_addrconf]
>   362 root 0 IW<  [kworker/1:1H]
>   363 root 0 IW<  [kworker/0:1H]
>   365 root 0 IW<  [kworker/3:1H]
>   366 root 0 IW<  [kworker/2:1H]
>   416 root 0 IW   [kworker/1:2]
>   417 root 0 IW   [kworker/0:2]
>   457 root 0 SWN  [jffs2_gcd_mtd6]
>   575 root 0 IW   [kworker/2:2]
>   869 root 0 IW<  [cfg80211]
>  1842 root 0 IW   [kworker/3:2]
>  7535 root  1328 S/bin/sh /lib/upgrade/stage2 /tmp/firmware.bin . /lib
>  7547 root  1184 R/bin/ps
> sysupgrade abort[  124.152193] reboot: Restarting system
> ed with return code: 256
>
> With a working update, KILL usually looks like this:
> Sending KILL to remaining processes ... loop limit 10
> hostapd
> hostapd
> celerway_wd
> loop limit 9
> hostapd
> hostapd
> loop limit 8
> hostapd
> hostapd
> loop limit 7
> hostapd
> hostapd
> loop limit 6
> hostapd

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Kristian Evensen]

Hi,

(Accidentally hit send)

On Fri, May 25, 2018 at 7:06 PM, Kristian Evensen
 wrote:
>> I know how to fix the issue by recovery, however, from the responses
>> in the topic on the Lede forum it seems more people are running into
>> this issue. This definitely needs to be fixed before a 18.06 release.
>> Is there someone with a mt7621 device that can reproduce the problem,
>> and that has serial access? We might be able to figure out what is
>> going wrong.

I kept looking into this and instrumented /lib/upgrade/stage2. I added
some output showing which processes were left for each iteration of
the loop, as well as when "Failed to kill ..." hits. It seems that
hostapd, for some reason, takes unexpectedly long to die:

Sending TERM to remaining processes ... loop limit 10
logd
rpcd
netifd
odhcpd
crond
ntpd
nginx
nginx
ubusd
dnsmasq
sh
sh
sh
sshd
sleep
sh
hostapd
hostapd
rsync
ssh
sleep

[  115.583843] device wlan0 left promiscuous mode
[  115.588436] br-lan: port 3(wlan0) entered disabled state
[  115.594261] device wlan1 left promiscuous mode
[  115.598798] br-lan: port 2(wlan1) entered disabled state
Sending KILL to remaining processes ... loop limit 10
hostapd
loop limit 9
hostapd
loop limit 8
hostapd
loop limit 7
hostapd
loop limit 6
hostapd
loop limit 5
hostapd
loop limit 4
hostapd
loop limit 3
hostapd
loop limit 2
hostapd
loop limit 1

Failed to kill all processes.
  PID USER   VSZ STAT COMMAND
1 root   992 S/sbin/upgraded /tmp/firmware.bin . /lib/functions.sh
2 root 0 SW   [kthreadd]
3 root 0 IW   [kworker/0:0]
4 root 0 IW<  [kworker/0:0H]
5 root 0 IW   [kworker/u8:0]
6 root 0 IW<  [mm_percpu_wq]
7 root 0 SW   [ksoftirqd/0]
8 root 0 IW   [rcu_sched]
9 root 0 IW   [rcu_bh]
   10 root 0 SW   [migration/0]
   11 root 0 SW   [cpuhp/0]
   12 root 0 SW   [cpuhp/1]
   13 root 0 SW   [migration/1]
   14 root 0 SW   [ksoftirqd/1]
   15 root 0 IW   [kworker/1:0]
   16 root 0 IW<  [kworker/1:0H]
   17 root 0 SW   [cpuhp/2]
   18 root 0 SW   [migration/2]
   19 root 0 SW   [ksoftirqd/2]
   20 root 0 IW   [kworker/2:0]
   21 root 0 IW<  [kworker/2:0H]
   22 root 0 SW   [cpuhp/3]
   23 root 0 SW   [migration/3]
   24 root 0 SW   [ksoftirqd/3]
   25 root 0 IW   [kworker/3:0]
   26 root 0 IW<  [kworker/3:0H]
   27 root 0 IW   [kworker/u8:1]
   34 root 0 IW   [kworker/u8:2]
   65 root 0 IW   [kworker/0:1]
   66 root 0 IW   [kworker/3:1]
   67 root 0 IW   [kworker/2:1]
  136 root 0 IW   [kworker/1:1]
  137 root 0 SW   [oom_reaper]
  138 root 0 IW<  [writeback]
  140 root 0 IW<  [crypto]
  142 root 0 IW<  [kblockd]
  157 root 0 IW   [kworker/u8:3]
  177 root 0 IW<  [watchdogd]
  201 root 0 SW   [kswapd0]
  233 root 0 IW<  [pencrypt]
  262 root 0 IW<  [pdecrypt]
  295 root 0 SW   [spi0]
  353 root 0 IW<  [ipv6_addrconf]
  362 root 0 IW<  [kworker/1:1H]
  363 root 0 IW<  [kworker/0:1H]
  365 root 0 IW<  [kworker/3:1H]
  366 root 0 IW<  [kworker/2:1H]
  416 root 0 IW   [kworker/1:2]
  417 root 0 IW   [kworker/0:2]
  457 root 0 SWN  [jffs2_gcd_mtd6]
  575 root 0 IW   [kworker/2:2]
  869 root 0 IW<  [cfg80211]
 1842 root 0 IW   [kworker/3:2]
 7535 root  1328 S/bin/sh /lib/upgrade/stage2 /tmp/firmware.bin . /lib
 7547 root  1184 R/bin/ps
sysupgrade abort[  124.152193] reboot: Restarting system
ed with return code: 256

With a working update, KILL usually looks like this:
Sending KILL to remaining processes ... loop limit 10
hostapd
hostapd
celerway_wd
loop limit 9
hostapd
hostapd
loop limit 8
hostapd
hostapd
loop limit 7
hostapd
hostapd
loop limit 6
hostapd
hostapd
loop limit 5
hostapd
hostapd
loop limit 4
hostapd
loop limit 3

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Kristian Evensen]

Hi,

On Fri, May 25, 2018 at 7:06 PM, Kristian Evensen
 wrote:
>> I know how to fix the issue by recovery, however, from the responses
>> in the topic on the Lede forum it seems more people are running into
>> this issue. This definitely needs to be fixed before a 18.06 release.
>> Is there someone with a mt7621 device that can reproduce the problem,
>> and that has serial access? We might be able to figure out what is
>> going wrong.

I kept looking into this and instrumented /lib/upgrade/stage2. I added
some output showing which processes were left for each iteration of
the loop, as well as when "Failed to kill ..." hits. It seems that
hostapd, for some time, takes unexpectedly long to close:

Sending TERM to remaining processes ... loop limit 10
logd
rpcd
netifd
odhcpd
crond
ntpd
nginx
nginx
ubusd
dnsmasq
sh
sh
sh
sshd
sleep
sh
hostapd
hostapd
rsync
ssh
sleep

[  115.583843] device wlan0 left promiscuous mode
[  115.588436] br-lan: port 3(wlan0) entered disabled state
[  115.594261] device wlan1 left promiscuous mode
[  115.598798] br-lan: port 2(wlan1) entered disabled state
Sending KILL to remaining processes ... loop limit 10
hostapd
loop limit 9
hostapd
loop limit 8
hostapd
loop limit 7
hostapd
loop limit 6
hostapd
loop limit 5
hostapd
loop limit 4
hostapd
loop limit 3
hostapd
loop limit 2
hostapd
loop limit 1

Failed to kill all processes.
  PID USER   VSZ STAT COMMAND
1 root   992 S/sbin/upgraded /tmp/firmware.bin . /lib/functions.sh
2 root 0 SW   [kthreadd]
3 root 0 IW   [kworker/0:0]
4 root 0 IW<  [kworker/0:0H]
5 root 0 IW   [kworker/u8:0]
6 root 0 IW<  [mm_percpu_wq]
7 root 0 SW   [ksoftirqd/0]
8 root 0 IW   [rcu_sched]
9 root 0 IW   [rcu_bh]
   10 root 0 SW   [migration/0]
   11 root 0 SW   [cpuhp/0]
   12 root 0 SW   [cpuhp/1]
   13 root 0 SW   [migration/1]
   14 root 0 SW   [ksoftirqd/1]
   15 root 0 IW   [kworker/1:0]
   16 root 0 IW<  [kworker/1:0H]
   17 root 0 SW   [cpuhp/2]
   18 root 0 SW   [migration/2]
   19 root 0 SW   [ksoftirqd/2]
   20 root 0 IW   [kworker/2:0]
   21 root 0 IW<  [kworker/2:0H]
   22 root 0 SW   [cpuhp/3]
   23 root 0 SW   [migration/3]
   24 root 0 SW   [ksoftirqd/3]
   25 root 0 IW   [kworker/3:0]
   26 root 0 IW<  [kworker/3:0H]
   27 root 0 IW   [kworker/u8:1]
   34 root 0 IW   [kworker/u8:2]
   65 root 0 IW   [kworker/0:1]
   66 root 0 IW   [kworker/3:1]
   67 root 0 IW   [kworker/2:1]
  136 root 0 IW   [kworker/1:1]
  137 root 0 SW   [oom_reaper]
  138 root 0 IW<  [writeback]
  140 root 0 IW<  [crypto]
  142 root 0 IW<  [kblockd]
  157 root 0 IW   [kworker/u8:3]
  177 root 0 IW<  [watchdogd]
  201 root 0 SW   [kswapd0]
  233 root 0 IW<  [pencrypt]
  262 root 0 IW<  [pdecrypt]
  295 root 0 SW   [spi0]
  353 root 0 IW<  [ipv6_addrconf]
  362 root 0 IW<  [kworker/1:1H]
  363 root 0 IW<  [kworker/0:1H]
  365 root 0 IW<  [kworker/3:1H]
  366 root 0 IW<  [kworker/2:1H]
  416 root 0 IW   [kworker/1:2]
  417 root 0 IW   [kworker/0:2]
  457 root 0 SWN  [jffs2_gcd_mtd6]
  575 root 0 IW   [kworker/2:2]
  869 root 0 IW<  [cfg80211]
 1842 root 0 IW   [kworker/3:2]
 7535 root  1328 S/bin/sh /lib/upgrade/stage2 /tmp/firmware.bin . /lib
 7547 root  1184 R/bin/ps
sysupgrade abort[  124.152193] reboot: Restarting system
ed with return code: 256

With a working update, KILL usually looks like this:


BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Kristian Evensen]

Hi,

> I know how to fix the issue by recovery, however, from the responses
> in the topic on the Lede forum it seems more people are running into
> this issue. This definitely needs to be fixed before a 18.06 release.
> Is there someone with a mt7621 device that can reproduce the problem,
> and that has serial access? We might be able to figure out what is
> going wrong.

I am seeing the same on my mt7621-based devices. It seems that upgrade
works roughly every second time. Here is output from serial one
sysupgrade that went wrong (i.e., no effect):

Sending TERM to remaining processes ... logd rpcd netifd odhcpd crond
hostapd ntpd hostapd nginx nginx dnsmasq ubusd sh sh sh sh sshd [
416.897350] device wlan0 left promiscuous mode
[  416.902098] br-lan: port 2(wlan0) entered disabled state
ssh [  416.915527] device wlan1 left promiscuous mode
[  416.920286] br-lan: port 3(wlan1) entered disabled state
ssh sleep sleep sleep
Sending KILL to remaining processes ... hostapd chostapd hostapd
hostapd hostapd hostapd hostapd hostapd hostapd /lib/upgrade/stage2:
line 132: can't open /proc/3469/cmdline: no such file

Failed to kill a[  420.497042] reboot: Restarting system
ll processes.
sysupgrade aborted with return code: 256

-Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

On Fri, May 25, 2018 at 1:35 PM, Levente  wrote:
> Try upgrading the sysupgrade image using your bootloader.
>
> Lev
>
> On Fri, May 25, 2018 at 1:25 PM, Jaap Buurman  wrote:
>> On Fri, May 25, 2018 at 1:14 PM, Jaap Buurman  wrote:
>>> On Fri, May 25, 2018 at 12:43 PM, Mathias Kresin  wrote:
 2018-05-25 12:48 GMT+03:00 Jaap Buurman :
> Dear Martin, Mathias and the rest,
>
> Please scratch my previous message. It seems like the flash was not
> successful, and hence I was still running the old firmware. However, I
> have tried flashing 3 different times now, without any luck. The
> router ends up rebooting and boots right into the old firmware. This
> seems to be a major bug. Is there anything I can do to help debug this
> particular issue?

 First of all, Martin is right. The commit in my staging tree should
 fix the MTU issue but I don't have the hardware to test it on my own.

 So far you never mentioned which board you have. Hence it's quite
 difficult to have a look at the code about what could be wrong. It
 would be helpful if you can name the last working revision to limit
 the number of commits to look at.

> Seems like a dealbreaker for 18.06 (which I am
> running now) to me. I could simply use recovery and flash a firmware
> like that, but I would prefer to get to the bottom of this issue so
> that end users won't end up stuck on a particular firmware. Any ideas
> what I could do to debug this?

 Your best bet is to attach the/a serial console and check the console
 for errors.

 Mathias
>>>
>>> My apologies for leaving out important details. I am using a Dir-860L
>>> B1. I used to be running Lede 17.01.4, until last Tuesday. At that day
>>> I upgraded to OpenWrt 18.06-SNAPSHOT r6917-8948a78 via Luci. Flashing
>>> any other firmware seems to be broken now: I have tried flashing a
>>> build compiled from your staging tree, I've tried reverting back to
>>> 17.01.4 and I've tried reflashing 18.06. All end up in the exact same
>>> spot: Still on the OpenWrt 18.06-SNAPSHOT r6917-8948a78 with all
>>> manually installed packages still present. I've tried flashing via
>>> Luci and via the sysupgrade command (with the -v switch for more
>>> verbosity), but no useful information there. The last line that is
>>> output is simply:
>>>
>>> Commencing upgrade. All shell sessions will be closed now.
>>>
>>> One particular weird thing that I do remember on this build, is the
>>> fact that I tried to update all upgradable packages via OPKG (I know
>>> this is discouraged). One of those packages was "base-files". The
>>> upgrade failed with a weird error (can't remember what exactly), but
>>> nothing seemed wrong at that time, so I didn't really think much about
>>> it. Is there anyone more knowledgeable than me that knows whether this
>>> could influence the sysupgrade functionality?
>>>
>>> Lastly, I do not have a serial cable unfortunately, so I think
>>> debugging will be difficult for me. I could use recovery to reflash a
>>> fresh 18.06 build, and see if upgrade functionality is still broken in
>>> that case. I will report back with my findings.
>>>
>>> Yours sincerely,
>>>
>>> Jaap Buurman
>>
>> Dear all,
>>
>> This just popped up on the Lede forum:
>> https://forum.lede-project.org/t/xiaomi-wifi-router-3g/5377/879
>>
>> So this might simply be a (mt7621 specific?) bug that prevents
>> sysupgrade from working properly. I am still awaiting his answers to
>> verify that he is indeed also running into the same issue where to
>> firmware won't upgrade.
>>
>> Yours sincerely,
>>
>> Jaap Buurman
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> http://lists.infradead.org/mailman/listinfo/openwrt-devel

I know how to fix the issue by recovery, however, from the responses
in the topic on the Lede forum it seems more people are running into
this issue. This definitely needs to be fixed before a 18.06 release.
Is there someone with a mt7621 device that can reproduce the problem,
and that has serial access? We might be able to figure out what is
going wrong.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Levente]

Try upgrading the sysupgrade image using your bootloader.

Lev

On Fri, May 25, 2018 at 1:25 PM, Jaap Buurman  wrote:
> On Fri, May 25, 2018 at 1:14 PM, Jaap Buurman  wrote:
>> On Fri, May 25, 2018 at 12:43 PM, Mathias Kresin  wrote:
>>> 2018-05-25 12:48 GMT+03:00 Jaap Buurman :
 Dear Martin, Mathias and the rest,

 Please scratch my previous message. It seems like the flash was not
 successful, and hence I was still running the old firmware. However, I
 have tried flashing 3 different times now, without any luck. The
 router ends up rebooting and boots right into the old firmware. This
 seems to be a major bug. Is there anything I can do to help debug this
 particular issue?
>>>
>>> First of all, Martin is right. The commit in my staging tree should
>>> fix the MTU issue but I don't have the hardware to test it on my own.
>>>
>>> So far you never mentioned which board you have. Hence it's quite
>>> difficult to have a look at the code about what could be wrong. It
>>> would be helpful if you can name the last working revision to limit
>>> the number of commits to look at.
>>>
 Seems like a dealbreaker for 18.06 (which I am
 running now) to me. I could simply use recovery and flash a firmware
 like that, but I would prefer to get to the bottom of this issue so
 that end users won't end up stuck on a particular firmware. Any ideas
 what I could do to debug this?
>>>
>>> Your best bet is to attach the/a serial console and check the console
>>> for errors.
>>>
>>> Mathias
>>
>> My apologies for leaving out important details. I am using a Dir-860L
>> B1. I used to be running Lede 17.01.4, until last Tuesday. At that day
>> I upgraded to OpenWrt 18.06-SNAPSHOT r6917-8948a78 via Luci. Flashing
>> any other firmware seems to be broken now: I have tried flashing a
>> build compiled from your staging tree, I've tried reverting back to
>> 17.01.4 and I've tried reflashing 18.06. All end up in the exact same
>> spot: Still on the OpenWrt 18.06-SNAPSHOT r6917-8948a78 with all
>> manually installed packages still present. I've tried flashing via
>> Luci and via the sysupgrade command (with the -v switch for more
>> verbosity), but no useful information there. The last line that is
>> output is simply:
>>
>> Commencing upgrade. All shell sessions will be closed now.
>>
>> One particular weird thing that I do remember on this build, is the
>> fact that I tried to update all upgradable packages via OPKG (I know
>> this is discouraged). One of those packages was "base-files". The
>> upgrade failed with a weird error (can't remember what exactly), but
>> nothing seemed wrong at that time, so I didn't really think much about
>> it. Is there anyone more knowledgeable than me that knows whether this
>> could influence the sysupgrade functionality?
>>
>> Lastly, I do not have a serial cable unfortunately, so I think
>> debugging will be difficult for me. I could use recovery to reflash a
>> fresh 18.06 build, and see if upgrade functionality is still broken in
>> that case. I will report back with my findings.
>>
>> Yours sincerely,
>>
>> Jaap Buurman
>
> Dear all,
>
> This just popped up on the Lede forum:
> https://forum.lede-project.org/t/xiaomi-wifi-router-3g/5377/879
>
> So this might simply be a (mt7621 specific?) bug that prevents
> sysupgrade from working properly. I am still awaiting his answers to
> verify that he is indeed also running into the same issue where to
> firmware won't upgrade.
>
> Yours sincerely,
>
> Jaap Buurman
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

On Fri, May 25, 2018 at 1:14 PM, Jaap Buurman  wrote:
> On Fri, May 25, 2018 at 12:43 PM, Mathias Kresin  wrote:
>> 2018-05-25 12:48 GMT+03:00 Jaap Buurman :
>>> Dear Martin, Mathias and the rest,
>>>
>>> Please scratch my previous message. It seems like the flash was not
>>> successful, and hence I was still running the old firmware. However, I
>>> have tried flashing 3 different times now, without any luck. The
>>> router ends up rebooting and boots right into the old firmware. This
>>> seems to be a major bug. Is there anything I can do to help debug this
>>> particular issue?
>>
>> First of all, Martin is right. The commit in my staging tree should
>> fix the MTU issue but I don't have the hardware to test it on my own.
>>
>> So far you never mentioned which board you have. Hence it's quite
>> difficult to have a look at the code about what could be wrong. It
>> would be helpful if you can name the last working revision to limit
>> the number of commits to look at.
>>
>>> Seems like a dealbreaker for 18.06 (which I am
>>> running now) to me. I could simply use recovery and flash a firmware
>>> like that, but I would prefer to get to the bottom of this issue so
>>> that end users won't end up stuck on a particular firmware. Any ideas
>>> what I could do to debug this?
>>
>> Your best bet is to attach the/a serial console and check the console
>> for errors.
>>
>> Mathias
>
> My apologies for leaving out important details. I am using a Dir-860L
> B1. I used to be running Lede 17.01.4, until last Tuesday. At that day
> I upgraded to OpenWrt 18.06-SNAPSHOT r6917-8948a78 via Luci. Flashing
> any other firmware seems to be broken now: I have tried flashing a
> build compiled from your staging tree, I've tried reverting back to
> 17.01.4 and I've tried reflashing 18.06. All end up in the exact same
> spot: Still on the OpenWrt 18.06-SNAPSHOT r6917-8948a78 with all
> manually installed packages still present. I've tried flashing via
> Luci and via the sysupgrade command (with the -v switch for more
> verbosity), but no useful information there. The last line that is
> output is simply:
>
> Commencing upgrade. All shell sessions will be closed now.
>
> One particular weird thing that I do remember on this build, is the
> fact that I tried to update all upgradable packages via OPKG (I know
> this is discouraged). One of those packages was "base-files". The
> upgrade failed with a weird error (can't remember what exactly), but
> nothing seemed wrong at that time, so I didn't really think much about
> it. Is there anyone more knowledgeable than me that knows whether this
> could influence the sysupgrade functionality?
>
> Lastly, I do not have a serial cable unfortunately, so I think
> debugging will be difficult for me. I could use recovery to reflash a
> fresh 18.06 build, and see if upgrade functionality is still broken in
> that case. I will report back with my findings.
>
> Yours sincerely,
>
> Jaap Buurman

Dear all,

This just popped up on the Lede forum:
https://forum.lede-project.org/t/xiaomi-wifi-router-3g/5377/879

So this might simply be a (mt7621 specific?) bug that prevents
sysupgrade from working properly. I am still awaiting his answers to
verify that he is indeed also running into the same issue where to
firmware won't upgrade.

Yours sincerely,

Jaap Buurman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

On Fri, May 25, 2018 at 12:43 PM, Mathias Kresin  wrote:
> 2018-05-25 12:48 GMT+03:00 Jaap Buurman :
>> Dear Martin, Mathias and the rest,
>>
>> Please scratch my previous message. It seems like the flash was not
>> successful, and hence I was still running the old firmware. However, I
>> have tried flashing 3 different times now, without any luck. The
>> router ends up rebooting and boots right into the old firmware. This
>> seems to be a major bug. Is there anything I can do to help debug this
>> particular issue?
>
> First of all, Martin is right. The commit in my staging tree should
> fix the MTU issue but I don't have the hardware to test it on my own.
>
> So far you never mentioned which board you have. Hence it's quite
> difficult to have a look at the code about what could be wrong. It
> would be helpful if you can name the last working revision to limit
> the number of commits to look at.
>
>> Seems like a dealbreaker for 18.06 (which I am
>> running now) to me. I could simply use recovery and flash a firmware
>> like that, but I would prefer to get to the bottom of this issue so
>> that end users won't end up stuck on a particular firmware. Any ideas
>> what I could do to debug this?
>
> Your best bet is to attach the/a serial console and check the console
> for errors.
>
> Mathias

My apologies for leaving out important details. I am using a Dir-860L
B1. I used to be running Lede 17.01.4, until last Tuesday. At that day
I upgraded to OpenWrt 18.06-SNAPSHOT r6917-8948a78 via Luci. Flashing
any other firmware seems to be broken now: I have tried flashing a
build compiled from your staging tree, I've tried reverting back to
17.01.4 and I've tried reflashing 18.06. All end up in the exact same
spot: Still on the OpenWrt 18.06-SNAPSHOT r6917-8948a78 with all
manually installed packages still present. I've tried flashing via
Luci and via the sysupgrade command (with the -v switch for more
verbosity), but no useful information there. The last line that is
output is simply:

Commencing upgrade. All shell sessions will be closed now.

One particular weird thing that I do remember on this build, is the
fact that I tried to update all upgradable packages via OPKG (I know
this is discouraged). One of those packages was "base-files". The
upgrade failed with a weird error (can't remember what exactly), but
nothing seemed wrong at that time, so I didn't really think much about
it. Is there anyone more knowledgeable than me that knows whether this
could influence the sysupgrade functionality?

Lastly, I do not have a serial cable unfortunately, so I think
debugging will be difficult for me. I could use recovery to reflash a
fresh 18.06 build, and see if upgrade functionality is still broken in
that case. I will report back with my findings.

Yours sincerely,

Jaap Buurman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Mathias Kresin]

2018-05-25 12:48 GMT+03:00 Jaap Buurman :
> Dear Martin, Mathias and the rest,
>
> Please scratch my previous message. It seems like the flash was not
> successful, and hence I was still running the old firmware. However, I
> have tried flashing 3 different times now, without any luck. The
> router ends up rebooting and boots right into the old firmware. This
> seems to be a major bug. Is there anything I can do to help debug this
> particular issue?

First of all, Martin is right. The commit in my staging tree should
fix the MTU issue but I don't have the hardware to test it on my own.

So far you never mentioned which board you have. Hence it's quite
difficult to have a look at the code about what could be wrong. It
would be helpful if you can name the last working revision to limit
the number of commits to look at.

> Seems like a dealbreaker for 18.06 (which I am
> running now) to me. I could simply use recovery and flash a firmware
> like that, but I would prefer to get to the bottom of this issue so
> that end users won't end up stuck on a particular firmware. Any ideas
> what I could do to debug this?

Your best bet is to attach the/a serial console and check the console
for errors.

Mathias

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

On Fri, May 25, 2018 at 11:30 AM, Jaap Buurman  wrote:
> On Thu, May 24, 2018 at 8:00 PM, Martin Blumenstingl
>  wrote:
>> Hello Jaap,
>>
>> On Thu, May 24, 2018 at 12:00 PM, Jaap Buurman  wrote:
>>> Dear all,
>>>
>>> I found some additional information in the system log: Thu May 24
>>> 11:38:39 2018 kern.err kernel: [83864.729458] eth0: Invalid MTU 1508
>>> requested, hw max 1500
>>> Digging deeper, this seems like a message that is spawned by a
>>> function in /net/core.dev.c of the linux kernel:
>>>
>>> if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
>>> net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
>>> dev->name, new_mtu, dev->max_mtu);
>>> return -EINVAL;
>>> }
>>>
>>> Is there anybody that happens to know where exactly this max_mtu value
>>> is set to 1500? For mt7621 devices this should be 2048 (Baby jambo
>>> frames).
>>>
>>> Thank you very much in advance.
>>>
>>> Yours sincerely,
>>>
>>> Jaap Buurman
>>>
>>> On Tue, May 22, 2018 at 3:05 PM, Jaap Buurman  wrote:
 Dear all,

 The switch to the 4.14 kernel apparently broke the baby jumbo frames
 support of 2048 bytes that the switch is capable off. I found out that
 changing the mtu above 1500 via Luci no longer applies properly.
 Trying to manually change the mtu via ssh also fails:

 root@LEDE:~# ifconfig eth0 mtu 1508 up
 ifconfig: SIOCSIFMTU: Invalid argument

 If there is any additional information that I can supply, please let
 me know. I am also more than willing to help test potential fixes :)
>> I *believe* Mathias has a fix for this in his tree (but I'm not sure
>> if he has the hardware to test it): [0]
>> maybe you can give it a go and report back?
>>
>>
>> Regards
>> Martin
>>
>>
>> [0] 
>> https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commitdiff;h=cc5f1fe7aa02943f3b39ffbd9dc3b8fcad569c8f
>
> Dear Martin and Mathias,
>
> I have compiled and flashed an image from Mathias' tree checked out at
> the commit linked in Martin's previous message. Unfortunately, I am
> still seeing the following message in dmesg:
> [  243.845159] eth0: Invalid MTU 1508 requested, hw max 1500
>
> If there are additional tests you would like me to run, please do not
> hesitate to contact me :)
>
> Yours sincerely,
>
> Jaap Buurman

Dear Martin, Mathias and the rest,

Please scratch my previous message. It seems like the flash was not
successful, and hence I was still running the old firmware. However, I
have tried flashing 3 different times now, without any luck. The
router ends up rebooting and boots right into the old firmware. This
seems to be a major bug. Is there anything I can do to help debug this
particular issue? Seems like a dealbreaker for 18.06 (which I am
running now) to me. I could simply use recovery and flash a firmware
like that, but I would prefer to get to the bottom of this issue so
that end users won't end up stuck on a particular firmware. Any ideas
what I could do to debug this?

Yours sincerely,

Jaap Buurman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

On Thu, May 24, 2018 at 8:00 PM, Martin Blumenstingl
 wrote:
> Hello Jaap,
>
> On Thu, May 24, 2018 at 12:00 PM, Jaap Buurman  wrote:
>> Dear all,
>>
>> I found some additional information in the system log: Thu May 24
>> 11:38:39 2018 kern.err kernel: [83864.729458] eth0: Invalid MTU 1508
>> requested, hw max 1500
>> Digging deeper, this seems like a message that is spawned by a
>> function in /net/core.dev.c of the linux kernel:
>>
>> if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
>> net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
>> dev->name, new_mtu, dev->max_mtu);
>> return -EINVAL;
>> }
>>
>> Is there anybody that happens to know where exactly this max_mtu value
>> is set to 1500? For mt7621 devices this should be 2048 (Baby jambo
>> frames).
>>
>> Thank you very much in advance.
>>
>> Yours sincerely,
>>
>> Jaap Buurman
>>
>> On Tue, May 22, 2018 at 3:05 PM, Jaap Buurman  wrote:
>>> Dear all,
>>>
>>> The switch to the 4.14 kernel apparently broke the baby jumbo frames
>>> support of 2048 bytes that the switch is capable off. I found out that
>>> changing the mtu above 1500 via Luci no longer applies properly.
>>> Trying to manually change the mtu via ssh also fails:
>>>
>>> root@LEDE:~# ifconfig eth0 mtu 1508 up
>>> ifconfig: SIOCSIFMTU: Invalid argument
>>>
>>> If there is any additional information that I can supply, please let
>>> me know. I am also more than willing to help test potential fixes :)
> I *believe* Mathias has a fix for this in his tree (but I'm not sure
> if he has the hardware to test it): [0]
> maybe you can give it a go and report back?
>
>
> Regards
> Martin
>
>
> [0] 
> https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commitdiff;h=cc5f1fe7aa02943f3b39ffbd9dc3b8fcad569c8f

Dear Martin and Mathias,

I have compiled and flashed an image from Mathias' tree checked out at
the commit linked in Martin's previous message. Unfortunately, I am
still seeing the following message in dmesg:
[  243.845159] eth0: Invalid MTU 1508 requested, hw max 1500

If there are additional tests you would like me to run, please do not
hesitate to contact me :)

Yours sincerely,

Jaap Buurman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Martin Blumenstingl via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello Jaap,

On Thu, May 24, 2018 at 12:00 PM, Jaap Buurman  wrote:
> Dear all,
>
> I found some additional information in the system log: Thu May 24
> 11:38:39 2018 kern.err kernel: [83864.729458] eth0: Invalid MTU 1508
> requested, hw max 1500
> Digging deeper, this seems like a message that is spawned by a
> function in /net/core.dev.c of the linux kernel:
>
> if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
> net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
> dev->name, new_mtu, dev->max_mtu);
> return -EINVAL;
> }
>
> Is there anybody that happens to know where exactly this max_mtu value
> is set to 1500? For mt7621 devices this should be 2048 (Baby jambo
> frames).
>
> Thank you very much in advance.
>
> Yours sincerely,
>
> Jaap Buurman
>
> On Tue, May 22, 2018 at 3:05 PM, Jaap Buurman  wrote:
>> Dear all,
>>
>> The switch to the 4.14 kernel apparently broke the baby jumbo frames
>> support of 2048 bytes that the switch is capable off. I found out that
>> changing the mtu above 1500 via Luci no longer applies properly.
>> Trying to manually change the mtu via ssh also fails:
>>
>> root@LEDE:~# ifconfig eth0 mtu 1508 up
>> ifconfig: SIOCSIFMTU: Invalid argument
>>
>> If there is any additional information that I can supply, please let
>> me know. I am also more than willing to help test potential fixes :)
I *believe* Mathias has a fix for this in his tree (but I'm not sure
if he has the hardware to test it): [0]
maybe you can give it a go and report back?


Regards
Martin


[0] 
https://git.openwrt.org/?p=openwrt/staging/mkresin.git;a=commitdiff;h=cc5f1fe7aa02943f3b39ffbd9dc3b8fcad569c8f

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

Dear all,

I found some additional information in the system log: Thu May 24
11:38:39 2018 kern.err kernel: [83864.729458] eth0: Invalid MTU 1508
requested, hw max 1500
Digging deeper, this seems like a message that is spawned by a
function in /net/core.dev.c of the linux kernel:

if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
dev->name, new_mtu, dev->max_mtu);
return -EINVAL;
}

Is there anybody that happens to know where exactly this max_mtu value
is set to 1500? For mt7621 devices this should be 2048 (Baby jambo
frames).

Thank you very much in advance.

Yours sincerely,

Jaap Buurman

On Tue, May 22, 2018 at 3:05 PM, Jaap Buurman  wrote:
> Dear all,
>
> The switch to the 4.14 kernel apparently broke the baby jumbo frames
> support of 2048 bytes that the switch is capable off. I found out that
> changing the mtu above 1500 via Luci no longer applies properly.
> Trying to manually change the mtu via ssh also fails:
>
> root@LEDE:~# ifconfig eth0 mtu 1508 up
> ifconfig: SIOCSIFMTU: Invalid argument
>
> If there is any additional information that I can supply, please let
> me know. I am also more than willing to help test potential fixes :)
>
> Yours sincerely,
>
> Jaap Buurman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Jaap Buurman]

Dear all,

The switch to the 4.14 kernel apparently broke the baby jumbo frames
support of 2048 bytes that the switch is capable off. I found out that
changing the mtu above 1500 via Luci no longer applies properly.
Trying to manually change the mtu via ssh also fails:

root@LEDE:~# ifconfig eth0 mtu 1508 up
ifconfig: SIOCSIFMTU: Invalid argument

If there is any additional information that I can supply, please let
me know. I am also more than willing to help test potential fixes :)

Yours sincerely,

Jaap Buurman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel