This is partially OT, but I believe in the general interest of all (who
use or ever plan to use ADSL).
Here's what I figured out from using it/reading the list/reading Mulix's
excelent howto, and talking to lots of friends who also did this:
If I understand correctly, your home box (let's call it the linux
router) runs a proggie called pptp, which on one side emulates a
Point-to-Point network interface, and on the other, opens a TCP session over bezeq's
IP network
to the 10.0.0.138 IP address, to port 1723.
10.0.0.138 is your ADSL modem, but all it does IP-level "static" or
"destination" NAT on the packets, and reforwards them to your favourite
redback server, located somewhere in a virtual cloud called "Bezeq". It
doesn't dig as deep as the application layer where your ppp-wrapped "real
internet traffic" lives. It doesn't even dig as deep as your ISP
authentication.
I am not sure about the next part, it could be one of tree:
For the application layer of your tunnel packets , the session exists
between:
1. Your home linux router and the redback server. The ADSL
modem only forwards them over it's DSL/ethernet interfaces, depending on
direction. The redback decrypts the packets and resends the data somehow
to your ISP. Highly Unlikely.
OR
2. The machine at your ISP and your home linux router, to where the
redback also only forwards them (doing the same as your modem - NATTING
and routing), not really caring what's inside.
OR
3. The Machine at your ISP and your home linux router, only the Redback
DOES, in addition to NATTING and routing dig into the application layer of
these packets, and :
a. checks which ISP the packets need to go to
b. (possibly) - performs authentication. (I don't think so).
I'd wager on [3].
Now to fragmentation problems:
Fragmentation is done when data passes between layers, and, providing that
I trust my ISP's tunnel enterance and my linux router's tunnel exit (or
vice versa), fragmentation somewhere in the tunnel infrastructure is
botched up.
Now, for my two Issues:
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.
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?
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?
If not, can THIS technique be used to work around the problem?
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."
=================================================================
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]
