arbitrary packets on an ethernet network

(Hope this is the correct newsgroup)

I write software for microcontroller-driven electronic boards, and I'm evaluating a way to interface such boards with an ethernet network.

I use very limited microcontrollers (32kbyte rom, 1,5kbyte ram), and it's quite difficult to implement a complete tcp/ip stack and have also space for my application. So I'm thinking to use ethernet packets with a user-defined protocol.

I'm doing some test with PCs; I'm using an ethernet packet generator (packeth, packeth.sourceforge.net ) and a sniffer (wireshark); I put in the ethernet header a random value (this value is 0800 for ip; 0806 for arp; I put 8959, wireshark tells it's an unknown one).

The test packet is correctly sent by packeth and correctly received by wireshark, and the other PCs on the network didn't complain about it, even if the ethernet destination address was 'ffffffffffff', broadcast.

My question is: can I use with no problems my protocol? There are things I should know? Some limitation I will run into? I have to use a particular ethernet packet type?

Thanks in advance and sorry for my english.

Best regards, BQ

Reply to
BQ
Loading thread data ...

BQ wrote in part:

ACK! Other PCs might not complain about the occasional packet, but it does load their stacks and slow them down via interrupts. Avoid broadcast of heavy traffic unless many stations are interested.

As other posters have suggested, I'd use UDP with simplified routing, especially if your transmissions fit into a single 1500 byte ethernet packet.

-- Robert

Reply to
Robert Redelmeier

If he has a dedicated net, then I suppose it is fine. That would be for testing only, though. Other devices that I have known with dedicated connections end up on on an active net pretty fast.

He only has 1.5K ram, so a 1500 byte packet is probably too big. I believe 576 is the minimum implementation limit. For UDP, he gets to define the packet contents, and so can set a limit.

-- glen

Reply to
glen herrmannsfeldt

Hmmm. I guess that the ethernet controller will have it's own receive buffer.

If you want to live on non-dedicated ethernets you will need to be able to process full size packets, even if you reject them they may still arrive. Also if you have a low performance device you might want to think about the possible rate of arrival of broadcasts.

If your network is dedicated then these will not be issues.

Reply to
Bod43

Many do, but some of the newer ones don't. He will probably want one that does.

route full size packets, but if, for example, you ping the router itself it will ignore packets larger than 576.

For example, RIP sets the datagram size to 512, such that with UDP and IP headers it is still within 576.

Yes, you at least must be sure to survive reading them, even if you just ignore them.

True, though if the controller has its own memory, you should be able to test and ignore them without copying the whole packet over.

Yes.

-- glen

Reply to
glen herrmannsfeldt

Robert Redelmeier wrote: (snip)

In addition to my other reply, a device with only 1.5K RAM isn't likely to get packets out very fast. Even so, broadcasting isn't a good idea. It would have been nice for IP to use multicast instead of broadcast for ARP, DHCP, RIP, etc, but it is a little late now.

-- glen

Reply to
glen herrmannsfeldt

Note that smart people really learn and this design flaw *has* been corrected. In IPv6.

Reply to
Denis Jedig

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.