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?
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.
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.
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.
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
formatting link
the one I mean, very hard to find with google.
This test may fill up your network so take precautions.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.