**** BEGIN LOGGING AT Wed Aug 14 02:59:56 2019 Aug 14 03:51:44 the failure rate is pretty much what i saw before, near 25% Aug 14 04:55:44 jow: Acked-by, sure Aug 14 04:58:42 aparcar[m]: https://github.com/openwrt/packages/pull/9659/files#r313611461 Aug 14 05:00:57 blogic: hi, can you pastebin that target/linux/mediatek/ bootlog (from any device) for me, please? Aug 14 05:03:59 hexa-: karlp: if you're switching between master and 19.07, you need to be careful about Python version used, master needs python3 whereas 19.07 python2 Aug 14 05:06:18 hexa-: karlp: workaround is to run `rm staging_dir/host/.prereq-build; rm staging_dir/host/bin/python*` after the switch Aug 14 05:09:20 hexa-: karlp: proper fix would probably mean adding CleanupPython3 to include/prereq.mk and forcing run of prereq python2/3 checks before every build Aug 14 06:12:37 aparcar[m]: ongoing discussion as you can imagine Aug 14 06:13:04 aparcar[m]: i hope to be able to give an update this week Aug 14 06:44:39 nbd: hi, if you can have a quick look at https://patchwork.ozlabs.org/patch/1145995/ and ack/nack that would be great Aug 14 07:03:44 champtar: i c&p'ed it into his jabber Aug 14 07:08:02 is there a hotplug event i can trigger on when eth0 comes up? i dropped a debugging script into /etc/hotplug.d/iface and /etc/hotplug.d/net and didn't see it trigger on DEVICE=eth0 Aug 14 07:09:17 rmilecki: net/ Aug 14 07:09:27 iface is for the /e/c/network interfaces Aug 14 07:09:39 rmilecki: net/ gives you ADD/REMOVE Aug 14 07:09:49 russell--: ahhh up events, no they dont exist Aug 14 07:10:05 russell--: you could use ustatusd, that will fire on carrier up/down events Aug 14 07:10:34 but that is ubus notifications and not hotplug Aug 14 07:12:18 ubus monitor shows nothing when i down/up the interface Aug 14 07:15:45 i'm looking for a robust bandaid for my https://bugs.openwrt.org/index.php?do=details&task_id=296 problem, want to check /sys/class/net/eth0/speed and retry until i'm golden Aug 14 07:31:50 lynxis: hi, can you please take a look at https://github.com/openwrt/openwrt/pull/2218#issuecomment-520914407 (access to the testing GitLab instance) ? Aug 14 07:53:26 jow: https://github.com/openwrt/packages/pull/9721 Aug 14 08:31:19 hmm, i wonder if this is related: in arch/mips/ath79/dev-eth.c, void __init ath79_register_eth(unsigned int id), and case ATH79_SOC_AR7240: pdata->set_speed = ath79_set_speed_dummy; Aug 14 08:37:49 russell--: Nope. set_speed is used to configure external MII interface, and ar7240 doesn't have one at all. Aug 14 08:44:54 yeah, that makes sense Aug 14 08:47:01 i'm looking in here now: __ag71xx_link_adjust() Aug 14 09:25:28 ynezz: eh, it will sort itself out, only matters for a few reusing build trees, works fine in a clean checkout, just a little fiddly. Aug 14 09:25:55 but thanks for the workaround, I had only tried rmp tmp, and "make prereq" Aug 14 09:29:01 russell--: The issue is also scheduled here to check Aug 14 09:29:20 russell--: what I dont see in Link adjust at first glance is the PLL alteration Aug 14 09:30:11 russell--: I have a gl.mifi device here, which has 2 ethernet ports Aug 14 09:30:41 when connecting it to a switch, eth1 report 1Gbit link in dmesg, while the remote switch connected to it shows 100Mbit link rate Aug 14 09:31:37 russell--: so running through link_adjust shows that the speed is set to 1000Mbit and the message is printed accordingly, but I guess it;s not altering the PLL speed to cope for 1Gbit Aug 14 10:06:10 ooh, i found a kludge. i can add an interface in /etc/config/network for eth0 with proto none and i get hotplug events Aug 14 13:22:03 nbd, Hauke: please see https://bugs.openwrt.org/index.php?do=details&task_id=2428 Aug 14 13:34:30 Hi blogic Aug 14 13:34:46 was wondering if you have any information on the first kernel panic posted in this thread https://forum.openwrt.org/t/regular-reboots-on-xiaomi-mi-router-3g/24028/3? Aug 14 13:35:28 I've just expierenced it myself. I noticed that you are the author of mtk_eth_soc.c which contains the implementation of fe_poll which eventually calls skb_panic Aug 14 13:58:31 karlp: why don't you try to upstream this fix https://github.com/etactica/openwrt/commit/7152087e9c1eef7490e4d8afa3b417e5f6e74f1b ? Aug 14 14:02:15 given how well it's been received here, I've got even less interest in trying upstream. Aug 14 14:02:59 when I asked for at least confirmaton that working around it is legitimate I've just had radio silence. any answer I ever get is, "it's your bootloader" which ignores the issue completely. Aug 14 14:03:48 Neighbor11111111: it means that the frame never left the mac Aug 14 14:04:06 if I was super bored I'd implement the pre-tiemout governor support for the ath79 watchdog, so that it just becomes "user configurable" and avoids ever having to convince anyone of anything, but that's a lot of work. Aug 14 14:04:23 and well beyond what I can devote work time to Aug 14 14:04:29 Neighbor11111111: the driver will be updated to the upstream one i believe Aug 14 14:05:22 thanks for your contribution and helping blogic. I've only just started looking at this issue. Is this happening in RX or TX direction? Aug 14 14:05:30 this is TX Aug 14 14:06:03 Ok great. I'll look further but after a quick search skb_put only appeared to be called in fe_poll_rx. Aug 14 14:06:36 What do you mean by the driver will be updated to the upstream one? I ask becausse I thought this driver is already upstreamed Aug 14 14:07:24 karlp: I could imagine that upstream is less strict about it. On other targets its acceptable to work around firmware/bootloader/biods bugs as well Aug 14 14:08:05 personally I'd have no objections either as it does not change behaviour Aug 14 14:09:27 the "not changing behaviour" is why I never understood the objections to it :) Aug 14 14:09:59 It gladdens me to hear warmer feelings to it though :) Aug 14 14:11:30 what is the worst possible outcome? That panic() somehow has a worse reset success rate than the chip reset interrupt? Aug 14 14:12:19 user can shoot themselves in the foot and disable reboot on panic I guess, not taht I really care about those people. Aug 14 14:15:12 one compromise I could envision is to somehow add reset-using-panic behaviour as dts-property where it can be enabled on a board by board basis Aug 14 14:15:52 maybe it would help to ask the Gluon people here, they have lots of ar71xx devices in the wild Aug 14 14:15:57 that's what the pretimeout governor support would be best for, Aug 14 14:16:06 you can choose to have panic as one of the pretimeout options. Aug 14 14:16:25 so you still get the orirginal watchdog if the pretimeout panic didn't get a reboot in time. Aug 14 14:18:45 if it's good enough for upstream, I've no problem to accept the backport Aug 14 14:19:49 * karlp laughs Aug 14 14:20:31 me neither Aug 14 14:20:38 sorry to bother, are you still there blogic? Aug 14 14:21:00 I think, that I'm quite consistent with "upstream first or forget about it" Aug 14 14:21:25 karlp: seems the onyl one having real objections was pepe2k, the rest either didn't care or wants to defer the decision to upstream Aug 14 14:21:40 well, when I first submitted it, openwrt was the defacto upstream. that's changed now. Aug 14 14:21:50 I know Aug 14 14:22:46 well, I've re-opened my internal ticket on this, will see when it comes up on the work list again, thanks for the encouragement. Aug 14 14:25:16 good, thanks Aug 14 14:34:02 karlp: BTW what is RME? :) Aug 14 14:34:30 as in the commit subject prefix Aug 14 14:35:04 acronym of the old company name. Aug 14 14:35:43 just a tag I use to keep track of commits that aren't upstream, either yet, or because they're not appropriate. Aug 14 14:36:14 happily, the stack is only one commit deep for both 1907 and 1806 :) everything else is just package cruft Aug 14 16:42:06 Hello! I'm trying to somehow implement Mikrotik IE. It carries some additional information like radio name and it's needed in some scenarios with Mikrotik devices. However I don't know the linux wireless stack at all. What's the correct place for this? mac80211 or the driver itself (ath5k, ath9k). UBNT has a patch for madwifi here: https://github.c Aug 14 16:42:06 om/jhairtt/ubnt-hal-0.7.379/blob/master/patches/madwifi-dfs-r3319-20080201/074-mtik-ie.patch) Aug 14 17:18:51 ynezz: ping Aug 14 17:20:37 can you activate your gitlab worker again? Aug 14 17:20:58 blogic: thanks for the update. I'm still working on gitlab stuff, would be cool to have a runner doing work for us Aug 14 17:21:07 blogic: regarding the server sponsoring Aug 14 18:59:01 Pepin95: do you want to parse that IE on the receiver side or emit it on the AP side? Aug 14 19:02:56 jow: on the client in this case but that doesn't really matter, does it? Aug 14 19:08:53 latest ath10k-ct driver is pushed to github, commit: 9e5ab25 Aug 14 19:09:17 it may fix MTU > 1500 issue, as well as DFS on 160 and 80+80 setups Aug 14 19:09:40 Pepin95: it does matter Aug 14 19:09:42 new FW coming shortly, though FW changes are not related to the bugs the driver fixes Aug 14 19:09:59 I'll give it a shot, but jumboframes on WiFi? I didn't even know that was a thing. Aug 14 19:10:34 more like MTU of 1560 to better handle encrypted tunnels I think Aug 14 19:10:41 Pepin95: on the client side you should be able to get access to the IE with "iw dev wlan0 scan" Aug 14 19:10:44 Ah, that makes sense. Aug 14 19:11:35 speaking of microtik, they made a pcie -> 4x-mini-pcie board, but it us EOL. Anyone know a good substitute, or know if Microtik might do a small MOQ order for such a thing? Aug 14 19:15:36 Pepin95: if you want to *send* this proprietary IE from OpenWrt, you need to patch hostapd, or use the OpenWrt hostapd ubus support (ubus call hostapd.wlan0 set_vendor_elements '{ "vendor_elements": "XXXXXX" }' Aug 14 19:15:56 Pepin95: ... where "XXXXXX" is the hexadecimal encoded IE data Aug 14 19:18:00 Pepin95: for details refer to https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/hostapd/src/src/ap/ubus.c#l459 Aug 14 19:19:38 @jow thanks! I don't really understand it though. Why does UBNT patch madwifi instead? Aug 14 19:20:20 because madwifi is a legacy, seme proprietary driver codebase Aug 14 19:20:22 *semi Aug 14 19:20:50 and vendors love to implement hideous hacks Aug 14 19:21:43 ubnt decided to hack the facility directly in the low level driver code (because they only have to support this single driver) Aug 14 19:22:08 openwrt opeted for a more generic solution on top of the hostapd daemon which usually drives linux mac80211 based drivers in ap mode Aug 14 19:24:18 @jow that would maybe work in AP mode, but I need this functionality in client mode. Aug 14 19:24:27 that does not make sense at all Aug 14 19:24:33 a client does not send beacons Aug 14 19:24:46 yeah Aug 14 19:24:50 its not just beacons Aug 14 19:25:48 that patch you linked just adds a proprietary information element to the becons sent Aug 14 19:28:38 greearb_: The driver part compiles cleanly on OpenWRT (after dropping an upstreamed patch), but I'm going to wait to flash it until the FW is available too. Aug 14 19:29:08 look: by setting addmtikie via ioctl on a UBNT client sends this proprietary IE Aug 14 19:29:38 the client needs to send this ie for a wds link between openwrt client and mikrotik ap to work Aug 14 19:34:21 looks like UBNT relied on madwifi for this Aug 14 19:34:54 their airos 8 (for ac, thus doesnt use madwifi) afaik doesn't have this proprietary mikrotik ie Aug 14 19:35:14 I still fail to see how a client can send a beacon Aug 14 19:35:36 maybe you mean its sent as part of a probe request Aug 14 19:39:47 in this case you probably need to patch either wpa_supplicant or the driver itself. Not sure if wpa_supp is able to add IEs to probe requests Aug 14 19:40:14 that is done by mac80211 Aug 14 19:42:43 @blogic any suggestion where to start? Aug 14 19:45:50 Pepin95: you will need to patch mac80211 Aug 14 19:46:03 if you dont know how, go to the forum and see if anyone will do it for you Aug 14 19:46:31 @blogic fully aware of that Aug 14 19:47:35 ugh, don't want someone to do it for me, was just curious what are the parts I should look into Aug 14 19:48:16 jow please have a look at this https://github.com/openwrt/openwrt/pull/2326 Aug 14 19:49:33 Pepin95: net/mac80211/util.c:struct sk_buff *ieee80211_build_probe_req(struct ieee80211_sub_if_data *sdata, Aug 14 19:55:37 @blogic thanks! I'll stop annoying you now, thanks for your time! Aug 14 20:11:42 aparcar[m]: oh, it's not running? Aug 14 20:18:18 ynezz: not anymore! And I'd require it to support docker of possible Aug 14 20:23:46 ok, should be back online Aug 14 20:31:27 aparcar[m]: there is `executor = "docker"` in the config.toml Aug 14 20:33:40 mamarley, I posted the new FW csums and such to the openwrt mailing list just now... Aug 14 20:33:51 Saw it, thanks! Aug 14 20:46:31 ynezz: and it requires privileged mode or mount the docker socket to it do it can start docker containers itself Aug 14 20:51:27 ynezz: please see here https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-workflow-with-docker-executor Aug 14 20:52:18 uhm, aparcar[m] I am getting failed circleci stuff on each commit in luci now, did you set something up there? Aug 14 21:12:57 aparcar[m]: it has `-v /var/run/docker.sock:/var/run/docker.sock` since day one Aug 14 21:24:54 aparcar[m]: anyway, I'm wondering if this can be avoided, why is it needed ? Aug 14 21:25:38 can't just one create a malicious PR and use this to escape from container? Aug 14 21:33:55 ynezz: to build openwrt/docker.git Aug 14 21:35:44 ok, so this can have something like dedicated runner with privileged mode Aug 14 21:42:57 jow: I activated it for testing not thinking it runs as well if no circleci is present (like in master) however I'll turn it off again once home again. Sorry for the extra spam. Aug 14 21:42:57 Generally I'd be in favor to run style and compile checks for luci.git as well. Aug 14 21:42:58 Also gitlab/circleci stores artifacts for instant testing Aug 14 21:50:01 it quite surprises me, why this rush? I've thought, that it was discussed several times already, that until the voting/decission about the forward path is made, it would be better to avoid this tighter integration with this proprietary platforms Aug 14 21:55:28 as I've touched .circleci stuff in the packages recently, I'm wondering about this copy&pasta .circleci dissease as well, I hope that it can be handled better Aug 14 22:18:20 aparcar[m]: where is openwrt/docker.git located and what is the purpose of it? if you're just trying to build a docker image there are other tools that can do that without requiring privileged mode to be enabled on the runners. Aug 14 22:19:02 https://github.com/openwrt/docker Aug 14 22:19:22 whoops. I checked git.openwrt.org :_) Aug 14 22:20:27 fragmented fragmentation, you know :) Aug 14 22:20:39 ok. I'll try to dig through this in the coming days, and if not before then I'll hack on it at CCCamp. Aug 14 22:33:45 agb (@freenode_agb:matrix.org): sounds good, I'll look into that. Generally for testing created docker containers I though dind is a requirement Aug 14 22:34:58 ynezz: yes right I'll deactivate it Aug 14 22:35:52 agb (@freenode_agb:matrix.org): https://github.com/openwrt/docker Aug 14 22:42:47 agb (@freenode_agb:matrix.org): thanks, please update me Aug 14 23:20:53 that's some nasty nick completion :) **** ENDING LOGGING AT Thu Aug 15 02:59:58 2019