From: CSBVAX::MRGATE!INFO-VAX-RELAY@KL.SRI.COM@SMTP 3-AUG-1988 21:36 To: ARISIA::EVERHART Subj: re: IOSB.SIZE on DELQA QIO's Received: from Venus.YCC.Yale.Edu by KL.SRI.COM with TCP; Tue, 2 Aug 88 09:01:48 PDT Date: Tue, 2 Aug 88 12:02 EST From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: re: IOSB.SIZE on DELQA QIO's To: killer!tness7!ninja!sys1!reden@ames.arc.nasa.gov, INFO-VAX@KL.SRI.COM X-VMS-To: IN%"killer!tness7!ninja!sys1!reden@ames.arc.nasa.gov",INFOVAX I'm currently writing a program to monitor ethernet packets by putting the DELQA in promiscuous mode. Everything works fine for the most part, but almost all packets except DECNET (%x6003) (including LAT,XNS) return an invalid IOSB.SIZE after the QIO completes. This really has me baffeled becuase the system is putting data in my buffer, just isn't noting the count in the IOSB. I am also getting some LAT packets with a length of 0. This causes a controller error to be returned in the IOSB.STATUS field. The since the ethernet doesn't allow packets with 0 data size, something must be screwed up here too. DECNET and INTEL packets come through OK with proper SIZE and STATUS fields so I don't think it's a data formatting problem. You are probably enabling padding on the channel (NMA$C_PCLI_PAD parameter); note that padding is enabled by default. When padding is enabled, the driver inserts a two-byte "actual byte count" at the beginning of every packet before sending it (and pads the packed to at least 46 bytes) - and assumes the byte count is there on reception. Some protocols use padding (including DECNET and apparently INTEL); others do not (LAT, apparently XNS). On a promiscuous-mode channel, the driver has no way to determine which packets were padded and which were not - it simply takes your word for it. For a non-padded message, the result is that the first two bytes of data are interpreted as the length, producing nonsense results. Worse, ON SOME VER- SIONS OF VMS A LONG APPARENT "LENGTH" CAN CAUSE THE DRIVER TO OVERWRITE IM- PORTANT STUFF IN MEMORY. The result is a crash. Do NOT run your program again until you have fixed this! When padding is turned off, the count the driver returns is the actual number of bytes that came of the wire. For padded protocols, this will INCLUDE the leading count and any trailing padding the sender added. -- Jerry