Thread: ethernet driver
Brought to you by:
aeb,
bencollins
From: <fra...@ya...> - 2000-05-02 09:30:24
|
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 |
From: <fra...@ya...> - 2000-05-02 15:40:02
|
Ok, I think I juste have to precise some few things : My driver is a study on how using IP over 1394 with less efforts. For linux, my driver is a network driver that use kernel ethernet facilities. So I have keept ethernet packet headers (and I use it). With my solution, I avoid to rewrite the ARP protocol for 1394 (I keep using the ethernet ARP protocol). But I had to choose arbitrary hardware addresses for my IEEE 1394 boards, and I had to build a very simple external protocol manage to found which node got which hardware address. Moreover, I only uses unified write transactions to transfer ethernet packets. To do that, I have just added one line in ieee1394_core.c which prevent the write response paquet to be transmitted while the CSR address of the paquet recieved match with those my driver is in charge. Of course, I write a new unified write transaction which complete when the 1394 packet is transmitted by the low-level device driver. This solution save bandwidth but might be not safe (the only acknowledgment sent for a received paquet is the 1394 link layer 8 bit ack). I think that TCP or other higher level protocol can ensure data integrity. My driver work (more or less), but is not as general as might be a real implementation of IP over 1394 using (for exemple) RFC 2734. I will soon post my source code and report bugs that I found. Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Sebastien R. <Seb...@sy...> - 2000-05-02 10:10:20
|
Good to hear that IP over 1394 is progressing ;-) >>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?= <iso-8859-1> writes: Franck> Since few weeks, I write an encapsuted ethernet driver on the top of Franck> the linux ieee1394 subsystem. By using the old 0.5 version of modules Franck> with 2 adaptec boards : Hot Connect 8920, I was able to transfer data Franck> twice as fast as on common ethernet interface. But, I found some Franck> problems using the linux ieee1394 subsystem. Franck> First, I was not able to find a way to transfer data using ``unified'' Franck> write transactions. So I make few modifications in the ieee1394 core Franck> module. Franck> The Hot Connect 8920 board use S200 speed bus. So the max payload data Franck> on a single paquet must be 1024 bytes. But, to avoid kernel freezing, Franck> I reduce the size of ethernet paquet to 200 bytes. If not, after some Franck> times, strangness append in the low level driver ``aic5800'', this Franck> could freeze the 2 computers. I think the AIC5800 is not supported anymore... it's been a few months since the last update for this driver has been announced. Franck> ---------- Franck> Last week, I recieved 2 ADS PYRO OHCI boards. So I download last CVS Franck> version of modules and libraw. After succesfull installation and Franck> tests, I rebuild my ethernet driver, using the new subsystem. And Franck> unfortunatly I found other strange problems. Franck> 1. ``insmoding'' 2 times the ohci modules freezing one or the other Franck> computer... I have not experienced any kernel freeze when loading the ohci module for quite a while now, and nobody else so far as complained about that on the list... however the ohci driver is still very much alpha quality and has not been extensively tested, so anything is possible. Could you please be more specific with your bug report. Can you repeat the kernel freeze easily ? Can you get part of the log file before it happens ? Franck> 2. My ethernet driver is working (vor exemple, flood ping is OK) but Franck> other kind of programs like ftp or telnet don't work well: for an Franck> unknown reason, after a few time, the ohci driver (or the board ?) Franck> stop recieve (or transmit) paquets, while it still can transmit (or Franck> receive) some other paquets like ARP ones. And of course, some times Franck> it crach ! When the ohci driver stops receiving packets, could you please make a dump of 'dmesg' and 'cat /proc/ohci1394'... Is this error repeatable as well ? Don't forget to turn on the 'excessive debugging messages' option. Franck> ___________ Franck> An other question : Franck> Now, I will work on isochronous transmissions and video stream. But Franck> unfortunatly, I have not any camrecorder. So does anyone know the way Franck> to make believe others nodes that my PC-linux is a camrecorder ? Well to simulate a camerate you need iso packet transmission. Unfortunately this functionality is not yet included in the ohci driver... either buy a camera, be patient or... write it and submit a patch ;-) Bonne journee, -- Sebastien Rougeaux RSISE, The Australian National University |
From: Frederic V. <fv...@ho...> - 2000-05-02 13:58:45
|
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 |
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 |