[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:FDDI - The Next Generation
Moderator:NETCAD::STEFANI
Created:Thu Apr 27 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2259
Total number of notes:8590

188.0. "DECBridge 500 treatment of invalid 802 frames" by STAR::STOCKDALE () Thu Dec 13 1990 15:10

What is done with 802 frames coming into a 10-100 bridge from the Ethernet
side which are invalid because of extra padding bytes?  Does the bridge
discard because they are invalid or does it ignore extra padding bytes (when
forwarding onto the FDDI side)?

Can anyone answer - or point me to some bridge documentation or the bridge
developers?

Thanks.

- Dick
T.RTitleUserPersonal
Name		DateLines
188.1KONING::KONINGNI1D @FN42eqThu Dec 13 1990 18:3717
    Currently it discards them.  This is actually the subject of discussion
    as we speak.  The reason why we chose discarding the frames is that
    such frames violate 802.3.  When the sender violates the spec, you
    can't know what the actual intent was.  Is the length right and the
    frame was padded erroneously?  Or is the frame all data and the length
    field is bad?
    
    Discarding "extra" bytes means assuming the former, i.e., the length
    field was correct and the extra bytes were where the error is.  If the
    actual mistake was the other one (wrong value in the Length field) then
    you've just corrupted the user data.  Depending on the application,
    this could have very serious consequences.
    
    So the decision was to discard illegal packets rather than to guess at
    the "real" intent and potentially corrupt data in doing so.
    
    	paul
188.2KONING::KONINGNI1D @FN42eqThu Dec 13 1990 18:375
    By the way, was that a "general interest" question or does it relate to
    an actual problem?  If it has any connection to a customer problem or
    issue, PLEASE let us know.
    
    	paul
188.3The problem seen thus farSTAR::STOCKDALEMon Dec 17 1990 09:328
There is some PC hardware (supported by Novell) which, to conform to the needs
of other now extinct PC hardware, automatically padded all non-even-byte-count
frames with an extra byte.  And so, applications talking to this hardware using
a VAX with a DEBNI/DEMNA may fail since the DEBNI/DEMNA would discard the
invalid frames.  The solution so far is to patch the driver to enable
receipt of the frames.

- Dick
188.4KONING::KONINGNI1D @FN42eqMon Dec 17 1990 14:443
Ugh.  Wish we'd known of that sooner!

	paul