mckee@MITRE.MITRE.ORG (H. Craig McKee) (05/15/89)
DEC has established a facility in St. Louis to test and integrate
various security components into a system for the USAF Military
Airlift Command. (The end result of this effort is to be a system that
provides Multilevel Security.) One of the components being tested is
the Xerox Encryption Unit (XEU). The XEU is designed to be installed
in the drop cable between a processor and the transceiver, as
illustrated below.
Thicknet or Thinnet ----| MAU |----------
|<----802.3
|
| XEU |
|<----802.3
|
| DECserver 100 |
One of the problems discovered by DEC is that the XEU will not forward
short packets; as reported by DEC: "The XEU's will not forward a short
ethernet packet. During power-up and self-testing, many devices
(including DECserver 100's) create a 32 byte packet (36 bytes with
CRC). This packet is transmitted to the network. The device expects
to receive the packet back from the network. This is how the device
determines that the network is operational. Although the Ethernet
Version 2 specification and the IEEE 802.3 specification state that
the minimum length of a data packet is 64 bytes, it is quite common in
the industry to use a smaller packet for network verification
testing. Actually, the LANCE chip set which is one of the most
common ethernet chips in the world implements this test. Most network
vendors using the LANCE chip perform this minimum length packet test of
the network. [...] For the terminal server to properly start up, this
packet must be passed through the XEU and back to the terminal
server."
Questions/Comments
I don't have the LANCE spec sheet, but it seems to me the chip set
should be passive with respect to packet length; that it is the
responsibility of the driver routine to insure proper packet length.
"Most network vendors ... perform this minimum length packet test ..."
Is that true? It would imply Xerox should have done a better job
checking the compatibility of the XEU.
Any advice or comments would be appreciated. Regards - Craigjqj@HOGG.CC.UOREGON.EDU (05/16/89)
Runt Ethernet packets are a problem for a number of Ethernet implementations. There is in fact a very good reason why the spec includes a minimum length; it's needed to insure that all stations detect a collision during packet reception. Without it, a collision that is noticed at one end of a cable may not be noticed at the other end. If DEC is in fact generating short packets, then they are in violation of both the 802.3 and Ethernet specs. I expect they will lose a few major RFPs as their competitors point out that they are not meeting the requirements. Unless, of course "Everybody does it".
eshop@saturn.ucsc.edu (Jim Warner) (05/17/89)
In article <8905151510.AA00477@mitre.arpa> mckee@MITRE.MITRE.ORG (H. Craig McKee) writes: > >Questions/Comments > >I don't have the LANCE spec sheet, but it seems to me the chip set >should be passive with respect to packet length; that it is the >responsibility of the driver routine to insure proper packet length. Remember that Ethernet is half-duplex. A station cannot send and receive at the same time. To be able to do so, Ethernet chips would have to be more complicated than they are. And their DMA circuitry would have to be able to support twice the data rate. The LANCE chip has enough ram in its Silo to receive the first 32 bytes of a packet when it is in loopback mode. Basicly, the test is to send a runt 32 byte packet and then read what is in the Silo to see if it is what was sent. A problem with this test is that the interface can't determine if a failure might be due to faulty hardware or because the runt suffered a collision. Perhaps this is part of the reason that the spec sheet encourages that the test be run several times in case of a failure before declaring the hardware nonfunctional. >"Most network vendors ... perform this minimum length packet test ..." >Is that true? It would imply Xerox should have done a better job >checking the compatibility of the XEU. I sorta doubt that this statement is true. I have a handly little transceiver cable breakout box that I can use to open the collision sense pair in the transceiver cable. What I've found is that most vendors ignor a missing heartbeat. I think that, except for DEC, most vendors are pretty sloppy about looking for errors. Still I think that if Xerox is going to stick something in the transceiver cable, they need to provide the local echo "just like a transceiver." I agree that it sounds like they didn't do their homework. >Any advice or comments would be appreciated. Regards - Craig ++++++++++ Please include standard disclaimer here +++++++++++++++++
tom@rsp.UUCP (Thomas Ruf) (05/17/89)
In article <8905151510.AA00477@mitre.arpa>, mckee@MITRE.MITRE.ORG (H. Craig McKee) writes: > ..... During power-up and self-testing, many devices > (including DECserver 100's) create a 32 byte packet (36 bytes with > CRC). This packet is transmitted to the network. The device expects > to receive the packet back from the network. This is how the device > determines that the network is operational. .............. > ..... > I don't have the LANCE spec sheet, but it seems to me the chip set > should be passive with respect to packet length; that it is the > responsibility of the driver routine to insure proper packet length. The LANCE is a half duplex device, which is sufficient for normal Ethernet operation. If you want to perform an external loopback test, as DEC does it during power-up, you need full duplex. Therefore, the LANCE has a special "external loopback test mode" which allows simultaneous send and receive operation. However, due to the size of the fifo, the packet length is limited to 36 bytes. Thomas -- Thomas Ruf Schneider & Koch GmbH {uunet,mcvax}!unido!rsp!tom West-Germany