Subject: Re: Networking strangeness Solution?
From: Brian Foddy (bkfoddy@soc.nwa.com)
Date: Tue May 09 2000 - 14:08:26 MDT
One more thing I've wondered before. There have been
numerous threads here about using the Ethertap and
IP Masquerading feature of Linux to masq all the traffic
for MOL. Its generally been promoted as a solution when
people are unable to create a seperate IP address for MOL,
DHCP for instance. I've personally never tried setting it
up because I have always been able to dedicate a second
public ip address for MOL. But I've wondered if that
solution would solve this problem also. I've asked before
on this list but never received a convincing answer and
haven't had time to try it myself. And would it work
for Appletalk as well as IP. Thoughts?
I'd be more volunteering to help with some of the
kernel/module programming, but I've never ventured into
UNIX kernel-land before, I keep all my development tasks
in user space. Not that I'm not interested...
Brian
Charles McLachlan wrote:
>
> On Tue, 09 May 2000, you wrote:
>
> > My (kernel newbie's) intuition is that there's a layering problem in how
> > the sheep_net driver's doing it's job.
>
> Spot on. See my post to Brian for fully details
>
> > Similar products, like VMware (www.vmware.com), don't have this kind of
> > difficulty.
>
> But they use a similar mechanism, a kernel module feeds packets into a user
> land process that feeds them onto a network driver running on the virtual
> machine.
>
> > I've done some
> > coding for this kind of thing on VMS, and I'd be happy to take a crack at
> > the Linux flavor: can anyone point me at a document that describes how
> > the Linux kernel does internal packet routing?
>
> The sheep_net code is actually very simple (I think). It just reads /dev/eth0,
> spools the packets and waits for someone (i.e. the osi_enet driver) to read from
> /dev/sheepnet.
>
> osi_enet seems to do pretty mush exactly the same thing, it reads from
> /dev/sheepnet, spools and waits for LinuxOSIGetPacket from the Mac driver.
> The virtual Mac is told about waiting data by a spoofed irq transition.
>
> In my nieve way I can see a few things that might jolly things along.
>
> 1) Cut out the spool in osi_enet. Have a thread in MOL that polls /dev/sheepnet
> and spoofs an irq when there's data ready. Then, when the Mac calls
> LinuxOSIGetPacket, thats when you do the read on /dev/sheepnet.
>
> 2) (I'm not totally sure on this one as I am vague about all the
> nuances of sheep_net's operation) Cut out sheep net for reading entirely. Get
> osi_enet to poll/ read directly on eth0. (Would this upset other things using
> eth0?)
>
> 3) Put a timeout on spoofing irqs up to the Mac. The Mac's STREAMS driver gets
> bogged down if too many irqs come too quickly so maybe get osi_enet to
> collect packets into groups and send one irq per group. (Will this work, or is
> it one irq per packet?)
>
> 4) Get the Mac STREAMS module to grab more memory (so it can deal with more
> packets before barfing).
>
> By the way, I really have no idea about what I'm talking about, this is my
> first venture into network/ kernel module/ STREAMS hackery so please don't
> freak if I'm talking dreck.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Charlie McLachlan
> AT&T Research Lab. Cambridge.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This archive was generated by hypermail 2a24 : Tue May 09 2000 - 14:10:38 MDT