• Please review our updated Terms and Rules here

8-bit ISA Bootable Ethernet Adapter with ATAoE

Mike Chambers said:
Yeah, I did it so fast because this is something I've been meaning to create for years anyway! :)

If you guys go to the vintage programming subforum, I just created a new thread in there calling for NetDrive testers! And yes, eeguru network card sharing has been one of my goals from the beginning. It doesn't do it yet, but it will soon. Sharing the packet driver with other software tranparently should be straight-forward enough to do.
Click to expand...

What would be the best way to accomplish that? Two separate MAC addresses would be ideal - one for the virtual disk, one for user. However most NICs won't support that non-promiscuously unless you overloaded a multicast address or something. So how would you decide which frames are destined for the virtual drive code and which are for the user?
 
A lot of the older NICs handle promiscuous mode just fine. There is usually a packet driver option to enable or disable it.

One way to do it is to simply only call the INT13 packet receiver routine when an interesting packet arrives. (Presumably that would be done by the ethernet packet type.) This can be done by putting a "shim" receiver ahead of any other receiver, and let the shim decide how to forward it on.

(A poor mans TCPDUMP that works transparently with any packet driver application would work like that. It would look like a shim, presenting a packet driver interface to the application code while filtering anything coming from the real packet driver.)
 
mbbrutman said:
A lot of the older NICs handle promiscuous mode just fine. There is usually a packet driver option to enable or disable it.
Click to expand...
Yes but soft-filtering every-frame on an XT makes me shudder - even at 10Mbps. With a single frame address, you could certainly filter on the image server address first - passing everything that doesn't match. However it would be nice to find a clever way of differentiating virtual drive frames from everything without having to peer too far into the payload. A multicast address works assuming the NIC has a hash based filter table. Without an IGMP join, it should be harmless enough on most networks with non-IGMP aware switches. Overloading one of the frame protocol enumerations works too.
 
mbbrutman said:
A lot of the older NICs handle promiscuous mode just fine. There is usually a packet driver option to enable or disable it.

One way to do it is to simply only call the INT13 packet receiver routine when an interesting packet arrives. (Presumably that would be done by the ethernet packet type.) This can be done by putting a "shim" receiver ahead of any other receiver, and let the shim decide how to forward it on.

(A poor mans TCPDUMP that works transparently with any packet driver application would work like that. It would look like a shim, presenting a packet driver interface to the application code while filtering anything coming from the real packet driver.)
Click to expand...

Exactly, Mike.

eeguru: you'd be surprised, there wouldn't really be any noticeable performance hit. I am already examining/comparing the ethertype of every single packet already and simply discarding the ones that don't match the one for NetDrive. The only difference would be passing it along to any user programs that ask for them.
 
eeguru said:
Yes but soft-filtering every-frame on an XT makes me shudder - even at 10Mbps. With a single frame address, you could certainly filter on the image server address first - passing everything that doesn't match. However it would be nice to find a clever way of differentiating virtual drive frames from everything without having to peer too far into the payload. A multicast address works assuming the NIC has a hash based filter table. Without an IGMP join, it should be harmless enough on most networks with non-IGMP aware switches. Overloading one of the frame protocol enumerations works too.
Click to expand...

I'm not sure how compliant most of the hardware is with respect to multi-cast. We're talking about hardware that is 20 to 25 years old in some cases.

Peeking at the payload is not a big deal. The packet driver interface that uses two interrupts for each packet received is the problem. (And one to send too!)
 
You must log in or register to reply here.
Back
Top