I'm trying to make a program listen on a port range in Go (520+ ports;TCP).
However, it doesn't seem to work. It listens on a few and then stops.
I was thinking to make a for loop increasing by one and then calling a listening function like so:
for i := <beginning port>; i <= <ending port>; i++ {
ipaddr := fmt.Sprintf("8.8.8.8:%d", i)
ipaddrnew, _ := parseAddress(ipaddr)
go listener(ipaddrnew)
}
That's what I've been trying to do but it stops after a few go through.
Update:
Here's a test I just ran:
I change the code to the following:
for i := 14480; i <= 15000; i++ {
ipaddr := fmt.Sprintf(":%d", i)
fmt.Println(i)
ipaddrnew, _ := parseAddress(ipaddr)
go listener(ipaddrnew)
}
and it gave the following response:
14480
14481
14482
14483
14484
14485
14486
14487
14488
14489
14490
14491
14492
14493
14494
14495
[TCP] Listening for connections on :14483.
14496
[TCP] Listening for connections on :14481.
14497
14498
14499
14500
14501
14502
14503
14504
14505
[TCP] Listening for connections on :14482.
14506
14507
14508
14509
14510
14511
14512
[TCP] Listening for connections on :14480.
14513
14514
14515
14516
14517
14518
14519
14520
14521
14522
14523
[TCP] Listening for connections on :14501.
14524
14525
14526
14527
14528
14529
14530
[TCP] Listening for connections on :14484.
14531
14532
14533
14534
14535
14536
14537
14538
14539
14540
14541
[TCP] Listening for connections on :14485.
14542
14543
14544
14545
14546
14547
14548
14549
14550
14551
14552
14553
14554
[TCP] Listening for connections on :14486.
14555
14556
14557
14558
14559
14560
[TCP] Listening for connections on :14487.
14561
14562
14563
14564
14565
14566
14567
14568
14569
[TCP] Listening for connections on :14488.
14570
14571
14572
14573
14574
14575
14576
[TCP] Listening for connections on :14489.
14577
14578
14579
14580
14581
14582
14583
14584
14585
14586
[TCP] Listening for connections on :14490.
14587
14588
14589
14590
14591
14592
[TCP] Listening for connections on :14491.
14593
14594
14595
14596
14597
14598
14599
14600
14601
14602
14603
14604
14605
[TCP] Listening for connections on :14492.
14606
14607
14608
14609
14610
14611
14612
[TCP] Listening for connections on :14493.
14613
14614
14615
14616
14617
14618
14619
14620
14621
14622
14623
14624
[TCP] Listening for connections on :14494.
[TCP] Listening for connections on :14562.
14625
14626
14627
14628
14629
14630
14631
14632
14633
14634
14635
14636
[TCP] Listening for connections on :14502.
14637
14638
14639
14640
14641
14642
14643
14644
14645
14646
14647
14648
14649
14650
14651
14652
14653
14654
14655
14656
14657
14658
14659
14660
14661
14662
14663
14664
14665
14666
14667
14668
14669
14670
14671
14672
[TCP] Listening for connections on :14503.
14673
14674
[TCP] Listening for connections on :14495.
14675
14676
14677
14678
14679
14680
14681
14682
[TCP] Listening for connections on :14504.
14683
14684
14685
14686
14687
14688
[TCP] Listening for connections on :14505.
14689
14690
[TCP] Listening for connections on :14496.
14691
14692
14693
14694
14695
[TCP] Listening for connections on :14506.
14696
14697
14698
14699
14700
14701
14702
[TCP] Listening for connections on :14507.
14703
[TCP] Listening for connections on :14497.
14704
14705
14706
14707
14708
14709
14710
14711
14712
[TCP] Listening for connections on :14508.
14713
14714
14715
14716
14717
14718
14719
14720
[TCP] Listening for connections on :14509.
14721
14722
14723
14724
14725
14726
[TCP] Listening for connections on :14510.
14727
14728
14729
14730
14731
14732
14733
14734
[TCP] Listening for connections on :14511.
14735
14736
14737
14738
14739
[TCP] Listening for connections on :14512.
14740
14741
14742
14743
14744
14745
14746
14747
[TCP] Listening for connections on :14513.
14748
14749
14750
14751
14752
[TCP] Listening for connections on :14514.
14753
14754
14755
14756
14757
[TCP] Listening for connections on :14515.
14758
14759
14760
14761
14762
14763
14764
14765
14766
14767
14768
[TCP] Listening for connections on :14516.
14769
14770
14771
14772
14773
14774
14775
14776
14777
14778
14779
14780
14781
14782
14783
14784
14785
14786
14787
14788
14789
14790
14791
14792
14793
14794
14795
14796
14797
14798
14799
14800
14801
14802
14803
14804
14805
14806
14807
14808
14809
14810
14811
14812
14813
14814
14815
14816
14817
14818
14819
14820
14821
14822
14823
14824
14825
14826
14827
14828
14829
14830
14831
14832
[TCP] Listening for connections on :14517.
14833
14834
14835
14836
14837
14838
14839
14840
14841
14842
[TCP] Listening for connections on :14518.
14843
14844
14845
14846
14847
14848
[TCP] Listening for connections on :14519.
14849
14850
14851
14852
14853
14854
14855
14856
14857
14858
14859
[TCP] Listening for connections on :14520.
14860
14861
14862
14863
14864
[TCP] Listening for connections on :14521.
[TCP] Listening for connections on :14522.
14865
14866
Go program ends when main function ends. Just wait indefinitely in main function.
func main() {
go listen()
select {}
}
Related
I use tcpdump to catch some tcp packets, when analyzing them according to ip/tcp packet schema, the packet seems to be broken. Here is a sample packet I got from tcpdump output. Is any one familiar with them?
Should not the first 4 bit of ip packet always be 0100 in under ipv4?
ip packet: https://en.wikipedia.org/wiki/IPv4
some examples: http://mike.passwall.com/networking/samplepacket.html
13:11:43.330397 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
172.16.0.14.16668 > 36.24.146.114.64853: Flags [S.], cksum 0xdc0f (correct), seq 3029391223, ack 129060479, win 14480, options [mss 1460,sackOK,TS val 1254469916 ecr 1492278057,nop,wscale 6], length 0
0x0000: feee 809f 3247 5254 0054 aa9f 0800 4500 ....2GRT.T....E.
0x0010: 003c 0000 4000 4006 d813 ac10 000e 2418 .<..#.#.......$.
0x0020: 9272 411c fd55 b490 d777 07b1 4e7f a012 .rA..U...w..N...
0x0030: 3890 dc0f 0000 0204 05b4 0402 080a 4ac5 8.............J.
uname -a
# Linux VM_0_14_centos 2.6.32-754.2.1.el6.x86_64 #1 SMP Fri Jul 13 12:50:12 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
# tcpdump
tcpdump tcp -vv -XX -n -i eth0 port 16668
0x0000: feee 809f 3247 5254 0054 aa9f 0800 4500 ....2GRT.T....E.
The first 14 bytes are from the link layer (EN10MB). The IP layer only starts with 4500, where the 4 (binary 0100) are the first 4 bits which describe the version number, i.e. IP version 4.
These link layer data are explicitly requested by the -XX option which is used by the OP as pointed out in a comment by David Hoelzer. To cite from the documentation of tcpdump:
-XX When parsing and printing, in addition to printing the headers of each packet, print the data of each packet, including its link level header, in hex and ASCII.
This is my Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = "bento/centos-7.1"
config.vm.define "test_mashine", primary: true do |test_mashine|
# ...
config.vm.box = "bento/centos-7.1"
test_mashine.vm.network "private_network", ip: "192.168.33.10", bridge: "eth0"
config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--memory", "2048"]
vb.customize ["modifyvm", :id, "--cpus", "1"]
end
end
config.ssh.insert_key = false
end
This is ping statistic:
ping 192.168.33.10
PING 192.168.33.10 (192.168.33.10) 56(84) bytes of data.
64 bytes from 192.168.33.10: icmp_seq=1 ttl=64 time=0.560 ms
64 bytes from 192.168.33.10: icmp_seq=2 ttl=64 time=0.179 ms
64 bytes from 192.168.33.10: icmp_seq=3 ttl=64 time=0.192 ms
64 bytes from 192.168.33.10: icmp_seq=4 ttl=64 time=0.205 ms
^C
--- 192.168.33.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.179/0.284/0.560/0.159 ms
when i do vagrant ssh -c"ifconfig":
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::a00:27ff:fef6:b007 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:f6:b0:07 txqueuelen 1000 (Ethernet)
RX packets 483 bytes 54593 (53.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 299 bytes 44693 (43.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.109 netmask 255.255.255.0 broadcast 192.168.56.255
inet6 fe80::a00:27ff:fe17:2deb prefixlen 64 scopeid 0x20<link>
ether 08:00:27:17:2d:eb txqueuelen 1000 (Ethernet)
RX packets 7 bytes 1632 (1.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 2090 (2.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Connection to 127.0.0.1 closed.
The ip address of machine is 192.168.56.109. Ip address must be 192.168.33.10. When I start machine with ip 192.168.101.100 - ip sets right.
Any ideas?
why your doing bridge ?
if you want to give private ip then you should give like:
test_mashine.vm.network :private_network, ip: "192.168.33.10", netmask: "255.255.255.0"
if you want to give ip from public subnet then you have to give like:
test_mashine.vm.network "public_network"
or for static you can give IP or bridge name also.
your Vagrantfile should be like:
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
# config.vm.box = "bento/centos-7.1"
config.vm.define :test_mashine do |test_mashine|
# ...
test_mashine.vm.box = "bento/centos-7.1"
test_mashine.vm.network :private_network, ip: "192.168.33.10", netmask: "255.255.255.0"
test_mashine.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--memory", "2048"]
vb.customize ["modifyvm", :id, "--cpus", "1"]
end
end
config.ssh.insert_key = false
end
For more info refer Vagrant Networking
I am using TCPDUMP to intercept the network traffic on an Android device.
The command I use is
./tcpdump -tt -nn -vv tcp > tcp.log
In the result file (tcp.log), I found that there are not only TCP packets, but also some others with Ethernet address. (Some IP and Ethernet addresses are obfuscated due to privacy purpose).
1410451676.980763 IP (tos 0x0, ttl 41, id 0, offset 0, flags [DF], proto TCP (6), length 60)
54.204.ABC.144.80 > 172.31.DEF.178.59949: Flags [S.], seq 572870324, ack 3778403975, win 17898, options [mss 1380,sackOK,TS[|tcp]>
1410451676.980916 IP (tos 0x0, ttl 64, id 44656, offset 0, flags [DF], proto TCP (6), length 52)
172.31.DEF.178.59949 > 54.204.ABC.144.80: Flags [.], seq 1, ack 1, win 1369, options [nop,nop,TS[|tcp]>
1410451676.982167 IP (tos 0x0, ttl 64, id 44657, offset 0, flags [DF], proto TCP (6), length 701)
172.31.DEF.178.59949 > 54.204.ABC.144.80: Flags [P.], seq 1:650, ack 1, win 1369, options [nop,nop,TS[|tcp]>
1410451676.996114 00:24:f9:c3:XX:00 > d8:50:e6:2b:YY:6a, ethertype IPv6 (0x86dd), length 86:
0x0000: 6000 0000 0020 0634 2607 f8b0 400d 0c03 `......4&...#...
0x0010: 0000 0000 0000 00bc 2001 0468 0c80 4340 ...........h..C#
0x0020: b040 b100 7831 4228 146c c1cc ceb8 fc7a .#..x1B(.l.....z
1410451677.000783 00:24:f9:c3:XX:00 > d8:50:e6:2b:YY:6a, ethertype IPv6 (0x86dd), length 535:
0x0000: 6000 0000 01e1 0634 2607 f8b0 400d 0c03 `......4&...#...
0x0010: 0000 0000 0000 00bc 2001 0468 0c80 4340 ...........h..C#
0x0020: b040 b100 7831 4228 146c c1cc ceb8 fc7a .#..x1B(.l.....z
1410451677.000935 d8:50:e6:2b:YY:6a > 00:24:f9:c3:XX:00, ethertype IPv6 (0x86dd), length 86:
0x0000: 6000 0000 0020 0640 2001 0468 0c80 4340 `......#...h..C#
0x0010: b040 b100 7831 4228 2607 f8b0 400d 0c03 .#..x1B(&...#...
0x0020: 0000 0000 0000 00bc c1cc 146c 3b74 2fa9 ...........l;t/.
1410451677.011006 IP (tos 0x0, ttl 41, id 62137, offset 0, flags [DF], proto TCP (6), length 52)
54.204.ABC.144.80 > 172.31.DEF.178.59949: Flags [.], seq 1, ack 650, win 75, options [nop,nop,TS[|tcp]>
In a regular TCP packet header, the result includes its timestamp (UNIX time), IP packet flag+options, source IP address+port, destination IP address+port, and TCP flags.
BUT, what I do not understand is that there are some Ethernet packets in between and according to the results, these packets include their MAC address, instead of IP address.
Why is the case? Are they TCP packets?
Thanks for your answers/insights.
All those packets are Ethernet packets.
The version of tcpdump you're using was apparently not built with IPv6 support, so, while it can recognize IPv4-over-Ethernet packets and printout the IP information, it can't recognize IPv6-over-Ethernet packets, and just prints out the Ethernet-layer information.
You should ask whoever built that version of tcpdump why it doesn't include IPv6 support.
i want to do subnetting with the given ip address as follows
192.168.10.0/25
My requirement is i want 30 addresses per subnet.
what will be the nw address of subnet 0?
is it 192.168.10.0/27 or 192.168.10.128/27 ?
The ipcalc tool can answer this for you:
Address: 192.168.10.0 11000000.10101000.00001010.0 0000000
Netmask: 255.255.255.128 = 25 11111111.11111111.11111111.1 0000000
Wildcard: 0.0.0.127 00000000.00000000.00000000.0 1111111
=>
Network: 192.168.10.0/25 11000000.10101000.00001010.0 0000000 (Class C)
Broadcast: 192.168.10.127 11000000.10101000.00001010.0 1111111
HostMin: 192.168.10.1 11000000.10101000.00001010.0 0000001
HostMax: 192.168.10.126 11000000.10101000.00001010.0 1111110
Hosts/Net: 126 (Private Internet)
Subnets
Netmask: 255.255.255.224 = 27 11111111.11111111.11111111.111 00000
Wildcard: 0.0.0.31 00000000.00000000.00000000.000 11111
Network: 192.168.10.0/27 11000000.10101000.00001010.000 00000 (Class C)
Broadcast: 192.168.10.31 11000000.10101000.00001010.000 11111
HostMin: 192.168.10.1 11000000.10101000.00001010.000 00001
HostMax: 192.168.10.30 11000000.10101000.00001010.000 11110
Hosts/Net: 30 (Private Internet)
Network: 192.168.10.32/27 11000000.10101000.00001010.001 00000 (Class C)
Broadcast: 192.168.10.63 11000000.10101000.00001010.001 11111
HostMin: 192.168.10.33 11000000.10101000.00001010.001 00001
HostMax: 192.168.10.62 11000000.10101000.00001010.001 11110
Hosts/Net: 30 (Private Internet)
Network: 192.168.10.64/27 11000000.10101000.00001010.010 00000 (Class C)
Broadcast: 192.168.10.95 11000000.10101000.00001010.010 11111
HostMin: 192.168.10.65 11000000.10101000.00001010.010 00001
HostMax: 192.168.10.94 11000000.10101000.00001010.010 11110
Hosts/Net: 30 (Private Internet)
Network: 192.168.10.96/27 11000000.10101000.00001010.011 00000 (Class C)
Broadcast: 192.168.10.127 11000000.10101000.00001010.011 11111
HostMin: 192.168.10.97 11000000.10101000.00001010.011 00001
HostMax: 192.168.10.126 11000000.10101000.00001010.011 11110
Hosts/Net: 30 (Private Internet)
Subnets: 4
Hosts: 120
Also, the address 192.168.10.128 is beyond the range of the original /25!
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
This question exists because it has
historical significance, but it is not
considered a good, on-topic question
for this site, so please do not use it
as evidence that you can ask similar
questions here.
More info: https://stackoverflow.com/faq
I am having a weird TCP issue that makes no sense at all. I am tearing my hair out.
When downloading a file from Amazon S3 (and only Amazon S3- every other site works fine) some percentage of the time the connections dies. This only happens from our servers in Seattle with a web server behind a NAT router. Connecting directly from the router works fine. From our servers here in Victoria everything works fine, and we can't replicate this at all.
Web server in Seattle (tried 10 different servers) -> SNAT router (2 different routers; old kernels and new kernels) -> Amazon S3 = doesn't work ~10% of the time
Web server in Seattle -> SNAT router -> any other website = works
Router box -> Amazon S3 = works
Web server in Victoria -> SNAT router in Victoria -> Amazon S3 = works
Things I've tried:
Disabling window scaling
Lowering the window size
upgrading the router to the newest kernel
Disabling the firewall entirely
In the failure case Amazon (or something along the way) sends us a 868 length packet instead of the expected 1500 byte packet. The server upon seeing the packets replies with a RST packet (error has occurred) and the connection is torn down.
Any help would be greatly appreciated!
Below are two TCP dumps-
------------ Begin Error Case TCP Dump -------------
tcpdump -r /tmp/s3doesntwork-died
reading from file /tmp/s3doesntwork-died, link-type EN10MB (Ethernet)
19:58:42.542189 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: S 193799772:193799772(0) win 5840 <mss 1460,sackOK,timestamp 760821159 0,nop,wscale 5>
19:58:42.544115 IP 189-81.amazon.com.www > locum.sparklit.com.39491: S 3148664267:3148664267(0) ack 193799773 win 8190 <mss 1460,nop,wscale 6,nop,nop,sackOK>
19:58:42.545176 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 1 win 183
19:58:42.545184 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: P 1:212(211) ack 1 win 183
19:58:42.548113 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . ack 212 win 916
19:58:42.558108 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 1:1461(1460) ack 212 win 916
19:58:42.558117 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 1461:2921(1460) ack 212 win 916
19:58:42.558123 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 2921:4381(1460) ack 212 win 916
19:58:42.558128 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 4381:5841(1460) ack 212 win 916
19:58:42.559108 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 5841:7301(1460) ack 212 win 916
19:58:42.559118 IP 189-81.amazon.com.www > locum.sparklit.com.39491: . 7301:8129(828) ack 212 win 916
19:58:42.559138 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: R 193799984:193799984(0) win 0
19:58:42.559169 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 1461 win 274
19:58:42.559176 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 2921 win 365
19:58:42.559180 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 4381 win 457
19:58:42.559188 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 5841 win 548
19:58:42.560167 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: . ack 7301 win 639
19:58:45.308618 IP locum.sparklit.com.39491 > 189-81.amazon.com.www: F 212:212(0) ack 7301 win 639
19:58:45.310512 IP 189-81.amazon.com.www > locum.sparklit.com.39491: R 3148671568:3148671568(0) win 8201
Update: Traceroute to Amazon
1 64.34.33.195 (64.34.33.195) 0.795 ms 0.775 ms 0.762 ms
2 six01-sea4.amazon.com (206.81.80.147) 0.746 ms 0.732 ms 0.715 ms
3 72.21.222.183 (72.21.222.183) 2.657 ms 2.651 ms 2.638 ms
4 72.21.222.179 (72.21.222.179) 2.618 ms 2.604 ms 2.591 ms
5 * * *
6 * * *
7 * * *
Update: The offending incoming packet that causes the RST to be sent
19:58:42.559118 IP (tos 0x0, ttl 57, id 18905, offset 0, flags [DF], proto TCP (6), length 868) 189-81.amazon.com.www > locum.sparklit.com.39491: ., cksum 0x9f6e (correct), 7301:8129(828) ack 212 win 916
0x0000: 4500 0364 49d9 4000 3906 05d7 cfab bd51 E..dI.#.9......Q
0x0010: 4022 21c5 0050 9a43 bbac ea50 0b8d 2730 #"!..P.C...P..'0
0x0020: 5010 0394 9f6e 0000 7c75 a901 cd57 0718 P....n..|u...W..
0x0030: a786 e954 4160 3734 f563 5029 e7ad 48a7 ...TA`74.cP)..H.
0x0040: 34c0 b11b 75a2 a341 c1e6 8aab a03c 31ee 4...u..A.....<1.
0x0050: 1496 c9ef df22 aadc b87e 8431 fc2a dcd6 ....."...~.1.*..
0x0060: e72d 8cf7 aa92 5b12 4923 3f51 50cd 5195 .-....[.I#?QP.Q.
0x0070: 7910 6ce4 0fc0 d63c f115 276b b7e7 5bf7 y.l....<..'k..[.
0x0080: 508e d8fa d655 c5b3 1638 3cd6 6cd1 198c P....U...8<.l...
0x0090: 1c7f 1b7e 59a4 4370 9c87 523d 0ae2 adb4 ...~Y.Cp..R=....
0x00a0: 4d8e 7ad5 7954 c6ac 79e3 9e05 4148 6c97 M.z.yT..y...AHl.
0x00b0: b711 f262 47fa 363f 9d52 bcd4 a58e 177f ...bG.6?.R......
0x00c0: b33b 1033 b530 7351 d8eb 29a9 dbcf 2c6b .;.3.0sQ..)...,k
0x00d0: b161 99e0 3e67 192b 8c9f a735 89ad f886 .a..>g.+...5....
0x00e0: 4d3a ff00 462e b0ad 8dec 8f04 9bdb 9121 M:..F..........!
0x00f0: 4263 0ac4 81c9 18e7 ae6a 1a65 d8db d3ee Bc.......j.e....
0x0100: 3722 b608 cf24 1182 2ba1 b39b 728a f29b 7"...$..+...r...
0x0110: df1e db68 9af5 b69a e51e 5923 2ed0 29fd ...h......Y#..).
0x0120: f0e4 6303 f8bb f4ae ef44 d5e3 bc67 8f70 ..c......D...g.p
0x0130: 5b88 8299 a30d 931e e1c0 38fc 6bca a917 [.........8.k...
0x0140: 7b9d 8a2d 2bb3 5ef7 9e0d 625e c59c d6dc {..-+.^...b^....
0x0150: e778 cd67 5c26 ecd2 a64b 6737 345b 643d .x.g\&...Kg74[d=
0x0160: 6a3d b57e f22f 98d5 455e b5da b546 0c60 j=.~./..E^...F.`
0x0170: 5c51 5281 8a69 4e69 888c af15 0b0a b240 \QR..iNi.......#
0x0180: c540 c334 0101 1935 04b5 6996 a091 7ad0 .#.4...5..i...z.
0x0190: 2676 ba0d 8bbc 30cc 3385 c7f2 a835 ab19 &v....0.3....5..
0x01a0: 2e0b 003a d75b e17b 453a 03b6 070a a7f4 ...:.[.{E:......
0x01b0: a6cf 671e 7270 6b59 ae5e 5f43 28eb 73cd ..g.rpkY.^_C(.s.
0x01c0: 53c2 8f34 9c8e 3e95 d268 fe0f 4864 4661 S..4..>..h..HdFa
0x01d0: 9008 2702 b75e 782d 81e0 0fc2 b3ae bc51 ..'..^x-.......Q
0x01e0: 0c00 e080 477a 9bb6 3b1f 08fc 7efd 943e ....Gz..;...~..>
0x01f0: 26eb ff00 163c 4bad 695e 1b97 51d2 2f6e &....<K.i^..Q./n
0x0200: 4cb6 f35b dca3 7c98 1d46 ec8f a62b c675 L..[..|..F...+.u
0x0210: 4fd9 dfc7 1a4b b2df e812 da63 fe7e 0b2f O....K.....c.~./
0x0220: eb8a fd38 bff1 d055 386f c735 cf5f f8fa ...8...U8o.5._..
0x0230: 7705 44ac 54f6 2723 f2ae d862 2a25 6b1c w.D.T.'#...b*%k.
0x0240: f2a5 06ee 7e6b a7c1 bd79 f2a2 2b1d c3b1 ....~k...y..+...
0x0250: ba5c d759 e03f 849a e787 3564 d6af 2d6d .\.Y.?....5d..-m
0x0260: db4e b7fd d48f 0ca1 8866 1c0e dcd7 db37 .N.......f.....7
0x0270: b2d9 eb2e 4dd6 9767 704f 5692 d949 fcf1 ....M..gpOV..I..
0x0280: 53da 7c3c d0fc 45a3 ea3a 4cf6 3f67 b379 S.|<..E..:L.?g.y
0x0290: a197 cbb5 7311 0dcf 20d6 8f11 2d99 2a94 ....s.......-.*.
0x02a0: 7a1e 69e1 9fda 77c5 7e0d d3ad 74f8 eeac z.i...w.~...t...
0x02b0: e6b3 b641 1c71 df5b 6085 1db7 a907 f3cd ...A.q.[`.......
0x02c0: 7a3e 81fb 6b4c 42ff 0069 6831 4ebd dec6 z>..kLB..ih1N...
0x02d0: e837 fe3a c335 3d9f ec75 e01d 576b 5c47 .7.:.5=..u..Wk\G
0x02e0: ab12 c3a7 f683 8fe9 5a29 fb07 7c31 3f32 ........Z)..|1?2
0x02f0: dbea 81fd 4ea7 2e7f 98ae 37ec 99aa 53e8 ....N.....7...S.
0x0300: cb5a 97ed cfe0 ad1f 4d6b 99f4 bd56 79c1 .Z......Mk...Vy.
0x0310: ff00 8f48 d151 c8ef 8627 15f4 1681 acc5 ...H.Q...'......
0x0320: e21d 0b4e d56d e378 adef add2 e238 e5c6 ...N.m.x.....8..
0x0330: f556 1900 e38c d781 d97e c3bf 0ce0 71f6 .V.......~....q.
0x0340: 9b1d 42ea 31fc 0fa9 cf8f fd0a be80 d2b4 ..B.1...........
0x0350: f834 8d3a d2c2 d13c ab4b 5896 1850 9270 .4.:...<.KX..P.p
0x0360: 8a30 073e .0.>
So we finally figured it out-
It turns out that our router was injecting the RST packets because Netfilter declared the packet invalid. There is a setting that makes netfitler more liberal so I tried enabling it (inet.ipv4.netfilter.ip_conntrack_tcp_be_liberal=1) and the connection is no longer torn down.
However, I still haven't figured out why netfilter declared that packet as invalid. Enabling "ip_conntrack_log_invalid" doesn't cause anything to be printed in the log.
This is a guess. Maybe running some traceroutes to the target target and collecting the hops. Then pinging each of the hops with a 1500 byte packet configured for a 100 count would help identify problems links.
The sender is entitled to send any length packet it likes between 1 and 1460 (in this case, being your apparent MTU). The question is why does your server send the RST?