Re: API changes
On Thursday 13 March 2008, Dan Williams said: A few API changes, both in the Settings specification, and in D-Bus. Some of these are thanks to Will's documentation effort and mini-review of the API while he was doing that. Great, glad to see the docu work is helping. And here's a bunch more API question marks that Helmut and myself came up with: They are organised by interface, and numbered, just grep for the #'s. Will org.freedesktop.NetworkManager Methods: #1 ActivateDevice ( o: device, s: service_name, o: connection, o: specific_object ) → nothing suggestion: move to org.freedesktop.NetworkManager.Device.Activate(s: service_name, o: connection, o: specific_object ) → nothing rationale: Helmut told me that this had already been discussed, and that because you could imagine Connection.Activate( Device ) or Device.Activate( Connection) it was decided to put it on the manager. If this was communicated properly, this is a worst of all compromise. Since Connection is on the settings service, the action can't be carried out there, so stay object-oriented and move this to Device. As I'm wrapping NM in Solid for KDE 4, I'll probably move this method onto the Device class anyway, but moving it in NM would be better for both projects IMO. #2 errors: org.freedesktop.NetworkManager.Error.ConnectionActivating Another connection is already activating or the same connection is already active. org.freedesktop.NetworkManager.Error.ConnectionActivating Does this mean the same connection is already activating or is another connection activating on this device? Suggestion: split into org.freedesktop.NetworkManager.Error.ConnectionAlreadyActive org.freedesktop.NetworkManager.Error.ConnectionActivating Although I'm not sure when this error would be raised, since a client might want to interrupt a connection attempt (maybe started with bad parameter, maybe it's going wrong and failing to error). #3 Sleep ( b: sleep ) → nothing Control the NetworkManager daemon's sleep state. When asleep, all interfaces that it manages are deactivated. Parameters sleep - b Indicates whether the NetworkManager daemon should sleep or wake. suggestion: It's not clear from the method name what this does SetSleepState( b: asleep ) perhaps? #4 enum: NM_STATE_CONNECTING = 2 The NetworkManager daemon is connecting a device. What does this mean when one device is already active and another is connecting? org.freedesktop.NetworkManager.AccessPoint #5 roperties: HwAddress - s - (read) The hardware address of the access point. suggestion: make this uint64 type=t? IP addresses are uints, and uint64 fits both 48 bit and 64 bit MAC addresses, and is smaller than the unicode string needed for a macaddress. org.freedesktop.NetworkManager.Device.Wired Properties: #6 HwAddress - s - (read) Hardware address of the device. Suggestion: change to 't' as above #7 org.freedesktop.NetworkManagerSettings Signals: NewConnection ( o: connection ) Suggestion: rename to ConnectionAdded to be consistent with NetworkManager.DeviceAdded #8 Where is ConnectionRemoved on this interface? See comment #11 below. Methods: #9 ListConnections ( ) → ao Suggestion: rename to GetConnections to be consistent with other Get list type methods org.freedesktop.NetworkManagerSettings.Connection #10 Suggestion: for the settings maps, switch to u instead of s keys defined by well-known enums - faster, smaller, safer Signals: #11 Removed ( ) Emitted when this settings object was removed. IIUC this is emitted before the object is removed, or else DBus would likely have a fit. If this is the case, then it has different semantics to NetworkManager.DeviceRemoved(o). If prior to removal, should be called AboutToBeRemoved. Clarify if what happens to this object after it emits this signal. Suggestion: move to NetworkManagerSettings.ConnectionRemoved to be emitted after removal org.freedesktop.NetworkManager.Device Properties: #12 Ip4Address - i - (read) The IPv4 address actually bound to the device. FIXME: wrong type - should be u. #13 FIXME: devices can have 1 IP address so make this 'au' with the canonical address first, OR state that secondary IP addresses are listed in the Ip4Config. #14 Ip4Config - o - (read) FIXME: make clear that is is the data used to configure the device, not the actual configuration QUESTION: since in the case of a dhcp IPv4 configuration, the referenced Ip4Config from the Settings will know nothing about the actual IP address, netmask etc, so where are these available apart from the Ip4Address above? #15 HwAddress - s - (read) The hardware address of the device. suggestion: uint64 (type=t) as above #16 org.freedesktop.NetworkManager.IP4Config Address - u - (read) IPv4 address. Suggestion: what about multiple addresses?change to 'au' #17 Hostname - s - (read) The hostname associated with this IPv4 address. Suggestion: what about multiple
nm applet and hidden ssid
I'm running F8 with the latest kernel, wpa_supplament and NetworkManager from koji. My wireless network has a hidden ssid, I am able to connect through nm applet using the 'connect to other wireless network...' Then the ssid shows up on the wireless networks list in nm applet. I am normally on a wired net and after a reboot the hidden ssid I connected before is gone and I have to go through the same steps as above. Which sucks. Also if I disconnect from wired network nm does not automatically switch to the ssid I had last which was the hidden one. Would it be better if once you connected to a hidden ssid it would always appear in the list if you are within range? -Thanks ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: API changes
On Thursday 13 March 2008, Dan Williams said: c) clarify the meaning of the 'mac-address' attribute of both the wired and wireless settings; a valid 'mac-address' will lock the connection to a device of the specified type with the specified MAC address. If we want to allow MAC address cloning, we'll have to add another field to wired wireless. Where is this clarified? Coupled with your ChangeLog entry from yesterday add the 'autoip' property from the spec, I'm worried now that I've missed some existing documentation. Will ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm applet and hidden ssid
On Thu, 2008-03-13 at 11:27 -0400, Louis E Garcia II wrote: I'm running F8 with the latest kernel, wpa_supplament and NetworkManager from koji. My wireless network has a hidden ssid, I am able to connect through nm applet using the 'connect to other wireless network...' Then the ssid shows up on the wireless networks list in nm applet. I am normally on a wired net and after a reboot the hidden ssid I connected before is gone and I have to go through the same steps as above. Which sucks. Also if I disconnect from wired network nm does not automatically switch to the ssid I had last which was the hidden one. Would it be better if once you connected to a hidden ssid it would always appear in the list if you are within range? Does the BSSID of your hidden AP show up in GConf under 'seen-bssids' for it's connection? Also, some logs from /var/log/messages would be useful during and right after the connection attempt. It may be that the applet is unable to grab the BSSID of the associated AP and therefore unable to cache that in GConf. NM uses the cached BSSIDs to match scan results with SSIDs. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: API changes
On Thu, 2008-03-13 at 16:37 +0100, Will Stephenson wrote: On Thursday 13 March 2008, Dan Williams said: c) clarify the meaning of the 'mac-address' attribute of both the wired and wireless settings; a valid 'mac-address' will lock the connection to a device of the specified type with the specified MAC address. If we want to allow MAC address cloning, we'll have to add another field to wired wireless. Where is this clarified? Coupled with your ChangeLog entry from yesterday add the 'autoip' property from the spec, I'm worried now that I've missed some existing documentation. NetworkManagerConfigurationSpecification on live.gnome.org I added, but then removed, the 'autoip' property from both the spec and the code; superseded by 'method' instead. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: API changes
On Thu, Mar 13, 2008 at 9:29 AM, Will Stephenson [EMAIL PROTECTED] wrote: org.freedesktop.NetworkManager Methods: #1 ActivateDevice ( o: device, s: service_name, o: connection, o: specific_object ) → nothing suggestion: move to org.freedesktop.NetworkManager.Device.Activate(s: service_name, o: connection, o: specific_object ) → nothing rationale: Helmut told me that this had already been discussed, and that because you could imagine Connection.Activate( Device ) or Device.Activate( Connection) it was decided to put it on the manager. If this was communicated properly, this is a worst of all compromise. Since Connection is on the settings service, the action can't be carried out there, so stay object-oriented and move this to Device. As I'm wrapping NM in Solid for KDE 4, I'll probably move this method onto the Device class anyway, but moving it in NM would be better for both projects IMO. It was never a discussion between Connection.Activate(Device) vs Device.Activate(Connection). The current solution isn't a compromise either, it's just the way things have to be right now. NMManager is the thing that has access to available settings and devices, hence it's the thing that can tie them together for activation. Device.Activate(connection_path) is not possible since device can't translate that connection_path to Connection without the help of NMManager. It can't do that since NMManager has to contain the list of devices, and circular dependencies are much bigger OOP offenders than what you suggest. The reason why it was pretty much impossible to add new device types to 0.6 branch was because of no class hierarchy, everything just called everything and to add a new device type meant changing almost all source files. With the strict hierarchy (that I've been defending very hard, and still do), adding a new device means implementing a subclass of NMDevice, a subclass of NMSetting and a registration function in NMHalManager. I'm not willing to give up all this just to have Device.Activate(Connection). #2 errors: org.freedesktop.NetworkManager.Error.ConnectionActivating Another connection is already activating or the same connection is already active. org.freedesktop.NetworkManager.Error.ConnectionActivating Does this mean the same connection is already activating or is another connection activating on this device? Suggestion: split into org.freedesktop.NetworkManager.Error.ConnectionAlreadyActive org.freedesktop.NetworkManager.Error.ConnectionActivating Although I'm not sure when this error would be raised, since a client might want to interrupt a connection attempt (maybe started with bad parameter, maybe it's going wrong and failing to error). #3 Sleep ( b: sleep ) → nothing Control the NetworkManager daemon's sleep state. When asleep, all interfaces that it manages are deactivated. Parameters sleep - b Indicates whether the NetworkManager daemon should sleep or wake. suggestion: It's not clear from the method name what this does SetSleepState( b: asleep ) perhaps? It would be even clearer to rename it to EnableNetworking(b: enabled). #4 enum: NM_STATE_CONNECTING = 2 The NetworkManager daemon is connecting a device. What does this mean when one device is already active and another is connecting? The NMState enum is not 100% accurate in case of multiple devices and it isn't meant to. It reflects the best state of NM. The reason behind it is to give easier API for applications that only care if the machine has network connection or not. So for your specific question, if a device is active and another one is activating, the NMState reamains NM_STATE_CONNECTED. If an app wants more information, it can always get NMManager, it's list of devices and the state of each device. org.freedesktop.NetworkManager.AccessPoint #5 roperties: HwAddress - s - (read) The hardware address of the access point. suggestion: make this uint64 type=t? IP addresses are uints, and uint64 fits both 48 bit and 64 bit MAC addresses, and is smaller than the unicode string needed for a macaddress. The data type for it in the kernel is struct ether_addr, just because it fits in a uint64 doesn't mean it's a good data type for it. There's no calculations to perform on it, the only useful operation on it would be to print it out. Then why bother with the conversions to save a few bites on communication when you're going to waste these same bites when you're actually going to do anything (display) it? org.freedesktop.NetworkManager.Device.Wired Properties: #6 HwAddress - s - (read) Hardware address of the device. Suggestion: change to 't' as above Just as above. #7 org.freedesktop.NetworkManagerSettings Signals: NewConnection ( o: connection ) Suggestion: rename to ConnectionAdded to be consistent with NetworkManager.DeviceAdded Sounds good to me. #8 Where is ConnectionRemoved
Re: API changes
On Thu, 2008-03-13 at 16:29 +0100, Will Stephenson wrote: On Thursday 13 March 2008, Dan Williams said: A few API changes, both in the Settings specification, and in D-Bus. Some of these are thanks to Will's documentation effort and mini-review of the API while he was doing that. Great, glad to see the docu work is helping. And here's a bunch more API question marks that Helmut and myself came up with: They are organised by interface, and numbered, just grep for the #'s. Will org.freedesktop.NetworkManager Methods: #1 ActivateDevice ( o: device, s: service_name, o: connection, o: specific_object ) → nothing suggestion: move to org.freedesktop.NetworkManager.Device.Activate(s: service_name, o: connection, o: specific_object ) → nothing This is somewhat hard internally, since the NMDevice objects are children of the NMManager object, and therefore have no access to the connection list or the settings services. I'm leaning more towards renaming this to something like: ActivateConnection( o: connection, o: device ...) since we're not going to do connections spanning multiple devices for 0.7 (bridging, etc). rationale: Helmut told me that this had already been discussed, and that because you could imagine Connection.Activate( Device ) or Device.Activate( Connection) it was decided to put it on the manager. If this was communicated properly, this is a worst of all compromise. Since Connection is on the settings service, the action can't be carried out there, so stay object-oriented and move this to Device. As I'm wrapping NM in Solid for KDE 4, I'll probably move this method onto the Device class anyway, but moving it in NM would be better for both projects IMO. #2 errors: org.freedesktop.NetworkManager.Error.ConnectionActivating Another connection is already activating or the same connection is already active. org.freedesktop.NetworkManager.Error.ConnectionActivating Does this mean the same connection is already activating or is another connection activating on this device? Suggestion: split into org.freedesktop.NetworkManager.Error.ConnectionAlreadyActive org.freedesktop.NetworkManager.Error.ConnectionActivating Probably a good thing to do. Although I'm not sure when this error would be raised, since a client might want to interrupt a connection attempt (maybe started with bad parameter, maybe it's going wrong and failing to error). #3 Sleep ( b: sleep ) → nothing Control the NetworkManager daemon's sleep state. When asleep, all interfaces that it manages are deactivated. Parameters sleep - b Indicates whether the NetworkManager daemon should sleep or wake. suggestion: It's not clear from the method name what this does SetSleepState( b: asleep ) perhaps? Well, Tambet and I figured it was kind of pointless to have two different functions. We could make them properties of the manager object and use the D-Bus property interface, but they are easier to lock down when they are methods. I guess I agree that the current name is a bit confusing; not sure quite what to call it though. #4 enum: NM_STATE_CONNECTING = 2 The NetworkManager daemon is connecting a device. What does this mean when one device is already active and another is connecting? Note that we need to preserve this state enum for minimal backwards compatibility with 0.6 clients. However, the mapping could be better in the manager right now. STATE_CONNECTED: there is at least one active connection STATE_CONNECTING: there are no active connections, but at least one connection is activating on a device STATE_DISCONNECTED: there are no active connections org.freedesktop.NetworkManager.AccessPoint #5 roperties: HwAddress - s - (read) The hardware address of the access point. suggestion: make this uint64 type=t? IP addresses are uints, and uint64 fits both 48 bit and 64 bit MAC addresses, and is smaller than the unicode string needed for a macaddress. When are 64-bit MAC addresses going to show up? That would take a pretty drastic change in the 802.11 protocol, so I don't think we need to care about it right now. WRT to this and the other comments about HwAddress; it's a device-type specific UID, it just happens that both 802.11 (WiFi), 802.16 (Bluetooth), and 802.3 (Ethernet) all use 48-bit MAC addresses. But I'd imagine we'll use HwAddress for the IMEI on GSM cards, the ESN/MEID on CDMA cards, etc. Perhaps it's confusing that the property is the same name for all the different device types even though the contents would be different? I think it would be worse if the type was also consistent across all devices. One benefit of keeping it as a string is that we're open to better forwards compatibility; we don't have to break API when something happens like CDMA changing from 32-bit ESN to 56-bit MEID happens. The downside of course is that the client has to parse
Re: API changes
Am Donnerstag, 13. März 2008 17:09:54 schrieb Tambet Ingo: On Thu, Mar 13, 2008 at 9:29 AM, Will Stephenson [EMAIL PROTECTED] rationale: Helmut told me that this had already been discussed, and that because you could imagine Connection.Activate( Device ) or Device.Activate( Connection) it was decided to put it on the manager. If this was communicated properly, this is a worst of all compromise. Since Connection is on the settings service, the action can't be carried out there, so stay object-oriented and move this to Device. As I'm wrapping NM in Solid for KDE 4, I'll probably move this method onto the Device class anyway, but moving it in NM would be better for both projects IMO. It was never a discussion between Connection.Activate(Device) vs Device.Activate(Connection). The current solution isn't a compromise This came up some time ago at [1]. But you're right, the arguments were somewhat different. Helmut [1] http://www.mail-archive.com/networkmanager-list@gnome.org/msg07328.html ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: API changes
On Thursday 13 March 2008, Tambet Ingo said: On Thu, Mar 13, 2008 at 9:29 AM, Will Stephenson [EMAIL PROTECTED] wrote: org.freedesktop.NetworkManager Methods: #1 ActivateDevice ( o: device, s: service_name, o: connection, o: specific_object ) → nothing suggestion: move to org.freedesktop.NetworkManager.Device.Activate(s: service_name, o: connection, o: specific_object ) → nothing rationale: Helmut told me that this had already been discussed, and that because you could imagine Connection.Activate( Device ) or Device.Activate( Connection) it was decided to put it on the manager. If this was communicated properly, this is a worst of all compromise. Since Connection is on the settings service, the action can't be carried out there, so stay object-oriented and move this to Device. As I'm wrapping NM in Solid for KDE 4, I'll probably move this method onto the Device class anyway, but moving it in NM would be better for both projects IMO. It was never a discussion between Connection.Activate(Device) vs Device.Activate(Connection). The current solution isn't a compromise either, it's just the way things have to be right now. NMManager is the thing that has access to available settings and devices, hence it's the thing that can tie them together for activation. Device.Activate(connection_path) is not possible since device can't translate that connection_path to Connection without the help of NMManager. It can't do that since NMManager has to contain the list of devices, and circular dependencies are much bigger OOP offenders than what you suggest. The reason why it was pretty much impossible to add new device types to 0.6 branch was because of no class hierarchy, everything just called everything and to add a new device type meant changing almost all source files. With the strict hierarchy (that I've been defending very hard, and still do), adding a new device means implementing a subclass of NMDevice, a subclass of NMSetting and a registration function in NMHalManager. I'm not willing to give up all this just to have Device.Activate(Connection). I'd keep the clean internal structure and offer a OO activate method by offering the dbus interface for Device via a facade object that has the back-reference to NMManager, but you're the one writing the code here. #3 Sleep ( b: sleep ) → nothing Control the NetworkManager daemon's sleep state. When asleep, all interfaces that it manages are deactivated. Parameters sleep - b Indicates whether the NetworkManager daemon should sleep or wake. suggestion: It's not clear from the method name what this does SetSleepState( b: asleep ) perhaps? It would be even clearer to rename it to EnableNetworking(b: enabled). Agreed #4 enum: NM_STATE_CONNECTING = 2 The NetworkManager daemon is connecting a device. What does this mean when one device is already active and another is connecting? The NMState enum is not 100% accurate in case of multiple devices and it isn't meant to. It reflects the best state of NM. The reason behind it is to give easier API for applications that only care if the machine has network connection or not. So for your specific question, if a device is active and another one is activating, the NMState reamains NM_STATE_CONNECTED. If an app wants more information, it can always get NMManager, it's list of devices and the state of each device. Ok, I'll explain this in the API docu. org.freedesktop.NetworkManager.AccessPoint #5 roperties: HwAddress - s - (read) The hardware address of the access point. suggestion: make this uint64 type=t? IP addresses are uints, and uint64 fits both 48 bit and 64 bit MAC addresses, and is smaller than the unicode string needed for a macaddress. The data type for it in the kernel is struct ether_addr, just because it fits in a uint64 doesn't mean it's a good data type for it. There's no calculations to perform on it, the only useful operation on it would be to print it out. Then why bother with the conversions to save a few bites on communication when you're going to waste these same bites when you're actually going to do anything (display) it? I understood the applet merges APs in the same network for presentation to the user, is that what all the calls to ether_aton() in the NM and applet sources are doing? And HAL uses uint64 for mac addresses. At a guess, you're converting from that, using hex-and-colons for dbus transport, converting it to ether_addr for comparisons, and converting it back again for the UI. org.freedesktop.NetworkManagerSettings.Connection #10 Suggestion: for the settings maps, switch to u instead of s keys defined by well-known enums - faster, smaller, safer Setting types are not necessarily well known. I've been trying to keep NM as extensible as possible and currently the only thing missing in NM to allow plugins (to
Re: API changes
On Thu, 2008-03-13 at 18:17 +0100, Will Stephenson wrote: On Thursday 13 March 2008, Tambet Ingo said: On Thu, Mar 13, 2008 at 9:29 AM, Will Stephenson [EMAIL PROTECTED] wrote: org.freedesktop.NetworkManager Methods: #1 ActivateDevice ( o: device, s: service_name, o: connection, o: specific_object ) → nothing suggestion: move to org.freedesktop.NetworkManager.Device.Activate(s: service_name, o: connection, o: specific_object ) → nothing rationale: Helmut told me that this had already been discussed, and that because you could imagine Connection.Activate( Device ) or Device.Activate( Connection) it was decided to put it on the manager. If this was communicated properly, this is a worst of all compromise. Since Connection is on the settings service, the action can't be carried out there, so stay object-oriented and move this to Device. As I'm wrapping NM in Solid for KDE 4, I'll probably move this method onto the Device class anyway, but moving it in NM would be better for both projects IMO. It was never a discussion between Connection.Activate(Device) vs Device.Activate(Connection). The current solution isn't a compromise either, it's just the way things have to be right now. NMManager is the thing that has access to available settings and devices, hence it's the thing that can tie them together for activation. Device.Activate(connection_path) is not possible since device can't translate that connection_path to Connection without the help of NMManager. It can't do that since NMManager has to contain the list of devices, and circular dependencies are much bigger OOP offenders than what you suggest. The reason why it was pretty much impossible to add new device types to 0.6 branch was because of no class hierarchy, everything just called everything and to add a new device type meant changing almost all source files. With the strict hierarchy (that I've been defending very hard, and still do), adding a new device means implementing a subclass of NMDevice, a subclass of NMSetting and a registration function in NMHalManager. I'm not willing to give up all this just to have Device.Activate(Connection). I'd keep the clean internal structure and offer a OO activate method by offering the dbus interface for Device via a facade object that has the back-reference to NMManager, but you're the one writing the code here. #3 Sleep ( b: sleep ) → nothing Control the NetworkManager daemon's sleep state. When asleep, all interfaces that it manages are deactivated. Parameters sleep - b Indicates whether the NetworkManager daemon should sleep or wake. suggestion: It's not clear from the method name what this does SetSleepState( b: asleep ) perhaps? It would be even clearer to rename it to EnableNetworking(b: enabled). Agreed #4 enum: NM_STATE_CONNECTING = 2 The NetworkManager daemon is connecting a device. What does this mean when one device is already active and another is connecting? The NMState enum is not 100% accurate in case of multiple devices and it isn't meant to. It reflects the best state of NM. The reason behind it is to give easier API for applications that only care if the machine has network connection or not. So for your specific question, if a device is active and another one is activating, the NMState reamains NM_STATE_CONNECTED. If an app wants more information, it can always get NMManager, it's list of devices and the state of each device. Ok, I'll explain this in the API docu. org.freedesktop.NetworkManager.AccessPoint #5 roperties: HwAddress - s - (read) The hardware address of the access point. suggestion: make this uint64 type=t? IP addresses are uints, and uint64 fits both 48 bit and 64 bit MAC addresses, and is smaller than the unicode string needed for a macaddress. The data type for it in the kernel is struct ether_addr, just because it fits in a uint64 doesn't mean it's a good data type for it. There's no calculations to perform on it, the only useful operation on it would be to print it out. Then why bother with the conversions to save a few bites on communication when you're going to waste these same bites when you're actually going to do anything (display) it? I understood the applet merges APs in the same network for presentation to the user, is that what all the calls to ether_aton() in the NM and applet sources are doing? And HAL uses uint64 for mac addresses. At a guess, you're converting from that, using hex-and-colons for dbus transport, converting it to ether_addr for comparisons, and converting it back again for the UI. NM pulls it right out of SIOCGIFHWADDR which is struct ether_addr (ie, char[6]). It does get converted from struct ether_addr to a string with ether_ntop for D-Bus transport. 1/2 dozen to one,
Converting wpa_supplicat.conf to NetworkManager setup
I've got a wpa_supplicat.conf file that can connect to my wireless network,
but I can't figure out how to make NetworkManager use the same settings. My
wpa_supplicat.conf file looks like this:
# ap_scan=2
network={
ssid=my-ssid
proto=WPA2
key_mgmt=WPA-EAP
eap=TLS
identity=my-id
# scan_ssid=1
private_key=my-key
private_key_passwd=my-password
priority=1
}
I tried to setup a corresponding WPA2 Enterprise with the fields as you
would expect, but when network manager connects it adds in the two commented
lined above. If I add those two lines to my wpa_supplicat.conf fie then I
can't connect. Does anybody know how to make NetworkManager use my
wpa_supplicat.conf file above?
P.S. One thought for the future would be to have a way to say, when trying
to connect to this ssid, use this conf file. That would allow anybody who
can make a wpa_supplicat.conf file that works able to use networkmanager
(even if through a bit of a brute force method)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: API changes
On Thu, Mar 13, 2008 at 11:48 AM, Dan Williams [EMAIL PROTECTED] wrote: On Thu, 2008-03-13 at 18:17 +0100, Will Stephenson wrote: I understood the applet merges APs in the same network for presentation to the user, is that what all the calls to ether_aton() in the NM and applet sources are doing? And HAL uses uint64 for mac addresses. At a guess, you're converting from that, using hex-and-colons for dbus transport, converting it to ether_addr for comparisons, and converting it back again for the UI. NM pulls it right out of SIOCGIFHWADDR which is struct ether_addr (ie, char[6]). It does get converted from struct ether_addr to a string with ether_ntop for D-Bus transport. 1/2 dozen to one, 6 to another. I think the decision to be made is to either leave it as-is (ie, strings), or convert the type to byte array with the exact length of the device type's hardware address (char[6] for 802.11, 802.3, and 802.15, char[7] for GSM CDMA). That's an easy decision. Since there isn't significant space savings between byte array and string (byte array with a couple of colons and '\0') and there's nothing else for UIs to do with these other than print out (as strings), there's no reason to change anything. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re[2]: NetworkManager VPN and routing in bridged mode
Hello,
The attached is updated version of the patch I've sent yesterday. The
main changes are as follows:
* Ported to NM 0.6.6 (SVN rev 3381)
* Handle user-specified routes correctly too
There are some architectural issues with the code - I've implemented
them the way to be as much backward-compatible as possible, nevertheless
they should be probably refactored in future. They are:
- handling of 11th arg (remote_gateway) in D-BUS message in
nm-vpn-service.c: it's no different from 10th, 9th, ... arg, so it
should be sent by all VPN daemons (set to zero if there is no remote
gateway i.e. we are dealing with P-t-P device) and warning should be
generated if it can't be found. It's not difficult to implement but I
have no setup to test pptp/vpnc and modify them accordingly.
- nm_system_device_set_ip4_route_with_iface(). Essentially, I've
reworked the function to accept interface name instead of NMDevice *
and create routes without RTF_GATEWAY flag if necessary. For now, an
older nm_system_device_set_ip4_route() acts as a wrapper to this.
P.S. In the very side note - what about
http://bugzilla.gnome.org/show_bug.cgi?id=353265 ? It's fixed for 0.7
but still not committed to 0.6 branch.
--
Regards,
Valentine Sinitsyn
Index: src/nm-ip4-config.c
===
--- src/nm-ip4-config.c (revision 3447)
+++ src/nm-ip4-config.c (working copy)
@@ -43,6 +43,8 @@
guint32 mtu;/* Maximum Transmission Unit of the interface */
guint32 mss;/* Maximum Segment Size of the route */
+
+ guint32 remote_gateway; /* Used for VPN networks with tap-style virtual
device */
GSList *nameservers;
GSList *domains;
@@ -56,6 +58,7 @@
* an IP4Config before it can be used.
*/
gbooleansecondary;
+
};
@@ -357,6 +360,20 @@
config-mss = mss;
}
+guint32nm_ip4_config_get_remote_gateway (NMIP4Config *config)
+{
+ g_return_val_if_fail (config != NULL, 0);
+
+ return config-remote_gateway;
+}
+
+void nm_ip4_config_set_remote_gateway (NMIP4Config *config, guint32
remote_gateway)
+{
+ g_return_if_fail (config != NULL);
+
+ config-remote_gateway = remote_gateway;
+}
+
/* libnl convenience/conversion functions */
static int ip4_addr_to_rtnl_local (guint32 ip4_address, struct rtnl_addr *addr)
Index: src/nm-ip4-config.h
===
--- src/nm-ip4-config.h (revision 3447)
+++ src/nm-ip4-config.h (working copy)
@@ -74,6 +74,9 @@
guint32nm_ip4_config_get_mss (NMIP4Config
*config);
void nm_ip4_config_set_mss (NMIP4Config
*config, guint32 mss);
+guint32nm_ip4_config_get_remote_gateway(NMIP4Config
*config);
+void nm_ip4_config_set_remote_gateway(NMIP4Config
*config, guint32 remote_gateway);
+
/* Flags for nm_ip4_config_to_rtnl_addr() */
#define NM_RTNL_ADDR_NONE 0x
#define NM_RTNL_ADDR_ADDR 0x0001
Index: src/vpn-manager/nm-vpn-service.c
===
--- src/vpn-manager/nm-vpn-service.c(revision 3447)
+++ src/vpn-manager/nm-vpn-service.c(working copy)
@@ -841,6 +841,17 @@
if (!get_dbus_string_helper (iter, login_banner, Login Banner))
goto out;
+ /* Eleventh arg: Remote VPN Gateway (UINT32)
+* For now, only OpenVPN service knows about it so we won't complain
+* if it is absent from the message.
+*/
+ if (dbus_message_iter_next (iter)
+(dbus_message_iter_get_arg_type (iter) == DBUS_TYPE_UINT32))
+ {
+ dbus_message_iter_get_basic (iter, num);
+ nm_ip4_config_set_remote_gateway (config, num);
+ }
+
#ifdef NM_DEBUG_VPN_CONFIG
print_vpn_config (ip4_vpn_gateway,
tundev,
Index: src/NetworkManagerSystem.c
===
--- src/NetworkManagerSystem.c (revision 3447)
+++ src/NetworkManagerSystem.c (working copy)
@@ -1,6 +1,7 @@
/* NetworkManager -- Network link manager
*
* Dan Williams [EMAIL PROTECTED]
+
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -51,23 +52,19 @@
#include netlink/utils.h
#include netlink/route/link.h
-
/*
- * nm_system_device_set_ip4_route
+ * nm_system_device_set_ip4_route_with_iface
*
*/
-static gboolean nm_system_device_set_ip4_route (NMDevice *dev, int
ip4_gateway, int ip4_dest, int ip4_netmask, int mss)
+static gboolean nm_system_device_set_ip4_route_with_iface (const char *iface,
int ip4_gateway, int ip4_dest, int ip4_netmask, int mss)
{
NMSock *sk;
gboolean
Re: Converting wpa_supplicat.conf to NetworkManager setup
On Thu, 2008-03-13 at 14:18 -0400, Matt Lavin wrote:
I've got a wpa_supplicat.conf file that can connect to my wireless
network, but I can't figure out how to make NetworkManager use the
same settings. My wpa_supplicat.conf file looks like this:
# ap_scan=2
network={
ssid=my-ssid
proto=WPA2
key_mgmt=WPA-EAP
eap=TLS
identity=my-id
# scan_ssid=1
private_key=my-key
private_key_passwd=my-password
priority=1
}
I tried to setup a corresponding WPA2 Enterprise with the fields as
you would expect, but when network manager connects it adds in the two
commented lined above. If I add those two lines to my
wpa_supplicat.conf fie then I can't connect. Does anybody know how to
make NetworkManager use my wpa_supplicat.conf file above?
This means your wireless driver does not support scan capabilities, and
doesn't implement the WEXT specification correctly. I'd ask your distro
vendor to apply the scan capability patch to their kernel (it's quite
small and low-impact and already in 2.6.24) and then you should be fine.
The problem is that NM cannot detect whether your driver has the ability
to use ap_scan=1 or whether it must fall back to ap_scan=2. Drivers
that do not work with ap_scan=2 are _broken_ by definition, but this is
a workaround.
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
