**** BEGIN LOGGING AT Tue May 11 02:59:57 2021
May 11 05:06:33 * enyc meows
May 11 05:07:19 <enyc> hrrm I need to put ttl serial monitoring on 21.02-RC1 or so.....
May 11 05:13:29 <enyc> HHv5a (xrx200 lantiq) definitely falls over in some configs ;-(
May 11 05:19:36 <owrt-snap-builds> Build [#87](https://buildbot.openwrt.org/master/images/#builders/64/builds/87) of `realtek/generic` completed successfully.
May 11 07:28:36 <Grommish> .. I keep getting cycled
May 11 07:28:54 <Grommish> Dunno why, but apologizes for the connect/dump messages
May 11 08:05:21 <dorf_> Grommish_: try increasing your ping timeout value in your client. often helps.
May 11 08:09:21 <Grommish_> dorf_: I'll try that.. Thanks :)
May 11 08:10:07 <dorf_> np!
May 11 09:35:06 <rsalvaterra> Hm.
May 11 09:35:11 <rsalvaterra> I just hit this one: https://bugs.openwrt.org/index.php?do=details&task_id=3790
May 11 09:35:16 <rsalvaterra> Anyone looking at it?
May 11 09:36:48 <zorun> gcc10 and glibc?? looks like a niche combination
May 11 09:39:00 <rsalvaterra> zorun: I'm on musl 1.22.
May 11 09:39:11 <rsalvaterra> So, this isn't strictly a glibc issue.
May 11 09:39:59 * enyc meows
May 11 09:40:18 <enyc> Grommish: hrrm openwrt reboot/'powercycle' ?
May 11 09:40:27 <enyc> Grommish: BT HHv5a seems to do that in some configs ;-(
May 11 09:41:30 <Grommish> enyc: I think it was due to IPv6 being enabled.  I killed wan6 and the issue seems to have stopped
May 11 09:41:54 <Grommish> but I have IPv6 upstream, so I think it was just fighting
May 11 11:21:32 <f00b4r0> xback: bug spotted. Fix incoming :)
May 11 12:00:24 <f00b4r0> xback: fix sent.
May 11 12:12:10 <aparcar[m]> jow: I'd merge this patch https://github.com/openwrt/openwrt/pull/4138 so it can be backported to 21.02 and then update busybox in master branch to remove the lede nslookup patch, fine?
May 11 18:03:06 <silverballz> has anyone tried using nunit instead of nginx for luci?
May 11 18:05:03 <silverballz> i have replaced uhttpd with nginx and everything seems to be working perfectly but im not sure if there are benefits for running a reverse proxy as a http server on a router with not much more than 100mb of memory.
May 11 18:05:36 <silverballz> nunit is an application server much more suited for http than nginx
May 11 18:05:42 <silverballz> probably smaller footprint too
May 11 18:07:26 <silverballz> the only benefits i can think of of using nginx over uhttp is perhaps its theoretically more secure...
May 11 18:29:10 <brentmagma> WARNING: Makefile 'package/feeds/packages/yubico-pam/Makefile' has a dependency on 'curl', which does not exist
May 11 18:29:38 <brentmagma> why curl is not avaiable in the head revision?
May 11 18:32:28 <karlp> how long since you built in that tree?
May 11 18:32:42 <karlp> it moved into packages, whihc may need some cleanup if your tree is old
May 11 19:17:53 <brentmagma> karlp: I was using refs/remotes/origin/openwrt-19.07
May 11 19:18:27 <brentmagma> just switched to the master revision
May 11 19:20:24 <brentmagma> the pabove problem happened during the following command: ./scripts/feeds install -a
May 11 19:20:55 <brentmagma> before
May 11 19:20:59 <brentmagma> make menuconfig
May 11 19:20:59 <brentmagma> make download
May 11 19:20:59 <brentmagma> make -j3
May 11 19:23:16 <zorun> given the changes between 19.07 and master, it's not surprising, you should clean up your tree
May 11 19:23:53 <zorun> at the very least remove tmp/
May 11 19:38:06 <brentmagma> I did run make clean
May 11 19:38:23 <brentmagma> what else should I run?
May 11 19:39:37 <brentmagma> the problem occured after executing ./scripts/feeds install -a, so what is the clean command for feeds?
May 11 19:40:22 <svanheule> brentmagma: if a package moved from core to feeds, you need to force install it again, it won't be installed with -a
May 11 19:45:29 <brentmagma> so I should use -af right?
May 11 19:45:41 <brentmagma> ./scripts/feeds install -af
May 11 19:45:52 <svanheule> or just -f curl
May 11 19:46:42 <svanheule> not sure if -f works without a package (list)
May 11 19:46:51 <brentmagma> WARNING: Not overriding core package 'curl'; use -f to force
May 11 19:47:10 <brentmagma> also prompted this
May 11 19:47:17 <brentmagma> ./scripts/feeds install -a
May 11 19:55:42 <brentmagma> svanheule: -af worked
May 11 20:15:09 <brentmagma> svanheule: another problem, I did not see my hardware support 21.02.0-rc1
May 11 20:15:32 <brentmagma> on the offcial website hardware list
May 11 20:15:55 <brentmagma> is it safe to build and install the master revision?
May 11 20:16:08 <brentmagma> will it brick the device instead?
May 11 20:16:27 <svanheule> brentmagma: if device support is in master, it should have been tested already
May 11 20:17:01 <brentmagma> I was using 18.06
May 11 20:17:20 <brentmagma> and updated some package for WPA3
May 11 20:17:26 <brentmagma> but now working
May 11 20:17:34 <brentmagma> sorry, but not working
May 11 20:17:37 <svanheule> if it's just a really old device, support may have been dropped due to insufficient flash/RAM
May 11 20:17:51 <brentmagma> the ram is big
May 11 20:18:11 <brentmagma> I have 521RAM
May 11 20:18:49 <brentmagma> you should check openwrt.org
May 11 20:19:12 <stintel> tell us what device you have
May 11 20:19:22 <brentmagma> the supported hardware for next stable release 21.02.0-rc1 is only lees than 10 models
May 11 20:19:48 <brentmagma> Lenono Newifi D2
May 11 20:19:53 <brentmagma> Lenovo
May 11 20:20:25 <brentmagma> I saw it in the make menuconfig
May 11 20:20:34 <svanheule> https://openwrt.org/toh/lenovo/newifi_d2
May 11 20:20:57 <svanheule> You should be able to just download 19.07 releases
May 11 20:21:00 <brentmagma> it says 19.07
May 11 20:21:15 <svanheule> and since it's MT7621, it should be in 21.02 as well
May 11 20:21:41 <stintel> https://downloads.openwrt.org/releases/21.02.0-rc1/targets/ramips/mt7621/
May 11 20:21:56 <stintel> d-team_newifi-d2-squashfs-sysupgrade.bin
May 11 20:22:18 <brentmagma> so someone should update the hardware support list page for 21.02
May 11 20:22:19 <stintel> wiki says 19.07 because 19.07 is the last stable release
May 11 20:22:27 <brentmagma> I want weekly snapshot build
May 11 20:22:56 <svanheule> well, then go to the snapshot builds an look for the newifi D2 there?
May 11 20:23:15 <svanheule> but if want WPA3, 21.02 would be a safer bet
May 11 20:23:43 <brentmagma> and with some minor modification as well ;)
May 11 20:24:43 <svanheule> you can also check out the 21.02 branch, and build from there
May 11 20:27:57 <brentmagma> It's building now
May 11 20:28:42 <brentmagma> I see MT7621 and MT7620 most common chipset for budget WIFI router nowadays
May 11 20:29:26 <brentmagma> should both be supported with 21.02
May 11 20:37:24 <stintel> here we go again https://www.fragattacks.com/ https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johannes@sipsolutions.net/
May 11 20:37:29 <Hauke> many new security problems in mac80211 wrere reported: https://www.openwall.com/lists/oss-security/2021/05/11/12
May 11 20:37:39 <Hauke> stintel: ;-)
May 11 20:37:45 <stintel> Hauke: beat you to it :D
May 11 20:41:32 <Hauke> I will wait till they show up in linux stable and then create new mac80211 backport tar files
May 11 20:41:45 <stintel> yeah and then probably roll new 18.06/19.07?
May 11 20:41:46 <Hauke> for ath10k we probably have to backport them manually to ath10k-ct
May 11 20:41:55 <Hauke> 19.07
May 11 20:42:02 <Hauke> it was anyway time for it
May 11 20:42:53 <Hauke> curently only mac80211 ath10k and ath11k are fixed, I would not be supprised to see more drivers with such problems
May 11 20:43:24 <Hauke> it says: "Three of the discovered vulnerabilities are design flaws in the Wi-Fi standard and therefore affect most devices. "
May 11 20:45:43 <Borromini> yes very encouraging
May 11 20:45:48 <Borromini> back to 2007 all the way
May 11 22:47:31 <Nick_Lowe> Hi all
May 11 22:47:32 <Nick_Lowe> https://lore.kernel.org/linux-wireless/20210511180259.159598-1-johannes@sipsolutions.net/
May 11 22:47:52 <Nick_Lowe> There's some 802.11 security issues that have popped up
May 11 22:48:09 <Nick_Lowe> And a great paper here: https://papers.mathyvanhoef.com/usenix2021.pdf
May 11 22:48:46 <Nick_Lowe> ath10k has had some patches which I suspect will need to also make their way to ath10k-ct
May 11 22:54:19 <stintel> Nick_Lowe: already on our radar
May 12 00:46:50 <mangix> Nick_Lowe: joy
May 12 00:47:22 <Nick_Lowe> At least the open source space can turn around fixes quickly
May 12 00:48:01 <Nick_Lowe> There's many companies using Broadcom's eSDK and QCA's QSDK in loads of versions - they all need to get updated
May 12 01:06:46 <mangix> it's interesting that all of these can get fixed in mac80211
May 12 01:07:00 <mangix> instead of fixing each individual driver
May 12 01:09:43 <blocktrr1> iwlwifi required firmware fixes if i understood it correctly
May 12 01:10:15 <Namidairo> which they deployed, quietly...
May 12 01:12:47 <blocktrr1> I'd much rather would've found it nice if they would at least disclosed which products were affected.
May 12 01:13:01 <mangix> blocktrr1: right. I meant softmac drivers
May 12 01:13:23 <mangix> iwlwifi and ath10k are a bit special though...
May 12 01:13:46 <blocktrr1> There were firmware updates for iwlmvm up to the 8xxx series, but none for newer cards
May 12 01:14:14 <blocktrr1> and no mention about iwldvm
May 12 01:14:47 <Namidairo> did they say which version fixed them though
May 12 01:15:09 <pkgadd> 19:56:19 < johill> prior to 9000 series, it's all in mac80211 software
May 12 01:15:38 <blocktrr1> I assume this is the fix from ... last october https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=346057dbe7c7595748e61b8a5b962e5c7316924b
May 12 01:15:39 <mangix> interesting...
May 12 01:16:03 <blocktrr1> Still lacks an explicit statement about iwldvm though
May 12 01:16:41 <blocktrr1> To be fair, these are 7 year old cards, so my expectations about them were low anyway
May 12 01:19:37 <Namidairo> i think most of the actively used intel cards older than the 9000 series in my house are actually dead or broken
May 12 01:19:53 <pkgadd> I won't tell you about my ipw2200 cards then ;)
May 12 01:27:43 <Nick_Lowe> Yes, it's not all fixed in mac80211
May 12 01:28:12 <Nick_Lowe> More will I am sure come out in the woodwork
May 12 01:28:29 <Nick_Lowe> We could really do with an effective 802.11 aware protocol fuzzer too
May 12 01:28:46 <Namidairo> some of the enterprise vendors are already pushing updates
May 12 01:29:11 <Nick_Lowe> https://github.com/vanhoefm/fragattacks - There's tooling to test black box for exposure to the new issues here btw
May 12 01:29:19 <Nick_Lowe> Yes, they are - but that is also fucked up
May 12 01:29:30 <Nick_Lowe> As the disclosure was partial
May 12 01:29:40 <Nick_Lowe> Some large vendors found out today
May 12 01:30:10 <Nick_Lowe> https://www.icasi.org/aggregation-fragmentation-attacks-against-wifi/
May 12 01:30:12 <Nick_Lowe> https://www.icasi.org/our-members/
May 12 01:30:32 <Nick_Lowe> Have any vendors expect those pushed updates?
May 12 01:30:51 <Namidairo> Aruba?
May 12 01:31:42 <Nick_Lowe> The WiFi Alliance apparently also tried to sync this apparently - but the vendor I work for heard nothing
May 12 01:31:48 <Nick_Lowe> So we're on the back foot
May 12 01:32:48 <Nick_Lowe> Anyway, the good news is that we're not likely going to see this practically exploited for a window of time
May 12 01:33:10 <Nick_Lowe> So no need to panic and let's ensure everything that needs to be patched gets patched
May 12 01:33:40 <Nick_Lowe> This really does show up the terrible servicing model for embedded devices and routers though
May 12 01:33:52 <Nick_Lowe> We all need to do better
May 12 01:34:25 <Namidairo> being unauthed and injecting ICMP into a secured network and capturing a response on the other end would be quite the party trick
May 12 01:46:13 <blocktrr1> my personal favorite is this one: https://lore.kernel.org/linux-wireless/20210511200110.11968c725b5c.Idd166365ebea2771c0c0a38c78b5060750f90e17@changeid/
May 12 02:03:28 <Namidairo> isn't this problematic for openwrt since ath79 defaults to the ath10k-ct variant
May 12 02:04:09 <Namidairo> one would have to see how long candela take to release an update?
May 12 02:11:44 <pkgadd> worst case would be switching (back-) to plain ath10k/ QCA firmware, not great, but no dark magic involved eithe
**** ENDING LOGGING AT Wed May 12 02:59:56 2021