**** BEGIN LOGGING AT Fri Nov 16 02:59:58 2018 Nov 16 04:55:45 dwmw2_gone: does openconnect support web based MFA ? Nov 16 04:55:53 dwmw2_gone: or rather i am almost sure it does not Nov 16 04:56:44 dwmw2_gone: have you however looked at this already ? when i connect to the server and log in, it'll reply with an url that the client prints on the shell Nov 16 04:57:04 dwmw2_gone: my guess is that this needs to be appended with some session cookie and then opened inside a browser Nov 16 04:57:26 stuck with the anyconnect client which is an insult to humanity for now Nov 16 05:28:31 Monkeh: I finally figured out the external watchdog, oddly it seems too sensitive to the tick (hw_margin_ms) Nov 16 05:29:04 and sysupgrades work without me worrying about watchdog rebooting midflash Nov 16 05:31:58 * russell-- about to try to put together a device tree for a ubnt-airrouter Nov 16 05:32:08 for ath79 Nov 16 05:33:04 * russell-- tries to remember that *most* of the power supplies littering my desk are *12V*, not 5V. Nov 16 06:05:04 abenz: 'too sensitive'? Nov 16 06:21:35 when i change iface proto from dhcp ti static or viceversa from luci, option metric 'xx' is lost in configs Nov 16 06:24:59 ds_shadof, that's normal, because isp's can have different metrics Nov 16 06:25:43 they can assign (almost) any mask they want Nov 16 06:28:10 Monkeh: I put lower values (sub 1 second) thinking thats a better reset interval but it didn't work Nov 16 06:28:19 increasing it to 1.6 seconds did the trick Nov 16 06:41:09 ds_shadof: all options but ifname and auto are reset on protocol changes Nov 16 06:41:09 thats to keep the implemantiation simple Nov 16 06:43:42 abenz: Odd. Would have to know the chip. Nov 16 06:50:48 jow, but breaks routing in router :) Nov 16 06:58:52 hmm. ethernet interfaces seem to be swapped. Nov 16 07:10:41 is there a way in device tree to swap them back? eth1 vs eth0 Nov 16 07:50:05 on ar71xx, eth1 is wan, eth0 is lan on airrouter. with a naive barebones dts on ath79, eth0 is wan, eth1 is lan. how to fix? Nov 16 07:51:22 blogic: ? Nov 16 07:54:57 russell--: Needn't fix it :) Nov 16 07:58:14 that's one option, but has the downside of breaking peoples configurations, maybe unnecessarily Nov 16 07:59:14 russell--: afair the agreement was to allow ath79 to introduce such breaks to get rid of legacy quirks Nov 16 07:59:50 ar71xx compatibility is not a design goal Nov 16 08:03:00 jow: okie-doke Nov 16 08:03:49 IMO ar71xx is in the wrong anyway there, wan first, then lan :D Nov 16 08:08:15 My router spits out the following during boot on dmesg; Nov 16 08:08:17 [ 10.120937] ath10k_ahb a000000.wifi: Direct firmware load for ath10k/pre-cal-ahb-a000000.wifi.bin failed with error -2 Nov 16 08:08:32 manufacturer says I can find the file here: "pre-cal-ahb-a000000.wifi.bin is extracted form ART partition by 11-ath10k-caldata script." Nov 16 08:09:02 is it correct to assume that if everything was working fine and it successfully extracted it then I shouldn't be getting that message? Nov 16 08:12:10 barhom: the problem is that ath10k spews a lot of errors during normal firmware loading Nov 16 08:12:30 it tries various places all erroring out until it eventually falls back to a usermode load helper Nov 16 08:12:48 right, so if the wifi is working = all good? Nov 16 08:13:00 right... that's what I was getting at Nov 16 08:13:04 I thought that maybe wifi would be better if I gave is caldata and it would work less good without it Nov 16 08:19:46 jwh: fwiw, netgear wndr3800 and buffalo wzr600dhp both have eth1 as wan (on both ar71xx and ath79) Nov 16 08:20:24 I'd have to change that pronto, would irritate me heh Nov 16 08:27:36 russell--: ermmm Nov 16 08:27:44 not sure Nov 16 08:35:46 russell--: on ar71xx, the board files control the eth0/eth1 assignment with the order the devices are registered. on ath79, the order of the nodes in the dts(i) files controls the eth0/eth1 assignment, so they are fixed for the whole target, unless you want to move them from the dtsi files to the dts files. A more practical solution might be to let procd? rename the eth devices to the expected/ar71xx names Nov 16 08:37:57 KanjiMonster: correct Nov 16 08:38:17 KanjiMonster: or patch the driver to take a property for explicit netdev names Nov 16 08:40:35 blogic: maybe an aliased based solution like spi uses might be reasonable, and handle it in the base instead of per driver. Or have aliases and let procd use them for renaming, in case upstream doesn't like it Nov 16 08:40:57 KanjiMonster: 2nd option sounds legit Nov 16 08:46:49 any one able to AC this? https://github.com/openwrt/openwrt/pull/1541 Nov 16 08:47:40 It will give me a excuse to kick off a new build. Nov 16 09:19:46 blogic: KanjiMonster: i am going to send my patch to the mailing list, please feel free to correct it (and i will watch and learn) ;-) Nov 16 09:29:03 russell--: learn from whom ? Nov 16 09:32:14 lol Nov 16 09:36:53 when i wrote "watch and learn", i was imagining king arthur and the knights as they approached the Bridge of Death Nov 16 09:37:29 KanjiMonster: ping Nov 16 09:38:18 are you planning to send https://pastebin.com/WD3383t6 upstream ? Nov 16 09:38:25 I can send it too but you wrote it ;) Nov 16 09:50:49 jow: are there snapshot builds of the 18.06 branch ? Nov 16 09:59:19 stintel: yes! :) http://downloads.openwrt.org/releases/18.06-SNAPSHOT/ Nov 16 09:59:24 aha! Nov 16 09:59:25 but don't tell anyone Nov 16 09:59:51 lol Nov 16 09:59:53 too late Nov 16 10:00:13 ;) Nov 16 10:00:33 they tend to cause confusion, thats why they aren't advertised anywhere and even hidden from the directory listing Nov 16 10:01:11 * ldir erases his memory Nov 16 10:01:21 maybe we can add some README to that page then ? Nov 16 10:25:16 greearb_: ping Nov 16 10:25:51 i'm working on my custom app using uci, i've just added #include to it and it does not compile with 17.01: Nov 16 10:25:56 staging_dir/target-arm_cortex-a9_musl-1.1.16_eabi/usr/include/uci.h:643:10: error: expected declaration specifiers or '...' before '(' token Nov 16 10:25:57 return uci_to_package(e); Nov 16 10:26:14 include order is uci.h -> libubus.h -> libubox/avl.h Nov 16 10:26:27 this problem is fixed in master and 18.06 by a following commit: https://git.openwrt.org/?p=project/libubox.git;a=commitdiff;h=ace64897d47b9bc7af277d8a3f8a0ff67976cba8 Nov 16 10:27:01 it's a matter of fixed container_of macro Nov 16 10:27:41 is that a good condidate to backport to 17.01? jow? nbd? Nov 16 10:28:20 oh, this is probably more meaningful error message: Nov 16 10:28:23 staging_dir/target-arm_cortex-a9_musl-1.1.16_eabi/usr/include/uci.h:643:10: error: '__mptr' undeclared (first use in this function) Nov 16 10:28:25 return uci_to_package(e); Nov 16 10:39:58 rmilecki: backport is fine with me Nov 16 11:51:58 jow: the IP of util-01 is no longer listed as blocked on the microsoft page Nov 16 11:52:25 stintel: until the next hotmail user fails to find the unsubscribe link Nov 16 11:53:09 :) Nov 16 11:53:17 jow: tbh I was listed there too Nov 16 11:53:25 with my OVH IP Nov 16 11:53:31 I suspect they just throw in entire IP ranges Nov 16 11:53:46 any VPS hosting cloud is probably on various smtp block lists by default Nov 16 11:53:50 I have used the same procedure to get my mailserver IP removed Nov 16 11:54:10 and have not had reports of mail delivery issues since Nov 16 11:54:29 the thing is I did that very same process you did yesterday a few months back Nov 16 11:54:29 the only client that uses my mailserver contacts his wife on @hotmail Nov 16 11:54:34 oh :/ Nov 16 11:54:46 maybe its due to the fact that we changed the domain Nov 16 11:54:54 but I remain very sceptical Nov 16 11:55:24 anyway, running a mail server is a pain. always. Nov 16 11:55:25 we do SPF, we do DKIM Nov 16 11:55:34 we got in touch with them and got reviewed Nov 16 11:55:39 still blocked eventually Nov 16 11:55:50 so not sure what else can be done Nov 16 11:56:06 yes I know, switch to hosted outlook ;) Nov 16 11:57:51 ahahaha Nov 16 11:58:00 we would still have issues Nov 16 11:58:12 with incoming mail ;) Nov 16 11:58:21 ah right Nov 16 11:58:44 screw mail, its old greybeard technology anyway Nov 16 11:58:52 we should use slack Nov 16 11:59:00 nooooooooo Nov 16 11:59:15 hey its totally cool Nov 16 11:59:21 you can send animated gifs and stuff Nov 16 11:59:38 and since its all on a single server it is webscale and has no pesky delivery issues Nov 16 12:00:10 fortunately one can use matterircd Nov 16 12:00:13 it features a really lean client as well, takes less then 4GB of ram after three days Nov 16 12:01:01 I refuse to run the client Nov 16 12:01:06 * ldir bans jow for mentioning slack Nov 16 12:01:23 but for our daily meeting I am forced to run chromium because slack in firefox doesn't voice/video call Nov 16 12:02:44 stintel: just mention that you've heard it leaks data to China ;-) Nov 16 12:05:57 meantime I'm getting very close to adjusting both of my qnap devices with a hammer - and qnap uk support keep *very* strange hours for a uk based operation. It's as if they're in another timezone really. strange. Nov 16 12:06:37 I'm using a Huawei Nov 16 12:06:47 it probably leaks to China too :P Nov 16 12:07:40 can someone remind me how to specify an led to do the status blinkie during boot? Nov 16 12:32:55 ah, found it: led-boot,etal aliases Nov 16 12:47:59 Is this the right channel when it comes to discussing problems as in: "I compiled myself a build for my router from the master branch and am facing issues, any ideas?" or should I just go to the main channel? Nov 16 12:50:34 Of course, I will give detailed information on the problem. Nov 16 14:18:14 jow: ping Nov 16 14:18:45 jow: could you repeat please how the uqmi fix should be tested, the usecase? I didn't save your previous reply :( Nov 16 14:25:09 xback: best is to setup a port forward Nov 16 14:25:31 xback: then compare iptables -t nat -S before/after and the warnings reported by "fw3 reload" before/after Nov 16 14:25:43 the contents of /var/run/fw3.state before/after would also be useful Nov 16 14:25:55 before/after means before and after applying the patch respectively Nov 16 14:26:07 jow: ok. just flashed the board with all required stuff setting up qmi currently Nov 16 14:27:35 great Nov 16 15:26:55 jow: see pm Nov 16 15:27:24 if needed, I can let you teamviewer so you can take a look Nov 16 16:08:29 xback: thanks! this was after applying the patch? Nov 16 16:08:48 teamviewer would be good Nov 16 16:12:27 jow: was after the patch Nov 16 16:12:38 ill setup teamviewer, sec Nov 16 16:15:06 jow: see pm for credentials Nov 16 16:17:26 blogic, here Nov 16 18:54:20 jow: any idea why fortify-headers is including host libraries? https://github.com/openwrt/packages/pull/7447 Nov 16 19:52:07 mangix: can you provide me with a log? Nov 16 20:01:16 jow: figured it out. Nov 16 20:02:22 OpenWrt's gcc does not include the poison-system-directories patch so it was somewhat hard to debug. Nov 16 20:08:04 anyone have any opinions on whether iperf2 or iperf3 is better? Nov 16 20:18:38 greearb_, iperf2 still exist ? Nov 16 20:18:54 evidently Nov 16 20:19:10 looks like iperf3 is actively developed, so I guess I'll use it Nov 16 20:19:54 iperf2 too: https://sourceforge.net/p/iperf2/code/ci/master/tree/ Nov 16 20:21:04 I only tried iperf3 for now, and I don't know if there is some iperf2 public server Nov 16 21:46:49 afaik, most servers still run iperf2 Nov 16 21:51:49 well, maybe not most, but some :) Nov 16 21:51:53 iperf3 is not multi-threaded while iperf2 is Nov 16 21:55:24 I noticed that, not sure how much it matters for my use case. Nov 16 21:56:00 also, iperf3 can only handle one client at a time, it needs dirty scripts like in https://iperf.fr/iperf-servers.php Nov 16 21:56:40 I don't understand why the iperf3 people didn't at least code the same features Nov 16 21:57:33 greearb_: from my tests, iperf3 is slightly faster than iperf2 on a single core Nov 16 21:57:52 but if you use multiple cores with iperf2 it beats the hell out of iperf3, obviously Nov 16 21:59:48 that one-at-a-time thing will be a potential issue for me, but since I want to automate gathering results, maybe best if I specifically launch multiple servers on different listening ports or something like that **** ENDING LOGGING AT Sat Nov 17 03:00:00 2018