CSYSMAS@OAC.UCLA.EDU (Michael Stein) (11/20/89)
Anyone using IBM's RT w/AOS (BSD based UNIX) on Token Ring?
I have an IBM RT (RISC processor) running IBM's AOS operating
system which is derived from BSD 4.3 UNIX.
The Token Ring interface code looses the last byte of an incoming
1500 byte IP packet (IP length of 1500) when the routing field is
long (6 entries). This cause TCP checksum errors, which makes
FTP's fail.
It appears that the LAN interface routine is initializing
the receive DMA length to the sum of:
MAC header length (maximum including max routing field)
LLC header length (8)
the interface MTU (1500 just like Ethernet)
Increasing this length by 3 seems to fix the above problem
(didn't try 1).
The above length (even +3) is still wrong as the ARP code sets
the "largest frame bits" to 010. This "claims" that the RT/AOS
will accept token ring frames with up to 2052 bytes of data
(exclusive of the TR MAC fields including the routing fields).
This would allow an IP packet of up to 2052 - 8 bytes of IEEE/LLC
=> 2044.
So while it seems legal for the code to limit the size of the IP
packets it sends to the MTU of 1500, it should be able to receive
packets which are larger.
The DMA is going into a "page" MBUF buffer. It's not clear that
it could hold 2044 bytes of data (so just increasing the receive
DMA length isn't a solution).
Changing the advertised Token Ring frame size to 1500 (the next
smaller size) doesn't sound like a good idea as that would
require 1500 byte IP packets routed from an Ethernet to be
fragmented (because of the LLC header on Token Ring).
I'd like to know the following:
1. Why does the original code seem to have the correct DMA
length for 1500 bytes packets, but in reality is one short?
2. Does the receive code need to be able to handle 2044 byte
IP packets (2052 byte frames)? If so, does anyone have
any suggestions (the page buffers my be only 2048 bytes
long).
3. Any other comments?brunner@ibmpa.UUCP (MH 6.6, Eric Brunner) (11/21/89)
Michael, I'm maintaining IBM's 4.3 release for the RT (actually the 6150, 6151, and 6152) platform. This looks like an APAR (real bug in the local lexicon) that I'd like to see and fix. Lets take this out of the tcp-ip list and work on it via email. BTW list co-readers, if you've IBM workstations running IBM/4.3 (aka "AOS", and "ACIS"), and you've a problem that either dosen't seem to make its way through the system, or if your site somehow dropped out of contact, drop me a note - you're not alone! Some 20 fixes have been posted to comp.sys.ibm.pc.rt, and an archive is available for anonymous ftp on bikini.cis.ufl.edu [128.227.224.1]. Eric Brunner, Consultant, IBM AWD Palo Alto (415) 855-4486 inet: brunner@monet.berkeley.edu uucp: uunet!ibmsupt!brunner