NCP protocol padding packets? - Netware

This is a discussion on NCP protocol padding packets? - Netware ; I've been asked to sniff a network that's currently running Novell Netware. I've noticing that many packets are padded to around the max MTU size (1518). After crunching some numbers, it looks like the padding itself is accounting for over ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: NCP protocol padding packets?

  1. NCP protocol padding packets?

    I've been asked to sniff a network that's currently running Novell
    Netware.

    I've noticing that many packets are padded to around the max MTU size
    (1518). After crunching some numbers, it looks like the padding itself
    is accounting for over 50% of the traffic (52% of the data transmitted
    on the network is all zeros...)

    Is there an option available to disable this padding? Or limit it? Or
    is there a good reason to allow it to persist?

    Not a Novell guy, thanks for any help.


  2. Re: NCP protocol padding packets?

    In article <1108483587.692468.194840@c13g2000cwb.googlegroups. com>,
    Not A Netware Guy wrote:
    >I've been asked to sniff a network that's currently running Novell
    >Netware.
    >
    >I've noticing that many packets are padded to around the max MTU size
    >(1518). After crunching some numbers, it looks like the padding itself
    >is accounting for over 50% of the traffic (52% of the data transmitted
    >on the network is all zeros...)
    >
    >Is there an option available to disable this padding? Or limit it? Or
    >is there a good reason to allow it to persist?
    >
    >Not a Novell guy, thanks for any help.


    Are you sure it's padding?? I've never seen Netware pad IPX (or NCP)
    packets except in the following 2 cases:

    1) If the packet is less than 60 bytes, it will be padded out to 60 bytes.

    2) If the packet length is odd, a single byte is added to make the packet
    length even.

    Do you have a packet trace you can share? I'll take a look at it if you
    do.

    Patrick
    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==== Read up on Usenet etiquette: http://www.faqs.org/usenet/index.html ====

  3. Re: NCP protocol padding packets?

    It's IP and etherpeek identifies it as destined/sourced from an NCP
    port.

    Here's a sample packet: (XXXX represents source and dest IPs, and, of
    course, view in a monotype font for readability)

    Flags: 0x00
    Status: 0x00
    Packet Length:1518
    Timestamp: 10:14:32.167273 02/14/2005
    Raw Packet Data
    ..O........{..E. 00 C0 4F 04 82 C4 00 01 F4 0B C2 7B 08 00 45 00
    ...*@....W...z.. 05 DC EB 2A 40 00 7F 06 FB 57 XXXXXXXXXXX XXXXX
    .......yiQ.~..P. XXXXX 02 0C 0D 9E 8D 79 69 51 F6 7E F4 D9 50 10
    W.....tNcP....33 57 C0 F1 07 00 00 74 4E 63 50 00 00 08 12 33 33
    .;..........Stan CB 3B 04 00 00 00 08 00 00 01 00 00 53 74 61 6E
    dard Jet DB..... 64 61 72 64 20 4A 65 74 20 44 42 00 00 00 00 00
    .n.b`..U..gr@?.. B5 6E 03 62 60 09 C2 55 E9 A9 67 72 40 3F 00 9C
    ~.....1.y..0.... 7E 9F 90 FF 85 9A 31 C5 79 BA ED 30 BC DF CC 9D
    c....F...N...R3 63 D9 ED C7 9F 46 FB 8A BC 4E CA 9A 9A 52 33 20
    ...^(....`T.{6.} F9 88 C6 5E 28 E6 13 B6 8A 60 54 94 7B 36 B6 7D
    ..w..C...34ay[.. DF B1 77 F4 13 43 CF AF B1 33 34 61 79 5B 92 B5
    |*..|......OJ.l> 7C 2A 05 F1 7C 99 01 1B 98 FD 12 4F 4A 94 6C 3E
    `&_....$.g..'D.. 60 26 5F 95 F8 D0 89 24 85 67 C6 1F 27 44 D2 EE
    .e....F.x....-.. CF 65 ED FF 07 C7 46 A1 78 16 0C ED E9 2D 00 00
    ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ----snip----
    ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    .............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00


  4. Re: NCP protocol padding packets?

    In article <1108564378.411788.35150@c13g2000cwb.googlegroups.c om>,
    Not A Netware Guy wrote:
    >It's IP and etherpeek identifies it as destined/sourced from an NCP
    >port.
    >
    >Here's a sample packet: (XXXX represents source and dest IPs, and, of
    >course, view in a monotype font for readability)
    >
    > Flags: 0x00
    > Status: 0x00
    > Packet Length:1518
    > Timestamp: 10:14:32.167273 02/14/2005
    >Raw Packet Data
    > ..O........{..E. 00 C0 4F 04 82 C4 00 01 F4 0B C2 7B 08 00 45 00
    > ...*@....W...z.. 05 DC EB 2A 40 00 7F 06 FB 57 XXXXXXXXXXX XXXXX
    > .......yiQ.~..P. XXXXX 02 0C 0D 9E 8D 79 69 51 F6 7E F4 D9 50 10
    > W.....tNcP....33 57 C0 F1 07 00 00 74 4E 63 50 00 00 08 12 33 33


    According to this header, NCP is returning 812 (hex) bytes of data, which
    is this whole packet plus some. Since this is TCP, the rest of this
    response data will be in the subsequent TCP packet.

    > .;..........Stan CB 3B 04 00 00 00 08 00 00 01 00 00 53 74 61 6E
    > dard Jet DB..... 64 61 72 64 20 4A 65 74 20 44 42 00 00 00 00 00
    > .n.b`..U..gr@?.. B5 6E 03 62 60 09 C2 55 E9 A9 67 72 40 3F 00 9C
    > ~.....1.y..0.... 7E 9F 90 FF 85 9A 31 C5 79 BA ED 30 BC DF CC 9D
    > c....F...N...R3 63 D9 ED C7 9F 46 FB 8A BC 4E CA 9A 9A 52 33 20
    > ...^(....`T.{6.} F9 88 C6 5E 28 E6 13 B6 8A 60 54 94 7B 36 B6 7D
    > ..w..C...34ay[.. DF B1 77 F4 13 43 CF AF B1 33 34 61 79 5B 92 B5
    > |*..|......OJ.l> 7C 2A 05 F1 7C 99 01 1B 98 FD 12 4F 4A 94 6C 3E
    > `&_....$.g..'D.. 60 26 5F 95 F8 D0 89 24 85 67 C6 1F 27 44 D2 EE
    > .e....F.x....-.. CF 65 ED FF 07 C7 46 A1 78 16 0C ED E9 2D 00 00
    > ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    > : : :
    > : : :


    This isn't padding at all, but actual data being returned by NCP. I don't
    know why these queries have so much 'blank' data, but without more context
    there's little to tell me what exactly was being requested by the client?

    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==== Read up on Usenet etiquette: http://www.faqs.org/usenet/index.html ====

  5. Re: NCP protocol padding packets?


    On 16 Feb 2005 06:32:58 -0800, "Not A Netware Guy"
    wrote:

    > .;..........Stan CB 3B 04 00 00 00 08 00 00 01 00 00 53 74 61 6E
    > dard Jet DB..... 64 61 72 64 20 4A 65 74 20 44 42 00 00 00 00 00


    That's MS Access, isn't it?

    Access is notorious for doing network-unfriendly things and for poor
    performance on networks.

    Are you sure it's not Access causing the problem?

    regards
    Marcus


  6. Re: NCP protocol padding packets?

    It seems that this is across several applications. Also, my decode
    indicates that there are ~1440 'extra bytes'.

    I assumed that this indicated that there was padding going on.

    Over 50% of the network traffic is composed of these extra bytes, so it
    would be nice to get rid of it.

    I'll look into this to determine where this is in the communications
    process.


  7. Re: NCP protocol padding packets?

    On 17 Feb 2005 09:58:41 -0800, Frank.Walters@gmail.com wrote:
    > It seems that this is across several applications. Also, my decode
    > indicates that there are ~1440 'extra bytes'.


    Could this be a side effect of Nagle mode trying to make full packets by
    putting smaller ones together to make big ones?


    --
    | David Gersic www.zaccaria-pinball.com dgersic_@_niu.edu |
    | Programming is the only art form that fights back. |
    | Email address is munged to avoid spammers. Remove the underscores. |

  8. Re: NCP protocol padding packets?

    In article ,
    David Gersic wrote:
    >On 17 Feb 2005 09:58:41 -0800, Frank.Walters@gmail.com wrote:
    >> It seems that this is across several applications. Also, my decode
    >> indicates that there are ~1440 'extra bytes'.

    >
    >Could this be a side effect of Nagle mode trying to make full packets by
    >putting smaller ones together to make big ones?


    No. According to the NCP (over IP) header, the syetem is sending a 812 (hex)
    byte response over TCP. The end of this specific response is actually in
    the next TCP packet. Whatever is being requested has the size of 2K (800
    hex) bytes. Add a header and you get what you see.

    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==== Read up on Usenet etiquette: http://www.faqs.org/usenet/index.html ====

  9. Re: NCP protocol padding packets?

    On 17 Feb 2005 19:20:45 GMT, Patrick Klos wrote:
    > In article ,
    > David Gersic wrote:
    >>On 17 Feb 2005 09:58:41 -0800, Frank.Walters@gmail.com wrote:
    >>> It seems that this is across several applications. Also, my decode
    >>> indicates that there are ~1440 'extra bytes'.

    >>
    >>Could this be a side effect of Nagle mode trying to make full packets by
    >>putting smaller ones together to make big ones?

    >
    > No. According to the NCP (over IP) header, the syetem is sending a 812 (hex)
    > byte response over TCP. The end of this specific response is actually in
    > the next TCP packet.


    On this packet, yes, but I was thinking of his general complaint/question
    of packets being "padded" with something. Perhaps the decode analysis is
    not accurately identifying what's in the packets.

    --
    | David Gersic www.zaccaria-pinball.com dgersic_@_niu.edu |
    | Newspaper headline: L.A. Voters Approve Urban Renewal By Landslide |
    | Email address is munged to avoid spammers. Remove the underscores. |

+ Reply to Thread