Date: Thu, 22 Jul 1999 16:36:42 -0400 (EDT) From: wpaul@ctr.columbia.edu (Bill Paul) To: jflowers@ezo.net (Jim Flowers) Cc: skip-info@skip-vpn.org, freebsd-security@freebsd.org Subject: Re: wi driver with SKIP Message-ID: <199907222036.QAA27461@startide.ctr.columbia.edu> In-Reply-To: <Pine.BSI.3.91.990722123700.26379A-100000@lily.ezo.net> from "Jim Flowers" at Jul 22, 99 04:22:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Jim Flowers had to walk into mine and say: > Thanks for the response. Sorry for the hypertext. A new portable not > fully configured yet. See comments below. Gotta watch those defaults. > > Hm. My understanding is that in an Ethernet II frame, the type field > > represents the payload type in the frame, which can be IP, ARP, reverse > > ARP, to name a few. If SKIP packets have a different kind of header > > than IP, then the frame type will be different from IP (which is 0x800). > > SKIP encapsulates the original packet and prepends a new IP header and > recalculates the header checksum. The 8-bit protocol field is 57. > Should look like a normal IP packet to the link layer. Just not TCP or > UDP. > > Note the problem is in the outbound direction so I don't quite see how > the Ethernet II type field would be wrong. Isn't this determined by the > wi driver and hardware? The host creates the ethernet frame header, including the destination address, source address and ethernet frame type. There are different frame types for different kinds of packets: #define ETHERTYPE_PUP 0x0200 /* PUP protocol */ #define ETHERTYPE_IP 0x0800 /* IP protocol */ #define ETHERTYPE_ARP 0x0806 /* Addr. resolution protocol */ #define ETHERTYPE_REVARP 0x8035 /* reverse Addr. resolution protocol */ #define ETHERTYPE_VLAN 0x8100 /* IEEE 802.1Q VLAN tagging */ #define ETHERTYPE_LOOPBACK 0x9000 /* used to test interfaces */ /* XXX - add more useful types here */ Like I said: the RFC1042 encapsulation is only done for IP, ARP and Reverse ARP frame types: if for some reason the SKIP software is using a different ethertype then the encapsulation won't be done and the packets will appear bogus on the other end. The receive decapsulation works because the WaveLAN tells the host ahead of time of the received frame has a SNAP header or not. If you look at the SKIP source you might actually be able to determine if this is the case. I don't have the SKIP source but you do (you must have or you wouldn't have been able to make it work with FreeBSD) so it's up to you to look. > > As to why it works when the packets originate on another interface, > > I'm not sure. I can only assume that in that case, the packets are > > tunneled through IP, in which case the ethertype is correct and > > wi_start() passes them correctly. > > Well, I think I misrepresented this. What works is to install SKIP on a > FreeBSD Ethernet interface (lnc1) and then connect this to a WaveLAN/EC > converter that then communicates with the Windows 98 skiphost. No wi driver > involved but it is what leads me to think that the W98 implementation is > OK. *sigh* You never mentioned a WaveLAN/EC before. > Before I try hacking the driver, No. You should try hacking the driver first, because it would take you a very short amount of time and it would satisfy my burning curiosity. You could even attempt to prove or disprove my theory by adding a single printf() in wi_start() which prints the ethertype field out so that you can see what it thinks it is. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Department of Electrical Engineering Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "Mulder, toads just fell from the sky!" "I guess their parachutes didn't open." ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907222036.QAA27461>