arbitrary packets on an ethernet network

arbitrary packets on an ethernet network

NewsGroups | Search | Tools
 comp.dcom.lans.ethernet  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
arbitrary packets on an ethernet network BQ 01-19-2007
Posted by BQ on January 19, 2007, 5:11 am
If you were  Registered and logged in, you could reply and use other advanced thread options


(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

Network Magic Graduation 20% off animated banner
Posted by Jeff Jonas on January 19, 2007, 5:57 am
If you were  Registered and logged in, you could reply and use other advanced thread options


>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.

Do you subscribe to Circuit Cellar magazine?
http://www.circuitcellar.com/
They have articles (and advertisements) for embedded ethernet controllers,
some with a TCP/IP stack built in or easily added to the microcode.
Zilog's ez80 has a lot of the on-chip since it's intended for
interfacing embedded devices directly to ethernet running internet-protocol
so it "plays well with others", such as allowing web servers
on anything you want to give status and allow remote administration.
If you have a home sharing unit (router/switch/WiFi/firewall)
you already know the joy of just pointing your web browswer to its address
to get status and administer the unit without any special software.

A major reason against using non-standard protocols
is that the packets can only be used locally.
They can't be routed, so the device cannot be accessed by
non-local devices via routers.
Netware (IPX) and other protocols suffer the same fate:
they're unrouteable, thus are local-only by definition.
And you have to write ALL the software yourself
for both sides of the connection.


--

-- mejeep deMeep ferret!

Posted by BQ on January 19, 2007, 6:14 am
If you were  Registered and logged in, you could reply and use other advanced thread options


Jeff Jonas ha scritto:
> Do you subscribe to Circuit Cellar magazine?
> http://www.circuitcellar.com/
> They have articles (and advertisements) for embedded ethernet controllers,
> some with a TCP/IP stack built in or easily added to the microcode.

I'm giving a look at it, thanks!

> Zilog's ez80 has a lot of the on-chip since it's intended for
> interfacing embedded devices directly to ethernet running internet-protocol
> so it "plays well with others", such as allowing web servers
> on anything you want to give status and allow remote administration.
> If you have a home sharing unit (router/switch/WiFi/firewall)
> you already know the joy of just pointing your web browswer to its address
> to get status and administer the unit without any special software.
>
> A major reason against using non-standard protocols
> is that the packets can only be used locally.
> They can't be routed, so the device cannot be accessed by
> non-local devices via routers.
> Netware (IPX) and other protocols suffer the same fate:
> they're unrouteable, thus are local-only by definition.
> And you have to write ALL the software yourself
> for both sides of the connection.
>
>

Thank you for your thoughts Jeff.
I'm thinking about this issue.
In the case I will opt for a standard protocol, which transport-layer
protocol would you suggest in order to send commands, small amounts of
data and retrieve information (e.g. retrieve the temperature read by a
sensor, send a start / stop command to a device, etc)? For example, I
think that TFTP is not ideal for this kind of job.

Cheers,
Marco

Posted by glen herrmannsfeldt on January 19, 2007, 7:15 am
If you were  Registered and logged in, you could reply and use other advanced thread options


BQ wrote:

(snip)

> In the case I will opt for a standard protocol, which transport-layer
> protocol would you suggest in order to send commands, small amounts of
> data and retrieve information (e.g. retrieve the temperature read by a
> sensor, send a start / stop command to a device, etc)? For example, I
> think that TFTP is not ideal for this kind of job.

UDP. TFTP is UDP based, but that doesn't mean you need to do anything
like that.

To make it more simple, if you can rely on both being on
the same subnet you can leave out routing code (at least for the
first try). You should really include it, at least with static
routing. In the end, it won't be much different than doing
your own protocol. When you receive a packet in the buffer,
exchange the source and destination MAC addresses, IP addresses,
and ports, extract the incoming data, store the outgoing
data, and send it out. You should compute the appropriate
checksum, but it is optional for UDP.

I believe you are supposed to be able to process at least
a 576 byte packet, but if you don't need that you can probably
ignore that one, too.

You might try comp.protocols.tcp-ip for continuing discussion.

-- glen


Posted by BQ on January 19, 2007, 9:35 am
If you were  Registered and logged in, you could reply and use other advanced thread options


glen herrmannsfeldt ha scritto:
[snip]
>
> You might try comp.protocols.tcp-ip for continuing discussion.
>
> -- glen
>

thank you all for your kind help! I think I'll adopt UDP as you
explained; in fact, as you pointed out, it is not much different than
doing my own protocol.
Cheers,
Marco

Similar ThreadsPosted
Promiscuous Mode on Sun BGE Network Driver Drops VLAN-tagged Packets April 20, 2005, 11:02 am
Using Ethernet cards to create arbitrary frames? October 26, 2005, 4:57 pm
Seeing Packets on an Ethernet Port That Should Not Be There October 4, 2007, 11:54 pm
Maximum maximum packets per second on 10 megabit ethernet ? 1.250.000 / 1538 = 812,743823 ??? February 19, 2005, 8:31 am
ping corrupted packets February 21, 2005, 9:19 am
DVMRP report packets September 24, 2006, 10:25 pm
Dropped packets/broken TCP connections August 23, 2006, 9:48 am
Question about VLAN tagging for packets March 21, 2007, 2:43 pm
Connection to Switch Drops Packets But Hub Works July 10, 2007, 1:36 am
watching outgoing ping packets via tcpdump/ethereal January 25, 2006, 10:14 am

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map