Re: Current SVN broken?
On Tue, 2007-02-20 at 20:45 +1300, Simon Geard wrote: On Mon, 2007-02-19 at 14:54 +0200, Tambet Ingo wrote: On Mon, 2007-02-19 at 21:03 +1300, Simon Geard wrote: Ok, I've given this a couple of weeks for recent changes to settle, but still finding trunk (rev 2337) completely unstable. It takes about 10 seconds to start up, going through the business of reconnecting to the system bus before aborting with the stacktrace. Don't use the SVN head. We know it's completely unstable. We'll let you know when it's usable again. Ok, I'll do that. Do you have any rough idea how long that might take - I don't mean dates, just whether it's days, weeks, or at worst, months. Hopefully days... though I was able to get it to associate with unencrypted yesterday OK. It should at least start up, find your devices, and if you have an instance of the applet (or another info-daemon) running, it should connect if it can see that network. What version of wpa_supplicant are you running? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
settings daemon D-Bus interface proposal
Proposal:
The system settings service (what we were calling NMI) will run either
as 'nobody' or 'root' (I'm not sure yet, thoughts?). Something will
have to start it, either NM or the startup scripts. It provides the
default/mandatory settings that users have published system-wide or that
the sysadmin has set. I'm somewhat afraid that if we run it as 'nobody'
that we'll not be able to trust the information we get out of it because
it's not root.
If we run the system settings service as 'root', then it can access the
system-wide published secrets and then NM doesn't have to contain code
to read the secrets in some lookaside directory. If it's run as
'nobody' then NM would have to store them. Your thoughts David?
This Gnome system settings daemon will be a copy of nm-applet and will
be run with the '--system' argument, which tells the applet to present
_no_ UI, not init GTK, and acquire the system settings service name
rather than the user-level settings service name.
We can use the same D-Bus interfaces between the normal user-level
settings service (i.e., nm-applet) and the system settings service,
since the data they are passing is actually the same format.
Service: org.freedesktop.NetworkManager.Settings.System
Path:/org/freedesktop/NetworkManager/Settings/System
And for the user-level settings service run from the login session:
Service: org.freedesktop.NetworkManager.Settings.User
Path:/org/freedesktop/NetworkManager/Settings/User
One problem is that .Settings overlaps with the 'settings' object
described below, but using .Config or .Preferences just doesn't
sound right. I think .Settings is probably best. Thoughts?
m = method, s = signal
Base Object
-
interface: org.freedesktop.NetworkManager.Settings
m ListConnections(out connections 'ao')
- Returns the object paths of known connections
s NewConnection(out connections 'o')
- Signals that a new connection object has been created
Connection Object
-
interface: org.freedesktop.NetworkManager.Settings.Connection
path: /org/freedesktop/NetworkManager/Settings/Connection/id
(path can be arbitrarily defined by the settings daemon)
m GetID(out id 's')
- returns the connection id. If NM doesn't store the secrets
then we won't need this, but if NM does store the secrets,
NM will need some unique identifier for each connection that
it can use to find the secrets on the filesystem
m GetSettings(out settings 'a{sa{sv}}')
- returns a dict of settings dictionaries in the format
sort of described here:
http://live.gnome.org/NetworkManagerConfiguration
Note that the Conceptual Diagram shown there is not how
the data will actually be represented in the dict of dicts.
Each settings object will have a well-known name which
is used as its key in the outer dict, and the key names and
value types of each member of the settings object will also
be well-known. We will spec these well-known things out.
m GetSecret(in setting-name 's', out secret 'ay')
- NM calls this method to request the secret for a specific
settings dict from the settings daemon (either system or user)
Replaces getKeyForNetwork(). Different settings objects may
require different secrets, so we need the ability to request
settings from each secret individually as necessary.
s Updated(settings 'a{sa{sv}}')
- Signals that the connection object's settings have changed,
and passes the entire dict of settings dicts. It is NM's
responsibility to determine what's changed and take appropriate
action as necessary.
s Removed()
- Signals that the connection object has been deleted by the
settings daemon and that it is no longer valid. NM should
dispose of the connection object and associated memory
and no longer call any method of it. NM may also need to
disconnect if this connection is currently in-use.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: OpenVPN gui change
On Sat, 2007-02-17 at 20:16 -0500, Jon Nettleton wrote: On Fri, 2007-02-16 at 15:33 -0500, Jon Nettleton wrote: On Fri, 2007-02-16 at 14:03 -0500, Dan Williams wrote: On Thu, 2007-02-15 at 21:28 -0500, Jon Nettleton wrote: I finally had a need to get OpenVPN running at home and figured I would just use the NetworkManager-openvpn from Fedora Extras. Well it worked, but the config gui was a little painful on my 1024x768 sub noteboook. I took a half an hour and created this patch that moves the optional information to another tab. Yes I know having tabs in tabs is bad, but I don't have time to redesign the entire gui right now. I also enabled the port option that was in the code, but didn't have a gui configuration entry ( I needed that functionality also.). I probably should have used the rport option, but again I don't have tons of time to spend on this. Here is the patch against 0.3.2 http://www.hekanetworks.com/~jnettlet/NetworkManager/NetworkManager-openvpn-port-ui.patch For Fedora People running Core 6 here is an rpm. Note I also moved the launcher from Internet to System Tools. http://www.hekanetworks.com/~jnettlet/NetworkManager/NetworkManager-openvpn-0.3.3-2.fc6.i386.rpm Hope this helps someone else out. Damn that's ugly :) You are right and it is bothering me now. How is this? http://www.hekanetworks.com/~jnettlet/NetworkManager/openvpnconfig.png Turn all the verbosity into Tooltips Moving Optional to its own tab gives enough room so you can fit all the X.509 and Password Dialogues on 1 page getting rid of the need for tabs down there. Fixup the general padding and alignment. If there are no objections I will finish the code to make this work, shouldn't take long. Jon But committed to stable branch because not much can possibly be worse than the dialog we have now. Also with davidz's patch. And just a note, we shouldn't be including the invisible_char thing in glade files since GTK does that automatically for us now. Glade still sticks it into glade files though, so we get to manually remove it for now. dan For those interested I have submitted my final gui patches to bugzilla. I finished my openvpn patch and then realized that the vpnc dialog was designed the same way as openvpn was. My OCD kicked in and had to create a patch to make the vpnc interface consistent. OpenVPN: http://bugzilla.gnome.org/show_bug.cgi?id=334800 VPNC: http://bugzilla.gnome.org/show_bug.cgi?id=408819 Any comments or suggestions would be appreciated. So I committed these; I'm not wild about the tab thing either, since if it's required info it should just be there and not in a tab. I think the best solution is to have an optional button or a second step in the wizard, but its clear that OpenVPN needs some way of being able to set many of the 5,000,000 options from the dialog. So what you've done is quite a bit better that what's there, and I've committed the vpnc stuff to trunk and stable, but the openvpn stuff doesn't apply to trunk. Can you take a look at it and file a new bug for that? Thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: settings daemon D-Bus interface proposal
On Tue, 2007-02-20 at 08:49 -0500, Dan Williams wrote: The system settings service (what we were calling NMI) will run either as 'nobody' or 'root' (I'm not sure yet, thoughts?). Something will have to start it, either NM or the startup scripts. It provides the default/mandatory settings that users have published system-wide or that the sysadmin has set. I'm somewhat afraid that if we run it as 'nobody' that we'll not be able to trust the information we get out of it because it's not root. If we run the system settings service as 'root', then it can access the system-wide published secrets and then NM doesn't have to contain code to read the secrets in some lookaside directory. If it's run as 'nobody' then NM would have to store them. Your thoughts David? It would be very nice if it weren't root. If nobody isn't trusted enough, maybe some other dedicated user, something that could be shared with hal policy daemon etc (which I know nothing about). Would make a lot of security-(paranoid-)people happy. This Gnome system settings daemon will be a copy of nm-applet and will be run with the '--system' argument, which tells the applet to present _no_ UI, not init GTK, and acquire the system settings service name rather than the user-level settings service name. Why do we want to do this? Because of the GConf dependency? In my opinion the settings daemon belongs much more to the core NM than NM-gnome, there's no desktop specific bits in it at all (it doesn't even have any UI or regular user who'd ever log in). I'd suggest using a simple GKeyFile-based configuration mechanism for the daemon for now. There are a lot of people interested in moving GConf down the stack, either below glib or maybe into glib, so it will happen sooner or later. Does this new settings code mean that most of the backends (more precisely, the information reading from /etc/sysconfig part) is now deprecated? If no, which information does the NM prefer, the new daemon or the distro specific? The API itself looks good to me. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: My wireless card activity could notberecognizedbyNetworkManager
On Tue, 2007-02-20 at 10:10 -0800, Jihua Cheng wrote:
Dan,
Could you tell me
1) How to find the HAL's version?
2) How to know if HAL detects my driver?
If you're on an rpm-based distribution:
rpm -qv hal
If hal detects your driver, it will show something like the following
for your wireless network device when you run 'lshal':
udi = '/org/freedesktop/Hal/devices/net_00_16_xx_xx_xx_xx'
info.udi = '/org/freedesktop/Hal/devices/net_00_16_xx_xx_xx_xx' (string)
linux.subsystem = 'net' (string)
linux.hotplug_type = 2 (0x2) (int)
net.80211.mac_address = xx (0x16) (uint64)
info.product = 'WLAN Interface' (string)
net.arp_proto_hw_id = 1 (0x1) (int)
net.linux.ifindex = 3 (0x3) (int)
net.address = '00:16:xx:xx:xx:xx' (string)
net.interface = 'eth0' (string)
net.physical_device = '/org/freedesktop/Hal/devices/pci_8086_4220' (string)
info.capabilities = {'net', 'net.80211'} (string list)
info.category = 'net.80211' (string)
info.parent = '/org/freedesktop/Hal/devices/pci_8086_4220' (string)
linux.sysfs_path = '/sys/class/net/eth0' (string)
Dan
Thanks a lot!
Jihua
-Original Message-
From: Dan Williams [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 17, 2007 5:58 AM
To: Jihua Cheng
Cc: networkmanager-list@gnome.org
Subject: RE: My wireless card activity could
notberecognizedbyNetworkManager
On Fri, 2007-02-16 at 12:28 -0800, Jihua Cheng wrote:
Dan,
I added the SET_NETDEV_DEV. Network Manager still does not detect my
wireless card.
I noticed that when I right click mouse on NetworkManager icon, only
Gray Wired Network showed up. I disconnect Ethernet connection.
Should
Network manager show Wireless Network? Could some parameter setting
is
not properly setup for NetworkManager?
This is really an issue between the driver and HAL. If you get it to
show up in HAL, then it will show up in NetworkManager (and then we can
see if your driver does WEXT right :). In any case, what version of HAL
do you have? Then we can track down exactly how HAL is looking for
wireless.
Dan
Thanks!
Jihua
-Original Message-
From: Dan Williams [mailto:[EMAIL PROTECTED]
Sent: Friday, February 16, 2007 11:45 AM
To: Jihua Cheng
Cc: networkmanager-list@gnome.org
Subject: RE: My wireless card activity could
notberecognizedbyNetworkManager
On Fri, 2007-02-16 at 11:25 -0800, Jihua Cheng wrote:
Dan,
Thanks a lot.
Please find the answer bellow.
- Do you call SET_NETDEV_DEV in your driver?
My driver does not call SET_NETDEV_DEV.
Do this then, that is definitely required for 2.6 drivers. It won't
break hard if you don't have it, but you need it. It makes a link
between your hardware device and the class device in sysfs and allows
HAL to determine the parent/child relationship.
Dan
- Does it show up in /proc/net/wireless?
Yes. cat /proc/net/wireless shows
Inter-| sta-| Quality| Discarded packets |
Missed | WE
face | tus | link level noise | nwid crypt frag retry misc |
beacon | 20
eth1: 00010 0 1600 0 6128224 27 86
0
- What is the contents of /sys/class/net/ethX ? (where ethX should
be
replaced with the interface name of the wireless device that is
created
when you load your driver)
ls /sys/class/net/eth1 shows
address
addr_len
broadcast
carrier
dormant
features
flags
ifindex
iflink
link_mode
mtu
operstate
statistics
subsystem
tx_queue_len
type
uevent
weight
wireles
- What is the contents of /sys/class/net/ethX/wireless? (same as
above,
replace ethX as appropriate)
ls /sys/class/net/eth1/wireless shows
beacon
crypt
fragment
level
link
misc
noise
nwid
retries
status
- Do you implement the get_wireless_stats function in your
iw_handler_def structure? That's what actually allows the system to
create the /sys/class/net/ethX/wireless directory for you.
get_wireless_stats is implemented.
Regards,
Charles
-Original Message-
From: Dan Williams [mailto:[EMAIL PROTECTED]
Sent: Friday, February 16, 2007 10:47 AM
To: Jihua Cheng
Cc: networkmanager-list@gnome.org
Subject: RE: My wireless card activity could not
berecognizedbyNetworkManager
On Fri, 2007-02-16 at 10:26 -0800, Jihua Cheng wrote:
/ Dan,
Thanks a lot!
The card model is SD wireless card, attached into PCI card. PCI
card
provides the bridge.
I wrote this driver. I can insmod my driver and it works well with
wireless tools(iwconfig, iwlist, etc) and network command ( for
example,
ping). I could find my driver loaded properly, by using lsmod.
You mentioned HAL doesn't appear to know about any wireless
interfaces. How can I make HAL know my wireless
Re: settings daemon D-Bus interface proposal
Hi, So I have one beef with this proposal and that is that it builds upon the same idea of a NetworkManagerInfo-ish service. As you might know, one of the features we're doing for Fedora 7 is fast user switching; it's basically done with what we have in Rawhide. There's one slight problem with NetworkManager though - consider this screenshot where Tom Ripley is a user I just created http://people.freedesktop.org/~david/nm-with-fus.png In the background (on another VT) I have my normal desktop running as user davidz and since this one was the first to start, the nm-applet instance running for davidz gets to tell the system-wide NetworkManager daemon what connections to use. This is somewhat broken (but still probably good enough for Fedora 7). So wouldn't it be a lot nicer to do this the traditional way where only NetworkManager is the server / mechanism (doesn't specify any policy whatsoever) and each client doesn't need to own any services? Notably, you wouldn't need NM to keep state like these are the VPN connections I can connect to (or keep these for N users all logged in at the same time); that would solely be in the client. For things like secrets NM would emit signals whenever it need more secrets when doing a transaction on behalf of a client. So it would look like this client (e.g. nm-applet) server (NetworkManager) Decides to connect to a network -- method: TransactionBegin (details) -- -- return: transaction id, transaction cookie -- does stuff; ugh need some secret. Looks up in system-wide secret store (/var/blah); if there continues; otherwise: -- signal: NeedInfo(id, details) - Looks up gconf for stuff; asks user -- method: ProvideInfo (id, cookie, details) -- --- return: void --- -- signal: TransactionComplete(id, success) - and so forth. NetworkManager would still maintain state such as what interfaces are available, what state they are in and so forth. But it wouldn't know *anything* about user settings such as what VPN connections some user have or how he wants to obtain IP adresses. It would be a pure mechanism. All the logic would be in the client (aka policy manager, e.g. nm-applet and friends). On Tue, 2007-02-20 at 08:49 -0500, Dan Williams wrote: Proposal: The system settings service (what we were calling NMI) will run either as 'nobody' or 'root' (I'm not sure yet, thoughts?). Something will have to start it, either NM or the startup scripts. It provides the default/mandatory settings that users have published system-wide or that the sysadmin has set. I'm somewhat afraid that if we run it as 'nobody' that we'll not be able to trust the information we get out of it because it's not root. If we run the system settings service as 'root', then it can access the system-wide published secrets and then NM doesn't have to contain code to read the secrets in some lookaside directory. If it's run as 'nobody' then NM would have to store them. Your thoughts David? I think NM should consult system-wide secrets somewhere in, say, /var/lib/NetworkManager/secrets.d. These would be in a textual format so it's easy for administrators to create RPM's or whatever for distribution of e.g. corporate WEP/WAP keys or whatever. In particular I don't see why it's useful to have this come from the daemon since at least nm-applet will use gnome-keyring (or some other store for secrets) exclusively to get these and this, by definition, requires user interaction e.g. someone needs to unlock the keyring and that will require human intervention e.g. password entry. This Gnome system settings daemon will be a copy of nm-applet and will be run with the '--system' argument, which tells the applet to present _no_ UI, not init GTK, and acquire the system settings service name rather than the user-level settings service name. Right, I think recycling the policy manager is a good idea as we do need some policy manager running when no-one is logged in / server use. Note that with ConsoleKit, NM can now identify the seat, session, session_is_active [1] a call from a client originates from. Hence, doing this is easy. When no-one is logged in we accept input from the system policy manager; when there are sessions logged in NM can reject method calls from policy managers in inactive sessions. So all in all I think that NM needs this architectural change to cope with f-u-s and other things. It might be a bit more work but I think a much clearer separation between *mechanism* and *policy* is worth it in the long run. In particular, to
RE: My wireless card activity could notberecognizedbyNetworkManager
Dan, My HAL version is 0.5.7-3. What Can I do to make HAL know my wireless interface? Do you know some HAL QA or related doc? Appreciate your help! Jihua -Original Message- From: Dan Williams [mailto:[EMAIL PROTECTED] Sent: Saturday, February 17, 2007 5:58 AM To: Jihua Cheng Cc: networkmanager-list@gnome.org Subject: RE: My wireless card activity could notberecognizedbyNetworkManager On Fri, 2007-02-16 at 12:28 -0800, Jihua Cheng wrote: Dan, I added the SET_NETDEV_DEV. Network Manager still does not detect my wireless card. I noticed that when I right click mouse on NetworkManager icon, only Gray Wired Network showed up. I disconnect Ethernet connection. Should Network manager show Wireless Network? Could some parameter setting is not properly setup for NetworkManager? This is really an issue between the driver and HAL. If you get it to show up in HAL, then it will show up in NetworkManager (and then we can see if your driver does WEXT right :). In any case, what version of HAL do you have? Then we can track down exactly how HAL is looking for wireless. Dan Thanks! Jihua -Original Message- From: Dan Williams [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 11:45 AM To: Jihua Cheng Cc: networkmanager-list@gnome.org Subject: RE: My wireless card activity could notberecognizedbyNetworkManager On Fri, 2007-02-16 at 11:25 -0800, Jihua Cheng wrote: Dan, Thanks a lot. Please find the answer bellow. - Do you call SET_NETDEV_DEV in your driver? My driver does not call SET_NETDEV_DEV. Do this then, that is definitely required for 2.6 drivers. It won't break hard if you don't have it, but you need it. It makes a link between your hardware device and the class device in sysfs and allows HAL to determine the parent/child relationship. Dan - Does it show up in /proc/net/wireless? Yes. cat /proc/net/wireless shows Inter-| sta-| Quality| Discarded packets | Missed | WE face | tus | link level noise | nwid crypt frag retry misc | beacon | 20 eth1: 00010 0 1600 0 6128224 27 86 0 - What is the contents of /sys/class/net/ethX ? (where ethX should be replaced with the interface name of the wireless device that is created when you load your driver) ls /sys/class/net/eth1 shows address addr_len broadcast carrier dormant features flags ifindex iflink link_mode mtu operstate statistics subsystem tx_queue_len type uevent weight wireles - What is the contents of /sys/class/net/ethX/wireless? (same as above, replace ethX as appropriate) ls /sys/class/net/eth1/wireless shows beacon crypt fragment level link misc noise nwid retries status - Do you implement the get_wireless_stats function in your iw_handler_def structure? That's what actually allows the system to create the /sys/class/net/ethX/wireless directory for you. get_wireless_stats is implemented. Regards, Charles -Original Message- From: Dan Williams [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 10:47 AM To: Jihua Cheng Cc: networkmanager-list@gnome.org Subject: RE: My wireless card activity could not berecognizedbyNetworkManager On Fri, 2007-02-16 at 10:26 -0800, Jihua Cheng wrote: / Dan, Thanks a lot! The card model is SD wireless card, attached into PCI card. PCI card provides the bridge. I wrote this driver. I can insmod my driver and it works well with wireless tools(iwconfig, iwlist, etc) and network command ( for example, ping). I could find my driver loaded properly, by using lsmod. You mentioned HAL doesn't appear to know about any wireless interfaces. How can I make HAL know my wireless interface? Some system function call? Make sure it does the right thing with sysfs. - Do you call SET_NETDEV_DEV in your driver? - Does it show up in /proc/net/wireless? - What is the contents of /sys/class/net/ethX ? (where ethX should be replaced with the interface name of the wireless device that is created when you load your driver) - What is the contents of /sys/class/net/ethX/wireless? (same as above, replace ethX as appropriate) - Do you implement the get_wireless_stats function in your iw_handler_def structure? That's what actually allows the system to create the /sys/class/net/ethX/wireless directory for you. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Current SVN broken?
On Tue, 2007-02-20 at 06:29 -0500, Dan Williams wrote: Hopefully days... though I was able to get it to associate with unencrypted yesterday OK. It should at least start up, find your devices, and if you have an instance of the applet (or another info-daemon) running, it should connect if it can see that network. Might give it another try again today... What version of wpa_supplicant are you running? 0.5.7 Simon. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
