"TCP segment of a reassembled PDU" Errors - TCP-IP

This is a discussion on "TCP segment of a reassembled PDU" Errors - TCP-IP ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: "TCP segment of a reassembled PDU" Errors

  1. "TCP segment of a reassembled PDU" Errors

    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.

    --
    Will



  2. Re: "TCP segment of a reassembled PDU" Errors

    On Fri, 10 Aug 2007 13:38:50 -0700, Will wrote:

    > 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

  3. Re: "TCP segment of a reassembled PDU" Errors

    "Martijn Lievaart" wrote in message
    newsan.2007.08.10.21.16.07@rtij.nl.invlalid...
    > On Fri, 10 Aug 2007 13:38:50 -0700, Will wrote:
    >
    >> 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.


    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



  4. Re: "TCP segment of a reassembled PDU" Errors

    On 11 Aug, 03:27, "Will" wrote:
    > "Martijn Lievaart" wrote in message
    >
    > newsan.2007.08.10.21.16.07@rtij.nl.invlalid...
    >
    >
    >
    >
    >
    > > On Fri, 10 Aug 2007 13:38:50 -0700, Will wrote:

    >
    > >> 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.

    >
    > 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
    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.


+ Reply to Thread