[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bezeq ADSL setup



Shachar,
There is no point trying to send a packet larger than your own intrface
MTU, with the dont fragment bit set. It shouldn't leave your machine in
the first place (because the packet must be fragmented).
Dani

On Wed, 13 Jun 2001, Shachar Shemesh wrote:

> Shachar Shemesh wrote:
>
> > Can someone verify that the setup does, in fact, support the RFC?
> >
> > I.e. - use hping or other packet crafting tool to generate a big
> > (say,  4K) TCP packet with the "don't fragment" flag set, and see
> > (with  tcpdump, or a real sniffer, such as ethereal) whether a
> > "fragment  needed" ICMP is sent.
> >
> > If it is not sent, but the packet does not go through, then there is
> > a  real problem. I would try, at this stage, incrementing the TTL,
> > starting  from one, and seeing where the "ICMP time exceeded" messages
> > stop  arrive. Wherever that happens - that's the curlpit (or the one
> > before).
> >
> > hping2 can be D/L from http://www.kyuzz.org/antirez/software.html
> >
> > The command line for a single, established, ~ 4KB packet to host foo,
> > with the "don't fragment" flag set is
> > hping2 foo -c 1 -A -d 4096 --dontfrag
> >
> > hping will display any reply packets received. If you want to test
> > the  TTL as well, add --ttl # to the arguments.
> >
> >              Shachar
>
>
> Hmm.
>
> Now this is interesting.
>
> I tried my own advice. I don't have an ADSL modem, but I tried it on our
> local network.
>
> I sent UDP packets, as the company I work for is heavily firewalled, and
> I wanted to send packets with payload.
>
> I tried sending 32K UDP packets (assuming that they must get fragmented
> on the way).
>
> Instead, this is what I got:
> [root@sshemesh ~]# hping2 www.microsoft.com -2 -c 1 -p 53 -d 32768
> --dontfrag --ttl 12
> eth0 default routing interface selected (according to /proc)
> HPING www.microsoft.com (eth0 207.46.230.229): udp mode set, 28 headers
> + 32768 data bytes
> TTL 0 during transit from 152.63.21.90  (189.at-1-0-0.TR1.NYC8.ALTER.NET)
>
> --- www.microsoft.com hping statistic ---
> 1 packets tramitted, 0 packets received, 100% packet loss
> round-trip min/avg/max = 0.0/0.0/0.0 ms
>
> Which means that the 32K+change packet got a "TTL exceeded", instead of
> a "Fragmentation needed". Strange!
>
> So, I ran a sniffer, and tried again.
>
> It turns out that the packet got fragmented leaving my own machine. The
> packet left the network interface, already fragmented. The "Don't
> fragment" flag got reset, and the usual "more fragments" flag was set.
>
> The reason I am bringing this up is because it turns out that the MTU on
> my network interface (Ethernet 10/100, currently in 100) is 100bytes
> (meaning 1480 bytes + header).
>
> Ok, now for a possible answer to the question that has been bothering
> all of us - why set the MTU on all computers on the network.
>
> Could it be that the MTU for ethernet, at least on Linux, is 1500 bytes?
>
> Could it be that some computers on the LAN don't autodetect this?
>
> Could it be that they then send (or try to) a packet longer than 1500
> bytes, which then unceremonially gets dropped by the Linux gateway
> (incapable of handling the receive)?
>
> Could it be that the "set MTU on all computers on the network" is merely
> a workaround for this fix?
>
>                        Shachar
>
>
> =================================================================
> To unsubscribe, send mail to linux-il-request@linux.org.il with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail linux-il-request@linux.org.il
>


=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il