tcpdump analysis question - TCP-IP
This is a discussion on tcpdump analysis question - TCP-IP ; I have a java application that's getting a broken pipe error. There's
nothing in the logs at either end to indicate what the problem really is.
I got a tcpdump file, and ran it through ethereal, and I see it ...
-
tcpdump analysis question
I have a java application that's getting a broken pipe error. There's
nothing in the logs at either end to indicate what the problem really is.
I got a tcpdump file, and ran it through ethereal, and I see it ending up
with 4 ACK's, a data packet, and then a lot of keepalives.
I also ran the tcpdump file through tcptrace - output for what I believe
is the relevant sessions is below.
Is there anything here that suggests a network problem rather than an
application problem? My first thought after looking over the ethereal was
"yes", but now that I see 0 retransmits in tcptrace I'm doubting that.
Thanks!
TCP connection 25:
host aw: solaris:9425
host ax: linux:5432
complete conn: no (SYNs: 2) (FINs: 0)
first packet: Wed Jun 6 21:48:17.483242 2007
last packet: Thu Jun 7 01:03:17.871464 2007
elapsed time: 3:15:00.388221
total packets: 166
filename: dump1
aw->ax: ax->aw:
total packets: 84 total packets: 82
ack pkts sent: 83 ack pkts sent: 82
pure acks sent: 75 pure acks sent: 66
sack pkts sent: 0 sack pkts sent: 0
dsack pkts sent: 0 dsack pkts sent: 0
max sack blks/ack: 0 max sack blks/ack: 0
unique bytes sent: 239 unique bytes sent: 630
actual data pkts: 8 actual data pkts: 15
actual data bytes: 239 actual data bytes: 630
rexmt data pkts: 0 rexmt data pkts: 0
rexmt data bytes: 0 rexmt data bytes: 0
zwnd probe pkts: 0 zwnd probe pkts: 0
zwnd probe bytes: 0 zwnd probe bytes: 0
outoforder pkts: 0 outoforder pkts: 0
pushed data pkts: 8 pushed data pkts: 15
SYN/FIN pkts sent: 1/0 SYN/FIN pkts sent: 1/0
req sack: Y req sack: Y
sacks sent: 0 sacks sent: 0
urgent data pkts: 0 pkts urgent data pkts: 0 pkts
urgent data bytes: 0 bytes urgent data bytes: 0 bytes
mss requested: 1380 bytes mss requested: 1460 bytes
max segm size: 48 bytes max segm size: 232 bytes
min segm size: 13 bytes min segm size: 5 bytes
avg segm size: 29 bytes avg segm size: 41 bytes
max win adv: 49680 bytes max win adv: 5840 bytes
min win adv: 49191 bytes min win adv: 5840 bytes
zero win adv: 0 times zero win adv: 0 times
avg win adv: 49241 bytes avg win adv: 5840 bytes
initial window: 39 bytes initial window: 9 bytes
initial window: 1 pkts initial window: 1 pkts
ttl stream length: NA ttl stream length: NA
missed data: NA missed data: NA
truncated data: 0 bytes truncated data: 0 bytes
truncated packets: 0 pkts truncated packets: 0 pkts
data xmit time: 0.051 secs data xmit time: 0.060 secs
idletime max: 180005.7 ms idletime max: 180013.5 ms
throughput: 0 Bps throughput: 0 Bps
-
Re: tcpdump analysis question
In article ,
Dan Stromberg - Datallegro wrote:
> I have a java application that's getting a broken pipe error. There's
> nothing in the logs at either end to indicate what the problem really is.
>
> I got a tcpdump file, and ran it through ethereal, and I see it ending up
> with 4 ACK's, a data packet, and then a lot of keepalives.
Is this last data packet ACKed? Are the keepalives ACKed?
"Broken pipe" usually means you received an RST in response to sending
data. Are there any RST packets in your dump? Nothing below mentions
resets.
>
> I also ran the tcpdump file through tcptrace - output for what I believe
> is the relevant sessions is below.
>
> Is there anything here that suggests a network problem rather than an
> application problem? My first thought after looking over the ethereal was
> "yes", but now that I see 0 retransmits in tcptrace I'm doubting that.
I don't see anything untoward below, either. Can you post the tcpdump
output? It's only about 160 packets.
>
> Thanks!
>
> TCP connection 25:
> host aw: solaris:9425
> host ax: linux:5432
> complete conn: no (SYNs: 2) (FINs: 0)
> first packet: Wed Jun 6 21:48:17.483242 2007
> last packet: Thu Jun 7 01:03:17.871464 2007
> elapsed time: 3:15:00.388221
> total packets: 166
> filename: dump1
> aw->ax: ax->aw:
> total packets: 84 total packets: 82
> ack pkts sent: 83 ack pkts sent: 82
> pure acks sent: 75 pure acks sent: 66
> sack pkts sent: 0 sack pkts sent: 0
> dsack pkts sent: 0 dsack pkts sent: 0
> max sack blks/ack: 0 max sack blks/ack: 0
> unique bytes sent: 239 unique bytes sent: 630
> actual data pkts: 8 actual data pkts: 15
> actual data bytes: 239 actual data bytes: 630
> rexmt data pkts: 0 rexmt data pkts: 0
> rexmt data bytes: 0 rexmt data bytes: 0
> zwnd probe pkts: 0 zwnd probe pkts: 0
> zwnd probe bytes: 0 zwnd probe bytes: 0
> outoforder pkts: 0 outoforder pkts: 0
> pushed data pkts: 8 pushed data pkts: 15
> SYN/FIN pkts sent: 1/0 SYN/FIN pkts sent: 1/0
> req sack: Y req sack: Y
> sacks sent: 0 sacks sent: 0
> urgent data pkts: 0 pkts urgent data pkts: 0 pkts
> urgent data bytes: 0 bytes urgent data bytes: 0 bytes
> mss requested: 1380 bytes mss requested: 1460 bytes
> max segm size: 48 bytes max segm size: 232 bytes
> min segm size: 13 bytes min segm size: 5 bytes
> avg segm size: 29 bytes avg segm size: 41 bytes
> max win adv: 49680 bytes max win adv: 5840 bytes
> min win adv: 49191 bytes min win adv: 5840 bytes
> zero win adv: 0 times zero win adv: 0 times
> avg win adv: 49241 bytes avg win adv: 5840 bytes
> initial window: 39 bytes initial window: 9 bytes
> initial window: 1 pkts initial window: 1 pkts
> ttl stream length: NA ttl stream length: NA
> missed data: NA missed data: NA
> truncated data: 0 bytes truncated data: 0 bytes
> truncated packets: 0 pkts truncated packets: 0 pkts
> data xmit time: 0.051 secs data xmit time: 0.060 secs
> idletime max: 180005.7 ms idletime max: 180013.5 ms
> throughput: 0 Bps throughput: 0 Bps
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***