**** BEGIN LOGGING AT Wed Sep 26 03:00:00 2018 Sep 26 05:05:25 Hauke: feel free to push mac80211 Sep 26 05:05:34 i am done with my testing and it all looks ace to me Sep 26 07:31:30 did we get any reports of IPsec issues with 18.06.*? Sep 26 07:47:50 stintel:not that I'm aware of Sep 26 07:48:35 ok, after ~30d uptime the openwrt firewall at our office started showing weird problems with IPsec connections Sep 26 07:48:55 kernel memory leak might exhibit "random" behavior I guess? Sep 26 07:48:56 https://lkml.org/lkml/2018/8/23/838 Sep 26 07:49:54 restarting strongswan didn't solve it, so the next day my colleagues rebooted the firewall and then it was OK Sep 26 07:50:05 all the more reason to suspect it's kernel related I'd say Sep 26 07:59:26 blogic:ping Sep 26 11:03:03 dedeckeh: pong Sep 26 11:51:39 hi, is it normal a 37 bogomips reported by kernel in mvebu? Sep 26 11:51:48 "Calibrating delay loop (skipped), value calculated using timer frequency.. 37.50 BogoMIPS" Sep 26 11:55:46 it's a 1.2GHz CPU Sep 26 12:49:19 danitool: i think you can totally ignore BogoMIPS Sep 26 12:49:29 ok Sep 26 15:18:50 it's on sunxi too, Sep 26 15:19:49 karlp: that is the nohz/dyntick thing Sep 26 15:19:59 since that was merged, bogomips can be ignored Sep 26 15:20:35 yeah, I just looked at it and went, "hrm, that's not right, gonna ignore that" Sep 26 15:20:47 :P Sep 26 15:20:47 which is about what Idid with bogomips numbers before too.... soooo Sep 26 15:21:00 maybe they should stop printing out garbage... but hey, what would I know :) Sep 26 15:21:26 karlp: upstream .. pfff :-D Sep 26 15:21:40 karlp: at least you are not blaming owrt for this :-D Sep 26 15:28:13 no of course not :) Sep 26 15:47:20 blogic: hi! am I correct in remembering that ipq806x dsa will come sometime in october? Sep 26 15:53:16 sigh, I wish people would divert the energy spent to disable ipv6 everywhere into supporting it instead Sep 26 16:11:48 jow: That would require actual mental effort Sep 26 16:15:08 The big problem IMHO are the ISPs. Here (Chile), they are investing in CGT (Carrier-grade NAT) equipment instead of implementing IPv6... Sep 26 16:29:40 I would like to enable ipv6, but my isp uses 6rd which didn't work too well with sqm cake last time I tried Sep 26 17:40:00 huaracheguarache: what problems did you have? Sep 26 17:40:43 luaraneda: this is a widespread problem- Sep 26 17:40:48 SwedeMike: browsing the web was a terrible experience since everything was loading very slowly Sep 26 17:41:11 huaracheguarache: and it worked better without sqm? Sep 26 17:41:15 yeah Sep 26 17:41:54 cake works perfectly on ipv4 only, so that's what I'm running now Sep 26 17:43:04 huaracheguarache: sounds like it might have treated all 6RD packets as a single flow? So that all IPv6 traffic had to compete as a single flow against lots of IPv4 flows? Sep 26 17:43:18 probably Sep 26 17:45:01 ldir: ^^ do you know anything about cake and 6rd? you seem to be working on some 6in4 stuff in your tree Sep 26 17:46:50 Hauke: I'm curious, when you updated mac80211, why did you update to 4.19-rc4 and not the 4.19-rc5 from your mac80211 tree? Sep 26 17:47:12 blogic: I am busy today, will have a lok at it tomorrow Sep 26 17:47:27 blogic: I am also fine with it Sep 26 17:48:03 blogic: when we commit the mac80211 update people will start to complain anyway ;-) Sep 26 17:52:15 my mac80211 tree is at 4.19-rc5, but there are not changes between 4.19-rc4 Sep 26 17:52:32 Ah, OK. Sep 26 18:21:52 Hauke: I'm about to start checking out and compiling the mac80211 changes on an ASUS RT-AC58U (ipq40xx / QCA4019), so I might start complaining later Sep 26 19:07:23 Hauke: I think there is a typo in target/linux/ipq40xx/Makefile Sep 26 19:07:59 The firmware selected is "ath10k-firmware-qca4019-ct-ct" but it doesn't exist Sep 26 19:08:31 The options are "ath10k-firmware-qca4019-ct" and "ath10k-firmware-qca4019-ct-htt" Sep 26 19:09:15 luaraneda: two -ct seams wrong Sep 26 19:09:23 please try ath10k-firmware-qca4019-ct Sep 26 19:09:33 ok Sep 26 19:11:17 I'm currently connected with an Ethernet cable to the router :( Sep 26 19:22:13 Hauke: Now it works, but the firmware loading is a little noisy: https://pastebin.com/ChviphyT Sep 26 19:22:46 It first try to load "ath10k/fwcfg-ahb-a000000.wifi.txt" Sep 26 20:18:53 luaraneda: do you happen to use WDS/ 4addr? I don't really want to cry wolf yet, but I think there may be an issue with the new backports and WDS-AP mode (seems to be fine as WDS-Client) Sep 26 20:20:49 (first noticed with ath10k/ QCA9984, but apparently also with ath9k/ AR9344, but again - early testing) Sep 26 20:27:03 (the WDS-Client is always ath9k/ AR9344) Sep 26 22:07:32 pkgadd: no, it just a single unit servicing my home. Nothing fancy or special about it Sep 26 22:08:57 luaraneda: normal clients work just fine, I just seem to have an issue with WDS (the backports version of the WDS client doesn't appear to matter, apparently just the WDS-AP is problematic) Sep 26 22:14:00 pkgadd: Sorry, I don't have a setup to test WDS. So far clients are connecting and working fine Sep 26 22:14:44 I have to to more testing, specially 11w, but for that I have to boot windows 10... Sep 26 22:17:19 yep, currently building r8137-e9d92bf1e1 for a back to back comparison with r8155-c662299bf9, but it looks like a regression as WDS-AP (4addr) in both ath10k and ath9k, but my normal setup doesn't really lend itself to debugging - setting up a second (ath9k-only) testbed for further debugging Sep 26 22:22:00 (the normal WDS-client is downstairs and configured with DHCP, which means if it can't associate with the WDS-AP, it's completely inaccessible; I'll probably cobble together a tl-wdr4300 and bt hh5a for testing) **** ENDING LOGGING AT Thu Sep 27 02:59:59 2018