**** BEGIN LOGGING AT Fri Feb 01 02:59:56 2019 Feb 01 03:50:24 gch981213: do you know where the driver came from? I see fritzbox references but that's abuo it Feb 01 04:28:25 mangix: Pick a GPL code in http://osp.avm.de/ (I downloaded http://osp.avm.de/fritzbox/fritzbox-7590/source-files-FRITZ.Box_7590-07.01.tar.gz), extract the GPL-kernel.tar.gz inside, that driver is at fs/antfs Feb 01 05:29:18 ynezz: i was just going to review #1776 ("lantiq/xrx200: Add support for the Fritzbox 7360v2") and you were faster again :P Feb 01 05:37:03 can someone CLOSE this one for me, please? https://github.com/openwrt/openwrt/pull/1747 Feb 01 06:57:07 rmilecki: oh, sorry, didn't noticed it Feb 01 06:57:25 ynezz: you're doing great :) Feb 01 09:06:32 rmilecki: closed as requested :) Feb 01 09:24:41 swalker: yes, of course I use build logs, it's impossibru to read -jN logs on the console Feb 01 09:25:09 swalker: yay, finally the tool that parse the timing logs! where is that please? Feb 01 09:26:50 swalker: also, it's a pcie attached ssd, if logging makes it dog slow, that's ..... very non-ideal Feb 01 09:34:41 swalker: even without build logs, it's still ~5min rebuilds without any changes Feb 01 09:50:24 yeah, after a few runs, with logs, ~7min rebuilds, without logs ~5min rebuilds. logs have more impact than they should, but best would be... not rbeuilding stuff :) Feb 01 10:09:55 Hi all, I'm quite new to wireless and I've got a couple questions. 1) Why does hostapd have to add the wireless interface to the bridge? It seems like it behaves different when the wireless is part of a bridge. What's special about a bridge from hostapd point of view? Feb 01 10:11:24 2) I started doing some wireless monitoring and noticed that beacons were seen very rarely (order of minutes). I assume only appearing after an active-scan. From what I've read beacons should be broadcast every ~ 100ms. Should I be seeing beacons more often? Feb 01 10:13:02 Neighbor11111117: the bridge is your LAN. hence why the wireless is part of it. Feb 01 10:13:04 karlp: it's 40s here, imx6 target on ubuntu 14.04 host Feb 01 10:14:14 Borromini, I think I understand that. But why does hostapd care? Can't I just give it the wireless interface exclusively, why does it need to know about the LAN bridge? Feb 01 10:15:10 no idea Feb 01 10:16:18 Neighbor11111117: in many cases hostapd is responsible for creatig interfaces Feb 01 10:16:33 OpenWrt does it in some bash script Feb 01 10:16:43 not sure why it was done that way Feb 01 10:16:58 anyway, hostapd can create interfaces and so it supports bridging them Feb 01 10:17:12 so OpenWrt just configs hostapd to bridge wireless interfaces to the LAN bridge Feb 01 10:17:37 Neighbor11111117: i'm not 100% sure if I understaood your quesiton Feb 01 10:17:42 and if I answered it Feb 01 10:17:53 thanks for the response rmilecki and Borromini Feb 01 10:18:26 Based on my googling I get teh impression that there is something special about a bridge and wireless authentiators (there are other platforms that seem to care about whats attached to the bridge as well) Feb 01 10:18:53 I haven't quite put my finger on it. I presume bridge interfers with EAP in someway Feb 01 10:19:11 ah, right Feb 01 10:19:15 OK, let me try again Feb 01 10:19:35 I recall that now Feb 01 10:19:37 I guess if it is adding the interface to the bridge that could be the reason though as you said. Feb 01 10:19:44 it's more specific Feb 01 10:21:15 EAPoL frames appear on the wireless interfaces (e.g. wlan0) Feb 01 10:21:19 what's important however: if wlan0 is bridged with br-lan, then EAPoL frames get redirected from wlan0 to the br-lan Feb 01 10:21:20 in such case authenticator (e.g. hostapd) has to be aware of it & listen for EAPoL frames on the br-lan Feb 01 10:21:31 ynezz: so awesome, we're in this twilight zone of rebuilds being dog slow for some people, but not all and no-one really knows why :) Feb 01 10:22:24 karlp: i built a few 18.06 head images myself the last few days and haven't noticed any slowdowns? Feb 01 10:22:35 it's not a slowdown, it's always been like this. Feb 01 10:22:53 just someone else complained about it on the mailing list, and I confirmed, and it turns out that not everyone sees this Feb 01 10:23:10 ok, so nothing new, but not everyone affected Feb 01 10:23:29 yes. Feb 01 10:23:33 seems that way. Feb 01 10:23:35 rmilecki, that makes sense. But why does it need to listen to the br-lan can it not just listen to the wireless? Or is that not possible once something gets bridged? Feb 01 10:23:44 and no setup similarities (hardware or OS) to speak of? Feb 01 10:24:00 Neighbor11111117: it's how bridging is implemented Feb 01 10:24:13 Neighbor11111117: if wlan0 is bridged, listening on wlan0 won't give you any EAPoL frames Feb 01 10:24:22 it's how bridging work at the Linux kernel level Feb 01 10:24:28 Ahh that is exactly what I needed to know Feb 01 10:24:45 so the bridge takes control of the interface Feb 01 10:24:57 Neighbor11111117: there is 1 big drawback in it, if you listen on br-lan (as you have to) you can't say if EAPoL is coming from wlan0, or wlan0-1 or wlan1, etc. Feb 01 10:25:16 Neighbor11111117: it can result in some false positives, but nothing critical Feb 01 10:25:37 Neighbor11111117: in some rare cases hostapd may believe STA sent frame on wlan0 which it was received on wlan1 Feb 01 10:25:51 very interesting Feb 01 10:25:59 thanks rmilecki Feb 01 10:26:01 it has been resolved by passing EAPoL frames using nl80211 protocol but we didn't implemented it in OpenWrt yet Feb 01 10:26:05 no problem Feb 01 10:26:26 one last quick question. Can you test your hostapd locally using wpa_supplicant? Feb 01 10:26:39 I.e. can I ran wpa_supplicant on the same machine as hostapd? Feb 01 10:27:10 using real hardware - I don't know Feb 01 10:27:15 you can experiemnt with hwsim Feb 01 10:27:22 mac80211_hwsim or something like that Feb 01 10:27:24 karlp: well, just helping you to figure out where the problem is so you can fix it :) Feb 01 10:27:37 karlp: maybe it's target/host specific? Feb 01 10:27:39 Neighbor11111117: using real hw it may be impossible Feb 01 10:29:11 The reason I ask is twofold. 1) As you just explained on the bridge hostapd can't tell which interface it came from. So couldn't I send an ethernet EAPOL to the bridge? 2) jow mentioned that as a way to use one authetnciator daemon over multiple wireless interfaces with netifd Feb 01 10:29:13 ynezz: yeah, thanks, it is good to know that more people are _not_ seeing this, it's not just a collective "that's just how it is" Feb 01 10:30:57 BTW I would try to build from scratch on the same box Feb 01 10:31:41 I've seen some weird bugs while upgrading few years old LEDE repository to latest master Feb 01 10:31:44 Neighbor11111117: yeah, sending EAPoL frames to bridge should work, I was thinking you want to hack real air traffic Feb 01 10:32:11 awesome thanks, much appreciated Feb 01 10:32:19 getting my head round wireless, it's pretty fun! Feb 01 10:33:44 fun until you get into some really ugly problems with some frames missing, hw radio failing, closed source firmware problems, etc :P Feb 01 10:33:52 it's a nightmare then :P Feb 01 10:34:54 I've asked yesterday, but didn't got any reply, so trying again today: I'm wondering if anyone has seen that yet with 4.19 kernels, but it seems like the kconfig behaves differently on different host systems ie. I see different behaviour on debian jessie 8.10 and ubuntu 14.04 for example in my case, ubuntu 14.04 host and 4.19 kernel for imx6 works fine with `make V=s target/linux/{clean,compile}` but Feb 01 10:35:00 on debian 8.10 `make V=s target/linux/{clean,compile}` stops at kconfig step due to missing symbols Feb 01 10:35:44 ynezz: any target on 4.19 yet? Feb 01 10:36:01 i can try master on my debian 10 desktop if you want. Feb 01 10:36:20 * russell-- starting to poke at mt76x8 devices again, wonders if anyone has given any more thought to the problem of controlling the agpio register bits via device tree? Feb 01 10:41:08 ynezz: it's always been lik ethis for me, no matter how many clones I have, on both this computer and my old one. Feb 01 10:41:16 but sure, I can try again. Feb 01 10:41:23 and always Fedora? Feb 01 10:41:30 yeah Feb 01 10:41:37 various versions back to fc17 or so Feb 01 10:41:49 but lot sof openwrt makefile improvements since then too Feb 01 10:41:50 and the other affected guy is running what distro? Feb 01 10:42:02 wasn't fedora, it's in themailing list. Feb 01 10:42:11 think they said ubu/debian Feb 01 10:42:38 Borromini: I can see the problem here with imx6 target and 4.19 kernel (you need to change to 4.19 manually), but not on 4.14 kernel Feb 01 10:43:43 ynezz: ok i'll check it out Feb 01 10:43:50 karlp: are you using ccache? Feb 01 10:44:16 although if it's Makefile related i assume ccache wouldn't make of a difference Feb 01 10:45:26 karlp: I can't find his distro information in this thread http://lists.infradead.org/pipermail/openwrt-devel/2019-January/015648.html Feb 01 10:47:48 rmilecki, I can only imagine! Feb 01 10:49:00 fwiw, i've noticed my rebuilds (on a 16-core build box) have gone from about 1m20s for a just files-overlay changes and make -j16 to around 2.5+ minutes, recently. Feb 01 10:50:50 russell--: this could be relatively easy to git bisect down Feb 01 10:52:18 Borromini: yes. has always made things faster in the past, I can turn it off and retry Feb 01 10:53:53 jow: ping - think I've stumbled across a subtle luci firewall status display bugette Feb 01 10:58:25 ynezz: in the other thread (they have DMARC problems, so threads ar eall screwed) they say they're on ubu 16.04 Feb 01 11:06:05 Anyone knows if Tobias WaldVogel is still active for OpenWRT? Feb 01 11:06:16 ynezz: got a minute? regarding your patch: https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=b854b0825bb4310cf66254558e358ea86e2097ea Feb 01 11:12:02 ynezz: in ar71xx, phy_stop() is called before ag71xx_hw_disable Feb 01 11:13:05 checking ag71xx_phy_stop shows that first phy_stop() is called, and then the link_adjust part Feb 01 11:13:59 Basically, in your patch, I think the LinkAdjust it adds, should be located between phy_stop() and ag71xx_hw_disable, and not behind ag71xx_hw_disable() Feb 01 11:14:30 Borromini: without ccache is ~same as with ccache after the first build again Feb 01 11:14:30 otherwise the behaviour will be different than in working ar71xx target Feb 01 11:15:27 karlp: ok so ccache is no factor then Feb 01 11:18:50 ynezz: i just have to change KERNEL_PATCHVER= right to switch to 4.19? Feb 01 11:21:09 no difference with "build multiple" and a single selected or just a single selected either Feb 01 11:23:31 * russell-- did a build, mv'd logs to logs_0 and built again. took 2m18s user time, but the logs/*/compile.txt don't show any actual rebuilds, just entering directories running the submake and returning. a few have a non trivial number of lines, but nothing egregiously overkillish seems to be happening. still, times seems longer than i remember. Feb 01 11:26:41 four compile.txt files have more than 100 lines: perl, mac80211, linux and xtables-addons (in order by increasing number) Feb 01 11:29:03 top Feb 01 11:32:22 ynezz: FYI, a clean imx6/4.19 build just works fine here (toolchain from scratch as well) Feb 01 11:44:40 Borromini: thanks! Feb 01 11:45:38 yw Feb 01 11:45:59 xback: I was just scared to touch that somehow working sequence and since it has fixed the problem, I've left it as it is Feb 01 11:50:00 xback: are you experiencing some issues with the patch as it is? Feb 01 11:52:36 xback: from my point of view, the most important part in this patch is that missing `ag->link = 0;` line, not calling ag71xx_link_adjust Feb 01 11:54:44 hm, no, I'm wrong, both parts are important Feb 01 12:04:11 ynezz: I altered the patch based on my review. could you test it? https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=1e50fdbcc2574606821e7d88f8607a9f2073d8d9 Feb 01 12:05:23 xback: sure, but I'll work with ar71xx next week, so it has to wait little bit Feb 01 12:05:46 ynezz: no worries. take your time :) Feb 01 12:05:48 gch981213: ^ could you please test it as well? Feb 01 12:09:15 * russell-- had a weirdness on a netgear wndr3800 (ath79) a few days ago where two devices hanging off the lan ports, where i could only communicate with one device at a time. both ports showed as UP from swconfig. i rebooted, and i could talk the the second one but not the first, i rebooted again and i could talk to both. Feb 01 12:09:44 the two devices were both meraki mr24's Feb 01 12:10:24 the meraki mr24's are running a few-months-old openwrt firmware Feb 01 13:45:18 hello everyone, i have created a custom build for the HLK-RM04 device with 8MB/32MB now i made ser2net integration with luci and that runs fine except that when i use save and apply the service doesn't get reloaded after the changes gets written it looks like that the service gets reloaded before because when i hit the button for a second time it does work. i tried using different hooks like; Feb 01 13:45:22 function s.on_after_commit(self) luci.sys.call("/etc/init.d/ser2net restart >/dev/null 2>&1") end Feb 01 13:45:34 but nothing seems todo the trick Feb 01 13:45:41 anyone got any ideas? Feb 01 13:47:34 also tried function m and map and replaced self with map etc etc Feb 01 14:19:08 Hauke: Hi, I've some quite strange issue with kconfig and imx6 4.19 kernel on Debian Jessie (8.10) host, where I need to add following symbols to generic config http://paste.ubuntu.com/p/N3zdk9mRvr/ Feb 01 14:22:41 Hauke: some of those symbols are already in x86/gemini configs Feb 01 14:34:35 Hauke: it's quite strange kconfig behaviour, since it works in this way only on my debian 8.10 build host, on ubuntu 14.04 and debian 10 (tested by Borromini) it works fine without this symbols Feb 01 14:37:16 Hauke: this is quite above my head, I don't see how the host might influence different kconfig behavior, I've tried to bisect it, but it leads me always to the commit introducing the symbol Feb 01 14:41:21 Hauke: here is build log http://paste.ubuntu.com/p/tpnK6b479z/ of `make V=sc target/linux/{clean,compile}` on that debian 8.10, here is the patch adding missing symbols https://github.com/openwrt/openwrt/pull/1714/commits/596e83d397d97aa63a0330e0b8a71a599ac37669#diff-2b943bd3217ede39dd6b6c44d2e1a327R1272 + fix for kmod-drm Feb 01 14:41:26 https://github.com/openwrt/openwrt/pull/1714/commits/a109f673e23604ca0f1f0f3a6c86c2d8f8d8dc74 Feb 01 14:48:20 ldir: pong Feb 01 14:49:08 ynezz: there's nothing wrong with them, You are simply doing tests properly. Usually when someone tests for changes, they only enable the device in interest, forgetting to build also with all kmods enabled. Feb 01 14:50:18 ynezz: regarding the behaviour difference, did you diff the kconfig sources between the kernels yet? Was there a kconfig update from 4.14 to 4.19? Feb 01 14:50:50 Maybe things like LC_ALL or LC_COLLATE (sort(3)) influence things, or different versions of flex/yacc Feb 01 14:52:27 jow: I don't think flex/yacc is at fault. The imx6 config was not refreshed. Feb 01 14:54:04 tmn505: if you check this http://paste.ubuntu.com/p/zDrv9grDvw/ (Ubuntu 14.04) it builds just fine Feb 01 14:54:25 same openwrt config on debian 8.10 and ubuntu 14.04, same kernel version Feb 01 14:54:26 hm, guess my other er-x-sfp really is dead Feb 01 14:54:46 gets link but nothing at all on the uart Feb 01 14:55:20 no tx on this other one either, hm Feb 01 14:55:29 here is the openwrt config https://paste.ubuntu.com/p/xfGrsxpfnz/ Feb 01 14:55:55 but it's producing different results on different hosts Feb 01 14:56:10 ynezz: I'm not at home this week and I'll test it about 10 days later. Feb 01 14:56:25 gch981213: sure, no problem, thanks! Feb 01 14:58:52 ynezz: can you please compare the locales and the output of env | grep LC_ between the machines? Feb 01 14:59:15 ynezz: could also be that kconfig.pl behaviour differs and not kernel kconfig itself Feb 01 14:59:52 I suggest to intercept the kconfig.pl calls to see if they already produce different results Feb 01 15:00:18 ynezz: indeed, maybe what jow said may be a clue. As I'm building on arch linux, I'll test this this evening. Feb 01 15:01:52 jow: http://paste.ubuntu.com/p/SNbNjfkFys/ locales diff Feb 01 15:02:25 ynezz: that will affect sort() in Perl at least Feb 01 15:02:29 possibly in glibc as well Feb 01 15:05:21 so we should add LC_ALL=C before kconfig.pl calls? Feb 01 15:05:36 try if it makes a diff, if yes then yes Feb 01 15:05:52 or rather $ENV{'LC_ALL'} = 'C'; in the script itself Feb 01 15:10:03 adding it to kconfig.pl didn't helped, I've added it to global env also, but it still builds here Feb 01 15:10:16 now I've same locale on ubuntu and debian boxes Feb 01 15:12:14 OpenWrt build own flex/bison, so it shouldn't use the one from the host Feb 01 15:30:06 jow: I raised https://github.com/openwrt/luci/issues/2495 - some rules missing from the ipv6 firewall status display Feb 01 15:33:24 jow: of course first I should say... well done & thank you for your time & hard work on the 18.06 release. Feb 01 15:35:48 Hauke: jow: tmn505: sorry for the noise, I wasn't using same config on my Ubuntu box :( it fails to build here as well with the same OpenWrt config Feb 01 15:36:44 would be nice if A64 timer fix could be merged before branching new release https://patchwork.ozlabs.org/patch/1031617/ Feb 01 15:39:48 without those patches A64 boards time will jump to the future and that will cause many issues Feb 01 16:23:58 ynezz: ack on the drm issue. now rebuilding with your patch for that Feb 01 16:31:49 nice, thanks! Feb 01 16:32:52 did you also compile-tested 4.14 with the patch applied? Feb 01 16:33:20 the drm patch indeed solves the issue for 4.19 Feb 01 16:34:40 yes, I've finished the build of 4.14 and 4.19 right now Feb 01 16:34:57 ynezz: ill push the drm patch Feb 01 16:35:13 I had @ge4.14 in my first version of the patch which was wrong, now it's @ge4.15 correct Feb 01 16:35:57 ynezz: drm patch pushed to master Feb 01 16:37:06 ynezz: I'm still getting some errors at the final packing part: https://pastebin.com/F9XrviFe will check those on Monday (unless someone beats me to it) Feb 01 16:37:58 hm, I don't see it here Feb 01 16:38:25 maybe related to this Downloading file:///home/kvdp/git/openwrt_staging/staging_dir/packages/imx6/Packages ? Feb 01 16:40:42 ynezz: here is the config: https://pastebin.com/0V5u7BzN Feb 01 16:40:58 it's with all kmods on for all (sub)targets Feb 01 16:42:47 * xback is away for the weekend Feb 01 16:57:03 xback: and with make V=s ? You won't see that problem otherwise **** BEGIN LOGGING AT Fri Feb 01 18:03:54 2019 Feb 01 18:04:05 anyway, I'll submit the patch and I think you'll see what I mean Feb 01 18:05:00 Aktan: yeah, I agree - its probably the safest to not interpret the string at all Feb 01 18:05:24 okay, cool Feb 01 18:09:40 jow: which branch should I be sending the pull request to? Feb 01 18:10:10 master, please Feb 01 18:10:34 okay, sicne I noticed master moved the JS out of display.htm into a static js file.. Feb 01 18:13:09 parsing into a date object and then back into a string will do the "right thing" for the user locale, Feb 01 18:13:39 but the listing is the same param needed to retrieve the data, so there is no need to parse then go back Feb 01 18:14:12 karlp: I think its a reasonable conclusion to not use Date() at all if it can be avoided. There's too many layers of quirks to safely use it Feb 01 18:14:33 or rather there's more way to get it wrong than to get it right Feb 01 18:15:04 Aktan: I can take care of backporting the relevant changes once it hit master Feb 01 18:15:05 the program splits a list of time periods it expects to receive as a param when viewing, but currenting the list of time periods is converted to date obj, then back to a string which is used for viewing Feb 01 18:15:22 I see no point in that when the program already spits the exact string needed for viewing Feb 01 18:16:36 jow: okay thanks, there is one last "bug" I now noticed it's very minor though I didn't look very hard so it might not be minor Feb 01 18:16:51 the attribute date-duration will be wrong for the current capture period Feb 01 18:16:54 (I've not read the issue, but if you have an isoblah timestamp in yyy-mmm-dddThhh:mmm:sss[.ss]style, surely it's perfectyly safe to call Date() on it? Feb 01 18:18:03 as it's using UTC for the first date and then subtracting it from the current time which is not in UTC time. I guess a solution is to make the current time UTC time Feb 01 18:19:13 Aktan: yeah Feb 01 18:19:19 okay, will do Feb 01 18:22:15 karlp: yeah that should be fine, the issue plainly was that there was no need to add complexity in converting a string when the original string is what is expected already Feb 01 18:25:25 again, I've not read the issue, I just presumed that if you're making a string from a "date" in js, you might want the users expectation of that date, not always the iso repor. Feb 01 18:26:41 ah, okay Feb 01 18:28:15 there's no "performance" win of any relevance to try and avoid making the Date object or anything. Feb 01 18:29:30 no, but when input = output then its smpler to avoid splitting, decorting, expaning, interpreting the string or adding/substracting timezone offsets multiplied by magic numeric constants Feb 01 18:29:38 *decorating Feb 01 19:11:40 jow: okay, after taking the time to get a signature, I finally have added the pull request Feb 01 19:47:40 hmm, what variable do I use in a Makefile to specify the dir name a tarball is extraced to ? for some silly package that uses a different name Feb 01 23:11:16 stintel: PKG_BUILD_DIR in case you're still wondering. Feb 02 00:44:05 karlp: https://pastebin.com/raw/hGujZTaE configure and waf are being ran again in my package logs **** ENDING LOGGING AT Sat Feb 02 02:59:56 2019