ARP and ICMP Protocols

Go To Last Post
37 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys, I'm designing a small embedded TCP/IP stack to learn the protocols. Thus far I have the ARP system setup and working and have began work on the ICMP protocol. I notice that the computer I have the AVR32 connected to does not respond to ARP broadcasts or pings.  The system is working however responding to ping requests and storing mac addresses using ARP.  The Ping example I've attached to this post shows an example of a ping request, Wireshark just says no response to the ping request.

 

Any advice would be appreciated, the only thing I can think of doing is setting up my own server using another AVR to connect too.  Like why would Windows (10) not like talking to me...  Thanks guys.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It’s probably turned off in Windows. If wireshark is running on that machine, then the message got there.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's is also not responding to ARP broadcasts.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It won’t respond if it doesn’t know about the device.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's what the ARP broadcast is for. It allows your IP to be associated with a MAC address. I also noticed that at boot-up the computer will repeatedly send ARP broadcasts on the gateway and I'll respond as per say but it keeps asking.  Stupid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can see you’ll be having a lot of fun. I wouldn’t be developing the code on the AVR - i’d do it under linux as you’ll have much better diagnostics and not have to go through a erase/flash cycle. Once you’ve got your protocols sorted, then put it on the AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was thinking about using Linux, and also another AVR32 to connect to instead of the computer.  I would sorely love to develop code on Ubuntu but sadly Atel decided to get into bed with Microshit.  

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Found it, apparently Windows does not allow ICMP responses in it's firewall.

 

http://www.sysprobs.com/enable-ping-reply-and-ftp-traffic-in-windows-10-and-server​

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm left wondering is there away to tell Windows 10 to allow full access to the Windows 10 network by telling it my ip address

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I was suspecting Windows had been blocking stuff. I’ve not had to deal with the low level details of Windows for many years now. The old way to identify hosts was to create an entry in the hosts file.
The code for your tcp/ip stack should be near identical regardless of the plarform it runs on. Only the network interface differs. So it stands to reason that you develop and test your code under the likes on Linux where you have much better tools then when you’ve debugged your protocol stack, then you run it on the target. I’m doing an encrypted protocol stack at the moment and I’m using xcode on the Mac to write and debug the code. I can compile and debug in a blink, send stuff to files etc. Once i’m reasonsbly sure its all good, i copy the code to my embedded project then test it there. Saves so much time. It also means i can write a test harness and validate the code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks Kartman for the advise

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Wouldn't you be better off having the AVR32 communicate with a true router not a Windows PC? If you get a router and put OpenWRT in it then you should be able to get all kinds of diagnostics about what is going on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Clawson, would installing Ubuntu on a virtual machine help?  I enabled Windows 10 to receive and respond to pings but it still does not work.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A VM might work though I'd be tempted to run it natively in case anything about the VM or the underlying OS (Windows) that is feeding that VM "gets in the way".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

okay, can I then run Studio 7 from a VM in Ubuntu?  i.e. can I connect to the ICE emulator to download to the AVR from Studio in the VM?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd get a "small Linux". Put it on a USB stick and boot from that. Or maybe just an external USB HDD. Perhaps an SSD?

 

I wouldn't go swapping around your host machine to switch Windows/Linux(VM) to Linux/Windows(VM) or whatever as something is bound to get broken that way.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

just tested to see what Windows does when I send a ping with a size greater than the MTU.  I does not even try to fragment it. it just drops it.  angry

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are the AVR32 and the Windows PC the only things on your LAN?  No router, printer, etc?

 

I was running Studio 7 in a Windows 10 VM on Ubuntu and it worked with the Dragon, JTAGICE mkII, and the mEDBG on the Xplained Minis, but it did not work with the EDBG on the Xplained Pros.  And then one day it quit working.  I was not able to determine what update caused the problem, so I went back to running Windows 10 natively.

Greg Muth

Portland, OR, US

Xplained Boards mostly

Atmel Studio 7.0 on Windows 10

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Drop the firewalls and it works, god windows is crap.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greg_Muth wrote:
Dragon, JTAGICE mkII, and the mEDBG on the Xplained Minis, but it did not work with the EDBG on the Xplained Pros.
First of those are USB 1.1, latter are USB 2.0

 

I've had this too. In theory you can add USB 2.0 support to VMs but I've not had a lot of success with that myself.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you sure the "firewalls" weren't working exactly as configured - but you just hadn't correctly configured them to do what you want ... ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I followed the advise on the web to allow ICMP protocol in Windows 10.  I also allowed the scope of the IP address.  I'm no expert on firewalls in Windows.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Time to move on to Fragmentation...  yes

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

just tested to see what Windows does when I send a ping with a size greater than the MTU.  I does not even try to fragment it. it just drops it.  angry

 

I think that's correct behavior.  Receiving a packet larger than the MTU on a hardware interface should be a low-level error - throw it away.   To get fragmentation, the packet needs to be legal on the incoming interface and too big for the outgoing interface (and the box needs to be a router.)

 

Fragmentation is considered harmful; I'd put it off till later (reassembly might be more important, though.)  There shouldn't be any reason for an endpoint node to ever source fragments, except to show that it can.   I think the last real protocol that relied on fragmentation was EGP (and it's not used any more.) (18k+ IP packets.  Seemed really big at the time!)

 

https://dl.acm.org/citation.cfm?... (original reference.   Widely available for download without charge...)
https://tools.ietf.org/html/draf...

https://perso.uclouvain.be/olivi...

 

I'll re-iterate my suggestion to buy a used cisco router, just for the debugging capabilities...
http://www.ebay.com/itm/Cisco-17...

(well, it might have a bit of a learning curve...)

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks for the input westfw...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I take it you can you cannot perform fragmentation in IP alone, i.e. you need to use TCP.  I ask because I'm working on the ICMP with fragmentation for pings greater than the MTU...   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I take it you can you cannot perform fragmentation in IP alone, i.e. you need to use TCP

No.  Fragmentation occurs at the IP layer, not the TCP layer.  It's perfectly legal to send ping packets with large payloads:

 

Greg Muth

Portland, OR, US

Xplained Boards mostly

Atmel Studio 7.0 on Windows 10

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do you derive the sequence number for the packets,  I know how to send fragments but the IP header does not seem to have the information to rebuild the packet?

 

EDIT:  If I receive the last packet but I have not yet received all the fragments it will fail...

 

Last Edited: Tue. Sep 26, 2017 - 07:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SOLVED, found an example to test.  Thanks guys.  Shizer!

Edit: UNSOLVED

Edit: SOLVED, lmfao, why make the system so complicated, when they could easily just specify a sequence number.  

 

When I'm piecing the packets together I need to know the total size of the telegram.  If I don't and then say I receive the last packet before completely receiving all the other packets I will miss calculate the frame size.  And fail to in-fragment the data!

 

 

Please help!

 

 

Last Edited: Tue. Sep 26, 2017 - 08:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I'm piecing the packets together I need to know the total size of the telegram.

    You will know the total size of the packet once you receive all fragments. The individual fragments taken alone are simply IP packets that just tell you they are part of a bigger one, if it is the first one, the last one or none of these.

    If you receive the last fragment and one or more are missing then you have to options: to discard whole  packet or to wait some time for the missing one(s) to arrive (notice how archaic this sounds in comparison with TCP ?).

 

    Wikipedia explains very well and gives you links to the official documents IP fragmentation is based on: https://en.wikipedia.org/wiki/IP... .

why make the system so complicated, when they could easily just specify a sequence number

    They do, and in fact you have three hints in the IP header that gives you information about this: Identification, Fragment Offset and Flags.

 

    I think you are walking the wrong path, or you want to reinvent the wheel. As others mentioned, IP fragmentation is out of grace for several reasons:

- it is an old technology that no longer fits the today's networking realities

- given the fact that the Identification field is only 16 bit long, old packets could arrive later and interfere with the new ones

- the same 16 bit long field is easier to guess, so a man in the middle could inject a fragment which would break your entire packet, or erroneous data will be delivered to the application

- for an embedded implementation is almost a no go. In order to reassemble the entire packet you need to buffer all this data. If you want to wait for late arriving fragments and in the mean time to handle new fragmented packets things only get worst. This is where TCP come to the rescue: you can deliver any amount of data you have received in order to the application freeing your receiving buffer. Selective acknowledgements improve this further

 

    What the networking industry came up in order to somehow transmit a larger packet at once is the jumbo frames.

 

    If you come with more details about your project I am sure people here will suggest a way to go and you can go to the right direction with your development.

 

Last Edited: Tue. Sep 26, 2017 - 09:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah yes, the good 'ol days. Remember when you could knock over a Windows host just by sending it a single ICMP packet larger than 64KiB? Good times...

 

EDIT: http://insecure.org/sploits/ping-o-death.html

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Tue. Sep 26, 2017 - 10:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks guys, fragmentation can be realized using insertion sort and simple maths..  I'll implement it just for the craic of it.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(One gets the feeling that fragmentation was mostly intended to address situations where the number of fragments would be small - "Let's send 1024byte datagrams using a 576byte MTU", probably.

It ALLOWS bigger datagrams with more fragments, but people didn't really think out what would happen when you had to wait TTL seconds for a possibly-lost 30th fragment while consuming memory for all 30.  And talk about possible DoS attacks! (which was NOT something typically considered in those days))

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i noticed that by dividing the fragment offset by 0xb9 will tll me where in the frame it goes....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i noticed that by dividing the fragment offset by 0xb9 will tll me where in the frame it goes....

    0xb9 * 8 = 1480 which is the max MTU of 1500 - 20 bytes IP header size. This is just one case where the fragments are sent with this size. You should not rely on this finding.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW, Be careful fetching Fragment Offset on little-endian machines.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fianawarrior wrote:
Hi guys, I'm designing a small embedded TCP/IP stack to learn the protocols.

...

I notice that the computer I have the AVR32 connected to does not respond to ARP broadcasts or pings.

fyi, µC/OS-III is on UC3A0512 and UC3B0256 with a TCP/IP stack for zero price in µC/OS for makersTM :

uC-OS-for-Makers-Logo

About µC/OS for Makers

https://www.micrium.com/makers/about/

via http://www.electronicdesign.com/industrial/industrial-grade-rtoss-iiot

 

Edit : via

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Mon. Oct 9, 2017 - 05:26 PM