[comp.os.vms] IOSB.SIZE on DELQA QIO's

reden@sys1.TANDY.COM (07/28/88)

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. 


  If anyone knows what I'm missing or can confirm the VMS bug, please let me
know....


robert Eden							reden@sys1.uucp

LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (08/03/88)

	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

gkn@SDS.SDSC.EDU (Gerard K. Newman) (08/03/88)

	From:	 killer!tness7!ninja!sys1!reden@ames.arc.nasa.gov
	Subject: IOSB.SIZE on DELQA QIO's
	Date:	 28 Jul 88 15:21:00 GMT

	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. 


	  If anyone knows what I'm missing or can confirm the VMS bug, please let me
	know....

Have you got padding turned off?  To do promiscuous mode properly with the
XEDRIVER one must set the parameter NMA$C_PCLI_PAD off.  This used to produce
a system crash at the MOVC3 in BUFPOST when you didn't, but it has since been
fixed, apparently.

Take a look at the I/O Users's Guide Part II in the chapter dealing with the
ethernet/IEEE 802 drivers.  You're interested in IO$_SETMODE.

gkn
----------------------------------------
Internet: GKN@SDS.SDSC.EDU
Bitnet:   GKN@SDSC
Span:	  SDSC::GKN (27.1)
MFEnet:   GKN@SDS
USPS:	  Gerard K. Newman
	  San Diego Supercomputer Center
	  P.O. Box 85608
	  San Diego, CA 92138-5608
Phone:	  619.534.5076