"TCP segment of a reassembled PDU" Errors
Will
server over the WAN. The client's sniffer trace shows lots of messages:
"TCP segment of a reassembled PDU"
Can someone tell me possible causes and workarounds?
The connection with the server is exceedingly slow, and the basic functions
in Notes like forwarding a large file in email are on occasion just failing.
A Windows 2000 client on the same client subnet works perfectly. So it
doesn't look like a server problem or a local network problem, but a problem
with the client.
I guess I could tinker with MTU, but my experience with MTU on Windows has
been that if you hardcode MTU values in the registry some things go faster
and many things break entirely.
--
Will
Martijn Lievaart
> I have a networking problem on a Windows XP client talking to a Lotus
> Notes server over the WAN. The client's sniffer trace shows lots of
> messages:
>
> "TCP segment of a reassembled PDU"
>
> Can someone tell me possible causes and workarounds?
This does not indicate a problem. When wireshark/ethereal (the message is
I think unique to that product) reassembles a higher level protocol, it
marks all packets that make up a higher level message this way.
F.i. in http, the reply often takes more than one packet. All but the
last packet of the reply are marked like this. It just means that this
packet is part of a larger message.
HTH,
M4
Will
news:pan.2007.08...@rtij.nl.invlalid...
So the interesting facts to be explained still are that:
1) Wireshark running on the other client computer of the same subnet does
*not* report the reassembled PDU message. On that computer where things
are working well you see the ACK and PSH,ACK messages and never reassembly
messages.
2) On the computer that is showing the reassembly messages, they occupy the
bulk of the sniffer trace, and something is most definitely broken on the
machine. Performance for the Notes application is beyond awful (maybe 10
times worse than the other computer) and many operations just terminate with
various error messages.
Maybe the reassembly messages are coincidental to the defect, but not sure
how to proceed.
--
Will
Bo...@hotmail.co.uk
As already noted your Ethereal message is NOT
an "error". It is normal for higher level PDUs to be
fragmented for transmission.
I seem to recall that I had the idea that
the behaviour of Ethereal/Wireshark in the respect
of the display of such messages has varied across versions.
One explanation for the diffrence is that in order to
decode the higher level protocol (SMB (CIFS),
whatever Notes uses, FTP, ...) Ethereal sometimes
needs to see the start of the data strream for that
connection. Perhaps one of your traces has the start
and the other does not. The one that does not have the start
will not be able to identify the high level PDUs at all
and will not be able to display the message that is causing
you concern.
In a modern LAN the most likely explanation for
behaviour such as you describe is a Duplex mismatch.
Set everything to auto and it will probaby go away.
To troubleshoot check the error counters on
every interface in the path. There should be
much less than 1:1,000,000 errors of any kind.
A decent enough test is to do a bunch of
simultaneous pings with say fping.exe.
fping x.x.x.x -i -s 1472 -t 0 -n 10000
run about 10 of these simultaneously and
if you don't get any drops the network is
probably pretty good. Run enough so that the reported
RTT rises then add a few more. This means that the
network is full.
[ IIRC 1472 may be the right value to generate
1500 byte ethernet packets. Check with ethereal,
if it's not adjust 'til it is]
fping from
http://www.kwakkelflap.com/
is the one I mean, very hard to find with google.
This test may fill up your network so take
precautions.