On Thu, 14 Jun 2001, Miki Shapiro wrote:
On Tue, 12 Jun 2001, Dani Arbel wrote:
WHY CHANGE DEFAULT MTU ON THE CLIENTS?
I do not realy know, but otherwise it won't work
Hmmm.
Sounds more like a pptp bug than an Orkit bug.
The problem occurs only when the LINUX box needs to handle
Dani's mail showed up really late on my box and that sort of completely
changes what I wrote in my last mail from this morning.
On Wed, 13 Jun 2001, Dani Arbel wrote:
The ADSL ACTUALY decripts (decapsulate) the pptp packets, leaving the
stream of data as a ppp one, and then puts it back on a
The strange point about the setup is that while you leave all interfaces
to their 1500 mtu default, it breaks. now when you reduce them all to 1452
it works. whatever fragmentation takes place in the 1500 setup, the same
hapens with 1452.
So it's not a fragmentation problem. It's just a bug
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
On Wed, 13 Jun 2001, Dani Arbel wrote:
You are totaly wrong. The ADSL just act as a bridge for the PPP session,
moving it from a pptp (or PPPoE in other setups) into an ADSL over ATM.
This is a simple task (implementing a PPTP server), and the ADSL anyway
have to implement lots of ATM
Shachar Shemesh wrote:
Dani Arbel wrote:
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
Oh, so you spotted this fact
On Tue, 12 Jun 2001, Dani Arbel wrote:
WHY CHANGE DEFAULT MTU ON THE CLIENTS?
I do not realy know, but otherwise it won't work
Hmmm.
Sounds more like a pptp bug than an Orkit bug.
The problem occurs only when the LINUX box needs to handle larger packets
than 1452 bytes on it's etherside.
Just wondering, does anyone know how to return to the root
command tree?
If you type 'ip' for example, IIRC you will get a prompt
something like
10.0.0.138 ip
Doing a @atm, for example, will change you to the atm
process, but I can't
figure out how to get back to root. Closing
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
Gentelman,
The BEZEQ-ADSL howto is based on the experience for more than one user,
with different ADSL equipment, at different phases of the service. As
mentioned on the howto itself, some of the setup details do not have good
theoretical explanations, but they do make the magic of changing the
Miki,
WHY CHANGE DEFAULT MTU ON THE CLIENTS?
I do not realy know, but otherwise it won't work
Hell, most of the SysAdmins I know don't even know how change the MTU
on any operating system ;-)
Thats why I have added the explanations of how this should be done.
(may I just mention here that
As mentioned on the howto itself, some of the setup details do not have
good theoretical explanations, but they do make the magic of changing
the system status from down to up.
No argument about the magic bit (Programmer's bible, Chapter 1, line #2
, right after write code decently is if it
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
Miki,
On Wed, 13 Jun 2001, Miki Shapiro wrote:
As mentioned on the howto itself, some of the setup details do not have
good theoretical explanations, but they do make the magic of changing
the system status from down to up.
No argument about the magic bit (Programmer's bible, Chapter 1,
This is partially OT, but I believe in the general interest of all (who
use or ever plan to use ADSL).
Here's what I figured out from using it/reading the list/reading Mulix's
excelent howto, and talking to lots of friends who also did this:
If I understand correctly, your home box (let's call
On Mon, 11 Jun 2001, Miki Shapiro wrote:
Now to fragmentation problems:
Fragmentation is done when data passes between layers, and, providing that
I trust my ISP's tunnel enterance and my linux router's tunnel exit (or
vice versa), fragmentation somewhere in the tunnel infrastructure is
It is my complete guess that the Linux 'NAT' code forwards packets and
only rewrites the source IP/port address on outgoing packets and does
not modify the packet in any other way (like fragmenting it). Someone
correct me if I am wrong ;)
You're both correct and incorrect.
You're looking
On Mon, 11 Jun 2001, Shlomo Matichin wrote:
well, it a bit beyond that. when you are NAT-ing, you are considered a
router, so when a packet that it bigger than the MTU of the outgoing
link is sent, you drop the packet. but an ICMP message please fragment
returns to the original sender.
hi miki,
| I
| ---
| If I understood this correctly from Mulix, when a too-large packet
| containing ppp-encapsulated stuff comes to the ADSL modem on
| ethernet interface and wants to go on the DSL interface, the frarmentation
| mechanism of the modem (I'm talking about my ATUR3) is
The MTU limit is because bezeq uses a fast ATM backbone for the whole
ADSL operation. ATM works with little packets. Also, even in LANs, system
administrator rarly give a MTU larger than 8K since this tends to slow
down RTT (round trip time).
In most LANs I know, the MTU on all machines on
Ok, I'll add my 4 cents.
That's two for the fragmantation mechanism, and two for the all hosts
on the network question. I'm afraid nothing of what I say will actually
answer the original question.
First - fraging:
When a router receives a packet which is too big to transfer to the next
hop,
On Mon, 11 Jun 2001, Shachar Shemesh wrote:
However, some protocols (such as TCP) don't care where their packets
end, and only about the entire stream. In order to save on fragmantation
costs, they employ an algorithm called Path MTU. Each packet is sent
with an IP flag called Don't
On Tue, 12 Jun 2001, Miki Shapiro wrote:
My opinion however remains that it is completely unneccesary to lower MTU
on all your windows clients and the linux ether interface, for the
benefit of time that you buy - the extra time that it takes your linux
router to get a too-large chunk,
23 matches
Mail list logo
