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.
Warning: (not unlike my previous posts) this is gonna be a bit long:
Let's take this setup:
Client MTU, linux eth MTU and linux ppp MTU all get set to 1452.
Scenario 1:
1. SMTP packet (NO FRAG bit set to 1) leaves client,
2. reaches Linux box, (as a 1452 bit packet because that's how large
windows made it),
3. gets stuffed into the 1452 byte ppp interface,
4. gets fed to the pptp program,
5. pptp should now open a tunnel session to the DSL modem,
transmit a new packet with ppp capsule inside as a 1500 byte packet
(additional acquired headers) over the same 1452-byte-limited ethernet
interface, and on these tunnel packets the NO FRAG bit is also set, so it
(theoretically) cannot send it (yet, as the hping results showed, it
probbably ignores this bit and frags it anyway. bug/feature? )
Now, first let's decide on what's the right thing to do under the
circumstances
I *think* it's to take the 1452 byte SMTP packet, dump it, and send an
ICMP packet to the windows box saying "smaller please" because 1452 bytes
plus the mandatory ppp/tunnel header make up for 1500 bytes which MUST be
sent with the DON'T FRAG flag set to the modem, and it can only convey
1452 byte chunks on the ethernet interface.
So, given proper operation, the inability to frag further there are only
two possibilities:
1. It frags it nontheless, like in the hping example we saw yesterday, and
it still works.
2. The pptp program can send an ICMP message back to the windows client
saying "smaller please". This raises some questions I don't know how to
answer:
When, on the linux box, the 1452-limited eth interface rejects pptp's 1500
byte capsule packet, an ICMP return message should be sent to the
to the IP socket by the routing mechanism, and since ICMP messages are
portless, how exactly does the socket know which of it's potentially many
TCP or UDP applications should be asked to generate smaller traffic?
And how exactly is our application (pptp in this case) notified by the
socket that collected the ICMP message that it needs to generate smaller
chunks?
Scenario 2:
SMTP packet (NO FRAG bit set to 0) leaves client, reaches linux box, pptp
builds a header over it, comes up with a 1500 byte packet, tries to send
over 1452 interface, doens't manage to, and it's in a fix.
It can:
A. frag the original packet (If it's smart enough; is it?)
or:
B. the linux routing mechanism can disregard the DON'T FRAG field, frag it
nontheless, and it may work, yet we should assume it should not.
Answers/Comments/Insights/Corrections/Enlightenment anyone?
---= Miki Shapiro =------------------
---= Cell: (+972)-56-322433 =--------
---= ICQ: 3EE853 =-------------------
---= Windows Programmer in Rehab =---
-------------------------------------
"If at first you don't succeed...
.. Skydiving is probbably not for you."
On Tue, 12 Jun 2001, Dani Arbel wrote:
> 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 if they don't know this they can't be
> regarded as sys admins..).
>
> >
> > > | Final comment, I don't know this issue that well, but can these ISP
> > > | routers be convinced to send smaller packets by sending them ICMP
> > > | source-quench requests? is this done automatically by some socket
> > > | mechanism?
> > >
> > > I doubt that. The limitation are for a reason.
> >
> > I don't think you understood what I'm suggesting.
> >
> > I'm not suggesting we remove all packet-size limits on the intenet and go
> > off downloading 15MB MP3's in a single chunk.
> >
> > I'm suggesting perhaps this mechanism can be used to overcome the
> > "Orkit modem bug broken fragmentation mechanism problem that does not get
> > solved by setting your ppp MTU to 1452 bytes"
> > by impopsing a stricter packetsize limitation where it might help solve
> > the problem :-)
> >
> >
> >
> > ---= Miki Shapiro =------------------
> > ---= Cell: (+972)-56-322433 =--------
> > ---= ICQ: 3EE853 =-------------------
> > ---= Windows Programmer in Rehab =---
> > -------------------------------------
> >
> > "If at first you don't succeed...
> > .. Skydiving is probbably not for you."
> >
> > On Mon, 11 Jun 2001, Shlomo Matichin wrote:
> >
> > > 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.
> > > | Workaround: don't send packets larger than so-and-so from your linux box
> > > | to your ADSL modem.
> > > | The bottlenecking is done by the ppp interface (limited to MTU 1452) and
> > > | once we do that, We're completely sure that the packets that reach the
> > > | ADSL modem over the ethernet interface will be no larger than
> > > | (what the ppp driver constructed plus the 48 bytes it added) - 1500 bytes
> > > | and their ppp core will be no larger than 1452.
> > > | And if they're smaller than 1500, the modem doesn't need to frag them
> > > | before sending over the DSL. Problem Solved.
> > > |
> > > | Now can someonce PLEASE explain to me why we need a SECOND bottleneck by
> > > | limiting the MTU Win9x-client-to-linux-over-ethernet traffic, as this
> > > | traffic is bekol-mikre encapsulated in the ppp shell, and isn't seen by the
>ADSL
> > > | modem as IP traffic at all?
> > > | Why wouldn't an ethernet with 64K IP packets work? If I understand
> > > | correctly, it would.
> > >
> > > 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).
> > >
> > > | Issue II
> > > | --------
> > > | What if the other side of our (above-described) tunnel session between ISP
> > > | computer and home-linux-router (or redback and home-linux-router) frags
> > > | packets?
> > > |
> > > | Does the ADSL modem handle fragmented packets from the ISP side correctly?
> > > | My guess is "NO, it's broken here too", because this problem is
> > > | ISP specific.
> > > | Obviously this poses a problem from some ISP's and doesn't from
> > > | others. (probbably those that also worked around this problem by limiting
> > > | the MTU on the tunnel interface on THEIR side) to avoid sending too large
> > > | packets to your DSL modem.
> > > |
> > > | What do we do then? notify them?
> > >
> > > For this one of the reasons the ICMP protocol exsists. If a packet too
> > > large comes to a router, it drops it, and send back a ICMP message to the
> > > sender, with a "please fragment" request.
> > >
> > > | Final comment, I don't know this issue that well, but can these ISP
> > > | routers be convinced to send smaller packets by sending them ICMP
> > > | source-quench requests? is this done automatically by some socket
> > > | mechanism?
> > >
> > > I doubt that. The limitation are for a reason.
> > >
> > > Shlomi.
> > >
> > >
> > > --
> > > -------------------------------------------
> > > Shlomo Matichin [EMAIL PROTECTED]
> > > The Mosix Group www.mosix.org
> > >
> >
> >
> > =================================================================
> > To unsubscribe, send mail to [EMAIL PROTECTED] with
> > the word "unsubscribe" in the message body, e.g., run the command
> > echo unsubscribe | mail [EMAIL PROTECTED]
> >
>
>
> =================================================================
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
>
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
