Re: Missing SIM PIN dialog after nm update
On Mon, 2011-10-10 at 23:58 +0100, Sérgio Basto wrote: > > My modem is a HUAWEI E1550 and does reboot and always worked. Just > last > update on Fedora seems to break it. Sorry , seems that all work fine now , can reproduced the problem anymore, maybe I miss a reboot of laptop after update . Thanks, -- Sérgio M. B. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Trouble with ICS (was Re: Ad-hoc network: cannot ping other machine)
Thanks for pointing me to /var/log/messages. I saw an error regarding dnsmasq, and I remembered reading somewhere about conflicts between dnsmasq and NetworkManager. I had dnsmasq starting up at boot. I removed it from my boot process, and now I can create a ICS connection on my desktop computer. I also had to disable the ifnet plugin because it seems to screw pretty much everything up. Nothing except connecting to an infrastructure network seems to work with ifnet. There seems to be only one last hurdle to clear: I started up my laptop to connect to the network I created on my desktop, and it won't connect. On my laptop I tried changing the IPv4 settings to DHCP and link-local, but neither works. What could be preventing the connection here? On 10/10/11, Patrick McMunn wrote: > I rebooted and attempted to connect after reboot before connecting to > the internet. Here's the relevant parts of /var/log/messages > > (This line about Avahi was a bit earlier in the log, but I'm including > it in case it's relevant) > > Oct 10 20:49:07 localhost dbus[4111]: [system] Failed to activate > service 'org.freedesktop.Avahi': timed out > > > Oct 10 20:50:20 localhost NetworkManager[4128]: Activation > (wlan0) starting connection 'share' > Oct 10 20:50:20 localhost NetworkManager[4128]: (wlan0): device > state change: disconnected -> prepare (reason 'none') [30 40 0] > Oct 10 20:50:20 localhost NetworkManager[4128]: Activation > (wlan0) Stage 1 of 5 (Device Prepare) scheduled... > Oct 10 20:50:20 localhost NetworkManager[4128]: Activation > (wlan0) Stage 1 of 5 (Device Prepare) started... > Oct 10 20:50:20 localhost NetworkManager[4128]: Activation > (wlan0) Stage 2 of 5 (Device Configure) scheduled... > Oct 10 20:50:20 localhost NetworkManager[4128]: Activation > (wlan0) Stage 1 of 5 (Device Prepare) complete. > Oct 10 20:50:20 localhost NetworkManager[4128]: Activation > (wlan0) Stage 2 of 5 (Device Configure) starting... > Oct 10 20:50:20 localhost NetworkManager[4128]: (wlan0): device > state change: prepare -> config (reason 'none') [40 50 0] > Oct 10 20:50:20 localhost NetworkManager[4128]: Activation > (wlan0/wireless): connection 'share' requires no security. No secrets > needed. > Oct 10 20:50:20 localhost NetworkManager[4128]: Config: added > 'ssid' value 'share' > Oct 10 20:50:20 localhost NetworkManager[4128]: Config: added > 'mode' value '1' > Oct 10 20:50:20 localhost NetworkManager[4128]: Config: added > 'frequency' value '2457' > Oct 10 20:50:20 localhost NetworkManager[4128]: Config: added > 'key_mgmt' value 'NONE' > Oct 10 20:50:20 localhost NetworkManager[4128]: Activation > (wlan0) Stage 2 of 5 (Device Configure) complete. > Oct 10 20:50:20 localhost NetworkManager[4128]: Config: set > interface ap_scan to 2 > Oct 10 20:50:20 localhost kernel: [ 212.847047] b43-phy0: Loading > firmware version 478.104 (2008-07-01 00:50:23) > Oct 10 20:50:20 localhost kernel: [ 212.896155] wlan0: Trigger new > scan to find an IBSS to join > Oct 10 20:50:20 localhost NetworkManager[4128]: (wlan0): > supplicant interface state: inactive -> associating > Oct 10 20:50:25 localhost kernel: [ 218.004183] wlan0: Trigger new > scan to find an IBSS to join > Oct 10 20:50:29 localhost kernel: [ 222.008033] wlan0: Trigger new > scan to find an IBSS to join > Oct 10 20:50:30 localhost kernel: [ 223.090029] wlan0: no IPv6 routers > present > Oct 10 20:50:30 localhost kernel: [ 223.303136] wlan0: Creating new > IBSS network, BSSID aa:2e:d1:95:8d:23 > Oct 10 20:50:30 localhost NetworkManager[4128]: (wlan0): > supplicant interface state: associating -> completed > Oct 10 20:50:30 localhost NetworkManager[4128]: Activation > (wlan0/wireless) Stage 2 of 5 (Device Configure) successful. > Connected to wireless network 'share'. > Oct 10 20:50:30 localhost NetworkManager[4128]: Activation > (wlan0) Stage 3 of 5 (IP Configure Start) scheduled. > Oct 10 20:50:30 localhost NetworkManager[4128]: Activation > (wlan0) Stage 3 of 5 (IP Configure Start) started... > Oct 10 20:50:30 localhost NetworkManager[4128]: (wlan0): device > state change: config -> ip-config (reason 'none') [50 70 0] > Oct 10 20:50:30 localhost NetworkManager[4128]: Activation > (wlan0) Stage 4 of 5 (IP4 Configure Get) scheduled... > Oct 10 20:50:30 localhost NetworkManager[4128]: Activation > (wlan0) Stage 3 of 5 (IP Configure Start) complete. > Oct 10 20:50:30 localhost NetworkManager[4128]: Activation > (wlan0) Stage 4 of 5 (IP4 Configure Get) started... > Oct 10 20:50:30 localhost NetworkManager[4128]: Activation > (wlan0) Stage 5 of 5 (IP Configure Commit) scheduled... > Oct 10 20:50:30 localhost NetworkManager[4128]: Activation > (wlan0) Stage 4 of 5 (IP4 Configure Get) complete. > Oct 10 20:50:30 localhost NetworkManager[4128]: Activation > (wlan0) Stage 5 of 5 (IP Configure Commit) started... > Oct 10 20:50:31 localhost NetworkManager[4128]: (wlan0): > removing resolv.conf from /sbin/resolvconf > Oct 10 20:50:31 localhost Networ
Re: Porting KDE3 NetworkManager to 0.9
Em Monday 10 October 2011, Robert Xu escreveu: > On Mon, Oct 10, 2011 at 20:02, Lamarque V. Souza wrote: > > You can also look at how we implemented it in Plasma NM (KDE 4.x): > > git clone git://anongit.kde.org/networkmanagement (branch nm09) > > This is our agent backends/NetworkManager/nmdbussecretagent.cpp. > > Oh, thanks for this. I was looking for how KDE4 did it in hopes that I > could maybe backport some stuff. > > > We added a watcher for NetworkManager service, everytime NM appears on > > DBus the watcher triggers the agent registration. > > So, basically, it just idles in the panel waiting for NM? Yes. The agent's constructor sets up the watcher and afterwards calls the slot reponsable for registering the agent. If NM is running the registration succeeds and that is it. If NM is not running the registration fails, but whenever NM appears on the system bus the slot is called again and it registers the agent. This scheme also works when NM restarts. If you call the registration slot only on knetworkmanager start the agent will stop working when NM restarts. > > In Qt 4.x you create a QDBusInterface to NM's agent manager service and > > just call ->connection().registerObject(NM_DBUS_PATH_SECRET_AGENT, > > d->agent, QDBusConnection::ExportAllSlots). d->agent is the pointer to > > our dbus adaptor object, which is a child of our agent and connects the > > agent to the system bus. > > *notes* > > > Well, I have never programmed with qt3's dbus bindings :-/ I cannot help > > with this part. > > That's fine, I think I have a much better idea now. > Thanks so much! You are welcome. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Porting KDE3 NetworkManager to 0.9
On Mon, Oct 10, 2011 at 20:02, Lamarque V. Souza wrote: > > You can also look at how we implemented it in Plasma NM (KDE 4.x): > git clone git://anongit.kde.org/networkmanagement (branch nm09) > This is our agent backends/NetworkManager/nmdbussecretagent.cpp. Oh, thanks for this. I was looking for how KDE4 did it in hopes that I could maybe backport some stuff. > > > We added a watcher for NetworkManager service, everytime NM appears on DBus > the watcher triggers the agent registration. > So, basically, it just idles in the panel waiting for NM? > > In Qt 4.x you create a QDBusInterface to NM's agent manager service and just > call ->connection().registerObject(NM_DBUS_PATH_SECRET_AGENT, d->agent, > QDBusConnection::ExportAllSlots). d->agent is the pointer to our dbus > adaptor object, which is a child of our agent and connects the agent to the > system bus. > *notes* > > Well, I have never programmed with qt3's dbus bindings :-/ I cannot help > with this part. That's fine, I think I have a much better idea now. Thanks so much! -- later daze. :: Robert Xu :: rxu.lincomlinux.org :: protocol.by/rxu ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Porting KDE3 NetworkManager to 0.9
On Mon, Oct 10, 2011 at 17:48, Dan Williams wrote: > On Sat, 2011-10-08 at 14:15 -0400, Robert Xu wrote: >> Hi all, >> >> Given the fact that I am relatively new at this stuff, forgive me if I >> am asking very noobish questions... >> >> I am trying to figure out how to implement the Register/Unregister >> functions and the SecretAgent interfaces. > > http://projects.gnome.org/NetworkManager/developers/api/09/ref-migrating.html > > has more information on the architecture changes in 0.9. One big one is > that the session applets (knetworkmanager, nm-applet, etc) no longer > store whole connections; they only store secrets. Thus they become > secret agents instead of full settings storage services. They no longer > need to advertise a D-Bus service. > >> - Where would I implement Register/Unregister? When the program starts >> up/closes down? > > Yes, whenever the thing that's going to respond to secrets requests (ie, > the secret agent) starts up and shuts down. So at program start/end... > >> - (what c++ call do I make to do that? >>;) > > Probably the Qt D-Bus bindings, which I think is what the old KDE stuff used. > >> - For SecretAgent interfaces, KNetworkManager has a storage file that >> handles this stuff. Should this all be depreciated for NM's new >> handling? > > Not necessarily; you'd still need to store secrets somewhere, and the > storage files are probably as good as any. But you wont' need to store > whole connections; just secrets. So at a minimum you'll need to store > the secret itself, the key name of the secret (ie 'psk' or 'password' or > whatever), and the UUID of the connection the secret is for. So the old storage backend just has to be modified to store secrets instead of connections... > >> - (again, how do you call the functions in c++? relatively new to >> dbus calling in c++ >>;) > > Usually with Qt/KDE you'd use the Qt D-Bus bindings to do anything D-Bus > related. Unfortunately I don't know much about those, but others on > this list (like Will Stephenson and Eckhart Woerner) know the Qt/KDE > side of things. > Ok, thanks! -- later daze. :: Robert Xu :: rxu.lincomlinux.org :: protocol.by/rxu ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ad-hoc network: cannot ping other machine
I rebooted and attempted to connect after reboot before connecting to the internet. Here's the relevant parts of /var/log/messages (This line about Avahi was a bit earlier in the log, but I'm including it in case it's relevant) Oct 10 20:49:07 localhost dbus[4111]: [system] Failed to activate service 'org.freedesktop.Avahi': timed out Oct 10 20:50:20 localhost NetworkManager[4128]: Activation (wlan0) starting connection 'share' Oct 10 20:50:20 localhost NetworkManager[4128]: (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0] Oct 10 20:50:20 localhost NetworkManager[4128]: Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Oct 10 20:50:20 localhost NetworkManager[4128]: Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Oct 10 20:50:20 localhost NetworkManager[4128]: Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Oct 10 20:50:20 localhost NetworkManager[4128]: Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Oct 10 20:50:20 localhost NetworkManager[4128]: Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Oct 10 20:50:20 localhost NetworkManager[4128]: (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] Oct 10 20:50:20 localhost NetworkManager[4128]: Activation (wlan0/wireless): connection 'share' requires no security. No secrets needed. Oct 10 20:50:20 localhost NetworkManager[4128]: Config: added 'ssid' value 'share' Oct 10 20:50:20 localhost NetworkManager[4128]: Config: added 'mode' value '1' Oct 10 20:50:20 localhost NetworkManager[4128]: Config: added 'frequency' value '2457' Oct 10 20:50:20 localhost NetworkManager[4128]: Config: added 'key_mgmt' value 'NONE' Oct 10 20:50:20 localhost NetworkManager[4128]: Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Oct 10 20:50:20 localhost NetworkManager[4128]: Config: set interface ap_scan to 2 Oct 10 20:50:20 localhost kernel: [ 212.847047] b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23) Oct 10 20:50:20 localhost kernel: [ 212.896155] wlan0: Trigger new scan to find an IBSS to join Oct 10 20:50:20 localhost NetworkManager[4128]: (wlan0): supplicant interface state: inactive -> associating Oct 10 20:50:25 localhost kernel: [ 218.004183] wlan0: Trigger new scan to find an IBSS to join Oct 10 20:50:29 localhost kernel: [ 222.008033] wlan0: Trigger new scan to find an IBSS to join Oct 10 20:50:30 localhost kernel: [ 223.090029] wlan0: no IPv6 routers present Oct 10 20:50:30 localhost kernel: [ 223.303136] wlan0: Creating new IBSS network, BSSID aa:2e:d1:95:8d:23 Oct 10 20:50:30 localhost NetworkManager[4128]: (wlan0): supplicant interface state: associating -> completed Oct 10 20:50:30 localhost NetworkManager[4128]: Activation (wlan0/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'share'. Oct 10 20:50:30 localhost NetworkManager[4128]: Activation (wlan0) Stage 3 of 5 (IP Configure Start) scheduled. Oct 10 20:50:30 localhost NetworkManager[4128]: Activation (wlan0) Stage 3 of 5 (IP Configure Start) started... Oct 10 20:50:30 localhost NetworkManager[4128]: (wlan0): device state change: config -> ip-config (reason 'none') [50 70 0] Oct 10 20:50:30 localhost NetworkManager[4128]: Activation (wlan0) Stage 4 of 5 (IP4 Configure Get) scheduled... Oct 10 20:50:30 localhost NetworkManager[4128]: Activation (wlan0) Stage 3 of 5 (IP Configure Start) complete. Oct 10 20:50:30 localhost NetworkManager[4128]: Activation (wlan0) Stage 4 of 5 (IP4 Configure Get) started... Oct 10 20:50:30 localhost NetworkManager[4128]: Activation (wlan0) Stage 5 of 5 (IP Configure Commit) scheduled... Oct 10 20:50:30 localhost NetworkManager[4128]: Activation (wlan0) Stage 4 of 5 (IP4 Configure Get) complete. Oct 10 20:50:30 localhost NetworkManager[4128]: Activation (wlan0) Stage 5 of 5 (IP Configure Commit) started... Oct 10 20:50:31 localhost NetworkManager[4128]: (wlan0): removing resolv.conf from /sbin/resolvconf Oct 10 20:50:31 localhost NetworkManager[4128]: Clearing nscd hosts cache. Oct 10 20:50:32 localhost NetworkManager[4128]: Executing: /sbin/iptables --table filter --insert INPUT --in-interface wlan0 --protocol tcp --destination-port 53 --jump ACCEPT Oct 10 20:50:32 localhost NetworkManager[4128]: Executing: /sbin/iptables --table filter --insert INPUT --in-interface wlan0 --protocol udp --destination-port 53 --jump ACCEPT Oct 10 20:50:32 localhost NetworkManager[4128]: Executing: /sbin/iptables --table filter --insert INPUT --in-interface wlan0 --protocol tcp --destination-port 67 --jump ACCEPT Oct 10 20:50:32 localhost NetworkManager[4128]: Executing: /sbin/iptables --table filter --insert INPUT --in-interface wlan0 --protocol udp --destination-port 67 --jump ACCEPT Oct 10 20:50:32 localhost NetworkManager[4128]: Executing: /sbin/iptables --table filter --insert FORWARD --in-interface wlan0 --jump REJECT Oct 10 20:50:32 localhost NetworkManager[4128]: Execut
Re: ModemManager: CDMA SMS and Phone support for Huawei plugin
On Mon, 2011-10-10 at 19:23 +0800, Heiher wrote: > Hello, > > This is lastest patches. One that concerns me is the changes to the serial port flags. Any idea why those changes are required? That has the potential to break a lot of existing modems. Are the SMS returned from the modem in plaintext, or encoded? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Networkmanager overwrites /etc/resolv.conf
On Mon, 2011-10-10 at 20:35 -0500, Patrick McMunn wrote: > I have NetworkManager compiled with support for OpenResolv. I use KPPP > to connect to the internet. For some reason, KPPP doesn't update Is this for a 3G modem? If so, NM won't overwrite stuff if you're controlling that modem with ModemManager. The problem is that there's no canonical source for resolv.conf. resolv.conf is really a composite of the DNS information from a number of different sources and thus if you have multiple things trying to update it, there's a lot of room to go wrong. You really need one thing. That one thing is usually NM when NM is running, but sometimes people stick things underneath, like openresolv or resolvconf. These sometimes cause more problems, but NM does try to work with them. First off, you need to make sure that you've built NM with resolvconf/openresolv support by passing --with-resolvconf=[yes|no| path-to-binary] and then NM will funnel it's composite configs to whatever resolvconf implementation you're using. Dan > /etc/resolv.conf with DNS info when it connects (I reported a bug 2 > years ago and it still hasn't been resolved). So in order to connect > to the internet and browse, I have my /etc/resolvconf.conf set up as > follows: > > name_servers="127.0.0.1 64.136.173.5 64.136.164.77" > > And when I connect to the internet /etc/resolv.conf is updated with > the info in /etc/resolvconf.conf. But if I disable networking in > NetworkManager then reenable it, or if I try to activate a wireless > network (I don't know it this also holds true for wired networks, > since I can't test that) while I'm connected to the internet, > NetworkManager overwrites /etc/resolv.conf and the only line in it is: > > # Generated by NetworkManager > > So I have to either redial my internet connection or manually edit > /etc/resolv.conf to add my DNS server info in order to continue > browsing. > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Networkmanager overwrites /etc/resolv.conf
I have NetworkManager compiled with support for OpenResolv. I use KPPP to connect to the internet. For some reason, KPPP doesn't update /etc/resolv.conf with DNS info when it connects (I reported a bug 2 years ago and it still hasn't been resolved). So in order to connect to the internet and browse, I have my /etc/resolvconf.conf set up as follows: name_servers="127.0.0.1 64.136.173.5 64.136.164.77" And when I connect to the internet /etc/resolv.conf is updated with the info in /etc/resolvconf.conf. But if I disable networking in NetworkManager then reenable it, or if I try to activate a wireless network (I don't know it this also holds true for wired networks, since I can't test that) while I'm connected to the internet, NetworkManager overwrites /etc/resolv.conf and the only line in it is: # Generated by NetworkManager So I have to either redial my internet connection or manually edit /etc/resolv.conf to add my DNS server info in order to continue browsing. -- Patrick McMunn - Learn more about the Catholic Faith: http://www.catholic.com/ - Pray with the Church: http://www.universalis.com/ ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ad-hoc network: cannot ping other machine
On Mon, 2011-10-10 at 20:15 -0500, Patrick McMunn wrote: > I was just excited to successfully create an ad-hoc network between > two Linux machines at all, even if ICS wasn't enabled. It is so easy > with Windows. Wireless networking with Linux has been a headache for > me. It should be painless on Linux, but sometimes stuff gets in the way :( > But anyway, I tried creating an internet connection sharing setup, and > NetworkManager will not connect to the network I'm trying to create. > Here's the setup: > > [Wireless] > SSID: share > Mode: Ad-hoc > Band: b/g > Channel: 10 > BSSID: > Restrict to Interface: Any > Cloned MAC Address: > MTU: Automatic Looks fine. > [Wireless Security] > Security: None > > [IPv4 Address] > Method: Shared > "IPv4 is required for this connection" checkbox is selected > > [IPv6 Address] > Method: Disabled > > /etc/NetworkManager/nm-system-settings.conf > [main] > plugins=ifnet,keyfile > > [ifnet] > managed=true > auto_refresh=false > > Fortunately, the created connection appears in the GUI (there is often > a problem with created connections not appearing in the GUI), and I > click on it. The status says "Configuring interface" for a few seconds > then "Setting network address for just a moment" and then goes back to > "Not connected." > > To try to get some feedback, I ran dmesg. The first time shows: > [ 133.491149] wlan0: Trigger new scan to find an IBSS to join > [ 137.008034] wlan0: Trigger new scan to find an IBSS to join > [ 141.008084] wlan0: Trigger new scan to find an IBSS to join > [ 142.299155] wlan0: Creating new IBSS network, BSSID 12:e3:2c:72:57:15 > [ 144.242036] wlan0: no IPv6 routers present NM dumps it's output to syslog's daemon facility, so can you paste in the relevant parts of /var/log/messages or /var/log/daemon.log? Dan > Subsequent attempts have the same message but omit "no IPv6 routers > present" and a different BSSID. > > I also ran avahi-daemon from a root console and tried to connect. Upon > starting it, I get > localhost patrick # avahi-daemon > Process 5268 died: No such process; trying to remove PID file. > (/var/run/avahi-daemon//pid) > Found user 'avahi' (UID 103) and group 'avahi' (GID 1009). > Successfully dropped root privileges. > avahi-daemon 0.6.30 starting up. > Successfully called chroot(). > Successfully dropped remaining capabilities. > Loading service file /services/sftp-ssh.service. > Loading service file /services/ssh.service. > System host name is set to 'localhost'. This is not a suitable mDNS > host name, looking for alternatives. > Joining mDNS multicast group on interface wlan0.IPv6 with address > fe80::211:50ff:fef5:592f. > New relevant interface wlan0.IPv6 for mDNS. > Joining mDNS multicast group on interface eth0.IPv6 with address > fe80::211:95ff:fefd:cbd9. > New relevant interface eth0.IPv6 for mDNS. > Network interface enumeration completed. > Registering new address record for fe80::211:50ff:fef5:592f on wlan0.*. > Registering new address record for fe80::211:95ff:fefd:cbd9 on eth0.*. > Registering HINFO record with values 'I686'/'LINUX'. > Server startup complete. Host name is linux.local. Local service > cookie is 3616907344. > Service "linux" (/services/ssh.service) successfully established. > Service "linux" (/services/sftp-ssh.service) successfully established. > > Then after attempting to create the ICS network avahi-daemon reports: > Joining mDNS multicast group on interface wlan0.IPv4 with address 10.42.43.1. > New relevant interface wlan0.IPv4 for mDNS. > Registering new address record for 10.42.43.1 on wlan0.IPv4. > Withdrawing address record for 10.42.43.1 on wlan0. > Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.42.43.1. > Interface wlan0.IPv4 no longer relevant for mDNS. > > Why is it that when I create a normal ad-hoc network, it creates an IP > address of 169.254.x.x but always tries to create an IP of 10.42.43.1 > when attempting ICS? Could that be part of the problem? > > Anyway, I hope this helps. If you can get ICS working for me I could kiss you. > > P.S. I'm currently running kernel 3.0.6 and I'm using dhcpcd with > zeroconf support through Avahi enabled. My wireless card in the > desktop in a Belkin PCI card with a Broadcom 4318 chipset. I'm using > the kernel's b43 driver with Broadcom's wl firmware. > > On 10/10/11, Dan Williams wrote: > > On Sat, 2011-10-08 at 23:54 -0500, Patrick McMunn wrote: > >> I just wanted to let anyone who runs across this know that I was able > >> to resolve the issue. I checked the output of dmesg on the laptop, and > >> I saw a message "disassociating by local choice (reason=3)" After > >> doing a Google search and finding this was a widely reported problem, > >> some of the proposed solutions included disabling power management on > >> the laptop's wifi card, disabling wpa_supplicant, and changing the > >> channel the connection is using. I was unable to disable > >> wpa_supplicant. If I killed the process, it respaw
Re: Missing SIM PIN dialog after nm update
On Mon, 2011-10-10 at 23:58 +0100, Sérgio Basto wrote: > On Mon, 2011-10-10 at 16:26 -0500, Dan Williams wrote: > > So what's happening here is that you probably have an Ericsson modem, > > and those don't drop off the bus during suspend/resume, but they do > > reset their state, so ModemManager wakes up and thinks nothing > > happened > > (because MM doesn't listen to suspend/resume signals, and because the > > modem didn't disappear), yet the modem reset its internal state and > > now > > requires a SIM PIN again because it effectively rebooted. > > My modem is a HUAWEI E1550 and does reboot and always worked. Just last > update on Fedora seems to break it. > I have to review this because I got other problem on vpn connection to > my office ( but the problem was in the office) and decide downgrade, > with > yum downgrade NetworkManager\* ModemManager\* > which put NetworkManager on version > NetworkManager-0.8.999-2.git20110509.fc15.x86_64 ( from fedora base) Interesting; can you grab some modem-manager logs as described here: http://live.gnome.org/NetworkManager/Debugging under the "3G for NM 0.8 and 0.9" section for us? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Ad-hoc network: cannot ping other machine
I was just excited to successfully create an ad-hoc network between two Linux machines at all, even if ICS wasn't enabled. It is so easy with Windows. Wireless networking with Linux has been a headache for me. But anyway, I tried creating an internet connection sharing setup, and NetworkManager will not connect to the network I'm trying to create. Here's the setup: [Wireless] SSID: share Mode: Ad-hoc Band: b/g Channel: 10 BSSID: Restrict to Interface: Any Cloned MAC Address: MTU: Automatic [Wireless Security] Security: None [IPv4 Address] Method: Shared "IPv4 is required for this connection" checkbox is selected [IPv6 Address] Method: Disabled /etc/NetworkManager/nm-system-settings.conf [main] plugins=ifnet,keyfile [ifnet] managed=true auto_refresh=false Fortunately, the created connection appears in the GUI (there is often a problem with created connections not appearing in the GUI), and I click on it. The status says "Configuring interface" for a few seconds then "Setting network address for just a moment" and then goes back to "Not connected." To try to get some feedback, I ran dmesg. The first time shows: [ 133.491149] wlan0: Trigger new scan to find an IBSS to join [ 137.008034] wlan0: Trigger new scan to find an IBSS to join [ 141.008084] wlan0: Trigger new scan to find an IBSS to join [ 142.299155] wlan0: Creating new IBSS network, BSSID 12:e3:2c:72:57:15 [ 144.242036] wlan0: no IPv6 routers present Subsequent attempts have the same message but omit "no IPv6 routers present" and a different BSSID. I also ran avahi-daemon from a root console and tried to connect. Upon starting it, I get localhost patrick # avahi-daemon Process 5268 died: No such process; trying to remove PID file. (/var/run/avahi-daemon//pid) Found user 'avahi' (UID 103) and group 'avahi' (GID 1009). Successfully dropped root privileges. avahi-daemon 0.6.30 starting up. Successfully called chroot(). Successfully dropped remaining capabilities. Loading service file /services/sftp-ssh.service. Loading service file /services/ssh.service. System host name is set to 'localhost'. This is not a suitable mDNS host name, looking for alternatives. Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::211:50ff:fef5:592f. New relevant interface wlan0.IPv6 for mDNS. Joining mDNS multicast group on interface eth0.IPv6 with address fe80::211:95ff:fefd:cbd9. New relevant interface eth0.IPv6 for mDNS. Network interface enumeration completed. Registering new address record for fe80::211:50ff:fef5:592f on wlan0.*. Registering new address record for fe80::211:95ff:fefd:cbd9 on eth0.*. Registering HINFO record with values 'I686'/'LINUX'. Server startup complete. Host name is linux.local. Local service cookie is 3616907344. Service "linux" (/services/ssh.service) successfully established. Service "linux" (/services/sftp-ssh.service) successfully established. Then after attempting to create the ICS network avahi-daemon reports: Joining mDNS multicast group on interface wlan0.IPv4 with address 10.42.43.1. New relevant interface wlan0.IPv4 for mDNS. Registering new address record for 10.42.43.1 on wlan0.IPv4. Withdrawing address record for 10.42.43.1 on wlan0. Leaving mDNS multicast group on interface wlan0.IPv4 with address 10.42.43.1. Interface wlan0.IPv4 no longer relevant for mDNS. Why is it that when I create a normal ad-hoc network, it creates an IP address of 169.254.x.x but always tries to create an IP of 10.42.43.1 when attempting ICS? Could that be part of the problem? Anyway, I hope this helps. If you can get ICS working for me I could kiss you. P.S. I'm currently running kernel 3.0.6 and I'm using dhcpcd with zeroconf support through Avahi enabled. My wireless card in the desktop in a Belkin PCI card with a Broadcom 4318 chipset. I'm using the kernel's b43 driver with Broadcom's wl firmware. On 10/10/11, Dan Williams wrote: > On Sat, 2011-10-08 at 23:54 -0500, Patrick McMunn wrote: >> I just wanted to let anyone who runs across this know that I was able >> to resolve the issue. I checked the output of dmesg on the laptop, and >> I saw a message "disassociating by local choice (reason=3)" After >> doing a Google search and finding this was a widely reported problem, >> some of the proposed solutions included disabling power management on >> the laptop's wifi card, disabling wpa_supplicant, and changing the >> channel the connection is using. I was unable to disable >> wpa_supplicant. If I killed the process, it respawned. If I >> uninstalled wpa_supplicant completely, NetworkManager refused to work >> at all. I ended up manually specifying the connection to use channel >> 10 as one person recommended, and voila! I was able to connect, and >> each machine was able to ping the other. Now if I can just get >> internet connection sharing working > > NM uses wpa_supplicant for wifi control, so yeah, you'd need it. WRT > channel 10 vs. channel 3, that's very interesting; it could be that the > driver for yo
Re: Porting KDE3 NetworkManager to 0.9
Em Monday 10 October 2011, Dan Williams escreveu: > On Sat, 2011-10-08 at 14:15 -0400, Robert Xu wrote: > > Hi all, > > > > Given the fact that I am relatively new at this stuff, forgive me if I > > am asking very noobish questions... > > > > I am trying to figure out how to implement the Register/Unregister > > functions and the SecretAgent interfaces. > > http://projects.gnome.org/NetworkManager/developers/api/09/ref-migrating.ht > ml > > has more information on the architecture changes in 0.9. One big one is > that the session applets (knetworkmanager, nm-applet, etc) no longer > store whole connections; they only store secrets. Thus they become > secret agents instead of full settings storage services. They no longer > need to advertise a D-Bus service. You can also look at how we implemented it in Plasma NM (KDE 4.x): git clone git://anongit.kde.org/networkmanagement (branch nm09) This is our agent backends/NetworkManager/nmdbussecretagent.cpp. > > - Where would I implement Register/Unregister? When the program starts > > up/closes down? > > Yes, whenever the thing that's going to respond to secrets requests (ie, > the secret agent) starts up and shuts down. We added a watcher for NetworkManager service, everytime NM appears on DBus the watcher triggers the agent registration. > > - (what c++ call do I make to do that? >>;) > > Probably the Qt D-Bus bindings, which I think is what the old KDE stuff > used. In Qt 4.x you create a QDBusInterface to NM's agent manager service and just call ->connection().registerObject(NM_DBUS_PATH_SECRET_AGENT, d->agent, QDBusConnection::ExportAllSlots). d->agent is the pointer to our dbus adaptor object, which is a child of our agent and connects the agent to the system bus. > > - For SecretAgent interfaces, KNetworkManager has a storage file that > > handles this stuff. Should this all be depreciated for NM's new > > handling? > > Not necessarily; you'd still need to store secrets somewhere, and the > storage files are probably as good as any. But you wont' need to store > whole connections; just secrets. So at a minimum you'll need to store > the secret itself, the key name of the secret (ie 'psk' or 'password' or > whatever), and the UUID of the connection the secret is for. In Plasma NM we allows to save secrets in kwallet or in plain text (text files). Kwallet is the default storage. This file implements our storage service: libs/service/secretstorage.cpp. > > - (again, how do you call the functions in c++? relatively new to > > > > dbus calling in c++ >>;) > > Usually with Qt/KDE you'd use the Qt D-Bus bindings to do anything D-Bus > related. Unfortunately I don't know much about those, but others on > this list (like Will Stephenson and Eckhart Woerner) know the Qt/KDE > side of things. Well, I have never programmed with qt3's dbus bindings :-/ I cannot help with this part. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Missing SIM PIN dialog after nm update
On Mon, 2011-10-10 at 16:26 -0500, Dan Williams wrote: > So what's happening here is that you probably have an Ericsson modem, > and those don't drop off the bus during suspend/resume, but they do > reset their state, so ModemManager wakes up and thinks nothing > happened > (because MM doesn't listen to suspend/resume signals, and because the > modem didn't disappear), yet the modem reset its internal state and > now > requires a SIM PIN again because it effectively rebooted. My modem is a HUAWEI E1550 and does reboot and always worked. Just last update on Fedora seems to break it. I have to review this because I got other problem on vpn connection to my office ( but the problem was in the office) and decide downgrade, with yum downgrade NetworkManager\* ModemManager\* which put NetworkManager on version NetworkManager-0.8.999-2.git20110509.fc15.x86_64 ( from fedora base) which don't have this problem. I have to update again and do a clean reboot to test it and certify that something happened on last version. Thanks, -- Sérgio M. B. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.9 asks for PK auth without need
On Fri, 2011-10-07 at 15:43 +0200, Ludwig Nussel wrote: > Ludwig Nussel wrote: > > 802.11x connections that are configured to always prompt for the > > password also always require polkit authentication (bgo#646187). So the PK stuff is a mix of permissions and historic configuration. First off, network configuration is potentially a privileged operation since you have a lot of power to screw up the machine. But storing your WPA PSK in your user session doesn't make a ton of sense since it's required by everyone who connects to the network. In contrast to a VPN password or a EAP password, which are specific to your user, not to the machine (typically). Windows and Mac OS X both make WiFi PSK networks system-wide, so NM's previous behavior also didn't match up with common expectations. But of course, to create a system-wide WiFi network, you need to be able to edit system config files, so that means we should require some permission to create the network and to request the password when showing a UI. Perhaps that's why Windows never shows you the password again after the initial connection :) So when creating a new wifi network, you first need to authenticate to create the network in the first place. That gets creating without the PSK since the applet doesn't necessarily want to include a ton of complex code that checks what specific passwords might be required. Instead, it waits for NM to ask the applet what is required. Then the applet throws up a dialog, but since users want to see any old passwords (since this case is no different than the "password is wrong" case) another request is triggered to read the secrets so we can populate the UI with the old key. Of course it's a new network, so that key isn't there yet. But there's no way to know that without requesting it, really. Obviously the secret could be stored in the user session and be visible to the creating user only; but that kills the feature of system-wide connections by default, which should be doing for most network types (excluding VPN and possibly 3G). That's essentially what 0.8 and earlier did, and we had reasonable requests to change that. The question has been asked before of why we don't just let people have system config permission by default in 0.9. That's because there might be old connections that were created before when users didn't have system config permission by default, and it seems somewhat insecure to suddenly allow access to those previously protected connections on an upgrade. There are probably ways to reduce the PK spammage, and I hope there are, and I'm very interested in figuring out how we can do that. But this also could be handled better at the PolicyKit level; perhaps we should simply default to auth_admin_keep or auth_self_keep? That should kill the need for the second dialog, I think. Does that make a difference in the usability? Dan > Here's a potentially embarrassing patch to fix or rather work around > the issue. Improvements welcome, I don't really know the first thing > about NM :-) > > After struggling with the code for some hours I think there are > several problems that make this situation complicated to fix though: > - NM does not know whether a secret is (intentionally) not in the > config file. It just looks at gobject properties that don't know > why they are at their default value. > - there doesn't seem to be a flag that tells NM whether a connection > is just being set up for the first time. Ie there is no need to > ask for auth again until the setup phase is complete. > - I wonder whether the general concept of suddenly prompting the > user for passwords/passphrases (with potential PK popup) after the > initial setup phase is a good idea. It might be better and less > annoying to simply fail the connection attempt and require the > user to manually use the edit dialog. > > cu > Ludwig > > ___ > 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
Re: Ad-hoc network: cannot ping other machine
On Sat, 2011-10-08 at 23:54 -0500, Patrick McMunn wrote: > I just wanted to let anyone who runs across this know that I was able > to resolve the issue. I checked the output of dmesg on the laptop, and > I saw a message "disassociating by local choice (reason=3)" After > doing a Google search and finding this was a widely reported problem, > some of the proposed solutions included disabling power management on > the laptop's wifi card, disabling wpa_supplicant, and changing the > channel the connection is using. I was unable to disable > wpa_supplicant. If I killed the process, it respawned. If I > uninstalled wpa_supplicant completely, NetworkManager refused to work > at all. I ended up manually specifying the connection to use channel > 10 as one person recommended, and voila! I was able to connect, and > each machine was able to ping the other. Now if I can just get > internet connection sharing working NM uses wpa_supplicant for wifi control, so yeah, you'd need it. WRT channel 10 vs. channel 3, that's very interesting; it could be that the driver for your wifi card is somewhat stupid; I've noticed a lot of variability in the quality of Ad-Hoc mode support in kernel wifi drivers. For example, in certain kernel versions Ad-Hoc + WPA simply doesn't work. At all. But we'd do best to investigate deeper into the kernel driver here. Second, for ICS, you want to choose "Shared to other computers" as the IPv4 connection method in the Ad-Hoc network you're creating. If that's an option in the KDE network config (that appears to be what you're using...). The method "Link-Local" will only do Link-local, it won't start up ICS. Dan > On 10/8/11, Patrick McMunn wrote: > > I'm using NetworkManager 0.9.1.90 (just installed yesterday; I've been > > using 0.9.0 for a while) and KNetworkManager from git. I have never > > been able to get a working ad-hoc network between two Linux machines - > > only when I create it with Windows and connect to it with a Linux > > machine. > > > > Here's my setup in KNetworkManager: > > SSID: 1337 > > Mode: Ad-Hoc > > Band: b/g > > Channel: 3 > > BSSID: > > Restrict to Interface: Any > > Cloned MAC Address: > > MTU: Automatic > > > > IPv4 Address: Link-Local > > IPv6 Address: disabled > > > > results of route from command line of desktop computer > > > > Kerne IP routing table > > Destination Gateway Genmask Flags Metric Ref > > Use Iface > > loopback* 255.0.0.0 U 0 00 lo > > link-local * 255.255.0.0 U 2 00 > > wlan0 > > 224.0.0.0 * 240.0.0.0 U 0 00 > > wlan0 > > > > Settings are the same on desktop and laptop computers. Link-Local is > > the only setting that will work at all under IPv4 settings. DHCP > > results: attempts to connect but fails. I have dhcpcd set to fallback > > to zeroconf, but that doesn't work with NM. I haven't had any luck > > with static IPs either. > > > > When using Link-Local, however, I can connect to the network easily. > > Then I can walk over to my laptop, use KNetworkManager's scan feature > > and identify the essid I created on the desktop. I have to change IPv4 > > settings to Link-Local, but everything else is usually identified > > correctly. Then I save and can connect - apparently. If I look at the > > network usage statistics of KNetworkManager, the graph indicates > > network activity for a few moments at the time I attempt to join the > > network, but then it goes back to zero never to do anything else. I > > cannot ping either machine from the other. I have tried this with no > > encryption at all for troubleshooting and with WPA Personal just to > > see what would happen - both with the exact same results (when I tried > > encryption, it even asked for my passphrase before connecting, so that > > seemed to work). > > > > Once I get this solved, I want to be able to share internet connection > > over wifi. > > > > Any ideas what's wrong? > > > > -- > > Patrick McMunn > > > > - Learn more about the Catholic Faith: http://www.catholic.com/ > > - Pray with the Church: http://www.universalis.com/ > ___ > 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
Re: [PATCH] set a destination for the IPv6 default gateway
On Fri, 2011-10-07 at 15:31 -0400, Mathieu Trudel-Lapierre wrote: > Hi, > > The attached patch appears to be required for setting the default > gateway for IPv6 with libnl3 (tested with libnl3 3.0). It comes with a > small fix to catch the return code for nm_netlink_route_add() so > success is correctly reported as such (or to get the "right" error > message). Was this the one that turned out to be a bug in libnl3? Or is it still applicable? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Support for direct connection without cross cable
On Sat, 2011-10-08 at 21:18 +0700, Arief M Utama wrote: > Hi all, > > > I'm just wondering, and might as well send the message on the list, in > case someone has more ideas. > > On recent windows, with recent network cards, I noticed (on a couple > laptops) that windows can setup networking to a direct-connected to > another device (tested couple of times with network-drives, such as WD > MyBook World) with simple straight forward ethernet cable. No crossing > needed. > > I'm wondering if NM (or linux?) can support this as well? Most network cards have supported direct vs. crossover detection for a while, so that shouldn't be a problem. What likely happens here is that when DHCP fails, the OS assigns a IPv4 Link-Local address, which presumably the network drive also does, and they can talk on a LL network. We used to have automatic functionality like that in NM, but people got really confused as to why NM said they were connected to the Internet when they really weren't. But that was long ago and we could probably figure out a better behavior here. As in, really, this should only happen on wired networks, and even after assigning a LL address we should periodically retry DHCP just in case you're connected to a real network but the DHCP server went down for 5 minutes. Something like that. But currently it's not automatic since doing this breaks a bunch of other use-cases. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Porting KDE3 NetworkManager to 0.9
On Sat, 2011-10-08 at 14:15 -0400, Robert Xu wrote: > Hi all, > > Given the fact that I am relatively new at this stuff, forgive me if I > am asking very noobish questions... > > I am trying to figure out how to implement the Register/Unregister > functions and the SecretAgent interfaces. http://projects.gnome.org/NetworkManager/developers/api/09/ref-migrating.html has more information on the architecture changes in 0.9. One big one is that the session applets (knetworkmanager, nm-applet, etc) no longer store whole connections; they only store secrets. Thus they become secret agents instead of full settings storage services. They no longer need to advertise a D-Bus service. > - Where would I implement Register/Unregister? When the program starts > up/closes down? Yes, whenever the thing that's going to respond to secrets requests (ie, the secret agent) starts up and shuts down. > - (what c++ call do I make to do that? >>;) Probably the Qt D-Bus bindings, which I think is what the old KDE stuff used. > - For SecretAgent interfaces, KNetworkManager has a storage file that > handles this stuff. Should this all be depreciated for NM's new > handling? Not necessarily; you'd still need to store secrets somewhere, and the storage files are probably as good as any. But you wont' need to store whole connections; just secrets. So at a minimum you'll need to store the secret itself, the key name of the secret (ie 'psk' or 'password' or whatever), and the UUID of the connection the secret is for. > - (again, how do you call the functions in c++? relatively new to > dbus calling in c++ >>;) Usually with Qt/KDE you'd use the Qt D-Bus bindings to do anything D-Bus related. Unfortunately I don't know much about those, but others on this list (like Will Stephenson and Eckhart Woerner) know the Qt/KDE side of things. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] add an ip6_manager object for the IPv6 Manual setting case
On Mon, 2011-10-10 at 16:32 -0500, Dan Williams wrote: > On Fri, 2011-10-07 at 16:50 -0400, Mathieu Trudel-Lapierre wrote: > > This is so the routes added in this case can be torn down by > > ...flush_routes() in nm_device_deactivate(). Without an ip6_manager > > object, only the IPv4 routes are considered (AF_INET is passed for > > family instead of AF_UNSPEC). > > Instead, could we check for (priv->ip6_manager || priv->ip6_config) in > nm_device_deactivate()? I just went ahead and did that for git master and 0.8.x using your name in the commit. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] add an ip6_manager object for the IPv6 Manual setting case
On Fri, 2011-10-07 at 16:50 -0400, Mathieu Trudel-Lapierre wrote: > This is so the routes added in this case can be torn down by > ...flush_routes() in nm_device_deactivate(). Without an ip6_manager > object, only the IPv4 routes are considered (AF_INET is passed for > family instead of AF_UNSPEC). Instead, could we check for (priv->ip6_manager || priv->ip6_config) in nm_device_deactivate()? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm_setting_gsm_get_pin() retuns null
On Sun, 2011-10-09 at 17:28 +0200, Anders Feder wrote:
> I now have the attached diff. Any chance you can help me understand why
> it segfaults when I try running it? Thanks,
Missing trailing G_TYPE_INVALID in gsm_device_added() on the GetAll call
will make dbus-glib overrun the end of the argument list. That's a
marker for the varargs list that tells dbus-glib it can stop processing
arguments. Not sure if that's it but should be fixed.
Any idea where it's crashing? can you get a backtrace when running the
applet in gdb?
Dan
> Anders Feder
>
> On 05-10-2011 23:35, Dan Williams wrote:
> > On Wed, 2011-10-05 at 23:21 +0200, Anders Feder wrote:
> >> Alternatively, can I simply request "SimIdentifier" from unlock_reply()
> >> instead of gsm_device_added()? That way sim_id_reply() won't be invoked
> >> unless unlock_reply() has already completed.
> > You could chain them together that way, yes, if you moved the stuff from
> > gsm_device_added() up into unlock_reply() where you get a successful
> > reply for DeviceIdentifier.
> >
> > Dan
> >
> >> Anders Feder
> >>
> >> On 05-10-2011 22:45, Dan Williams wrote:
> >>> On Wed, 2011-10-05 at 22:12 +0200, Anders Feder wrote:
> Thanks for that thorough explanation. However, I wonder if there isn't a
> race condition in that implementation: if we request all three
> properties in gsm_device_added(), can we be certain that we have all of
> them once we are in sim_id_reply()? Isn't there a risk that
> sim_id_reply() might be called back before unlock_reply()?
> >>> Yes, a small risk. This can be alleviated by doing some logic in both
> >>> functions and tracking in the 'info' struct whether we've gotten replies
> >>> for both the initial modem properties and the initial card properties,
> >>> and then only doing the unlock dialog when both of those are true AND
> >>> the other stuff I wrote was true, and doing that check from both places.
> >>> It just means more variables.
> >>>
> >>> Dan
> >>>
> Anders Feder
>
> On 03-10-2011 23:18, Dan Williams wrote:
> > On Mon, 2011-10-03 at 14:20 +0200, Anders Feder wrote:
> >> Where would you propose the new code be added?
> >>
> >> In the first iteration, I imagine it would work something like this:
> >>
> >> If (UnlockRequired)
> >> Get SimIdentifier
> >> If (SimIdentifier is found)
> >> Get PIN for SimIdentifier from keyring
> >> If (PIN is found for SimIdentifier)
> >> Try unlock using saved PIN
> >> While (unlock failed)
> >> Prompt user for new PIN
> >> Try unlock using new PIN
> >> If (unlock succeeded)
> >> Save new PIN for SimIdentifier to keyring
> >>
> >> If this works, a similar procedure could be applied for
> >> DeviceIdentifier, if SimIdentifier is not found.
> >>
> >> Is this the best approach?
> > Yeah, that's basically it. So UnlockRequired and DeviceIdentifier are
> > both properties of the org.freedesktop.ModemManager.Modem interface, and
> > thus you can retrieve them both in the same D-Bus properties call using
> > GetAll(). For that, in src/applet-device-gsm.c's gsm_device_added()
> > function, where it calls the Get() method with UnlockRequired, what you
> > want to do is call "GetAll" instead and kill the "UnlockRequired"
> > argument. Then in the unlock_reply() for the dbus_g_proxy_end_call()
> > you'll do something like:
> >
> > GHashTable *props = NULL;
> >
> > if (dbus_g_proxy_end_call (proxy, call,&error,
> > DBUS_TYPE_G_MAP_OF_VARIANT,&props,
> > G_TYPE_INVALID)) {
> >GHashTableIter iter;
> >const char *prop_name;
> >GValue *value;
> >
> >g_hash_table_iter_init (&iter, props);
> >while (g_hash_table_iter_next (&iter, (gpointer)&prop_name,
> > (gpointer)&value)) {
> >if ((strcmp (prop_name, "UnlockRequired") == 0)&&
> > G_VALUE_HOLDS_STRING (value)) {
> > g_free (info->unlock_required);
> >info->unlock_required = parse_unlock_required (value);
> >}
> >
> >if ((strcmp (prop_name, "DeviceIdentifier") == 0)&&
> > G_VALUE_HOLDS_STRING (value)) {
> >g_free (info->devid);
> >info->devid = g_value_dup_string (value);
> >}
> >}
> > }
> >
> > That takes care of the UnlockRequired and DeviceIdentifier properties.
> > Now you need to get the SimIdentifier property, which is a GSM-specific
> > property (unlike UnlockRequired and DeviceIdentifier which are provided
> > for CDMA devices too). For that you'll want to do something like this
> > in gsm_
Re: Missing SIM PIN dialog after nm update
On Mon, 2011-10-10 at 16:31 +0100, Sérgio Basto wrote: > Hi, > after read this messages I test my modem 3G. And works, after I suspend > e resume computer and try again, and no "SIM PIN dialog", but I don't > got modem detected . > I do > killall modem-manager > > Sfter some seconds modem was detected and "SIM PIN dialog" was > appears. So what's happening here is that you probably have an Ericsson modem, and those don't drop off the bus during suspend/resume, but they do reset their state, so ModemManager wakes up and thinks nothing happened (because MM doesn't listen to suspend/resume signals, and because the modem didn't disappear), yet the modem reset its internal state and now requires a SIM PIN again because it effectively rebooted. So we need to hook ModemManager into some mechanism (upower? udev?) to listen for wake events, mark the modem as disabled, and go through PIN check and reinitialization. Dan > > On Mon, 2011-10-10 at 12:00 +0200, Arne Caspari wrote: > > Hello list, > > > > I updated to GNOME 3.2 on Ubuntu 11.04 with the GNOME3 and > > ricotz-testing PPAs. NetworkManager now is at Version 0.9.1.90. Since > > the update, I no longer get a dialog requesting the PIN for my USB UMTS > > modem. The nm-applet menu lists a mobile broadband connection but if I > > select it, nothing happens. > > > > In /var/log/syslog the following line appears after selecting the > > connection: > > > > "NetworkManager[897]: failed to enable/disable modem: (32) SIM > > PIN required" > > > > I tried to enter the PIN maually in the nm-connection-editor but it > > does not get saved ( ie. the next time I open the dialog, there is no > > PIN entered ). > > > > Anybody got an idea what to do to get my UMTS modem working again? > > > > > > /Arne > > ___ > > 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
Re: Trouble using the dbus method GetDevices() with the glib library..
On Thu, 2011-10-06 at 20:02 +0100, Iraq Ja wrote:
> When I try to use the GetDevices() method using the glib library, I
> get the following error message:
>
>
> ** ERROR **: Error calling GetDevices: Unregistered object at path
> '/org/freedesktop/NetworkManager/Devices/0'
>
>
> I've attached the program that causes the error.
>
>
> I just want to make sure that this is a issue with the dbus-glib
> library, if so I'll report it.
It's not; I think its caused by poor documentation of the
DBUS_TYPE_G_OBJECT_ARRAY marshalling type. From a quick look at the
dbus-glib and dbus code, that looks like it only works from a *server*
program, because it uses dbus_connection_get_object_path_data() to find
objects registered with that path, but that dbus library function only
operates on objects that have been registered for export. So I don't
think it's what you want.
Instead, use dbus_g_type_get_collection ("GPtrArray",
DBUS_TYPE_G_OBJECT_PATH) instead, and you'll get a GPtrArray of "char *"
which you can then create your own DBusGProxys from.
Dan
>
> Any help/advice would be appreciated.
> ___
> 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
Re: [PATCH] fix stop condition of while loop
On Fri, 2011-10-07 at 15:21 +0200, Ludwig Nussel wrote:
> ---
> src/supplicant-manager/nm-supplicant-manager.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied, thanks. Stupid mistake on my part.
Dan
> diff --git a/src/supplicant-manager/nm-supplicant-manager.c
> b/src/supplicant-manager/nm-supplicant-manager.c
> index 0e9fc20..349f722 100644
> --- a/src/supplicant-manager/nm-supplicant-manager.c
> +++ b/src/supplicant-manager/nm-supplicant-manager.c
> @@ -140,7 +140,7 @@ get_eap_methods_reply (DBusGProxy *proxy,
> G_TYPE_INVALID)) {
> if (G_VALUE_HOLDS (&value, G_TYPE_STRV)) {
> iter = g_value_get_boxed (&value);
> - while (iter) {
> + while (iter && *iter) {
> if (strcasecmp (*iter++, "FAST") == 0) {
> priv->fast_supported = TRUE;
> break;
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] glib 2.30.0 doesn't have g_value_get_schar yet
On Fri, 2011-10-07 at 15:21 +0200, Ludwig Nussel wrote:
> ---
> libnm-util/nm-param-spec-specialized.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied, thanks.
Dan
> diff --git a/libnm-util/nm-param-spec-specialized.c
> b/libnm-util/nm-param-spec-specialized.c
> index f0ca1d9..7496cb6 100644
> --- a/libnm-util/nm-param-spec-specialized.c
> +++ b/libnm-util/nm-param-spec-specialized.c
> @@ -92,7 +92,7 @@ _gvalues_compare_fixed (const GValue *value1, const GValue
> *value2)
>
> switch (G_VALUE_TYPE (value1)) {
> case G_TYPE_CHAR: {
> -#if GLIB_CHECK_VERSION(2,29,90)
> +#if GLIB_CHECK_VERSION(2,30,1)
> gchar val1 = g_value_get_schar (value1);
> gchar val2 = g_value_get_schar (value2);
> #else
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] remove AP always on device disconnect
On Fri, 2011-10-07 at 15:21 +0200, Ludwig Nussel wrote:
> This avoids immediate reconnect after link timeout to an AP that may no
> longer exist (down/out of range). This also avoids needless prompting for a
> password for the no longer existing AP.
This could work, but I think we need to restrict the AP removal to cases
where the supplicant times out after we've already been successfully
connected, which is basically the case you're talking about. For
example, in the case of an explicit disconnect (via the menu item or
D-Bus call) we'd remove a perfectly good AP and might not find it again
until the next scan happened a few minutes after the disconnect.
Maybe instead of doing it during deactivate, remove the AP in
supplicant_connection_timeout_cb() right before moving to the
DISCONNECTED state?
Dan
> ---
> src/nm-device-wifi.c | 12 +++-
> 1 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/src/nm-device-wifi.c b/src/nm-device-wifi.c
> index 42080ae..e73ab92 100644
> --- a/src/nm-device-wifi.c
> +++ b/src/nm-device-wifi.c
> @@ -1285,15 +1285,9 @@ real_deactivate (NMDevice *dev)
> set_current_ap (self, NULL);
> priv->rate = 0;
>
> - /* If the AP is 'fake', i.e. it wasn't actually found from
> - * a scan but the user tried to connect to it manually (maybe it
> - * was non-broadcasting or something) get rid of it, because 'fake'
> - * APs should only live for as long as we're connected to them. Fixes
> - * a bug where user-created Ad-Hoc APs are never removed from the scan
> - * list, because scanning is disabled while in Ad-Hoc mode (for
> stability),
> - * and thus the AP culling never happens. (bgo #569241)
> - */
> - if (orig_ap && nm_ap_get_fake (orig_ap)) {
> + /* remove ap always. If it's still there it will re-appear on next
> + * scan. Avoids reconnect when is no longer available */
> + if (orig_ap /* && nm_ap_get_fake (orig_ap) */) {
> access_point_removed (self, orig_ap);
> priv->ap_list = g_slist_remove (priv->ap_list, orig_ap);
> g_object_unref (orig_ap);
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add missing return values
On Fri, 2011-10-07 at 22:25 +0200, Thomas Jarosch wrote:
> Signed-off-by: Thomas Jarosch
Applied, thanks!
> ---
> examples/C/qt/add-connection-wired.cpp |2 ++
> examples/C/qt/list-connections.cpp |2 ++
> libnm-util/nm-setting-template.c |1 +
> 3 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/examples/C/qt/add-connection-wired.cpp
> b/examples/C/qt/add-connection-wired.cpp
> index f9e3f6c..475eaff 100644
> --- a/examples/C/qt/add-connection-wired.cpp
> +++ b/examples/C/qt/add-connection-wired.cpp
> @@ -72,4 +72,6 @@ int main() {
> QDBusConnection::systemBus());
>
> addConnection(interface, "__Test connection__");
> +
> +return 0;
> }
> diff --git a/examples/C/qt/list-connections.cpp
> b/examples/C/qt/list-connections.cpp
> index fb98166..586a770 100644
> --- a/examples/C/qt/list-connections.cpp
> +++ b/examples/C/qt/list-connections.cpp
> @@ -48,4 +48,6 @@ int main() {
> QDBusConnection::systemBus());
>
> listConnections(interface);
> +
> +return 0;
> }
> diff --git a/libnm-util/nm-setting-template.c
> b/libnm-util/nm-setting-template.c
> index 989c1db..7dd8797 100644
> --- a/libnm-util/nm-setting-template.c
> +++ b/libnm-util/nm-setting-template.c
> @@ -47,6 +47,7 @@ static gboolean
> verify (NMSetting *setting, GSList *all_settings)
> {
> NMSettingTemplate *self = NM_SETTING_TEMPLATE (setting);
> + return TRUE;
> }
>
> static void
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Missing SIM PIN dialog after nm update
Hi, After read this messages I test my modem 3G, and works normally. After suspend and resume computer and plug modem 3G again, no "SIM PIN dialog", but I don't got modem detected so I did: killall modem-manager After some seconds modem was detected and "SIM PIN dialog" was appears. but we got a little issue where . I have NetworkManager-0.9.1.90-3.git20110927.fc15.x86_64 ModemManager-0.4.998-1.git20110706.fc15.x86_64 on Fedora 15 On Mon, 2011-10-10 at 12:00 +0200, Arne Caspari wrote: > Hello list, > > I updated to GNOME 3.2 on Ubuntu 11.04 with the GNOME3 and > ricotz-testing PPAs. NetworkManager now is at Version 0.9.1.90. Since > the update, I no longer get a dialog requesting the PIN for my USB UMTS > modem. The nm-applet menu lists a mobile broadband connection but if I > select it, nothing happens. > > In /var/log/syslog the following line appears after selecting the > connection: > > "NetworkManager[897]: failed to enable/disable modem: (32) SIM > PIN required" > > I tried to enter the PIN maually in the nm-connection-editor but it > does not get saved ( ie. the next time I open the dialog, there is no > PIN entered ). > > Anybody got an idea what to do to get my UMTS modem working again? > > > /Arne > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Sérgio M. B. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Missing SIM PIN dialog after nm update
Hi, after read this messages I test my modem 3G. And works, after I suspend e resume computer and try again, and no "SIM PIN dialog", but I don't got modem detected . I do killall modem-manager Sfter some seconds modem was detected and "SIM PIN dialog" was appears. On Mon, 2011-10-10 at 12:00 +0200, Arne Caspari wrote: > Hello list, > > I updated to GNOME 3.2 on Ubuntu 11.04 with the GNOME3 and > ricotz-testing PPAs. NetworkManager now is at Version 0.9.1.90. Since > the update, I no longer get a dialog requesting the PIN for my USB UMTS > modem. The nm-applet menu lists a mobile broadband connection but if I > select it, nothing happens. > > In /var/log/syslog the following line appears after selecting the > connection: > > "NetworkManager[897]: failed to enable/disable modem: (32) SIM > PIN required" > > I tried to enter the PIN maually in the nm-connection-editor but it > does not get saved ( ie. the next time I open the dialog, there is no > PIN entered ). > > Anybody got an idea what to do to get my UMTS modem working again? > > > /Arne > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Sérgio M. B. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Missing SIM PIN dialog after nm update
Hello list, I updated to GNOME 3.2 on Ubuntu 11.04 with the GNOME3 and ricotz-testing PPAs. NetworkManager now is at Version 0.9.1.90. Since the update, I no longer get a dialog requesting the PIN for my USB UMTS modem. The nm-applet menu lists a mobile broadband connection but if I select it, nothing happens. In /var/log/syslog the following line appears after selecting the connection: "NetworkManager[897]: failed to enable/disable modem: (32) SIM PIN required" I tried to enter the PIN maually in the nm-connection-editor but it does not get saved ( ie. the next time I open the dialog, there is no PIN entered ). Anybody got an idea what to do to get my UMTS modem working again? /Arne ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
