Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #2982 > unrolled thread

Establish an alternative connection to an embedded system

Back to article view | Back to comp.os.linux.networking

Contents

  Establish an alternative connection to an embedded system perf60@gmail.com - 2014-06-22 00:34 -0700
    Re: Establish an alternative connection to an embedded system Andrzej Adam Filip <anfi@onet.eu> - 2014-06-22 10:09 +0200
      Re: Establish an alternative connection to an embedded system perf60@gmail.com - 2014-06-22 01:46 -0700
        Re: Establish an alternative connection to an embedded system ein <ein@no.spam> - 2014-06-22 11:28 +0200
        Re: Establish an alternative connection to an embedded system ein <ein@no.spam> - 2014-06-22 11:36 +0200
          Re: Establish an alternative connection to an embedded system perf60@gmail.com - 2014-06-22 03:20 -0700
            Re: Establish an alternative connection to an embedded system Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-06-22 12:37 +0200
              Re: Establish an alternative connection to an embedded system ein <ein@no.spam> - 2014-06-22 13:45 +0200
                Re: Establish an alternative connection to an embedded system perf60@gmail.com - 2014-06-22 05:15 -0700
                  Re: Establish an alternative connection to an embedded system Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-06-22 14:20 +0200
                    Re: Establish an alternative connection to an embedded system perf60@gmail.com - 2014-06-22 05:46 -0700
                      Re: Establish an alternative connection to an embedded system Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-06-22 15:05 +0200
                        Re: Establish an alternative connection to an embedded system perf60@gmail.com - 2014-06-22 06:26 -0700
                          Re: Establish an alternative connection to an embedded system Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2014-06-22 15:47 +0200
                            Re: Establish an alternative connection to an embedded system perf60@gmail.com - 2014-06-22 07:02 -0700
    Re: Establish an alternative connection to an embedded system David Brown <david.brown@hesbynett.no> - 2014-06-22 14:45 +0200

#2982 — Establish an alternative connection to an embedded system

I have an embedded linux system on a remote farm. Usually I ssh into the system via the farms ADSL/WiFi system (using port forwarding). But sometimes the traffic on the farm blocks me from connecting.

To solve this, I have added a GSM/GPRS modem to the system. The modem uses the gsmmux giving 3 channels /dev/mux0 thru /dev/mux2. I have a python daemon watching SMS messages om /dev/mux1. Then I can send an SMS telling this daemon to set up ppp on /dev/mux0. After the link is set up, the daemon answer the SMS telling me the IP number of the alternative link.

Problem is, it does not work to ssh into this IP. Something is obviously missing in my setup - it only works from the system towards the internet.

What must I do to enable ssh to access my system via this alternative connection?

[toc] | [next] | [standalone]

#2983

perf60@gmail.com wrote:
> I have an embedded linux system on a remote farm. Usually I ssh into
> the system via the farms ADSL/WiFi system (using port forwarding). But
> sometimes the traffic on the farm blocks me from connecting.
>
> To solve this, I have added a GSM/GPRS modem to the system. The modem
> uses the gsmmux giving 3 channels /dev/mux0 thru /dev/mux2. I have a
> python daemon watching SMS messages om /dev/mux1. Then I can send an
> SMS telling this daemon to set up ppp on /dev/mux0. After the link is
> set up, the daemon answer the SMS telling me the IP number of the
> alternative link.
>
> Problem is, it does not work to ssh into this IP. Something is obviously missing in my setup - it only works from the system towards the internet.
>
> What must I do to enable ssh to access my system via this alternative connection?

1) Have you changed ListenAddress in /etc/ssh/sshd_config ?
2) Have you implemented source based TCP/IP routing to make _both_ links work
   at the same time? [unless your system is for monitoring only]
3) Have you used tcptracerourote to track TCP connections attempts?
   [ There may be a firewall in between ]
4) AFAIR some GSM internet providers block incoming TCP connections.
   You may try to overcome it by making outgoing ssh connection over GSM link
   with -R port forwarding

-- 
[Andrew] Andrzej A. Filip  -  https://www.linkedin.com/in/andfil

[toc] | [prev] | [next] | [standalone]

#2984

kl. 10:09:21 UTC+2 søndag 22. juni 2014 skrev Andrzej Adam Filip følgende:
> perf60@gmail.com wrote:
> 
> > I have an embedded linux system on a remote farm. Usually I ssh into
> 
> > the system via the farms ADSL/WiFi system (using port forwarding). But
> 
> > sometimes the traffic on the farm blocks me from connecting.
> 
> >
> 
> > To solve this, I have added a GSM/GPRS modem to the system. The modem
> 
> > uses the gsmmux giving 3 channels /dev/mux0 thru /dev/mux2. I have a
> 
> > python daemon watching SMS messages om /dev/mux1. Then I can send an
> 
> > SMS telling this daemon to set up ppp on /dev/mux0. After the link is
> 
> > set up, the daemon answer the SMS telling me the IP number of the
> 
> > alternative link.
> 
> >
> 
> > Problem is, it does not work to ssh into this IP. Something is obviously missing in my setup - it only works from the system towards the internet.
> 
> >
> 
> > What must I do to enable ssh to access my system via this alternative connection?
> 
> 
> 
> 1) Have you changed ListenAddress in /etc/ssh/sshd_config ?
> 
> 2) Have you implemented source based TCP/IP routing to make _both_ links work
> 
>    at the same time? [unless your system is for monitoring only]
> 
> 3) Have you used tcptracerourote to track TCP connections attempts?
> 
>    [ There may be a firewall in between ]
> 
> 4) AFAIR some GSM internet providers block incoming TCP connections.
> 
>    You may try to overcome it by making outgoing ssh connection over GSM link
> 
>    with -R port forwarding
> 
> 
> 
> -- 
> 
> [Andrew] Andrzej A. Filip  -  https://www.linkedin.com/in/andfil

Thanks for your answer!

1) No, ListenAddress is commented. The default is to listen on all local addresses - so do I need to spesify?

2) No, I do not have the knowledge yet. I believe this is a problem. I guess I will have to write scripts in the /etc/ppp/ip-up.d and ip-down.p that should modify routing. My system is only monitoring local devices. Any help is very welcome ;-)
3) Not yet.
4) I do not know Telenor's (Norway) policy.

[toc] | [prev] | [next] | [standalone]

#2985

perf60@gmail.com wrote:
> kl. 10:09:21 UTC+2 søndag 22. juni 2014 skrev Andrzej Adam Filip følgende:
>> perf60@gmail.com wrote:
>> 4) AFAIR some GSM internet providers block incoming TCP connections.
>>
> 4) I do not know Telenor's (Norway) policy.

IMHO most probable scenario.  We don't have here in Poland any ISP
provider who allows it by default.

5) You can use embedded's ssh client to connect back to you while
creating forwarding connection to itself. Look @ `-L' option in man ssh.

[toc] | [prev] | [next] | [standalone]

#2986

perf60@gmail.com wrote:
> kl. 10:09:21 UTC+2 søndag 22. juni 2014 skrev Andrzej Adam Filip følgende:
>> perf60@gmail.com wrote:
>>
>>> I have an embedded linux system on a remote farm. Usually I ssh into
>>> the system via the farms ADSL/WiFi system (using port forwarding). But
>>> sometimes the traffic on the farm blocks me from connecting.
>>
>>> To solve this, I have added a GSM/GPRS modem to the system. The modem
>>> uses the gsmmux giving 3 channels /dev/mux0 thru /dev/mux2. I have a
>>> python daemon watching SMS messages om /dev/mux1. Then I can send an
>>> SMS telling this daemon to set up ppp on /dev/mux0. After the link is
>>> set up, the daemon answer the SMS telling me the IP number of the
>>> alternative link.
>>
>>> Problem is, it does not work to ssh into this IP. Something is obviously missing in my setup - it only works from the system towards the internet.
>>> What must I do to enable ssh to access my system via this alternative connection?
>>
>> 1) Have you changed ListenAddress in /etc/ssh/sshd_config ?
>> 2) Have you implemented source based TCP/IP routing to make _both_ links work
>>    at the same time? [unless your system is for monitoring only]
>> 3) Have you used tcptracerourote to track TCP connections attempts?
>>    [ There may be a firewall in between ]
>> 4) AFAIR some GSM internet providers block incoming TCP connections.
>>    You may try to overcome it by making outgoing ssh connection over GSM link
>>    with -R port forwarding
> 
> Thanks for your answer!
> 
> 1) No, ListenAddress is commented. The default is to listen on all local addresses - so do I need to spesify?

No. Default is listening on all interfaces.

> 2) No, I do not have the knowledge yet. I believe this is a problem. I guess I will have to write scripts in the /etc/ppp/ip-up.d and ip-down.p that should modify routing. My system is only monitoring local devices. Any help is very welcome ;-)

It definitely can be the problem. If in your route table ('route -n')
are two routes to 0.0.0.0/0 and metric for ppp0 default route is higher
you have found it. :)

4) Andrew is right, "-R" option in SSH client. I'm still sleeping.

[toc] | [prev] | [next] | [standalone]

#2987

kl. 11:36:31 UTC+2 søndag 22. juni 2014 skrev ein følgende:
> perf60@gmail.com wrote:
> 
> > kl. 10:09:21 UTC+2 s�ndag 22. juni 2014 skrev Andrzej Adam Filip f�lgende:
> 
> >> perf60@gmail.com wrote:
> 
> >>
> 
> >>> I have an embedded linux system on a remote farm. Usually I ssh into
> 
> >>> the system via the farms ADSL/WiFi system (using port forwarding). But
> 
> >>> sometimes the traffic on the farm blocks me from connecting.
> 
> >>
> 
> >>> To solve this, I have added a GSM/GPRS modem to the system. The modem
> 
> >>> uses the gsmmux giving 3 channels /dev/mux0 thru /dev/mux2. I have a
> 
> >>> python daemon watching SMS messages om /dev/mux1. Then I can send an
> 
> >>> SMS telling this daemon to set up ppp on /dev/mux0. After the link is
> 
> >>> set up, the daemon answer the SMS telling me the IP number of the
> 
> >>> alternative link.
> 
> >>
> 
> >>> Problem is, it does not work to ssh into this IP. Something is obviously missing in my setup - it only works from the system towards the internet.
> 
> >>> What must I do to enable ssh to access my system via this alternative connection?
> 
> >>
> 
> >> 1) Have you changed ListenAddress in /etc/ssh/sshd_config ?
> 
> >> 2) Have you implemented source based TCP/IP routing to make _both_ links work
> 
> >>    at the same time? [unless your system is for monitoring only]
> 
> >> 3) Have you used tcptracerourote to track TCP connections attempts?
> 
> >>    [ There may be a firewall in between ]
> 
> >> 4) AFAIR some GSM internet providers block incoming TCP connections.
> 
> >>    You may try to overcome it by making outgoing ssh connection over GSM link
> 
> >>    with -R port forwarding
> 
> > 
> 
> > Thanks for your answer!
> 
> > 
> 
> > 1) No, ListenAddress is commented. The default is to listen on all local addresses - so do I need to spesify?
> 
> 
> 
> No. Default is listening on all interfaces.
> 
> 
> 
> > 2) No, I do not have the knowledge yet. I believe this is a problem. I guess I will have to write scripts in the /etc/ppp/ip-up.d and ip-down.p that should modify routing. My system is only monitoring local devices. Any help is very welcome ;-)
> 
> 
> 
> It definitely can be the problem. If in your route table ('route -n')
> 
> are two routes to 0.0.0.0/0 and metric for ppp0 default route is higher
> 
> you have found it. :)
> 
> 
> 
> 4) Andrew is right, "-R" option in SSH client. I'm still sleeping.

This in the "normal" table in the remote system:
root@cooly:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

After setting up ppp it looks like this:

root@cooly:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.0.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

What is the simplest way to obtain my goal of using ppp0 to ssh into (or outof . the -R case)? Some scripting required?

[toc] | [prev] | [next] | [standalone]

#2988

perf60@gmail.com a écrit :
> 
> After setting up ppp it looks like this:
> 
> root@cooly:~# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
> 10.0.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
> 192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

1) The peer on ppp0 has a private IP address. If ppp0 has a private IP
address too, then it is not directly reachable from the public internet.

2) The routing table does not have a default route on ppp0. Indeed pppd
ignores the "defaultroute" option if a default route already exists,
unless the "replacedefaultroute" flag (which IIRC is absent from
upstream pppd but implemented by some distributors such as openSUSE or
Debian) is added to it.

[toc] | [prev] | [next] | [standalone]

#2989

Pascal Hambourg wrote:
> 2) The routing table does not have a default route on ppp0. Indeed pppd
> ignores the "defaultroute" option if a default route already exists,
> unless the "replacedefaultroute" flag (which IIRC is absent from
> upstream pppd but implemented by some distributors such as openSUSE or
> Debian) is added to it.

Interesting.

Referring to author's SSH forwarding question:
You need setup pppd to do the following after each connection:
root@cooly:~# ssh root@server -p 22 -R 222:192.168.1.X:22 -v
Where:
-p 22 - is the port number of SSH @ server
X - is IP address of eth0 interface @ cooly
-v - be verbose

ssh root@server -p 22 -R 222:192.168.1.X:22
In big shortcut it means: connect to server at port 22 and forward TCP
traffic from server's 222 port of loopback interface (127.0.0.1) through
SSH connection to cooly's 192.168.1.X:22.

Then you can reach cooly from server like this:
root@server:~# ssh root@127.0.0.1 -p 222

Please use documentation to discover how to provide pppd scripting.
http://www.tldp.org/HOWTO/PPP-HOWTO/ip-up.html

Then add this options to ssh @ cooly
-N      Do not execute a remote command.  This is useful for just
forwarding ports (protocol version 2 only).
-f      Requests ssh to go to background just before command execution.

You should also setup RSA key auth. instead of using passwords, generate
keys longer than or equal to 2048B.
Root account isn't required, but only root can open ports bellow 1024
AFAIR. Use higher port instead when using different account than root.

[toc] | [prev] | [next] | [standalone]

#2990

kl. 13:45:39 UTC+2 søndag 22. juni 2014 skrev ein følgende:
> Pascal Hambourg wrote:
> 
> > 2) The routing table does not have a default route on ppp0. Indeed pppd
> 
> > ignores the "defaultroute" option if a default route already exists,
> 
> > unless the "replacedefaultroute" flag (which IIRC is absent from
> 
> > upstream pppd but implemented by some distributors such as openSUSE or
> 
> > Debian) is added to it.
> 
> 
> 
> Interesting.
> 
> 
> 
> Referring to author's SSH forwarding question:
> 
> You need setup pppd to do the following after each connection:
> 
> root@cooly:~# ssh root@server -p 22 -R 222:192.168.1.X:22 -v
> 
> Where:
> 
> -p 22 - is the port number of SSH @ server
> 
> X - is IP address of eth0 interface @ cooly
> 
> -v - be verbose
> 
> 
> 
> ssh root@server -p 22 -R 222:192.168.1.X:22
> 
> In big shortcut it means: connect to server at port 22 and forward TCP
> 
> traffic from server's 222 port of loopback interface (127.0.0.1) through
> 
> SSH connection to cooly's 192.168.1.X:22.
> 
> 
> 
> Then you can reach cooly from server like this:
> 
> root@server:~# ssh root@127.0.0.1 -p 222
> 
> 
> 
> Please use documentation to discover how to provide pppd scripting.
> 
> http://www.tldp.org/HOWTO/PPP-HOWTO/ip-up.html
> 
> 
> 
> Then add this options to ssh @ cooly
> 
> -N      Do not execute a remote command.  This is useful for just
> 
> forwarding ports (protocol version 2 only).
> 
> -f      Requests ssh to go to background just before command execution.
> 
> 
> 
> You should also setup RSA key auth. instead of using passwords, generate
> 
> keys longer than or equal to 2048B.
> 
> Root account isn't required, but only root can open ports bellow 1024
> 
> AFAIR. Use higher port instead when using different account than root.

Thanks! I have lots to learn, but this looks promising.
I have another ppp configuration which gives me this routing table:

root@cooly:# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.254.254 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0

What would the implications for remote ssh be in this case? Which should I use?

[toc] | [prev] | [next] | [standalone]

#2991

perf60@gmail.com a écrit :
> 
> I have another ppp configuration which gives me this routing table:

What do you mean by "another ppp configuration" ?

> root@cooly:# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
> 192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
> 192.168.254.254 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
> 
> What would the implications for remote ssh be in this case? Which should I use?

Now there is a default route on ppp0, but the remote peer still has a
private address, in a different prefix. What about the local IP address
on ppp0 ?

[toc] | [prev] | [next] | [standalone]

#2993

kl. 14:20:43 UTC+2 søndag 22. juni 2014 skrev Pascal Hambourg følgende:
> perf60@gmail.com a ï¿oecrit :
> 
> > 
> 
> > I have another ppp configuration which gives me this routing table:
> 
> 
> 
> What do you mean by "another ppp configuration" ?
> 
> 
> 
> > root@cooly:# route -n
> 
> > Kernel IP routing table
> 
> > Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 
> > 0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
> 
> > 192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
> 
> > 192.168.254.254 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
> 
> > 
> 
> > What would the implications for remote ssh be in this case? Which should I use?
> 
> 
> 
> Now there is a default route on ppp0, but the remote peer still has a
> 
> private address, in a different prefix. What about the local IP address
> 
> on ppp0 ?


"another ppp configuration": The file named in the pppd call <file> is different - setting up a default route. Cooly has IP address 192.168.1.30

The IP address on ppp0 is given by Telenor during the pppd dialog.

I will try to do what "ein" wrote.

[toc] | [prev] | [next] | [standalone]

#2994

perf60@gmail.com a écrit :
> 
> Cooly has IP address 192.168.1.30

This is the address on eth0. Irrelevant.

> The IP address on ppp0 is given by Telenor during the pppd dialog.

Of course it is. I am asking whether it is a private or public address.
If it is a private adress, you cannot connect to it from the outside.

[toc] | [prev] | [next] | [standalone]

#2995

kl. 15:05:56 UTC+2 søndag 22. juni 2014 skrev Pascal Hambourg følgende:
> perf60@gmail.com a ï¿oecrit :
> 
> > 
> 
> > Cooly has IP address 192.168.1.30
> 
> 
> 
> This is the address on eth0. Irrelevant.
> 
> 
> 
> > The IP address on ppp0 is given by Telenor during the pppd dialog.
> 
> 
> 
> Of course it is. I am asking whether it is a private or public address.
> 
> If it is a private adress, you cannot connect to it from the outside.
From the logged dialog (from pppd) apart from nameservers IP numbers I receive:
local  IP address 37.253.96.136
remote IP address 192.168.254.254
and the remote IP address finds its way into the routing table. 
I assume the 37.253.96.136 address is the external accessible address (local to Telenor)

Trying ssh root@37.253.96.136 from my home does not work.
Pinging google.com form cooly works.

Maybe Telenor do not allow incoming connections.
Maybe the -R approach will work?

[toc] | [prev] | [next] | [standalone]

#2996

perf60@gmail.com a écrit :
>
> From the logged dialog (from pppd) apart from nameservers IP numbers I receive:
> local  IP address 37.253.96.136
> remote IP address 192.168.254.254
> and the remote IP address finds its way into the routing table. 
> I assume the 37.253.96.136 address is the external accessible address (local to Telenor)

Yes. So it is a public address.

> Trying ssh root@37.253.96.136 from my home does not work.
> Pinging google.com form cooly works.

What path does it use ? eth0 or ppp0 ?

> Maybe Telenor do not allow incoming connections.

Maybe.

> Maybe the -R approach will work?

It should. However,

> But sometimes the traffic on the farm blocks me from connecting.

Have you considered correcting this issue ?

[toc] | [prev] | [next] | [standalone]

#2997

kl. 15:47:40 UTC+2 søndag 22. juni 2014 skrev Pascal Hambourg følgende:
> perf60@gmail.com a ï¿oecrit :
> 
> >
> 
> > From the logged dialog (from pppd) apart from nameservers IP numbers I receive:
> 
> > local  IP address 37.253.96.136
> 
> > remote IP address 192.168.254.254
> 
> > and the remote IP address finds its way into the routing table. 
> 
> > I assume the 37.253.96.136 address is the external accessible address (local to Telenor)
> 
> 
> 
> Yes. So it is a public address.
> 
> 
> 
> > Trying ssh root@37.253.96.136 from my home does not work.
> 
> > Pinging google.com form cooly works.
> 
> 
> 
> What path does it use ? eth0 or ppp0 ?

Pinging is on ppp0

> 
> 
> 
> > Maybe Telenor do not allow incoming connections.
> 
> 
> 
> Maybe.
> 
> 
> 
> > Maybe the -R approach will work?
> 
> 
> 
> It should. However,
> 
> 
> 
> > But sometimes the traffic on the farm blocks me from connecting.
> 
> 
> 
> Have you considered correcting this issue ?

Sure! But there are children and foreign guest-workers on the farm, so I have to  find an alternative for my low-bandwidth access.
And there is a football match going on somwhere - i believe there are watchers using IP at the farm ;-)

[toc] | [prev] | [next] | [standalone]

#2992

On 22/06/14 09:34, perf60@gmail.com wrote:
> I have an embedded linux system on a remote farm. Usually I ssh into
> the system via the farms ADSL/WiFi system (using port forwarding).
> But sometimes the traffic on the farm blocks me from connecting.
>
> To solve this, I have added a GSM/GPRS modem to the system. The modem
> uses the gsmmux giving 3 channels /dev/mux0 thru /dev/mux2. I have a
> python daemon watching SMS messages om /dev/mux1. Then I can send an
> SMS telling this daemon to set up ppp on /dev/mux0. After the link is
> set up, the daemon answer the SMS telling me the IP number of the
> alternative link.
>
> Problem is, it does not work to ssh into this IP. Something is
> obviously missing in my setup - it only works from the system towards
> the internet.
>
> What must I do to enable ssh to access my system via this alternative
> connection?
>

Based on other posts here, you have an issue with routing tables once 
ppp0 is up.  However, here are a couple more points:

You might need to re-start the sshd daemon after bringing up ppp0 so 
that it listens on that interface too.

Telenor does not block incoming TCP sessions on GPRS as far as I know - 
though I have only used it for outgoing connections.

Since you are using SMS to initiate the connection, it makes a lot more 
sense for the board to connect to a server than to open a connection 
into the board.  In many cases, if you are on an existing network then 
your board can initiate a connection to an outside server directly.  So 
when it receives the SMS, it should then connect to the server via 
Ethernet or Wifi before trying to fall back to GPRS (which is usually 
slow and expensive).

There are a couple of convenient ways to make this connection and let 
you then get into the system.  Reverse ssh is one that has been 
mentioned.  Another is openvpn - have the SMS trigger opening an openvpn 
tunnel to your server, and then you have a "direct" connection into your 
box (over ethernet, wifi, gprs, whatever).

When you set up your routing tables and pppd scripts, you probably don't 
want to change the default routes.  A better idea could be to add a 
static route that routes connection to your server - but only your 
server - via GPRS.  I don't know what other traffic you have on your 
system, but usually you only want specific and limited traffic over GPRS 
to minimise running costs.

mvh.,

David

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web