**** BEGIN LOGGING AT Tue Nov 03 03:00:33 2020 Nov 03 06:11:28 any news on vht over 2.4GHz? Nov 03 06:11:34 will it be accepted? Nov 03 09:13:13 anyone who can help me? building an image based on kernel 5.9 and under /build_dir/hostpkg i have libubox that pops out an error, missing a helper file that is included in /build_dir/hostpkg/json Nov 03 09:14:04 the file requesting the helper is located under /build_dir/hostpkg/libubox and states #include Nov 03 09:14:25 what the correct syntax to point to the correct location? Nov 03 09:23:24 nevermind, figured it out :) Nov 03 10:39:50 alix have bios at 38400 baud, but grub is defaulting to 115200 Nov 03 10:41:19 ab20c638b6c6a204482a721eead6f3f1b33288c5 Nov 03 11:04:50 Guys, how about we disable scp from dropbear by default? :) Nov 03 11:04:58 * rsalvaterra runs Nov 03 11:06:13 I mean, we can already use ssh for file transfer… Nov 03 11:07:19 whut? Nov 03 11:08:28 ssh root@192.168.1.1 "cat > /tmp/target.bin" < source.bin Nov 03 11:08:37 For example. Nov 03 11:09:39 I just added this to the wiki. :) Nov 03 11:15:06 rsalvaterra: why? Nov 03 11:15:12 that is so horrible Nov 03 11:15:37 damex: It's not horrible. It's UNIX. And it works, of course. Nov 03 11:15:49 rsalvaterra: if something works - does not mean it should be used Nov 03 11:16:14 like cat+grep+sed in place of awk. Nov 03 11:17:05 That's an apples to oranges comparison. ;) Nov 03 11:20:15 please seek medical attention immediately Nov 03 11:21:44 LOL Nov 03 11:23:32 Ok, I guess that's a "no". :P Nov 03 11:37:31 very much so... Nov 03 11:37:44 build your own custom if you want to go crazy Nov 03 11:41:42 In any case, I believe it's a good idea to at least have this file transfer possibility documented in the wiki. Do you agree? Nov 03 11:42:34 damex: if there's sed there shouldn't be any need for grep. Nov 03 12:41:37 rsalvaterra: maybe add a comment about comparing sizes and checksums when using such methods... Nov 03 13:04:50 dangole: Oh, yeah, I noticed absolutely no reference to checksum comparison in the wiki too. Nov 03 13:08:16 Wait, it's mentioned, after all. Nov 03 13:13:13 But if someone's yoloflashing without comparing hashes, I guess the file transfer is the least of his problems. Nov 03 13:46:53 anyone familiar with the rtl83xx u-boot? I've DGS-1210-28-F1 (RTL8382M_8218B_INTPHY_8218B_8214FC_DEMO) with U-Boot 2011.12.(2.1.5.67086)-Candidate1 (Oct 20 2017 - 15:38:59) and having issue with UART TX, tried 3 different UART converters but still not able to type in the u-boot prompt Nov 03 13:47:36 I'm able to stop the execution with the Esc key during 'Hit Esc key to stop autoboot: 0', but then nothing more Nov 03 13:47:54 is it somehow locked? couldn't find any mention about it anywhere Nov 03 13:50:57 it doesn't stop on any other key, so I assume, that the wiring is correct Nov 03 13:51:32 ynezz: yes Nov 03 13:51:37 esc to interrupt boot Nov 03 13:51:42 then ctrl-c Nov 03 13:52:06 ooh, victory! Nov 03 13:52:08 thanks! Nov 03 13:54:27 1 sec Nov 03 13:54:39 owrt=tftpboot 0x8f000000 dlink10; bootm Nov 03 13:54:49 use that ram addr for an initramfs boot Nov 03 13:57:15 is it time to by realtek stock as the entire openwrt community will now buy rtl-based switches? :P Nov 03 14:01:41 Heh… I'd really like to my TL-SG2008 v1 how to OpenWrt, as it's running VxWorks… Nov 03 14:02:22 *to teach Nov 03 14:03:13 … but I haven't got the equipment for it it yet (programmer and SOP8 clamp). Nov 03 14:05:03 rsalvaterra: raspberrypi can be used as an SPI flash programmer without additional tools. Nov 03 14:10:20 Oh, really? I have a RPi B+ somewhere. Nov 03 14:12:47 stintel: hehe Nov 03 14:19:24 rsalvaterra: sure, there's a page on flashrom wiki. You can connect it directly to the target chip provided Vcc is 3.3 V. Nov 03 14:20:16 It's been a while, I need to measure again, but I'm almost sure it's 3.3 V. Nov 03 14:20:27 But you'll have to solder some wires if you have no clamp. And probably somehow take care for the SoC to not influence the communication, is there a reset pin you can pull low? Nov 03 14:21:05 haha I made that mistake of hooking up a 3.3V programmer to a SPI NOR flash chip without verifying its voltage first Nov 03 14:21:07 *poof* Nov 03 14:21:47 now I have an Odroid XU4 with 1.8V SPI for those Nov 03 14:22:06 stintel: Me too, a looong time ago… trying to turn a Sound Blaster Live! Value into a Live! Gold. :P Nov 03 14:22:14 ehehehe Nov 03 14:22:18 sounds long time ago indeed Nov 03 14:22:56 Yeah, almost 20 years ago. Nov 03 15:12:28 how come there is just adrianschmutzler reviewing PR/MR on github? should i just dump it as patches and send to maillist to get merged or what? Nov 03 15:12:57 feels bad that there is no adjustments left, changes work great and yet, no one can merge it Nov 03 16:44:17 wpad-full brings in wpa_supplicant which takes 2.3MB memory for nothing, what /etc/init.d/wpad starts wpa_supplicant by default. Nov 03 16:44:28 s/what/why/ Nov 03 16:45:04 maybe it should be off by default and run it when I need openwrt to act as a wifi client? Nov 03 16:54:02 Yes, I've noticed both hostapd and wpa_supplicant always run when wpad is used. Nov 03 16:54:27 I think that's wrong. A quick workaround is to just delete the symlink that you do not need. Nov 03 16:54:40 You can't. Nov 03 16:54:51 They're started by the same script. Nov 03 16:55:22 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/hostapd/files/wpad.init;h=3198e9801f0df3dd43d1b8591f30cf8ce2664380;hb=HEAD Nov 03 16:55:46 Yes, they shouldn't be both started if some of them is not needed. Nov 03 16:56:02 Yeah, this is a bit weird. Yes, it's a multicall binary, but they're still independent daemons… Nov 03 17:00:29 So, wpa_supplicant should only be started if there's at least one STA iface. Likewise, hostapd should only be started if there's at least an AP iface. Nov 03 17:00:34 Yes Nov 03 17:14:27 I also noticed eap_server is only enabled for WPS mode in hostapd, which is odd, eap_server should be a toggle flag in /etc/config/wireless in my opinion Nov 03 17:19:41 rr123: I gather you need wpa_supplicant on your router, just not all the time, right? Nov 03 17:21:29 rsalvaterra: for me it will be an AP so no need wpa_supplicant ever, but someone might need set openwrt as a client, or repeater, that will need wpa_supplicant, the point is, start wpa_supplicant when it's needed, not turn on it by default, that saves 2.3MB RAM at least Nov 03 17:22:53 if you don't need wpa-supplicant ever then just use hostapd and problem solved? Nov 03 17:23:05 or is wpad the default in our images Nov 03 17:23:18 stintel: yes that's what I'm building, but all docs recommend wpad-* Nov 03 17:26:07 rr123: Yeah, the docs… :/ Nov 03 17:26:34 The docs are so wonderful I just ignore them and read the source code, most of the time. Nov 03 17:27:40 quote: "for bare metal system you read the doc then write the code, for linux(openwrt) you read the code then write the doc" :( Nov 03 17:29:25 * rr123 is clueless about 'diff hostapd hostapd-openssl' in menuconfig Nov 03 17:31:03 stintel: Still, just using hostapd isn't solving the underlying problem… :/ Nov 03 17:31:35 in Makefile they're all the same, $(Package/hostapd/install), reading Makefile now Nov 03 17:32:39 rr123: I'd just use one of the hostapd-basic-{openssl,wolfssl}, depending on your requirements. Nov 03 17:34:39 rsalvaterra: I'm now using hostapd and wpa_supplicant, not sure what those openssl/wolfssl are for(security? or just CA-based 8021x, or what?), also I plan to hack the init script to try out eap_server which is unsupported by current openwrt code Nov 03 17:35:26 the menuconfig under wirelsssAPD is very confusing Nov 03 17:35:47 For WPA3 Personal and OWE, you need openssl/wolfssl. Nov 03 17:36:41 so, hostapd-wolfssl is a superset of hostapd then? Nov 03 17:36:45 The WirelessAPD menu is "interesting", indeed. :P Nov 03 17:37:02 looks like openwrt is shifting towards wolfssl from openssl Nov 03 17:37:28 openssl was never default Nov 03 17:37:32 rr123: Yes. The hostapd is a variant with embedded crypto, and only supports WPA2-PSK. Nov 03 17:37:36 the indent is completely broken as well. I once tried to fix it, but something in the internals seems to be wrong Nov 03 17:38:09 adrianschmutzler: The indentation depends on the order the CONFLICTS directives are expressed, I believe. Nov 03 17:38:51 I had to juggle with them a bit for the tor-basic variant. Nov 03 17:38:58 ok I now enabled 'hostapd-wolfssl' and 'wpa-supplicant-wolfssl', hope that's a good alternative to 'wpad' or 'wpad-wolfssl' Nov 03 17:39:49 Why not just hostapd-basic-wolfssl…? Nov 03 17:41:31 there is only hostapd-basic-openssl, plus, the basic only has wpa-psk/11r/11w but I need wpa2-enterprise Nov 03 17:42:39 rr123: You're not running master? Nov 03 17:43:27 Ah, if you need WPA2 Enterprise you must run a -full variant. Nov 03 17:45:46 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 100.0% packages reproducible in our current test framework.) Nov 03 17:48:52 rsalvaterra: i'm on master branch Nov 03 17:51:35 If you're on master, there's definitely hostapd-basic-wolfssl. You don't need it, though. :) Nov 03 17:52:00 Ah! It's just hostapd-basic. Nov 03 17:52:43 * rr123 is trying to add eap_server compiler flag to Makefile Nov 03 17:54:57 rr123: That's not enough. Not even the full variant is configured with internal RADIUS. You need an external one. Nov 03 17:56:18 it appears hostapd can do basic 8021x/eap-authentication without a full freeradius somewhere else Nov 03 17:56:40 but I'm unsure, thus the test Nov 03 17:59:26 Wait a minute. hostapd-basic is *not* linked against wolfssl. There actually isn't a hostapd-basic-wolfssl variant! Nov 03 17:59:49 Guys? Do we want to add it? If so, I'll take care of it. Nov 03 18:01:07 I'm going to add it anyway, since I need it for my AirGrid M2. :P Nov 03 18:02:24 The question is whether the (relatively) few bytes that hostapd saves compared to wpad matter when we add wolfssl/openssl anyway ... Nov 03 18:03:19 adrianschmutzler: The point is RAM, not storage. Nov 03 18:04:23 interesting; can you elaborate? Nov 03 18:04:32 With wpad, you have two daemons. Sure, that's a different issue and should be solved too. Nov 03 18:05:16 And yes, I'm aware that a good part of the processes memory is shared, but still… Nov 03 18:07:13 and this has an impact even if the relevant feature isn't used? i.e. wpad... will consume more memory if I just ran an AP compared to hostapd? Nov 03 18:07:41 adrianschmutzler: wpad_supplicant is started unconditionally, even if there are no STA interfaces defined. Nov 03 18:08:12 Check out the /etc/init.d/wpad script. Nov 03 18:08:39 Okay, interesting. Never thought about this in detail, I should have a closer look at some point. Nov 03 18:09:36 And the same is valid for hostapd, it's always started even if there are no AP ifaces. :) Nov 03 18:10:05 btw I have sta interfaces running with hostapd only Nov 03 18:10:38 Uhh… with no crypto, right? Nov 03 18:10:50 yes, IIRC Nov 03 18:11:07 used for configuring automatic meshing in Freifunk context Nov 03 18:11:38 Yeah, I thought it would something like that. Nov 03 18:12:10 *be Nov 03 18:12:11 so, network is open anyway, and whoever really wants to break the network locally will be able to anyway Nov 03 18:13:08 the switch from wpad to hostapd actually made it possible to still support the 4m flash devices with 19.07 ... Nov 03 18:13:12 Sure, but this use case is related to WPA2/3 Personal, otherwise we wouldn't need no supplicant. :) Nov 03 18:13:33 Of course, I slipped into OT a little here ... Nov 03 18:13:45 I still believe in 4 MiB. :P Nov 03 18:14:18 Stripped to the bare essentials, of course, but not impossible… Nov 03 18:14:35 Well, for me it's a practical point, in Freifunk communities you frequently have 80-90 % of _devices_ with 4M Nov 03 18:15:30 I try to keep them working as long as possible, so we don't create a huge pile of waste Nov 03 18:16:11 Reduce, Reuse <- you are here, Recycle. :) Nov 03 18:17:18 Ok, BRB… Nov 03 18:17:33 * rsalvaterra dives in the hostapd makefile, again… Nov 03 18:17:57 check your oxygen, don't drown there Nov 03 18:19:37 hehe Nov 03 18:20:28 It's not that bad, once you understand the structure… it's arguably better than the menu itself. :P Nov 03 18:21:46 Yes, but I'm always confused by the high degree of redundancy there that cannot be optimized away Nov 03 18:25:17 Complicated package is complicated. :) Nov 03 18:25:37 damex: Shield builds out/flashes fine with your octeon changes. Nov 03 18:25:55 damex: I'm still hoping you can wangle an octeon3 target so we can ditch octeonplus Nov 03 18:25:56 Grommish: nice, thanks. could you please report to MR? Nov 03 18:28:17 Grommish: i believe we could propose octeon3 subtarget later. it is harder to propose all changes at the same time Nov 03 18:28:55 damex: true, it wouldn't matter about changing it later.. just as much work Nov 03 18:29:09 But it gives us another device to justify it Nov 03 18:29:39 Or at least try to justify it heh Nov 03 18:30:18 Grommish: it is not just about device. it is about what it could give beside FPU. we need to test and show that there is an actual performance improvement in openwrt related tasks Nov 03 18:30:39 damex: right.. which isn't something I could quantify prior Nov 03 18:30:46 Certainly not as the only octeon3 device Nov 03 18:30:55 err could NOT quantify Nov 03 18:31:07 for all network related tasks, i couldn't see any difference that mattered Nov 03 18:31:33 stintel: working on x509 support for strongswan… but noticed a few things weren’t supported… like keyingtries and left/rightprotoport... Nov 03 18:31:37 I don't know if the encryption ASICs will make a difference or not Nov 03 18:31:51 and not every octeon3 has them Nov 03 18:33:11 philipp64|work: we're still in crisis situation at work and I'm still don't have time to properly focus on stuff outside of that Nov 03 18:33:21 other thoughts… what about having a common UCI for libreswan and strongswan? looking at the UCI, some of the documentation doesn’t seem to agree with /etc/init.d/ipsec … Nov 03 18:33:48 okay, I’ll plug at it and let you know when I have something to look at. hope the alligators aren’t snapping at your butt. Nov 03 18:34:25 was also thinking about migrating from ipsec.conf to swanctl.conf Nov 03 18:35:02 if anyone else wants to join in on the Strongswan party, more eyes on the problem are welcome… Nov 03 18:36:13 philipp64|work: swanctl.conf is WIP Nov 03 18:36:58 philipp64|work: https://github.com/stintel/openwrt-packages/commit/b489d87f645023194670cad5957e10f8d5c5a0c7 Nov 03 18:37:02 adrianschmutzler: Since OpenWrt is an operating system (mostly) for wireless routers, I believe it would even make more sense for the default wireless daemon to be hostapd and not wpad… Nov 03 18:37:48 philipp64|work: feel free to come up with something better :) Nov 03 18:38:13 rsalvaterra: well, that's a general "function vs. size" question, which different people will answer differently Nov 03 18:38:56 or "function vs. resource consumption" with reference to your RAM argument Nov 03 18:39:59 I'm not 100 % sure yet about the RAM argument either… It's the same executable, so the code is only mapped once. The difference will be in the data. Nov 03 18:40:25 stintel: I like the idea of /etc/init.d/ipsec abstracting away the “backend” and just continuing to transparently when the cut-over is made from ipsec.conf to swanctl.conf … but that means that the settings should probably have more “generic” names… which means throwing a switch. Nov 03 18:40:32 Memory accounting is hard. Nov 03 18:40:35 And that's exactly why I asked about whether having relevant interfaces or not will matter Nov 03 18:41:34 So, we would come to the main measure for all these discussions: Is there a sufficient reason to _change_ the current state? Nov 03 18:42:27 I'll answer that question after building/running. ;) Nov 03 18:43:54 Will be interesting in any case. However, I personally doubt you will find many allies among the committers for wpad->hostapd Nov 03 18:45:11 Oh, I don't mind about whatever the defaults are. I just believe in this case it makes sense to have the choice. Nov 03 18:45:58 So, coming back to whether one should just have an hostapd-basic-xxxssl available? Nov 03 18:46:13 Yep! Nov 03 18:49:37 Hey, this morning I suggested disabling scp by default since we can transfer files via ssh, and I was told to seek medical assistance, so… :P Nov 03 18:51:01 aren't they just the same multi-call dropbear Nov 03 18:51:35 rsalvaterra: And to which conclusion did the doctors come? Nov 03 18:52:33 rr123: scp is over 14 % of the dropbear size. Nov 03 18:52:39 adrianschmutzler: Right. :P Nov 03 18:53:25 But knowing that is actually an interesting lever for 4M again ... Nov 03 18:54:44 Let's put it this way: my dropbear executable is 96165 bytes. Nov 03 18:55:02 (74Kc, -O2) Nov 03 18:55:19 dropbear here is 253K Nov 03 18:57:00 but I turned on all the 'features', I probably don't need them all Nov 03 18:58:07 rr123: To reduce the size as much as I did, you need to apply my pending patch series… and even then it won't be enough, as I have still a patch to compile dropbear with MIPS16 instructions. Nov 03 18:59:29 The only crypto I have enabled is Ed25519, Curve25519 and ChaCha20-Poly1305. Nov 03 19:21:22 rsalvaterra: i think hostapd-common is the one started wpa_supplicant unconditionally, specifically, the /etc/init.d/wpad script inside it Nov 03 19:22:35 it basically says if you have a wpa_supplicant installed i will run it immediately, i don't care if it's from wpad or you need it or not Nov 03 19:23:05 rr123: Yes, it's what I told PaulFertser, above. Nov 03 19:26:31 I wasn't expecting such a large difference in the final image size (openwrt-ath79-generic-ubnt_nanostation-loco-m-squashfs-sysupgrade.bin)… Nov 03 19:26:31 4719426 bytes - wpad-basic-wolfssl Nov 03 19:26:31 4457282 bytes - hostapd-basic-wolfssl Nov 03 19:28:21 Now let's see if it runs… Nov 03 19:40:36 … and it works perfectly. Nov 03 19:55:10 you don't ever need wpa-supplicant then, mesh/client/repeater might need that? Nov 03 19:56:44 rr123: Wonderful question. I have no idea. I only use infrastructure mode. Nov 03 20:37:32 rr123: I think the latest versions of wpa_supplicant can either be a client or AP, so for a while now that’s been all you’ve needed. It has subsumed the hostapd functionality. Nov 03 21:03:46 rr123, rsalvaterra philipp64|work: wpa_supplicant supports AP mode to some degree, however, we do not support making use of that in OpenWrt. It lacks WPA-Enterprise features and a few other things, but Android uses that for thethering, so it does work to some degree Nov 03 21:05:18 dangole: Interesting, and quite unexpected. :) Nov 03 21:06:57 obviously we'd also have to reimplement AP+STA (which is a local patch we've been carrying more than a decade)... Nov 03 21:08:51 dangole: And here I was, thinking carrying patches for over 3 months is a lot of time… Nov 03 21:09:14 dangole: thanks for the info Nov 03 21:09:25 just came back from election, time to try eap_server Nov 03 21:09:41 to see if it can replace freeradius for simple 8021x use case Nov 03 21:19:40 has anyone tried ap+sta recently? does it stillkill the AP side if you get the wrong password on the sta side? (kill == hangs trying to reconnect sta forever, never servicing the ap side) Nov 03 21:20:15 I'd be ok with terrrible perf for channel switching, but the lockout on wrong password made it pretty much useless Nov 03 23:23:21 guys concerning NAT Slipstreaming mitigation, could you please send a feedback / review https://github.com/openwrt/openwrt/pull/3564 ?? Thank you **** ENDING LOGGING AT Wed Nov 04 02:59:57 2020