Connman forgets gateway IP address upon reboot and/or waking from sleep

[Lee Hyde]

It appears that a recent update to *connman* has resulted in the former inability to remember the gateway IP address of a saved wireless network. It appears that *connman* is able to remember all of the other fields, except the gateway address which presents as blank upon reboot or upon waking from sleep/suspension.

Installed Versions:
*Ubuntu*: 10.10 (x86-64)
*indicator-network*: 0.3.2-0ubuntu1+r128+201101101920
*connman*: 0.64-0ubuntu1+ind4+r3135+201101190339
*connman-gnome*: 0.5-0ubuntu1

[Kalle Valo (kvalo)]

Lee Hyde <email address hidden> writes:

> It appears that a recent update to *connman* has resulted in the former
> inability to remember the gateway IP address of a saved wireless
> network. It appears that *connman* is able to remember all of the other
> fields, except the gateway address which presents as blank upon reboot
> or upon waking from sleep/suspension.

Thank you for the bug report. I have some extra questions:

1. Are you using DHCP (ie. the default setting) or manual IPs?

2. Do you see this only with one network or with all networks you have
   access to? (Wondering if this is a problem with a specific DHCP
   server or a more general problem.)

3. I assume that you are using only IPv4, please correct me if that's
   not the case.

4. I see that you are using daily builds. Good, makes it easier to find
   the culprit. With what version did you see the problem first? Even a
   rough guess would help.

--
Kalle Valo

[Lee Hyde (anubeon)]

Greetings *Kalle*

Thank you for taking the time to respond to this bug report! In answer to your follow-up questions:

1. I am *not* using DHCP (it is disabled on my router), I have manually set all IP addresses.

2. I'm afraid I only have access to one wireless network at the present time, so I can not provide any further information here.

3. Yes, I am only using IPv4. (Does connman even support IPv6 yet?)

4. I can't really say for sure, but I would estimate that the issue reared its head approximately 1-2 weeks ago (~10th Jan. 2010). I wish I had taken notes when I first noticed the issue, but alas I am a fool!

I hope that is of some assistance too your good self (although I doubt it). If there's anything else I can do, please do let me know.

Kind Regards,

Lee Hyde.

[Kalle Valo (kvalo)]

Lee Hyde <email address hidden> writes:

> Greetings *Kalle*

Hi Lee,

> 1. I am *not* using DHCP (it is disabled on my router), I have manually
> set all IP addresses.

Ah, this is the key. I use dhcp myself and that's why I had missed this.

This can be reproduced at least like this:

1. configure a wired connection to use manual ip
2. suspend
3. resume
4. connmand now crashes
5. restart connmand (normally happens automatically)
6. the wired connection doesn't have gateway anymore

I was able to reproduce with current upstream git and I'll report this
forward to the connman project.

The stacktrace:

#0 0x000000000079e5bb in ?? ()
#1 0x000000000041cfba in method_call_reply (call=0x6f0a00,
    user_data=<value optimized out>) at gsupplicant/dbus.c:386
#2 0x00007ffff78c553a in complete_pending_call_and_unlock (
    connection=0x674620, pending=0x6f0a00, message=<value optimized out>)
    at dbus-connection.c:2311
#3 0x00007ffff78c81af in dbus_connection_dispatch (connection=0x674620)
    at dbus-connection.c:4596
#4 0x000000000040cd08 in message_dispatch (data=<value optimized out>)
    at gdbus/mainloop.c:80
#5 0x00007ffff7b3ab1b in g_timeout_dispatch (source=0x754200,
    callback=0x7fffffffe1d0, user_data=0x7ffff6e69298)
    at /build/buildd/glib2.0-2.26.0/glib/gmain.c:3585
#6 0x00007ffff7b3a342 in g_main_dispatch (context=0x673120)
    at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2149
#7 g_main_context_dispatch (context=0x673120)
    at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2702
#8 0x00007ffff7b3e2a8 in g_main_context_iterate (context=0x673120,
    block=<value optimized out>, dispatch=<value optimized out>,
    self=<value optimized out>)
    at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2780
#9 0x00007ffff7b3e7b5 in g_main_loop_run (loop=0x6722e0)
    at /build/buildd/glib2.0-2.26.0/glib/gmain.c:2988

ipv4 configuration in step 6:

  IPv4 = { Netmask=255.255.255.0 Method=manual Address=192.168.1.232 }
  IPv4.Configuration = { Netmask=255.255.255.0 Method=manual Address=192.168.1.232 }

> (Does connman even support IPv6 yet?)

It does, but the support in indicator-network is not yet implemented. It
will be implemented soon.

See bug #686354 and bug #686356 for more.

> 4. I can't really say for sure, but I would estimate that the issue
> reared its head approximately 1-2 weeks ago (~10th Jan. 2010). I wish I
> had taken notes when I first noticed the issue, but alas I am a fool!

That's good to know. In case we need to start bisecting the patch which
broke this it's good to know when this started happening. Saves our time :)

> I hope that is of some assistance too your good self (although I doubt
> it). If there's anything else I can do, please do let me know.

This is more than enough and we can start working on the bug now.

Lee, thank you very much for reporting the issue.

--
Kalle Valo

[Kalle Valo (kvalo)]

Filed bug upstream:

http://bugs.meego.com/show_bug.cgi?id=12795

[Lee Hyde (anubeon)]

I'm not sure if this is pertinent at all, but more recently (~1 week) *connman* has been forgetting my gateway address mid-session. Furthermore, whilst this typically entails the replacement of my gateway address with a blank field it occasionally entails its replacement with a random string such as 'SSID' or '0' (etc...). I assume that these strings (of which there are more I cannot recall) are being pulled from my router in some fashion.

[Lee Hyde (anubeon)]

I'm attempting to write a simple script (to be run in chron) to temporarily rectify the issue via *cmcc* but I need a trigger, a command with a simple output (i.e. true|false) indicating the state of internet connectivity.

Neither *cmcc state* nor *ping* will do, as their outputs are large. Is there any way I could truncate the output, or use only the first /n/ lines as triggers? Forgive me, I'm a complete layman when it comes to these sorts of things.

If I get a working script, I'll post it here (and upstream) should anyone wish to avail of it until this bug is fixed.

Kind Regards,

Lee.

[Lee Hyde (anubeon)]

Okay, I created a simple script to be run at regular intervals via *cron*. It simply pings Googles name server (8.8.8.8) five times and if the result is 100% packet loss uses *connman's* built in CLI (*cmcc*) to reconnect your chosen wireless network service.

On the off chance anyone else is effected by this bug (I'm sure most use DHCP) please feel free to download the attached script, edit to variables defined at the top of the script ($SSID, $address, $netmask, $gateway, $DNS, etc.) to suit your network set-up and set to run at a regular intervals (~5-10 min) with cron/scheduler.

[Kalle Valo (kvalo)]

I cannot reproduce the bug anymore even though I was able to reproduce this earlier. I tried both ubuntu daily builds (as of yesterday) and current connman git. The test was to suspend and resume five times with a network using manual ipv4 settings. No crashes and gateway was set correctly every time after resume.

Maybe this is fixed in connman now? Lee, do you still see this?

[Lee Hyde (anubeon)]

This issue was fixed for me a while back, so I'm going to go ahead and mark this as fixed.