Re: Sierra Modem Problem
On Tue, 2009-03-10 at 19:54 -0700, Josefa Molina wrote: Hi, I am having this problem and would like to know what exact text change is needed so that I can add it to the file. Also, I've seen this fix list the location of the file in etc/hal/fdi/information/modems.fdi vs /usr/share/hal/fdi/information/10freedesktop/. Which is correct? Only /usr/share/hal/fdi/information/10freedesktop is the official location provided by the upstream hal-info project. Not sure what is creating the other location. In the file you'll see a section for Sierra devices. Look for the section starting with !-- Sierra Wireless --. In that section, you'll see one block for GSM devices, and one block for CDMA devices. Add your modem's product ID to the end of the list in the right section for your modem. The product ID can be found as the hexadecimal number after the colon in the output of 'lsusb' for your modem: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub product ID Dan Thanks. Message: 4 Date: Tue, 10 Mar 2009 10:08:11 -0700 From: Chetan Karia chetanka...@gmail.com Subject: Supporting new Sierra CDMA modems. To: networkmanager-list@gnome.org Message-ID: 521673c40903101008y3634b54cjcbfb73cb47082...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, I am an employee of Sierra wireless USA. I was testing network manager on Ubuntu 8.10. I found that all Sierra CDMA modems worked well with network manager except our two new products which were not detected by Network Manager. On investigating further I discovered its just matter of adding the Vendor ID and Product ID of our new devices to the file 10-modem.fdi under the directory /usr/share/hal/fdi/information/10freedesktop/. Once I edit this file and add the VID/PID's the Network Manager detects the devices and connects to CDMA network. I wanted to know the procedure to officially add the VID/PID's of new Sierra device to 10-modem.fdi file, so that I do not have to edit it manually. Your help will be much appreciated. Thanks, Chetan -- Message: 5 Date: Tue, 10 Mar 2009 18:12:38 +0100 From: Rapha?l Jacquot sxp...@sxpert.org Subject: Re: Supporting new Sierra CDMA modems. To: networkmanager-l...@gnome..org Message-ID: 20090310171238.gf11...@sxpert.org Content-Type: text/plain; charset=us-ascii On Tue, Mar 10, 2009 at 10:08:11AM -0700, Chetan Karia wrote: Hi, I am an employee of Sierra wireless USA. I was testing network manager on Ubuntu 8.10. I found that all Sierra CDMA modems worked well with network manager except our two new products which were not detected by Network Manager. On investigating further I discovered its just matter of adding the Vendor ID and Product ID of our new devices to the file 10-modem.fdi under the directory /usr/share/hal/fdi/information/10freedesktop/. Once I edit this file and add the VID/PID's the Network Manager detects the devices and connects to CDMA network. I wanted to know the procedure to officially add the VID/PID's of new Sierra device to 10-modem..fdi file, so that I do not have to edit it manually. Your help will be much appreciated. you should contact the Udev people linux-hotp...@vger.kernel.org Thanks, Chetan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Message: 6 Date: Tue, 10 Mar 2009 18:50:37 +0100 From: Alexander Sack a...@ubuntu.com Subject: Re: Supporting new Sierra CDMA modems. To: Chetan Karia chetanka...@gmail.com Cc: networkmanager-list@gnome.org Message-ID: 20090310175037.gh29...@jwsdot.com Content-Type: text/plain; charset=us-ascii Hi, On Tue, Mar 10, 2009 at 10:08:11AM -0700, Chetan Karia wrote: Hi, I am an employee of Sierra wireless USA. I was testing network manager on Ubuntu 8.10. I found that all Sierra CDMA modems worked well with network manager except our two new products which were not detected by Network Manager. On investigating further I discovered its just matter of adding the Vendor ID and Product ID of our new devices to the file 10-modem.fdi under the directory /usr/share/hal/fdi/information/10freedesktop/. Once I edit this file and add the VID/PID's the Network Manager detects the devices and connects to CDMA network. I wanted to know the procedure to officially add the VID/PID's of new Sierra device to 10-modem.fdi file, so that I do not have to edit it manually. Please provide info on the exact pieces required. One way to move foward would be to file a bug with that info against hal-info [1] package in launchpad. We (ubuntu) takes care that info submitted there regularly gets committed upstream. [1] -
Re: force nm to use a connection
On Wed, Mar 11, 2009 at 12:10:40AM +0100, Jérôme PRIOR wrote: hello, I'm looking for info to force nm to use a connection instead of Auto eth0. I explain : at home I need a static IP, with special DNS, ... So, I created a connection called `home` with those parameters. Works fine when I activated it manually. When I'm outside, I need `auto eth0`. How can I tell nm when I'm at home, connect me via `home`, even if connect me via `auto eth0` ? I try to pla with automatic connection but of course, if I put `home` as auto, and `auto eth0` as no-auto, when I'm outside, `home` is up. And inversement. NetworkManager currently has no smart tie-break logic to decide which auto connection to use. Not sure, but maybe it prefers the last one that was active. Not sure if we could come up with something smarter for wired. Any ideas? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Supporting new Sierra CDMA modems.
On Tue, 2009-03-10 at 10:08 -0700, Chetan Karia wrote: Hi, I am an employee of Sierra wireless USA. I was testing network manager on Ubuntu 8.10. I found that all Sierra CDMA modems worked well with network manager except our two new products which were not detected by Network Manager. On investigating further I discovered its just matter of adding the Vendor ID and Product ID of our new devices to the file 10-modem.fdi under the directory /usr/share/hal/fdi/information/10freedesktop/. Once I edit this file and add the VID/PID's the Network Manager detects the devices and connects to CDMA network. I wanted to know the procedure to officially add the VID/PID's of new Sierra device to 10-modem.fdi file, so that I do not have to edit it manually. Your help will be much appreciated. Hi! Alexander has already described how to get the modem recognized. Let us know if there's any other questions you have. In the future, we're going to use modem port detection where a small program will query the modem for supports AT command sets (using ATI or AT+GCAP) when its plugged in. So updating hal-info shouldn't be necessary for NetworkManager later than 0.7.1. I have one question for you, however. Many modems (including some Sierra ones) expose more than one AT-capable serial port. On those modems, usually only one port returns unsolicited responses like CONNECT that NetworkManager needs to listen for. Is that also the case with Sierra modems that expose multiple AT-capable serial ports? If so, how do we know which of the ports provides that unsolicited response? For example, Option NV modems expose up to 4 or 5 AT-capable serial ports, but for ealier models, only usb interface 0 provides the necessary CONNECT response. On later models, the 'hso' driver queries the Option firmware for port types and exposes that information to userspace. Is there a similar mechanism for Sierra? Thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: force nm to use a connection
On Wed, 2009-03-11 at 11:34 +0100, Alexander Sack wrote: On Wed, Mar 11, 2009 at 12:10:40AM +0100, Jérôme PRIOR wrote: hello, I'm looking for info to force nm to use a connection instead of Auto eth0. I explain : at home I need a static IP, with special DNS, ... So, I created a connection called `home` with those parameters. Works fine when I activated it manually. When I'm outside, I need `auto eth0`. How can I tell nm when I'm at home, connect me via `home`, even if connect me via `auto eth0` ? I try to pla with automatic connection but of course, if I put `home` as auto, and `auto eth0` as no-auto, when I'm outside, `home` is up. And inversement. NetworkManager currently has no smart tie-break logic to decide which auto connection to use. Not sure, but maybe it prefers the last one that was active. Yes, it uses the last connected Ethernet connection. For wifi, it uses the last connected AP that's currently visible. Not sure if we could come up with something smarter for wired. Any ideas? Not for plain wired, unless you want to try ARP sniffing or ARP-ing a known IP address to match a known MAC address or something. Not that that is in any way secure, and it would also increase connection latency. But maybe that's a worthwhile tradeoff to get the right wired connection; most people will only have one or two, so a few seconds to sniff which connection to use (if its been configured that way) might be worth it. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.7.1 rc3 oddness with 3G USB device
On Tue, 2009-03-10 at 12:42 +0200, Tambet Ingo wrote: On Mon, Mar 9, 2009 at 21:05, Dan Williams d...@redhat.com wrote: Mobile broadband capabilities are detected with udev capabilities now too, but the problem here is that nothing reports which channel is the control channel and which isn't. That information need to go into the driver somewhere like it does for 'hso' type devices. I don't know; maybe asac is right and we do need to prefer HAL over udev at least for 0.7.1. I agree with asac then. With any modem other than HSO, you have no idea from probing which port is the control port and which just accepts AT commands. With HAL, while things are fragile and require manual updates, there's at least a chance it works. Alternatively, we could use the HAL information in addition to the udev information. Given a udev probe of the ports, get the HAL info as well. If HAL thinks the port is GSM/CDMA-capable, use it. If HAL doesn't know about any ports for the device, just pick a port to use like the udev stuff does now. Or we could start putting port-types into the udev rules just like we've done for HAL. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: force nm to use a connection
On Wed, Mar 11, 2009 at 06:40:31AM -0400, Dan Williams wrote: On Wed, 2009-03-11 at 11:34 +0100, Alexander Sack wrote: On Wed, Mar 11, 2009 at 12:10:40AM +0100, Jérôme PRIOR wrote: hello, I'm looking for info to force nm to use a connection instead of Auto eth0. I explain : at home I need a static IP, with special DNS, ... So, I created a connection called `home` with those parameters. Works fine when I activated it manually. When I'm outside, I need `auto eth0`. How can I tell nm when I'm at home, connect me via `home`, even if connect me via `auto eth0` ? I try to pla with automatic connection but of course, if I put `home` as auto, and `auto eth0` as no-auto, when I'm outside, `home` is up. And inversement. NetworkManager currently has no smart tie-break logic to decide which auto connection to use. Not sure, but maybe it prefers the last one that was active. Yes, it uses the last connected Ethernet connection. For wifi, it uses the last connected AP that's currently visible. Not sure if we could come up with something smarter for wired. Any ideas? Not for plain wired, unless you want to try ARP sniffing or ARP-ing a known IP address to match a known MAC address or something. Not that that is in any way secure, and it would also increase connection latency. But maybe that's a worthwhile tradeoff to get the right wired connection; most people will only have one or two, so a few seconds to sniff which connection to use (if its been configured that way) might be worth it. I think it would be worth it and would be in line with NM's idea of being as smart as possible :). I am not sure about the security implications, but how does current autoconnect strategy not come with the same risks? Also related, how about probing for pppoe concentrators to add more automagic on that front? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq-base does work for connection sharing
On Tue, 2009-03-10 at 09:30 +0900, Jacobs Shannon wrote: Not sure what I did differently this last time, but dnsmasq-base (alone) is working properly for the connection sharing. I've noticed a few minor behavioral differences, but I think that's probably just some differences in the security settings. The other problems I mentioned are minor, and I can just live with them for now. I'll work with this configuration for a few weeks and see how things go. Thanks again for your encouragement. And sometimes it doesn't... Presumably whatever I saw last night was whatever was going on the first time when it didn't seem to be working. I don't know what state it is in, but various lesser solutions such as tweaking the configuration settings (in various orders) and restarting the network don't fix it. Nothing short of a full reboot seems to do the trick. Whatever state it is in, the DHCP part seems to be working, and the gateway computer is connected normally, but none of the guest computers can reach the external network, though they can ping the gateway machine. I now realize that I didn't do quite enough testing to pin it to the DNS, but I'll check with an external IP address the next time I see it... So that sounds more like iptables rules than anything to do with dnsmasq. dnsmasq will only provide DHCP and DNS, so you should still be able to ping external addresses as long as dnsmasq is returning the correct gateway to machines that perform DHCP requests. What's the routing table on a machine you're sharing to? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Forcing a BSSID, unchecking Connect automatically doesn't work
On Tue, 2009-03-10 at 14:58 -0400, Chuck Anderson wrote: I'm trying to force a specific BSSID (testing 802.11n in fact) but NetworkManager keeps trying to associate to the other BSSID's (APs) on the same ESSID. In fact, it popped up with a dialog to set up the encryption settings, etc. (WPA TLS) because it couldn't use the connection profile that I forced the BSSID on. So I let it create another Auto profile, set up the encryption, and then unchecked the Connect automatically...but guess what? It still connects automatically. How do I force NetworkManager to ignore all BSSID's for a specific ESSID, except for the one I want? Can you post some of the NM log output? You should see NM sending bssid to wpa_supplicant. If NM sends that, and you still see the driver connecting to random BSSIDs, then that's purely a driver problem. You should be able to recreate the issue with plain wpa_supplicant as well, using the 'bssid' key in a network block to tell the driver to only use that BSSID. This is highly driver/stack dependent, so it could be a bug in the mac80211 stack too, if you're using one of the mac80211 drivers. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: force nm to use a connection
On Wed, 2009-03-11 at 11:52 +0100, Alexander Sack wrote: On Wed, Mar 11, 2009 at 06:40:31AM -0400, Dan Williams wrote: On Wed, 2009-03-11 at 11:34 +0100, Alexander Sack wrote: On Wed, Mar 11, 2009 at 12:10:40AM +0100, Jérôme PRIOR wrote: hello, I'm looking for info to force nm to use a connection instead of Auto eth0. I explain : at home I need a static IP, with special DNS, ... So, I created a connection called `home` with those parameters. Works fine when I activated it manually. When I'm outside, I need `auto eth0`. How can I tell nm when I'm at home, connect me via `home`, even if connect me via `auto eth0` ? I try to pla with automatic connection but of course, if I put `home` as auto, and `auto eth0` as no-auto, when I'm outside, `home` is up. And inversement. NetworkManager currently has no smart tie-break logic to decide which auto connection to use. Not sure, but maybe it prefers the last one that was active. Yes, it uses the last connected Ethernet connection. For wifi, it uses the last connected AP that's currently visible. Not sure if we could come up with something smarter for wired. Any ideas? Not for plain wired, unless you want to try ARP sniffing or ARP-ing a known IP address to match a known MAC address or something. Not that that is in any way secure, and it would also increase connection latency. But maybe that's a worthwhile tradeoff to get the right wired connection; most people will only have one or two, so a few seconds to sniff which connection to use (if its been configured that way) might be worth it. I think it would be worth it and would be in line with NM's idea of being as smart as possible :). I am not sure about the security implications, but how does current autoconnect strategy not come with the same risks? Also related, how about probing for pppoe concentrators to add more automagic on that front? Can you point me to some info on how that can be done? Tambet also said we can autodetect 802.1x-enabled switches as well. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Shutting down specific device
On Tue, 2009-03-10 at 12:20 -0700, Drew Moseley wrote: Is there a bit of scripting magic where I can force a specific network device to shut down? We have a device that when it is powered down via external switch, Network Manager handles it but sees a state change to FAILED so it is marked as invalid. I'd like to be able to tell Network Manager that it should be disconnected so it is handled more gracefully. Does the device get hot-unplugged from the machine when its switched off? Or does it look like rfkill? Obviously you need to get *some* indication in the kernel that the device is no longer available. The normal indications of this are no carrier (wired) or rfkill (wifi). I'd suggest using either of those if you can. If it's wired, your driver should be setting netif_carrier_off() and NM will handle that appropriately. If it's wifi, the driver should be hooking into the kernel's rfkill subsystem and setting the rfkill device to the hard-blocked state, which NM (through HAL's killswitch support) will pick up. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Feature request: Blacklist BSSID or MAC address
On Tue, 2009-03-10 at 15:25 -0400, Matthew Saltzman wrote: Our campus wireless network has several dozen access points scattered around campus. From where I sit in my office, I can see about a dozen or so. Frequently, NM (or the driver) selects an AP with a relatively weak signal (to the point of being unusable), even though I sit across the hall from a much stronger one. This would be a supplicant or driver problem and should probably be solved there. The supplicant should be ordering the scan list by best signal strength already anyway. The driver may also roam between APs without interaction with NM or the supplicant. I don't want to bind the configuration to a single BSSID, because I do move around the campus and I want to be able to connect wherever I am. But I do want to blacklist the weak APs near my office, so I don't have to force reassociation (which seems to require power-cycling my wireless interface). I don't see a way to do that in the pull-down Edit Connections menu. Is it possible to add such a feature? Or should I be asking for something else to deal with this issue? (For example, is it a driver bug?) Yeah, it's either a driver or supplicant issue first; there's simply not a way to blacklist a specific BSSID at levels lower than NM yet. Have you run 'iwlist' when you notice you're on a bad AP and looked at the relative signal strengths of the reported APs to see how bad the one you're on really is? We could modify the supplicant to never select certain APs, and then we'd also have to modify the driver to ensure that it never automatically roamed to those APs as well. That's probably not possible with WEXT, but should be with the newer wireless driver API (cfg80211). Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: force nm to use a connection
On Wed, Mar 11, 2009 at 06:55:45AM -0400, Dan Williams wrote: Can you point me to some info on how that can be done? The pppoe command line tool provides the -A option (from man): -A The -A option causes pppoe to send a PADI packet and then print the names of access concentrators in each PADO packet it receives. Do not use this option in conjunction with pppd; the -A option is meant to be used interactively to give interesting information about the access concentrator. I tried that when i still had my pppoe thing connected to a system and it worked. - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fw: DBus interface clarification part2
On Tue, 2009-03-10 at 18:50 -0700, Kevron Rees wrote: On Mon, 2009-03-09 at 04:09 -0700, Kevron Rees wrote: Answering myself, since I got no response here, ActivateConnection requires that the connection you want to activate has been connected to in the past. Am I correct on this? You basically have to get the connection object from the org.freedesktop.NetworkManagerSettings ListConnections() method. From that list, you have to find the specific connection to use. You do so by looking in that path and the org.freedesktop.NetworkManagerSettings.Connection interface using the GetSettings() method. Correct me if i'm wrong, but if this is a new access point, you cannot connect to it via dbus? Wouldn't a simpler: ActivateConnection(o: device, o: specific_object_to_connect_to) I responded on Saturday: http://mail.gnome.org/archives/networkmanager-list/2009-March/msg00082.html Let me know if you have any further questions! Dan Thanks Dan! I didn't see the reply on Saturday. My mistake. Your example is very helpful. Is it possible to use a blank path (/) as the connection if this is a new connection and no settings are available yet? Not quite. *Every* call to Activate requires a connection in the settings service. If you don't have a connection defined, a number of things won't work or get ugly, since there's no overall tracking object associated with that request. The Connection provides the human-readable name for that request like Home or Work, plus a UUID that other processes can use to perform actions when the connection succeeds or fails. The normal process of connecting to a new AP would usually be to create a connection for that AP in the settings service, then request that NM activate the newly created connection. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq-base does work for connection sharing
Date: Wed, 11 Mar 2009 06:51:11 -0400 From: Dan Williams d...@redhat.com On Tue, 2009-03-10 at 09:30 +0900, Jacobs Shannon wrote: Not sure what I did differently this last time, but dnsmasq-base (alone) is working properly for the connection sharing. I've noticed a few minor behavioral differences, but I think that's probably just some differences in the security settings. The other problems I mentioned are minor, and I can just live with them for now. I'll work with this configuration for a few weeks and see how things go. Thanks again for your encouragement. And sometimes it doesn't... Presumably whatever I saw last night was whatever was going on the first time when it didn't seem to be working. I don't know what state it is in, but various lesser solutions such as tweaking the configuration settings (in various orders) and restarting the network don't fix it. Nothing short of a full reboot seems to do the trick. Whatever state it is in, the DHCP part seems to be working, and the gateway computer is connected normally, but none of the guest computers can reach the external network, though they can ping the gateway machine. I now realize that I didn't do quite enough testing to pin it to the DNS, but I'll check with an external IP address the next time I see it... So that sounds more like iptables rules than anything to do with dnsmasq. dnsmasq will only provide DHCP and DNS, so you should still be able to ping external addresses as long as dnsmasq is returning the correct gateway to machines that perform DHCP requests. What's the routing table on a machine you're sharing to? Well, it hasn't got into the strange state lately, but I'll keep working with it and see if I can detect any patterns. Right now I'm mostly impressed with it, but I'm thinking about experimenting with the wireless side of it for ad hoc wireless networking to two of my machines instead of going through the hub. -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
AW: Re: dnsmasq-base does work for connection sharing
Hi all On Tue, 2009-03-10 at 09:30 +0900, Jacobs Shannon wrote: I now realize that I didn't do quite enough testing to pin it to the DNS, but I'll check with an external IP address the next time I see it... I ran into a DNS-related problem with dnsmasq (once i had discovered in syslog that NM complained about not finding the dnsmasq binary, so I installed dnsmasq-base). It returned a REFUSED status code upon a client's query. Via Google I found a post in the dnsmasq-discuss list that said: | The only circumstance in which dnsmasq will generate a REFUSED reply is | when it has no upstream server available to forward a query to, but it's | worth bearing in mind that if dnsmasq _does_ forward the a query, then | the upstream nameserver could also return a REFUSED reply, and dnsmasq | would send that back to the original requester. And then I realised what had happened: The client had obtained an IP address and issued a DNS request before my mobile broadband connection was up and the sharing computer had learnt about the ISPs DNSs via PPP. So making sure that the to-be-shared link is up and running before bringing up the sharing Ethernet or WLAN profile should help. Right now I'm mostly impressed with it, but I'm thinking about experimenting with the wireless side of it for ad hoc wireless networking to two of my machines instead of going through the hub. Works. Define a new ad-hoc WLAN profile, set WEP parameters as needed. Bring up the upstream link first, then Create new wireless network from nm-applets menu and select your previously created ad-hoc profile. AFAIK, NM currently has no built-in way to run a WLAN NIC in master mode to create an AccessPoint/Infrastructure network, so we're stuck with ad-hoc for the time being. regards Marc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq-base does work for connection sharing
On Wed, 2009-03-11 at 21:51 +0900, Jacobs Shannon wrote: Date: Wed, 11 Mar 2009 06:51:11 -0400 From: Dan Williams d...@redhat.com On Tue, 2009-03-10 at 09:30 +0900, Jacobs Shannon wrote: Not sure what I did differently this last time, but dnsmasq-base (alone) is working properly for the connection sharing. I've noticed a few minor behavioral differences, but I think that's probably just some differences in the security settings. The other problems I mentioned are minor, and I can just live with them for now. I'll work with this configuration for a few weeks and see how things go. Thanks again for your encouragement. And sometimes it doesn't... Presumably whatever I saw last night was whatever was going on the first time when it didn't seem to be working. I don't know what state it is in, but various lesser solutions such as tweaking the configuration settings (in various orders) and restarting the network don't fix it. Nothing short of a full reboot seems to do the trick. Whatever state it is in, the DHCP part seems to be working, and the gateway computer is connected normally, but none of the guest computers can reach the external network, though they can ping the gateway machine. I now realize that I didn't do quite enough testing to pin it to the DNS, but I'll check with an external IP address the next time I see it... So that sounds more like iptables rules than anything to do with dnsmasq. dnsmasq will only provide DHCP and DNS, so you should still be able to ping external addresses as long as dnsmasq is returning the correct gateway to machines that perform DHCP requests. What's the routing table on a machine you're sharing to? Well, it hasn't got into the strange state lately, but I'll keep working with it and see if I can detect any patterns. Right now I'm mostly impressed with it, but I'm thinking about experimenting with the wireless side of it for ad hoc wireless networking to two of my machines instead of going through the hub. If *anything* else is touching iptables rules on your machine, it could step on the NM's rules unless that program is careful to only undo what it added in the first place. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: AW: Re: dnsmasq-base does work for connection sharing
On Wed, 2009-03-11 at 13:36 +, netzt...@bluewin.ch wrote: Hi all On Tue, 2009-03-10 at 09:30 +0900, Jacobs Shannon wrote: I now realize that I didn't do quite enough testing to pin it to the DNS, but I'll check with an external IP address the next time I see it... I ran into a DNS-related problem with dnsmasq (once i had discovered in syslog that NM complained about not finding the dnsmasq binary, so I installed dnsmasq-base). It returned a REFUSED status code upon a client's query. Via Google I found a post in the dnsmasq-discuss list that said: | The only circumstance in which dnsmasq will generate a REFUSED reply is | when it has no upstream server available to forward a query to, but it's | worth bearing in mind that if dnsmasq _does_ forward the a query, then | the upstream nameserver could also return a REFUSED reply, and dnsmasq | would send that back to the original requester. And then I realised what had happened: The client had obtained an IP address and issued a DNS request before my mobile broadband connection was up and the sharing computer had learnt about the ISPs DNSs via PPP. So making sure that the to-be-shared link is up and running before bringing up the sharing Ethernet or WLAN profile should help. Right now I'm mostly impressed with it, but I'm thinking about experimenting with the wireless side of it for ad hoc wireless networking to two of my machines instead of going through the hub. Works. Define a new ad-hoc WLAN profile, set WEP parameters as needed. Bring up the upstream link first, then Create new wireless network from nm-applets menu and select your previously created ad-hoc profile. AFAIK, NM currently has no built-in way to run a WLAN NIC in master mode to create an AccessPoint/Infrastructure network, so we're stuck with ad-hoc for the time being. That's because (a) drivers universally suck for master mode, and (b) there's a hell of a lot more setup required for master mode than adhoc. At the moment, I don't see a compelling reason to use master mode over adhoc until drivers get better. We certainly can't flip the switch until most of the mac80211-based drivers get good AP mode support. While some drivers do have OK AP-mode support, there question is, what advantages does master mode bring, and if those are significant, how do we let the user know what impact master vs. adhoc will have on their day-to-day workflow? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Re: How to suppress pop-up window when device is inserted ?
Hi Alexander, This requires a patch to not add actions if there is no action support. Forgot to submit it ... will come in a minute .. could you be a litte bit more specific about the actions that you mentioned, point me in some direction where I should start digging to understand how this works? Is that something which goes into the hal fdi files? Do I need to look at the dbus methods that NM provides? Which one specifically? Or is it the nm-applet code to look at? As I am new to NM I couldn't see that immediately by looking at your patch. Just a hint with some more context where to start looking would be nice. many thanks Chris http://www.acurana.de/ ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Re: How to suppress pop-up window when device is inserted ?
On Wed, 2009-03-11 at 16:58 +0100, Christopher Lang wrote: Hi Alexander, This requires a patch to not add actions if there is no action support. Forgot to submit it ... will come in a minute .. could you be a litte bit more specific about the actions that you mentioned, point me in some direction where I should start digging to understand how this works? Is that something which goes into the hal fdi files? Do I need to look at the dbus methods that NM provides? Which one specifically? Or is it the nm-applet code to look at? As I am new to NM I couldn't see that immediately by looking at your patch. Just a hint with some more context where to start looking would be nice. The patches that pop up a notification when you plug in the 3G card are Ubuntu specific and not part of upstream NetworkManager, so you won't find them in official NM sources. But Alexander is the maintainer of NM for Ubuntu and thus would be quite qualified to point out how to suppress it. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq-base does work for connection sharing
That's because (a) drivers universally suck for master mode, and (b) there's a hell of a lot more setup required for master mode than adhoc. At the moment, I don't see a compelling reason to use master mode over adhoc until drivers get better. er.. I didn't mean to complain about the lack (which I don't consider as such) of AP-mode support. If my words sounded like a complaint, I offer my apologies on the spot. I like NM very much, and it's fun seeing how it gets better with every release: I was stunned how easy it was to get my USB 3G modem working with NM (plug, PIN, works), where it took me half an evening to make it work on MacOS X, half of which figuring out which software to obtain from where and what exactly to use it for... The one thing that springs to mind if it comes to Infrastructure vs ad-hoc modes of 802.11 could be scaleability for a larger number of devices, and another thing might be the lack of WPA/WPA2 support I see occurring in most implementations once you switch over to ad-hoc mode. I'm not quite sure if that is because of the nature of how 802.11 ad-hoc mode works or if no vendor's so far cared about implementing WPA/WPA2 in ad-hoc mode. regards Marc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Re: How to suppress pop-up window when device is inserted ?
Ubuntu specific and not part of upstream NetworkManager, so you won't Dan, thanks, that clarifies things a bit. Chris ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Skipping popup requesting secrets
What is the best way to have NetworkManager/nm-applet __not__ request wireless secrets? We have a scenario where we are attempting to connect to the network and we do not have a user at the system. In this scenario we just want to fail this particular connection without marking the connection as bad. We want to attempt another connection with the same secrets later, ala background polling. Drew ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Feature request: Blacklist BSSID or MAC address
On Wed, 2009-03-11 at 07:04 -0400, Dan Williams wrote: On Tue, 2009-03-10 at 15:25 -0400, Matthew Saltzman wrote: Our campus wireless network has several dozen access points scattered around campus. From where I sit in my office, I can see about a dozen or so. Frequently, NM (or the driver) selects an AP with a relatively weak signal (to the point of being unusable), even though I sit across the hall from a much stronger one. This would be a supplicant or driver problem and should probably be solved there. The supplicant should be ordering the scan list by best signal strength already anyway. The driver may also roam between APs without interaction with NM or the supplicant. I don't want to bind the configuration to a single BSSID, because I do move around the campus and I want to be able to connect wherever I am. But I do want to blacklist the weak APs near my office, so I don't have to force reassociation (which seems to require power-cycling my wireless interface). I don't see a way to do that in the pull-down Edit Connections menu. Is it possible to add such a feature? Or should I be asking for something else to deal with this issue? (For example, is it a driver bug?) Yeah, it's either a driver or supplicant issue first; there's simply not a way to blacklist a specific BSSID at levels lower than NM yet. Have you run 'iwlist' when you notice you're on a bad AP and looked at the relative signal strengths of the reported APs to see how bad the one you're on really is? We could modify the supplicant to never select certain APs, and then we'd also have to modify the driver to ensure that it never automatically roamed to those APs as well. That's probably not possible with WEXT, but should be with the newer wireless driver API (cfg80211). OK I will keep an eye on this with that in mind and post to the supplicant bug list when I have enough data to make it worthwhile. Thanks. Dan -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM stops and doesn't connect
- Original Message - From: Dan Williams d...@redhat.com To: Cliff McDiarmid cliffhan...@gardener.com Cc: networkmanager-list@gnome.org Subject: Re: NM stops and doesn't connect Date: Mon, 09 Mar 2009 16:21:16 -0400 I'm sending this message to the mailing site this time, I don't know whether anyone can help me further. Are you using the supplicant manually? With NM, there's no need to have a supplicant config file even, since NM will send config information to the supplicant on its own, based on the connections you've defined either in your distro config files or in GConf. Yes Dan, its the only way I can get it loaded, dbus is supposed to activate it but won't, I've tried everything I know, which is not much because I'm not a programmer. I should make it clear that I'm trying to connect via the command prompt as a user, although I get the same result as root. I assume this is possible or should I be in a desktop manager with the applet etc? NetworkManager is trying to start the system settings service with D-Bus service activation, which is normal. Do you have the /usr/share/dbus-1/system-services/org.freedesktop.NetworkManagerSystemSettings.service file, and if so, what does it contain? [D-BUS Service] Name=org.freedesktop.NetworkManagerSystemSettings Exec=/usr/sbin/nm-system-settings --config /etc/NetworkManager/nm-system-settings.conf User=root When nm-system-settings is started, what's the output of the following command? dbus-send --system --print-reply --dest=org.freedesktop.NetworkManagerSystemSettings /org/freedesktop/NetworkManagerSettings org.freedesktop.NetworkManagerSettings.ListConnections method return sender=:1.2 - dest=:1.4 reply_serial=2 object path /fi/epitest/hostap/WPASupplicant/Interfaces/0 MAC -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
dns work arounds
running with ubuntu 8.04 and a crufty netmanager from last summer. my main problem is that the dns data from open vpn connections is ignored. a secondary problem is that routes are not handled correctly when switching between wifi and wired. since the latest netmanager won't compile on 8.04 (kernel too old), any ideas for workarounds? thanks --- eric ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dns work arounds
On Wed, 2009-03-11 at 16:40 -0400, Eric S. Johansson wrote: since the latest netmanager won't compile on 8.04 (kernel too old), any ideas for workarounds? https://launchpad.net/~network-manager/+archive/ppa select hardy heron and find the right sources.list statements: deb http://ppa.launchpad.net/network-manager/ppa/ubuntu hardy main deb-src http://ppa.launchpad.net/network-manager/ppa/ubuntu hardy main That should word, I think regards Marc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dns work arounds
(forgot to send to list) Marc Luethi wrote: On Wed, 2009-03-11 at 16:40 -0400, Eric S. Johansson wrote: since the latest netmanager won't compile on 8.04 (kernel too old), any ideas for workarounds? https://launchpad.net/~network-manager/+archive/ppa select hardy heron and find the right sources.list statements: deb http://ppa.launchpad.net/network-manager/ppa/ubuntu hardy main deb-src http://ppa.launchpad.net/network-manager/ppa/ubuntu hardy main That should word, I think regards W: GPG error: http://ppa.launchpad.net hardy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D702BF6B8C6C1EFD installed key -BEGIN PGP PUBLIC KEY BLOCK- Version: SKS 1.0.10 mI0ESXX0pgEEAMDSk9Vd+OWZNIa4dL2SpqFAjVq/hm4Nac2oc33g+BwP3jFajUC/quPnYXXl N7GER+tTHJ9d0PlXQDoRxXFRdSjZYUHDkiT8UV1I+sTxkjDaA7uMXD4dEcL0SG0nh6OyHHrd 9PrWzIZ/jS6PsYtKrKwHYCvP/igPr5/bH1PQoyZzABEBAAG0IUxhdW5jaHBhZCBQUEEgZm9y IE5ldHdvcmstbWFuYWdlcoi2BBMBAgAgBQJJdfSmAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AACgkQJI3R7ryOv+h8JQP+Ib07jYEiNG3PZf22xkV2rU/ybI9s4fT1CCoPJq5V3uJmouUs jtSXMD/9V44kFamw+Xq1EVEWeExfeABjaX7Vc9SR50Kl/DJVvBAbGs8rM2JxldQsl4sGWnTn AMJx/fv4iQsdyaklS3TcK6xo1yL21C4j0wYsmNxS16F28L3hRQ4= =8t/V -END PGP PUBLIC KEY BLOCK- used the text and video instructions. I've had this problem for months and when I wasn't able to resolve it, I deleted the repository and forgot about it till now. any idea why this problem persists? --- eric Marc ___ 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
Trouble configuring a VPN interface to access a Windows network
I am having trouble configuring a VPN interface to access a Windows network. Within the Windows Network Connections window this connection is listed as: Name: net name Type: Virtual Private Network Device Name: WAN Miniport (PPTP) It was created via the New Connection Wizard as follows: Network Connection Type: Connect to the network at my workplace Network Connection: Virtual Private Network connection Connection Name: net name Public Network: Do not dial the initial connection VPN Server Selection: host name / ip address Connection Availability: Anyone's use I have tried to configure the connection via the nm-applet as follows: Choose a VPN Connection Type: Point-To-Point Tunneling Protocol (PPTP) Gateway: host name / ip address User name: user name - see Note Password: password - see Note NT Domain: domain name - see Note (Advanced Button - basically used the defaults) Authentication Allow the following authentication methods: (all checked) Security and Compression Use Point-To-Point encryption (MPPE): unchecked Allow BSD compression: checked Allow Deflate compression: checked Use TCP header compression: checked Echo Send PPP echo packets: unchecked NOTE: The user name, password are those that are entered in Windows when the I connect to the VPN and the Domain is the Windows domain that I am logging into. Note that the user name and password used for the actual Windows login is different to the ones used above. When trying to activate the connection, the following is produced in the system log file. (Note that this has been slightly edited for security reasons.) NetworkManager: info Starting VPN service 'org.freedesktop.NetworkManager.pptp'... NetworkManager: info VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 25013 NetworkManager: info VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections NetworkManager: info VPN plugin state changed: 3 NetworkManager: info VPN connection 'VPN connection 1' (Connect) reply received. pppd[25016]: Plugin /usr/lib/pppd/2.4.4/nm-pptp-pppd-plugin.so loaded. pppd[25016]: pppd 2.4.4 started by root, uid 0 pppd[25016]: Using interface ppp0 pppd[25016]: Connect: ppp0 -- /dev/pts/2 pptp[25017]: nm-pptp-service-25013 log[main:pptp.c:314]: The synchronous pptp option is NOT activated pptp[25026]: nm-pptp-service-25013 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' pptp[25026]: nm-pptp-service-25013 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply pptp[25026]: nm-pptp-service-25013 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established. pptp[25026]: nm-pptp-service-25013 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' pptp[25026]: nm-pptp-service-25013 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply. pptp[25026]: nm-pptp-service-25013 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 61490). pptp[25026]: nm-pptp-service-25013 log[ctrlp_disp:pptp_ctrl.c:950]: PPTP_SET_LINK_INFO received from peer_callid 50110 pptp[25026]: nm-pptp-service-25013 log[ctrlp_disp:pptp_ctrl.c:953]: send_accm is , recv_accm is pptp[25026]: nm-pptp-service-25013 warn[ctrlp_disp:pptp_ctrl.c:956]: Non-zero Async Control Character Maps are notsupported! pppd[25016]: CHAP authentication succeeded pppd[25016]: LCP terminated by peer (^BM-?-M-K^@m-...@^@^BM-f) pptp[25026]: nm-pptp-service-25013 log[ctrlp_disp:pptp_ctrl.c:950]: PPTP_SET_LINK_INFO received from peer_callid 50110 pptp[25026]: nm-pptp-service-25013 log[ctrlp_disp:pptp_ctrl.c:953]: send_accm is , recv_accm is pptp[25026]: nm-pptp-service-25013 warn[ctrlp_disp:pptp_ctrl.c:956]: Non-zero Async Control Character Maps are notsupported! pptp[25026]: nm-pptp-service-25013 log[ctrlp_disp:pptp_ctrl.c:912]: Received Call Clear Request. NetworkManager: info VPN plugin failed: 1 pppd[25016]: Connection terminated. pptp[25017]: nm-pptp-service-25013 warn[decaps_hdlc:pptp_gre.c:204]: short read (-1): Input/output error pptp[25017]: nm-pptp-service-25013 warn[decaps_hdlc:pptp_gre.c:216]: pppd may have shutdown, see pppd log pptp[25026]: nm-pptp-service-25013 log[callmgr_main:pptp_callmgr.c:234]: Closing connection (unhandled) pptp[25026]: nm-pptp-service-25013 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' NetworkManager: info VPN plugin failed: 1 pptp[25026]: nm-pptp-service-25013 log[call_callback:pptp_callmgr.c:79]: Closing connection (call state) pppd[25016]: Modem hangup pppd[25016]: Exit. NetworkManager: info VPN plugin failed: 1 NetworkManager: info VPN plugin state changed: 6 NetworkManager: info VPN plugin state change reason: 0 NetworkManager: WARN connection_state_changed(): Could not process the request because no VPN connection was active. NetworkManager:
Re: Skipping popup requesting secrets
On Wed, 2009-03-11 at 12:11 -0700, Drew Moseley wrote: What is the best way to have NetworkManager/nm-applet __not__ request wireless secrets? We have a scenario where we are attempting to connect to the network and we do not have a user at the system. In this scenario we just want to fail this particular connection without marking the connection as bad. We want to attempt another connection with the same secrets later, ala background polling. Drew I had a similiar issue, a user that doesn't have a clue what the wifi password is, so I spent lots of time to tell that 'all you need to do is press that reconnect button duh!' There were some problems with wifi device that caused it to timeout like that. Now I use latest -git of NM and wpa_supplicant, latest wireless-testing and I never see that dialog, even after many minutes, if I on purpose set invalid password. Maybe this got fixed? Best regards, Maxim Levitsky ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
