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 ppp over ATM
> stream down to the DISLAM. From there it goes to the redback, still ass a
> ppp session. curently the service model of Bezeq ends the ppp session at
> the redback, but there are other possibilities.
> If you look into the pptp rfc you will notice that the ADSL have no choice
> but to decapsulate the pptp data.
> the points are:
>
> 1) It should work (theoreticaly) with the NAT clients maxmtu set to
> default (1500)
> 2) for some ADSL modems it does not work
> 3) the workaround in the HOWTO solves this problems
>
> as a remark : Orkit, having gone out of the ADSL market, probably do not
> care anymore about the bugs in the ADSL modem s/w .
Ooookie. That shows things in a different light.
(Especially the bit about bezeq using unsupported and
discontinued hardware. Even sounds like good'ol bezeq to me).
I just don't get one thing:
Is the problem solved by the INITIAL smtp or whatever packets being
smaller, or by the linux router sending smaller packets to the modem's eth
interface?
---= 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 Wed, 13 Jun 2001, Dani Arbel wrote:
> 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, line #2
> > , right after "write code decently" is "if it works, don't touch it"),
> > BUT
> > <flamethrower out> I would like to know how stuff works. And if it
> > doesn't, I would like to know where and how it's broken. I don't agree
> > with the poke-in-the-dark "let's try to shut down the refrigerator --> oh
> > look! the computer problem went away --> let's tell everybody to shut down
> > their fridge in the howto" attitude. I think there is far more than enough
> > network knowledge on this list to fully understand and diagnose this
> > problem. And to stick Bezeq's/ISP's noses in it someday when the time
> > comes. <done flaming>
> >
> > > note that the pptp tunnel ends at the
> > > ADSL , so the question of "don't fragment" is irelevant.
>
> The ADSL ACTUALY decripts (decapsulate) the pptp packets, leaving the
> stream of data as a ppp one, and then puts it back on a ppp over ATM
> stream down to the DISLAM. From there it goes to the redback, still ass a
> ppp session. curently the service model of Bezeq ends the ppp session at
> the redback, but there are other possibilities.
> If you look into the pptp rfc you will notice that the ADSL have no choice
> but to decapsulate the pptp data.
>
> >
> > I seriously think
> you're mistaken (although I may be
> too). > I quite seriously doubt if our ADSL modems actually decrypt the
> > pptp session to port 17xx from your linux box, take out the
> > tunnel data, establish a new tunnel to the redback and sends you ppp
> > packets there, acting as a pptp-application-protocol-proxy (Hell knows,
> > maybe they implemented an ICQ server in it's firmware too, just for the
> > kicks)
> >
> > I *think* (This involves about 1% of the work of implementing as compared
> > to what you suggested) an ADSL modem does the same thing that a FRAD and a
> > router do together only with an ADSL instead of Frame Relay connection:
> >
> > 1. Takes ethernet packets, decapsulates the IP packet inside. In the
> > ADSL case, This is not your IP traffic to the internet, but rather a
> > pptp-protocol application layer packet carrying a ppp core that is
> > supposed to eventually reach your ISP (not that the DSL modem really
> > cares what's inside). Deep inside that is your real internet
> > traffic.
> > 2. Does Destination-NAT (what checkpoint call "Static
> > NAT") by changing the target IP address of the IP packet to that of the
> > redback server (or the next hop on it's way there)
> > 3. Forwards the IP packet with the now-edited IP header through it's
> > second interface - the DSL line.
> > 4. The Redback server (as I assumed in a previous post) either decrypts
> > the data, again acting as proxy, and again, an unlikely scenario, or does
> > the same thing as the modem - NATs and resends the packet, bringing it to
> > the real end of the tunnel, which should be your ISP.
> No,
>
> 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 stuff (login into the beast and take a
> look...).
> The ppp session ends at the redback, or even farther (at the isp LAN or
> edge router), so the ip routing is done there (and not the ADSL).
> >
> > > It is interesting to discuss these issues, however, please do not ask for
> > > removing things from the HOWTO, unless you find it actualy wrong.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > I just pointed out that *it is* in the howto, and raised the question of
> > whether it was in any way relevant to the problem. I *did* pose the
> > question of whether the said issue was the sole reason for the problem
> > going away for anybody. And nobody suggested removing anything from any
> > howto yet.
> >
> > Anyone else have a coupl'a cents he can add to our collective
> > little pile? :-)
> While writing that part in the howto, I was wondering weather there is
> another way to solve this problem. I built a Linux pptp server and tested
> a setup similar to a linux box doing NAT connected to a ADSL uplink (but
> with the Linux box replacing the ADSL ). The pure Linux setup did not show
> that problem. Hence my conclusion is that the problem is with the ADSL
> modem (or the redback). Since I can't realy debug the setup/behaviour of
> both, I left the known solution in the HOWT.
>
> the points are:
>
> 1) It should work (theoreticaly) with the NAT clients maxmtu set to
> default (1500)
> 2) for some ADSL modems it does not work
> 3) the workaround in the HOWTO solves this problems
>
> as a remark : Orkit, having gone out of the ADSL market, probably do not
> care anymore about the bugs in the ADSL modem s/w .
>
> Dani
>
> >
> > ---= 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:
> >
> > > 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
> > > system status from "down" to "up".
> > > As for the MTU , packet sizes etc, I do believe that it is a bug in the
> > > ADSL routing s/w (at least ATUR 2). note that the pptp tunnel ends at the
> > > ADSL , so the question of "don't fragment" is irelevant.
> > > It is interesting to discuss these issues, however, please do not ask for
> > > removing things from the HOWTO, unless you find it actualy wrong.
> > >
> > > Dani
> > >
> > > On Tue, 12 Jun 2001, Cedar Cox wrote:
> > >
> > > >
> > > > 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:
> > > > >
> > > > > >
> > > > > > On Tue, 12 Jun 2001, Miki Shapiro wrote:
> > > > > >
> > > > > > >
> > > > > > > Is there anyone on this list for whom specifically this technique
>actually
> > > > > > > *solved* the broken sessions problem (as opposed to optimizing sessions
>by
> > > > > > > 20ms on the first packet?) ? If so, by accomplishing *what*?
> > > > > > >
> > > > > > > .. If not, maybe it's not worth bothering people with in the HowTo...
> > > > > >
> > > > > > Me, for one. Without a MaxMTU I typically never got a response beyond 4
> > > > > > packets, ie. things just did not work. With MaxMTU 1452, everything seems
> > > > > > to be just about normal (that is to say I haven't seen any problems yet).
> > > > > >
> > > > > > -Cedar
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > =================================================================
> > > > 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]
>
=================================================================
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]
