RE: ethernet driver
Brought to you by:
aeb,
bencollins
From: Rodney R. <re...@de...> - 2000-05-03 00:16:21
|
I have some code that I am willing to share. It began with the Ethernet encapsulation driver draft by Emanuel Pirker <ep...@ed...> incorporating a hunt for viable peer layer to talk to among the nodes. But that's the only real simularity. I intended it to be able to talk to Mac and Windows boxes, not just other Linux boxes and here, in a nutshell, is how it works: There are two channels set up in the address space of each node: the ether channel, where packets are transfered, and a common address resolution channel. First, at boot a shell script provides the ARP channel address # that all boxes will know. This is set with ioctl's socket extension enum: SIO_PRIVATE. This address is used to do a read-query on all nodes during this time and at any time bus reset occurs. Any remote replies return an ether HW address(which comes from the ROM's GUID) and an address # that has been successfully allocated on the remote for ether packet exchange. This information is cached in the devices private ARP table. When a packet is transmitted the ether HW destination is read and looked up in this ARP table and sent to the appropriate node. If the HW address is the broadcast value then all nodes are engaged. The code has not been built or tested and a few issues remain: 1) Should a queue be maintained during the internal ARP for packets leaving the ifc. 2) The Little/big endian issue in a mixed environ currently has all big endian boxes swapping bytes to maintain binary compatablity, this causes a dependency on the low-level HW driver since OHCI allows for byte swapping. 3) I don't think I've implemented broadcast correctly and a few functions are still incomplete 4) raw1394 seems to undergone some success, it might be better to use its treatment of the under-layer since there is a potiential deadlock when a layer does not maintain its own serialization objects. 5) If an unrecognized HW address is found an globally incomplete ARP table is indicated, should private ARP be attempted from this point also or request a bus reset? The code is raw but I think structurally operable. I've had little time of late to go forward with it and hoped to set up CVS on my own www server and solicit contribitors. Until then, anyone wishing to go forward I will be happy to email them the work. Rodney -----Original Message----- From: Frederic Villeneuve [mailto:fv...@ho...] Sent: Tuesday, May 02, 2000 8:48 AM To: Franck Bonin Cc: lin...@li... Subject: Re: ethernet driver Hello, I was thinking about working on IP over 1394 . I would be willing to participate to that project. Do you have the source code available ? Frederic Villeneuve ----- Original Message ----- From: "Franck Bonin" <fra...@ya...> To: <lin...@li...> Sent: Tuesday, May 02, 2000 4:21 AM Subject: ethernet driver Since few weeks, I write an encapsuted ethernet driver on the top of the linux ieee1394 subsystem. By using the old 0.5 version of modules with 2 adaptec boards : Hot Connect 8920, I was able to transfer data twice as fast as on common ethernet interface. But, I found some problems using the linux ieee1394 subsystem. First, I was not able to find a way to transfer data using ``unified'' write transactions. So I make few modifications in the ieee1394 core module. The Hot Connect 8920 board use S200 speed bus. So the max payload data on a single paquet must be 1024 bytes. But, to avoid kernel freezing, I reduce the size of ethernet paquet to 200 bytes. If not, after some times, strangness append in the low level driver ``aic5800'', this could freeze the 2 computers. ---------- Last week, I recieved 2 ADS PYRO OHCI boards. So I download last CVS version of modules and libraw. After succesfull installation and tests, I rebuild my ethernet driver, using the new subsystem. And unfortunatly I found other strange problems. 1. ``insmoding'' 2 times the ohci modules freezing one or the other computer... 2. My ethernet driver is working (vor exemple, flood ping is OK) but other kind of programs like ftp or telnet don't work well: for an unknown reason, after a few time, the ohci driver (or the board ?) stop recieve (or transmit) paquets, while it still can transmit (or receive) some other paquets like ARP ones. And of course, some times it crach ! ___________ An other question : Now, I will work on isochronous transmissions and video stream. But unfortunatly, I have not any camrecorder. So does anyone know the way to make believe others nodes that my PC-linux is a camrecorder ? ---- Thanks for any comment or answer. Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |