Re: Problem while setting DF bit ON

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Yes I knwo this fact thats why I am using a UDP server at other side, in
conjnuction with timeouts.

Actually my question was, why the above mentioned option for setting the DF
bit ON is not working for windows 2000(and with a XP machine)??

"Alexander Nickolov" wrote:

> ICMP is routinely blocked by firewalls, so you shouldn't
> rely on it. About the only thing you can do is employ timeouts
> for confirmations...
>
> Note I didn't say sendto won't fail for your packet, I said
> it might not fail so you shouldn't rely on it failing.
>
> --
> =====================================
> Alexander Nickolov
> Microsoft MVP [VC], MCSD
> email: agnickolov@xxxxxxxx
> MVP VC FAQ: http://www.mvps.org/vcfaq
> =====================================
>
> "Rajat" <Rajat@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:81AEFDDF-3B70-45F6-8227-EF7E9A82CFE4@xxxxxxxxxxxxxxxx
> > Thanks Alex for you response, But what if the MTU of that interface is
> > smaller than the packet size, on which socket is bound. Generally in this
> > case, the sendto returns with Error 10040. And for most of the machine it
> > is
> > working like that.
> > Anyway if IP layer drops it, then for that the should be some error
> > notification, may be in form of ICMP message. But I am listening on both
> > UDP
> > and ICMP socket, there is no message to receive. Could you point me how to
> > handle this issue.
> > However, if a packet is dropped by an intermediate router, having smaller
> > MTU, then it will sent back a ICMP message to sender, and here I am
> > listening
> > on a ICMP socket to catch any such kinda messages.
> >
> > "Alexander Nickolov" wrote:
> >
> >> Why do you think sendto should fail? It successfully delivers
> >> the packet to the UDP layer after all, and that's all it cares.
> >> The IP layer will drop it for you, but sendto doesn't need
> >> to know this. Besides, on a more complex route the packet
> >> may go out fine on your network and be dropped in an
> >> intermediate network with smaller MTU. How do you
> >> expect to deal with that?
> >>
> >> --
> >> =====================================
> >> Alexander Nickolov
> >> Microsoft MVP [VC], MCSD
> >> email: agnickolov@xxxxxxxx
> >> MVP VC FAQ: http://www.mvps.org/vcfaq
> >> =====================================
> >>
> >> "Rajat" <Rajat@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> >> news:E98E82C6-2255-4034-955D-D3978BCEEB61@xxxxxxxxxxxxxxxx
> >> > Hello experts,
> >> >
> >> > I am working for discovering Path MTU between two host, and I am facing
> >> > a
> >> > strange problem with window's setsockopt() API and its
> >> > IP_DONTFRAGMENT option, for setting DF bit on.
> >> >
> >> > As I created a UDP socket, and to enable DF bit option on this socket I
> >> > used
> >> > the following code,
> >> >
> >> > #include <winsock2.h>
> >> > #include <ws2tcpip.h>
> >> >
> >> >
> >> > /* Flag value to be set. */
> >> > int optval = 1;
> >> >
> >> > /* Set the Don't fragment flag in IP header, for udp socket. */
> >> > err_code = setsockopt(udp_socket,
> >> > IPPROTO_IP,
> >> > IP_DONTFRAGMENT,
> >> > (const char FAR *)&optval,
> >> > sizeof(int));
> >> >
> >> > Though for most of the system(having Windows XP and 2003) it is working
> >> > fine. But in my LAN for one machine(windows 2000) and one other
> >> > machine(windows XP), it is not working properly. If I send a
> >> > packet(with
> >> > DF
> >> > bit ON) having size more than the capacity of
> >> > interface(MTU), then "sendto()" API *SHOULD* return with an error, but
> >> > it
> >> > is
> >> > returning with success, and showing those many bytes sent. But if I use
> >> > sniffer to watch that sent packet, it doesn't show.
> >> > Means the sendto() API is showing, that larger packet has been sent
> >> > successfully, but actually it is not coming out of the interface(may be
> >> > dropping packet in between without showing error).
> >> >
> >> > Could any body point out on this situation. Any comment would be
> >> > appreciated.
> >>
> >>
> >>
>
>
>
.

Relevant Pages

  • RE: traceroute-like tool for UDP or TCP packet
    ... there is no UDP echo-request packet except against ... Linux traceroute sends UDP packets against high ports above 33000 and counts ... the ICMP Port-Unreachable. ... packet, ...
    (Security-Basics)
  • RE: traceroute-like tool for UDP or TCP packet
    ... there is no UDP echo-request packet except against ... Linux traceroute sends UDP packets against high ports above 33000 and counts ... the ICMP Port-Unreachable. ... packet, ...
    (Security-Basics)
  • RE: traceroute-like tool for UDP or TCP packet
    ... there is no UDP echo-request packet except against ... Linux traceroute sends UDP packets against high ports above 33000 and counts ... the ICMP Port-Unreachable. ... packet, ...
    (Security-Basics)
  • Re: port=1026&reason=ICMPsent
    ... > Actually ICMP is a layered protocol the UDP protocol in question is a ... in the payload of an ICMP ... with a payload indicating it was in response to a UDP packet? ...
    (alt.computer.security)
  • Re: Multiple closed networks and UDP. Please help me.
    ... Each of the three computers will be in its own closed network. ... I have worked with TCP many times, but never UDP. ... When I open a socket to receive one UDP socket stream do I ... there is a packet to receive. ...
    (microsoft.public.vc.mfc)