**** BEGIN LOGGING AT Thu Jun 11 02:59:59 2020 Jun 11 03:35:51 build #323 of layerscape/armv7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/323 Jun 11 04:30:24 build #159 of bcm27xx/bcm2711 is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2711/builds/159 blamelist: Adrian Schmutzler , Renaud Lepage Jun 11 06:41:42 I got the device I'm porting to fully functional on the network side of things, but I'm only getting 200mbps instead of the full 500 I usually get when connected directly to my main router which is the same as the one I'm porting to (everything I'm mentioning is over ethernet). Are there any optimizations I can do to get the speeds up or is openwrt just inherently slower? The vlans are configured to have wan traffic pass through Jun 11 06:41:42 the CPU just like the OEM firmware. The router is IPQ8064 based. Jun 11 06:43:03 mangix: it is not typical bureaucracy - that is bullshit Jun 11 06:43:23 it is us trying to keep resources under control Jun 11 06:55:36 Tapper: downsides are increased ressource consumption (+5GB per target per release, +1h hour buildtime per cycle), increased amount of targets (+1 for now, ynezz suspects that it'll quickly by +3 due to kernel size limitations), increased support load (directing people to new targets) Jun 11 06:55:45 Tapper: and so far I don't see any actual upsides Jun 11 06:56:08 very few non-router packages might benefit slightly (video transcoding?) Jun 11 06:56:31 neither routing throughput nor wireless signal or whatever would be affected by this Jun 11 06:57:16 if that extra 5% speed are needed when transcoding videos on a router, you can simply add the cortexa9_neon repo to opkg.conf and install packages from there Jun 11 07:21:42 jow: and that should be suggested Jun 11 07:22:01 it's not 5% Jun 11 07:37:20 hmm i wonder if that PR speeds up wireguard. i would think it does. Jun 11 07:37:46 wireguard has NEON code Jun 11 07:39:58 wär mir neu dass wireguard auf maschinencode baut Jun 11 07:46:28 well, wireguard can't take advantage of hardware acceleration yet. Jun 11 07:49:00 the c compiler can do that if needed Jun 11 07:50:05 https://lwn.net/Articles/804181/ "crypto: crypto API library interfaces for WireGuard" mentions Neon Jun 11 07:51:47 even has mips ASM. still slow. Jun 11 07:52:46 faster than OpenVPN though Jun 11 07:54:10 but is it faster than IPsec :) Jun 11 07:54:42 depends Jun 11 07:54:45 thats so because in-kernel vs. userland Jun 11 07:54:55 partially Jun 11 07:54:59 mainly Jun 11 07:55:21 wireguard also has a lower overhead design Jun 11 07:55:23 on most systems wg is faster than openvpn although openvpn works with null-cipher Jun 11 07:55:55 wireguard in userspace is also faster than opencpn Jun 11 07:56:11 *vpn Jun 11 07:56:28 mangix: which PR? Jun 11 07:57:11 https://github.com/openwrt/openwrt/pull/3079 Jun 11 07:59:16 default is vfpv3. Jun 11 08:18:20 oh cool Jun 11 08:18:28 yea enabling kernel neon will result in perf boost Jun 11 08:20:08 jow: i noticed that changing MAC address using LuCI doesn't work Jun 11 08:20:20 it writes to "config interface" section instead of "config device" section Jun 11 08:20:33 rmilecki: known issue, luci has no support for device sections Jun 11 08:20:43 ok Jun 11 08:30:09 anybody here who knows details of the fritzbox4040 port of openwrt? Jun 11 08:52:43 Is there a reason for vxlan to be in the main repo? Jun 11 08:53:33 is there a reason against it? Jun 11 08:53:48 low level network config tools belong in main, imo Jun 11 08:54:20 we're after all a distro targeting mainly network devices Jun 11 08:54:34 on a quick look it seemed like it could go into packages as well Jun 11 08:55:04 also, there is VXLAN support in netifd. which is a core service. I'd say it belongs in main, not feeds Jun 11 08:58:26 after I saw that commit to enable packet_steering on ramips/mt7621 I tried uci `set network.globals.packet_steering=1` on my apu2 but I'm getting "uci: Invalid argument" Jun 11 08:58:56 don't use backticks, but quotes Jun 11 08:59:01 does this require anything specials to be able to use? Jun 11 08:59:13 adrianschmutzler: sorry, those `` are wrong Jun 11 08:59:21 I tried `uci set network.globals.packet_steering=1` Jun 11 08:59:30 there are no backticks or quotes used in the command Jun 11 08:59:42 just used `` to show that it is an executed command Jun 11 08:59:59 syntax seems correct Jun 11 09:01:16 did you do it in shell or via uci-defaults? Jun 11 09:01:37 because I can run it in shell without problem, though on a completely different target Jun 11 09:02:16 shell Jun 11 09:02:25 strace -> https://gist.github.com/stintel/294cd58813e823fd5ee19f35b840f06c Jun 11 09:02:57 tried `touch /tmp/.uci/network` and then again but same Jun 11 09:03:20 do you have a globals section in /etc/config/network ? Jun 11 09:03:38 yes Jun 11 09:03:43 I don't Jun 11 09:03:43 ok Jun 11 09:04:05 ah, didn't think of that Jun 11 09:04:13 then obviously the section needs to be created first Jun 11 09:04:31 where do we create the ula_prefix put there? Jun 11 09:05:09 https://github.com/openwrt/openwrt/blob/master/package/base-files/files/etc/uci-defaults/12_network-generate-ula Jun 11 09:05:19 ah, I always throw out that ula Jun 11 09:05:33 that explains why I don't have it Jun 11 09:05:36 there. but it also does not create the block, so where is the block coming from Jun 11 09:05:55 the ula file start with 12, so the other one is run beforehand it might still fail Jun 11 09:05:57 network.esk.ifid='50'uci: Parse error Jun 11 09:05:57 (section of different type overwrites prior section with same name) at line 17, byte 23 Jun 11 09:06:00 meh Jun 11 09:06:06 looks like my xfrm config is busted Jun 11 09:06:20 the question is, where is the globals block created? Jun 11 09:06:23 I never use uci, maybe I should Jun 11 09:06:28 yeah, good question Jun 11 09:06:51 bin/config_generate Jun 11 09:07:08 https://github.com/openwrt/openwrt/blob/master/package/base-files/files/bin/config_generate#L22 Jun 11 09:07:17 I don't see what is wrong with that ifid 50 Jun 11 09:07:20 so, did you nuke the whole block then? Jun 11 09:07:22 yes Jun 11 09:07:36 as the ula is usually the only block in it Jun 11 09:07:56 now I suspect I cannot commit the new globals section because of that ifid Jun 11 09:07:58 then you could solve your problem by keeping the block and just removing the option Jun 11 09:08:10 but if I remove that my ipsec xfrm config will not work anymore Jun 11 09:08:44 maybe that ifid is conflicting with something else Jun 11 09:09:03 cannot help you there, I have no experience with that Jun 11 09:09:42 git grep ifid on netifd.git only shows one match, XFRM related Jun 11 09:09:43 hmmm Jun 11 09:09:57 however, it's quite interesting that the setup of network.globals depends on /proc/sys/net/ipv6, so for ipv4-only setups the corresponding uci-defaults scripts will fail Jun 11 09:10:38 sounds like something that could use improving :) Jun 11 09:11:12 I will send a simple patch for that in a minute Jun 11 09:11:31 btw, the DAP-2695-A1 looks fine now, thanks for implementing my feedback Jun 11 09:12:51 adrianschmutzler: thanks. I'll add a Reviewed-by ? Jun 11 09:13:19 or Acked-by? Jun 11 09:14:10 that uci error seems to come from something else Jun 11 09:14:19 I suspect snmpd config Jun 11 09:14:34 I haven't looked at the details of the network setup, as I'm not too familiar with that rgmii/sgmii stuff, and for the fixwrgg I've just checked whether it's the same as ar71xx. but should be good enough for a Reviewed-by Jun 11 09:14:35 I can uci commit network just fine Jun 11 09:15:07 so maybe just add the review to 3/3, but not the two earlier patches Jun 11 09:15:37 alright Jun 11 09:17:42 lol, there was a /etc/config/snmpd-opkg file Jun 11 09:17:55 yeah that was it Jun 11 09:18:09 that sounds like a bug, as opkg will leave such files at will Jun 11 09:18:16 uci should probably ignore them Jun 11 09:18:56 jow: thanks for your ancer. I think if all that would be put in the PR then there would be more understanding of the push back. Jun 11 09:19:25 meh. now I still have uci: Invalid argument Jun 11 09:19:57 run set network.globals='globals' Jun 11 09:20:06 err, uci set network.globals='globals' Jun 11 09:20:11 before the other command Jun 11 09:20:15 that will create the section Jun 11 09:20:31 without the section, you cannot create an option in it Jun 11 09:20:44 I created it already Jun 11 09:20:56 ah okay, then I don't know Jun 11 09:21:05 but I guess the wrong wayu Jun 11 09:21:11 I did "uci add network globals" Jun 11 09:21:32 then you will create a section with the _type_ globals, but a random _name_ Jun 11 09:21:54 you could use uci set network.@globals[0].something=1 then Jun 11 09:22:17 if you look into your config file, you normally have Jun 11 09:22:22 never really worked with uci, I just wrote the section and the packet_steering option in /etc/config/network Jun 11 09:22:34 config globals 'globals' Jun 11 09:22:43 so, config type 'name' Jun 11 09:22:56 with your command, there will be no name, so you will create Jun 11 09:23:00 config globals Jun 11 09:23:04 in the file Jun 11 09:23:34 so you indeed will need my command, as it will set the name and the type Jun 11 09:25:25 stintel: heh, yeah, the named section vs typed thing for adding the right basic block is extremely non-obvios :) Jun 11 09:27:58 wasn't anybody working on Cisco like CLI for OpenWrt? :P Jun 11 09:31:59 adrianschmutzler: speaking of moving packages to the packages feed, a list of potential ones would be nice. Jun 11 09:33:05 stintel: which is useful to one set of people, and completley alien to everyone else :) Jun 11 09:34:51 karlp: might be, but imo it's much more userfriendly than what we have. even for noobs Jun 11 09:34:59 just hit ? and tab and you'll find what you need Jun 11 09:35:51 I find luci _massively_ easier to find things in than trying to tab complete possible trees of commands Jun 11 09:36:05 I can tab complete "ip" on desktop linux, but it's still a forest of options Jun 11 09:36:24 you're comparing a GUI with CLI now, that doesn't really work Jun 11 09:36:42 well, you said this alternative cli is noob friendly.. :) Jun 11 09:36:56 it's still a CLI Jun 11 09:37:13 ok, so how do you separate the "I'm in command mode" vs "I'm at a shell" ? Jun 11 09:37:32 because config clis like cisco et al are _only_ command mode, all the time. Jun 11 09:38:44 with a shell command to enter command mode Jun 11 09:38:57 or command mode command to enter shell mode Jun 11 09:39:04 based on what you configured that you prefer Jun 11 09:39:20 or user root -> shell, user foo -> command mode Jun 11 09:39:25 many options there Jun 11 09:40:02 i hate ip :( Jun 11 09:40:54 I've been using ip since I can't remember, I'm so used to it I don't even know if I like or dislike it Jun 11 09:41:52 * stintel goes back to PowerShell Jun 11 09:42:26 :P Jun 11 09:43:13 well part of the product we develop needs to interface with things that only have Windows SDKs. so we have 1 service running on Windows IIS Jun 11 09:43:25 I had some fun automating the deployment of that part Jun 11 09:43:30 as long as I don't need to click in GUIs Jun 11 09:53:54 stintel: powershell? heresy!!! Jun 11 09:54:42 i installed luci-proto-wireguard, is there some trick to make LuCI list "WireGuard VPN" protocol without me rebooting my device? Jun 11 09:54:46 i tried /etc/init.d/rpcd restart already Jun 11 09:59:04 mangix: it's actually quite useful. nobody in my team wants to do Windows. so I've automated basically everything. I can deploy a full Active Directory with Federation services by running an Ansible playbook Jun 11 09:59:23 team happy because no Windows clickery, management happy because we don't say "we don't do Windows" Jun 11 10:00:42 i'm joking of course. bash seems to be the orthodoxy with linux Jun 11 10:01:14 I think I've written more powershell than bash for this client :P Jun 11 10:01:19 powershell is available on linux last i remember. Jun 11 10:04:02 mangix: I was just asking for vxlan specifically in this case, I'm more of an observer for the whole "move to packages feed" discussion Jun 11 10:05:20 I wasn't there when this was discussion in the meeting, and the only committer pushing this seems to ynezz as far as I can tell Jun 11 10:05:32 I think anything that you might reasonable expect on a router has its place in the main repo Jun 11 10:05:47 that does not include fileserver or transcoding stuff or irc clients etc Jun 11 10:06:01 but things like snmpd, lldpd, upnp, ... Jun 11 10:06:08 network/management related Jun 11 10:06:56 but I understand opinions differ on the matter ;) Jun 11 10:07:04 being quite a soft definition of course, i.e. why is batman-adv in routing feed and vxlan in main repo... Jun 11 10:07:05 rmilecki: you need to restart netifd Jun 11 10:07:10 rmilecki: /etc/init.d/network restart Jun 11 10:07:23 it does not support hot (re)loading protocol handlers Jun 11 10:07:26 :D Jun 11 10:07:38 :( Jun 11 10:08:14 jow: thank you! worked ofc Jun 11 10:09:21 I guess that also flushed conntrack and hence firewall rejected the existing connection Jun 11 10:09:57 yep Jun 11 11:25:34 nbd: Packet steering on MT7621 slows down LAN->5GHz throughput. Before it was 550Mbps, now 400Mbps Jun 11 11:32:20 dengqf6: hm, interesting Jun 11 11:32:35 single connection or multiple? Jun 11 11:32:40 Single Jun 11 11:33:43 nbd: smp_affinity of mt76x2e is set to 2nd core in the script Jun 11 11:34:23 nbd: so the first handles eth0 IRQ and the second handles wifi IRQ Jun 11 11:34:54 please compare multiple connections as well Jun 11 11:35:04 packet steering doesn't really provide any benefits for single connection traffic Jun 11 11:35:54 steering has a noticeable cost, which gets amortized by being able to process traffic on multiple cores Jun 11 11:35:55 nbd: Did you see pr 2974? Jun 11 11:36:12 but a single connection cannot be processed on multiple cores Jun 11 11:36:15 not yet Jun 11 11:45:32 nbd: iperf3 lan to 5ghz result Jun 11 11:45:47 without steering: 1 connection: 545Mbps Jun 11 11:45:59 5 connections: 500Mbps Jun 11 11:46:13 with steering: 1 connection: 401Mbps Jun 11 11:46:23 5 connections: 480Mbps Jun 11 11:50:56 i'll run some more tests to see if i can avoid that overhead somehow Jun 11 12:22:33 adrianschmutzler: commit 108df3eabbb4dd93ff3c616c9455d69daaa98b49 talks about telnet, i think the author just copy/pasted the wiki entry about installation... Jun 11 13:00:40 Borromini: indeed. probably because it already was supported in ar71xx Jun 11 13:02:33 Borromini: I think so, too. Jun 11 13:29:13 these devices are 100% clones apart from a board id, so I didn't push too hard for that PR... Jun 11 14:48:36 I just learned about https://patchwork.readthedocs.io/en/latest/usage/headers/ Jun 11 14:49:48 wonder if we can use "X-Patchwork-State: Accepted" in the patchwork-apply.sh script which generates the reply using git send-email Jun 11 14:50:21 to avoid an extra pwclient call Jun 11 14:59:07 /home/dwmw2/git/lede/master/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/image/bpi_bananapi-r2-uEnv.txt: No such file or directory Jun 11 14:59:07 ] Jun 11 14:59:13 Hm... what was supposed to put that there? :) Jun 11 15:08:32 * dwmw2_gone makes something put that there Jun 11 15:18:37 build #160 of bcm27xx/bcm2711 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2711/builds/160 **** ENDING LOGGING AT Fri Jun 12 02:59:58 2020