**** BEGIN LOGGING AT Mon Jan 13 02:59:57 2020 Jan 13 06:34:11 ldir-bot, blogic: the ios 13+ issue of not being able to join if 802.11w and/or 802.11r is enabled is still an issue after switching to sae-mixed on 19.07 Jan 13 07:16:43 build #264 of ath25/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath25%2Fgeneric/builds/264 Jan 13 07:53:20 build #263 of octeontx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/octeontx%2Fgeneric/builds/263 Jan 13 08:09:59 DonkeyHotei: perhaps give https://gitlab.com/ynezz/openwrt/commit/73e437d0f5352032785688336444f6af5e5bdc5d.patch a test (no mesh patches applied, but more current hostapd) Jan 13 08:13:35 does that apply to master, or 19.07? Jan 13 08:13:43 build #261 of oxnas/ox820 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/261 Jan 13 08:16:27 DonkeyHotei: I've tested it on master Jan 13 08:16:52 and? Jan 13 08:17:39 DonkeyHotei: works, but I don't have any apple devices ;) Jan 13 08:18:05 that's why i pinged ldir-bot Jan 13 08:33:49 btw, now that 4MB flash devices are considered to be unsupported, should we think about adding a default ssl implementation to the images to make uclient / uhttpd / hostapd etc. ssl-aware? Jan 13 09:03:59 build #259 of at91/sam9x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/259 Jan 13 09:32:10 jow: I'm in favor of this change, but still would like to have some kind of core/basic image (probably the IB based solution discussed earlier?), so luci (everything with ssl) and core (just dhcp/dropbear, no hostapd, no ssl) Jan 13 09:32:54 or core (dhcp, dropbear, no ssl), minimal (hostapd, ssl), luci (everything, ssl) Jan 13 09:34:29 correction: minimal = core + hostapd and ssl Jan 13 10:04:36 build #254 of arc770/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/254 Jan 13 10:14:13 build #248 of pistachio/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/pistachio%2Fgeneric/builds/248 Jan 13 10:35:19 my only bug with ssl in uhttpd is that it self signs which still gives you warnings in browsers. Jan 13 10:36:33 why isn't hostapd in core? Jan 13 10:38:56 core = just the minimum to boot and be able to provision it over ssh Jan 13 10:39:19 you don't need hostapd on a switch Jan 13 10:40:13 karlp: I see no alternative to self signing Jan 13 10:47:35 (short of getting a real cert like "router.openwrt.org" and shipping its private key with every build) Jan 13 10:48:02 but that wouldn't work for multiple devices in the network Jan 13 10:48:11 unless you ship wildcard certs :P Jan 13 11:07:20 yeah, I know, I don't know anything better, and I know that the browsers are moving towards warnings for non-ssl at all. Jan 13 11:07:24 so it's not going to get better Jan 13 11:07:41 but _right now_ a plain http site is "ok" and a self signed site is "warnings ahoy" Jan 13 11:08:25 ynezz: "provision" over ssh, requing opkg to get workign wireless? seems non-ideal IMO. Jan 13 11:09:05 I'd also start with luci / non-luci variants Jan 13 11:09:12 that'll likely satisfy the majority Jan 13 11:09:39 karlp: "bug"... nah... Just that now https is became so.. "mainstream" that all the people want's it, which isn't bad in itself, but in the process there get's lost the core of how or often even wh Jan 13 11:10:11 karlp: I think I now understood your initial statement Jan 13 11:10:24 it bugs me, not a bug in uhttpd. Jan 13 11:10:30 you mean once we ship ssl, users will get the warnings while they don't get them now Jan 13 11:10:34 jow: correct Jan 13 11:10:59 yeah, a valid point. I'd probably start with disabled https redirection by default Jan 13 11:11:11 Also for say SSH-provisioning.. I don't personally feel there shuld be default way to do that, but an site-HW-admin could/should have easy menas to enable such things, like in imagebuilder or whatnot Jan 13 11:11:24 karlp: ah indeed.. tired eyes reading here :) Jan 13 11:11:33 and, even though many of us use openwrt for all sorts of things, for the "this is the web gui of my internal lan admin" https is still not really something I see as being a high priority. Jan 13 11:11:33 but that assumes that browsers are smart enough to not helpfully redirect to https when the cert is invalid Jan 13 11:12:25 jow: well, as soon as browsers start to cry about non-SSL, at that stage it could be just as good move to switch to self-signed ssl per default Jan 13 11:12:36 depending pretty much exactly how briwsers does things Jan 13 11:12:46 so they'll cry either way :) Jan 13 11:13:14 at least that is the scenario they've painted to us, yet to be seen Jan 13 11:13:52 yah, https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/ Jan 13 11:14:30 it's only a grey info right now, but they're planning a timeline for it to be "upgraded" to full blown warnings on http down the road Jan 13 11:15:33 build #236 of at91/sama5 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsama5/builds/236 Jan 13 11:18:49 How about an official IB service, something, that would be part of the infra? Jan 13 11:19:57 PaulFertser: thats on the roadmap somewhere Jan 13 11:20:13 its just a huge task, devops-wise Jan 13 11:20:31 I mean you could ship valid ssl-cert with openwrt, but thing is that you also ship the key with it, so.. yeah... also that for example LE certs are that 3 months max, so always old in this context Jan 13 11:21:51 karlp: when connecting for the first time with SSH you do not mind typing "yes" to store the fingerprint in known hosts. Why using a web browser for exactly the same purpose need to be different? Jan 13 11:22:23 because teh warning isn't the same at all. Jan 13 11:23:06 jow: indeed. With WSL available though, I'd say every "power user" can easily run IB locally. And those who can't are probably shouldn't be configuring network equipment anyway. So the real demand for that might be low. Jan 13 11:24:11 karlp: what's essentially different about it? SSH host keys are not signed by a trusted authority. Same about the default TLS cert in uhttpd. The meaning of the message is the same. The means (manually "trust" it) too. I can't yet see any difference. Jan 13 11:25:41 PaulFertser: SSH has no root ting to trust, SSL has root-certs to trust, in the matter of context.. Also in broad general one can transit the trust to DNS and SSHFP (with DNSSEC being the trust-anchor there) and make SSH-client happily trust those Jan 13 11:25:43 PaulFertser: the wording is completely different, and much more open to saying "yes, sure" on ssh. the brwosers are doing everything to make you say now, including hiding the yes option behind "advanced" and "are you reallllly sure" type dialots Jan 13 11:26:05 Indeed, the UX can certainly be better Jan 13 11:26:35 like "you're visiting $host for the first time, this is ther cert..." Jan 13 11:26:57 that woudl be sane and rational though :) Jan 13 11:27:10 or if existing, "$host presents a different certificate compared to the last time you accessed it. [yeah okay] [oh, sounds bad] [details...]" Jan 13 11:27:13 jow: well.. trust model is still diffirent in HTTPS and SSH Jan 13 11:27:50 can be restricted to rfc1918 / ula space too Jan 13 11:28:15 olmari: I know. But you're connecting to an embedded device that just booted, you can't (and actually shouldn't!) expect its key to be signed by a trusted party. Being "trusted" proves nothing, anybody can build an image embedding such a trusted key. Jan 13 11:28:48 I know, but that still isn't HTTPS trust models fault either :) Jan 13 11:29:35 If you're a web-browser user you've already used to its UI, wording is irrelevant. Self-signed is self-signed no matter if you need to press two or three buttons to approve it... Jan 13 11:29:51 it also does not help that the cert failure dialogs are modelled like http errors Jan 13 11:30:22 And I fully realise the issue, I just don't see easy remedy given current https model (as in to have valid cert per default in openwrt) Jan 13 11:30:25 Web browsers suck for a reason (modern Web is driven by the suckers). No way 'round that, IMHO. Jan 13 11:31:26 People who have no clue shouldn't be configuring network equipment anyway. Jan 13 11:31:31 PaulFertser: actualy, many users _arne't_ used to the ui of self signed certs in web browsers. Jan 13 11:31:46 I mean I know some methods like described, but that wasn't any more secure than no ssl, given https key is public data too in this.. Jan 13 11:31:46 PaulFertser: surely we are meant to be helping people be able to configure their equipment too? Jan 13 11:32:04 karlp: I'd say those are not the OpenWrt target audience. Jan 13 11:33:01 I'd say they could be :) but even so, you still have to go through the hoops every time you go to the ui now. Jan 13 11:33:09 karlp: yes, helping sane people. Helping those who can't read and do not know anything about how TLS is supposed to protect them, no, as that's most often than not just a waste of time. Remember Jan-. Jan 13 11:33:16 just saying it's a pain, there's no solution I can think of. Jan 13 11:33:43 I still heavily suspect jan- was trolling Jan 13 11:33:45 karlp: oh, do you mean the latest web-browsers do not allow to "add a permantent exception", really? Jan 13 11:33:57 I've never seen such an option Jan 13 11:34:05 it's certainly not on the default ui. Jan 13 11:34:29 I know I can probably go into prferences and try and add some exception for some ip or something, but it's definitely not in the ui when you're presented it. Jan 13 11:34:41 It used to be there for ages, did they really remove it? In firefox it's not present if you use a private tab. But in normal tab it's there, at least used to be there. Jan 13 11:34:52 It certainly was easy! Jan 13 11:37:05 if I remember correctly, the UI depends on the TLS error Jan 13 11:37:09 karlp: I have 3 mouse clicks to add a permanent exception. You can check e.g. in non-private tab/window on https://cacert.org Jan 13 11:37:21 for a self-signed cert you can still add an exception Jan 13 11:37:37 zorun: indeed, "bad/old/vuln" TLS can't be added easily Jan 13 11:43:27 In ssh it's 4 keypresses (yes), so about the same :) Jan 13 11:53:36 I still strongly disagree that the ui is "the same" in ssh as for browsers, but ok :) Jan 13 11:55:12 Issue in general with both are that rarely peoples actually checks nor, heavens sake, verify what is offered... depending on context it can be meh or catastrophy Jan 13 11:56:21 for https with just turned up device that isn't on internet yet it's pretty much useless to check anything... with ssh across internet claiming to be server you want.. well... ;( Jan 13 12:05:46 olmari: sysadmins are often paranoid enough Jan 13 12:07:01 karlp: I'm saying "the same" meaning how I think about them. My idea is that many (reasonably experienced) people will agree with the notion. Wording is different of course, and might be misleading. Jan 13 12:14:04 build #242 of ramips/rt3883 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/242 Jan 13 12:18:07 build #229 of layerscape/armv8_64b is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/229 Jan 13 13:35:51 build #240 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7623/builds/240 Jan 13 14:26:07 DonkeyHotei: Unfortunately I no longer have any APs running openwrt. Jan 13 14:26:28 ... Jan 13 14:32:59 DonkeyHotei: It isn't just iOS, my Pixel 3 also refuses to connect if SAE and 802.11r are both enabled. Jan 13 14:33:31 mamarley: previously had 18.06 with no sae, no difference Jan 13 16:47:40 zorun: thanks a lot for help with the bugs! Jan 13 16:48:20 zorun: feel free to close the bug/issue if you think, that it's fixed and just add "Please ask re-open if you're able to reproduce on latest version XY" Jan 13 16:50:06 my experience is, that most of the people simply dont reply back, so the bug would stay in the waiting/open state forever Jan 13 16:53:32 ynezz: I like to give people a chance before closing reports Jan 13 16:54:06 when I make a second pass and a report is in "wiating for reporter" mode and nothing happened, then it can make sense to close Jan 13 16:54:12 build #250 of ramips/rt288x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt288x/builds/250 Jan 13 16:55:31 zorun: that 2nd pass time could be spent on 1st pass on different issues :) Jan 13 16:55:44 just my view Jan 13 17:01:28 ynezz: actually, I just realized I don't have the rights to close bug reports :D Jan 13 17:04:21 I've added you to the Developers group Jan 13 17:06:18 thanks! Jan 13 17:27:15 we're down to 37 bug reports for 19.07: https://bugs.openwrt.org/index.php?do=tasklist&project=2&status%5B0%5D=open&reported%5B%5D=10&order=severity&sort=desc Jan 13 18:26:11 zorun: that's not actually true as some bugs can be reported in Trunk or All and it can affect OpenWrt 19.07 as well. Jan 13 18:32:42 Pepe: true Jan 13 20:51:51 WRT1900ACv1 (mamba) wifi is completely unusable on master branch kernel 4.19 connects to clients but will disconnect then reconnect perpetually Jan 13 20:52:36 thagabe: https://openwrt.org/docs/techref/driver.wlan/mwlwifi look at official support Jan 13 20:53:26 which looks dead BTW Jan 13 21:01:20 yes, it is dead. which is why im turning to the openwrt community. It seems to stem from an update in hostapd or wpad because a few months ago it was not doing this. I wonder what will come of this. As an aside any good routers with the ath10k drivers or is ath9k still the better implementation? Jan 13 21:05:31 such issues are hard to reproduce, so hard to fix Jan 13 21:06:31 ideally you should find out, which commit in the hostapd caused the issue Jan 13 21:07:16 then there's a very good chance, that someone can take a look at it and probably fix it Jan 13 21:07:28 isnt Marvell owned by Freescale now? Jan 13 21:07:34 or NPX Jan 13 21:09:10 thagabe: some people are having similar issues, but I'm not able to reproduce it here https://bugs.openwrt.org/index.php?do=details&task_id=2679 Jan 13 21:39:34 Slimey: marvell bought cavium but sold their wifi division to nxp Jan 13 21:39:49 ah Jan 13 21:40:11 and broadcom has recently sold their wifi division as well Jan 13 21:40:24 to whom Jan 13 21:41:15 cypress Jan 13 21:42:15 but it was not the whole division, and now they're looking to sell the rest of it Jan 13 22:03:13 DonkeyHotei mehe maybe I should have started off with a easier device to port instead of the 2030 ;) Jan 13 22:21:36 Most people don't know what a clusterfuck wifi drivers can be lol **** ENDING LOGGING AT Tue Jan 14 03:00:09 2020