🚀 go-pugleaf

In article <1992Nov13.171632.27991@news.uit.no>, anders@spip.cc.uit.no (Anders Baardsgaard) writes:
> 
> Does the FDDI standard require pad stripping?
> 
> This may seem like an odd question, but it is based on an actual inter-
> operability problem. This is the scenario:
> 
>                                  -----
> FDDI ----------------------------I R I------------------- 10base5
>            I            I        -----         I
>            I            I                      I
>          -----        -----                  -----
>          I A I        I B I                  I C I
>          -----        -----                  -----
> 
> Telnet from A to C doesn't work.
> 
> A packet trace on host B (tcpdump) displays TCP SYN packets going from
> A to C, and from C to A. But the TCP SYN packet from C never shows up
> on an internal packet trace on host A, and the connection fails.
> 
> Approximately once in every 5 attempts telnet succeeds in establishing
> a connection, but the session is unacceptably slow due to a high retrans-
> mission rate.
> 
> The only observed distinguishing feature between success and non-success
> in connection establishing is the packet size of the TCP SYN response
> from C to A. It succeeds when tcpdump reports 58 bytes packet size, and
> fails on 60 bytes. (The numbers are probably wrong anyway, since tcpdump
> or some OS mechanism on host B apparently transforms the FDDI snap-header
> to an "ethernet-header". The point is that they are different, and that
> the observed behavior varies consistently with the 58 vs. 60 bytes packet
> size reported by tcpdump -e)
> 
> My current hypothesis is that because the "offending" packets originate
> on an ethernet, they have a couple of bytes of padding to comply with the
> minimum packet size requirement of that medium (60+4 bytes). And that the
> router usually fails to strip these extra bytes when forwarding the packets
> onto the FDDI ring.
> 
> The question is: should it pad strip every packet? Or can an FDDI packet
> contain any amount of padding as long as it doesn't violate the 4.5k limit?


In short, no.
What could A or B rely on to strip the ethernet padding?

I guess "R" must be some kind of bridge.  A bridge cannot fiddle with
the contents of the ethernet packets, because there is no length field
in an ethernet packet.  (Yes, there is 802.3, but almost no one uses it
for TCP/IP.) If "R" is a router, then R could and should removing the
ethernet padding, but things should still work fine if it does not.
I'd be leary of any bridge that stripped the padding from some frames
but not others.

A and B must be able to talk to C regardless of whether R is an IP
router or a bridge.  If your diagnosis is right, than the problem must
be in A.  A reasonable TCP/IP/FDDI host must be willing to discard a
reasonable number of pad bytes.

Your best hope for figuring out what is going on is to use network
monitors on the ethernet and FDDI that do not mess with the incoming
packets.  If you evidently hadn't already made the wrong decision on
which hosts to buy, I'd suggest getting the network analyzing software
for my employer's workstations.  However, all is not lost, since I
think some of the dedicated network analyzers now have FDDI
interfaces.


Vernon Schryver,  vjs@sgi.com