> 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 handling packets
larger than so-and-so.
Check out what I just stumbled upon:
One of the things I did when playing around with the whole thing is limit
the ppp interface more than 1452 - I limited it to 1400. And that solved
the problem too. Which means linux frags the internet traffic just fine,
and sends it out as 1400+pppherader instead of 1452+pppheader packets to
herr frauline modem. The eth MTU remains on 1500.
That means that the modem has a problem handling large chunks indeed (and
as you pointed out, since it's the pptp server, it's not a fragmentation
issue) - just a "send me a large packet and I'll throw it away
without telling you anything" thing.
Now the question is what it defines as large......
> Maybe i'll do another test about this problem when we start a new test
> with Bezeq ...
Make sure you get "Our subscribers don't get any ATUR2/3 modems" in your
contract with them ;-)
Cheers!
---= 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 Thu, 14 Jun 2001, Dani Arbel wrote:
>
>
> 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 larger packets
> > than 1452 bytes on it's etherside.
>
> 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.
> on the other hand, as I mentioned before, replacing the ADSL pptp server
> with a linux pptp server does not show this problem. So I believe this is
> a bug/setup error in bezeq side (adsl modem, DISLAM or redback).
>
> Maybe i'll do another test about this problem when we start a new test
> with Bezeq ...
>
> Dani
>
>
> >
> > 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]
