Bug 7215 (int-116548)

Summary: udhcpc overriding default routes
Product: [Maemo Official Platform] Connectivity Reporter: Gregor Schaffrath <grsch-maemo>
Component: ICDAssignee: unassigned <nobody>
Status: VERIFIED FIXED QA Contact: icd-bugs
Severity: major    
Priority: Low CC: andrea, andre_klapper, patrik.flykt
Version: 5.0/(1.2009.42-11)   
Target Milestone: 5.0/(2.2009.51-1)   
Hardware: N900   
OS: Maemo   

Description Gregor Schaffrath (reporter) 2009-12-22 02:53:55 UTC
(Settings > General > About product)

(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

udhcpc should not override the default route in this case

it does override the default route

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

none relevant ;)

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 @@
         for i in $router
+          #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

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:
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:
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
(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
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
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
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
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. :)