First Last Prev Next    No search results available
Bug 7215 - (int-116548) udhcpc overriding default routes
(int-116548)
: udhcpc overriding default routes
Status: VERIFIED FIXED
Product: Connectivity
ICD
: 5.0/(1.2009.42-11)
: N900 Maemo
: Low major (vote)
: 5.0/(2.2009.51-1)
Assigned To: unassigned
: icd-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-12-22 02:53 UTC by Gregor Schaffrath
Modified: 2010-01-22 18:40 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)


Note

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

Description Gregor Schaffrath (reporter) 2009-12-22 02:53:55 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 a wifi network (best with short lease time ;) ) 
2. define and start openvpn tunnel using peer as default gw 
3. wait until udhcpc updates network configuration and resets default route to
the wifi next hop

EXPECTED OUTCOME:
udhcpc should not override the default route in this case

ACTUAL OUTCOME:
it does override the default route

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


EXTRA SOFTWARE INSTALLED:
none relevant ;)

OTHER COMMENTS:
I'd rather put this bug under udhcpc - but I did not find a matching category -
maybe you can remap it to the appropriate place

a workaround is adding the following lines to the udhcpc script:

--- libicd_network_ipv4.script.orig    2009-12-22 01:31:37.000000000 +0100
+++ libicd_network_ipv4.script    2009-12-22 01:35:39.000000000 +0100
@@ -25,6 +25,8 @@
         succeeded=no
         for i in $router
         do
+          #if someone uses this route to create a tunnel to another default
gw, don't mess it up by reconfiguring the default route
+           hoproute=`route -n | grep $i` ; defroute=`route | grep default` ;
if [ -z "$hoproute" -o -z "$defroute" ]; then 
           echo /sbin/route add default gw $i dev $interface >> $LOG
             /sbin/route add default gw $i dev $interface
           fi

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 AB 2009-12-26 03:21:57 UTC 
Andre, could you move this bug to the ICD component?
Comment 2 Andre Klapper maemo.org 2009-12-31 18:43:33 UTC 
And by the way: Thanks for reporting this. :)
Comment 3 AB 2010-01-03 20:51:24 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 4 Gregor Schaffrath (reporter) 2010-01-04 17:35:49 UTC 
this one is not related to cellular, but wifi connections.

Andre: very much welcome. ;)
Comment 5 AB 2010-01-04 20:59:21 UTC 
(In reply to comment #4)

> this one is not related to cellular, but wifi connections.

I know, but my idea is that all three bugs are related to the missing G flag in
the default route. If you have time (atm I don't :-( ) try and see if it makes
any difference for this bug without your patch.
Comment 6 Gregor Schaffrath (reporter) 2010-01-04 21:59:19 UTC 
Hm - I don't fully get it... in this bug report, I'm referring to a wifi
connection (default route has the G flag set) and an openvpn connection
(default route relevant routes have the G flag set) - hence there's no G flag
to set...
or would you like me to remove the G flag and see whether the behaviour is the
same as with the gprs0 interface?

In this bug, it's merely the udhcpc ignoring the default route and replacing
it, even though it's not supposed to.
Comment 7 AB 2010-01-06 20:52:58 UTC 
(In reply to comment #6)

> In this bug, it's merely the udhcpc ignoring the default route and replacing
> it, even though it's not supposed to.

You're right, sorry for polluting this report.
Comment 8 Patrik Flykt nokia 2010-01-07 11:26:53 UTC 
(In reply to comment #6)

> In this bug, it's merely the udhcpc ignoring the default route and replacing
> it, even though it's not supposed to.

The udhcpc script has been fixed with respect to the default route handling. It
is to be expected in an upcoming update.
Comment 9 Andre Klapper maemo.org 2010-01-07 14:30:36 UTC 
This has been fixed in package
libicd-network-ipv4 0.22+0m5
which is part of the internal build version
2.2009.45-12
(Note: 2009 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 10 Andre Klapper maemo.org 2010-01-14 12:28:20 UTC 
The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.
Comment 11 Gregor Schaffrath (reporter) 2010-01-14 12:42:43 UTC 
Thx for the notification - I'll test it over the next week :)
But as far as I can see, it's my applied patch, which worked for me before - so
I don't expect it not to work because somebody else inserted it ;)
Cheers, Gregor.
Comment 12 Gregor Schaffrath (reporter) 2010-01-21 21:35:01 UTC 
hm - I was mistaken about the patch application, it seems, as I just saw that
it was my old script I saw... hence I guess that I do not have the newest
version (even though there was an update in the application manager)

I see that the new image requires me to flash the entire root partition - so I
have to do a backup first - not sure when I'm going to get around to this (I'll
try in the next couple of days, but can't promise, as I'm currently in deadline
stress ;) )

But a colleague of mine has the newest version on his n900 and tells me he's
experiencing a similiar problem... I've pointed him to this bug report and
asked him to check out, whether the problem's gone or whether it's the same
thing. :)

Cheers, Gregor.
Comment 13 Gregor Schaffrath (reporter) 2010-01-22 18:40:58 UTC 
Hi.
Upgraded and tested today... seems to work fine to this respect.
The problem of my colleague seems to relate to my other openvpn bug report.
Marking verified - thx for the fix. :)
First Last Prev Next    No search results available