**** BEGIN LOGGING AT Wed Apr 24 02:59:57 2019 Apr 24 05:20:34 nbd: https://bugs.openwrt.org/index.php?do=details&task_id=2254 Apr 24 05:52:14 jow: much appreciated Apr 24 06:45:47 jow: thanks, i'll take care of this today Apr 24 06:48:03 anyone knows if there is any more work being done on mwlwifi? last serious commit was ages ago... Apr 24 07:29:17 Does anyone use luci2 on lighttpd? Apr 24 07:34:50 jow: done Apr 24 07:41:04 Is there any better way to add fcgi to solve the similar functions of the original uhttp-mod-ubus? Apr 24 08:25:23 albert: no, there are no alternative implementations of uhttpd-mod-ubus Apr 24 08:25:39 you need to write a cgi or fcgi program mimicking the protocol Apr 24 08:26:18 nbd: thanks! while you're at it, could you also look at https://bugs.openwrt.org/index.php?do=details&task_id=2253 Apr 24 08:26:30 the patch looks sane to me, but you know more context Apr 24 08:40:01 albert: if you have enough resources to run lighttpd, then you could simply run uhttpd in parallel and reverse-proxy the /ubus prefix Apr 24 08:40:30 bind uhttpd to 127.0.0.1:8080 or something and reverse proxy /ubus to http://127.0.0.1:8080/ubus Apr 24 08:52:50 ok, thanks Apr 24 11:26:54 Hello to everyone Apr 24 11:30:02 I've just finished my work and ported OpenWrt to Mikrotik rb912R-2nD. But i faced with an issue about board detection. /lib/ar71xx.sh script does not detect this model even if I copy paste it from /tmp/sysinfo/model Apr 24 11:30:21 So I decided to ask some advice before pull request Apr 24 11:31:25 I tried to add some breaking points, but without any success. Apr 24 11:33:06 Here is the patch Apr 24 11:33:07 https://pastebin.com/ryW5mdWG Apr 24 11:34:50 Even with this patch detection works for other boards Apr 24 11:35:10 May be I did something wrong Apr 24 11:36:49 line 21 is probably the wrong match Apr 24 11:37:00 also, you need to keep those lists alphbetically sorted, don't just drop yours in the end. Apr 24 11:38:13 are you naming it ltap-hb or what? Apr 24 11:38:46 your mips machine is ltap-hb, but then you're looking fot this 912-nd2 whatsti? Apr 24 11:38:54 are you sure you're been consistent with those? Apr 24 11:40:00 that's because this board name is RB912R-2nD, but lt-ap mini as a marketing name. ltap-hb is a MIPS machine name Apr 24 11:41:53 BTW don't waste the time with ar71xx anymore, it's unlikely, that it would be merged at this point of time, you should focus on ath79, for details see for example this thread http://lists.infradead.org/pipermail/openwrt-devel/2019-April/016679.html and https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=750a57b8364c2ef9e021b9428725585e47864163 Apr 24 11:42:46 But all mikrotik devices are ar71xx now Apr 24 11:43:14 There is no mikrotik subtarget for ath79 Apr 24 11:44:02 The bookwise answer would be that "all mikrotik devices should change to ath89", but ofcourse achieving that is whole ffirent thing... but point is that ath79 replaces ar71xx and ar71xx is obsoleted Apr 24 11:44:25 s/89/79 Apr 24 11:44:57 for this new Mikrotik naming scheme see for example this PR https://github.com/openwrt/openwrt/pull/1943 Apr 24 11:48:16 ynezz, but this new mikrotik scheme is not merged yet Apr 24 11:48:17 BTW I've tried to scrap all the new Mikrotik product codes https://gist.github.com/ynezz/0e42e09422e6c155b854892940a0dad1 but I can't find your device there Apr 24 11:48:35 so perhaps it's this one RB912R-2nD-LTm ? Apr 24 11:48:48 it's quite a nice mess :) Apr 24 11:49:03 When you select a target, how does OpenWRT know which default packages to install? Apr 24 11:49:32 git grep DEFAULT_PACKAGES Apr 24 11:49:44 It's all RB912R-2nD-* devices Apr 24 11:50:16 The one board =) Apr 24 11:50:23 Thanks ynezz Apr 24 11:53:19 So what is the main idea about mikrotik devices? New target, new ath79 subtarget, LTS variant of ar71xx? Apr 24 11:55:19 Also I think it's a good thing to keep ar71xx target, because (for example) TP-Link has devices that do ethernet initialization while the system is loading. So there is no way, we should use mach for that Apr 24 11:55:48 EAP-245 as i remember Apr 24 12:01:23 I probably miss something obvious, but I simply don't see any reason why Mikrotik should be ath79 subtarget Apr 24 12:02:11 Me too Apr 24 12:02:41 I jus try to figure out =) Apr 24 12:02:47 good :) Apr 24 12:12:37 sorry, but even with alphabetic order it does not work Apr 24 12:12:38 https://pastebin.com/YGnAPvNq Apr 24 12:13:03 # cat /tmp/sysinfo/model MikroTik RouterBOARD RB912R-2nD Apr 24 12:14:07 the alphabetical was just style that you need to fix, it certainly won't "fix" any problems :) Apr 24 12:14:57 # cat /tmp/sysinfo/board_name unknown Apr 24 12:15:14 Damn =) Apr 24 12:16:44 So can I create a pull request with only initial support od this board and continue this work in github ? Apr 24 12:18:30 you can, but when you know it's not actualyl ready, you should probably just wait until you've fixed it. Apr 24 12:19:19 Sorry, I'm not so cool in bash and I can't detect problem for now Apr 24 13:05:21 you're probably overthinking it. Apr 24 15:32:28 mangix: have we decided to just update everything in 1806 all the time now too? are there any packages that you're _not_ going to try and just update to latest as well? Apr 24 15:33:07 please don't Apr 24 16:01:41 yeah, I don't want themt oo either, but the packages repo is getting spammed with updates for 1806 because something failed on ppc, or something minor had a cve in some old version. Apr 24 16:52:24 hi, i have a MT7628DAN (ramips) dev board that i've been messing around with Apr 24 16:53:04 I want to generate a factory bin for the board, but I only see references to tplink specifics when it comes to generating a ramips factory bin Apr 24 16:53:29 Where can I go to read how to generate one for my dev board? If it helps, its the OOLITE 3.5 dev board Apr 24 16:53:32 or so the silkscreen says Apr 24 17:12:36 foxtrot: oolite ships with openwrt already don't they? Apr 24 17:12:52 factory is the images in the format needed by the factory software's built in update procedures. Apr 24 17:13:06 if they take "normal" openwrt sysupgrade, then you don't need a special "factory" image Apr 24 17:13:07 foxtrot: factory.bin only exists when you need a special way to pack the firmware to bypass the firmware check in the original firmware. Most of those dev boards don't need such a thing. Apr 24 17:14:04 Right, I changed some GPIO stuff in the DTS and threw my board into a bootloop / openwrt that wont boot, I figured a factory bin flashed from uboot would get me past that Apr 24 17:14:33 I don't know of another way to flash the board with the sysupgrade.bin I have without access to the sysupgrade tool Apr 24 17:17:37 use the serial console in the bootloader.... Apr 24 17:20:03 I... don't see how that answers my question? Apr 24 17:20:29 I'm obviously attached to the serial, I guess what I don't know is how to flash the sysupgrade from uboot Apr 24 17:20:49 my experience is limited to flashing only factory images via uboot. Apr 24 17:23:51 so... how do you flash this "factory" image via uboot? Apr 24 17:24:09 you probably already have a kernel and rootfs in your bin dir? Apr 24 17:24:59 No, I have only a sysupgrade. Apr 24 17:25:20 in .bin Apr 24 17:26:08 I flashed a sysupgrade with a change that doesn't allow me to fully boot the board now, so I can't undo the change, build a sysupgrade, and flash one that undo's my changes Apr 24 17:26:15 That's why I asked for some guidance Apr 24 17:33:35 any Turris people here? Apr 24 17:35:14 karlp: updating is the easiest route. just git cherry-pick. For loasec I'll edit the patch Apr 24 17:37:18 it's not about easy, it's about whether major version upgrades are better or worse than the cves. Apr 24 17:38:32 for prosody i'll wait for the maintainer to weigh in. Apr 24 17:38:33 mangix: I'd say often they're not. new versions just have new cves. if there's no explicit security patch for the version from upstream, I don't really think that just blanket updating to latest is the right approach Apr 24 17:40:17 i don't actually use prosody so I can't say one way or another. Apr 24 17:40:33 foxtrot: you know about tftp? Apr 24 18:28:24 fascinating...the first time i've seen -fpic fail: https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53/packages/libxerces-c/compile.txt Apr 24 18:29:25 oh that's dated April 5. nvm. Apr 24 19:06:05 for development I'd like to run multiple qemu VMs with different configurations. Is it possible to mount the config directory externally or something similar? anyone experience? Apr 24 19:36:12 mangix: yesterday's build is failing as well. Apr 24 20:07:00 bizzarre Apr 24 20:07:05 will look when i have time Apr 24 20:20:43 russell--: Yes, I know about tftp Apr 24 20:21:05 I don't know if i'm just not explaining myself properly Apr 24 20:21:15 Can I flash the sysupgrade if I don't have access to the OS? Apr 24 20:25:28 If you can, I have never done that so I was curious how to do so Apr 24 20:50:53 I have a fairly fat OpenWRT image with a good number of kernel modules - CONFIG_ARM_MODULE_PLTS isn't set by default so it was failing Apr 24 20:54:41 is it intentional that this kernel option is disabled in OpenWRT? Apr 24 20:56:08 size is king, if a feature isn't strictly required, it tends to be disabled Apr 24 21:01:18 yeah, the problem is that without it, you can quickly end up having more kernel modules than the kernel itself has space to load Apr 24 21:02:06 since, by default, it uses a relatively small area - with the above option, it gains the ability to stick them in the vmalloc area if needed Apr 24 21:25:38 stintel: You were trying to enable WPA3 at some point, right? Did you ever get it to work with any device? After my troubles with it on Android, I decided to compile wpa-supplicant 2.8 for Ubuntu and try there, but I always get "CTRL-EVENT-ASSOC-REJECT bssid=fc:ec:da:88:15:7c status_code=31". Apr 24 21:25:44 And 31 is "TS deleted because QoS AP lacks sufficient bandwidth for this QoS STA due to a change in BSS service characteristics or operational mode" Apr 24 21:26:11 Hauke: You might be interested in this too (it pertains to the WPA3 connection issues I was trying to debug on Android.) Apr 24 21:26:37 mamarley: Debian with wpa_supplicant 2:2.7+git20190128+0c1e29f-4 is working for me on a netbook with ath5k Apr 24 21:27:09 pkgadd: If you don't mind sharing, what is your exact /etc/config/wireless (sans keys, of course)? Apr 24 21:27:23 I'm wondering if I might have just done something wrong on that side. Apr 24 21:31:06 mamarley: I have a lot of optional stuff enabled and am currently using mixed mode, but I did test pure WPA3psk as well (also against a commercial implementation): http://paste.debian.net/hidden/bef0d850/ Apr 24 21:31:15 Thanks! Apr 24 21:32:03 my main problem was trying to use a hex key, instead of a passphrase - that drove me mad for weeks (months) Apr 24 21:34:02 I just have an 18-character passphrase with all ASCII characters, no spaces, special characters, Unicode, or anything else. Apr 24 21:34:51 mamarley: what AP are you using? Apr 24 21:35:17 Hauke: Ubiquiti UAP-AC-PRO, I have tried both the ath10k and ath9k chips with the same result. Apr 24 21:36:20 I've also tried disabling 802.11r, 802.11w, and only broadcasting one SSID per device, none of which have made any difference Apr 24 21:37:31 802.11w is activated by default in sae mode now Apr 24 21:37:38 can you explictly set it to 0 Apr 24 21:38:31 the stanard says when the client uses sae it has to support 802.11w and the AP has to require it, for legacy clients it is optional Apr 24 21:38:50 I will have some sleep now Apr 24 21:39:16 Hauke: I tried that, now I get status 53 instead of status 31. Apr 24 21:40:12 "The mesh STA has reached the supported maximum number of peer mesh STAs", which doesn't make any sense, because I'm not doing anything with mesh… Apr 24 21:41:05 Wait, after a couple of attempts, it actually succeeded… Apr 24 21:42:41 Perhaps the driver on the client side doesn't support MFP? Apr 24 21:42:41 * mamarley looks… Apr 24 21:46:34 I use a "pwgen -s 63 1" as my psk, so something like FIOYFdgfASiMuZDnOqzxAixfq2z8GugL3CbDE5dntSATU38PvPHMAT5VrCbXw4Q Apr 24 21:47:13 pkgadd: What chip is your client device using? I'm thinking MFP support may be the issue here. Apr 24 21:47:27 ath5k (AR5007EG) Apr 24 21:48:39 ipw2200 doesn't support it - and I haven't tested my assortment of other WLAN cards yet Apr 24 21:49:52 I have some Intel 6000-series card. It looks like iwlwifi-dvm supports MFP conditionally, now to figure out if my card satisfies that condition… Apr 24 21:51:27 mamarley: I should try it again some time Apr 24 21:51:54 I tried mix mode but some devices were unable to connect then so I reverted to just psk2 Apr 24 21:52:22 stintel: You do have 802.11w turned on, right? Because I know you were involved with that MFP performance thing on ath10k. Besides Android, which devices wouldn't connect? Apr 24 21:53:04 I don't recall. but my gf's iphone just refused to connect to my guest network that had mixed mode still enabled Apr 24 21:53:22 not sure which iphone it is, I think 5 but not sure Apr 24 21:53:27 Ah, OK. I am testing out my MFP theory right now… Apr 24 21:54:10 I do have 11w enabled, optional Apr 24 21:54:30 It is required by the standard for SAE/WPA3. Apr 24 21:55:03 yes, but I have in my config option ieee80211w '1' Apr 24 21:55:14 not sure what that does in combination with mixed mode Apr 24 21:55:28 stintel: OpenWRT passes "sae_require_mfp 1" to hostapd by default. Apr 24 21:55:34 ah ok Apr 24 21:55:53 http://paste.debian.net/1079204/ and http://paste.debian.net/1079203/ are the client side Apr 24 21:56:57 But I can confirm that with 80211w 1 and sae_require_mfp 0, the laptop still connects. MFP is definitely the problem, I guess this old-ass WiFi chipset doesn't support it. Apr 24 21:58:38 oh well, not up for messing with it now Apr 24 21:59:08 Sorry, I wasn't intending to imply you should. I was just trying to pick your brain. Apr 24 21:59:13 maybe in the weekend, before traveling on Sunday Apr 24 21:59:18 no worries Apr 24 22:00:00 laterz! Apr 24 22:00:05 Intel 6000-series isn't old, my ipw2200 are Apr 24 22:04:43 In any case, I can't seem to tell if it supports MFP or not, so I must assume not since making it optional on the AP side for SAE makes the problem go away. Now I wonder if this was causing the Android problem too… Apr 24 22:29:27 can I somehow set the country3 option of hostapd through uci? Apr 24 22:29:50 I want to influence the channel selection to only consider outdoor channels by setting country3=0x4f Apr 24 22:30:29 you can at least provide channel lists Apr 24 22:31:05 sure could, but this is for a more generic solution, where I would like it to simply default to outdoor channels supported in the regdom Apr 24 22:50:53 fwiw, there is hostapd_options, where kv-pairs can simply be added to an array Apr 25 00:24:18 stintel: mixed WPA2/3? Apr 25 00:24:36 my iphone refuses to connect as well Apr 25 00:25:00 Apple engineering. Think different: https://en.wikipedia.org/wiki/Think_different Apr 25 00:25:54 iOS 6 and below refuses to connect if the WPA2 network has SHA256 enabled for authentication Apr 25 00:34:55 foxtrot: you give u-boot the option to flash an image via tftp Apr 25 00:35:16 or build an initramfs image and tftp-boot it Apr 25 00:35:55 ramips u-boot has some numbered options Apr 25 00:36:12 capture the serial console and review what the options are Apr 25 00:36:36 It does indeed have some options, I don't have the board right this second. I was just unaware that you could flash the sysupgrade image via tftp Apr 25 00:36:44 I thought it had to be a factory.bin Apr 25 00:38:27 i appreciate the info Apr 25 00:42:16 I also tried again and found that the MFP issue had nothing to do with my Androids refusing to connect. Neither the one with 9 nor the one with Q beta 2 will connect to an "sae-mixed" network, even with "sae_require_mfp" 0. Apr 25 00:52:17 mamarley: klte with lineageos 16 works well with sae-mixed (and so do lineageos 14/ i9105p and cm 7.2/ HTC legend), neither of them can actually do WPA3 though (the first two are brcm dhd, the later TI1271) Apr 25 00:54:24 pkgadd: Both of the devices I tested were Pixel XLs with whatever the integrated WiFi chip on the Snapdragon 821 is. I'm pretty sure that's the problem. Apr 25 00:55:17 I actually have a Pixel 3 coming hopefully later this week (to replace one of the Pixel XLs which is partially busted due to having taken an unintended swim), so it will be interesting to see what that does. **** ENDING LOGGING AT Thu Apr 25 03:00:02 2019