Creating a test packet

Creating a test packet

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
Creating a test packet darin 10-13-2005
Posted by on October 13, 2005, 11:21 am
If you were  Registered and logged in, you could reply and use other advanced thread options


I've got an ethernet driver I'm modifying that sends out a test packet
when it starts to get around a hardware bug. There is no need to ever
get a reply, it's sent only to kickstart things.

I'm a bit worried that the data format used could be interpreted by
some
equipment as a valid packet, though this would be rare. What I want is
some sort of test packet that is universally ignored. The data as it
is
now would start with an LLC header of "00 00 00". Is this likely to be
misinterpreted, or is there something else I can try?

--
Darin Johnson



Pure Networks
Posted by on October 13, 2005, 12:31 pm
If you were  Registered and logged in, you could reply and use other advanced thread options


> I'm a bit worried that the data format used could be interpreted by
> some
> equipment as a valid packet, though this would be rare. What I want is
> some sort of test packet that is universally ignored. The data as it
> is
> now would start with an LLC header of "00 00 00". Is this likely to be
> misinterpreted, or is there something else I can try?

It's very unlikely to be missinterpreted.

http://www.wildpackets.com/support/compendium/ethernet/frame_formats

http://www.ethermanage.com/ethernet/enet-numbers/ieee-lsap-list.html
http://www.ethermanage.com/ethernet/enet-numbers/cisco-lsap-list.html
http://www.ethermanage.com/ethernet/descript-troubleshoot.html

Mention a NULL LSAP with the address fields set to
zero.

Maybe your zero, zero is just the job. You should get the IEEE
802.2 doc and check yourself though. You used to be
able to buy them on-line and download a pdf.

Here are a few possible workarounds.

Avoid broadcast and m'cast dest MAC.

Could you send a packet with an invalid CRC?
Then everything would ignore it.

What happens if you send it to your own MAC address?
Everything else would ignore it, but it might possibly come back to
you.

Buy a NIC, get its address then destroy it. Use that
address as the destination address.

Send a 'good' frame eg an ICMP echo request or an ARP request.

Just pick a destination MAC, the chances of
ever coming into contact with it are rather small.
Unless:- you sell millions of them in which case send
me my share:)

Look through the OUI list and pick an unlikely vendor, say
one that has not yet been taken over and is not too likely to be.

http://www.iana.org/assignments/ethernet-numbers

How about:

080056 Stanford University

Not likely to be taken over any day soon and not
too likely to go into the mass production of
printers, games consoles or refrigerators.

Of course they might sell it.



Posted by News Me on October 13, 2005, 6:06 pm
If you were  Registered and logged in, you could reply and use other advanced thread options


anybody43@hotmail.com wrote:

[snip]

> Just pick a destination MAC, the chances of
> ever coming into contact with it are rather small.
> Unless:- you sell millions of them in which case send
> me my share:)
>
> Look through the OUI list and pick an unlikely vendor, say
> one that has not yet been taken over and is not too likely to be.
>
> http://www.iana.org/assignments/ethernet-numbers
>
> How about:
>
> 080056 Stanford University
>
> Not likely to be taken over any day soon and not
> too likely to go into the mass production of
> printers, games consoles or refrigerators.

Rather than hijacking a globally administered MAC address, use a locally
administered one. The second bit of the most-significant byte of the
MAC is the local/global flag (1 = local, 0 = global). The first bit of
the most-significant byte is the multicast/unicast bit (1 = multicast, 0
= unicast), so the second digit MUST be even if you want to prevent
switches from possibly forwarding your packet. So as long as the second
digit of the OUI is one of you should be OK. E.g.,
02-00-00-00-00-01.

NM

--
convert UPPERCASE NUMBER to a numeral to reply


Posted by stephen on October 13, 2005, 9:18 pm
If you were  Registered and logged in, you could reply and use other advanced thread options


> > I'm a bit worried that the data format used could be interpreted by
> > some
> > equipment as a valid packet, though this would be rare. What I want is
> > some sort of test packet that is universally ignored. The data as it
> > is
> > now would start with an LLC header of "00 00 00". Is this likely to be
> > misinterpreted, or is there something else I can try?
>
> It's very unlikely to be missinterpreted.
>
> http://www.wildpackets.com/support/compendium/ethernet/frame_formats
>
> http://www.ethermanage.com/ethernet/enet-numbers/ieee-lsap-list.html
> http://www.ethermanage.com/ethernet/enet-numbers/cisco-lsap-list.html
> http://www.ethermanage.com/ethernet/descript-troubleshoot.html
>
> Mention a NULL LSAP with the address fields set to
> zero.
>
> Maybe your zero, zero is just the job. You should get the IEEE
> 802.2 doc and check yourself though. You used to be
> able to buy them on-line and download a pdf.

00 is the "null" LSAP, so 00,00 should be OK - i think this can be used as
an 802.2 type "ping".
>
> Here are a few possible workarounds.
>
> Avoid broadcast and m'cast dest MAC.
>
> Could you send a packet with an invalid CRC?
> Then everything would ignore it.
>
> What happens if you send it to your own MAC address?
> Everything else would ignore it, but it might possibly come back to
> you.

it shouldnt - but this is what cisco and various others such as the
Wellfleet / Bay Nortel routers do for a "test" packet.

Also - there is a Ethernet type code 9000 which i think is allocated for
"test" - i have seen this "in the wild" with a sniffer.

>
> Buy a NIC, get its address then destroy it. Use that
> address as the destination address.
>
> Send a 'good' frame eg an ICMP echo request or an ARP request.
>
> Just pick a destination MAC, the chances of
> ever coming into contact with it are rather small.
> Unless:- you sell millions of them in which case send
> me my share:)
>
> Look through the OUI list and pick an unlikely vendor, say
> one that has not yet been taken over and is not too likely to be.
>
> http://www.iana.org/assignments/ethernet-numbers
>
> How about:
>
> 080056 Stanford University
>
> Not likely to be taken over any day soon and not
> too likely to go into the mass production of
> printers, games consoles or refrigerators.
>
> Of course they might sell it.
--
Regards

stephen_hope@xyzworld.com - replace xyz with ntl




Posted by on October 15, 2005, 11:24 am
If you were  Registered and logged in, you could reply and use other advanced thread options




<snip>
You should get the IEEE
> 802.2 doc and check yourself though. You used to be
> able to buy them on-line and download a pdf.

802 group stuff specs are currently free (this is mentioned on charles
spurgeon's website)

http://standards.ieee.org/getieee802/



Similar ThreadsPosted
Built-In Bit Error Test? July 5, 2005, 3:53 pm
How to test network in windows? September 19, 2008, 2:15 am
Utilities to Test Gigabit Ethernet July 25, 2006, 2:39 am
How to test spanning tree protocol July 28, 2006, 1:03 am
test comp.dcom.lans.ethernet August 7, 2006, 1:42 pm
switches or other devices which respond to Test frames? May 23, 2008, 2:31 pm
I search a test with benchmark of several ethernet gigabit switch September 1, 2006, 11:18 am
Generate packet with bad CRC June 21, 2007, 9:15 am
Packet recorder August 8, 2007, 11:36 am
Packet capture November 28, 2007, 12:07 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