Bug 7217 - openvpn breaking switch from wifi to gprs
: openvpn breaking switch from wifi to gprs
Status: NEW
Product: openvpn
General
: 2.1~rc20
: N900 Maemo
: Low major (vote)
: ---
Assigned To: AB
: general
:
:
:
:
  Show dependency tree
 
Reported: 2009-12-22 03:02 UTC by Gregor Schaffrath
Modified: 2014-03-08 10:29 UTC (History)
2 users (show)

See Also:


Attachments
route -n output & cfgs. (2.69 KB, application/zip)
2009-12-22 18:08 UTC, Gregor Schaffrath
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Gregor Schaffrath (reporter) 2009-12-22 03:02:17 UTC
SOFTWARE VERSION:
(Settings > General > About product)

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. connect to wifi network
2. start openvpn (default route via tunnel)
3. switch to gprs

EXPECTED OUTCOME:
either openvpn should die and leave the gprs route alone, or it should
reconnect via the gprs connection

ACTUAL OUTCOME:
udhcpc stops ; the gprs default route comes up ; the dying openvpn eliminates
the gprs default route ; the gprs default route is (at least not immediately)
not reinstated, and the device is left without net connection, until the user
'disconnects' and 'reconnects'

REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
always

EXTRA SOFTWARE INSTALLED:
none relevant ;)

OTHER COMMENTS:
workaround: killall -9 openvpn upon udhcpc deconfig trigger... but that's a
dirty hack ;)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.6)
Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.0.8, Ant.com Toolbar 1.3
Comment 1 Mikko Vartiainen 2009-12-22 14:15:33 UTC
(In reply to comment #0)
> (default route via tunnel)

is this done with redirect-gateway?
Comment 2 Gregor Schaffrath (reporter) 2009-12-22 17:17:26 UTC
yes, it is.
Comment 3 Mikko Vartiainen 2009-12-22 17:35:37 UTC
actually it's essential to see the whole openvpn config, because I can
reproduce this just by connecting/disconnecting openvpn too.
Comment 4 Mikko Vartiainen 2009-12-22 17:44:25 UTC
Could you show the routing tables in all steps you described?
Comment 5 Gregor Schaffrath (reporter) 2009-12-22 18:08:56 UTC
Created an attachment (id=1826) [details]
route -n output & cfgs.

here you go :)
Comment 6 AB 2010-01-03 20:50:16 UTC
Bug #7215 & bug #7217 & bug #7596 are apparently related to the
"redirect-gateway" keyword not working as expected in the case of a cellular
connection, because the corresponding route does not have the G flag.

This seems to be an issue with upstream as well:
http://openvpn.net/archive/openvpn-users/2007-12/msg00029.html
Comment 7 AB 2010-01-06 21:46:02 UTC
(In reply to comment #0)

> OTHER COMMENTS:
> workaround: killall -9 openvpn upon udhcpc deconfig trigger... but that's a
> dirty hack ;)

Thanks for the report(s). Another workaround, as suggested in upstream's
README.Debian, requires adding the "openvpn <vpnname>" option to
/etc/network/interfaces, which does not include wlan0 on Maemo. That might be
tricky considering that there might be multiple VPNs configured in the system.
Comment 8 Gregor Schaffrath (reporter) 2010-01-07 15:06:34 UTC
hm - after getting openvpn to run on cellular connections, I tried a switch
from gprs to wifi with a confusing result:

1) gprs interface went down (OK)
2) wifi went up (including one LAN route and one new default route) (OK)
3) openvpn died and killed the new wifi default route along with it's own
deprecated routes (but left the new LAN route alone)

I certainly did not expect this behaviour...