> 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.
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.
> 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? :-)
---= 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]
