Re: IP_HDRINCL

On Jul 24, 10:32 pm, lak <lakindi...@xxxxxxxxx> wrote:

First I need to know why it is not fragmented if IP_HDRINCL is set.

Because the operating system cannot fragment a packet without changing
the header. If you pass IP_HDRINCL, that means that you set the
header. So you are responsible for fragmentation.

Then if possible I will fix that.

I suppose you could make it do that, but then the operating system
would have to generate headers other than the one you specifically
chose to include. I'm not sure that this is a good idea.

Could you explain why it is not fragmented if IP_HDRINCL is set?

If you are passing raw packets, and you generate the header, the OS
assumes you want the packets sent exactly as you generated them. The
entity that generates the header is also the entity responsible for
fragmentation.

If the OS fragments the packet, it would have to modify the headers.
This seems to contradict your own desire. How can the OS even know for
sure how to fragment such a packet or that fragmentation is legal? How
can it be sure the other end does disassembly?

The reason you would send a raw packet with IP_HDRINCL, rather than
letting the OS generate the header, is because you want to do
something special and unusual. To fragment the packet, the OS has to
assume the header is ordinary and typical.

DS
.

Relevant Pages

  • Re: dx upgrade - unexpected network connection
    ... > Ethernet II (Packet Length: ... > Internet Protocol ... = Don't fragment: Set ... > Header checksum: 0xa61c ...
    (microsoft.public.security)
  • Re: 8159 bytes takes 20 ms, 8160 bytes takes 200 ms?
    ... look for Nagle algorithm in TCP ... > this is what etheral shows, a packet with ack and push flag set, and win2k ... > Header length: 20 bytes ... > Fragment offset: 0 ...
    (microsoft.public.win32.programmer.networks)
  • RE: 8159 bytes takes 20 ms, 8160 bytes takes 200 ms?
    ... > this is what etheral shows, a packet with ack and push flag set, and win2k ... > Time since reference or first frame: ... > Header length: 20 bytes ... > Fragment offset: 0 ...
    (microsoft.public.win32.programmer.networks)
  • Re: Socket send problem (ucLinux)
    ... The boards repeats the bad packet several times until the conection times ... Fragment offset: 0 ... Header checksum: 0xdffd ...
    (comp.os.linux.embedded)
  • Re: IP_HDRINCL
    ... Because the operating system cannot fragment a packet without changing ... the header. ... So you are responsible for fragmentation. ... If the OS fragments the packet, it would have to modify the headers. ...
    (comp.unix.programmer)