**** BEGIN LOGGING AT Tue Dec 24 02:59:57 2019 Dec 24 03:09:10 iputils package still broken :( Dec 24 03:35:44 broken how? Dec 24 03:38:35 nyt: did you do the scripts/feeds install -a -f ? Dec 24 06:21:59 yeah theres still something screwy, it doesnt present config options in make menuconfig, i never got to track it down Dec 24 06:28:33 nyt: it's working here, afaict Dec 24 06:28:40 at least it built Dec 24 06:28:56 iputils-ping_20190709-1_aarch64_cortex-a53.ipk Dec 24 06:30:57 do you have iputils options in your .config? Dec 24 06:31:06 and youre updated to head? Dec 24 06:31:44 WARNING: Makefile 'package/feeds/packages/backuppc/Makefile' has a dependency on 'iputils-ping', which does not exist Dec 24 06:32:31 thats still crying, but i got nothing in menuconfig to select iputils-ping or any of the other options Dec 24 06:36:35 Symbol: PACKAGE_iputils-ping Type : unknown Selected by: PACKAGE_backuppc Dec 24 06:49:16 nyt: what does it say when you do: scripts/feeds install -a -f Dec 24 06:49:49 i'm on e2eb6d5829c71ded0238059a7f2c6ade19c8b171 Dec 24 06:51:29 cries about iputils-ping like i pasted above, and stubby missing ca-certs Dec 24 06:51:30 also Dec 24 06:51:30 Overriding core package 'iputils' with version from packages Dec 24 06:51:53 what the crap Dec 24 06:52:03 it did not do that when i ran it the last few times Dec 24 06:52:29 and now its in menuconfig Dec 24 07:48:07 nyt: expected behavior Dec 24 07:49:11 there is a push to get a bunch of the packages in the main openwrt tree over to the packages feed Dec 24 09:45:21 Hauke: is default built for dir-615-e4 disabled because it can't build just the "factory" image (but sysupgrade is fine)? Dec 24 09:45:53 (I'll send the for-19.07 ath79 patch today, yes) Dec 24 10:36:34 build #66 of ramips/rt305x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt305x/builds/66 Dec 24 11:18:14 PaulFertser: yes the factory image for the dir-615-e4 was failing in the build bots Dec 24 11:18:18 I think sysupgrade works Dec 24 11:18:32 PaulFertser: thanks for sending a patch for 19.07 Dec 24 11:20:44 Hauke: I'm not sure if not being able to build a factory image is the right reason to disable building sysupgrade too but I guess you know better. Dec 24 11:21:25 Still working on the patch. And spotted two tplink devices I managed to miss for the master, not sure how that happened. Dec 24 11:28:10 PaulFertser: if the factory image is failing because it became too large then the chance for the sysupgrade image actually working (= having enough space for the overlay) is likely rather slim Dec 24 11:31:03 KanjiMonster: in the specific case that's a wrong reasoning because I set factory image size to what's expected by the vendor firmware, and the sysupgrade size to what's actually usable on the target (the difference is 3 * 64 KiB). Plus 4K sectors are used, so 20 KiB free is enough for a usable overlay. I wouldn't be surprised if vendor web-interface could accept larger images too, just never Dec 24 11:31:09 tried that. Dec 24 11:42:23 PaulFertser: I am fine with a better solution, but this broke the complete ath79 tiny build: https://buildbot.openwrt.org/master/images/builders/ath79%2Ftiny Dec 24 11:44:17 Hauke: ok, so not really a policy but that's how the build system is currently working. I personally will be self-building in any case so probably that's not important. Dec 24 12:35:29 fyi, someone feel free to take over the smallbuffer review, I'm currently travelling and no idea when I'll find time to look into it Dec 24 12:37:40 ah, nvm, it's already in master Dec 24 16:09:42 Hauke: I plan to work on going through ipq40xx and ipq806x devices this evening. I do not plan to do anything about ar71xx. Dec 24 17:03:53 PaulFertser: thanks Dec 24 17:11:11 Hauke: what to do with three card devices with 256 MiB? Should they default to fast or to safe? :) Dec 24 17:11:47 PaulFertser: I would use the fast version for now Dec 24 17:12:06 and wait till people complain Dec 24 17:12:33 Hauke: in the gluon pull request Sven writes he's able to OOM them but that required active UDP traffic on all three radios. So a bordercase really :) Dec 24 17:13:04 yes Dec 24 17:13:43 Ok, fast it is then. Dec 24 17:14:19 ;-) Dec 24 17:14:30 You'll need to mention the issue in the release notes anyway for the ar71xx users who'd need to manually change kmods. Dec 24 17:59:32 Hauke: found no affected devices in ipq806x Dec 24 18:01:22 PaulFertser: Hauke: thanks btw :) Dec 24 18:01:45 stintel: I wonder if someone has run-time tested it yet :) Dec 24 18:02:31 I did not manage to OOM my device before your changes so I never got to building a new image with your changes Dec 24 18:03:24 well, I saw it OOM earlier, but when I tried to reproduce it last week I couldn't Dec 24 18:05:17 stintel: people were saying doing whatever it takes for luci to initiate "opkg update" was usually enough (with wireless brought up). Dec 24 18:05:41 ah yeah I didn't have luci in my image either so couldn't try that Dec 24 19:30:02 mangix: it was weird since i install -a -f a couple times, and the options were NOT in menuconfig, did it again, and they were Dec 24 20:07:42 build #162 of brcm2708/bcm2711 is complete: Failure [failed kmods] Build details are at http://buildbot.openwrt.org/master/images/builders/brcm2708%2Fbcm2711/builds/162 blamelist: Koen Vandeputte , Hauke Mehrtens , Paul Fertser , ?lvaro Fern?ndez Rojas Dec 24 20:36:50 I see there were kernel bumps in master branch, but they are not included in 19.07 nor 18.06 can someone cherry-pick them together with Wireguard update from master branch to 19.07? Dec 24 21:30:42 Is there a possibility to relay dhcp option 43 information which got sent through dhcp, served by the dhcp server? Dec 24 21:31:21 So the router gets it from the isp, but is supposed to send it to iptv boxes Dec 24 21:32:20 I wiresharked the info, and put it in the dhcp option at the server. Dec 24 21:32:41 But it may change, and it should send recognise new info when it comes. Dec 24 21:33:47 It contains info such as where to get info from. Dec 24 21:35:51 http://community.cambiumnetworks.com/t5/ePMP-3000-2000-and-1000/DHCP-Relay-DHCP-option-43-and-66/td-p/34275 Dec 24 21:41:25 jmv200: OpenWrt is using udhcpc by default to get addresses from upstream IPv4 routers Dec 24 21:41:40 jmv200: you can configure it to request those options by using reqopts uci parameter. Dec 24 21:42:11 jmv200: and then you can edit /lib/netifd/dhcp.script to extract and set those options with "uci" for dnsmasq to relay. Dec 24 21:43:18 Is this appropriate discussion for this channel? Dec 24 21:55:26 jmv200: actually, edit /etc/udhcpc.user , not the generic script. Dec 24 22:42:12 BAH. WPA3 doesn't work right on my redmi note 7 Dec 24 22:44:09 any way to see if a client is connected through WPA3? Dec 24 22:54:23 I fear the easiest test is making your AP WPA3-only for a while Dec 24 22:54:34 I can see if the STA is using 802.11w Dec 24 22:54:53 but I don't really see anything about its SAE capability Dec 24 22:55:16 # hostapd_cli -i wlan1 all_sta | grep flags Dec 24 22:55:16 flags=[AUTH][ASSOC][AUTHORIZED][SHORT_PREAMBLE][WMM][MFP] Dec 24 23:42:16 * mangix just realized his router's running out of memory Dec 24 23:42:23 32MB is quite little Dec 25 00:31:28 yep, it's quite hard to keep make them do something useful with 4/32 or 8/32, fortunately I don't have to - and can just try to keep them running current master without having to rely on their performance Dec 25 00:38:17 yeah this doesn't even sysupgrade correctly Dec 25 00:38:29 i just flash firmware through the bootloader Dec 25 00:38:49 yep, same problem on my tl-wr1043nd v1 Dec 25 00:39:00 ah, same router :) Dec 25 00:39:17 it helps a lot to rm /etc/modules.d/* && reboot and stop as many services before running the sysupgrade as possible Dec 25 00:39:45 ...who needs wireless, ppp, and friends for the sysupgrade ;) Dec 25 00:40:02 of course :) Dec 25 00:40:49 4/32 is easier in that regard, less temptation to include optional stuff, less RAM usage Dec 25 00:42:33 I guess the only choice is 18.06 for these routers Dec 25 00:43:11 given that you're building the images yourself, not really - but you have to really trim it down Dec 25 00:43:46 uhttpd/ lua is a killer though Dec 25 00:43:51 sure, but newer kernels seems to have higher memory usage. There's also the issue of OpenSSL Dec 25 00:44:05 OpenSSL 1.1 is huge compared to 1.0.2 Dec 25 00:44:15 around 1 MB, yes Dec 25 00:44:15 I think runtime as well Dec 25 00:45:10 it pays off that I've switched from strongswan to wireguard (not because of size reasons, but because of IPv6 compatibility (for the android app)) Dec 25 00:45:30 I assume you also mean speed :) Dec 25 00:45:51 I hope you don't have a tl-wr941nd v2/ v3 in your collection, that one will break with kernel 4.19 https://bugs.openwrt.org/index.php?do=details&task_id=2524 Dec 25 00:46:02 speed isn't that much of a concern to me Dec 25 00:46:27 even the tl-wr1043nd v1 was surprisingly fast with strongswan Dec 25 00:46:56 ...but in practice I'm using my nbg6817/ ipq8065 for that - and that one is fast enough(TM) Dec 25 00:48:15 well, let's see how it'll behave when I switch to ftth/ 400/200 MBit/s - but even then my LTE uplink is limited to around 50 MBit/s Dec 25 00:49:00 I'll be looking at something new too, soon. upgrading my ftth from 200/120 to 1000/1000 Dec 25 00:49:26 ipq8074 is a nice SOC Dec 25 00:50:39 actually the MACCHIATObin caught my interest, as it's available with 2x 10gbe SFP+ slots, and I'm upgrading my network to 10gbe too Dec 25 00:50:57 but it seems hard to find in Europe Dec 25 00:51:01 (yes, it'll need some work - but according to blogıc it reaches routing at 1 GBit/s linespeed without NSS/ NPU support, just running hotter than by taking advantage of it; the SOC is usually paired with at least one 2.5/ 5 GBit/s aquantia ethernet chip) Dec 25 00:52:13 https://compex.com.sg/hk01-qualcomm-first-802-11ax-dbdc-solution/ a 'bit' over my pain threshold, but it's nice Dec 25 00:52:22 stintel: I've had this in my tree for a while: https://github.com/openwrt/packages/pull/10871 Dec 25 00:54:06 pkgadd: it'll need some work is an understatement :) Dec 25 00:55:02 yeah, but it has lots of potential (and performance under the hood) Dec 25 00:56:41 two notes on that: someone's gonna need to do the work. And according to blogic, QCA = Qualcomm Crack Addicts :) Dec 25 00:57:57 there's no denying either of those Dec 25 00:59:13 The Marvell stuff has really good support upstream. Kernel 5.5 even introduces XDP support :) Dec 25 01:00:06 ..and qcn5024 is faster than 1 GBit/s ethernet now (with ath11k going into v5.6). Dec 25 01:00:25 s/qcn5024/qcn5054/ Dec 25 01:01:38 good times ahead :) Dec 25 01:01:43 nn folks Dec 25 01:02:26 my problem with marvell is the wireless side Dec 25 01:02:45 if I just wanted a fast router, I'd simply go the path of least resistance --> x86_64 Dec 25 01:08:44 but I'm rather hopeful that ipq8065 will (just) do the job for 400/200, giving me some time Dec 25 01:10:05 well, a dedicated AP is always best Dec 25 01:11:07 yes (and I have that, if necessary), but I'll still try Dec 25 01:12:49 somehow I still like the perception of having 'internet access' sorted in a single box Dec 25 01:13:19 the wireless side on marvell is indeed a disaster Dec 25 01:14:05 the crappy way to fix it is to use a USB wireless adapter. Dec 25 01:14:08 sadly yes (I still have wrt1900ac v2 and upwards kind of my to-loo-for list, if I'll find it cheap enough) Dec 25 01:14:25 I remember the WRT1900ACv1 has actual minipcie slots Dec 25 01:14:33 for the wifi Dec 25 01:14:58 no idea if anyone had tried replacing those Dec 25 01:15:06 I've made bead experiences with USB wireless cards and AP mode/ 24/7 operations (including carl9170 and ath9k_htc), not really going down that road Dec 25 01:19:47 pkgadd: there's also mt7612u Dec 25 01:20:32 I haven't tried that yet, but intel ax200 isn't too bad (firmware is a bit crashy); obviously not for AP mode Dec 25 01:28:32 that's surprising Dec 25 01:30:15 * mangix remembers reporting an important bug in iwlwifi Dec 25 01:30:33 the intel money fixed it **** ENDING LOGGING AT Wed Dec 25 03:00:03 2019