**** BEGIN LOGGING AT Wed Nov 20 02:59:58 2019
Nov 20 03:12:45 <owrt-1907-builds> build #41 of ipq40xx/generic is complete: Failure [failed images]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ipq40xx%2Fgeneric/builds/41  blamelist: Koen Vandeputte <koen.vandeputte@ncentric.com>
Nov 20 05:28:38 <mangix> SDK broken again
Nov 20 05:28:52 <mangix> bad GPG signature
Nov 20 06:49:42 <xback> stintel: yeah, I noticed it. as ldir mentioned i'll remove those 2 in a separate patch so it's clear what happened over there
Nov 20 06:49:58 <xback> hexa-: thank you for reporting. will check right away
Nov 20 06:51:38 <xback> stintel: it's a bit annoying that both upstream and rpi fiddle with all the changes at the same time ..
Nov 20 06:52:00 <xback> stintel: and the fun always begins when upstream changes something where rpi lags behind
Nov 20 07:03:21 <owrt-1806-builds> build #40 of ipq40xx/generic is complete: Failure [failed images]  Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ipq40xx%2Fgeneric/builds/40  blamelist: Koen Vandeputte <koen.vandeputte@ncentric.com>
Nov 20 08:28:24 <xback> hexa-: fixes pushed. srry for the issue :-)
Nov 20 08:58:24 <stintel> xback: there are much more patches to be cleaned up there
Nov 20 08:58:44 <stintel> I was looking into it but had some breakage otherwise I'd have pushed something already
Nov 20 08:59:13 <xback> stintel: yeah, I agree.  But it's a bit out of my scope at work as I don't use that target
Nov 20 09:00:02 <stintel> xback: I can have another look, I had to do it too when I bumped that target to 4.14
Nov 20 09:29:35 <olmari> Hauke: Not that it really matters, I wasn't going to say anything until I've dug a little bit deeper, but your issue sounds exactly same as mine, everytihng matches execpt owrt version itself, so I wanted to chime in yesterday that indeed, similar low Rx speed I got too
Nov 20 09:56:04 <ynezz> anyone familiar with clang fuzzer? I'm trying to begin with https://llvm.org/docs/LibFuzzer.html#toy-example but getting some weird errors (having clang-10 + deps installed form apt.llvm.org)
Nov 20 09:57:07 <ynezz> as the page mentions clang 5 release, I'm assuming, that it's just outdated
Nov 20 09:59:31 <ynezz> llvm is quite huge project so I would rather spend time on writing the actual tests instead of setting that monstrosity up
Nov 20 10:12:25 <aleksander_m> can anyone tell me what's the purpose of the 'proto_config_add_string "device:device"' setup in the qmi/mbim/3g/ncm/directip protocol handlers?
Nov 20 10:13:48 <aleksander_m> nbd, blogic: ^?
Nov 20 10:50:29 <jow> aleksander_m: it registers a string option named "device"
Nov 20 10:51:06 <aleksander_m> jow: how is that different than 'proto_config_add_string "device"' ?
Nov 20 11:01:32 <jow> aleksander_m: the string after the colon is a datatype which is validated
Nov 20 11:05:28 <jow> aleksander_m: however I am not sure if that is even used. As far as I can follow the code it is parsed by netifd and printed back out, e.g. with "ubus call network get_proto_handlers"
Nov 20 11:05:46 <jow> external code could use that information to validate the config
Nov 20 11:05:52 <aleksander_m> jow: I see
Nov 20 11:06:43 <jow> the "device" type refers to https://lxr.openwrt.org/source/ubox/validate/validate.c#L934
Nov 20 11:06:54 <jow> so a char or block special /dev node
Nov 20 11:34:15 <aleksander_m> jow: and who does that validation? because then the modemmanager proto is not doing it right
Nov 20 11:34:17 <indy__> aparcar[m]: ping hi just tested docker.io/openwrtorg/rootfs:x86-64-19.07.0-rc1 and in var is missing lock folder, so opkg update do not work
Nov 20 11:34:38 <aleksander_m> jow: in the modemmanager proto, we have the "device" option that specifies a full sysfs device path, not a /dev node
Nov 20 11:35:17 <aleksander_m> jow: should probably remove the ":device" suffix I assume then in the modemmanager proto
Nov 20 11:38:28 <hexa-> xback: no worries, thanks :)
Nov 20 11:45:40 <jow> aleksander_m: right now nothing uses these validation hints
Nov 20 11:45:47 <jow> at least as far as I can see
Nov 20 11:45:59 <aleksander_m> jow: ok, thanks for confirming
Nov 20 12:29:14 <pepe2k> greearb__: ping
Nov 20 13:53:21 <johnf> I'm building some new kernel packages on an old version of openwrt that I have retained my build directory for
Nov 20 13:53:31 <johnf> the new packages, of course, have a different kernel hash
Nov 20 13:53:39 <johnf> so I need to force dependancis to install
Nov 20 13:53:45 <johnf> still on the ancient kernel version though
Nov 20 13:54:10 <johnf> is there a way I can override the hash being computed for the kernel?
Nov 20 13:54:33 <johnf> I understand that in buildroot itself it's possible to build kernels without the hash being part of the package naming
Nov 20 13:59:08 <ynezz> you can do whatever you want, even shoot yourself in the foot if you want
Nov 20 14:06:14 <johnf> can't argue
Nov 20 14:06:22 <johnf> and this would be a great way to cause yourself trouble
Nov 20 14:06:38 <johnf> that being said, I don't expect to create any issues
Nov 20 14:06:53 <johnf> but I would like to be able to ship packages instead of files to my devices
Nov 20 14:14:59 <ynezz> LINUX_VERMAGIC
Nov 20 14:29:16 <johnf> thanks ynezz, appreciate it
Nov 20 15:06:56 <kos_tom> hello
Nov 20 15:07:07 <kos_tom> I've added some options in config/Config-kernel.in, to be able to optionally enable some kernel features
Nov 20 15:07:28 <kos_tom> of course, when one enables OPTION_FOO in the kernel configuration, then all options that had a "depends on OPTION_FOO" become usable
Nov 20 15:08:00 <kos_tom> and I found that sometimes during the build, the kernel kconfig would ask about the value of all those new options that have appeared, sometimes not
Nov 20 15:08:14 <kos_tom> so I'm a bit confused by what is the OpenWrt strategy here
Nov 20 15:08:20 <kos_tom> I guess there are two possibilities
Nov 20 15:08:49 <kos_tom>  (1) OpenWrt takes into account the KERNEL_* options in config/Config-kernel.in, and then does a "make olddefconfig" in the kernel to automatically accept the default values for all non-specified options
Nov 20 15:09:10 <kos_tom>  (2) OpenWrt wants to explicitly handle all possible options in config/Config-kernel.in, but that sounds like a maintenance nightmare
Nov 20 15:09:24 <stintel> add these symbols to generic/config-X.X
Nov 20 15:09:47 <stintel> is what I would do ?
Nov 20 15:10:07 <kos_tom> that sounds weird, it would be a lot easier for OpenWrt to run the kernel "make olddefconfig" target
Nov 20 15:19:10 <Hauke_work> aparcar[m]: where do I find the prpl buildbot with the falcon_mountain?
Nov 20 15:20:50 <Hauke_work> aparcar[m]: this does not work any more: https://buildmaster.aparcar.org/#/builders/118/builds/5/steps/43/logs/stdio
Nov 20 15:40:32 <Hauke_work> aparcar[m]: found it https://builder.prpl.dev
Nov 20 15:52:57 <greearb__> pepe2k, here
Nov 20 15:58:18 <pepe2k> greearb__: ath10k-ct in master, does LED support work for you?
Nov 20 15:58:47 <pepe2k> QCA9886, with generic ath10k LED works, with ath10k-ct it doesn't
Nov 20 15:59:38 <pepe2k> ath79, kernel 4.19
Nov 20 16:00:17 <greearb__> I haven't tried
Nov 20 16:00:45 <greearb__> maybe some out-of-kernel patches need applying?
Nov 20 16:10:07 <Hauke_work> I think there is a ath10k patch for leds, I am not sure if it is also applied to ath10k-ct
Nov 20 16:17:13 <greearb__> if it can be conditionally compiled so that it doesn't mess up non-openwrt systems, I can probably add it to ath10k-ct driver
Nov 20 16:18:10 <greearb__> I think we already pass a -D foo flag when compiling ath10k-ct driver for openwrt, so might can use that.
Nov 20 16:35:43 <pepe2k> Hauke_work: greearb__ I think LED support is already there, I see ath10k-phy0 in /sys/class/leds
Nov 20 16:37:09 <stintel> yes
Nov 20 16:37:10 <stintel> see 39a96205474fa82e37d756399fde01d2964d3125
Nov 20 16:38:40 <pepe2k> yep, will bisect to find out where it got broken
Nov 20 18:07:35 <aparcar[m]> Hauke_work: the files created by the builder are moved here http://148.251.78.235/19.07-SNAPSHOT/targets/intel_mips/xrx500/
Nov 20 18:37:34 <xdarklight> mkresin: Hauke: it would be great if you had a look at https://github.com/openwrt/openwrt/pull/2216
Nov 20 18:37:39 <mangix> My pull requests fail with signify error. Everyone else's do not. Weird.
Nov 20 18:38:55 <Hauke> xdarklight: I will have a look tomorrow
Nov 20 19:47:17 <pepe2k> Hauke: what is intel_mips?
Nov 20 19:50:43 <ynezz> mangix: sha256sum: WARNING: 1 computed checksum did NOT match
Nov 20 19:53:54 <ynezz> mangix: 27fdddf8643a289294b8a07820bcbee877cb3ffa ?
Nov 20 20:05:08 <xdarklight> Hauke: great, thank you!
Nov 20 20:05:40 <xdarklight> pepe2k: possibly the GRX500 SoCs (https://lwn.net/Articles/761729/)
Nov 20 20:06:12 <ynezz> s/lantiq/intel_mips/ ?
Nov 20 20:06:17 <blogic> [SUM]  77.00-78.00  sec   167 MBytes  1.40 Gbits/sec    0
Nov 20 20:06:20 <blogic> :-D
Nov 20 20:06:25 <stintel> ax?
Nov 20 20:06:26 <blogic> over the air
Nov 20 20:06:30 <blogic> HE80
Nov 20 20:06:42 <ynezz> from your phone?
Nov 20 20:06:51 <blogic> an ODM unit
Nov 20 20:07:00 <blogic> between 2 AP
Nov 20 20:07:05 <blogic> both running ath11k
Nov 20 20:07:16 <pepe2k> blogic: 4x4?
Nov 20 20:07:18 <ynezz> how many crashes in between? :p
Nov 20 20:07:30 <blogic> ynezz: none seen in 2 weeks
Nov 20 20:07:41 <blogic> pepe2k: yes HE80 4x4 mcs11
Nov 20 20:08:02 <stintel> distance between the APs ?
Nov 20 20:08:07 <blogic> i started with 900mbit last week
Nov 20 20:08:08 <pepe2k> xdarklight: yeah, looks like, also with iwlwav for the AX series WAV600, Archer AX50 is based on that platform... ~60 USD
Nov 20 20:08:17 <blogic> stintel: ~50cm antennas aligned
Nov 20 20:08:21 <stintel> ok
Nov 20 20:08:36 <blogic> pepe2k: latest iwlwav driver is inside prpl git
Nov 20 20:08:51 <blogic> pepe2k: compiles on 19.07 + all userland tooling and uci integration
Nov 20 20:08:57 <pepe2k> blogic: yeah, got link from Paul
Nov 20 20:09:01 <blogic> kk
Nov 20 20:09:11 <blogic> getting an updated version early next week I am told
Nov 20 20:10:13 <Borromini> wtf 1,4 Gbps o_O
Nov 20 20:10:38 <blogic> Borromini: I have no idea what its supposed to be usefull for
Nov 20 20:10:49 <Borromini> to complain wired is too slow of course :D
Nov 20 20:10:54 <blogic> unless you want to stream 8K over wifi or summin
Nov 20 20:11:08 <blogic> Borromini: the unit has 10gbit wire
Nov 20 20:11:15 <blogic> i can push ~4,8 on it
Nov 20 20:11:35 <Borromini> not even 8k will eat that much... 4k doesn't even fill up gigabit wired unless it's badly compressed
Nov 20 20:11:39 <Borromini> neat.
Nov 20 20:11:41 <pepe2k> blogic: you can still improve... QSDK8 IIRC, IPQ8072, 4x4, ~2 Gbps on 5G only
Nov 20 20:11:57 <blogic> pepe2k: using vht160
Nov 20 20:12:04 <blogic> pepe2k: using he160
Nov 20 20:12:25 <pepe2k> dunno
Nov 20 20:12:41 <Borromini> wait so that Archer is an ax device and it has lantiq/intel wireless?
Nov 20 20:12:52 <pepe2k> but power consumption ~25W + :D
Nov 20 20:13:27 <blogic> pepe2k: :-)
Nov 20 20:13:31 <Borromini> yeah something needs to give eh.
Nov 20 20:13:33 <pepe2k> Borromini: AX50, yes, Intel/Lantiq (so, MIPS) + their new WAV600 radios?
Nov 20 20:14:13 <pepe2k> blogic: IPQ8070, low budget QCA for AX, tell us more please :)
Nov 20 20:14:26 <blogic> pepe2k: cypress
Nov 20 20:14:31 <blogic> ipq60xx
Nov 20 20:14:35 <blogic> its tha AX dakota
Nov 20 20:14:36 <Borromini> pepe2k: neat - the ac drivers being open source?
Nov 20 20:15:39 <pepe2k> Borromini: haven't checked, just registered myself on prpl gitlab and cloning... but I would expect blobs, blobs everywhere and firmware blobs, blobs :)
Nov 20 20:16:05 <Borromini> yeah probably. can you share the link?
Nov 20 20:16:30 <pepe2k> blogic: so the IPQ8070 is Dakota for AX?
Nov 20 20:17:02 <blogic> 8070 was acron i think
Nov 20 20:17:06 <pepe2k> Borromini: ask blogic or aparcar[m], it looks public but I haven't seen that announced anywhere so far
Nov 20 20:17:07 <blogic> 8072 is oak
Nov 20 20:17:12 <blogic> 60xx is cypress
Nov 20 20:17:24 <Borromini> ok ty
Nov 20 20:17:24 <blogic> pepe2k: its public
Nov 20 20:17:35 <pepe2k> blogic: Cortex-A53?
Nov 20 20:17:38 <blogic> that is the whole point
Nov 20 20:17:41 <pepe2k> Borromini: https://git.prpl.dev/intel/iwlwav
Nov 20 20:17:45 <Borromini> thanks!
Nov 20 20:17:52 <blogic> not sure, i'll boot the eval kit tomorrow and let you know
Nov 20 20:17:57 <Borromini> at least duckduckgo isn't turning it up
Nov 20 20:18:01 <blogic> its still wrapped up, only had it for 5 days
Nov 20 20:18:09 <Borromini> but duckduckgo can suck big time on some searches :(
Nov 20 20:18:34 <blogic> Borromini: https://git.prpl.dev/prplwrt/prplwrt/wikis/getstarted
Nov 20 20:18:41 <blogic> this will build an image for netgear rax40
Nov 20 20:18:47 <Borromini> cool, thanks
Nov 20 20:18:55 <blogic> using 19.07 + sdk drivers/kernel from intel
Nov 20 20:19:11 <pepe2k> bin blobs?
Nov 20 20:19:12 <blogic> with all the hw accell and so on
Nov 20 20:19:20 <blogic> pepe2k: for the wifi fw
Nov 20 20:19:23 <blogic> rest is full src
Nov 20 20:19:29 <blogic> incl dsl, tapi drivers
Nov 20 20:19:33 <Hauke> pepe2k: the intel_mips target is the OpenWrt Intel uses for their MIPS based SoC like GRX500 and Falcon Mountain in their SDK
Nov 20 20:19:35 <Hauke> https://git.prpl.dev/prplwrt/feed-intel/tree/intel-19.07/intel_mips
Nov 20 20:19:56 <pepe2k> blogic: not great, not terrible ;)
Nov 20 20:20:08 <pepe2k> Hauke: will that hit OpenWrt someday?
Nov 20 20:20:17 <blogic> pepe2k: yeah well we can all use 11n and have it libre wifi
Nov 20 20:20:24 <blogic> pepe2k: yes
Nov 20 20:20:28 <blogic> its a staging tree
Nov 20 20:20:41 <blogic> small steps at a time
Nov 20 20:20:45 <Borromini> i like ac at the moment :) we'll see about ax when the time (and money) is there :P
Nov 20 20:20:45 <blogic> 1) get it into a public git
Nov 20 20:20:48 <blogic> 2) clean it up
Nov 20 20:20:53 <blogic> 3) integrate it upstream
Nov 20 20:21:31 <aparcar[m]> blogic: do you plan to get gen_config.sh upstream too?
Nov 20 20:21:38 <pepe2k> blogic: I'm very strong in opinion that closed source firmware is the worse radio manufacturer can do
Nov 20 20:21:44 <blogic> aparcar[m]: yes
Nov 20 20:21:54 <blogic> pepe2k: agreed
Nov 20 20:22:17 <blogic> write a letter to them and complain, i will co-sign it
Nov 20 20:22:26 <Borromini> pepe2k: don't they pretty much all do it nowadays?
Nov 20 20:22:50 <blogic> well for AX you need soft realtime
Nov 20 20:22:56 <pepe2k> Borromini: yes, patents and all other political/marketing/money bullshit
Nov 20 20:23:08 <blogic> pepe2k: .../ego
Nov 20 20:23:20 <pepe2k> blogic: is there a schedule for ath11k in our repo?
Nov 20 20:23:36 <pepe2k> got bunch of hardware already, just waiting ;)
Nov 20 20:23:41 <Borromini> :D
Nov 20 20:23:58 <blogic> V3 is posted upstream
Nov 20 20:24:08 <blogic> I am hoping it'll hit v5.6
Nov 20 20:24:14 <blogic> once upstream we can backport it
Nov 20 20:24:16 <pepe2k> and also QSDK10... but I'm just not brave enough and I'm tired with them
Nov 20 20:24:47 <pepe2k> time to switch to Realtek ;)
Nov 20 20:24:58 <blogic> and v3.16 kernel
Nov 20 20:25:12 <pepe2k> NO! 3.18!
Nov 20 20:25:16 <Borromini> :P
Nov 20 20:25:37 <stintel> 2.6.32
Nov 20 20:25:48 <pepe2k> so, next year will be finally interesting, Intel AX, QCOM AX... what about MTK?
Nov 20 20:25:54 <Borromini> ^^
Nov 20 20:25:57 <pepe2k> stintel: the best one so far ;)
Nov 20 20:26:21 <pepe2k> MT7629 looks like from stone age...
Nov 20 20:26:38 <pepe2k> answer for QCOM IPQ40xx
Nov 20 20:27:54 <DonkeyHotei> i'm guessing iwlwav won't support the older wave wifi
Nov 20 20:29:04 <DonkeyHotei> that's still for the driver that was "a whole other level of crazy"
Nov 20 20:29:25 <pepe2k> DonkeyHotei: don't you like iwlwifi?
Nov 20 20:29:50 <Borromini> pepe2k: does iwlwifi work for station mode? i thought people did not recommend it at all.
Nov 20 20:30:03 <DonkeyHotei> what does iwlwifi have to do with lantiq?
Nov 20 20:30:28 <pepe2k> Borromini: yes, but at least AX200 is also supported by iwlwifi
Nov 20 20:32:34 <DonkeyHotei> i was referring to wave300
Nov 20 20:32:43 <Borromini> ok. no idea about linux client support. until now intel used to be pretty quick on that point (i always tend to swap in an intel card when i buy a new laptop)
Nov 20 20:38:47 <pepe2k> DonkeyHotei: isn't wave300 N-only?
Nov 20 20:38:54 <Hauke> iwlwifi != iwlwav
Nov 20 20:39:11 <pepe2k> iwlwav is for AP :)
Nov 20 20:39:31 <Hauke> and a complete different HW
Nov 20 20:39:51 <blogic> Hauke: different everything
Nov 20 20:39:56 <Hauke> yes
Nov 20 20:40:37 <Hauke> differnt teams from differnt business units and different history
Nov 20 20:41:12 <Borromini> iwlav is lantiq wireless no?
Nov 20 20:41:31 <blogic> metalink wireless
Nov 20 20:42:52 <Hauke> Borromini: yes
Nov 20 20:43:57 <pepe2k> Hauke: is it better now?
Nov 20 20:46:27 <Hauke> pepe2k: I havne't looked at wifi
Nov 20 21:15:46 <stintel> bloody unifi switch keeps losing its config after every reboot and needs to be adopted again
Nov 20 21:21:46 <pepe2k> stintel: broken flash?
Nov 20 21:22:24 <stintel> pepe2k: that would be interesting. I just replaced a broken flash chip in my power8 box :)
Nov 20 21:22:30 <stintel> but how to figure that out
Nov 20 21:22:57 <pepe2k> stintel: erase, write, read back and check cheksum?
Nov 20 21:23:41 <stintel> pepe2k: well that worked fine on the flash chip of my power8 box
Nov 20 21:23:46 <stintel> still a new chip made it boot again
Nov 20 21:24:10 <pepe2k> stintel: I don't know the reason but ubnt has always been like that, I used to buy broken ones and 99/100 had broken flash
Nov 20 21:24:25 <stintel> I see, good to know
Nov 20 21:25:09 <pepe2k> (excluding AR724x with burned eth)
Nov 20 21:26:33 <Borromini> stintel: isn't that a relatively recent box?
Nov 20 21:26:51 <stintel> well actually it's worse, I have just adopted it, upgraded to latest firmware, adopted again, and it already missed a heartbeat
Nov 20 21:26:55 <stintel> Borromini: which one?
Nov 20 21:27:14 <Borromini> you got a new PPC based box no this year?
Nov 20 21:27:28 <Borromini> or was that power 9 already (your workstation)
Nov 20 21:27:29 <stintel> power8? it's 2nd hand, force flashed wrong image, no access to BMC, so removed the flash chip to write with external programmer
Nov 20 21:27:44 <Borromini> oh :)
Nov 20 21:27:54 <stintel> no, I just created an account on raptorcs.com so I could see shipping quote
Nov 20 21:28:00 <stintel> USD1250 for shipping only
Nov 20 21:28:28 <Borromini> eh o_O
Nov 20 21:28:33 <stintel> that's a bit too much, add customs handling and import tax ..
Nov 20 21:28:36 <pepe2k> stintel: will they bring it themselves directly to your door for that price?!
Nov 20 21:28:37 <Borromini> ok so no non-x86_64 workstation yet?
Nov 20 21:28:42 <Borromini> pepe2k: in a pink tutu.
Nov 20 21:28:43 <stintel> Borromini: nope
Nov 20 21:28:56 <stintel> well for that price I can fly there and get it myself :P
Nov 20 21:28:57 <Borromini> ok i thought you already had it.
Nov 20 21:28:59 <Borromini> :P
Nov 20 21:29:00 <pepe2k> Borromini: signing and dancing
Nov 20 21:29:11 <Borromini> pepe2k: yep. 'sign here please'
Nov 20 21:29:17 <stintel> but this would be 8k EUR for mobo + 2x18c CPU + 2x heatsink
Nov 20 21:29:36 <Borromini> you can get quite a few threadrippers for that.
Nov 20 21:29:43 <pepe2k> stintel: one month without beer and you get two
Nov 20 21:29:43 <stintel> still need to add expensive DDR4 ECC RAM, a case that can fit the mobo, and storage
Nov 20 21:29:49 <Borromini> lol
Nov 20 21:30:00 <stintel> so I estimate around 10k EUR for a working box
Nov 20 21:30:21 <stintel> so yeah, you can build probably 2 top threadrippers for that
Nov 20 21:30:34 <stintel> and they are going to be faster too
Nov 20 21:30:56 <stintel> as much as I like the talos II idea ... money doesn't grow on a tree
Nov 20 21:31:23 <pepe2k> they do!
Nov 20 21:31:37 <pepe2k> on bush... but it's usually illegal to grow such things
Nov 20 21:32:03 <Borromini> they do it in mexico and they send you the DEA for doing that
Nov 20 21:32:17 <olmari> cotton field in USA ;)
Nov 20 21:32:19 <Borromini> i mean look at what happened to walter white
Nov 20 21:32:24 <olmari> so almost tree but not quite
Nov 20 21:32:31 <Borromini> :P
Nov 20 21:32:51 <olmari> rest of world uses somehting more duable and australia has plastic I think =(
Nov 20 21:35:48 <Borromini> i'm out guys goodnight
Nov 20 21:37:29 <olmari> oh I think I got something wrong way.. euros are cotton too... oh well
Nov 20 21:44:47 <owrt-1907-builds> build #42 of ipq40xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ipq40xx%2Fgeneric/builds/42
Nov 20 21:55:27 <t4h4[m]> https://forum.openwrt.org/t/sta-speed-slows-down-after-eap-reauthentication/48506 So.. This is caused by this commit -> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=0b2c42ced21a7bc053e0d729f85041f1e3b54fbc
Nov 20 21:59:30 <DonkeyHotei> Hauke: ^
Nov 20 22:00:09 * ldir has updated some documentation - proof I'm not a real developer
Nov 20 22:00:16 <stintel> pepe2k: thanks for that hint about ubnt and broken flash
Nov 20 22:00:40 <stintel> good that I finally got some soic clips or what were they called
Nov 20 22:01:10 <pepe2k> stintel: welcome, I think they recently started using flash S/N for some identification
Nov 20 22:02:21 <pepe2k> some modern devices I replaced flash were reporting Error-A12
Nov 20 22:03:19 <pepe2k> stintel: https://community.ui.com/questions/Edgerouter-ERLite-3-stopped-working-Error-A12-etc-passwd-size-0/7acb3f87-e471-45fe-94ba-c1b1dfc3f74a#answer/0a494f76-9741-4897-a647-f17a04bc2e02
Nov 20 22:05:04 <stintel> I wonder why I keep buying their stuff
Nov 20 22:05:24 <stintel> then again, find another PoE-PD switch with PoE-PT for that price
Nov 20 22:06:53 <Hauke> DonkeyHotei: I plan to update it again ;-)
Nov 20 22:10:38 <Hauke> t4h4[m]: I have some intermediate versions here: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mac80211-5.0
Nov 20 22:14:01 <pepe2k> stintel: https://www.reddit.com/r/Ubiquiti/comments/ddodo7/burned_installers_are_leaving_ubiquiti/
Nov 20 22:14:42 <pepe2k> and this one: https://www.theregister.co.uk/2019/11/07/ubiquiti_networks_phone_home/
Nov 20 22:15:12 <t4h4[m]> Hauke: any idea which patch in particular can cause this?
Nov 20 22:16:29 <t4h4[m]> Idk if this even affects non-mt76
Nov 20 22:17:57 <t4h4[m]> s/this/this bug/
Nov 20 22:22:09 <Hauke> t4h4[m]: was it working before 0b2c42ced21a7bc053e0d729f85041f1e3b54fbc  and broken after that commit?
Nov 20 22:22:21 <Hauke> this updates mac80211 from version 4.19 to 5.2-rcX
Nov 20 22:22:39 <Hauke> the link I posted also has the intermediate versions like 4.20 5.0 and 5.1
Nov 20 22:46:03 <stintel> pepe2k: maybe time to try this again: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/iproc
Nov 20 22:46:43 <stintel> and poke the switch until it configures my VLANs correctly :D
Nov 20 22:49:08 <pepe2k> Broadcom, nah :P
Nov 20 22:51:04 <stintel> pepe2k: I've succesfully erased, and then written + verified to the US-8 flash
Nov 20 22:53:29 <pepe2k> so, not a flash problem
Nov 20 22:53:46 <KanjiMonster> stintel: is the HR2 switch core even supported?
Nov 20 22:54:16 <stintel> KanjiMonster: doubt it
Nov 20 22:54:30 <stintel> that's why I said "poke until" ;)
Nov 20 23:03:49 <KanjiMonster> stintel: dunno if you are aware, OpenNetworkLinux has a iproc 4.14 patch -> https://github.com/opencomputeproject/OpenNetworkLinux/blob/master/packages/base/any/kernels/4.14-lts/patches/brcm-iproc-4.14.patch
Nov 20 23:10:22 <stintel> KanjiMonster: cool. didn't even know about opennetworklinux
Nov 20 23:11:22 <KanjiMonster> stintel: it's what sometimes used in higher end switches (those with 10G ports and faster)
Nov 20 23:11:58 <stintel> interesting. there might be hope for the future :)
Nov 20 23:12:23 <KanjiMonster> but the whole switch core logic is driven by closed source code
Nov 20 23:15:37 <KanjiMonster> stintel: on arm (or powerpc) based switches they use u-boot, you can find the sources here -> https://github.com/opencomputeproject/onie (and 3.2 based iproc support ;)
Nov 20 23:18:16 <Slimey> hi
Nov 20 23:24:12 <Hauke> KanjiMonster: so the switch driver contains closed source code?
Nov 20 23:24:28 <Hauke> not only a FW running on some other CPU, but something running on the same CPU as Linux?
Nov 20 23:29:22 <KanjiMonster> Hauke: yes. https://github.com/Broadcom-Switch/OpenNSL - in the sdk-* directory you'll find a driver that basically exposes the switch register space ("cmicd" in case of iproc) to userspace, and then a closed sourced app that actually programs the switch registers
Nov 20 23:32:30 <Hauke> KanjiMonster: ok then I do not have to look at it
Nov 20 23:33:02 <KanjiMonster> yes, there is nothing of interest in there, all the juicy stuff is closed
Nov 21 00:12:31 <stintel> russell--: the flash chip of the Power8 box was apparently broken. replaced it today and it's up and running again
Nov 21 00:12:46 <stintel> and with that I have my OpenWrt build/deploy pipeline back :)
Nov 21 00:23:48 <russell--> yay!
Nov 21 00:39:09 <t4h4[m]> Hauke: yes it works normally with a build at d616b2c906690d2e471144ca12b0a9ed28de21c2. Apply 0b2c42ced21a7bc053e0d729f85041f1e3b54fbc (and mt76 kernel oops patch 09c33df76fb88d80a804dc128f7bd08c361e998b) and it breaks.
Nov 21 00:41:25 <stintel> pfff that image building code
Nov 21 00:52:37 <stintel> Hauke: any idea when you will update mac80211 again? I'm seeing strange issues on RPi0W as well. sometimes it associates but there seems to be no traffic
Nov 21 00:54:40 <stintel> ran into this on the 2 Pi0W in my pipeline, they boot after sysupgrade, even show "wlan0: link becomes ready" but there is no traffic
Nov 21 00:59:44 <stintel> hmmm, the 2nd one did not become reachable after another reboot even
Nov 21 00:59:45 <stintel> 02:56:54.569057 b8:27:eb:35:69:b6 > ff:ff:ff:ff:ff:ff Null Unnumbered, xid, Flags [Response], length 46: 01 00
Nov 21 00:59:46 <stintel> 02:56:54.647568 IP6 :: > ff02::1:ff35:69b6: ICMP6, neighbor solicitation, who has fe80::ba27:ebff:fe35:69b6, length 32
Nov 21 01:00:01 <stintel> I did see only this
Nov 21 01:00:13 <stintel> when it associated. no DHCP or so
Nov 21 01:10:20 <owrt-1806-builds> build #41 of ipq40xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/ipq40xx%2Fgeneric/builds/41
**** ENDING LOGGING AT Thu Nov 21 02:59:57 2019