Re: Not able to connect from CDMA2000 Modem from Network Manager connection
Could you please give me the package here in forum? I want to finish this testing now. I am not feeling comfortable with fedora build system Thanks Aleksander http://old.nabble.com/file/p34455920/21.png Aleksander Morgado-5 wrote: > > >> >> May be, I am doing something wrong...I have got same log after installing >> RPM!! >> >> from link: http://koji.fedoraproject.org/koji/taskinfo?taskID=4473547 >> http://koji.fedoraproject.org/koji/taskinfo?taskID=4473547 >> > > Ah, of course, I didn't update that RPM, just the sources. > > -- > Aleksander > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > -- View this message in context: http://old.nabble.com/Not-able-to-connect-from-CDMA2000-Modem-from-Network-Manager-connection-tp33876035p34455920.html Sent from the Gnome - NetworkManager mailing list archive at Nabble.com. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[MM] [PATCH] modem-helpers: handle the case when operator name is "Unknown"
Some modems report "Unknown" as the operator name when failed to obtain
the actual value:
--> 'AT+COPS=3,0;+COPS?'
<-- '+COPS: 0,0,"Unknown",0OK'
This patch prevents "Unknown" from being treated as a valid operator name.
---
src/mm-modem-helpers.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/mm-modem-helpers.c b/src/mm-modem-helpers.c
index db0bfbd..9aa360d 100644
--- a/src/mm-modem-helpers.c
+++ b/src/mm-modem-helpers.c
@@ -1456,6 +1456,8 @@ mm_3gpp_parse_operator (const gchar *reply,
}
if (operator) {
+gchar *casefolded_operator;
+
/* Some modems (Option & HSO) return the operator name as a hexadecimal
* string of the bytes of the operator name as encoded by the current
* character set.
@@ -1468,8 +1470,18 @@ mm_3gpp_parse_operator (const gchar *reply,
*/
if (!g_utf8_validate (operator, -1, NULL)) {
g_free (operator);
+return NULL;
+}
+
+/* Some modems (Novatel LTE) return the operator name as "Unknown" when
+ * it fails to obtain the operator name. Return NULL in such case.
+ */
+casefolded_operator = g_utf8_casefold (operator, -1);
+if (g_utf8_collate (casefolded_operator, "unknown") == 0) {
+g_free (operator);
operator = NULL;
}
+g_free (casefolded_operator);
}
return operator;
--
1.7.7.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Two WLANs with the same SSID but different connection names
Den 19. sep. 2012 14:23, skrev Marius Kotsbak: Does the same happen if you remove autoconnect for both of them? Maybe NM always autoconnect to the first one. Turning off autoconnect to both networks actually did the trick. Still, that means the autoconnect option overrides my manual selection. Not cool. -- Alexander Karlstad ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Two WLANs with the same SSID but different connection names
Hello, Not that nm-applet will show you, however you can use d-feet to look at NM via D-Bus. You can look at the /org/freedesktop/NetworkManager/ActiveConnection.Connection property which will tell which 'settings' path/dbus object it is connected to. On 09/19/2012 06:01 AM, Alexander Karlstad wrote: Den 18. sep. 2012 19:21, skrev Dan Williams: Also, can you verify from /var/log/messages or /var/log/daemon.log (or wherever the syslog daemon facility goes) that NM is actually only ever activating the single connection even if you choose the other one? NM prints out exactly which connection it's starting in the logs. Weird enough, /var/log/syslog tells me that it uses the right connection with the right cridentials when I select it, but I still get the same IP, DNS servers and so on. Attaching excerpt from /var/log/syslog when connecting to the "different" networks in the list. BTW, is it possible to get nm-applet to somehow show me which of the two connections I'm connected to? There are no "check signs" or other visual signs next to the active connection in the eduroam list (as seen in [1]). [1]: http://ubuntuone.com/1T2nTxtAyYjoMD64XFwkSx ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list -- Nathanael d. Noblet t 403.875.4613 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can I configure a specified PEAP wireless in network-manager
On 09/19/2012 12:12 AM, Dan Williams wrote:
On Tue, 2012-09-18 at 14:45 +0800, Frank wrote:
Here's the wpa_supplicant.conf file:
ap_scan=1
network={
ssid=""
proto=WPA2
key_mgmt=WPA-EAP
pairwise=CCMP
group=CCMP
eap=PEAP
phase1="peaplabel=0"
phase2="auth=GTC"
identity=""
password=""
}
I can use wpa_supplicant to connect the wireless, but unfortunately,
when I configured these settings in Network Manager, it failed to
connect to the network. I wonder what's wrong with that.
If you can get some logs off of NM, that would be great. They are
normally sent wherever syslog's 'daemon' facility gets logged, various
as /var/log/messages, /var/log/daemon.log,
or /var/log/NetworkManager.log depending on your distro. That may only
indicate that the supplicant failed to connect, and then we need some
supplicant debug logging instead, which is roughly:
1) mv /usr/sbin/wpa_supplicant /
2) killall -TERM wpa_supplicant
3) /wpa_supplicant -dddtu
4) retry the connection and let it fail
5) grab the supplicant debug output (careful, may be sensitive info)
But before you do that, NM logs the configuration its sending to the
supplicant to syslog, so try to match that up with what you have from
the plain wpa_supplicant config and see what the differences are. You
will see NM send "TKIP CCMP" instead of just "CCMP", but that is not
going to be the problem.
Does your network have *both* WPA-only and WPA2-only acess points with
the same SSID?
Dan
Well, I first say thanks to you. Tomorrow I'll try the wireless
connection. Before that, I can tell you that my distro is Debian
GNU/Linux Wheezy.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dhcp6 and fqdn support (for dns)
On 09/18/2012 04:17 PM, Dan Williams wrote: On Tue, 2012-09-18 at 14:59 -0400, Gene Czarcinski wrote: On 09/18/2012 02:22 PM, Dan Williams wrote: On Tue, 2012-09-18 at 13:08 -0500, Dan Williams wrote: On Tue, 2012-09-18 at 13:19 -0400, Gene Czarcinski wrote: On 09/17/2012 02:36 PM, Gene Czarcinski wrote: On 09/17/2012 02:24 PM, Gene Czarcinski wrote: On 09/17/2012 12:05 PM, Jiri Popelka wrote: On 09/16/2012 09:55 PM, Gene Czarcinski wrote: BTW, from the info in the dhcp-options man-page, I believe that NetworkManager should be doing "send fqdn.fqdn" instead of "send host-name" for IPv4. This should be with a plain name ... not a qualified name. See the man-page. The story behind this is https://bugzilla.redhat.com/show_bug.cgi?id=694758#c20 (NetworkManager) https://bugzilla.redhat.com/show_bug.cgi?id=697877 (initscripts) OK, bug or feature? Well, me and the original reporter of those bugs had suggested to "send fqdn.fqdn" when $(hostname) was FQDN and "send host-name" otherwise, but Bill Nottingham (initscripts) decided to always "send host-name". So I thought it would be better for NM to stay consistent with initscripts. Read those BZs and if you think the behavior is wrong you could try to re-open them. I have not gone back to look into the history of what should or should not be sent. I only looked at what is said in the current (Fedora 17, dhcp-common-4.2.4-9.P1.fc17) dhcp-options man page. option fqdn.fqdn text; Specifies the domain name that the client wishes to use. This can be a fully-qualified domain name, or a single label. If there is no trailing ´.´ character in the name, it is not fully-qualified, and the server will generally update that name in some locally-defined domain. --- It also says that "options fqdn.hostname" and "option fqdn.domainname" should never be set. When I got things to work, there was a lot of options in the lease file in addition to fqdn. I am not sure exactly what needs to be specified except that for IPv6 if I specify "-F " on the dhclient command line, things work. For IPv7 "-H " seems to work. Regardless, as things now work I do not get dynamic dns update for IPv6 (works fine for IPv4). This has been with dnsmasq as the dns and dhcp server. I am not setting up testing on qemu/kvm/libvirt with a guest running named and dhcpd instead of dnsmasq. My expectation is that it will not do dynamic dns either. My reason for pushing this is that while using radvd to help with IPv6 address assignment works for a client-only situation, it soon falls apart when I have a bunch of systems referring to each other. For IPv4 using addresses only is painful, for IPv6 it is impractical. I believe that such situations will needs either a IPv6 dhcpd with DDNS to named or a dnsmasq. I do not know, there might be other packages out there but these seem to be common. https://bugzilla.gnome.org/show_bug.cgi?id=684242 I have duplicated the situation but instead of using dnsmasq for dns and dhcp services. I installed and configured named, dhcpd, and dhcpd6 on the server an started them. On the client, disable networking and stop the NettworkManager.service. Again, the small change in the ifup-eth network script to use "-F" instead of "-H" and on dhclient commandline for "-6" and "ifup eth0" works its magic. "host " now provides both IPv6 and IPv4 addresses. ISTR the problem here is that since you can't use -H and -F together, you have to pick one or the other. And how do you make that choice? Is it another checkbox in the UI that nobody should ever really have to click? Does the DHCP server not have a configuration option to handle DDNS using the 'send host-name' bits? THe manpage for dhclient says "the server will append the ddns-domainname or domain-name options, if any, to derive the fully qualified domain name of the client" but while that talks about DDNS, it's unclear whether that does any DDNS stuff. Ok, I see what's going on now. The ISC DHCP client has two modes: "adhoc" and "draft". The "adhoc" mode is now deprecated and apparently doesn't work with failover, while the "draft" mode is preferred. The "adhoc" mode used the hostname + a config option to construct the DDNS name, while the "draft" mode uses the FQDN and is preferred. So the question becomes: is anyone actually using the old "adhoc" mode, and would we break anyone by moving to using the FQDN option instead? That's the big question here. Plus, we're not just talking about the ISC DHCP client, we need to figure out what happens with (a) MS DHCP/DNS and (b) WiFi routers with built-in DDNS functionality. Couple of things to consider -- 1. You could make it a configuration option Right, but ideally we don't have to. More UI checkboxes isn't something anyone wants. Yes, it could be a config option underneath or something like that, not exposed in the UI, but ideally we find a solution that handles this and then we don't need another config
Re: Two WLANs with the same SSID but different connection names
2012/9/18 Alexander Karlstad > Hi > > I've added two WLANs to my list in NM, both with the same SSID (eduroam) > but I've given them different names, e.g. «eduaroam (foo)» and «eduroam > (bar)». In nm-applet, «eduroam» appears, but with a sub list which shows > both «eduroam (foo)» and «eduroam (bar)»[1][2][3]. > > Does the same happen if you remove autoconnect for both of them? Maybe NM always autoconnect to the first one. -- Marius ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Two WLANs with the same SSID but different connection names
Den 18. sep. 2012 19:21, skrev Dan Williams: Also, can you verify from /var/log/messages or /var/log/daemon.log (or wherever the syslog daemon facility goes) that NM is actually only ever activating the single connection even if you choose the other one? NM prints out exactly which connection it's starting in the logs. Weird enough, /var/log/syslog tells me that it uses the right connection with the right cridentials when I select it, but I still get the same IP, DNS servers and so on. Attaching excerpt from /var/log/syslog when connecting to the "different" networks in the list. BTW, is it possible to get nm-applet to somehow show me which of the two connections I'm connected to? There are no "check signs" or other visual signs next to the active connection in the eduroam list (as seen in [1]). [1]: http://ubuntuone.com/1T2nTxtAyYjoMD64XFwkSx -- Alexander Karlstad Sep 19 13:51:29 cosmo NetworkManager[6459]: (wlan0): disconnecting for new activation request. Sep 19 13:51:29 cosmo NetworkManager[6459]: (wlan0): device state change: activated -> disconnected (reason 'none') [100 30 0] Sep 19 13:51:29 cosmo NetworkManager[6459]: (wlan0): deactivating device (reason 'none') [0] Sep 19 13:51:29 cosmo NetworkManager[6459]: (wlan0): canceled DHCP transaction, DHCP client pid 11840 Sep 19 13:51:29 cosmo avahi-daemon[1169]: Withdrawing address record for fe80::8ea9:82ff:fe88:2f08 on wlan0. Sep 19 13:51:29 cosmo avahi-daemon[1169]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::8ea9:82ff:fe88:2f08. Sep 19 13:51:29 cosmo avahi-daemon[1169]: Interface wlan0.IPv6 no longer relevant for mDNS. Sep 19 13:51:29 cosmo kernel: [11660.406186] wlan0: deauthenticating from a8:b1:d4:23:d8:a0 by local choice (reason=3) Sep 19 13:51:29 cosmo dnsmasq[11843]: exiting on receipt of SIGTERM Sep 19 13:51:29 cosmo NetworkManager[6459]: DNS: starting dnsmasq... Sep 19 13:51:29 cosmo kernel: [11660.478576] cfg80211: All devices are disconnected, going to restore regulatory settings Sep 19 13:51:29 cosmo kernel: [11660.478592] cfg80211: Restoring regulatory settings Sep 19 13:51:29 cosmo kernel: [11660.478604] cfg80211: Calling CRDA to update world regulatory domain Sep 19 13:51:29 cosmo avahi-daemon[1169]: Withdrawing address record for *.*.94.157 on wlan0. Sep 19 13:51:29 cosmo avahi-daemon[1169]: Leaving mDNS multicast group on interface wlan0.IPv4 with address *.*.94.157. Sep 19 13:51:29 cosmo avahi-daemon[1169]: Interface wlan0.IPv4 no longer relevant for mDNS. Sep 19 13:51:29 cosmo wpa_supplicant[1289]: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3 Sep 19 13:51:29 cosmo NetworkManager[6459]: (wlan0): writing resolv.conf to /sbin/resolvconf Sep 19 13:51:29 cosmo dnsmasq[12092]: started, version 2.59 cache disabled Sep 19 13:51:29 cosmo dnsmasq[12092]: compile time options: IPv6 GNU-getopt DBus i18n DHCP TFTP conntrack IDN Sep 19 13:51:29 cosmo dnsmasq[12092]: warning: no upstream servers configured Sep 19 13:51:29 cosmo kernel: [11660.492403] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain Sep 19 13:51:29 cosmo kernel: [11660.492412] cfg80211: World regulatory domain updated: Sep 19 13:51:29 cosmo kernel: [11660.492416] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Sep 19 13:51:29 cosmo kernel: [11660.492422] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 2000 mBm) Sep 19 13:51:29 cosmo kernel: [11660.492427] cfg80211: (2457000 KHz - 2482000 KHz @ 2 KHz), (300 mBi, 2000 mBm) Sep 19 13:51:29 cosmo kernel: [11660.492432] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 2000 mBm) Sep 19 13:51:29 cosmo kernel: [11660.492438] cfg80211: (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 2000 mBm) Sep 19 13:51:29 cosmo kernel: [11660.492443] cfg80211: (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 2000 mBm) Sep 19 13:51:29 cosmo NetworkManager[6459]: Activation (wlan0) starting connection 'eduroam (bar)' Sep 19 13:51:29 cosmo dbus[1091]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper) Sep 19 13:51:29 cosmo NetworkManager[6459]: (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0] Sep 19 13:51:29 cosmo NetworkManager[6459]: Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Sep 19 13:51:29 cosmo NetworkManager[6459]: (wlan0): supplicant interface state: completed -> disconnected Sep 19 13:51:29 cosmo NetworkManager[6459]: Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Sep 19 13:51:29 cosmo NetworkManager[6459]: Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Sep 19 13:51:29 cosmo NetworkManager[6459]: Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Sep 19 13:51:29 cosmo NetworkManager[6459]: Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Sep 19 13:51:29 cosmo dbus[1091]: [system] Successfully activated ser
Re: Ad hoc mode via Dbus
Thank you very much Dan for your support,
I'll try that and I will keep you posted.
On Tue, Sep 18, 2012 at 5:53 PM, Dan Williams wrote:
> On Tue, 2012-09-18 at 16:21 +0200, ppulib...@libero.it wrote:
> >
> > nothing at all! this is exactly what one could do to figure it
> > out...if none diid it before and knows how to do it, which was my
> > question
>
> Some resources that may help you:
>
> Examples in many languages of communicating with NetworkManager via
> D-Bus or NM's helper libraries:
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples
>
> A description of the NM D-Bus API, which many of the examples use:
> http://projects.gnome.org/NetworkManager/developers/api/09/spec.html
>
> A description of the configuration that you'll use to create your adhoc
> connection:
>
> http://projects.gnome.org/NetworkManager/developers/api/09/ref-settings.html
>
> Essentially, you're creating a wifi connection just like :
>
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/add-system-wifi-connection.py
>
> except that's for 802.1x. You'll want to skip the 802.1x setting, and
> instead do something like:
>
> s_wifi = dbus.Dictionary({
> 'ssid': dbus.ByteArray("my adhoc"),
> 'mode': 'adhoc'})
>
> for an open network. If you want security, you're currently limited to
> WEP, because the kernel has bugs that cause WPA Ad-Hoc networks to fail,
> and WPA2 Ad-Hoc support in the kernel is limited, and you also need a
> supplicant built with CONFIG_RSN_IBSS.
>
> Dan
>
> > Il giorno martedì 18 settembre 2012, Derek Atkins ha scritto:
> > ppulib...@libero.it writes:
> >
> > > Derek,
> > >
> > > I know it uses DBus to communicate to NM!
> > > The problem is I need to code code the configuration of wifi
> > directly via
> > > network manager over the DBus interface. I was able to
> > configure it, but I
> > > wasn't able to set it to ad hoc mode.This task must be
> > automatically
> > > performed by my application without using any GUI. Was
> > anyone able to
> > > successfully code this task?
> > > Untill now I didn't find anyone who was able to do this so
> > I think the only
> > > way to do figure that out is to look into the source code of
> > the network
> > > manager..
> > >
> > > The problem is that while I can
> >
> > And what's wrong with looking at nm-applet to see how it does
> > it?
> >
> > -derek
> >
> > --
> >Derek Atkins, SB '93 MIT EE, SM '95 MIT Media
> > Laboratory
> >Member, MIT Student Information Processing Board
> > (SIPB)
> >URL: http://web.mit.edu/warlord/PP-ASEL-IA
> > N1NWH
> >warl...@mit.eduPGP key
> > available
> > ___
> > networkmanager-list mailing list
> > networkmanager-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
>
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
