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