> 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 b
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
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 nee
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 ethersid
>
> 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"
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 spot
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,
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 so
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 bi
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
> 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
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 th
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
Yes.. and just for the fun of it, I confirmed that this is the same from a
Masq'd Linux box also...
On Tue, 12 Jun 2001, Miki Shapiro wrote:
>
> We're talking about the Windows client MTU, not the ppp-interface-on-linux-router
>MTU. right?
>
> On Tue, 12 Jun 2001, Cedar Cox 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
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, d
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
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,
> 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 o
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 broken
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.
> 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 lookin
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
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 i
24 matches
Mail list logo
