ICMP CheckSum

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

Hi guys, how do you calculate the ICMP Checksum when the data is split into two or more telegrams?

 

Thanks

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

    ICMP Checksum is calculated as a single packet. It is at IP level where the fragmentation occur.

 

    When you send an ICMP packet you build the whole packet, calculate its checksum and hand it over to IP which will fragment it if it is larger than MTU. At reception IP rebuilds the original ICMP packet as in its original form, and then you check its checksum. From ICMP perspective you don't know (no need to worry about) if it will be fragmented or if it was fragmented.

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

Nice one angelu....  just what I thought.  THANKS

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

Greg Muth

Portland, OR, US

Xplained Boards mostly

Atmel Studio 7.0 on Windows 10

 

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

Or simply pull apart one of about 50 open source "operating systems" that are already doing the whole TCP/IP thing. Have you, for example, looked at uIP or lwIP? Or at a higher level how about the Linux kernel? Or perhaps TCP/IP for FreeRTOS or ....

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

I'd rather re-invent the wheel guys, the is more an academic project if anything.  I have the TCP/IP Lean book but it's worthless.  Plus I'm running it on a RTOS of my own making.  So I can take advantage of it in the design.

 

Okay, question time, I'm fragmenting the telegrams at the IP level.  I have not started TCP yet but when I do.  Do I handle the sequence acknowledge/ resend at the IP level or the TCP level???   

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

Fianawarrior wrote:
I'd rather re-invent the wheel guys, the is more an academic project if anything.
Fianawarrior wrote:
Okay, question time, ...

 

I realize that you did pose a specific question here, and got a responce from a knowledgeable 'Freak.

 

However, I must point out the recurring theme on AVRfreaks over the years:  "I want to re-invent that wheel for myself; I learn so much more..."

 

OK, fine.  To be blunt, then why post questions here?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Do I handle the sequence acknowledge/ resend at the IP level or the TCP level???

    The same way as for ICMP and any other protocol on top of IP.

 

    An IP fragmented packet that carry a TCP payload will carry only one TCP header, and will be in the fist fragment. Until you get the IP reassembled, this TCP header is useless because its checksum depends on the original IP packet length, so you can't process TCP portions of the original TCP packet.

 

    Most TCP implementations advertise a MSS of 1460 bytes which normally is not subject to fragmentation.

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

theusch wrote:
To be blunt, then why post questions here?
I wondered about that. Clearly angelu is an expert in this field but I kind of wondered how many other Freaks have implemented a TCP/IP stack!? There have got to be better places on the internet where the knowledgeable assemble as we do here to talk about AVRs

 

(my own experience is that I once had to wade in and try and fix a Syn/Ack breakdown in an HTTP client that a contractor company of ours had written - not a pretty sight! But for most net stuff I would just stick Linux in the solution and get on with developing the application!)

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

This is one of the reasons that I tried to discourage you from implementing fragmentation at this point in your stack development.   It really IS supposed to be invisible (via layering) to all the protocol layers that are either above or below IP itself, and  IP doesn't NEED to have it.

 

 

Most TCP implementations advertise a MSS of 1460 bytes

Hmmph.  Young people!

 

 

why post questions here?

So far, she's getting very good answers.  I suspect that "we" have more tolerance for re-inventing the wheel than most network-oriented fora (if there ARE any.  Most of the stacks, and interest in writing them, were done with a couple decades ago.)  (although there IS "new stuff", particularly wrt IPv6 and (still) congestion issues http://queue.acm.org/detail.cfm?... )