can ethereal detect an ethernet packet for which crc is wrong

There are more CRCs in a ethernet packet:

1. PHY level. The very last 4 bytes. In linux ifconfig will show you the number of packet errors on a NIC. Ethereal won't detect it because the network driver throws away the packet if it's bad. Some driver won't even generate interrupt for bad packets, in that you cannot see the error unless you recompile the driver and enable interrupts for bad packets.

1. CRCs in IP headers. ethereal will detect it.

Zoltan

Yes. Look on the data side, not the line side. Scrambling will make an idle link look the same as a busy one.

-- Mike Treseler

I run tethereal for all my packet analysis. Two options to use: tethereal -x -i eth0 (or whatever your interface is) - complete data dump tethereal -V -i eth0 (or ...) - protocol level dump

I believe tethereal will give you invalid FCS (CRC) packets.

A sample ethernet packet from 08:00:46:63:ca:e3 with destination

00:13:20:0a:25:db is here. The first byte on the wire is given first - so transmit the MAC address bytes from left to right. Bits 0-3 go first on the wire, 4-7 afterwards

0000 08 00 46 63 ca e3 00 13 20 0a 25 db 08 00 45 10 ..Fc.... .%...E.

0010 00 74 3e b4 40 00 40 06 c5 53 0a 01 11 40 0a 01 .t>.@.@..S...@.. 0020 11 2b 00 16 81 0d 97 0e cc 65 84 46 8d 49 80 18 .+.......e.F.I.. 0030 0a a8 36 d3 00 00 01 01 08 0a 5c 54 28 18 00 6f ..6.......\T(..o 0040 69 8d 70 8b af ba 95 1e 29 bc 92 53 9d ca d8 e9 i.p.....)..S.... 0050 e7 46 81 bf eb 16 6d 86 11 f0 63 a1 59 77 4a 75 .F....m...c.YwJu 0060 e9 da cf 8d e5 b1 d2 3a 0d 04 ad 8c 41 88 c5 cb .......:....A... 0070 13 d4 1b c1 b3 30 43 d2 d9 62 c9 0e 08 31 1d 64 .....0C..b...1.d 0080 43 9b C.

It is probably best to start out broadcasting packets for your tests - send to ff:ff:ff:ff:ff:ff, that way they should get received whatever. Also it is worth writing ethernet rx before tx - make sure you can receive packets with the correct FCS from the wire, and then you can get your tx to work with your known working rx code.

Anyway, a packet to your destination address from MAC address

01:23:45:67:89:a0 with total packet length including MAC addresses and FCS, with other content 00, is...

00 01 80 3f 6c e6 01 23

45 67 89 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 75 78 03 93

Hello Gavin, Thanks for sending an ethernet packet which includes my destination address. Does the last 4 bytes represent CRC of all the data. You didnt inlude the length/type, 2 bytes , which comes after source address. I guess we need to compute the crc for that also.

Please check and advice

thanks ashwin

Gav> I run tethereal for all my packet analysis. Two options to use:

That's not the hardware level CRC at the end of the packet. It's not even a CRC, just a 1's complement add.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited

Do they still make Ethernet gear that runs on coax? If you can find some of that the bit order will be pretty obvious.

Send a packet from your PC. Grab the bits with a scope. Then you can make your CRC agree with one that is known to work.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited

Ethereal will happily receive the above packet - it will tell you all sorts of errors about it, though... Don't worry about the length etc until you can get a blank packet correct. If you can do that, then you should have the FCS code all working, and you are at a different debug level. The last 4 bytes are FCS.

I'd second that - the lazy way to work this out is to instrument the image on the rx side (ie using something like chipscope), transmit some packets on the network, and see if it matches what you expect. It can be easy to to get caught out. You can then write a simple state machine to dump the data you saw on the rx side out the tx side.

The rx side is easier to get working first, since you can: a) Get your crc code right first by checking crcs on recieved packets (quite likely to be correct) b) You can then simulate a loopback situation to check that your rx crc code and tx crc code match c) It forces you to recheck your assumptions on nybble/byte ordering, since if what you expected was different from what you recieved from the packet, then you're probably wrong :)

Also, if your crc code is incorrect, it's easier if you have a 'golden' source, as you can then run simulations or a c program using a known good piece of code (from a bsd kernel or something like that) to see where you went wrong. It helps to localise the error if you are using a known good source.

My 2c, Jeremy

Hello,

I developed a wee Gigabit MAC but with quite a different setup, Virtex 2 Pro (with my MAC + Internal MGT - 16 bit wide @ 62.5MHz) + Copper SFPs (with embedded Marvell 88E1111 in SGMII mode) PC

I did use Ethereal, and noticed that crc errored packets were filtered out, not sure if it was the SFP, the PHY in the PC or the PC driver, I'm positive that packets were not getting to Ethereal at all. I also noticed that packets smaller than 64 bytes were also filtered out and I am pretty sure it was the Driver in my PC.

For testing I used a ping frame...

--=============================================--

--IP DA (192.168.0.85 : c0.a8.00.55)

--IP SA (192.168.0.33 : c0.a8.00.21)

--Header Length & IPv4 = x"4500"

--IP Datagram = x"0800"

--SA = 12.34.56.78.9a.bc (it doesn't really matter)

--DA = 00.0d.88.b5.88.71 (change it to yours, it doesn't really matter in promiscous mode)

--=============================================--

constant C_GBE_DATA : word32_array(18 downto 0) := ( X"68697071", X"64656667", X"77616263", X"73747576", X"6f707172", X"6b6c6d6e", X"6768696a", X"63646566", X"04006162", X"485c0100", X"00550800", X"0021c0a8", X"96b3c0a8", X"00002001", X"003c8247", X"08004500", X"56789abc", X"88711234", X"000d88b5" );

Bytes go out like: 00 - 0d - d8 - b5 - 88 - 71 ...

FCS for the packet above => X"257eaf61"

On thing I recommend is using loopback if your PHY supports it, and also the internal CRC if the PHY provides one (just for testing) before trying to send packets to your PC.

Regards,

--
Ignacio Ulises Hernandez
" I'm not normally a praying man, but if you're up there, please save me,