[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bezeq ADSL setup
- To: Miki Shapiro <aris(at-nospam)pharoe.com>
- Subject: Re: Bezeq ADSL setup
- From: Dani Arbel <darbel(at-nospam)techunix.technion.ac.il>
- Date: Wed, 13 Jun 2001 09:06:53 +0300 (IDT)
- Cc: Happy Linux Campers <linux-il(at-nospam)linux.org.il>
- Delivered-To: linux.org.il-linux-il@linux.org.il
- In-Reply-To: <Pine.LNX.4.21.0106130755530.2913-100000@pharoe.com>
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
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 linux-il-request@linux.org.il with
> > > the word "unsubscribe" in the message body, e.g., run the command
> > > echo unsubscribe | mail linux-il-request@linux.org.il
> > >
> >
> >
> > =================================================================
> > To unsubscribe, send mail to linux-il-request@linux.org.il with
> > the word "unsubscribe" in the message body, e.g., run the command
> > echo unsubscribe | mail linux-il-request@linux.org.il
> >
>
=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il