Unusual tcpdump output?

I've got a problem (in the last four weeks or so) with an internet
connection that is causing corrupt downloads from selected locations
notably the Norton antivirus update site.

I'm getting the following output from tcpdump when downloading:
eg. wget http://definitions.symantec.com/defs...-003-i32-1.exe

]# tcpdump port 80
tcpdump: listening on eth0
00:15:02.467793 srv-001.34278 > 203.147.56.230.http: S
893928169:893928169(0) win 5840 <mss 1460,sackOK,timestamp 1227266425
0,nop,wscale 0> (DF)
00:15:02.505943 203.147.56.230.http > srv-001.34278: S
2745254075:2745254075(0) ack 893928170 win 5792 <mss
1452,sackOK,timestamp 793312392 1227266425,nop,wscale 0> (DF)
00:15:02.506041 srv-001.34278 > 203.147.56.230.http: . ack 1 win 5840
<nop,nop,timestamp 1227266429 793312392> (DF)
00:15:02.506901 srv-001.34278 > 203.147.56.230.http: P 1:139(138) ack 1
win 5840 <nop,nop,timestamp 1227266429 793312392> (DF)
00:15:02.559360 203.147.56.230.http > srv-001.34278: . ack 139 win 5792
<nop,nop,timestamp 793312447 1227266429> (DF)
00:15:02.608380 203.147.56.230.http > srv-001.34278: . 1:1401(1400) ack
139 win 5792 <nop,nop,timestamp 793312468 1227266429> (frag
48159:1...@0+)
00:15:02.609319 srv-001.34278 > 203.147.56.230.http: . ack 1441 win
8640 <nop,nop,timestamp 1227266439 793312468> (DF)
00:15:02.637621 203.147.56.230.http > srv-001.34278: . 1441:2841(1400)
ack 139 win 5792 <nop,nop,timestamp 793312468 1227266429> (frag
48160:1...@0+)
00:15:02.638452 srv-001.34278 > 203.147.56.230.http: . ack 2881 win
11520 <nop,nop,timestamp 1227266442 793312468> (DF)
00:15:02.666490 203.147.56.230.http > srv-001.34278: P 2881:4281(1400)
ack 139 win 5792 <nop,nop,timestamp 793312468 1227266429> (frag
48161:1...@0+)
00:15:02.667565 srv-001.34278 > 203.147.56.230.http: . ack 4321 win
14400 <nop,nop,timestamp 1227266445 793312468> (DF)
00:15:02.754391 203.147.56.230.http > srv-001.34278: . 4321:5721(1400)
ack 139 win 5792 <nop,nop,timestamp 793312612 1227266439> (frag
48162:1...@0+)
00:15:02.755739 srv-001.34278 > 203.147.56.230.http: . ack 5761 win
17280 <nop,nop,timestamp 1227266454 793312612> (DF)
00:15:02.783075 203.147.56.230.http > srv-001.34278: . 5761:7161(1400)
ack 139 win 5792 <nop,nop,timestamp 793312612 1227266439> (frag
48163:1...@0+)
00:15:02.784486 srv-001.34278 > 203.147.56.230.http: . ack 7201 win
20160 <nop,nop,timestamp 1227266456 793312612> (DF)
00:15:02.812262 203.147.56.230.http > srv-001.34278: P 7201:8601(1400)
ack 139 win 5792 <nop,nop,timestamp 793312612 1227266442> (frag
48164:1...@0+)
00:15:02.813098 srv-001.34278 > 203.147.56.230.http: . ack 8641 win
23040 <nop,nop,timestamp 1227266459 793312612> (DF)
00:15:02.841202 203.147.56.230.http > srv-001.34278: . 8641:10041(1400)
ack 139 win 5792 <nop,nop,timestamp 793312612 1227266442> (frag
48165:1...@0+)

and so on until:

00:15:25.127738 203.147.56.230.http > srv-001.34278: P
1023841:1025241(1400) ack 139 win 5792 <nop,nop,timestamp 793334338
1227268620> (frag 48870:1...@0+)
00:15:25.156780 203.147.56.230.http > srv-001.34278: P
1025281:1026681(1400) ack 139 win 5792 <nop,nop,timestamp 793334338
1227268620> (frag 48871:1...@0+)
00:15:25.156854 srv-001.34278 > 203.147.56.230.http: . ack 1026714 win
34560 <nop,nop,timestamp 1227268694 793334338> (DF)
00:15:25.159200 srv-001.34278 > 203.147.56.230.http: F 139:139(0) ack
1026714 win 34560 <nop,nop,timestamp 1227268694 793334338> (DF)
00:15:25.210642 203.147.56.230.http > srv-001.34278: F
1026714:1026714(0) ack 140 win 5792 <nop,nop,timestamp 793335104
1227268694> (DF)
00:15:25.210696 srv-001.34278 > 203.147.56.230.http: . ack 1026715 win
34560 <nop,nop,timestamp 1227268699 793335104> (DF)

(Google has thoughtfully obfuscated all the size figures, thinking they
are email addresses, but they all started out as 1432)

There appears to be some strange fragmentation problem here, but I'm at
a loss as to how to troubleshoot it further - any suggestions on
decyphering this output, or where to go from here?

(E-Mail Removed) wrote:
> I've got a problem (in the last four weeks or so) with an internet
> connection that is causing corrupt downloads from selected locations
> notably the Norton antivirus update site.
>
> I'm getting the following output from tcpdump when downloading:
> eg. wget http://definitions.symantec.com/defs...-003-i32-1.exe
>
> ]# tcpdump port 80

Only your side of the connection is using port 80, so we are only
seeing your packets outgoing What is coming in as a response?

> tcpdump: listening on eth0
> 00:15:02.467793 srv-001.34278 > 203.147.56.230.http: S
> 893928169:893928169(0) win 5840 <mss 1460,sackOK,timestamp 1227266425
> 0,nop,wscale 0> (DF)

Please separate your packets as I have done here -- much easier to
read.

mss 1460 ... (DF)

> 00:15:02.505943 203.147.56.230.http > srv-001.34278: S
> 2745254075:2745254075(0) ack 893928170 win 5792 <mss
> 1452,sackOK,timestamp 793312392 1227266425,nop,wscale 0> (DF)

mss 1452 ... (DF)

> 00:15:02.506041 srv-001.34278 > 203.147.56.230.http: . ack 1 win 5840
> <nop,nop,timestamp 1227266429 793312392> (DF)

> 00:15:02.506901 srv-001.34278 > 203.147.56.230.http: P 1:139(138) ack
1
> win 5840 <nop,nop,timestamp 1227266429 793312392> (DF)

> 00:15:02.559360 203.147.56.230.http > srv-001.34278: . ack 139 win
5792
> <nop,nop,timestamp 793312447 1227266429> (DF)

3 nops in a row ...

> 00:15:02.608380 203.147.56.230.http > srv-001.34278: . 1:1401(1400)
ack
> 139 win 5792 <nop,nop,timestamp 793312468 1227266429> (frag
> 48159:1...@0+)

Already fragmenting in .608380 - .467793 = 0.140587 secs and it
continues.

> 00:15:02.609319 srv-001.34278 > 203.147.56.230.http: . ack 1441 win
> 8640 <nop,nop,timestamp 1227266439 793312468> (DF)

> 00:15:02.637621 203.147.56.230.http > srv-001.34278: .
1441:2841(1400)
> ack 139 win 5792 <nop,nop,timestamp 793312468 1227266429> (frag
> 48160:1...@0+)

[snip]

> (Google has thoughtfully obfuscated all the size figures, thinking
they
> are email addresses, but they all started out as 1432)

Not sure what you mean here. What sizes? Mean your MTU on eth0 is
1432? First packet out shows mss=1460. 1460 - 1432 = 28 bytes. pppoe
is usually 26 bytes total header, IIRC.

> There appears to be some strange fragmentation problem here, but I'm
at
> a loss as to how to troubleshoot it further - any suggestions on
> decyphering this output, or where to go from here?

Fragmenting and DF (Don't Fragment) don't play well together. Change
in netpath hardware (could be anywhere along the line)? Download via
web browser work OK? Different web browser?

Your TCP settings in /dev could be obnoxious to your net provider's
equipment. Looked at output from netstat? ifconfig -a? What's your
MTU? Looks like it should be <= mss 1452

Basically, there is not enough here to work with -- you already know
you have a fragmentation problem and all we can do is confirm your
notion of that. Upstream equipment changes could be boinking you.
hth,
prg
email above disabled

Hi,
Thanks for the response....

prg wrote:
> Only your side of the connection is using port 80, so we are only
> seeing your packets outgoing What is coming in as a response?

I thought this connection was between port 34278 (my pc) and port 80
(remote pc). Am I confused? (Happens often!)

[snip]

Thank you for the breakdown of the output. Although I don't pretend to
understand it all, it's very useful to have a second opinion.

> ack
> > 139 win 5792 <nop,nop,timestamp 793312468 1227266429> (frag
> > 48159:1...@0+)

[snip]

> > (Google has thoughtfully obfuscated all the size figures, thinking
> they
> > are email addresses, but they all started out as 1432)
>
> Not sure what you mean here. What sizes? Mean your MTU on eth0 is
> 1432? First packet out shows mss=1460. 1460 - 1432 = 28 bytes.
pppoe
> is usually 26 bytes total header, IIRC.

See the :1...@0+ above? This originally :1432@0+

I took this to mean a fragmented packet of 1432, with more to come. The
problem seems to be that the 'more' never arrives.

> Fragmenting and DF (Don't Fragment) don't play well together. Change
> in netpath hardware (could be anywhere along the line)? Download via
> web browser work OK? Different web browser?

Nothing that I've tried works. Web/FTP both on Windows and Linux with
different workstations (This connection uses a Cisco router/DSL modem)
I suspect that the problem is 'down the line'. My difficulty is how to
explain to the ISP here what is going wrong, hence the request for more
troubleshooting tips.

> Your TCP settings in /dev could be obnoxious to your net provider's
> equipment. Looked at output from netstat? ifconfig -a? What's your
> MTU? Looks like it should be <= mss 1452

ip mtu 1492
ip tcp adjust-mss 1452

> Basically, there is not enough here to work with -- you already know
> you have a fragmentation problem and all we can do is confirm your
> notion of that. Upstream equipment changes could be boinking you.

Thanks again. I would expect to see the second and subsequent
fragmented packets coming in:

18:57:32.509716 mandril.creatis.insa-lyon.fr.64930 > srv-001.34333: .
69121:70521(1400) ack 1 win 1448 <nop,nop,timestamp 199964851
1251280796> (frag 25154:1432@0+)

(First fragment)

18:57:32.510832 mandril.creatis.insa-lyon.fr > srv-001: (frag
25154:40@1432)

(And the last one)

But all except the first fragments seem to be getting dropped with the
problem connections. The question now is: How can I demonstrate this
unequivocably to the ISP?

(E-Mail Removed) wrote:
> Hi,
> Thanks for the response....
>
> prg wrote:
> > Only your side of the connection is using port 80, so we are only
> > seeing your packets outgoing What is coming in as a response?
>
> I thought this connection was between port 34278 (my pc) and port 80
> (remote pc). Am I confused? (Happens often!)

My bad -- wasn't thinking clearly. Had been using another tool past
several days where -p 80 meant -port 80 [only] ;(

> [snip]
>
> Thank you for the breakdown of the output. Although I don't pretend
to
> understand it all, it's very useful to have a second opinion.
>
> > ack
> > > 139 win 5792 <nop,nop,timestamp 793312468 1227266429> (frag
> > > 48159:1...@0+)
>
> [snip]
>
> > > (Google has thoughtfully obfuscated all the size figures,
thinking
> > they
> > > are email addresses, but they all started out as 1432)
> >
> > Not sure what you mean here. What sizes? Mean your MTU on eth0 is
> > 1432? First packet out shows mss=1460. 1460 - 1432 = 28 bytes.
> pppoe
> > is usually 26 bytes total header, IIRC.
>
> See the :1...@0+ above? This originally :1432@0+
>
> I took this to mean a fragmented packet of 1432, with more to come.
The
> problem seems to be that the 'more' never arrives.

Yes, that's correct -- was wondering where you got the 1432. BTW, typo
on my part above re: pppoe and header length -- should have been 16 not
26

> > Fragmenting and DF (Don't Fragment) don't play well together.
Change
> > in netpath hardware (could be anywhere along the line)? Download
via
> > web browser work OK? Different web browser?
>
> Nothing that I've tried works. Web/FTP both on Windows and Linux with
> different workstations (This connection uses a Cisco router/DSL
modem)
> I suspect that the problem is 'down the line'. My difficulty is how
to
> explain to the ISP here what is going wrong, hence the request for
more
> troubleshooting tips.

This is the sort of problem you get when DF is set but can't be honored
along the route the packets are taking. You might want to have this
handy for the occassion it might help -- don't see anything troublesome
at present:
http://ipsysctl-tutorial.frozentux.n...-tutorial.html

> > Your TCP settings in /dev could be obnoxious to your net provider's
> > equipment. Looked at output from netstat? ifconfig -a? What's
your
> > MTU? Looks like it should be <= mss 1452
>
> ip mtu 1492
> ip tcp adjust-mss 1452

I think 1432 might be worth trying -- did you?

> > Basically, there is not enough here to work with -- you already
know
> > you have a fragmentation problem and all we can do is confirm your
> > notion of that. Upstream equipment changes could be boinking you.
>
> Thanks again. I would expect to see the second and subsequent
> fragmented packets coming in:
>
> 18:57:32.509716 mandril.creatis.insa-lyon.fr.64930 > srv-001.34333: .
> 69121:70521(1400) ack 1 win 1448 <nop,nop,timestamp 199964851
> 1251280796> (frag 25154:1432@0+)
>
> (First fragment)
>
> 18:57:32.510832 mandril.creatis.insa-lyon.fr > srv-001: (frag
> 25154:40@1432)
>
> (And the last one)
>
> But all except the first fragments seem to be getting dropped with
the
> problem connections. The question now is: How can I demonstrate this
> unequivocably to the ISP?

My tired eyes don't scan tcpdump lines very well since they can get
wrapped inconsistently, etc. Great for scripting, but for eyeball work
I find ethereal _much_ better. And you can watch the packets as they
flow

You are getting the fragments as revealed by:
(frag 48159:
(frag 48160:
(frag 48161:
(frag 48162:
....
(frag 48870
(frag 48871
etc.

This ongoing fragmenting could cause download problems, but you might
have to capture the whole tranfer to find the spot where it boinks.

It could be hardware or some firewall setups will treat/massage
fragments. In fact, you could try this trick if you're up to it
http://lartc.org/howto/lartc.cookbook.mtu-mss.html
Perhaps yours is a case where it might help, but the dump "seems" to
indicate that pmtu is working. You never know, though.

Just what are you trying to download? If you could provide a link to
it or near it so that I could find it and attempt to download it at my
end, perhaps some clue will turn up. The dump address -- srv-001.34278
-- does not resolve to an IP with my tools. Too lazy to search

Maybe the problem is at/near their end (meaning file source network)
and not yours. Seems more likely if this is the only place you're
seeing this misbehavior.

hth,
prg
email above disabled

(E-Mail Removed) wrote:
> Hi,
> Thanks for the response....
>
> But all except the first fragments seem to be getting dropped with
the
> problem connections. The question now is: How can I demonstrate this
> unequivocably to the ISP?

My download -- looked at first post for the file -- and not hitches.
DF set at their end also and due its size nature it is almost certainly
at your end.

But where ...?

Seems like it would have a misconfiguration some where. Try this link
to get a quick backgrounder on what to try. The commands are for
Windows but will easily translate to Linux. $ man ping

You did not mention your hardware connection to ISP. ADSL? Cable?
Analog?

Anyway, by doing a traceroute to some out-of-your-ISP's-network site
you should get a list of the internal route out of your network. This
is the IP of the download site: 69.31.48.25 (a568.d.akamai.net) this
morning.

Then start at your gateway and work through the spots traceroute
returned with ping packets till you hit the spot that returns
fragmentation errors.

$ ping -c1 -s1472 69.31.48.25

adjust -s option as appropriate for your setup -- -s1452?

Some spot should return fragment error, at which time reduce size of
pings to that spot till errs are gone, then increase size by 1 till
errs return. Max MTU should (hopefully) then be last size - 1.

Then continue as far as you can and hope for no _further_ fragment
errs.

Ethereal "printout" from this AM. This is the first frame with a full
data payload after the setup:

Frame 71 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:02:7d:66:5c:54, Dst: 00:40:d0:04:06:ac
Internet Protocol, Src Addr: a568.d.akamai.net (69.31.48.25), Dst Addr:
xxx-xx.xxx-xx.ISP.com (xxx.xxx.xxx.xxx)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 1500
Identification: 0x561d (22045)
Flags: 0x04
..1.. = Don't fragment: Set
...0. = More fragments: Not set
Fragment offset: 0
Time to live: 56
Protocol: TCP (0x06)
Header checksum: 0xd0a5 (correct)
Source: a568.d.akamai.net (69.31.48.25)
Destination: xxx-xx.xxx-xx.ISP.com (xxx.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: http (80), Dst Port: 32944
(32944), Seq: 280368654, Ack: 3388643919, Len: 1448
Hypertext Transfer Protocol


hth,
prg
email above disabled

(E-Mail Removed) wrote:
> Hi,
> Thanks for the response....
>
> prg wrote:

[snip]

Well, actually it's what he did _not_ write. Gotta start proofing my
posts or my senility will be obvious to all

Here's the link I mentioned re: using ping to determine "best" MTU:
http://www.dslreports.com/tweaks/MTU

Sorry about that.

prg

Thank you again.

What do you think about this....

traceroute definitions.symantec.com 1500
traceroute: Warning: definitions.symantec.com has multiple addresses;
using 203.147.56.237
traceroute to a568.d.akamai.net (203.147.56.237), 30 hops max, 1500
byte packets
1 rtr (172.16.140.1) 3.115 ms 2.922 ms 2.687 ms
2 203.156.16.1 (203.156.16.1) 77.451 ms 115.336 ms 80.315 ms
3 203.156.102.117 (203.156.102.117) 83.186 ms 81.525 ms 80.349 ms
4 203.130.158.62 (203.130.158.62) 84.160 ms 80.574 ms 80.154 ms
Icmp checksum is wrong
5 203.147.56.237 (203.147.56.237) 98.727 msIcmp checksum is wrong
107.798 msIcmp checksum is wrong
100.028 ms
Could it be that this (203.147.56.237) box is misconfigured?

(E-Mail Removed) wrote:
> Thank you again.
>
> What do you think about this....
>
> traceroute definitions.symantec.com 1500
> traceroute: Warning: definitions.symantec.com has multiple addresses;
> using 203.147.56.237
> traceroute to a568.d.akamai.net (203.147.56.237), 30 hops max, 1500
> byte packets
> 1 rtr (172.16.140.1) 3.115 ms 2.922 ms 2.687 ms
> 2 203.156.16.1 (203.156.16.1) 77.451 ms 115.336 ms 80.315 ms
> 3 203.156.102.117 (203.156.102.117) 83.186 ms 81.525 ms 80.349 ms
> 4 203.130.158.62 (203.130.158.62) 84.160 ms 80.574 ms 80.154 ms
> Icmp checksum is wrong
> 5 203.147.56.237 (203.147.56.237) 98.727 msIcmp checksum is wrong
> 107.798 msIcmp checksum is wrong
> 100.028 ms
> Could it be that this (203.147.56.237) box is misconfigured?

Hard to say. Certainly 4 and 5 are flakey.

$ man traceroute (-x option)

I tried some traceroutes from my end.

I could not get to your symantec IP:
$ /usr/sbin/traceroute 203.130.158.62
-- traceroutes stopped as soon as I reached:
Lookup 203.147.0.56 (r56.ji-net.com) in 20+9 Zones
AS: 203.147.0.0/24 AS7616 Jasmine Internet Co, Ltd. UNKNOWN
??? In Thailand ???

Some others I tried -- with and without 1500 -- returned checksum
errors. But not consistenly. Eg. (with clean returns snipped):

$ /usr/sbin/traceroute 69.31.48.25 1432
traceroute to 69.31.48.25 (69.31.48.25), 30 hops max, 1432 byte packets
[xxx]
8 asn4436-nlayer.eqdltx.sbcglobal.net (151.164.248.98) 41.445 ms
35.546 ms 37.846 ms Icmp checksum is wrong
9 ip-69-31-48-25.nlayer.net (69.31.48.25) 43.677 msIcmp checksum is
wrong 39.926 ms Icmp checksum is wrong 40.781 ms

$ /usr/sbin/traceroute 69.31.48.25
traceroute to 69.31.48.25 (69.31.48.25), 30 hops max, 38 byte packets
[xxx]
8 asn4436-nlayer.eqdltx.sbcglobal.net (151.164.248.98) 27.603 ms
29.929 ms 30.508 ms
9 ip-69-31-48-25.nlayer.net (69.31.48.25) 29.054 ms 32.016 ms
35.888 ms

$ /usr/sbin/traceroute definitions.symantec.com 1500
traceroute: Warning: definitions.symantec.com has multiple addresses;
using 64.215.169.46
traceroute to a568.d.akamai.net (64.215.169.46), 30 hops max, 1500 byte
packets
[xxx]
11 so0-0-0-9953m.ar4.atl1.gblx.net (67.17.68.230) 72.255 ms 77.473
ms 73.313 ms Icmp checksum is wrong
12 64.215.169.46 (64.215.169.46) 79.195 ms Icmp checksum is wrong
75.178 ms Icmp checksum is wrong 73.382 ms

$ /usr/sbin/traceroute definitions.symantec.com 576
traceroute: Warning: definitions.symantec.com has multiple addresses;
using 205.161.6.38
traceroute to a568.d.akamai.net (205.161.6.38), 30 hops max, 576 byte
packets
[xxx]
9 sl-st21-dal-3-0.sprintlink.net (144.232.9.95) 30.337 ms 40.721
ms 29.733 ms Icmp checksum is wrong
10 205.161.6.38 (205.161.6.38) 31.443 msIcmp checksum is wrong
39.949 msIcmp checksum is wrong 30.840 ms

$ /usr/sbin/traceroute definitions.symantec.com 1432
traceroute: Warning: definitions.symantec.com has multiple addresses;
using 205.161.6.24
traceroute to a568.d.akamai.net (205.161.6.24), 30 hops max, 1432 byte
packets
[xxx]
9 * sl-st21-dal-3-0.sprintlink.net (144.232.9.95) 35.231 ms 41.718
ms Icmp checksum is wrong
10 205.161.6.24 (205.161.6.24) 38.543 msIcmp checksum is wrong
41.489 msIcmp checksum is wrong 38.708 ms

I'm not sure you can read too much into this as ICMP is often not
handled well and many sites/routers are configured with little/no
thought to making ICMP work "correctly".

Since you are trying to download a file only 1+ MB I would try to
determine an acceptable ping size, set nic MTU to that value and try
again. If it works, fine. If the MTU size is unacceptably small (<
1400 ?) change it back till you run into this problem again.

>From your original post, it seems this is inconsistent, ie., does not
occur at all sites you hit. That would lead me to believe that it's
probably _outside_ your immediate provider's network -- not much they
can about that. In fact, it may be an intermediate transition network
that is the source. I just don't have the time or inclination to track
it down to anything more specific.

All of your checksum errors _are_ occuring inside Jasmine Internet Co.
Ltd. I used http://www.openrbl.org/ and just used default DNSBL search
for all the checksum error IPs I generated -- they were scattered from
Virginia, to Holland, to New South Wales, to Thailand. Synmantec have
spread their anti-viruses everywhere it seems.
good luck,
prg
email above disabled

Hi, thanks for all your help. I reported the problem to Jasmine, and,
to their credit, they corrected it that afternoon.

A dump of the same download now starts off with what I assume is the
packet size negotiation, and then goes on to a non-fragmented transfer:

19:18:25.362096 srv-001.34418 > 203.147.56.230.http: S
3038767767:3038767767(0) win 5840 <mss 1460,sackOK,timestamp 1303244854
0,nop,wscale 0> (DF)
19:18:25.401951 203.147.56.230.http > srv-001.34418: S
1892053261:1892053261(0) ack 3038767768 win 5792 <mss
1452,sackOK,timestamp 1553321144 1303244854,nop,wscale 0> (DF)

19:18:25.402042 srv-001.34418 > 203.147.56.230.http: . ack 1 win 5840
<nop,nop,timestamp 1303244858 1553321144> (DF)
19:18:25.402317 srv-001.34418 > 203.147.56.230.http: P 1:137(136) ack 1
win 5840 <nop,nop,timestamp 1303244858 1553321144> (DF)
19:18:25.438489 203.147.56.230.http > srv-001.34418: . ack 137 win 5792
<nop,nop,timestamp 1553321179 1303244858> (DF)
19:18:25.467278 203.147.56.230.http > srv-001.34418: . 1:1441(1440) ack
137 win 5792 <nop,nop,timestamp 1553321181 1303244858> (DF)

19:18:25.467329 srv-001.34418 > 203.147.56.230.http: . ack 1441 win
8640 <nop,nop,timestamp 1303244864 1553321181> (DF)
19:18:25.493780 203.147.56.230.http > srv-001.34418: . 1441:2881(1440)
ack 137 win 5792 <nop,nop,timestamp 1553321181 1303244858> (DF)

19:18:25.493833 srv-001.34418 > 203.147.56.230.http: . ack 2881 win
11520 <nop,nop,timestamp 1303244867 1553321181> (DF)
19:18:25.520091 203.147.56.230.http > srv-001.34418: P 2881:4321(1440)
ack 137 win 5792 <nop,nop,timestamp 1553321181 1303244858> (DF)

19:18:25.520141 srv-001.34418 > 203.147.56.230.http: . ack 4321 win
14400 <nop,nop,timestamp 1303244869 1553321181> (DF)
19:18:25.549212 203.147.56.230.http > srv-001.34418: . 4321:5761(1440)
ack 137 win 5792 <nop,nop,timestamp 1553321236 1303244864> (DF)

19:18:25.549260 srv-001.34418 > 203.147.56.230.http: . ack 5761 win
17280 <nop,nop,timestamp 1303244872 1553321236> (DF)
19:18:25.575775 203.147.56.230.http > srv-001.34418: . 5761:7201(1440)
ack 137 win 5792 <nop,nop,timestamp 1553321236 1303244864> (DF)

[....]

19:18:31.402344 203.147.56.230.http > srv-001.34418: .
288001:289441(1440) ack 137 win 5792 <nop,nop,timestamp 1553326533
1303245392> (DF)

19:18:31.402428 srv-001.34418 > 203.147.56.230.http: R
3038767904:3038767904(0) win 0 (DF)

19:18:31.428946 203.147.56.230.http > srv-001.34418: .
289441:290881(1440) ack 137 win 5792 <nop,nop,timestamp 1553326534
1303245392> (DF)

19:18:31.428993 srv-001.34418 > 203.147.56.230.http: R
3038767904:3038767904(0) win 0 (DF)

19:18:31.458018 203.147.56.230.http > srv-001.34418: .
290881:292321(1440) ack 137 win 5792 <nop,nop,timestamp 1553326569
1303245397> (DF)

19:18:31.458063 srv-001.34418 > 203.147.56.230.http: R
3038767904:3038767904(0) win 0 (DF)

19:18:31.484381 203.147.56.230.http > srv-001.34418: .
292321:293761(1440) ack 137 win 5792 <nop,nop,timestamp 1553326569
1303245397> (DF)

19:18:31.484426 srv-001.34418 > 203.147.56.230.http: R
3038767904:3038767904(0) win 0 (DF)

19:18:31.525769 203.147.56.230.http > srv-001.34418: .
293761:295201(1440) ack 137 win 5792 <nop,nop,timestamp 1553326630
1303245403> (DF)

19:18:31.525814 srv-001.34418 > 203.147.56.230.http: R
3038767904:3038767904(0) win 0 (DF)
..... and so on ....

Thanks again for your help.

(E-Mail Removed) wrote:
> Hi, thanks for all your help. I reported the problem to Jasmine, and,
> to their credit, they corrected it that afternoon.
>
> A dump of the same download now starts off with what I assume is the
> packet size negotiation, and then goes on to a non-fragmented
transfer:
>
> 19:18:25.362096 srv-001.34418 > 203.147.56.230.http: S
> 3038767767:3038767767(0) win 5840 <mss 1460,sackOK,timestamp
1303244854
> 0,nop,wscale 0> (DF)
> 19:18:25.401951 203.147.56.230.http > srv-001.34418: S
> 1892053261:1892053261(0) ack 3038767768 win 5792 <mss
> 1452,sackOK,timestamp 1553321144 1303244854,nop,wscale 0> (DF)
>
> 19:18:25.402042 srv-001.34418 > 203.147.56.230.http: . ack 1 win 5840
> <nop,nop,timestamp 1303244858 1553321144> (DF)
> 19:18:25.402317 srv-001.34418 > 203.147.56.230.http: P 1:137(136) ack
1
> win 5840 <nop,nop,timestamp 1303244858 1553321144> (DF)
> 19:18:25.438489 203.147.56.230.http > srv-001.34418: . ack 137 win
5792
> <nop,nop,timestamp 1553321179 1303244858> (DF)
> 19:18:25.467278 203.147.56.230.http > srv-001.34418: . 1:1441(1440)
ack
> 137 win 5792 <nop,nop,timestamp 1553321181 1303244858> (DF)
[snip]
> .... and so on ....
>
> Thanks again for your help.

Glad you could get it fixed. And thanks for reporting back -- I was
just wondering yesterday how it was working out.
regards,
prg
email above disabled