**** BEGIN LOGGING AT Tue Apr 09 03:00:03 2019 Apr 09 03:01:03 hllo Apr 09 03:22:20 just switched build options from 4.14 to 4.19 for x86, hitting this error, any idea how to fix? Apr 09 03:22:21 Package kmod-br-netfilter is missing dependencies for the following libraries: Apr 09 03:22:21 bridge.ko Apr 09 03:22:37 ./build_dir/target-x86_64_musl/linux-x86_64/linux-4.19.34/net/bridge/bridge.ko exists Apr 09 03:24:38 nyt: sounds like a makefile problem Apr 09 03:29:28 so any idea on how to fix? Apr 09 03:36:32 add +kmod-something to dependencies mayube Apr 09 03:37:02 there is no kmod-bridge package Apr 09 03:37:16 guess you'll have to create Apr 09 03:37:36 this was working find recently, not sure if it was from changing kernel or merging in the latest master Apr 09 03:43:28 jeffsf: dude, your connection... Apr 09 03:44:00 and the dependencies seem auto generated for kmod-br-netfilter Apr 09 04:13:47 ldir: what about the dmesg line from ar71xx? Apr 09 04:30:28 compiles fine with 4.14, not 4.19 :/ stupid bridge error Apr 09 04:39:52 not sure where that's coming from even :/ Apr 09 04:59:50 Hi, I'm trying to use uhttpd's key/cert for another application, from my understanding the cert is in DER format, so I converted it to PEM so I can supply it to a format the new application understands (while keeping the original for uhttpd's use) Apr 09 05:00:21 only the cert is in DER, the key in my understanding is in PEM format already Apr 09 05:01:43 however I get SSL/handshake error (thats the actual error, nothing specified) Apr 09 05:02:48 the application I'm trying to use is AriaNG which is a webui to control aria2c. I simply put the folder in /www/ariang, I can access and control aria2 fine (if I access router with http, disable https redirect) Apr 09 05:03:30 once https redirect is enabled, ariang loses access, hence why I'm trying to supply the cert/key in the right format so I can use https Apr 09 06:13:21 aparcar[m]: correct, already replied Apr 09 07:04:53 rmilecki: morning :-). [ 0.095685] Performance counters: mips/74K PMU enabled, 4 32-bit counters available to each CPU, irq 13 Apr 09 07:12:42 ldir: ok, we probably have all basic info collected now, but I don't know how IRQs work on Atheros platform, e.g. does it have only 8 hardware IRQs or more? Apr 09 07:13:02 ldir: the problem is perf has IRQ 13 assigned for both: ar71xx & ath79 Apr 09 07:13:22 ldir: with ath79 however that IRQ is already used by ehci_hcd:usb1 Apr 09 07:13:36 ldir: with ar71xx ehci_hcd:usb1 was using IRQ 48 (a software IRQ?) Apr 09 07:14:06 blogic: can you see my above messages and https://pastebin.com/Q4TqExwK please? do you know anyone we can ping about that IRQs issue? Apr 09 07:14:25 ? Apr 09 07:14:39 dynamic irq mapping issue ? Apr 09 07:14:57 on ath79 irq numbers are virtual Apr 09 07:15:39 so the perf irq needs to be mapped to misc controller line 5 Apr 09 07:15:43 blogic: any idea how to fix that? Apr 09 07:15:58 which kernel version is this ? Apr 09 07:16:00 v4.19 ? Apr 09 07:16:14 ldir: ^^ Apr 09 07:16:20 v4.14 Apr 09 07:18:30 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/mips/ath79/setup.c?h=v4.14.111#n186 Apr 09 07:18:39 that function needs to be ofified Apr 09 07:19:41 probably easiest would be to just extend the miscint code to register the irq and export it via the function inside setup.c Apr 09 07:20:47 let me think for a sec Apr 09 07:23:27 I thought that the perf counter interrupt was a fixed number internal to cpu (13) so how to stop it being claimed for other things? Apr 09 07:23:42 its not Apr 09 07:23:49 so mips has 7 irqs Apr 09 07:23:59 no 8 Apr 09 07:24:02 these are 0-7 Apr 09 07:24:18 then there are external irq controllers attched to these line Apr 09 07:25:03 so perf is on mis(5) Apr 09 07:25:13 and misc is on mips(6) ? Apr 09 07:26:08 on old kernels these had fixed offsets Apr 09 07:26:20 but with OF we use irq_domains with dynamic number allocation Apr 09 07:26:41 people smarter than us decided that this is how its done so dont ask me why Apr 09 07:27:00 * ldir head hurts and it's before breakfast Apr 09 07:27:22 there seems to be now fixed way to do this Apr 09 07:27:28 erm, how urgent is this ? Apr 09 07:27:48 blogic: not urgent for me, I was just helping ldir Apr 09 07:28:34 ahhh Apr 09 07:28:47 amazingly i apparently had this on ralink beofre and its fixed there Apr 09 07:28:48 indeed not urgent - it would be 'nice' if stuff that worked on ar71xx worked in ath79 - and I'm feeling left out of the 'playing with perf' gang :-) Apr 09 07:29:00 /* tell the kernel which irq is used for performance monitoring */ Apr 09 07:29:03 rt_perfcount_irq = irq_create_mapping(domain, 9); Apr 09 07:29:08 :) Apr 09 07:29:25 ldir: i'll fire up an ath79 kernel thgis week and port the fix over Apr 09 07:29:32 today is just a bad day for that Apr 09 07:30:10 np and thanks - I have a *collection* of bad days Apr 09 07:30:15 * ldir hunts breakfast Apr 09 07:34:12 blogic: thanks for looking at that! Apr 09 07:36:19 ah ok Apr 09 07:36:23 -EWIN Apr 09 08:01:20 jeffsf_: may, fix your client or Internet connection, you're reconnecting every minute Apr 09 08:01:43 jeffsf_: *man Apr 09 08:02:10 and my client is too stupid to hide (dis)connect notification after /ignore jeffsf :( Apr 09 08:47:10 nbd: did you even see something like this? Apr 09 08:47:18 > ~/openwrt/FlameGraph/stackcollapse-perf.pl ./wan-to-lan.data --all 2>&1 | head Apr 09 08:47:25 Unrecognized line: PERFILE2h�h��('��=p����hX��������?�����[kernel.kallsyms]_stexth�����@/lib/modules/4.14.108/bcma-hcd.koh������@/lib/modules/4.14.108/usb-common.koh������@/lib/modules/4 Apr 09 08:48:21 oh, nevermind, I forgot the "perf script" step Apr 09 09:07:13 * blogic just got reminded why quilt edit is better than quilt add / vi Apr 09 09:07:59 is there such a command? ;) Apr 09 09:09:16 how do you get the number of jobs the root make is being run with? Not the -j arugment, I mean the number Apr 09 09:14:34 I have a build that won't respect -jx and insists upon an integer being passed to JOBS=x :( Apr 09 09:17:00 dansan: OpenWrt's Makefile has a notice to run without -j if compilation fails Apr 09 09:17:06 dansan: i don't know exact message or code Apr 09 09:17:28 dansan: make OpenWrt fail to compile, try to copmile it, check the notice message, grep for it in the OpenWrt sources Apr 09 09:17:31 rmilecki: Well I don't want to run the build with only one job, that would take forever Apr 09 09:17:35 you should see how OpenWrt handles that Apr 09 09:18:17 I can't even use Build/Compile/Default because the stupid build breaks on any -j or --jobserver Apr 09 09:18:26 does anyone mind if we kick out jeffsf for now? Apr 09 09:18:37 rmilecki: Please do! Apr 09 09:18:41 ..faster than trying -jx and forever failing... and with j1 (or no j) makes also log readable Apr 09 09:18:55 I tried adding him to ignore, but the message still comes through Apr 09 09:19:51 olmari: it's not faster than it not build, that's a different metric. Besides, it's stupid to not be able to get that :( Apr 09 09:20:12 /home/daniel/proj/embedded/openwrt/gse/build_dir/target-mipsel_24kc_musl/OpenJDK-8-u202//make/Main.gmk:80: *** make -j is not supported, use make JOBS=n. Stop. Apr 09 09:20:29 Stupid Oracle Apr 09 09:20:34 [Notice] -ChanServ- You are not authorized to (de)op rmilecki on #openwrt-devel. Apr 09 09:20:36 oh Apr 09 09:20:42 aww :( Apr 09 09:21:19 irc... one has ignore for example joins, parts, quites too... conbine with nick properly and there's your rule :) Apr 09 09:21:30 great. #openwrt-devel is still owned by Kaloz Apr 09 09:21:45 Maybe I should just make JOBS=`$$$$((RANDOM % 15))` Apr 09 09:21:57 :) Apr 09 09:22:38 dansan: i think I misunderstood your question, I thought you want to know how Makefile can known the -j argument value Apr 09 09:22:40 sorry Apr 09 09:22:51 Oh Apr 09 09:23:10 I need to pass it to a make process, but I can't use the standard mechanism :( Apr 09 09:23:51 I kind of hope I never get OpenJDK into any repos because it's big and ugly, but I did get it to build and work on mipsel w/ musl Apr 09 09:25:09 olmari: yeah, I gotta find that in Konversation... Apr 09 09:27:01 On that off-topic note: I personally have moved to Matrix "solely", it has good bridging to most other IM-networks, including irc :) but yeah =) Apr 09 09:27:37 olmari: I'm considering changing after 10 years of Konversation Apr 09 09:28:27 dansan: you should probably use JOBS=$(subst -j,,$(PKG_JOBS)) Apr 09 09:29:03 ynezz: thanks for that! :) I'm not that fluent in make Apr 09 09:30:33 ynezz: darn, PKG_JOBS is expanding to -jobserver-auth=3,4 instead of a -j number Apr 09 09:31:01 ah Apr 09 09:31:20 For some reason I thought it was using -j before Apr 09 09:31:37 jow: are you added to ChanServ for #openwrt-devel? Apr 09 09:31:48 jow: can you try /msg chanserv op #openwrt-devel rmilecki Apr 09 09:35:03 ynezz: That's just what happens when some company decides that *their* way is better than what the entire FOSS community has adopted. oh well Apr 09 09:35:36 maybe I can hack their .m4 files and get rid of it Apr 09 09:35:41 thanks for the help Apr 09 09:50:07 gch981213: BTW I've just got an email in private about this commit https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9fc506e9b2e40db8f3a6df5b59556e59351e376f Apr 09 09:50:58 gch981213: it seems to cause performance issues https://forum.openwrt.org/t/netgear-r7800-exploration-ipq8065-qca9984/285/1565 Apr 09 10:02:50 these pkg_mirror_hash vs pkg_hash is the gift that keeps giving. Apr 09 10:08:23 ynezz: I'd assume it's caused by this one: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d6366ce3665f010a7ae7061a557689643073040a Apr 09 10:18:41 [Tue 2019-04-09 02:21:28 AM PDT] great. #openwrt-devel is still owned by Kaloz <------- yes, but wigyori is op Apr 09 10:18:56 i'll try to sort it out later Apr 09 10:18:58 thanks DonkeyHotei Apr 09 10:32:24 gch981213: I would understand the regression on ipq806x, but it's causing 10.29% kworker load on Archer c7v4 as well Apr 09 10:34:16 karlp: there have to be easy things for idiots like me to fix - low hanging fruit is how we trap new people into maintaining stuff ;-) Apr 09 10:37:07 ynezz: polling mib counters is a ton of mdio operations. there are 39 fields for every port, each field contains at least 1 byte, each register reading is done by 4 mdio commands. Consider that commit changes the behavior from polling mib for 1 port to polling for all 7 ports I won't be surprised there is a CPU load increase. Apr 09 10:38:48 * gch981213 feels bad about his commits causing several bugs so far, though :( Apr 09 10:42:21 gch981213: just add yourself to the long & distinguished line of people who have done the same ;-) Apr 09 10:42:48 yeah, no worries, that's development snapshot, we just need to find some proper fix for this regression Apr 09 10:48:03 gch981213: I'm just wondering what would be the proper fix, though, maybe increasing the qca,mib-poll-interval ? Apr 09 10:49:06 Does it need to be polled one byte at the time, or could you poll it more bulk and then parse it (ought that even help the overall cpu usage) Apr 09 10:49:34 ynezz: I'm going to suggest exactly that. Apr 09 10:49:51 * gch981213 is unable to open GitHub for some unknown reason Apr 09 10:51:59 great firewall? :) Apr 09 10:52:25 on ipq80xx that interval should be 2s as per #define AR8XXX_MIB_WORK_DELAY 2000 /* msecs */ Apr 09 10:52:28 right? Apr 09 10:53:13 ynezz: yes. Apr 09 10:53:31 is there an ETA to the release branch yet? asking because PR 1359 was still NAK'ed for complexity Apr 09 10:54:16 or rather ar71xx interested reviewer :) Apr 09 10:54:54 yes, well, exposure is an issue for that Apr 09 10:55:07 ynezz: AR8XXX_MIB_WORK_DELAY in ar8216.c defined the default polling interval. I wonder if changing that to at least 12000 can fix the problem. Apr 09 10:55:45 wasn't ar71xx meant to be phased out? not that there couldn't/shouldn't be fixes Apr 09 10:56:13 olmari: word is the upcoming branch will be its last Apr 09 10:59:04 gch981213: is there any reason to not have it 30/60s by default, it could be set to lower value with `qca,mib-poll-interval` if desired Apr 09 11:01:49 ynezz: No idea about that. Apr 09 11:02:23 what's drawback of using lower update mib rate? Apr 09 11:03:33 ynezz: Possible counter overflow, I think. Apr 09 11:03:52 DonkeyHotei: afaik there is no ETA. Apr 09 11:04:01 ynezz: I don't think that's harmful. Apr 09 11:04:14 rmilecki: did you test GRO (HWLRO) also with +5.0 kernel on your mt7621 target? I think mt7621 also should support LRO but is currently not enabled. Apr 09 11:05:03 Rene__: no, I was experimenting with kernel 5.0+ on bcm53xx only Apr 09 11:05:14 Rene__: didn't mess with ramips/ar71xx so much Apr 09 11:05:30 gch981213: yeah, but the default settings should be probably tuned for majority of the use cases, so I would prefer to have higher update rates by default Apr 09 11:06:31 gch981213: it seems like the device-tree is too static (would need reflashing in order to change this value) for this purpose as well, maybe some sysfs variable would be more appropriate? Apr 09 11:07:54 rmilecki: ok Apr 09 11:12:25 ynezz: That's possible. But ar8216 doesn't have anything related to sysfs so that'll be a lot of work. Apr 09 11:38:35 ynezz: After some calculation I found out that mib counters won't overflow in 1 minute even if the port is under full 1000Mbps load. Apr 09 11:44:56 i think one of the main issues is the fact that there are simply too many MIB counters that almost nobody needs Apr 09 11:45:28 and i think the use of the mib counters should be opt-in Apr 09 11:46:10 so maybe add a separate mib counter enable variable that can be controlled Apr 09 11:46:17 and group mib counters Apr 09 11:46:33 so you could configure the mib counter polling to none, basic and extended Apr 09 11:47:20 basic could cover just simple rx/tx packet/bytes counters Apr 09 11:52:49 nbd: how this settings should be controlled? it makes no sense to me to have this tweaked through device-tree as it's too static, so perhaps only sysfs? Apr 09 11:53:03 nbd: That's a good idea. Apr 09 11:53:07 i'd suggest swconfig Apr 09 11:53:30 just add a global attribute for it Apr 09 11:53:45 but isn't swconfig being slowly deprecated by dsa ? Apr 09 11:54:15 yeah, but if i didn't misread the context, we're talking about modifications to a swconfig driver here Apr 09 11:54:57 ah, correct Apr 09 12:07:10 ynezz: I could implement what nbd just suggested the day after tomorrow if it isn't urgent. Is that OK? Apr 09 12:08:41 nbd: BTW, how should the swconfig interface look like, `swconfig dev switch0 set mib_counters_enable [0-2]` (0=disable, 1=basic, 2=full) ? swconfig dev switch0 set mib_update_interval ? Apr 09 12:09:27 or perhaps use mib-poll-interval, so `swconfig dev switch0 set mib_poll_interval ` Apr 09 12:11:11 gch981213: sounds like a plan (BTW I don't think, that this is urgent) Apr 09 12:14:32 meanwhile Rickard (shelterx) has created an issue for this FS#2230 as requested Apr 09 12:50:01 anyone here with some gstreamer experience? Apr 09 12:54:41 ynezz: port status polling on ar82/3xx is broken Apr 09 12:55:04 its a silicon level bug that will make the fabric hang for 200ms and make the switch bursty and loos throughout Apr 09 12:55:17 ynezz: does that sound like what you observe ? Apr 09 12:55:28 ynezz: can be tested with iperf3 Apr 09 13:14:59 blogic: I didn't experienced it myself while testing, it was reported in a private email first then in FS#2230, but rather as an issue with 100% cpu spikes of kworker thread every 2 seconds in latest snapshots in comparison to 18.06.2 release images Apr 09 13:16:23 ynezz: could have been that Apr 09 13:16:36 basically the port state stuff locks the switch somehow Apr 09 13:16:43 i recall that having been a problem in the past Apr 09 13:18:42 this new information makes me wonder if the swconfig changes for mib counters opt-in are worth the effort Apr 09 13:19:32 why adding support for something which might not work as expected anyway and could cause confusion Apr 09 13:22:17 potentionally this could lead to a new wave of "I've enabled mib counters and the performance suffers, please fix it" bug reports Apr 09 13:22:19 ynezz blogic: I think that should happen in ar8xxx_mib_capture, which we are always calling every 2s since 7 years ago. Apr 09 14:28:21 * ldir needs head examining - sent 3 patches to kernel maintainers - waits for feedback - hopes it isn't 'can you completely re-write with a bit more blue this time' Apr 09 14:29:46 you could reply that you're colorblind ;) Apr 09 14:31:20 * ldir is not google/redhat/big $$$ corporation paying to get features in but rather a semi-literate unpaid lone wolf idiot with an idea and not much ability to code. Apr 09 14:36:55 https://lore.kernel.org/netfilter-devel/FEBDDE5A-DC07-4E41-84B3-C5033EB20CCE@darbyshire-bryant.me.uk/T/#u Apr 09 14:38:58 and the other one https://lore.kernel.org/netdev/20190409113315.64132-1-ldir@darbyshire-bryant.me.uk/ Apr 09 14:45:57 and this (well a backport variation of the tc action) has been running for weeks on my archer - works a treat! Apr 09 16:38:46 impossible question to answer I suspect but what are the advantages of (for the same device) ath79 vs. ar71xx ? Apr 09 16:43:42 I can't seem to rebuild/compile wpa-supplicant as a package (with make package/wpa-supplicant/compile) despite it being selected and built by make Apr 09 16:44:06 I can run it for other packages such as make package/hostapd/compile Apr 09 16:44:48 Is wpa-supplicant built using a different name - any help appeciated Apr 09 16:45:17 pierz: do you have wpad selected? It is hostapd and wpa-supplicant combined Apr 09 16:45:44 No - just wpa-supplicant Apr 09 16:46:21 I have hostapd selected Apr 09 16:47:16 It seems that some packages can't be built using make packages command - I also tried it for hostap-utils and it fails with the same error (make[1]: *** No rule to make target `package/hostapd-utils/compile'. Stop.) Apr 09 16:47:40 Yet these packages have all been built when I run 'make' Apr 09 17:36:38 ldir: kind of sneaky answer, but that "the ath79 images will remain for the 20.x.0 releases, while ar71xx is scheduled to be dropped" ;) and ath79 is slowly/ partially being mainlined, so it gets more eyes on it Apr 09 18:09:59 so that's annjoying, building 4.19 with x86 keeps setting bridge to module instead of yes Apr 09 18:10:06 kernel_menuconfig rather Apr 09 18:12:08 ah ipv6 was set to m which forced bridge to m Apr 09 18:12:09 nm Apr 09 18:13:01 are we already discussing 20.x? :P Apr 09 18:13:15 what's holding up 19.0x? ^_^ Apr 09 18:15:46 Development never stops, even if next-stable has some issue ;) Apr 09 18:18:27 true enough Apr 09 19:39:59 is there any real differene between `opkg install` and `opkg update`? It seems to me that if a package is upgradeable, `install` will also perform an upgrade Apr 09 19:45:23 pkgadd: the question behind the question (as ever..it is *me* after all) is I've fallen over a regression whereby perf counters on the Archer c7 don't work on ath79 (yet) but they do on ar71xx - and I wondered what else was worse under ath79 Apr 09 19:46:50 I'm not really missing anything on ath79, but admitted, I've shifted my most active devices to ipq806x/ ipq40xx Apr 09 19:50:53 i have no ath79 in production myself, but the master builds i test are ath79 and not ar71xx anymore. all my devices are fully ported afaict Apr 09 19:51:46 tl-wdr3600 and tl-wdr4300 are still in use, just no longer in most active capacity (WDS AP/ repeater) Apr 09 19:52:08 ...and as clod standby Apr 09 19:52:12 cold* Apr 09 19:52:58 I'm just musing/thinking/pondering out loud. Apr 09 20:16:17 anyone notice that 4.19 is using nf_conntrack_tcp_timeout_max_retrans instead of nf_conntrack_tcp_timeout_established for established connections/ Apr 09 20:16:19 quite annoying Apr 09 20:26:54 just went from 4.14 to 4.19 and got hit with that fun Apr 09 20:28:03 Hi ldir I dont see any dif from changing my c7 to ath79 from ar71xx Apr 09 20:28:32 all seems the same Apr 09 20:32:53 I think I was probably one of the first lunatics to switch to ath79 as soon as blogic put the relevant DTS commit in, brave/stupid enough to try a sysupgrade -F (force!) - it is near identical in behaviour except for perf support which I discovered was missing a few months ago. Apr 09 20:34:30 it has exercised the paranoia muscle in terms of wondering if there's anything else different. Apr 09 20:37:19 I'm sure blogic will fix it in a week or so and at that point I'll stop 'pondering/wondering' :-) Apr 09 20:39:03 lol Apr 09 20:39:50 ldir how you doing any way dude? Apr 09 20:43:08 I'm sorta ok. Work has been a bit quiet of late but I'm just about to go into a 2.5 week solid run! Helps with cash flow and paying the mortgage. Apr 09 20:44:59 knackered now, so off to bed Apr 09 20:51:01 ldir: just toying with perf on ath79 now, what doesn't work for you ? Apr 09 20:56:47 ynezz: perf top - doesn't work due to the fact it can't claim the perf interrupt. https://pastebin.com/Q4TqExwK Apr 09 20:59:29 yes, I've removed the clashing module Apr 09 22:02:09 ugh, found the bug Apr 09 22:02:17 after digging in the kernel, and realizing nf_conntrack_tcp_no_window_check is not part of it :/ Apr 09 22:03:07 ./target/linux/generic/pending-4.19/613-netfilter_optional_tcp_window_check.patch Apr 09 22:03:08 this is broke af Apr 09 22:03:40 not sure why that's even enabled by default. Apr 09 22:22:45 nyt: this patch is in the tree for ages https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=19eaf1c5f78afb7133e9208dd4d94938c19b3d08 Apr 09 22:23:09 it's broken on 4.19 Apr 09 22:23:28 it causes tcp_in_window() to return prematuurely Apr 09 22:23:38 before properly calling contrack methods Apr 09 22:24:06 so instead of nf_conntrack_tcp_timeout_established being applied for the countdown timer, nf_conntrack_tcp_timeout_max_retrans is Apr 09 22:24:22 I just updated to 4.19 this morning Apr 09 22:24:29 and noticed my idle ssh sessions were getting killed Apr 09 22:24:35 nuisance Apr 09 22:24:42 most people probably wont even notice, but it's broke af Apr 09 22:31:01 nyt: if it's problem, then the problem should be visible on 4.14 as well Apr 09 22:32:30 you're assuming that tcp_in_window() is identical between 4.14 and 4.19 Apr 09 22:33:02 yes, assuming so by this list of changes between 4.14 and 4.19 http://paste.ubuntu.com/p/GXF2fqzgGc/ Apr 09 22:34:15 literally the only change I made was 4.14 to 4.19. It broke conntrack Apr 09 22:34:20 toggling that sysctl value fixed it Apr 09 22:34:27 the patch is clearly at fault Apr 09 22:34:57 https://pastebin.com/raw/MftPn941 Apr 09 22:35:17 ok, feel free to report it on bugs.openwrt.org so it gets fixed Apr 09 22:37:21 or one of the methods called in tcp_in_window is now required to update the ct table properly Apr 09 22:40:39 msg'd nbd about it, still digging into the code to see if i can come up with a solution Apr 09 23:15:56 friggen $dayjob interrupting me, though Apr 09 23:22:58 https://github.com/torvalds/linux/blob/v4.19/net/netfilter/nf_conntrack_proto_tcp.c#L997 Apr 09 23:23:05 https://github.com/torvalds/linux/blob/v4.14/net/netfilter/nf_conntrack_proto_tcp.c#L1024 Apr 09 23:23:09 different behavior Apr 09 23:23:12 didnt get to read it all Apr 09 23:25:43 looks like in 4.19 timeouts are going to get set every time tcp_in_window returns true Apr 09 23:25:49 even if it's just an ack Apr 09 23:39:25 https://github.com/torvalds/linux/blob/v4.19/net/netfilter/nf_conntrack_proto_tcp.c#L1030 Apr 09 23:39:29 likely right there Apr 09 23:55:24 gotta get some food with the wife, will try to update the patch later to still work **** ENDING LOGGING AT Wed Apr 10 02:59:57 2019