dlw@VIOLET.BERKELEY.EDU (David Wasley) (10/04/88)
This seems to have been introduced in 8.0 - is there a (good) reason for this? I realize the U-B code is ill behaved, but there is a lot of it out there on our net. Would it be hard to go back to the smaller pads? David --- From gts@mica.berkeley.edu Sat Oct 1 15:20:16 1988 Date: Sat, 1 Oct 88 15:23:16 PDT From: gts@mica.Berkeley.Edu To: austins@mica.Berkeley.Edu, cliff@cmsa.Berkeley.Edu, mtxinu!kinetics!minshall@mica.Berkeley.Edu Subject: Re: tn3270 Proteon Problem Cc: dlw@violet.berkeley.edu, gts@violet.berkeley.edu, msawyer@violet.berkeley.edu The problem is that the Proteon is now padding short IP packets to 64 byte Ethernet packets instead of 60 bytes (minimum Ethernet packet size). This also occurs on Sun clients and some MicroVax ethernet interfaces. Does anyone know where this bad habit is comming from?! The UB TCP-PC code does not accept Ethernet packets with junk bytes at the end (except one odd pad byte). The new release allows up to 128 junk pad bytes but will not likely be in wide use until late this year. This will impact PC connections connections to ALL hosts off the 152 subnet. Anytime an IP packet of length 46-48 (tcp data 6-8) is sent through the Proteon to a PC, the PC will ignore it. Progress can only be forced by typing such input as will eventually cause the host to resend the data in a larger packet. IP Packet Size Ethernet Packet Size Proteon Ethernet Packet Size 40 60 (6 pad bytes) 64 (10 pad bytes!) 41 60 (5 pad bytes) 64 ( 9 pad bytes!) 42 60 (4 pad bytes) 64 ( 8 pad bytes!) 43 60 (3 pad bytes) 64 ( 7 pad bytes!) 44 60 (2 pad bytes) 64 ( 6 pad bytes!) 45 60 (1 pad bytes) 64 ( 5 pad bytes!) 46 60 ( pad bytes) 64 ( 4 pad bytes! UB TCP-PC Rejects) 47 60 ( pad bytes) 64 ( 3 pad bytes! UB TCP-PC Rejects) 48 60 ( pad bytes) 64 ( 2 pad bytes! UB TCP-PC Rejects) 49 60 ( pad bytes) 64 ( 1 pad bytes!) 50 60 ( pad bytes) 64 ( 0 pad bytes ) greg small
jas@proteon.COM (John A. Shriver) (10/04/88)
This was a mistake in the Proteon Ethernet (p4215) driver. The chipset on that board makes it the programmer's responsibility to pad the packet. The length we padded to was off by 4 (the size of the CRC). This is fixed in R8.1. It was never a problem with the old Interlan Ethernet (p4213/p4214), which did the padding for us in it's microcode. In general, IP implementations should allow for arbitrary padding of packets. For example, some versions of Wiscnet (VM) padded all packets to a fixed physical length, whatever the IP length.