Re: DBUS specifications for NetworkManager 0.9
Hi Ajay, you find all useful information for developers at [1]. The dbus interface spec is at [2]. Cheers, Tom [1] https://live.gnome.org/NetworkManager/ [2] http://projects.gnome.org/NetworkManager/developers/api/09/spec.html On Sat, 2012-03-10 at 09:47 +0530, Ajay Garg wrote: > Hi all. > > Are the dbus-specifications for NetworkManager 0.9 out (on similar lines as > http://projects.gnome.org/NetworkManager/developers/spec-08.html) ? > > Will be grateful for a reply. > > Thanks and Regards, > Ajay > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
DBUS specifications for NetworkManager 0.9
Hi all. Are the dbus-specifications for NetworkManager 0.9 out (on similar lines as http://projects.gnome.org/NetworkManager/developers/spec-08.html) ? Will be grateful for a reply. Thanks and Regards, Ajay ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: iptables rules
In fact, you should plan your firewall policy a little better. You have two systems doing exactly the same thing. Is this really necessary? Em 9 de março de 2012 18:41, rob stone escreveu: > Please ignore previous e-mail. > I have found the "problem". The firestarter firewall alters iptables > when it is launched. All I have to do is alter the init.d sequences so > my script starts last. > > Cheers, > Rob > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
iptables rules
Please ignore previous e-mail. I have found the "problem". The firestarter firewall alters iptables when it is launched. All I have to do is alter the init.d sequences so my script starts last. Cheers, Rob ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
iptables rules
Hi, Don't know where else to ask this question. What process is adding rules to iptables that specify the IP addresses of the nameservers I use?? Somewhere in the init sequence, "my" rules are being replaced and these rules contain specific references to the nameservers as well as the dhcp supplied IP address for my laptop (which obviously differs each time I boot it up). Any suggestions welcomed. Regards, Rob ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
On Fri, Mar 9, 2012 at 9:30 AM, Nathan Williams wrote: > On Fri, Mar 9, 2012 at 8:19 AM, Aleksander Morgado > wrote: > >> A possible fix to handle the case where we don't know how much we can > > read would be to try to read the first bytes of the record (3 or 4 or 5 >> just in case) to get the full record length of the record, assuming 1-3 >> bytes max for the size field, so we read "A3" + size encoded in 1 or 2 >> or 3 bytes + "80"); and once we know the whole record size, read the >> exact list size. >> > > Yeah, I thought about this, but had hoped to avoid it (If the record is > present at all, there will be a minimum of 7 bytes - A3058003FF - so I > think that's the right amount for an initial read). > > Here's a version that does the 7-then-more retry. It works on my SIM (retrying from 7 to 34 bytes, even though the entries are all FF); see what you think. - Nathan 0001-Fetch-parse-and-plumb-up-the-SPDI-information-from-t.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Query on setting ca-path and ca-cert with dbus for 802.1x
Hi, I'm writing a small app that creates 802.1x profiles. I can create profiles and connect, but I'm not sure I'm doing the right thing re certificates for phase1 (I'm not using EAP-MSCHAPv2 and EAP-GTC. I'm not using EAP-TLS): According to http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html I must set ca-cert to "file:///path/to/cert.der" with a trailing null byte and I should also set ca-path to a directory that contains the certs for the chain (as DER). I'm assuming that phase2-ca-cert and phase2-ca-path are used for EAP-TLS and I shouldn't be concerned with them. If I supply the chain certs do I need to supply the server cert in ca-cert? If I supply just the ca-cert do I need the chain certs? Is there anything else I need to know or do to avoid creating a big security hole? Thanks, John. -- John Carter Identity Networks jcar...@identitynetworks.com ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] dbus error enum fixes
I'm not sure I got the description of the problem right in the commit
message...
This fixes all of the enums that had been manually registered
pre-glib-mkenums to have the same values now as they did then. It also
fixes a few new enum types (bond and vlan stuff) to use the same
conventions. It doesn't change non-GError enum types, and it doesn't
change NMDnsManagerError or NMNetlinkMonitorError, because they weren't
registered before, and so presumably aren't being sent across D-Bus.
-- Dan
>From d34d24d36faba480c832d6bb9d2bf176cb13600d Mon Sep 17 00:00:00 2001
From: Dan Winship
Date: Fri, 9 Mar 2012 09:39:58 -0500
Subject: [PATCH] Fix names of error enum values
When NM was registering all of its enum types by hand, it was using
NamesListThis rather than the default names-like-this for the "nick"
values. When we switched to using glib-mkenums, this resulted in
dbus-glib using different strings for the D-Bus error names, causing
some problems.
Fix this by using glib-mkenums annotations to manually fix all the
enum values back to what they were before. (This can't be done in a
more automated way, because they old names aren't 100% consistent. Eg,
"UNKNOWN" frequently becomes "UnknownError" rather than just
"Unknown".)
---
libnm-glib/nm-remote-settings.h |6 ++--
libnm-glib/nm-secret-agent.h | 12 +-
libnm-glib/nm-vpn-plugin.h| 18
libnm-util/nm-connection.h|8 +++---
libnm-util/nm-setting-8021x.h |6 ++--
libnm-util/nm-setting-bluetooth.h |8 +++---
libnm-util/nm-setting-bond.h |6 ++--
libnm-util/nm-setting-cdma.h |8 +++---
libnm-util/nm-setting-connection.h| 10
libnm-util/nm-setting-gsm.h |8 +++---
libnm-util/nm-setting-infiniband.h|6 ++--
libnm-util/nm-setting-ip4-config.h|8 +++---
libnm-util/nm-setting-ip6-config.h|8 +++---
libnm-util/nm-setting-olpc-mesh.h |6 ++--
libnm-util/nm-setting-ppp.h |8 +++---
libnm-util/nm-setting-pppoe.h |8 +++---
libnm-util/nm-setting-serial.h|8 +++---
libnm-util/nm-setting-vlan.h |6 ++--
libnm-util/nm-setting-vpn.h |6 ++--
libnm-util/nm-setting-wimax.h |6 ++--
libnm-util/nm-setting-wired.h |6 ++--
libnm-util/nm-setting-wireless-security.h | 14 ++--
libnm-util/nm-setting-wireless.h | 10
libnm-util/nm-setting.h |8 +++---
src/dhcp-manager/nm-dhcp-manager.h|4 +-
src/logging/nm-logging.h |4 +-
src/modem-manager/nm-modem-cdma.h |6 ++--
src/modem-manager/nm-modem-gsm.h |6 ++--
src/nm-config.h |2 +-
src/nm-device-bond.h |6 ++--
src/nm-device-bt.h|6 ++--
src/nm-device-ethernet.h |6 ++--
src/nm-device-infiniband.h|6 ++--
src/nm-device-olpc-mesh.h |6 ++--
src/nm-device-vlan.h |6 ++--
src/nm-device-wifi.h |8 +++---
src/nm-device.h |6 ++--
src/nm-manager.h | 20 +-
src/nm-session-utils.h|8 +++---
src/settings/nm-agent-manager.h | 14 ++--
src/settings/nm-settings-error.h | 32 ++--
src/vpn-manager/nm-vpn-manager.h |8 +++---
src/wimax/nm-device-wimax.h |8 +++---
43 files changed, 180 insertions(+), 180 deletions(-)
diff --git a/libnm-glib/nm-remote-settings.h b/libnm-glib/nm-remote-settings.h
index 510c954..dd6c5a3 100644
--- a/libnm-glib/nm-remote-settings.h
+++ b/libnm-glib/nm-remote-settings.h
@@ -50,9 +50,9 @@ G_BEGIN_DECLS
*
**/
typedef enum {
- NM_REMOTE_SETTINGS_ERROR_UNKNOWN = 0,
- NM_REMOTE_SETTINGS_ERROR_CONNECTION_REMOVED,
- NM_REMOTE_SETTINGS_ERROR_CONNECTION_UNAVAILABLE,
+ NM_REMOTE_SETTINGS_ERROR_UNKNOWN = 0,/*< nick=UnknownError >*/
+ NM_REMOTE_SETTINGS_ERROR_CONNECTION_REMOVED, /*< nick=ConnectionRemoved >*/
+ NM_REMOTE_SETTINGS_ERROR_CONNECTION_UNAVAILABLE, /*< nick=ConnectionUnavailable >*/
} NMRemoteSettingsError;
#define NM_REMOTE_SETTINGS_ERROR nm_remote_settings_error_quark ()
diff --git a/libnm-glib/nm-secret-agent.h b/libnm-glib/nm-secret-agent.h
index 6a513ba..19f257e 100644
--- a/libnm-glib/nm-secret-agent.h
+++ b/libnm-glib/nm-secret-agent.h
@@ -30,12 +30,12 @@ G_BEGIN_DECLS
GQuark nm_secret_agent_error_quark (void);
typedef enum {
- NM_SECRET_AGENT_ERROR_NOT_AUTHORIZED = 0,
- NM_SECRET_AGENT_ERROR_INVALID_CONNECTION,
- NM_SECRET_AGENT_ERROR_USER_CANCELED,
- NM_SECRET_AGENT_ERROR_AGENT_CANCELED,
- NM_SECRET_AGENT_ERROR_INTERNAL_ERROR,
- NM_SECRET_AGENT_ERROR_NO_SECRET
Re: [MM 0.6] Plumb up the SPN display-rule bits
On Fri, Mar 9, 2012 at 8:19 AM, Aleksander Morgado wrote: > Hey Nathan, > The command to get the SPDI in the code didn't work for me: > --> AT+CRSM=176,28621,0,0,255 > <-- +CRSM: 103,0 >OK > Ah, bummer. With that change on, the list is properly parsed: > $ mmcli -i 0 > SIM '/org/freedesktop/ModemManager1/SIM/0' > - > Properties | imsi : '214040106373910' > | id : '8934041110059281105' > | operator id : '21404' > |operator name : 'Yoigo' > | operator SPDI list : '21401,21407' > |show PLMN at home : no > | show op name roaming : no > > My operator is Yoigo (21404), and I get 2 operators in the SPDI list: > 21401 (Vodafone) and 21407 (Movistar). But, I'm not sure about the > flags, I believe I should have gotten a 'yes' in 'show PLMN at home', > will check that later. > > For a quick check, grep for the 28486 query - if 'show PLMN at home' is true, the first byte of the response will be 01; this is reporting that the first byte of the response is 00. > A possible fix to handle the case where we don't know how much we can > read would be to try to read the first bytes of the record (3 or 4 or 5 > just in case) to get the full record length of the record, assuming 1-3 > bytes max for the size field, so we read "A3" + size encoded in 1 or 2 > or 3 bytes + "80"); and once we know the whole record size, read the > exact list size. > Yeah, I thought about this, but had hoped to avoid it (If the record is present at all, there will be a minimum of 7 bytes - A3058003FF - so I think that's the right amount for an initial read). > Don't know, but that very first read may fail I guess, if an empty SPDI > list is found (not sure if that will be "A3028000" or "A300") and we try > to read more than that and the modem doesn't allow it. > > On some cards the SPDI just isn't present and the whole thing returns an error (the same can happen with the SPN). It's a tiny bit noisy in the logs, but the correct (empty) results show up in the properties. > And a side note; it seems that the SIM initialization sequence is not > properly run after getting SIM-PIN unlocked, will take care of that myself. > > OK, I'm glad this wasn't just me. I'll hold off on reporting my crashes until you hit this. - Nathan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
Hey Nathan, > Also, if we do expose these two properties we also need to load and > expose the SPDI network list, or the properties will be useless. > > > Here's a patch to do that. There's a bit of annoying fighting with gchar > ** and gdbus's idea of constness, but it seems reasonable otherwise. > It works for me on SIMs with no SPDI information at all and on those > with extant empty lists; I'd appreciate a test on a SIM known to have a > non-empty list. > The command to get the SPDI in the code didn't work for me: --> AT+CRSM=176,28621,0,0,255 <-- +CRSM: 103,0 OK I can get the SPDI list here (Cinterion modem) using a shorter length to read, even if it's not the exact one; so instead of 255 I can use 60, 40, 30, 15... If I modify that in the code: --> AT+CRSM=176,28621,0,0,15 <-- +CRSM: 144,0,A308800612F41012F470FF OK With that change on, the list is properly parsed: $ mmcli -i 0 SIM '/org/freedesktop/ModemManager1/SIM/0' - Properties | imsi : '214040106373910' | id : '8934041110059281105' | operator id : '21404' |operator name : 'Yoigo' | operator SPDI list : '21401,21407' |show PLMN at home : no | show op name roaming : no My operator is Yoigo (21404), and I get 2 operators in the SPDI list: 21401 (Vodafone) and 21407 (Movistar). But, I'm not sure about the flags, I believe I should have gotten a 'yes' in 'show PLMN at home', will check that later. A possible fix to handle the case where we don't know how much we can read would be to try to read the first bytes of the record (3 or 4 or 5 just in case) to get the full record length of the record, assuming 1-3 bytes max for the size field, so we read "A3" + size encoded in 1 or 2 or 3 bytes + "80"); and once we know the whole record size, read the exact list size. Don't know, but that very first read may fail I guess, if an empty SPDI list is found (not sure if that will be "A3028000" or "A300") and we try to read more than that and the modem doesn't allow it. --- And a side note; it seems that the SIM initialization sequence is not properly run after getting SIM-PIN unlocked, will take care of that myself. -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
