Hardware related - how protocol analyzer gives frame info. - TCP-IP

This is a discussion on Hardware related - how protocol analyzer gives frame info. - TCP-IP ; Hi, The protocol analyzer software applications is able to display the Ethernet frame contents. Since the Ethernet frames are being handled at MAC level (Hardware) How does the software get the frame information? -MS...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Hardware related - how protocol analyzer gives frame info.

  1. Hardware related - how protocol analyzer gives frame info.

    Hi,
    The protocol analyzer software applications is able to display the
    Ethernet frame contents.
    Since the Ethernet frames are being handled at MAC level (Hardware)
    How does the software get the frame information?

    -MS

  2. Re: Hardware related - how protocol analyzer gives frame info.

    muthusnv@gmail.com writes:

    > Hi,
    > The protocol analyzer software applications is able to display the
    > Ethernet frame contents.
    > Since the Ethernet frames are being handled at MAC level (Hardware)
    > How does the software get the frame information?


    bits are bits.

    The driver gets the bits.
    The question is - does the driver allow applications to see these bits?
    In general, this is useful for debugging drivers. Therefore drivers
    typically allow this access.

    It's hard to debug a black box with no visibility into the inner workings.

    If you think real protocols strictly follow the layering of the ISO
    reference model, then you may be mistaken. :-)





    --
    Posted via a free Usenet account from http://www.teranews.com


  3. Re: Hardware related - how protocol analyzer gives frame info.

    On Feb 1, 9:58*pm, Bruce Barnett
    wrote:
    > muthu...@gmail.com writes:
    > > Hi,
    > > The protocol analyzer software applications is able to display the
    > > Ethernet frame contents.
    > > Since the Ethernet frames are being handled at MAC level (Hardware)
    > > How does the software get the frame information?

    >
    > bits are bits.
    >
    > The driver gets the bits.
    > The question is - does the driver allow applications to see these bits?
    > In general, this is useful for debugging drivers. Therefore drivers
    > typically allow this access.
    >
    > It's hard to debug a black box with no visibility into the inner workings.
    >
    > If you think real protocols strictly follow the layering of the ISO
    > reference model, then you may be mistaken. :-)
    >
    > --
    > Posted via a free Usenet account fromhttp://www.teranews.com


    Thanks, I agree with you.
    My question is on the Ethernet header.

    I think, the MAC (hardware) in the NIC drops the Ethernet header and
    pass only the ethernet payload to Software (driver, protocol stack).

    Since the protocol analyzer is just a software tool installed in my
    PC, how it displays the ethernet frame types (which is part of
    Ethernet header) as Ethernet-II or 802.2 or Netware 802.3...?



  4. Re: Hardware related - how protocol analyzer gives frame info.

    On Feb 5, 5:07 am, muthu...@gmail.com wrote:
    > My question is on the Ethernet header.
    >
    > I think, the MAC (hardware) in the NIC drops the Ethernet header and
    > pass only the ethernet payload to Software (driver, protocol stack).
    >
    > Since the protocol analyzer is just a software tool installed in my
    > PC, how it displays the ethernet frame types (which is part of
    > Ethernet header) as Ethernet-II or 802.2 or Netware 802.3...?- Hide quoted text -



    On the contrary, the NIC usually does *not* drop the MAC header.
    There are several reasons - first, the NIC may be listening for
    several different MAC addresses (and in the case of Ethernet, it's
    always at least one address plus the broadcast addresses), and the
    network stack often needs to be able to distinguish where a frame was
    addressed to. Second the stack in question certainly needs access to
    the type/length field. Further, some network protocols depend on MAC
    addresses (for example, traditional non-routable SNA), and need to see
    the source MAC address. In some networks, there may be additional
    information in the header as well - Token-Ring Source Routing
    information for example, although that sort of thing is fairly rare.

    So in short, the NIC cannot generically discard the MAC header
    information.

    OTOH, some NICs allow the offload of much of the IP stack processing,
    and those NICs, when supporting IP (they also usually support non-IP
    protocols via some bypass mechanism), often do hide the MAC details
    from the host. But even then there's usually a way to ask to see the
    raw packets. But a hypothetical NIC dedicated to supporting IP4 only,
    could, at least theoretically, not provide access to the MAC headers,
    but it's hard to imagine why you'd build such a thing, although there
    have been all sort of strange things done in the name of performance
    and compatibility (and in fact, I know of some mainframe NIC
    implementations that did not really provide access to raw frames, but
    they did first level protocol identification on the NIC, and appeared
    to be separate I/O devices, one for each protocol, to the host - but
    even there MAC addresses were visible).

    Now there are other parts of the frame, for example, the FCS (CRC) at
    the end, which may, or may not, be visible depending on the NIC, but
    usually we don't care about that very much.

  5. Re: Hardware related - how protocol analyzer gives frame info.

    On Feb 6, 7:34*am, "robertwess...@yahoo.com"
    wrote:
    > On Feb 5, 5:07 am, muthu...@gmail.com wrote:
    >
    > > My question is on the Ethernet header.

    >
    > > I think, the MAC (hardware) in the NIC drops the Ethernet header and
    > > pass only the ethernet payload to Software (driver, protocol stack).

    >
    > > Since the protocol analyzer is just a software tool installed in my
    > > PC, how it displays the ethernet frame types (which is part of
    > > Ethernet header) as Ethernet-II or 802.2 or Netware 802.3...?- Hide quoted text -

    >
    > On the contrary, the NIC usually does *not* drop the MAC header.
    > There are several reasons - first, the NIC may be listening for
    > several different MAC addresses (and in the case of Ethernet, it's
    > always at least one address plus the broadcast addresses), and the
    > network stack often needs to be able to distinguish where a frame was
    > addressed to. *Second the stack in question certainly needs access to
    > the type/length field. *Further, some network protocols depend on MAC
    > addresses (for example, traditional non-routable SNA), and need to see
    > the source MAC address. *In some networks, there may be additional
    > information in the header as well - Token-Ring Source Routing
    > information for example, although that sort of thing is fairly rare.
    >
    > So in short, the NIC cannot generically discard the MAC header
    > information.
    >
    > OTOH, some NICs allow the offload of much of the IP stack processing,
    > and those NICs, when supporting IP (they also usually support non-IP
    > protocols via some bypass mechanism), often do hide the MAC details
    > from the host. *But even then there's usually a way to ask to see the
    > raw packets. *But a hypothetical NIC dedicated to supporting IP4 only,
    > could, at least theoretically, not provide access to the MAC headers,
    > but it's hard to imagine why you'd build such a thing, although there
    > have been all sort of strange things done in the name of performance
    > and compatibility (and in fact, I know of some mainframe NIC
    > implementations that did not really provide access to raw frames, but
    > they did first level protocol identification on the NIC, and appeared
    > to be separate I/O devices, one for each protocol, to the host - but
    > even there MAC addresses were visible).
    >
    > Now there are other parts of the frame, for example, the FCS (CRC) at
    > the end, which may, or may not, be visible depending on the NIC, but
    > usually we don't care about that very much.


    Thanks very much for the explanation.

+ Reply to Thread