multiple ppp links and routing ..

Hello all,

I'm using debian stable on a machine with multiple serial modems that
would eventually simultaneously connect the machine to the Internet.

To do so, I studied ppp, serial, modem and networking HowTo's including
lartc but still I found lots of informations and I'm not sure what ever
the solution I'm adopting is the better.Also, some things were debian
related!

So at the end, to make it simplier, let's say we have two standard
serial modems (56k) one on ttyS0 and one on ttyS1 :

I configure the files : /etc/network/interfaces with :

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0

The file /etc/ppp/peers/ppp_provider1 :

hide-password
noauth
connect "/usr/sbin/chat -v -f /etc/chatscripts/chat_script1"
debug
/dev/ttyS0
115200
noipdefault
user "(E-Mail Removed)"
ipparam ppp_provider1
usepeerdns

The file /etc/chatscripts/chat_script1 :

ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT
'NO DIAL TON
E' ABORT 'NO ANSWER' ABORT DELAYED
'' ATZ
OK-AT-OK "ATDT0331051010"
CONNECT \d\c

and finally both /etc/ppp/pap-secrets and /etc/ppp/chap-secrets to :

"(E-Mail Removed)" * "p455w04d"

This for one connection, for the other connection would be pretty
similar but let's say I would call the script ppp_provider2


Anyway, when I want to make a connection i use pon ppp_providerx and
this would create in ifconfig the interface pppX where X is either 0 or
1 depending on if a ppp connection was already established or not.

Because I need to apply the routing, and because pon returns
immediately I have to write some scripts to execute after ppp goes
online, ppp ip-up is the solution but this would execute every time a
ppp connection is established and I have to create a different routing
table for each ppp connection :

I allow some users of the LAN (eth0) to use ppp1, and some other users
to use ppp2 and I know at the time i lunch pon which users should use
one or the other Internet access, my problem is that the connection
could be even 10 and I should be able to create a table with iproute2
on the fly for each connection and if already exist simply delete and
flush .. I'm a bit confused!

I don't know how to write this script, I know I have $1 to $6 as
parameters of the connection and that I could use a couple of if
condition to check whatever is the first , second, third ppp connection
being bought up and then, dunno how, create/delete/update the tables ..

Thanks for any help or suggestion!

On 28 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed). com>, Lawrence wrote:

>I'm using debian stable on a machine with multiple serial modems that
>would eventually simultaneously connect the machine to the Internet.

Is this a continuation of the stuff you posted about back in January in
the uk.comp.os.linux newsgroup?

>The file /etc/ppp/peers/ppp_provider1 :

OK

>The file /etc/chatscripts/chat_script1 :
>
> ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT
>'NO DIAL TONE' ABORT 'NO ANSWER' ABORT DELAYED

Does your modem(s) really know how to say all of those words?

> '' ATZ

Do you know specifically that this is the correct init-string for your
modem? "ATZ" sets what has been saved to NVRAM setting 0, and unless you
know positively that what is set in NVRAM, you are better off using the
factory default setting - almost always AT&Fn where 'n' is 0, 1, or maybe
2.

> OK-AT-OK "ATDT0331051010"

OK ATDT0331051010

>Because I need to apply the routing, and because pon returns
>immediately I have to write some scripts to execute after ppp goes
>online, ppp ip-up is the solution but this would execute every time a
>ppp connection is established and I have to create a different routing
>table for each ppp connection :

Use a 'case' statement based on the IP address of the peer (variable $5
in /etc/ppp/ip-up)

man bash
man ppp
man route

case "$5" in
12.34.56.78)
/sbin/route add -net 12.34.56.0 broadcast 12.34.56.255 netmask
255.255.255.0 gw $5 $1
;;
23.45.67.89)
/sbin/route add -net 23.45.67.0 broadcast 23.45.67.255 netmask
255.255.255.0 gw $5 $1
;;
esac

Then create a similar /etc/ppp/ip-down script that removes the route, again
using a case statement based on the peer's IP address.

>I allow some users of the LAN (eth0) to use ppp1, and some other users
>to use ppp2 and I know at the time i lunch pon which users should use
>one or the other Internet access, my problem is that the connection
>could be even 10 and I should be able to create a table with iproute2
>on the fly for each connection and if already exist simply delete and
>flush .. I'm a bit confused!

You'll also need to add some firewall rules to restrict use of each
connection. When you '/sbin/route add -net' that route is available
to _all_ users, not just the one who brought up the connection.

>I don't know how to write this script, I know I have $1 to $6 as
>parameters of the connection and that I could use a couple of if
>condition to check whatever is the first , second, third ppp connection
>being bought up and then, dunno how, create/delete/update the tables ..

A case statement is probably easier. See the Bash-Prog-Intro-HOWTO and
the "Advanced Bash Scripting Guide" from http://tldp.org/guides.html.

Old guy

Moe Trin wrote:

> Is this a continuation of the stuff you posted about back in January in
Yes, it is

> Does your modem(s) really know how to say all of those words?

I don't know.All I did was looking for example and copying settings I
though I should use.
Let's say that if it understands this words it would be usefull ?

> > '' ATZ
>
> Do you know specifically that this is the correct init-string for your
> modem? "ATZ" sets what has been saved to NVRAM setting 0, and unless you
> know positively that what is set in NVRAM, you are better off using the
> factory default setting - almost always AT&Fn where 'n' is 0, 1, or maybe
> 2.
>
> > OK-AT-OK "ATDT0331051010"
>
> OK ATDT0331051010

So I should only use what you say ?
I just copied the result of some configuration tool available for
debian ..
I also had a look in how to's but I wanted to use the most standard
setting I could ..


> You'll also need to add some firewall rules to restrict use of each
> connection. When you '/sbin/route add -net' that route is available
> to _all_ users, not just the one who brought up the connection.
>

This is already done by iptables .. it first refuses anyone, adding
manually who can be routed but then also i have a routing table for
each connection (with all users as rules) and no default route .. I
think is enough, is it ?
Oh, let me ask an other question, is it possible to count data in/out
for a certain IP with iptables and log ? like 40 mb in and 90 mb out
for user 10.0.0.2
> A case statement is probably easier. See the Bash-Prog-Intro-HOWTO and
> the "Advanced Bash Scripting Guide" from http://tldp.org/guides.html.

Hey thanks and good memory!

On 29 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed). com>, Lawrence wrote:

>Moe Trin wrote:

>> Does your modem(s) really know how to say all of those words?
>
>I don't know.All I did was looking for example and copying settings I
>though I should use.
>Let's say that if it understands this words it would be usefull ?

It's just a minor waste of CPU cycles and RAM - really not of major
importance. The idea is to know what it takes to talk to the modem, and
do that. With the normal setup, you need only look for "NO DIALTONE" (USR)
or "NO DIAL TONE" (Rockwell) if you expect that the modem might become
unplugged or the telephone company go tits up, "BUSY", and "NO CARRIER"
(which occurs if the phone gets answered, but the modem can't agree how
to talk with whatever answered).

>>> OK-AT-OK "ATDT0331051010"
>>
>> OK ATDT0331051010
>
>So I should only use what you say ?
>I just copied the result of some configuration tool available for
>debian ..
>I also had a look in how to's but I wanted to use the most standard
>setting I could ..

The 'OK-AT-OK' sequence is useless. It says to expect a response of "OK"
to the preceding command, and if you haven't received that response within
the TIMEOUT time (default is 45 seconds), then send the Hayes Command
Prefix ("I'm going to send a command") and expect that to cause the modem
to wake up. If your sending the modem init string failed to produce the
expected OK, there is no reason to expect that sending the command prefix
is going to do anything different. This sequence seems to have started
around 1995, as I can find a similar sequence in the ppp-on-dialer script
in ppp-2.2.0 (script dated 8 August 1995) though there is no author credited
that I can see (and this sequence is not used in ppp-2.1.2d from May 1995).
There, it's the even more interesting 'OK-+++\cOK ATH0' which says that if
you don't get the "OK" you should send the Hayes command break sequence
(at least a second of silence, three + characters, and another period of
silence) to get the modem to go to the command mode - then the command tells
the modem to hang up the phone. Now, I don't know about you, but if the
system was keeping the phone off-hook all of the time, I'd like to know
about this now, rather than wait until the end of the month when I get this
monstrous bill from the telephone company. (It's also interesting that
this same script - same file date and all - is still part of ppp-2.4.4b1
from August 2005, although it's not installed by default any more.)

>Oh, let me ask an other question, is it possible to count data in/out
>for a certain IP with iptables and log ? like 40 mb in and 90 mb out
>for user 10.0.0.2

[compton ~]$ whatis pppstats
pppstats (8) - print PPP statistics
[compton ~]$

That's been part of the ppp package since at least 2.1.2d, though the
data count values were not reported until 2.3.0. Also, ppp-2.3.8 (from
May 1999) added environment variables CONNECT_TIME, BYTES_SENT and
BYTES_RCVD for the ip-down and auth-down scripts indicating the statistics
for the connection just terminated. (CONNECT_TIME is in seconds.) You
can access those variables in /etc/ppp/ip-down. It's in the man page.

Old guy

(E-Mail Removed) (Moe Trin) writes:

>On 29 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
><(E-Mail Removed) .com>, Lawrence wrote:

>>Moe Trin wrote:

>>> Does your modem(s) really know how to say all of those words?
>>
>>I don't know.All I did was looking for example and copying settings I
>>though I should use.
>>Let's say that if it understands this words it would be usefull ?

>It's just a minor waste of CPU cycles and RAM - really not of major
>importance. The idea is to know what it takes to talk to the modem, and
>do that. With the normal setup, you need only look for "NO DIALTONE" (USR)
>or "NO DIAL TONE" (Rockwell) if you expect that the modem might become
>unplugged or the telephone company go tits up, "BUSY", and "NO CARRIER"
>(which occurs if the phone gets answered, but the modem can't agree how
>to talk with whatever answered).

>>>> OK-AT-OK "ATDT0331051010"
>>>
>>> OK ATDT0331051010
>>
>>So I should only use what you say ?
>>I just copied the result of some configuration tool available for
>>debian ..
>>I also had a look in how to's but I wanted to use the most standard
>>setting I could ..

>The 'OK-AT-OK' sequence is useless. It says to expect a response of "OK"

Almost certainly correct. I could imagine a scenario where the modem was
just being hung up whent the first AT command arrived and it was not ready
for it, and did not issue an OK.

>to the preceding command, and if you haven't received that response within
>the TIMEOUT time (default is 45 seconds), then send the Hayes Command
>Prefix ("I'm going to send a command") and expect that to cause the modem
>to wake up. If your sending the modem init string failed to produce the
>expected OK, there is no reason to expect that sending the command prefix
>is going to do anything different. This sequence seems to have started
>around 1995, as I can find a similar sequence in the ppp-on-dialer script
>in ppp-2.2.0 (script dated 8 August 1995) though there is no author credited
>that I can see (and this sequence is not used in ppp-2.1.2d from May 1995).
>There, it's the even more interesting 'OK-+++\cOK ATH0' which says that if
>you don't get the "OK" you should send the Hayes command break sequence
>(at least a second of silence, three + characters, and another period of
>silence) to get the modem to go to the command mode - then the command tells
>the modem to hang up the phone. Now, I don't know about you, but if the
>system was keeping the phone off-hook all of the time, I'd like to know
>about this now, rather than wait until the end of the month when I get this
>monstrous bill from the telephone company. (It's also interesting that
>this same script - same file date and all - is still part of ppp-2.4.4b1
>from August 2005, although it's not installed by default any more.)

This one makes more sense, since it is possible that the modem was left in
a weird state of not having hung up. Most telco will disconnect the line if
the far side has hung up, but your modem may not recognize it and stay on
line. Again a somewhat far fetched scenario, but possible.

Not sure how you would be informed about it. If the OK never came back what
would you want your dialup script to do? Just fail?


>>Oh, let me ask an other question, is it possible to count data in/out
>>for a certain IP with iptables and log ? like 40 mb in and 90 mb out
>>for user 10.0.0.2

>[compton ~]$ whatis pppstats
>pppstats (8) - print PPP statistics
>[compton ~]$

>That's been part of the ppp package since at least 2.1.2d, though the
>data count values were not reported until 2.3.0. Also, ppp-2.3.8 (from
>May 1999) added environment variables CONNECT_TIME, BYTES_SENT and
>BYTES_RCVD for the ip-down and auth-down scripts indicating the statistics
>for the connection just terminated. (CONNECT_TIME is in seconds.) You
>can access those variables in /etc/ppp/ip-down. It's in the man page.

> Old guy

On 30 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<e84345$bhi$(E-Mail Removed)>, Unruh wrote:

>(E-Mail Removed) (Moe Trin) writes:

>>The 'OK-AT-OK' sequence is useless. It says to expect a response of "OK"
>
>Almost certainly correct. I could imagine a scenario where the modem was
>just being hung up whent the first AT command arrived and it was not ready
>for it, and did not issue an OK.
>
>>to the preceding command, and if you haven't received that response within
>>the TIMEOUT time (default is 45 seconds),

I purposely included the rest of the phrase I wrote here. The modem has 45
seconds in the default chat configuration to hang up the phone from the
previous instance, while pppd is closing things down and killing off the
lock files, etc. I just ran a couple of quick checks here, and from what
I can see, the time between the modem hangup command (DTR goes low) to
the exit of pppd (I run scripts out of ip-down.local which night add a
second or two) and clearing the lock file seems to be running between 5
and 8 seconds. Thus, an attempt to run another instance of pppd would
_likely_ run into the lock file of the previous instance. I also tried
to run back-to-back sessions (a script that runs my existing dialin
script, manually killing pppd with a killall from outside, and on exit
of that session immediately begins a second) with no indication of a
problem. But YMMV.

>This one makes more sense, since it is possible that the modem was left in
>a weird state of not having hung up. Most telco will disconnect the line if
>the far side has hung up, but your modem may not recognize it and stay on
>line. Again a somewhat far fetched scenario, but possible.

Were this the case, I'd certainly like to be informed of the problem, as
this "is not normal".

>Not sure how you would be informed about it. If the OK never came back what
>would you want your dialup script to do? Just fail?

That's what the "NO DIALTONE" abort string is for, but in any case chat
would fail due to the lack of the OK. A " pppd[5743]: Connect script failed"
in /var/log/messages is a clue to investigate things. I used to get this
with some frequency during the summer. The phone-droid wouldn't find any
problem. Finally, after the water supply pipe from the street burst (the
home builder had skimped and used PolyButylene instead of real pipe) and
I had the pipe replaced with copper, we discovered that the ground lead
was connected to a two foot copper stub of the feed pipe (it transitioned
to PB about 9 inches below grade) that things improved. We then had the
power company come in and check _their_ grounding, and _it_ was found to
be deficient. Idiots who shave corners to save a buck - at least the
plumber and electricians who did the work during construction had gone
out of business, so even though I did file a complaint with the state
licensing boards, it was to late.

Old guy

(E-Mail Removed) (Moe Trin) writes:

>On 30 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
><e84345$bhi$(E-Mail Removed)>, Unruh wrote:

>>(E-Mail Removed) (Moe Trin) writes:

>>>The 'OK-AT-OK' sequence is useless. It says to expect a response of "OK"
>>
>>Almost certainly correct. I could imagine a scenario where the modem was
>>just being hung up whent the first AT command arrived and it was not ready
>>for it, and did not issue an OK.
>>
>>>to the preceding command, and if you haven't received that response within
>>>the TIMEOUT time (default is 45 seconds),

>I purposely included the rest of the phrase I wrote here. The modem has 45
>seconds in the default chat configuration to hang up the phone from the
>previous instance, while pppd is closing things down and killing off the

I have no idea what is in the rest of his script, but almost noone actually
leaves the default time at 45 sec, but rather sets things up to give say a
5 or 10 sec timeout. But it would not matter. If you sent the modem an AT,
it would be the state of the modem when the AT was received that would
matter. The fact that 10 sec later the modem would be reset would not
produce an OK fromt eh AT received during the initial time.

Actually I know of no instance in which a 45 sec timeout is useful EXCEPT
during the dialing phase, when 45 sec for the far side to pick up the phone
and start negotiating may be OK ( although even then it is probably too
long) ( on a reasonable local phone call
that is the time of about 8 or 9 rings. I use TIMEOUT 24 when I use chat
as a phone dialer).

>lock files, etc. I just ran a couple of quick checks here, and from what
>I can see, the time between the modem hangup command (DTR goes low) to
>the exit of pppd (I run scripts out of ip-down.local which night add a
>second or two) and clearing the lock file seems to be running between 5
>and 8 seconds. Thus, an attempt to run another instance of pppd would
>_likely_ run into the lock file of the previous instance. I also tried
>to run back-to-back sessions (a script that runs my existing dialin
>script, manually killing pppd with a killall from outside, and on exit
>of that session immediately begins a second) with no indication of a
>problem. But YMMV.

>>This one makes more sense, since it is possible that the modem was left in
>>a weird state of not having hung up. Most telco will disconnect the line if
>>the far side has hung up, but your modem may not recognize it and stay on
>>line. Again a somewhat far fetched scenario, but possible.

>Were this the case, I'd certainly like to be informed of the problem, as
>this "is not normal".

>>Not sure how you would be informed about it. If the OK never came back what
>>would you want your dialup script to do? Just fail?

>That's what the "NO DIALTONE" abort string is for, but in any case chat
>would fail due to the lack of the OK. A " pppd[5743]: Connect script failed"
>in /var/log/messages is a clue to investigate things. I used to get this
>with some frequency during the summer. The phone-droid wouldn't find any
>problem. Finally, after the water supply pipe from the street burst (the
>home builder had skimped and used PolyButylene instead of real pipe) and
>I had the pipe replaced with copper, we discovered that the ground lead
>was connected to a two foot copper stub of the feed pipe (it transitioned
>to PB about 9 inches below grade) that things improved. We then had the
>power company come in and check _their_ grounding, and _it_ was found to
>be deficient. Idiots who shave corners to save a buck - at least the
>plumber and electricians who did the work during construction had gone
>out of business, so even though I did file a complaint with the state
>licensing boards, it was to late.

> Old guy

On 1 Jul 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<e86ptb$85n$(E-Mail Removed)>, Unruh wrote:

>I have no idea what is in the rest of his script, but almost noone actually
>leaves the default time at 45 sec, but rather sets things up to give say a
>5 or 10 sec timeout.

Hmmm... http://www.theory.physics.ubc.ca/ppp-linux.html

[compton ~]$ grep timeout ppp-linux.txt
still alive) will reset the timer and stop the idle timeout from ever
[compton ~]$ grep -- -t ppp-linux.txt
instead-- one of Linux's charms.--thanks to M. Cook for pointing this
[compton ~]$

Actually, I don't think I've ever used the option.

>But it would not matter. If you sent the modem an AT, it would be the state
>of the modem when the AT was received that would matter. The fact that 10
>sec later the modem would be reset would not produce an OK fromt eh AT
>received during the initial time.

Poorly worded on my part. As mentioned below this point, I'm seeing 5 to 8
seconds between DTR going low and the lock file being removed. Now there is
(to the best of my knowledge) nothing that the modem can do that might delay
or allow removal of the lock and pppd exiting, but watching the lights on
the phone and the modem, in my case DTR low -> line in use going off is a
matter of no more than a second. Looking at several modem manuals, this may
be a settable "S" parameter, depending on manufacturer and chipset.

>Actually I know of no instance in which a 45 sec timeout is useful EXCEPT
>during the dialing phase, when 45 sec for the far side to pick up the phone
>and start negotiating may be OK ( although even then it is probably too
>long) ( on a reasonable local phone call
>that is the time of about 8 or 9 rings. I use TIMEOUT 24 when I use chat
>as a phone dialer).

I see significant variation with the three dial-in services I use - anywhere
from 21 to 34 seconds between pppd started by $USER and "Serial connection
established". I do have one provider who seems to have one b0rked terminal
server that acts like a screwed up ACCM mask - I've set 'lcp-max-configure'
to 3 to bail quicker when the round-robin happens to hit that one. But
otherwise, I think I've always gone with default timings.

Old guy

> [compton ~]$ whatis pppstats
> pppstats (8) - print PPP statistics
> [compton ~]$
>
> That's been part of the ppp package since at least 2.1.2d, though the
> data count values were not reported until 2.3.0. Also, ppp-2.3.8 (from
> May 1999) added environment variables CONNECT_TIME, BYTES_SENT and
> BYTES_RCVD for the ip-down and auth-down scripts indicating the statistics
> for the connection just terminated. (CONNECT_TIME is in seconds.) You
> can access those variables in /etc/ppp/ip-down. It's in the man page.
>
> Old guy

Well, right.
This would be enough if what I was looking for was a general connection
information.
The thing is I need this information per user, and the user could be
checked either by IP either by MAC.
Also, I might need to do the same thing for an ethernet connection so
using iptables would be more convienient.
I'm going to make some rules that would log the packet size of each
packet sent by selected IPs or MACs

Thanks all for the help