AVR Freaks

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

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.

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.

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.  

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...)

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.

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