On Tue, 25 May 2010 00:54:53 +0200 patrick kristensen
<kristensenpatri...@gmail.com> wrote:
> 2010/5/24, J.C. Roberts <list-...@designtools.org>:
> >
> > I realize you must be frustrated while learning something new, but
> > I am frustrated by you not paying attention. Now let's look at what
> > I wrote one more time:
> >
> >>> set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
> >>> part#1 part#2 part#3 part#4
> >
> > The first chunk of part#1, namely '10.0.0.1', says I want my IP
> > address to be 10.0.0.1 but the second chunk of part#1, namely the
> > '/0', is a netmask which says I will accept any IP address the
> > remote system wants me to use on my side.
> >
> > The first chunk of part#2, namely '10.0.0.2', says I want the remote
> > side to use IP address 10.0.0.2 but the second chunk of part#2,
> > namely the '/0', says I will accept any IP address the remote
> > system wants to use on their side.
> >
> > The IP addresses (and netmasks) stated in part#1 and part#2 are
> > important. They should never be the same, and they should never be
> > set to default route address ('0.0.0.0'). This is why two separate
> > private IP addresses are used in the above (10.0.0.1 and 10.0.0.2),
> > and also why the netmask '/0' in CIDR notation allows for the
> > remote side to pick any address it wants to use for *both* your IP
> > address and its IP address.
> >
> > If you forget the CIDR notation netmask on part#1 or part#2, you are
> > DEMANDING that the specified address be used, and if the other side
> > disagrees, your side will disconnect.
> >
> > The part#3 is the netmask assigned on my side to the resulting
> > connection after we negotiate addresses. Links between two systems
> > made with Point to Point Protocol (ppp) are "weird" in comparison
> > to typical network links, and some operating systems do not have a
> > specific PointToPoint netmask in the network stack, so the netmask
> > must be faked. Using '0.0.0.0' as the part#3 netmask tells the ppp
> > program to use what is available and the result is ppp will
> > typically set the netmask to '255.255.255.255' automatically.
> >
> > The part#4 is the trigger address which controls when ppp will try
> > to establish a connection. Since we set part#4 to the equivalent of
> > "any address" namely '0.0.0.0' any attempt to contact another
> > system will result in ppp automatically establishing the
> > connection. The thing to realize is 0.0.0.0 is roughly equivalent
> > to a default route.
> >
> > The stuff you are doing is just plain wrong:
> >
> >> set ifaddr 0.0.0.0/0 0.0.0.0-255.255.255.254 0.0.0.0 0.0.0.0
> >>> part#1 part#2 part#3 part#4
> >
> > Prior to negotiating address, you are saying your IP address will
> > initially be 0.0.0.0 and the remote IP address will also initially
> > be 0.0.0.0 The problem is, when two systems have the same IP
> > address you have a conflict. Additionally, since 0.0.0.0 equates to
> > the default route, this is very bad. Needless to say, the ppp(8)
> > software is compensating for your mistakes and doing the best it
> > can with your broken config.
> >
> > In the second chunk of your part#1, namely '/0', this netmask says
> > that you will accept any IP address the other side wants you to
> > use. This is good.
> >
> > In the second chunk of part#2, namely '-255.255.255.254' is using
> > the wrong syntax. The ppp(8) program might interpret this as a
> > range of addresses, or might interpret it as a pair of addresses,
> > or it might interpret it as a netmask. You should use simple CIDR
> > notation as described in the ppp man page.
> >
> > If ppp(8) is interpreting this bad second chunk of part#2 as a
> > netmask, the you are *DEMANDING* that the remote system use 0.0.0.0
> > or 0.0.0.1 as its IP address, and if the remote side refuses to use
> > one of those two addresses, then you will disconnect.
> >
> >
> > jcr
> >
>
> I didn't get the importance of having different addresses in part#1
> and #2 and assumed from 'ifconfig tun0' [ ... ] inet 95.124.11.167 -->
> 10.0.0.2 netmask 0xfffffff [ ... ] that HISADDR did not change to a
> valid one. I should have understood you were telling me the correct
> syntax literally. I see that this configuration works and i understand
> the syntax.
>
> Sorry this took longer time than it should and thanks for following
> through. I have found a great resource in 'Absolute OpenBSD: UNIX for
> the Practical Paranoid' (ISBN 1886411999) and of course this was a
> great first impression from this mailing list. I will try not to
> abuse it. All the best to you
>
Heck, in my last two paragraphs I put part#3 instead of part#2
(corrected above) but you still understood it. ;)
The Absolute OpenBSD is good but parts of it are now outdated, but this
is to be expected.
As for ppp(8), the ppp.conf file gives you full control of a a fairly
complex Finite State Machine (FSM), so the man page is long and takes
some effort to understand. Once you know the basics, ppp(8) becomes
*REALLY* useful for debugging and monitoring connections.
There are still a few minor problems with your chat script, but they do
not effect operation.
> set dial "ABORT BUSY TIMEOUT 5 \
> \"\" \
> AT OK-AT-OK \
> AT+CPIN=\\\"7291\\\" OK-AT-OK \
> AT+CFUN=1 OK-AT-OK \
> AT+CGDCONT=1,\\\"IP\\\",\\\"movistar.es\\\" OK-AT-OK \
> \\dATDT*99***1# TIMEOUT 30 CONNECT"
When you sent a command like "AT" modems which are in echo mode will
repeat the command you sent to it, and then give you the response to
the command. You send "AT" and the modem replies with:
AT
OK
If echo mode is turned off, the modem will just give you the response,
if any, followed by OK (in most situations). So with echo mode off, if
you sent "AT" (an abbreviation for "ATtention") to the modem, it would
reply with
OK
Some modems default to having echo mode turned on, but others default
to having echo mode turned off, and worse, whether or not the command
to turn echo mode on and off (ATE1 or ATE0 respectively) was implemented
also depends on the device itself, so you just don't know what to expect
(without testing). It's even more retarded than this... --Some devices
will not send an "OK" at all, and instead send reply with something
else.
The expected replies in the ppp(8) man page are written assuming you do
not know if the modem is in echo mode or not, but do expect the device
to give a trailing "OK<newline>" after other output, if any.
This line from your chat script is correct:
> AT OK-AT-OK \
The above says, send "AT" to the modem, and expect the response to
be either just "OK<newline>" or "AT<newline>OK<newline>" and ppp will
ignore any other output until it gets what it is expecting or times out
waiting for the correct response. Since all you really care about is
the trailing "OK<newline>" you could simplify the above as:
> AT OK \
And ppp will keep reading whatever is received from the modem until it
gets the "OK<newline>" it wants.
As you can see from your logs, your modem is in echo mode, so expecting
the 'AT+CPIN' 'AT+CFUN' and 'AT+CGDCONT' to be echoed back to you as
"AT<newline>OK<newline>" is wrong. Since you also accept just
"OK<newline>" ppp still accepts the response as correct.
You may want to add the following to your chat script:
AT+CTA=0 OK \
AT+CSQ OK \
The first, CTA ("Connect/Call Timer Activity"), *should* shut off the
internal activity timeout inside of the device itself.
The second, CSQ ("Connect/Call Signal Quality"), *should* give you
signal quality information.
Of course, unless you test them and look at your logs, you will not
know if those commands will work with your Ericsson F3500g device.
Also, you should test your ATDT dialing line without the leading '\\d'
since you may not need the two second delay. Some devices/providers
need the delay, but others do not, so if you can save 2 seconds on each
connect, go for it.
If you decide to use the auto mode of ppp (e.g. `ppp -auto esp`),
you'll need to have at least a 'timeout' set for the connection, but
it's also helpful to set your 'redial' to get past intermittent
failures.
set timeout 600
set redial 3+0-1 0
When you're testing/debugging stuff, you don't want to use the 'redial'
or 'timeout' above. If your config is wrong, the 'redial' will result in
an endless loop of trying to connect and failing. If you're using the
'timeout' you'll disconnect after the specified time and wonder why. ;)
Mobile Data Networks (a.k.a. Cellular Data Networks) are really
annoying in a number of ways, and each provider has it's own
esoteric (inane) idea of the "right" way to do things. Worse yet,
there's tons of little-known know-how on making mobile data network
connections reasonably stable.
1.) Make sure to occasionally update the PRL (Preferred Roaming List) on
the device. If you start having constant disconnects, it could be
caused by your PRL being out of date, so your provider cuts disconnects
you very quickly after you connect (5-120 seconds). Though you can
configure ppp(8) to automatically dial the PRL update number (typically
'*228' or '*22899') the time it takes to update the PRL (read TIMEOUT)
and the text of the response from the device (read "Expect:") varies a
whole lot, so getting it right is a real pain.
On *some* (read: "not all") devices, you can put the
AT+CDV=*228 TIMEOUT 120 OK \
or
AT+CDV=*22899 TIMEOUT 120 OK \
2.) Occasionally, keep an eye on your ability to ping other systems.
Many providers will allow ping at the start of a connection, and then
later block it. Disconnecting and reconnecting will usually fix this.
Many mobile data network providers do all sorts of wicked things to
connections for the sake of saving network/tower resources, and killing
off ICMP is just one of the many rotten tricks. The reason why they
kill ICMP is some idiots set their systems to continuously ping yahoo or
google to keep their connection alive. For this reason, make sure you
have your /etc/hosts correct so you don't create any spurious dns
lookups.
And don't be too surprised if you cannot reach mozilla.org. The
fucktards at mozilla have firefox configured by default to continuously
check for "news" at mozilla.org. This continuous tcp traffic can set
off alarms at your provider (like an auto ping of yahoo), and they will
block access to it.
Similar is true for various types of chat networks and programs,
particularly those which do any sort of "pinging" (ICMP, TCP, UDP) to
maintain the connection status to the server.
3.) Below is a nice addition to use as your /etc/ppp/ppp.linkdown
MYADDR:
set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
Any time your connection is closed, your tun0 interface is reset, so
the results of `ifconfig tun0` are actually meaningful. There nothing
worse than looking at `ifconfig tun0` and seeing a public IP address
(as if it's connected) even though the connection has died.
4.) IPv6 traffic will cause ppp(8) and pppd(8) to attempt a connection
even if your provider doesn't support IPv6. You can use pf to fix this
by setting the following in your /etc/pf.conf
block quick inet6
Additionally, you probably want to set the following in your
/etc/ppp/ppp.conf
default:
set log ...
disable ipv6cp
You can (and should) go further by using ppp(8) filters to set up
specific conditions for what traffic should cause ppp to"dial" (make
a connection) or stay "alive" (remain connected). If you look at the
".sample" files in /etc/ppp/ and the ppp(8) man page, you'll see how to
use the 'set filter dial ...' and 'set filter alive ...' commands.
Since most providers have bandwidth caps measuring all network
traffic, preventing your system from connecting when it doesn't need to
be connected is fairly important. Unlike the old POTS (land line)
modems, these new mobile data network devices (EVDO, HSPA, ...) can
establish a connection *very* quickly. This means only connecting when
you need to is pretty fast and will help save your bandwidth.
Now that you know all this great stuff about ppp, I expect you to be
able to assist the next person who asks for help with it on the list. ;)
Welcome To OpenBSD!
jcr
--
The OpenBSD Journal - http://www.undeadly.org
