Re: Couple of minor issues with 0.7

[Dan Williams <dcbw redhat com>]

On Sun, 2008-07-20 at 14:50 -0400, Darren Albers wrote:
> 0.7 has been working great for me, I upgraded to the latest SVN
> snapshot (As of Sunday Jul 20th at 1:30pm EST) and most items seem to
> work except for VPN.   Are the VPN plugins broken right now?

Hmm, they shouldn't be.  I've been using vpnc and pptp for the past few
days OK.

> Here are the messages dumped to the console when I run nm-applet:
> ** (nm-applet:9585): WARNING **: Could not retrieve dbus connections:
> Launch helper exited with unknown return code 1.
> 
> ** (nm-applet:7218): WARNING **: Active connection
> /org/freedesktop/NetworkManager/ActiveConnection/1 had no devices!
> 
> ** (nm-applet:7218): WARNING **: Active connection
> /org/freedesktop/NetworkManager/ActiveConnection/1 had no devices!

Yeah, these are weird and I'm not quite sure whether they are harmless
or a problem yet.  Need to look into that.

> ** (nm-applet:7218): WARNING **: Active connection
> /org/freedesktop/NetworkManager/ActiveConnection/1 had no devices!
> 
> ** (nm-applet:7218): WARNING **: Active connection
> /org/freedesktop/NetworkManager/ActiveConnection/1 had no devices!
> 
> ** (nm-applet:7218): WARNING **: Active connection
> /org/freedesktop/NetworkManager/ActiveConnection/1 had no devices!
> 
> ** (nm-applet:7218): WARNING **: Active connection
> /org/freedesktop/NetworkManager/ActiveConnection/1 had no devices!
> 
> ** (nm-applet:7218): WARNING **: Property 'state' unhandled.

Need to quiet this; I moved the state change handing from property
notifications to actual signals (so we can get the reason code for the
state change so we can report failures better), and the code complains
when there's an unhandled property.  Should be harmless.

> ** (nm-applet:7218): WARNING **: Property 'state' unhandled.
> 
> ** (nm-applet:7218): WARNING **: Property 'state' unhandled.
> 
> ** (nm-applet:7218): WARNING **: Property 'state' unhandled.
> 
> ** (nm-applet:7218): WARNING **: Property 'state' unhandled.
> 
> ** (nm-applet:7218): WARNING **: Property 'state' unhandled.
> 
> ** (nm-applet:7218): WARNING **: Property 'state' unhandled.
> 
> ** (nm-applet:7218): WARNING **: Property 'state' unhandled.
> 
> ** (nm-applet:7218): WARNING **: Property 'state' unhandled.
> 
> ** (nm-applet:7218): WARNING **: Property 'dhcp4-config' change
> detected but couldn't be found on the object.

I need to write the libnm-glib proxy bits for the dhcp4-config stuff
still, but the error should be harmless at the moment.

> Jul 20 14:46:20 dpalap NetworkManager: <info>  Trying to start the
> system settings daemon...
> 
> When I edit any VPN settings I get:
> ** (nm-connection-editor:9275): WARNING **: Invalid setting VPN: key
> /bin/sh: /bin/awk: not found

So this is really weird and a bug.  What VPN plugin are you using?  This
comes from the UI validation code in the connection editor and could
indicate a bug in the VPN plugin.

> If it matters I do have awk installed, but in /usr/bin so I created a
> symlink and now I can connect but no routes are pushed.
> 
> A few other minor issues:
> 
> 1)  I think this has been mentioned before but now that there is the
> ability to do multiple interfaces not having the ability to disable a
> connected but not used wired interface is a bit of a problem.   In my
> case I use a 3G card frequently when also connected to a wired
> network, it can be a hassle to have to unplug the cable from the
> docking station rather than an option to disable wired.
> 
> 2)  Recent SVN snapshots prompt me for a password for my card but it
> doesn't actually require one.   Maybe a box that says "My Provider
> does not require one" and if you check that box something random is
> sent.   While I know that I can enter anything there, it is likely
> that a less technical user will not realize that.

Yeah, I thought I'd nailed that one but the code would work better with
an explicit "doesn't require authentication" checkbox.  However, if we
can fix the current behavior without an additional checkbox, that would
be better.  If that's not possible (and the current code is a bit ugly)
then a checkbox like you suggest would be the next best solution.  Does
your provider require a username but not a password?  Or do you not need
any auth credentials?

Dan