[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bezeq ADSL setup
- To: Happy Linux Campers <linux-il(at-nospam)linux.org.il>
- Subject: Re: Bezeq ADSL setup
- From: Shachar Shemesh <linuxil(at-nospam)consumer.org.il>
- Date: Wed, 13 Jun 2001 08:42:26 +0300
- CC: Miki Shapiro <aris(at-nospam)pharoe.com>
- Delivered-To: linux.org.il-linux-il@linux.org.il
- References: <Pine.LNX.4.21.0106120905100.1902-100000@nanu.visionforisrael.com> <3B25BA16.2040801@consumer.org.il>
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
- User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; 0.8) Gecko/20010215
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