00:46 <slh> that site exists for a long time, well over 10-15 years - but that doesn't mean the sources are always complete or buildable

00:48 <slh> most of the big vendors (except ZyXEL, there you have to mail them, provide them with your device's serial number and ask/ answer why, ask, ask) have GPL tarballs - but it varies widely (between vendors and different devices of the same vendor) how complete/ useful they are

00:59 <russell--> lol, yeah re zyxel "are you an authorized something? why do you want it?" answer: "you are obigated to provide it on request, that's why"

01:02 <Mangix> ping Ansuel

08:06 <f00b4r0> nbd: how do I enable wm debug again?

08:20 <aparcar[m]> test123

08:20 <aparcar[m]> Ansuel: ping

10:38 <rmilecki> jow: did you sort out that memory corruption something bug?

12:35 <nbd> f00b4r0: echo 1 > /sys/kernel/debug/ieee80211/phy0/mt76/fw_debug_wm

12:41 <jow> rmilecki: no

12:43 <f00b4r0> nbd: thanks. A bit too late tho, the device has already crashed again ;^)

12:44 <f00b4r0> same timeouts followed by "phy1-ap0: HW problem - can not stop rx aggregation for ...".

12:44 <f00b4r0> rebooting now, I'll enable debug

12:45 <f00b4r0> it lasted less than 24h this time which is definitely on the fast side

16:37 <Mangix> ping Ansuel

18:50 <nbd> f00b4r0: implemented some mcu hang recovery code in the testing branch

18:50 <nbd> hopefully it should reset itself now when the mcu crashes

18:50 <nbd> it seems to work in my test when i force the MCU to crash via debugfs

18:54 <f00b4r0> nbd: ok, so you're not actually fixing the problem, merely hiding it? :-)

18:54 <f00b4r0> i'll test tomorrow

18:56 <nbd> i added some more fixes as well

18:56 <nbd> but at least this way firmware crashes won't be fatal anymore

18:57 <schmars[m]> very nice

18:57 <schmars[m]> i'll do my best to test drive it as well

18:58 <schmars[m]> i have three publicly reachable nodes with the crash, just in case that's useful

18:59 <f00b4r0> nbd: out of curiosity, is the recovery "quick"? Because when the fw crashes, there can be a long-to-very-long time during which the device is hung and non-responsive

18:59 <schmars[m]> two actually, the third isn't reachable anymore once it crashes :-)

19:00 <f00b4r0> looking at the collectd data for today, the hang time lasted 1h20mn

19:00 <f00b4r0> (i.e. for 1h20 there was no collectd data being sent from the device, even though said data is sent over wire)

19:00 <schmars[m]> yeah i see that period too, crazy high cpu usage for a while, and once cpu usage recovers, the "hw problem" log messages start

19:01 <f00b4r0> so if it takes that long to recover it's still essentially unuseable

19:02 <nbd> f00b4r0: since there is mcu msg retry now, it should block for 60 seconds while waiting for a mcu response

19:02 <schmars[m]> oh wow now that i'm looking, i've had it take 7 hours once

19:02 <nbd> after that it declares the mcu dead and triggers recovery immediately

19:02 <nbd> without running into further timeouts

19:02 <schmars[m]> ah that sounds nice

19:03 <f00b4r0> ok. definitely an improvement, although there can still be a 1mn downtime worst case

19:03 <nbd> yes

19:03 <nbd> that can be brought down further by dynamically adjusting mcu timeouts based on msg type

19:03 <f00b4r0> (forgive me for being obnoxious but in a PoS scenario, 1mn *is* a problem)

19:04 <schmars[m]> i'm rebooting these devices with cron once an hour at the moment, so it's not a imworsement either :-)

19:04 <nbd> but first i want to make sure that recovery is working as expected

19:04 <f00b4r0> makes sense

19:04 <schmars[m]> yeah PoS different matter than a normal public hotspot i guess

19:04 <f00b4r0> would be nice to understand what crashes the firmware. Some locations are very prone to it, but I was unable to isolate common denominators

19:05 <f00b4r0> (then again I'm not keeping track of which devices are connecting)

19:05 <nbd> i do want to get to the bottom of this as well

19:05 <nbd> just because there's recovery doesn't mean i will stop working on the bug

19:06 <nbd> but given the scale, damage control is important :)

19:06 <f00b4r0> good to know, thanks :D

19:06 <f00b4r0> yeah definitely

19:06 <schmars[m]> my guess is that it's client devices. my crashing devices A and B are on a busy public place, and crash maybe once a day. the other is in a relatively quiet living area, and it crashes right away after boot, so i'm assuming a problematic client device is right nearby

19:06 <f00b4r0> schmars[m]: that's my guess as well, but I'm totally clueless beyond that

19:06 <schmars[m]> if you tell me what packets to capture, i can arrange for that

19:07 <f00b4r0> i don't think it's a packet problem

19:07 <nbd> my hunch is that it may be triggered by clients that become unresponsive by going out of range without diassociating

19:07 <f00b4r0> it's probably at the radio layer

19:07 <f00b4r0> nbd: that could make sense, especially in a public hotspot scenario (the case here)

19:08 <nbd> so maybe there are some corner cases regarding deleting those clients while packets are buffered for them

21:31 <jow> rmilecki: upon further investigation it appears this memory corruption happens during a musl realloc

21:33 <jow> rmilecki: a realloc which relocates the base pointer to a new location to be specific, after the ensuing memcpy() to the new location performed by libc, the new memory contents are just different than the previous ones

21:47 <jow> totally crazy

22:11 <R2D2> Русские есть?

22:12 <roberto117> Hello, I looked at the changelog between 22.x and 23.x but I find no mention of why RTL8187 was dropped for x86-64 in 23.x, any clue ?

22:15 <R2D2> unzip не знаю где взять файл для Версия ядра3.18.45 OpenWrt TP-Link TL-MR3220 v2 OpenWrt Chaos Calmer 15.05.1 r49389 / LuCI for-15.05 branch (git-17.013.32081-d89b022) OpenWrt Chaos Calmer 15.05.1 r49389 в результате чего не могу распаковывать архивы в zip через консоль как исправить?

22:17 <R2D2> архив zapret-master.zip для интересных делишек, память на роутере увеличил до 16гигов по юсб разьему на роутере

22:18 <R2D2> только не говорите что нужно сменить железо

22:19 <R2D2> на гетхабе заблокировали из за множество вопросов пользователям ппц

22:20 <Habbie> R2D2, most people in here cannot read that; try english

22:21 <R2D2> I don't speak English but I'll try with the help of a translator

22:23 <R2D2> Russians? unzip I don't know where to get the file for Kernel version 3.18.45 OpenWrt TP-Link TL-MR3220 v2 OpenWrt Chaos Calmer 15.05. 1 r49389 / LuCI for-15.05 branch (git-17.013.32081-d89b022) OpenWrt Chaos Calmer 15.05. 1 r49389 as a result of which I can't unpack archives in zip via console how to fix it? archive zapret-master.zip for interesting things, increased the memory on the router to 16 gigs via USB connector on the router

22:26 <jow> hah, found a simple non-ucode reproducer

22:28 <jow> test code: https://pastebin.com/uML90LNU

22:28 <jow> failure after a few dozen runs: https://pastebin.com/enUdtN25

22:31 <jow> even happens at the very same offset, byte #165 flips from 0x80 to 0x00

23:07 <tersono> Can ubus patches be submitted as PRs on https://github.com/openwrt/ubus or should they be sent to the mailing list?

23:47 <Edu4rdSHL> tersono, it's just a mirror, so mailing list