RE: ethernet driver

[Rodney R. <re...@de...>]

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