**** BEGIN LOGGING AT Fri Feb 05 02:59:57 2021 Feb 05 07:28:25 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 92.8% packages reproducible in our current test framework.) Feb 05 10:06:25 nbd: ping Feb 05 10:16:03 rsalvaterra: pong Feb 05 10:17:04 nbd: something's rotten in MT7615's GTK rekeying, for sure. :/ Feb 05 10:18:07 This test works just fine with software rekeying. https://github.com/openwrt/mt76/issues/494#issuecomment-772423778 Feb 05 10:20:11 Pinged the wireless client successfully. Waited for a GTK renegotiation. Purged the ARP entry on the local machine. Pinged the wireless client again, also successfully. Feb 05 10:20:25 can you test if it's specific to wpa3 or wpa2 with 802.11w enabled? Feb 05 10:20:41 i.e. does it happen if you just use plain wpa2 with 802.11w explicitly disabled Feb 05 10:20:45 This is WPA3, so 802.11w is implicitly enabled. Feb 05 10:22:09 It also fails with WPA2, but I'm not sure if the client had 802.11w disabled, since it was optional (sae-mixed on the router). Feb 05 10:22:27 please try disabling 802.11w on the router with wpa2 for testing Feb 05 10:22:38 I'll try with psk2 on the router and explicitly disabling 802.11w. Feb 05 10:27:20 Aw, crap… have to build an unpatched image, of course… Feb 05 11:41:51 rsalvaterra nbd: i think i see the same on MT7915 with traffic coming to a halt upon GTK rekeying Feb 05 11:43:56 I have a WPA2 11w disabled VAP and a SAE 11w enabled VAP and IIRC it only broke on the SAE one. Feb 05 11:44:41 I'll be back at the APs place this weekend so i can verify this Feb 05 11:48:20 blocktrron: Maybe it's 802.11w related, we should also test WPA2 with 802.11w. Feb 05 11:56:05 that might be why I haven't hit it yet Feb 05 11:57:46 I would have hit a ton of rekeying by now if it's at 600 Feb 05 12:39:46 build #645 of ath79/generic is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fgeneric/builds/645 blamelist: John Audia Feb 05 12:41:19 No space left on device ... Feb 05 14:30:27 Namidairo: GTK rekeying is done once a day (86400 seconds) per station, by default, except for TKIP (but nobody should be using TKIP in 2021). Feb 05 16:05:07 nbd, blocktrron, I'm pretty sure it's 802.11w related. Feb 05 16:06:16 WPA2 without 802.11w works, WPA2 with 802.11w and WPA3 don't work. Feb 05 16:45:40 adrianschmutzler: Just wanted to say thanks for merging the MR12 commit. I apologize for being a frequent pain in the ass Feb 05 16:46:22 This will be a huge help for the supportability of our mesh net. We're getting a pile of MR62's soon and I was beginning to work on code to help maintain a patch of the upcoming release. But this saves me a ton of work. Feb 05 16:50:23 have a free photo of an old dude prototyping mounting brackets for a Meraki MR66 https://paste.c-net.org/TimingFallen Feb 05 17:22:27 you're welcome Feb 05 17:22:49 note that I modified the compat message, as for the two-port design network config will be incompatible as well when updated from ar71xx Feb 05 17:23:02 so you need to flash with -n when coming from ar71xx Feb 05 17:23:19 (just pushed it a minute ago) Feb 05 17:24:47 does btrfs allow to have a rw overlay over a ro rootfs? I'm looking for an alternative to overlayfs because of the hassle to manage the upperdir and workdir mounts. Feb 05 17:27:42 anybody knows if there is some openwrt or associated talk at FOSDEM 2021 ? Feb 05 17:28:12 noticed openwifi hardware and some legal talk so far Feb 05 17:36:26 vdl: I would actually ask that in #btrfs Feb 05 17:39:08 adrianschmutzler: Thanks for sussing out that scenario. Feb 05 18:44:06 stintel: thank you Feb 05 19:30:46 blocktrron: any news regarding the GitHub notice? deadline is monday Feb 05 19:36:16 no reply from github yet Feb 05 19:50:18 you tried to contact the guy ? Feb 05 19:53:46 * ldir- doesn't like 240e:f7:4000::/36 Feb 05 19:54:32 whats not to like? Feb 05 19:54:53 36 prefix seems pretty bad-ass to me Feb 05 19:55:18 China Telecom aka Communist Party of China doing slow (3 ish/per second) address/port scan Feb 05 19:55:51 harmless Feb 05 19:56:36 It is since I drop the prefix in & out Feb 05 19:57:19 i got 160 mb worth of ssh brute force a day, dont give a funk Feb 05 20:01:42 I'm domestic user, I don't run any servers etc I don't understand why they're looking/what they're looking for. Feb 05 20:02:41 theyre just ensuring that your shed is secure, nothing to do with .cn Feb 05 20:02:41 Well... scanning whole IPv4 address space isn't that hard thing to do, so also very likely that something akin to that happends Feb 05 20:04:06 i am more annoyed with crawlers ignoring my robots.txt and constantly crawling my git history endlessly Feb 05 20:25:23 i will admit though that port scans on ip6 arent all the common, atleast not on my network Feb 05 20:25:57 but other than that, its just a fact of life and can't be bothered with it (keeps me sharp so in a way to should be thankful) Feb 05 20:31:26 look at it this way, theyre ringing your doorbell to see if youre home Feb 05 20:31:35 alteast someone cares Feb 05 20:48:32 I take a slightly more suspicious slant - they're checking to see which doors are locked on a row of parked cars.... the intent is unclear. Feb 05 20:48:42 but yes that comes from someone who allows anonymous root access to his router ... LOL Feb 05 20:49:27 do I ? Feb 05 20:49:34 i am actually anxiously awaiting someone to log on LOL Feb 05 20:49:39 no i do Feb 05 20:51:27 will they report the unlocked door to the owner, the police, a criminal element, get in and drive off themselves? Feb 05 20:52:00 look they;s dumb fucks scan the network find its open , but they wouldnt know what to do with it Feb 05 20:52:13 even if it gives root access Feb 05 21:01:18 champtar: yes, he also tries to contact GitHub Feb 05 21:07:11 but look i do understand what you mean but if youre confident that you closed all the doors and that any open doors lead to nothing then why would you be worried? are you not confident? Feb 05 21:08:03 port scanning, brute forcing is just a think of modern internet. If you let that get to you then you have an issue Feb 05 21:09:10 blocking a 36 prefix for this is probably not very sustainable strategy Feb 05 21:11:03 point i am trying to make is that in this world you need a level of conidence and trust otherwise it will drive you nust Feb 05 21:11:07 nuts Feb 05 21:12:07 i wont let some lousy script intimidate me Feb 05 21:14:30 so bottom-line for me i like 36 prefixes, i wish i had one Feb 05 21:15:08 blocktrron: could you ask him to make a public comment in the PR explaining the situation so that on monday when a random guy at GitHub review the case they don't suspend / delete the repo because nothing was done Feb 05 21:22:22 they would make a lot of people happy by doing exactly that :p Feb 05 21:24:33 rsalvaterra: ping Feb 05 21:24:48 Borromini: pong Feb 05 21:25:04 rsalvaterra: hi Feb 05 21:25:57 i am still trying to get to the bottom about my MT7613 issue, but I have two MT7615 devices in production here Feb 05 21:26:24 and i realised today that weirdness i've been saying (ping dropping intermittently at some point) is the MT7615 radios Feb 05 21:26:41 Right, check mt76 bug 494. Feb 05 21:26:50 e.g. 5 that go through, 5 that drop, ... Feb 05 21:27:15 https://github.com/openwrt/mt76/issues/494 Feb 05 21:27:56 i just have WPA3 SAE here Feb 05 21:29:18 Borromini: there's a problem with broadcast and 802.11w on MT7615. Hacking the driver to force software GTK rekeying makes it work. Feb 05 21:30:04 it seems here it's not just pings dropping, i can SSH in when the ping responds but the connection just cuts off once the ping dies as well Feb 05 21:30:23 so you think that's similar/the same? Feb 05 21:30:46 sometimes it pops up after a few hours, and this time it took a few days. Feb 05 21:31:57 ok that report has a patch, i might give that a spin Feb 05 21:35:00 Borromini: Yes. It happens after a GTK rekeying. Feb 05 21:35:10 The patch fixes it. Feb 05 21:35:15 ok Feb 05 21:35:24 Well, hacks around it, more precisely. Feb 05 21:35:33 so gtk rekeying happens at random intervals? Feb 05 21:36:16 Once a day (every 86400 seconds), per station, by default. Feb 05 21:39:01 ok. should have checked the uptime before rebooting Feb 05 21:43:37 https://www.youtube.com/watch?v=g5n1zXkB5xw Feb 05 22:27:36 Is DSA already on par with swconfig, featurewise? Feb 05 22:28:47 (I don't mean in LuCI, just UCI.) Feb 05 23:00:52 rsalvaterra: AFAIK no Feb 05 23:01:48 mangix: Still no untagging? Feb 05 23:02:54 I'm trying to bridge (on an Omnia) eth2.100 with lan3 untagged. Feb 05 23:03:05 *eth2.105 Feb 05 23:04:52 No idea about that. Feb 05 23:05:49 Wait, it worked(!!), Feb 05 23:06:12 I'm not touching it anymore. Even afraid to sneeze atm. Feb 05 23:44:02 My device uses -march=octeonplus by default from the repo. If I add a -mtune=octeon3, will I still be able to use the octeonplus ipk repos generated by the build bot, or will it complain about arch types? Feb 05 23:45:55 I know I can't change the -march or it complains and refuses, but not use if I leave the arch and add a tune if it'll still work Feb 06 00:55:02 must just be a luci bug showing me the wrong default then Feb 06 00:56:34 ah yeah there it is https://github.com/openwrt/luci/blob/master/modules/luci-mod-network/htdocs/luci-static/resources/view/network/wireless.js#L1105 Feb 06 02:49:12 hi I'm having some trouble with the latest build and SELinux, the following AVC is what I'm seeing, wondering if anyone could help me out. avc: "avc: denied {  write } for pid=2405 comm="fw3" name="net" dev="proc" ino=2722 scontext=u:r:sys.subj tcontext=u:r:sys.subj tclass=dir permissive=0" Feb 06 02:51:38 it occurs 3 times on boot Feb 06 02:52:03 with different pid's each time same comm"="fw3" Feb 06 02:53:09 im trying to figure out if this is a false positive or something which should actually be blocked. Feb 06 02:58:34 looks like port 80 on lan is blocked, maybe the file which fw3 is trying to write is responsible for opening port 80 **** ENDING LOGGING AT Sat Feb 06 02:59:57 2021