Skip to content

Ethernet next step and a big success! Can you say PING!

February 28, 2013

008

This is the money shot from a couple of hours hard work this afternoon. The olduino is successfully responding to ping requests(or, as we in the know call them: IP datagrams with ICMP echo requests).

Yesterday I had the olduino receiving packets but not dealing with them. I discovered that some of the data that comes in from the ethernet controller is little-endian so it wasn’t recognized. Fixing that it now recieves and recognizes an ARP request and (I think) responds appropriately. In the sequence below you can see the packet header and body and at the end the sequence “ARP test… ARP mkarp” which mean it’s trying to respond.

13:50:20.883> dumping 6
13:50:20.883> 46004000C003
13:50:20.972> got a packet with nextPacketL=0046 and nextPacketH=0000
13:50:21.130> got a packet with nextPacket=70 and byteCount=64
13:50:21.130> (header.statusL & 0x80)=0080
13:50:22.753> len=60dumping 60
13:50:22.879> FFFFFFFFFFFFBC77 3776B83A08060001
13:50:22.941> 080006040001BC77 3776B83AC0A80167
13:50:23.004> 000000000000C0A8 01BE000000000000
13:50:23.066> 0000000000000000 5FE909A2
13:50:23.128> ARP Test with 0008 0006
13:50:23.128> ARP
13:50:23.128> mkarp

When I queried the windows arp cache I can see the IP address I’m using 192.168.1.190 and my made-up MAC beside it.
Yesterday I was getting destination host unreachable but today I’m seeing timeouts even if I give a ping timeout of 10 seconds. It may just be a speed issue but I don’t see the sequence that would mean I was recognizing the ping request.
C:\lcc42\examples\enc28j60>arp -a

Interface: 192.168.1.103 --- 0xd
Internet Address Physical Address Type
192.168.1.1 00-1d-7e-21-a9-92 dynamic
192.168.1.104 6c-3e-6d-42-d2-9f dynamic
192.168.1.190 74-69-69-2d-30-35 dynamic
192.168.1.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static
224.0.0.252 01-00-5e-00-00-fc static
224.0.0.253 01-00-5e-00-00-fd static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static

Ok, putting in some debug prints, I am seeing and responding to the ping request.
B2014E00C000
14:34:59.838> got a packet with nextPacketL=00B2 and nextPacketH=0001
14:34:59.950> got a packet with nextPacket=434 and byteCount=78
14:35:00.010> (header.statusL & 0x80)=0080
14:35:01.945> 74dumping 74
14:35:02.007> 7469692D3035BC77 3776B83A08004500
14:35:02.072> 003C7F2A00008001 3721C0A80167C0A8
14:35:02.196> 01BE08004D410001 001A616263646566
14:35:02.257> 6768696A6B6C6D6E 6F70717273747576
14:35:02.320> 7761626364656667 6869
14:35:02.393> ARP Test with 0008 0000
14:35:02.393> ping requested
14:35:02.569> sending a packet of length 74
14:35:02.632> dumping 74
14:35:02.694> BC773776B83A7469 692D303508004500
14:35:02.756> 003C7F2A40004001 3721C0A801BEC0A8
14:35:02.882> 0167000055410001 001A616263646566
14:35:02.952> 6768696A6B6C6D6E 6F70717273747576
14:35:03.015> 7761626364656667 6869

The 74 byte packet just above here is the response. The source and dest macs look ok(reversed), the packet type stuff looks ok, the ips look ok, the IP_PROTO_P at 0x17 looks right(ICMP_V is 1), and the ICMP_TYPE_P at 0x22 looks right (ECHOREQUEST is 0). So this could be something mysterious or I’m just too slow – let’s try the speed thing first.

OK!
Taking all the diagnostic prints out of my code and using a ping timeout of 10 seconds, I can successfully return a ping. I think I can still dramatically improve the time I take to do spi transfers by going to an intergrated procedure in assembler rater than a sequence of 8 write/shift/read/clock’s each done with a painful digitalWrite/digitalRead.
C:\lcc42\examples\enc28j60>ping -w 10000 192.168.1.191

Pinging 192.168.1.191 with 32 bytes of data:
Reply from 192.168.1.191: bytes=32 time=4257ms TTL=64
Reply from 192.168.1.191: bytes=32 time=4339ms TTL=64
Reply from 192.168.1.191: bytes=32 time=4338ms TTL=64
Reply from 192.168.1.191: bytes=32 time=4339ms TTL=64

Ping statistics for 192.168.1.191:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4257ms, Maximum = 4339ms, Average = 4318ms

Advertisements

From → Uncategorized

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: