ppp multilink not

I am trying to set up multilink ppp on my home Debian Sarge PC to
increase the very poor bandwidth from my gprs (GSM cell telephone)
Internet connection. I have ppp 2.4.3 with a custom-compiled 2.6.5
kernel with multilink enabled.

To enable multilink I added the option "multilink" to the ppp
connection options for both serial interfaces (/dev/ttyUSB0 and /dev/
ttyUSB1). This is all I did. It does not appear to be necessary to
set the "endpoint" option.

With the "multilink" option specified, during the "chat" negotiations
for /dev/ttyUSB0 (the first serial device) ppp sends a request to my
ISP to set the "endpoint". As the chat dialog below shows, my ISP
acknowledges and accepts this "endpoint", which makes me believe that
both negotiating machines support multilink. (It is impossible to ask
any questions of the state-owned ISP here in Costa Rica.)

The problem is, however, that when I dial up with my second modem (/
dev/ttyUSB1), instead of adding it to ppp0, it initiates a SECOND ppp
interface (ppp1). Shouldn't the "bundled" interface be ppp0, the
first multilink-enabled ppp connection? I have looked at the ppp
source and it looks like when multilink is enabled, a new ppp device
should not be created.

After scouring the Internet, the only info I have found on ppp
multilink for 2 modems is the ppp man page. The way I read it, the
"multilink" option needs to be specified for BOTH connections. Is
that right?

I have pasted the ppp chat dialog for device /dev/ttyUSB0 below. The
dialog when connecting /dev/ttyUSB1 looks similar, except it becomes
interface ppp1.

I hope someone can help me! Thanks in advance.

Lloyd

chat ppp negotiations
-------------------------------

Starting negotiation on /dev/ttyUSB0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x4e168c34> <pcomp>
<accomp> <mrr u 1500> <endpoint [MAC:00:10:b5:92:c8:12]>]
rcvd [LCP ConfRej id=0x1 <magic 0x4e168c34> <mrru 1500> <endpoint [MAC:
00:10:b5:92:c8:12]>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0x0> <pcomp> <accomp>
<auth pap>]
sent [LCP ConfAck id=0x1 <mru 1500> <asyncmap 0x0> <pcomp> <accomp>
<auth pap>]
sent [LCP EchoReq id=0x0 magic=0x0]
sent [PAP AuthReq id=0x1 user="lloyd" password=<hidden>]
rcvd [LCP EchoRep id=0x0 magic=0x0]
sent [PAP AuthReq id=0x2 user="lloyd" password=<hidden>]
rcvd [PAP AuthAck id=0x1 "Welcome!"]
Remote message: Welcome!
PAP authentication succeeded
Using interface ppp0
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <addr 192.168.111.111>]
sent [IPCP ConfAck id=0x1 <addr 192.168.111.111>]
rcvd [IPCP ConfRej id=0x1 <ms-dns3 0.0.0.0>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr 10.40.88.85> <ms-dns1
208.133.206.44>]
sent [IPCP ConfReq id=0x3 <addr 10.40.88.85> <ms-dns1
208.133.206.44>]
rcvd [IPCP ConfAck id=0x3 <addr 10.40.88.85> <ms-dns1
208.133.206.44>]
local IP address 10.40.88.85
remote IP address 192.168.111.111
primary DNS address 208.133.206.44
Script /etc/ppp/ip-up started (pid 11142)
Script /etc/ppp/ip-up finished (pid 11142), status = 0x0

On Sun, 08 Jul 2007 14:10:19 -0700, lstandish <(E-Mail Removed)>
wrote:

>The problem is, however, that when I dial up with my second modem (/
>dev/ttyUSB1), instead of adding it to ppp0, it initiates a SECOND ppp
>interface (ppp1).


Then your ISP is not supporting multilink - and there's nothing you
can do about it except ask them if they will implement it. Almost all
ISPs stopped providing multilink about 2 to 3 years ago. Google for
"multilink providers" to see if ML-IP might work for you. That same
search might be useful for persuasion when dealing with your ISP.
--
buck

Thanks for the reply, Buck. What puzzles me is that my ISP
acknowledged the "endpoint" request made by my machine, which
indicates to me that multilink was accepted:

sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x4e168c34> <pcomp>
<accomp> <mrr u 1500> <endpoint [MAC:00:10:b5:92:c8:12]>]
rcvd [LCP ConfRej id=0x1 <magic 0x4e168c34> <mrru 1500> <endpoint [MAC:
00:10:b5:92:c8:12]>]

I have noticed that the ISP will not acknowledge and echo back a
request that it does not agree to. Is multilink's "endpoint" an
exception? Do you know if the mulitlink option needs to be added to
BOTH interfaces' connection scripts (as I did)?

Googling the web shows that there is almost no information available
on using ppp multilink. If I ever get this working I'll put up a
webpage on it.

Lloyd

On Jul 8, 6:32 pm, buck <b...@private.mil> wrote:
> On Sun, 08 Jul 2007 14:10:19 -0700, lstandish <lstand...@gmail.com>
> wrote:
>
> >The problem is, however, that when I dial up with my second modem (/
> >dev/ttyUSB1), instead of adding it to ppp0, it initiates a SECOND ppp
> >interface (ppp1).
>
> Then your ISP is not supporting multilink - and there's nothing you
> can do about it except ask them if they will implement it. Almost all
> ISPs stopped providing multilink about 2 to 3 years ago. Google for
> "multilink providers" to see if ML-IP might work for you. That same
> search might be useful for persuasion when dealing with your ISP.
> --
> buck

On Mon, 09 Jul 2007 06:57:34 -0700, lstandish <(E-Mail Removed)>
wrote:

>I have noticed that the ISP will not acknowledge and echo back a
>request that it does not agree to. Is multilink's "endpoint" an
>exception? Do you know if the mulitlink option needs to be added to
>BOTH interfaces' connection scripts (as I did)?

If I recall correctly (it has been at least 2 years since I was able
to multilink), the endpoint ALWAYS was OK'd even though multilink
support had been eliminated. Except for the serial port, both of the
setups were identical on my end. So yes, your setup must include
multilink in both scripts.

It is far from a good solution, but you might want to have a look at
http://yesican/lartc/success.txt

Your "solution" is to get the ISP to implement multilink, which I'm
certain (from your results) they don't do now. Unless you see sth in
their web pages that says they do it, you can assert that they don't.

Remember, cellular packets are TERRIBLE for TCP/IP so even multilink
is not going to be particularly satisfying - though of course better
than a single connection.
--
buck

On Mon, 09 Jul 2007 10:11:39 -0700, buck <(E-Mail Removed)> wrote:

>It is far from a good solution, but you might want to have a look at
>http://yesican/lartc/success.txt

OOPS!:
http://yesican.chsoft.biz/lartc/success.txt

Buck, thanks for your information on multilink. Without your
information, I would still be wondering whether or not multilink might
be supported by my cellular ISP. As I said, it is impossible to find
out any technical information from them. Based on what you wrote,
I've concluded that my connection scripts were OK and that my ISP
simply does not support multilink.

My gprs (cellular) Internet service has bad latency, but once a
connection is established (say, to download a file) it does
surprisingly well: about 32,000 baud.

Thanks for the link to a workaround using iptables. However, I think
it would not work for a the connections established by a single user
using an Internet browser program (like Mozilla or Opera). Am I
wrong?

Lloyd

On Jul 9, 8:53 pm, buck <b...@private.mil> wrote:
> On Mon, 09 Jul 2007 10:11:39 -0700, buck <b...@private.mil> wrote:
> >It is far from a good solution, but you might want to have a look at
> >http://yesican/lartc/success.txt
>
> OOPS!:http://yesican.chsoft.biz/lartc/success.txt

On Thu, 12 Jul 2007 15:48:38 -0700, lstandish <(E-Mail Removed)>
wrote:

>Thanks for the link to a workaround using iptables. However, I think
>it would not work for a the connections established by a single user
>using an Internet browser program (like Mozilla or Opera). Am I
>wrong?

For normal browsing, no it won't help. For downloading via a browser
a large file (getRight, Etc.), yes it does help.

>Lloyd
>
>On Jul 9, 8:53 pm, buck <b...@private.mil> wrote:
>> On Mon, 09 Jul 2007 10:11:39 -0700, buck <b...@private.mil> wrote:
>> >It is far from a good solution, but you might want to have a look at
>> >http://yesican/lartc/success.txt
>>
>> OOPS!:http://yesican.chsoft.biz/lartc/success.txt