**** BEGIN LOGGING AT Mon Feb 18 02:59:56 2019 Feb 18 05:07:24 morning Feb 18 05:07:56 jow: would you find a minute to look at https://forum.openwrt.org/t/wan-to-lan-wired-throughput-using-iperf/31349/7 ? i'm curious about that one Feb 18 05:56:21 rmilecki: did you just add that config manually? Feb 18 05:56:34 rmilecki: editing the /etc/config/firewall file? Feb 18 05:56:40 SwedeMike: i'm not thread author Feb 18 05:57:32 i was just curious what could cause 2 different NAT speeds (depending on the direction) Feb 18 05:57:41 if there is sth wrong with the user's rule Feb 18 05:57:48 or maybe sth wrong in fw3 or sth Feb 18 06:04:50 I'm thinking that when he added that rule then things stopped going through the flowoffload code path, perhaps conntrack didn't get enabled for that traffic or -j FLOWOFFLOAD wasn't added to the rule in iptables. Feb 18 06:18:37 ;;;;;;;;;;;;;;;;;;;;;;;p[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[p;.l''''''''''''..........................-;';; R;2~Pкк,'-1ч'.?----------------------------------------------------------------------------- Feb 18 06:19:00 Feb 18 06:19:37 mmmmmm, ,. mmmmmmv-+ Feb 18 08:53:23 SwedeMike: i ddin't think about that. interesting Feb 18 08:53:32 SwedeMike: sounds like a possible reason Feb 18 15:39:03 Hello everybody, I've found a serious issue regarding MTU and WDS, issue tracker ID 2101. Feb 18 15:39:21 Does anyone had a similar experience? Feb 18 16:22:16 beEnry: if 2000 with no-frag doesn't work then 1473+20 won't work either. Feb 18 16:22:54 beEnry: your "cliff" is at 1492 total for PC1. I don't know why, but you should figure out why it works from PC2 and not from PC1 Feb 18 16:23:21 ie what's the difference between Ping from PC1 to 1.1.1.1 with 2000 packet size and fragmentation allowed = failure and Ping from PC2 to 1.1.1.1 with 2000 packet size and fragmentation allowed = success Feb 18 16:29:00 beEnry: you never stated what the difference between PC1 and PC2 was. Feb 18 16:30:12 beEnry: it would also help if you provided a tcpdump on LAN and WAN for when it works and doesn't, it' easier to figure out where the packet is dropped then. Feb 18 16:30:57 beEnry: then you'd be able to see what packet sizes are for the different cases and whether you're dropping the packets egress or ingress. Feb 18 16:38:36 SwedeMike: PC1 and PC2 are both the same. Even the same notebook used with ethernet port as PC1 and with the wlan card as PC2. Both NIC set at 1500MTU Feb 18 16:40:30 SwedeMike: I alreay one the trace with tcpdump but no particular thing happened. Capturing on R7800 resulted in some missed packets. Feb 18 16:41:21 SwedeMike: also the difference between Ping from PC1 to 1.1.1.1 with 2000 packet size and fragmentation allowed = failure and Ping from PC2 to 1.1.1.1 with 2000 packet size and fragmentation allowed = success is: none :) Feb 18 16:42:02 from PC1 it times out, from PC2 is fine. Feb 18 16:42:19 I think this is a fragmentation problem that only happens with WDS connection. Feb 18 16:43:14 As I recently added to the issue tracker, using the same PC1 but using its wlan0 card connecting on the 5Ghz AP but not using the WDS option lead to perfectly fine fragmentation as I'm able to ping anything on WAN side with >1500byte size Feb 18 16:45:36 beEnry: is this WDS domain purely bridged, or how does it work? Feb 18 16:48:02 can PC1 ping PC2 with 2000 byte packets and fragmentation allowed? Feb 18 16:48:52 if this WDS thing isn't just L2 switching then I'd first check if the ICMP NEED-TO-FRAG packets are getting lost or if PC1 is receiving them properly. Feb 18 16:49:53 when it tries to ping to 1.1.1.1 with 2000 byte packets then it will send one 1500 byte packet and then one ~550 byte packet, then there should be ICMP NEED-TO-FRAG = 1492 message, and PC1 will re-send now with a 1492 + ~560 byte packet Feb 18 16:49:55 SwedeMike: pure L2 bridge Feb 18 16:50:07 so this is what you need to figure out, does this work properly or not. Feb 18 16:50:21 but the problem is when from local subnet PC1 i want to reach internet at L3 Feb 18 16:50:40 so you need to figure out where the packets are lost and which ones are lost Feb 18 16:51:20 The router has the pppoe at 1492, it just fragment the packets correctly from the other clients Feb 18 16:51:41 The issue happens only from ethernet clients behind the WDS station Feb 18 16:51:53 The entire rest of the LAN has not a single issue Feb 18 16:53:04 well, backing up that claim with actual tcpdump output pointing to "here is where the packet comes in and here it's not sent out" would exactly pinpoint the issue. Feb 18 16:53:14 now you're inferring from the observed behaviour at a higher level Feb 18 16:53:33 doesn't sound like a development issue :D Feb 18 16:56:43 I'm sorry, this isn't in fact a development issue. This is a serious issue with "something" and the issue tracker doesn't really seems populated nor active at all so I came here for help. Feb 18 16:57:55 Anyway, I 'll try when I'll arrive at home some tcpdump. Do you know any better place to talk about this issue? Feb 18 17:40:42 Is it possible to choose the order in which network interfaces come up? I'd like the 6in4 interface to come up before the Wireguard interface Feb 18 19:55:49 stintel: ping Feb 18 19:57:24 Strykar: they come up in the dependency order, or should do Feb 18 19:57:34 does wg depend on 6in4 being up? (and if so whyyyyyyy?) Feb 18 20:00:16 Borromini: pang Feb 18 20:02:21 stintel: your aim needs some work :^) Feb 18 20:02:34 my targets disagree ;) Feb 18 20:02:38 stintel: is jow the only one with access to the infra? i saw you say he was on holiday till next week Feb 18 20:02:54 and there seems to be something wonky with the server(s) hosting the git repo Feb 18 20:03:07 Borromini: no, I have access to some of it, and some others as well Feb 18 20:04:12 define wonky Feb 18 20:04:34 stintel: check all the staging trees that disappeared overight Feb 18 20:04:40 s/ight/night/ Feb 18 20:04:48 like xback's for example Feb 18 20:04:58 and at one point there was just hauke's Feb 18 20:05:03 https://git.openwrt.org/?p=openwrt/staging/xback.git;a=summary ? Feb 18 20:05:05 and someone elses Feb 18 20:05:15 yeah that's a 404 here mate Feb 18 20:05:18 heh Feb 18 20:05:20 works for me Feb 18 20:05:25 shift ctrl r? Feb 18 20:05:32 same Feb 18 20:05:37 well it is very dead here Feb 18 20:05:56 and i'm not the only one not seeing half of the staging trees Feb 18 20:05:59 nbd's: gone atm Feb 18 20:05:59 Borromini: throw output of `host git.openwrt.org` in /q Feb 18 20:06:15 I'm seeing that just fine as well Feb 18 20:15:08 stintel: Borromini I am also getting a 404 with IPv4 and ipv6 Feb 18 20:15:42 from my server it works Feb 18 20:18:04 https://git.openwrt.org/?p=openwrt/staging/xback.git;a=summary works for me over IPv6. Feb 18 20:19:29 but the most recent activity is 3 days ago Feb 18 20:33:57 Borromini: Hauke retry ? Feb 18 20:35:18 stintel: looks fixed on my end, thanks Feb 18 20:35:21 everything back Feb 18 20:35:28 there are 2 backens in haproxy Feb 18 20:35:34 I just disabled one of them Feb 18 20:36:02 ok Feb 18 20:36:13 i probably happened to be on the crippled backend then Feb 18 20:36:54 stintel: thanks, I am still having problems with cloning over the git protocol Feb 18 20:37:40 Hauke: retry ? Feb 18 20:39:29 * Borromini didn't try a clone just a web ui refresh Feb 18 20:40:08 stintel: now it works, but it takes long git@git.openwrt.org takes very long Feb 18 20:40:38 for the others I am using git://git.openwrt.org Feb 18 20:41:33 yeah I fucked up because someone put debian testing in fucking sources.list and I missed it and I saw that the machine is running a kernel from january 2018 so I deciced to apt-get upgrade and now the box is running fucking testing Feb 18 20:41:37 not amused Feb 18 20:42:36 lol Feb 18 20:42:45 debian testing should get stable in some months ;-) Feb 18 20:42:55 As such, the transition freeze of Debian 10 is planned on January 12, 2019, with Buster's soft-freeze scheduled for February 12. Feb 18 20:42:57 aight Feb 18 20:43:08 not that bad then Feb 18 20:44:13 Hauke: hehe Feb 18 20:44:46 stintel: if it helps, i've been on testing for over a month now and it's hunky dory Feb 18 20:44:52 for me at least. Feb 18 20:45:15 not using haproxy though :) Feb 18 20:45:15 I am also on testing, my server is still on debian 8, I should really upgrade Feb 18 20:46:39 I'm feeling bad because my infra is still on 4.14.78 Feb 18 20:47:02 can you imagine how I felt when I saw 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux Feb 18 20:47:30 my server is on 3.16.0-7-amd64 Feb 18 20:47:50 debian stable is on 4.9 Feb 18 20:48:30 i am running an arm flavour of debian on my odroid and the maintainer happily pushes 4.14 bumps (partially because hardkernel did the heavy lifting of course) Feb 18 20:48:44 the only hardware here still on debian 9 :^) Feb 18 20:48:59 Borromini: pfft hardkernel. you want vanilla u-boot and vanilla kernel (see meson branch in my staging tree) Feb 18 20:49:35 I'm waiting until after 19.01 (19.03?) branching Feb 18 20:49:39 to push that to master Feb 18 20:49:50 because I don't want to add a target that will not be supported due to 4.19 kernel only Feb 18 20:50:07 you got odroid support? Feb 18 20:50:15 Linux owrtdroidc2 4.19.20 #0 SMP Sat Feb 9 19:26:24 2019 aarch64 GNU/Linux Feb 18 20:50:17 sure Feb 18 20:50:17 i've seen your meson tree but no clue what it was :( Feb 18 20:50:20 that's fancy. Feb 18 20:50:51 have a razberry module on it (:P), running domoticz, and a ccs811 censor Feb 18 20:50:51 can i just replace my uboot from within debian? Feb 18 20:50:53 sensor* Feb 18 20:50:57 neat Feb 18 20:51:13 u-boot is on the uSD Feb 18 20:51:26 so if you build an image from my branch "it just works" Feb 18 20:51:31 ok Feb 18 20:51:38 i'd like to stick with debian though :( Feb 18 20:51:40 * Borromini hides Feb 18 20:51:47 haha no worries Feb 18 20:52:20 wow, Odroid-C2 running OpenWrt could be cool. Feb 18 20:52:33 it looks like hardkernel isn't providing a 4.19 bump Feb 18 20:52:53 when can I expect OpenWrt for xu4? :) Feb 18 20:52:59 :D Feb 18 20:54:03 Pepe: https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/meson Feb 18 20:54:04 ah Feb 18 20:54:06 it's not on 4.19 yet Feb 18 20:54:16 I'll just push my WIP to it Feb 18 20:55:05 ok so git-01 reverse-proxies to itself and git-02 Feb 18 20:55:09 I don't have access to git-02 Feb 18 20:55:23 so I've disabled the git-02 backend for http and git proto Feb 18 20:56:40 thanks Feb 18 20:57:08 now let's see if I can fix that slowness Feb 18 20:58:39 Hauke: can you retry that ? Feb 18 20:58:54 I think I fixed it Feb 18 20:59:22 systemctl daemon-reexec && hide Feb 18 20:59:33 when in doubt, kill systemd ;-) Feb 18 21:00:01 the root of all evil! Feb 18 21:00:40 amen Feb 18 21:06:24 Pepe: you can now build an image for odroid-c2 with 4.19 kernel, working HDMI, vanilla u-boot, ... from https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/meson Feb 18 21:06:34 night gents and thanks for the help stintel. Feb 18 21:06:36 enjoy the beers Feb 18 21:06:40 stintel: ty Feb 18 21:06:41 njama problem Feb 18 21:06:55 s/jama/o/ Feb 18 21:07:03 sorry, get carried away with Bulgarian sometimes Feb 18 21:07:03 is that hungarian Feb 18 21:07:05 k Feb 18 21:07:12 njema problema eh Feb 18 21:11:53 stintel: yes it is fast again Feb 18 21:13:23 Hauke: thanks for testing Feb 18 21:14:00 * ldir leaves this here https://www.youtube.com/watch?v=o_AIw9bGogo - a different perspective Feb 18 21:18:17 and when you take a service point of view of things, there's more than one occasion where we hear 'how do I make x depend on y on startup' in openwrt. I'm not suggesting usystemd...well not yet anyway. Feb 18 21:19:20 * ldir waits for the ban :-) Feb 18 21:29:04 Btw, I'm curious, but why in OpenWrt 18.06 isn't Python 3.6.8, but there is 3.6.5 and patched? It must be a hell to maintain it with those backports, and so on. Feb 18 21:34:01 Pepe: once a release branch is made, versions are supposed to be frozen Feb 18 21:35:01 unless a project guarantees that patch versions maintain full compatibility, staying at the exact same version is probably safer Feb 18 22:26:29 ldir: I'd be rather curious to actually see a proof of concept for systemd+networkd+iwd, I don't think it would be able to compete (certainly not on size (I don't think you'd be able to get that into less than 32 MB), but hardware is getting better, so, maybe, one day) - but it would be interesting to see and test. Feb 18 22:28:58 pkgadd: https://github.com/jdub/openwrt-systemd (not mine) ;) Feb 18 22:29:37 probably can be done on 16MB + extroot Feb 18 22:32:35 KanjiMonster: thanks, interesting Feb 19 02:08:48 jwh, where can I edit the order? and no, wg doesn't depend on 6in4 being up. quite the opp actually, since I route all traffic via a GCP wg install, openwrt sends the 6in4 traffic there too and the interface never comes up. if I start the 6in4 interface before wg, it works as expected. ipv6 via wan and the ipv4 via wg **** ENDING LOGGING AT Tue Feb 19 02:59:57 2019