Sorry but it took me some time to be able to give you an answer. No, raw sockets cannot solve my problem since what I should do is to get any packet that is sent to my eth controller (no matter the destination address or the protocol used) and forward it exactly as it is. I think that in this case the only thing I can do is interfacing my I/O driver directly to the low level eth driver, set my microcontroller in promiscuous mode and keep all the packets I get as they are. Anything wrong in that? Thanks anyway for your advices.
Michele On 7/2/07, Gary Thomas <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michele Paselli wrote: > But we didn't agree that no raw socket was implemented in eCos? Then I > don't understand how the "ping" tests can be based on SOCK_RAW. Have you tried it, or looked at the sources, or just assumed that everything you read on this list is gospel? I don't know where that line of reasoning came from (I hope I didn't say it first), but I also didn't have time to refresh my memory about the stack (after all, I did do that work more than 5 years ago...) Bottom line: use the source! One question which I've asked you multiple times (and not received an answer) is whether RAW sockets solve your needs. > > On 7/2/07, Gary Thomas <[EMAIL PROTECTED]> wrote: > Michele Paselli wrote: >> Thanks guys, since in my specific application I don't need any other >> networking stacks I think I'll start implementing the I/O ethernet >> driver without any synchronization. My only concern is about Redboot, >> which also has a small networking layer. May I have problems with it >> if I don't synchronize packets? Of course I guess that then I'll not >> be able anymore to debug my system with ethernet but I can always do >> it with serial. Also, in my case I need to be extra fancy, because I >> have to receive ethernet packets in promiscouos mode, so even if the >> destination address in the packet is different from the one of the >> receiver one. >> Grant, I guess your driver will be built on top of the device specific >> one, so it will not be so different from mine. If your employer allows >> you, I would be grateful if you could contribute it, otherwise thanks >> anyway for your help. > > I don't understand what all the hoopla is about this. The BSD network > stack provides for SOCK_RAW - why isn't this good enough? (Note: I > know it works, at least at some level, because the 'ping' tests all > work and they use RAW sockets!!) > > >> On 2007-06-28, Gary Thomas <[EMAIL PROTECTED]> wrote: > >>>> It's a pretty thin layer -- it just allows you to queue up >>>> outbout packets with cyg_io_write() and read from a queue of >>>> inboung packets (with a specified protocol type) using >>>> cyg_io_read(). >>>> >>>> Using RAW sockets would be nice, but adding a little code to >>>> an in-house driver is logistically easier than adding raw >>>> socket support to an "off-the-shelf" network stack and then >>>> turning around and doing it all again a couple years later >>>> when the network stack changes. > >>> Your comments, while they make sense about eCos in general, >>> aren't helping. > >> Sorry. I just wanted to point out that what I described is >> actually pretty simple. > >>> I want to know why Michele thinks he needs to write his own >>> stack (that's what his questions were about). > >>> Do you have your cyg_io code? Can you contribute it? > >> I'll check with my employer. > >> All you do is register the Ethernet driver as a normal "cyg_io" >> style driver and add syncronization so that simultaneous >> "write" operations from the network stack and from >> cyg_io_write() don't trip over each other. If you want to be >> extra fancy, you can add a receive queue for the custom >> protocol packets. The code is all Ethernet device specific, so >> I'm not sure how much help it would be to contribute it. > >>> As for the network stack changing - I don't see that happening >>> anytime soon. The last time was 5 years ago and there's not a >>> great impetus for change now. It makes sense to me to fix >>> things that are missing or broken, rather than inventing new >>> ways of doing things. > >> I agree. If we were starting now, that's probably what I'd >> try first. > >> But, 7 years ago we had no experience with either eCos or >> either of the BSD network stacks, so adding a few (OK, maybe >> 50-100) lines of code the the Ethernet driver seemed like the >> safest way to go, since it didn't require us to get up to speed >> on NetBSD stack internals, and there was no danger of having to >> maintain a forked network stack. It also allowed us to >> implement a very low overhead zero-copy mechanism for raw >> ethernet I/O in a product where network stack overhead was by >> far the most significant bottleneck (I also spent several weeks >> writing and tweaking an assembly-language IP checksum routine). > > > >> - -- - ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGiPP5maKbSsQGV8ARAh6JAJ9YY5SGwcUYN07+e3oAH7Eobe6E3ACeNlOD zZytNmbqOJ2x3NX4Ds5YbqI= =dIEe -----END PGP SIGNATURE-----
-- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
