dcr0@harvey.gte.com (David Robbins) (04/09/91)
We have a peculiar Ethernet protocol that I am considering porting to A/UX. Question: does there exist a capability to speak to the Ethernet driver on A/UX 2.0 at a level more primitive than a raw IP socket? Something along the lines of Sun's NIT or the Berkeley enetfilter (aka Ultrix 4.0 packetfilter)? Or has Apple carefully hidden the Ethernet interface behind TCP/IP in order to idiot-proof it (and, in the process, rendering it less useful for us weirdos)? -- Dave Robbins GTE Laboratories Incorporated drobbins@bunny.gte.com 40 Sylvan Rd. ...!harvard!bunny!drobbins Waltham, MA 02254 CYA: I speak only for myself; GTE may disagree with what I say. -- Dave Robbins GTE Laboratories Incorporated drobbins@bunny.gte.com 40 Sylvan Rd. ...!harvard!bunny!drobbins Waltham, MA 02254 CYA: I speak only for myself; GTE may disagree with what I say.
urlichs@smurf.sub.org (Matthias Urlichs) (04/11/91)
In comp.unix.aux, article <10944@bunny.GTE.COM>,
dcr0@harvey.gte.com (David Robbins) writes:
< We have a peculiar Ethernet protocol that I am considering porting to A/UX.
< Question: does there exist a capability to speak to the Ethernet driver on
< A/UX 2.0 at a level more primitive than a raw IP socket? Something along the
< lines of Sun's NIT or the Berkeley enetfilter (aka Ultrix 4.0 packetfilter)?
< Or has Apple carefully hidden the Ethernet interface behind TCP/IP in order to
< idiot-proof it (and, in the process, rendering it less useful for us weirdos)?
Hmm, the Device Driver's kit has source code to the Ethernet driver, which
has something called ETHERLINK in it, which seems to do what you want. Search
for ETHERLINK in the header files (/usr/include/*/*).
Caveat (from said source code): if you open an [AP]F_ETHERLINK socket, you'll
have to bind an IP address to it so that it can find the correct interface to
send to.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/tony@tui.marcam.dsir.govt.nz (Tony Cooper) (04/11/91)
< lines of Sun's NIT or the Berkeley enetfilter (aka Ultrix 4.0 packetfilter)? Grab the source for the Sun enetfilter from rutgers.edu (128.6.4.7 or 128.6.21.9) and give it a go. One of these days I will do just that but I have a zillion other things to do right now. I recommend the Sun version cos it is the most modern version I can find. I also have the source to the original Stanford version if you want that too. From memory that is a Vax version. Seeing as the Sun and the Vax versions are similar I would bet 50 cents that the "A/UX version" would be similar. I don't think you need to know about hardware. I think you just grab the bytes from the mbufs. I don't know about using promiscuous mode - maybe that needs some hardware information. Anyway, being promiscuous will give you AIDS eventually. Cheers, Tony Cooper
ksand@Apple.COM (Kent Sandvik, 120dB or more) (04/12/91)
In article <!RX_3+_@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.unix.aux, article <10944@bunny.GTE.COM>, > dcr0@harvey.gte.com (David Robbins) writes: >< We have a peculiar Ethernet protocol that I am considering porting to A/UX. >< Question: does there exist a capability to speak to the Ethernet driver on >< A/UX 2.0 at a level more primitive than a raw IP socket? Something along the >< lines of Sun's NIT or the Berkeley enetfilter (aka Ultrix 4.0 packetfilter)? >< Or has Apple carefully hidden the Ethernet interface behind TCP/IP in order to >< idiot-proof it (and, in the process, rendering it less useful for us weirdos)? >Hmm, the Device Driver's kit has source code to the Ethernet driver, which >has something called ETHERLINK in it, which seems to do what you want. Search >for ETHERLINK in the header files (/usr/include/*/*). >Caveat (from said source code): if you open an [AP]F_ETHERLINK socket, you'll >have to bind an IP address to it so that it can find the correct interface to >send to. Funny, I was reading the same stuff today, yes you could dive down all the way to the ethernet packet level with the example Ethernet device driver. A word of warning, the A/UX dev. driver kit is for A/UX 2.0, and u_phys has changed, and there are some header file changes. It could happen that the dev. driver kit works OK with most of the 2.0.1 headers/object files, but the object code will link together a 2.0 kernel, and that's not exactly what you want for testing on a 2.0.1 system. Kent -- Kent Sandvik, DTS junkie
paul@taniwha.UUCP (Paul Campbell) (04/13/91)
In article <13022@goofy.Apple.COM> ksand@Apple.COM (Kent Sandvik, 120dB or more) writes: > >A word of warning, the A/UX dev. driver kit is for A/UX 2.0, and u_phys >has changed, and there are some header file changes. It could happen >that the dev. driver kit works OK with most of the 2.0.1 headers/object >files, but the object code will link together a 2.0 kernel, and that's >not exactly what you want for testing on a 2.0.1 system. > Every time I go to a developers conference I rail about the A/UX people changing the kernel data structures out from under developers feet all the time - it's really simple - if you are going to remove/reuse a data structure field by all means do it BUT LEAVE A PAD IN ITS PLACE don't change the offsets to all the other stuff. However everyone nods their heads wisely, sais that they understand the problem and nothing ever seems to change. Can you imagine the havoc it would cause if the MacOS systems people started popping fields out of say Window structures - every MacOS application in the world would break if you did you would get fired!! Well when you do it to us developers in the A/UX world it's just as bad (there are just fewer of us). I figure that getting upgrades to all my users last time you did this cost me about $1,000 (out of my pocket) - and you didn't actually change anything that really affected me (someone just snuck a new field into the middle of the tty structure instead of put it at the end). It's about time we came up with some guidelines for binary compatability a good start would be for Apple Q/A to verify offsets key fields within key data structures and make sure that they don't change from release to release - perhaps developers could nominate the ones that they really care about and we could all come to some agreement Flame off. BTW CommCard drivers don't use anything after u.u_phys so the 2.0 drivers (our version 2.5.2) work under 2.01 too - but I'm sure someone else somewhere is tearing their hair. Paul Campbell Taniwha Systems -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P "But don't we all deserve. More than a kinder and gentler fuck" - Two Nice Girls, "For the Inauguration"