**** BEGIN LOGGING AT Wed Nov 07 02:59:59 2018 Nov 07 06:20:43 morning Nov 07 06:20:48 blogic: how can I access 138.201.250.213:~/backports-v4.18.5.tar.xz ? Nov 07 06:54:08 nbd: Is mt7603e expected to successfully recover from a manual watchdog reset currently? Nov 07 07:44:19 Hauke: thanks for the hint i will have a look and give them a try Nov 07 07:45:54 Hauke: one thing is strange! why are there binaries in the repo under prpl-demo-utils? Nov 07 08:50:19 hauke: zorun: I will take care of it Nov 07 09:16:05 xback: ok, thanks! Nov 07 10:05:50 ugh. unbound rebind protection disabled yet does not resolve records pointing to internal IPs Nov 07 10:06:43 Monkeh: at least in my tests it does Nov 07 10:11:34 nbd: I tried setting that brcmf_cfg80211_ops.update_connect_params = NULL but that did not solve my problem Nov 07 10:17:18 stintel: might have been to late at that point - there is a callback that returns a copy of that struct; so probably that is called before nulling the pointer Nov 07 10:17:28 s/callback/function/ Nov 07 10:19:25 KanjiMonster: it didn't even work when I removed that callback completely Nov 07 10:19:36 afair Nov 07 10:20:24 KanjiMonster: as in https://pastebin.com/UqV8Tyrz Nov 07 10:21:54 stintel: with that change it should at least silence the warning with roamoff=1 Nov 07 10:22:51 I will rebuild and test again Nov 07 10:26:21 KanjiMonster: can confirm that it does NOT silence that warning Nov 07 10:26:25 oh wait Nov 07 10:26:42 sorry, I'm multitasking Nov 07 10:28:02 it's one of those days where everything seems to be broken Nov 07 10:28:38 I know these days Nov 07 10:28:57 started with colleague behind CGN unable to connect to our company IPsec VPN, our OpenWrt firewall becoming unreachable - my colleagues blame the firewall, I still suspect the switch Nov 07 10:29:06 Slack acting up (why do people even insist on using that?!) Nov 07 10:30:05 I once spend (what felt like) hours on finding out why none of my changes made it in the image, until I found out I was scp'ing a different (obviously unchanged) image all the time Nov 07 10:31:25 hmmm that roamoff=0 really seems to make my rpi0w wifi slow to a crawl Nov 07 10:34:55 stintel: did you set it before the wiphy register call? Nov 07 10:35:05 ah Nov 07 10:35:21 missed the fact that you tried removing it as well Nov 07 10:35:29 does it hit the same warning? Nov 07 10:35:31 yeah, but I retested that now and it seems to be fine now Nov 07 10:35:47 sorry 'bout the noise Nov 07 10:36:04 now that I know it works like that, let me see if I can fix it nicely Nov 07 10:36:28 :) Nov 07 10:36:43 it's really weird though, I've rebuilt like 10 times to be sure and I kept hitting that issue Nov 07 10:36:53 I must be getting old Nov 07 10:37:15 although I wonder if the warning isn't supposed to be the other way round, i.e. warn if someone claims to support roaming (flag is set) and the callback isn't populated Nov 07 10:37:41 well we could wait for Arend to come up with a fix Nov 07 10:37:58 but that means master is broken on brcm2708 Nov 07 10:38:28 the target probably doesn't have many users, but still :) Nov 07 10:39:11 also, isn't it weird that only 2 drivers set that flag? is it so exotic then? Nov 07 10:40:47 KanjiMonster: both make sense. i guess the current warning is that way because there are other places in the code that only check for the callback, not the flag Nov 07 10:41:54 https://gist.github.com/stintel/e4956b8f8e73ba887d1e0d44182db644 going to try this now Nov 07 10:43:29 nbd: but some the other places already existed before the warning was introduced, which is why I wonder if the warning isn't overreaching. And why I'm not sure if removing the callback pointer is the right solution (don't know enough about the code to determine that) Nov 07 10:44:04 zorun: patch pushed to 18.06. I compile-tested both kernels just to be safe. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=aa0aa47aa176133ff302c4a5cea785d971bc26b3 Nov 07 10:45:53 xback: thanks! Nov 07 11:13:23 nbd: KanjiMonster: fyi, https://gist.github.com/stintel/e4956b8f8e73ba887d1e0d44182db644 seems to work Nov 07 11:21:03 stintel: does this also work the other way round, i.e. nopping the callback if noroam=1 instead of populating it? (to verify that the change is applied before the struct is copied) Nov 07 11:26:23 KanjiMonster: I tried that, it didn't but let me try it again just to be sure Nov 07 11:27:04 stintel: if you already did, the it's fine Nov 07 11:31:12 yeah but I already tried completely killing that callback and that didn't work then either Nov 07 11:32:25 so in case nopping the callback if roamoff=1 doesn't work, what do you think of https://gist.github.com/stintel/19c4586e40d3f95d34432c131df8aa09 ? Nov 07 11:32:41 is that commit message good enough? Nov 07 11:34:07 and just to verify, this is what you mean with other way around: https://gist.github.com/stintel/fa4012288541dcaa6aa01a5869b814fa ? Nov 07 11:36:46 nbd: i remember you wrote sth here about issues with mt76 and iOS /apple ? i think i'm observing this issue, too - and just wanted to ask if there's a bug report somewhere which i could follow Nov 07 11:47:23 KanjiMonster: ok, https://gist.github.com/stintel/fa4012288541dcaa6aa01a5869b814fa doesn't work Nov 07 11:47:52 stintel: if nopping the callback doesn't work, then it means that the ops are copied before that, and thus your change would break the case of roamoff=0 Nov 07 11:49:50 KanjiMonster: so https://gist.github.com/stintel/19c4586e40d3f95d34432c131df8aa09 looks good to you then ? Nov 07 11:50:09 also should I base this on wireless-testing, or what. I'm reading https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches but not seen it yet Nov 07 11:50:41 and I add Cc: stable@ # 4.19 myself ? Nov 07 11:51:40 stintel: no, what I mean is that this change will (likely) break the case of roamoff=0, as now update_connect_params is never set from the wireless point of view Nov 07 11:52:04 ah Nov 07 11:54:25 you probably need to make brcmf_cfg80211_get_ops() aware of the state of roamoff and nop/populate the pointer there in the copied struct to not break the default case Nov 07 12:02:53 KanjiMonster: in that case I'm stuck, I don't see how to get ifp in brcmf_cfg80211_get_ops Nov 07 12:03:11 I'll just leave it to the adults, as ldir would say Nov 07 12:05:30 rotanid: what issues are you having? Nov 07 12:06:19 KanjiMonster: still works with roamoff=0 though Nov 07 12:06:45 stintel: did you test if roaming still works? Nov 07 12:06:54 or not. I do get "wlan0: link becomes ready" Nov 07 12:07:01 but getting no route to host Nov 07 12:08:24 hmm, had to run "ifup lan", wifi didn't seem to be enough to do dhcp Nov 07 12:08:55 now it has an IP and I can access it. let me try to force roaming Nov 07 12:09:46 nbd: forgive me, i don't have technical details, as i don't have apple devices myself i can't reproduce it on purpose. i just think it's related to my neighbors iphone logging into the AP which is running the mt76 driver (latest openwrt 18.06 branch) Nov 07 12:10:39 i can't point you at the right bug report, because there are lots of open bug reports with sometimes different, sometimes overlapping topics where people throw in new information Nov 07 12:10:45 so it's kind of hard to keep track of Nov 07 12:10:59 ok, thank you nevertheless for your work Nov 07 12:11:15 what i can say is that i think the latest version which is currently in openwrt master (and will be backported to 18.06 soon hopefully), ios devices should no longer bring down the network for other users Nov 07 12:11:26 there might still be some connectivity issues specific to ios devices Nov 07 12:11:33 iwi Nov 07 12:11:34 but it should only affect the link to the ios device itself Nov 07 12:11:41 oops, wrong keyboard Nov 07 12:12:05 nbd: that sounds great, i'll give it a try! Nov 07 12:12:12 i hope to get the remaining issues sorted out as well in the near future Nov 07 12:12:44 i know it's not much, but if we meet again at ccc, a beverage is on me ;) Nov 07 12:12:58 thanks :) Nov 07 12:13:00 KanjiMonster: ok, "iw dev wlan0 del" -> No error information (-524) Nov 07 12:13:03 i won't be there this year though Nov 07 12:13:06 maybe next year Nov 07 12:13:10 so yeah, seems utterly broken now too Nov 07 12:13:20 oh, ok. maybe another time. Nov 07 12:13:29 I give up, back to day job Nov 07 12:15:17 nbd: did you find a way to reproduce the issue with an iOS device in your hand or was it purely by reading logs and digging code? Nov 07 12:16:13 stintel: whitespace broken, but this should do the trick: https://pastebin.com/WD3383t6 Nov 07 12:17:43 purely by reading logs and digging code Nov 07 12:18:04 and experience probably ;) Nov 07 12:18:18 sure Nov 07 12:18:20 it's not the first time apple devices break otherwise perfectly working wifi Nov 07 12:18:50 stintel: assuming update_connect_params is not needed outside of roaming Nov 07 12:21:29 good to have experienced people Nov 07 12:33:36 KanjiMonster: nbd thought so and after looking at https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git/tree/include/net/cfg80211.h#n2981 I think I can confirm Nov 07 12:40:10 KanjiMonster: seems I'm getting the same "No error information (-524)" on iw wlan0 del with that patch Nov 07 12:40:18 I'll look back at this tonight Nov 07 12:41:25 nbd: In my test case it results in the same endless loop of MCU message timeouts I get with my 4addr issue Nov 07 12:41:37 but getting that with both roamoff=0 and roamoff=1 Nov 07 12:41:52 I haven't tried with the radio configured as an AP yet Nov 07 12:41:59 I'd say brcmfmac is in quite the bad state currently Nov 07 12:43:07 nbd: I can say I see no performance issues with MFP now at least? :) Nov 07 12:43:21 Assuming I remembered to have that enabled AP side still Nov 07 12:57:11 'lo Nov 07 13:15:40 Monkeh: what device are you using? Nov 07 13:16:56 nbd: The test example is a custom carrier board for an MT7628N module, but I'm pretty sure I can reproduce with my RE350 with a normal MT7603E Nov 07 13:17:35 on my mt7603e based device it works just fine if i trigger the reset at run time Nov 07 13:17:43 i didn't test mt7628 in a while though Nov 07 13:18:04 I was able to reproduce the 4addr failures on the RE350 a while back at any rate. Nov 07 13:19:05 Give me a few minutes to lash up and I'll try the RE350 Nov 07 13:20:00 nbd: Have you tried it with the radio up as a client? Nov 07 13:53:25 nbd: Cannot reproduce with the MT7603E so far Nov 07 13:54:16 Either issue Nov 07 13:55:47 dedeckeh: ping Nov 07 13:55:55 Monkeh: great Nov 07 13:56:14 The 4addr issue I'm pretty sure I used to be able to trigger on it, so that's something Nov 07 14:00:19 stintel: it is expecteds Nov 07 14:00:27 stintel: brcmfmac does not allow deleting wlan0 or wlan1 Nov 07 14:00:37 stintel: it's harmless error Nov 07 14:00:47 stintel: OpenWrt still setup interfaces just fine anyway Nov 07 14:00:58 * rmilecki afk for a bit Nov 07 14:12:42 nbd: Another old favourite test of mt7603e AP with mt7628 STA is now working except for the same 4addr failure as well. Much improvement :) Nov 07 14:23:38 ldir:pong Nov 07 14:24:03 stintel: i'm bacck online Nov 07 14:25:57 build #620 of layerscape/armv8_64b is complete: Failure [failed images] Build details are at http://phase1.builds.lede-project.org/builders/layerscape%2Farmv8_64b/builds/620 blamelist: Rafa? Mi?ecki , Felix Fietkau Nov 07 14:28:45 Monkeh: i can reproduce the mt7628 issue Nov 07 14:28:48 will look into it Nov 07 14:28:51 Hurrah Nov 07 14:28:53 Many thanks Nov 07 14:29:51 nbd: And many thanks for the large round of fixes already made :) Nov 07 14:30:02 dedeckeh: I'm thinking about dropping dnsmasq patch 210-dnssec-improve-timestamp-heuristic - we don't use the timestamp method of enabling dnssec validation any more...for a while actually. Thoughts? Nov 07 14:30:09 i may actually put this RE350 back into service now it's not a trap Nov 07 14:32:06 mirko: ping Nov 07 14:34:31 ldir:let me check Nov 07 14:36:01 The other option is to send it upstream to Simon, but I wonder if it could do with some #ifdef LINUX type trapping. Nov 07 14:56:32 ldir:agree on removing the patch Nov 07 14:57:07 ldir:as you pointed out the file timestamp method we're not using it anymore Nov 07 14:58:01 ldir:and the usage of timestamp_time depends on timestamp_file being set Nov 07 14:58:27 ok, it's on my todo list for the next bump. Nov 07 15:00:07 Monkeh: which issue do you have which you describe with 7603/7628 ? Nov 07 15:03:20 rotanid: TX hangs with 4addr STAs. Nov 07 15:35:59 jow: pong Nov 07 15:51:37 mirko: I think you can shutdown the nanl host now Nov 07 15:55:01 RIP :) Nov 07 15:55:11 Monkeh: mind telling me what 4addr STAs are? *duck* Nov 07 15:55:14 rmilecki: sorry, day job Nov 07 16:07:00 jow: dev2.openwrt.org, git.openwrt.org are currently openwrt related still running hosts - one is the old trac, the other one you just migrated - correct? Nov 07 16:27:47 mirko: correct Nov 07 17:24:40 what creates /etc/config/wireless ? Nov 07 17:25:16 wifi detect Nov 07 17:25:56 I have a system where disabled is set to 0, but on others it is set to 1 by default it seems...not sure of why there is a difference Nov 07 17:26:22 does it (re) run on module reload or anything like that? Nov 07 17:26:40 i don't think so Nov 07 17:26:50 netifd probably launches it Nov 07 17:29:04 mangix: 'wifi config' nowadays Nov 07 17:32:38 nbd: going on 24h here, but i see you already pushed an update to master, i assume that contains this singular patch i applied :) Nov 07 17:32:48 yes, among other fixes Nov 07 17:33:21 :) Nov 07 17:33:51 i assume you don't mind me trying that update on stable? Nov 07 17:34:50 sorry, going on 24h should have been going on 48h :-/ Nov 07 17:35:19 of course i don't mind :) Nov 07 17:35:29 if it works for you, i will backport the entire driver to stable Nov 07 17:35:40 so stable gets mt76x0 and usb support as well Nov 07 17:36:33 :) i'll keep you posted. Nov 07 18:17:37 Hi what's nft-qos? Nov 07 18:26:21 so, google thinks that the NanoPI NEO2 is supported in openwrt, but I cannot find it anywhere in the menuconfig target listing. Any clues? Nov 07 18:26:44 google doesn't, the sites google index do Nov 07 18:26:49 i'd start investigating there :) Nov 07 18:27:00 well yeah Nov 07 18:27:08 openwrt page says target is 'sunxi' Nov 07 18:27:16 https://openwrt.org/toh/hwdata/friendlyelec/friendlyelec_nanopi_neo_plus2 Nov 07 18:29:01 greearb_: but it's cortex a53 processor, You chose wrong subtarget. Nov 07 18:30:58 Seems to be under all-winner, then the 64-bit processor option...now 'target profile' offers an option for Nanopi Nov 07 18:36:27 greearb_: doesn't it turn up when you use the buildroot search function (a forward slash)? Nov 07 18:37:12 sort of, but unless you know the top-level target, then you can't select it Nov 07 18:38:19 i thought it showed in the search results, but i'm probably mistaken Nov 07 18:45:35 Anyone know if the suggested WUSB6300 driver is kmod-rtl8xxxu? Nov 07 20:05:48 feckert: I do not know why there are only avalibale as binaries Nov 07 21:32:24 so, I have a .config that works well for me with r7800 (it has perl configured, etc). I tried copying that .config to a new tree that compiles for neo2 platform. Once I use menuconfig to change to neo2 target, perl is unselected, and lots of other changes are unselected as well). That seem normal? Nov 07 21:33:08 dependencies for those packages? Nov 07 21:33:44 I'm able to (re)select them in menuconfig, so not sure that is the issue Nov 07 21:34:06 oh Nov 07 21:34:07 weird Nov 07 21:34:29 dunno if theres any verbosity for kconf stuff Nov 07 21:45:03 ./scripts/diffconfig.sh in the original > /tmp/foo.txt, remove first 3 lines having to do with arch, then append the rest to the .config in the new tree, and that seems to be working at least somewhat Nov 07 21:45:30 heh Nov 07 21:46:16 if the r7800 is a different "target system" than the neo2, then changing that to the one for neo2 might be the problem Nov 07 21:46:49 it's qca ARM for sunxi (no idea what sunxi is) Nov 07 21:46:52 yeah, like menuconfig re-inits itself to defaults Nov 07 21:46:59 sunxi is allwinner Nov 07 21:47:01 right? Nov 07 21:47:04 yes Nov 07 21:47:09 because cryptic arch names Nov 07 21:47:10 :D Nov 07 21:47:12 :D Nov 07 21:48:35 menuconfig is nice when it works as you expect it to. When it doesn't, it is a nightmare Nov 07 21:49:13 i think it's a precaution to not keep any cruft that might work nicely on arch A but might cripple arch B Nov 07 21:49:29 yeah, it tries to do the right thing Nov 07 21:53:56 oh, I know *why* it does things that way, but I often wish there were a way to change two things "simultaneously" in it, so I can change to a sub-arch which I know does support the things I want Nov 07 22:12:21 oh, yeah Nov 07 22:16:06 hmmm, are there any openwrt supported boxes with FXO ports? Nov 07 22:16:44 like maybe a lantiq? Nov 07 22:17:18 sucks that cheap ATSs exist (FXS) but not for the other way round Nov 07 22:18:02 bonus points if it can use the power from the line Nov 07 22:22:00 oh hm, maybe a fritzbox **** BEGIN LOGGING AT Wed Nov 07 23:30:56 2018 Nov 07 23:31:17 * mangix *mind blown* Nov 07 23:31:28 Xi = phonetic translation of system Nov 07 23:31:32 ahhhhh Nov 07 23:31:34 hoping I can get some rtl USB wifi NICs to work on it...got the driver cross compiled, but still getting openwrt plus my stuff on it Nov 07 23:31:48 so how did they get from allwinner to sun Nov 07 23:31:49 :D Nov 07 23:32:02 Yes, sunxi support is improving greatly on recently. Thanks to the sunxi community and Bootling Nov 07 23:32:53 jwh (IRC): http://linux-sunxi.org/Main_Page#What_is_sunxi Nov 07 23:33:41 "Allwinner does not actively participate in or support this community. In fact, it is violating the GPLv2 license in several ways and has so far not shown willingness to resolve this." Nov 07 23:34:10 * karlp is currently laying out an draft replacing an ar9331 platform with a sunxi platform :) Nov 07 23:34:38 Most of the board support packages came with a heavily modified 3.4 kernel. Even before devicetree was popular Nov 07 23:37:25 yeah, it's muchhhhhh better now Nov 07 23:37:49 karlp, what hardware are you looking at using? Nov 07 23:40:07 is the neo2 using realtek ethernet? Nov 07 23:40:30 root@OpenWrt:/home/lanforge# ethtool -i eth0 Nov 07 23:40:30 driver: st_mac100 Nov 07 23:41:12 interesting... Nov 07 23:41:26 ah makes sense nvm Nov 07 23:41:35 greearb_: Don't expect much difference between the different boards. Usually the RAM bandwidth is the limiting factor Nov 07 23:42:03 And most of the use the internal gmac + Realtek PHY Nov 07 23:42:07 luaraneda, sure, I'm more interested in form factor and easy access to serial port, or maybe built-on NICs, etc. Nov 07 23:43:09 That's whats great about them. You can find some board that are half the size of a raspberry pi Nov 07 23:43:33 Like some nanopi boards Nov 07 23:43:46 yeah, I'm using nanoPi neo2 right now Nov 07 23:51:10 greearb_: using a nanopi duo2 right now, Nov 07 23:51:25 gonna solder down som so8 flash on it, Nov 07 23:51:51 ok for a proto, not sure what ll go down the road Nov 07 23:52:25 speaking of wifi NICs, my mt76 one becomes supported in kernel 4.20. That'll be fun. I no doubt will break it with my use case. Nov 07 23:52:49 the driver that is Nov 07 23:53:19 allwinner h3 designs are "off the shelf" shouldn't be hard to get one customized for us as we need. Nov 07 23:55:19 *nft-qos Nov 07 23:57:49 The problem with most Allwinner SoCs is that they don't have high speed buses, like PCIe, to connect a good WiFi card/SoC. Instead, they use WiFi/Bluetooth combo modules connected by SDIO Nov 07 23:58:20 how fast is SDIO? Nov 07 23:59:12 mangix (IRC): I was just looking a that. It seems to depend on the specification that the controller implements Nov 07 23:59:31 hmmmm Nov 07 23:59:41 I don't think allwinner does SDXC Nov 08 00:00:10 I doubt they support UHS either Nov 08 00:01:02 yep. they probably are high-speed controllers (25 MB/S) Nov 08 00:01:12 I'm using ethernet, with wifi just as a config AP, Nov 08 00:01:18 don't need AC performance or anything. Nov 08 00:01:26 luaraneda: that is horrible Nov 08 00:01:39 sdio has lots of versions, Nov 08 00:01:53 if my /etc/config/firewall file has only one commented out line, what could be creating iptable rules? Nov 08 00:02:28 mangix (IRC): But that's only for WiFi. The Ethernet MAC is internally connected (I'm assuming AHB or some version of AXI) Nov 08 00:03:09 oh of course Nov 08 00:03:17 no way to do 900MB/s otherwise Nov 08 00:03:29 According to the H5's datasheet, it's SDIO3.0 Nov 08 00:04:14 That means 50 MB/S Nov 08 00:04:22 sdio3 can do uhs-1 speeds. Nov 08 00:06:25 From H5's datasheet: "1-bit or 4-bit data bus transfer mode for connecting to an external Wi-Fi module up to 150MHz in SDR mode and 50MHz in DDR mode" Nov 08 00:08:28 It's not PCIe, but it should be enough for a small device with a good Wi-Fi module Nov 08 00:10:16 I noticed that 'dhclient' is trying to exec /sbin/dhclient-script, but instead it is located in /usr/sbin/dhclient-script Nov 08 00:10:42 easy enough to fix with softlink, but probably should be fixed eventually..not sure the correct fix Nov 08 00:14:01 hm, where is the package? Nov 08 00:14:12 ? Nov 08 00:14:28 also uh, any reason you chose dhclient over dhcpcd? Nov 08 00:14:43 I've used it forever and it is already integrated into my product Nov 08 00:14:52 ah Nov 08 00:15:00 I like to be able to customize it's callback script Nov 08 00:15:10 but in this case, just trying to get 'dhclient eth0' to work Nov 08 00:17:05 I did not notice this dhclient problem on r7800 btw, so maybe something special about the sunxi target and/or the fact it targets an ext4 file system Nov 08 00:21:28 neo2 will not reboot clean, btw...hangs on startup Nov 08 00:52:32 bugger, gdb won't build for neo2 Nov 08 00:53:29 heading home, will deal with it later Nov 08 01:00:04 build #1093 of x86/legacy is complete: Failure [failed kmodupload] Build details are at http://phase1.builds.lede-project.org/builders/x86%2Flegacy/builds/1093 blamelist: Rafa? Mi?ecki , Felix Fietkau **** ENDING LOGGING AT Thu Nov 08 02:59:59 2018