Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 1:41 AM, Slokunshialgo [EMAIL PROTECTED] wrote: I know I posted something about this awhile ago, but thinking about it a bit more, a couple of questions and ideas have arisen in my mind. For those who may not have read this before, the idea is to have something using NetworkManager to automatically log in to web-authenticated networks (ie: hotspots in a cafe) when it connects to specific networks. I have three ideas on how to implement this, but they all revolve around the idea of having a Firefox extension that would listen to dbus signals being sent by nm, and when told to, would go to a specific webpage to log in, using Firefox's password storage. 1) Have nm check to see if Firefox is open, if not, open it and send the signal 2) Make nm have nothing to do with the extension, but merely sending its regular signals and FF picking them up 3) Make nm send modified signals specifically for the autologin, letting any program pick them up (such as network name, URL to visit, etc) Judging by before, I doubt #1 would be the best idea (forcing FF to be installed is not good), #2 may or may not work, but I think #3 would be best. To get around whether FF is open or not, a small program could be written to start on login (separate from nm) that would listen for the signals, start FF, and pass it along. As for the technical side of this, it's primarily, what sort of information does nm send through dbus, and are multiple programs able to pick up on it? Opinions, ideas, information? Add a dispatcher script that runs xdg-open $url for a specific SSID you need it for and you're done. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 04, 2008 at 03:02:04PM +0100, Patryk Zawadzki wrote: On Tue, Nov 4, 2008 at 2:46 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote: The benefit is that the user is not redirected to the hotspot webpage, but is logged in automatically. It might seem a silly difference, but is a requested feature. Our customer requires WISPr/WSP capabilities and I'm very interested in the outcome of this thread. I agree that it would be nice to be automatically logged in, but I don't clearly see how why we need firefox to do that authentication. Another idea would be to write a tray applet that recognizes when NM goes online and the probes whether it gets redirected to hotspot site. If thats the case the tray thing would authenticate and would allow users also to end that session later (from the tray). This could be done by nm applet itself, but as we dont really have a plugin infrastructure for that yet I would suggest to make that a standalone tray tool until we have more experience on what we really want here. Would that work? I think the important question is: isn't this a direct violation of the ToS? By automatically doing something that was created to enforce user interaction you are creating a tool that silently accepts all licenses, terms and conditions without notifying the user. From what i understand the user would still have to provide some form of credentials. Thus the user would be presented at minimum an initial login dialog, where he probably could opt-in for auto login in the future. - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 3:06 PM, Pablo Martí [EMAIL PROTECTED] wrote: No, the very first time you interact with the hotspot, you'll be redirected to the login page anyway. You'll have to accept the ToS and *pay*. The use-case discussed here is after paying for the access, not having to explicitly log in the hotspot every time you want to use afterwards Then it's entirely doable as a Firefox extension without any NM integration (check if the page is the login one, submit data and reload) or easily doable using python, dbus and curl (wait for connection, check SSID, if matching call curl with necessary POST payload - could be read from the keyring). -- Patryk Zawadzki ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 2:46 PM, Alexander Sack [EMAIL PROTECTED] wrote:
On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote:
On Tue, Nov 4, 2008 at 1:21 PM, Alexander Sack [EMAIL PROTECTED] wrote:
On Tue, Nov 04, 2008 at 01:29:22PM +0200, Tambet Ingo wrote:
On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack [EMAIL PROTECTED] wrote:
On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote:
Add a dispatcher script that runs xdg-open $url for a specific SSID
you need it for and you're done.
Do we have per-user dispatcher scripts or are you suggesting to open
the browser as root here :) ?
Ok, you're right, but listening for a DBus signal from a user process
isn't all that hard either. Or do you prefer NM executing firefox
directly (as root) like the original mail suggested?
Dbus would work. However, I dont really understand the use-case this
is supposed to cover. The browser usually redirects to the login site
anyway? What benefit would the user by such a firefox extension?
The benefit is that the user is not redirected to the hotspot webpage,
but is logged in automatically. It might seem a silly difference, but
is a requested feature. Our customer requires WISPr/WSP capabilities
and I'm very interested in the outcome of this thread.
I agree that it would be nice to be automatically logged in, but I
don't clearly see how why we need firefox to do that authentication.
Another idea would be to write a tray applet that recognizes when NM
goes online and the probes whether it gets redirected to hotspot
site. If thats the case the tray thing would authenticate and would
allow users also to end that session later (from the tray). This could
be done by nm applet itself, but as we dont really have a plugin
infrastructure for that yet I would suggest to make that a standalone
tray tool until we have more experience on what we really want
here. Would that work?
Sure! I also think that the Firefox approach is not the right one, is
just that I'm not very fond on NM's dispatcher
architecture/capabilities. I kinda like the description/mockup given
here [0]. Marcelo asked in nm-list 1 year ago and he was pointed to a
dispatcher script[1].
[0] http://blog.marcelotoledo.org/2007/09/01/network-manager-with-wispr-support/
[1]
http://mail.gnome.org/archives/networkmanager-list/2007-September/msg2.html
- Alexander
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
El mar, 04-11-2008 a las 15:02 +0100, Patryk Zawadzki escribió: On Tue, Nov 4, 2008 at 2:46 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote: The benefit is that the user is not redirected to the hotspot webpage, but is logged in automatically. It might seem a silly difference, but is a requested feature. Our customer requires WISPr/WSP capabilities and I'm very interested in the outcome of this thread. I agree that it would be nice to be automatically logged in, but I don't clearly see how why we need firefox to do that authentication. Another idea would be to write a tray applet that recognizes when NM goes online and the probes whether it gets redirected to hotspot site. If thats the case the tray thing would authenticate and would allow users also to end that session later (from the tray). This could be done by nm applet itself, but as we dont really have a plugin infrastructure for that yet I would suggest to make that a standalone tray tool until we have more experience on what we really want here. Would that work? I think the important question is: isn't this a direct violation of the ToS? By automatically doing something that was created to enforce user interaction you are creating a tool that silently accepts all licenses, terms and conditions without notifying the user. Uhmmm not really sure... It seems it tries to be a standard thing: WISPr was the first step toward standardizing HotSpot authentication.[0] Moreover, this is not the first time this protocol is around this list[1], although the answer was the same as the beginning of this thread [0]http://en.wikipedia.org/wiki/WISPr [1]http://mail.gnome.org/archives/networkmanager-list/2007-September/msg0.html Kind regards, -- Daniel Baeyens ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 3:21 PM, Alexander Sack [EMAIL PROTECTED] wrote:
On Tue, Nov 04, 2008 at 03:11:13PM +0100, Pablo Martí wrote:
Sure! I also think that the Firefox approach is not the right one, is
just that I'm not very fond on NM's dispatcher
architecture/capabilities. I kinda like the description/mockup given
here [0]. Marcelo asked in nm-list 1 year ago and he was pointed to a
dispatcher script[1].
[0]
http://blog.marcelotoledo.org/2007/09/01/network-manager-with-wispr-support/
[1]
http://mail.gnome.org/archives/networkmanager-list/2007-September/msg2.html
OK thanks for the links. I really think this can be done outside of NM
applet to things started.
Writing a wispr-applet that listens to D-Bus events from NM and which
does the wispr probing and authentication business should be fairly
easy.
Thanks for the input Alexander, much appreciated. What do other
developers think of this approach? Tambet? Dan?
Regards,
- Alexander
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 4:54 PM, Pablo Martí [EMAIL PROTECTED] wrote: On Tue, Nov 4, 2008 at 3:21 PM, Alexander Sack [EMAIL PROTECTED] wrote: OK thanks for the links. I really think this can be done outside of NM applet to things started. Writing a wispr-applet that listens to D-Bus events from NM and which does the wispr probing and authentication business should be fairly easy. Thanks for the input Alexander, much appreciated. What do other developers think of this approach? Tambet? Dan? I agree it should be done outside of NM. That's the point of having a stable (yeah, yeah, we'll get to that eventually) public DBus API. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 4:10 PM, Tambet Ingo [EMAIL PROTECTED] wrote:
On Tue, Nov 4, 2008 at 4:54 PM, Pablo Martí [EMAIL PROTECTED] wrote:
On Tue, Nov 4, 2008 at 3:21 PM, Alexander Sack [EMAIL PROTECTED] wrote:
OK thanks for the links. I really think this can be done outside of NM
applet to things started.
Writing a wispr-applet that listens to D-Bus events from NM and which
does the wispr probing and authentication business should be fairly
easy.
Thanks for the input Alexander, much appreciated. What do other
developers think of this approach? Tambet? Dan?
I agree it should be done outside of NM. That's the point of having a
stable (yeah, yeah, we'll get to that eventually) public DBus API.
Alright, thanks! I was still doubting between a separate process and a
dispatcher script, but it seems that the consensus is a separate
process. Thanks all for the input!
Tambet
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote: On Tue, Nov 4, 2008 at 1:21 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 01:29:22PM +0200, Tambet Ingo wrote: On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote: Add a dispatcher script that runs xdg-open $url for a specific SSID you need it for and you're done. Do we have per-user dispatcher scripts or are you suggesting to open the browser as root here :) ? Ok, you're right, but listening for a DBus signal from a user process isn't all that hard either. Or do you prefer NM executing firefox directly (as root) like the original mail suggested? Dbus would work. However, I dont really understand the use-case this is supposed to cover. The browser usually redirects to the login site anyway? What benefit would the user by such a firefox extension? The benefit is that the user is not redirected to the hotspot webpage, but is logged in automatically. It might seem a silly difference, but is a requested feature. Our customer requires WISPr/WSP capabilities and I'm very interested in the outcome of this thread. I agree that it would be nice to be automatically logged in, but I don't clearly see how why we need firefox to do that authentication. Another idea would be to write a tray applet that recognizes when NM goes online and the probes whether it gets redirected to hotspot site. If thats the case the tray thing would authenticate and would allow users also to end that session later (from the tray). This could be done by nm applet itself, but as we dont really have a plugin infrastructure for that yet I would suggest to make that a standalone tray tool until we have more experience on what we really want here. Would that work? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Problems with NM and a AccessPoint
Good evening, I went with a notebook in the range of my AccessPoint and the NetworkManager need 40s to create with it. Is it normal? How can I get informations about the problem? How can I start the NM with debug informations? Thanks -- Mfg der bijektive Homomorphismus ist ein Isomorphismus Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
location of DHCP lease files
Hi -
I've noticed that the native Fedora ifup-eth script puts its lease files into
/var/lib/dhclient/dhclient-${DEVICE}.leases
but, NetworkManager puts the lease files into
/var/run/dhclient-${DEVICE}.lease
It looks like this is coming from nm-dhcp-manager.h, which builds
NM_DHCP_MANAGER_RUN_DIR from LOCALSTATEDIR and the constant /run. The
localstatedir is set to /var in the top level Makefile.
Is this inconsistency related to running an SVN version (r4254), when compared
to an official Fedora yum update?
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Problems with NM seeing 3G modem
Hello, I am a new user to Linux and tried to find the proper resources before seeking help. I am using NM 0.7.0-lp.0025.o.4 I am using a Sierra Wireless 881 WCDMA modem with ATT As far as I can tell, I successfully installed the modem driver and it is listed as /dev/ttyUSB0 Unfortunately, when try to dial using wvdial, it says the device is busy. So I can't verify that it is working. Secondarily, if I open the NM window, I am only able to add a wired or WiFi connection. So I'm not sure why I can't add the 3G device that the docs refer to. I'm happy to read more, so if there is an existing FAQ that will help, please point me in that direction. I am using this as my baseline: http://www.sierrawireless.com/faq/ShowFAQ.aspx?ID=1076 Thank you! ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: location of DHCP lease files
On Tue, 2008-11-04 at 11:47 -0500, Miner, Jonathan W (US SSA) wrote:
Hi -
I've noticed that the native Fedora ifup-eth script puts its lease files
into
/var/lib/dhclient/dhclient-${DEVICE}.leases
but, NetworkManager puts the lease files into
/var/run/dhclient-${DEVICE}.lease
Correct. NM uses different lease files because in the near future,
we'll want to use separate lease files for _each connection_. Since
many machines move around, it's pretty pointless to use the same lease
file for your home AP as for your work AP.
What happens right now is that you'll get a lease from work, dhclient
will cache it, and then when you come home it'll try to renew that work
lease at home, leading to DHCP lag. That's bad.
So even if the lease files _did_ stay in the same place as dhclient puts
them, you'd have a lot more lease files anyway. But, once we modify NM
to handle leasefile-per-connection, we should probably move them back
to /var/lib/dhclient just to they are persistent.
I assume you're worried about persistence of the lease across boots?
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, 2008-11-04 at 15:54 +0100, Pablo Martí wrote: On Tue, Nov 4, 2008 at 3:21 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 03:11:13PM +0100, Pablo Martí wrote: Sure! I also think that the Firefox approach is not the right one, is just that I'm not very fond on NM's dispatcher architecture/capabilities. I kinda like the description/mockup given here [0]. Marcelo asked in nm-list 1 year ago and he was pointed to a dispatcher script[1]. [0] http://blog.marcelotoledo.org/2007/09/01/network-manager-with-wispr-support/ [1] http://mail.gnome.org/archives/networkmanager-list/2007-September/msg2.html OK thanks for the links. I really think this can be done outside of NM applet to things started. Writing a wispr-applet that listens to D-Bus events from NM and which does the wispr probing and authentication business should be fairly easy. Thanks for the input Alexander, much appreciated. What do other developers think of this approach? Tambet? Dan? Shouldn't be part of NM, but NM should expose all the necessary information to allow auto-login to be possible using external tools. If that includes requesting WSP information explicitly from the DHCP server, that's great, we should add that. The DHCP information is already exposed over D-Bus and thus any app that listens for NM events should be able to get it. You can tie specific logins pretty easily to each connection's UUID, thus if you know that your Starbucks connection just came up (as opposed to any other connection) you could certainly match that up with stored credentials and try to auto-login with those first before doing any probing or whatever. Basically, if the AP is at least WPA encrypted, and NM connected, there's a 95% chance that nobody is spoofing the connection, and that you really are connected to Starbucks, so you can save some time probing by just trying stored Starbucks auth info first, maybe. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: Hello, I am a new user to Linux and tried to find the proper resources before seeking help. I am using NM 0.7.0-lp.0025.o.4 I am using a Sierra Wireless 881 WCDMA modem with ATT As far as I can tell, I successfully installed the modem driver and it is listed as /dev/ttyUSB0 Unfortunately, when try to dial using wvdial, it says the device is busy. So I can't verify that it is working. Secondarily, if I open the NM window, I am only able to add a wired or WiFi connection. So I'm not sure why I can't add the 3G device that the docs refer to. Is this with Ubuntu? Ubuntu has changed the mobile broadband connection creation sequence so you may need to file a launchpad bug. Does 'lshal | grep -i gsm' show anything, and if so, what? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Cannot list wireless networks
On Mon, 2008-11-03 at 18:42 -0600, fREW Schmidt wrote: Ok, so I got networkmanager up and running and I can't see any networks listed in the add new connection screen. I am using knetworkmanager as an interface, but I presume that it's a lower level issue, so I'll post the output to nm-tool here: When this occurs, as root, does 'iwlist eth1 scan' show any output? Dan FrewSchmidt2 [8158] % nm-tool NetworkManager Tool State: connected - Device: eth0 Type: Wired Driver:8139too State: unmanaged Default: no HW Address:00:00:00:00:00:00 Capabilities: Supported: yes Carrier Detect: yes Speed: 100 Mb/s Wired Settings - Device: eth1 Type: 802.11 WiFi Driver:ipw2200 State: unmanaged Default: no HW Address:00:00:00:00:00:00 Capabilities: Supported: yes Wireless Settings WEP Encryption: yes WPA Encryption: yes WPA2 Encryption: yes Wireless Access Points Any ideas? -- -fREW ___ 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: Problems with NM and a AccessPoint
On Tue, 2008-11-04 at 17:24 +0100, Marco Franke wrote: Good evening, I went with a notebook in the range of my AccessPoint and the NetworkManager need 40s to create with it. Is it normal? Not usually, no, but it depends greatly on how strong the AP's signal is. How can I get informations about the problem? How can I start the NM with debug informations? If you could try to create a plain wpa_supplicant config file for your AP, and attempt a connection with that, that is the best way to debug whether it's an NM or a driver issue. If you need help creating that file or running the supplicant, let us know. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: location of DHCP lease files
I understand the need for multiple lease files, based on network.
My concern was the two different directories being used. I was trying to solve
a network problem, and couldn't understand why my lease files were several
months old... Then I discovered that NM was putting lease files somewhere else.
Persistence across boots would require some cooperation with the DHCP server,
which, in my case, may give me a new IP each time I boot. (It's some 3rd party,
Windows based DHCP/DNS solution, which I don't manage)
- Jon
-Original Message-
From: Dan Williams [mailto:[EMAIL PROTECTED]
Sent: Tue 11/4/2008 1:41 PM
To: Miner, Jonathan W (US SSA)
Cc: networkmanager-list@gnome.org
Subject:Re: location of DHCP lease files
On Tue, 2008-11-04 at 11:47 -0500, Miner, Jonathan W (US SSA) wrote:
Hi -
I've noticed that the native Fedora ifup-eth script puts its lease files
into
/var/lib/dhclient/dhclient-${DEVICE}.leases
but, NetworkManager puts the lease files into
/var/run/dhclient-${DEVICE}.lease
Correct. NM uses different lease files because in the near future,
we'll want to use separate lease files for _each connection_. Since
many machines move around, it's pretty pointless to use the same lease
file for your home AP as for your work AP.
What happens right now is that you'll get a lease from work, dhclient
will cache it, and then when you come home it'll try to renew that work
lease at home, leading to DHCP lag. That's bad.
So even if the lease files _did_ stay in the same place as dhclient puts
them, you'd have a lot more lease files anyway. But, once we modify NM
to handle leasefile-per-connection, we should probably move them back
to /var/lib/dhclient just to they are persistent.
I assume you're worried about persistence of the lease across boots?
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
I just submitted a patch for this card up stream? What distro are you running? You try Ubuntu Intrepid ? You will need hal entries for it to find it in your distro. I use the ATT Sierra Wireless now. Only thing with Ubuntu Intrepid (as temporary work around till network manager gets updated), you will need to remove the APN entry. After that it will just works. I use the PCMCIA version of this card with my Thinkpad T61 daily. Jerone On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: Hello, I am a new user to Linux and tried to find the proper resources before seeking help. I am using NM 0.7.0-lp.0025.o.4 I am using a Sierra Wireless 881 WCDMA modem with ATT As far as I can tell, I successfully installed the modem driver and it is listed as /dev/ttyUSB0 Unfortunately, when try to dial using wvdial, it says the device is busy. So I can't verify that it is working. Secondarily, if I open the NM window, I am only able to add a wired or WiFi connection. So I'm not sure why I can't add the 3G device that the docs refer to. I'm happy to read more, so if there is an existing FAQ that will help, please point me in that direction. I am using this as my baseline: http://www.sierrawireless.com/faq/ShowFAQ.aspx?ID=1076 Thank you! ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote: On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: Hello, I am a new user to Linux and tried to find the proper resources before seeking help. I am using NM 0.7.0-lp.0025.o.4 I am using a Sierra Wireless 881 WCDMA modem with ATT As far as I can tell, I successfully installed the modem driver and it is listed as /dev/ttyUSB0 Unfortunately, when try to dial using wvdial, it says the device is busy. So I can't verify that it is working. Secondarily, if I open the NM window, I am only able to add a wired or WiFi connection. So I'm not sure why I can't add the 3G device that the docs refer to. Is this with Ubuntu? Ubuntu has changed the mobile broadband connection creation sequence so you may need to file a launchpad bug. the NM version from above doesnt look ubuntu/deb stylish. Its definitly not a version of the official archives ;). - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: location of DHCP lease files
On Tue, 2008-11-04 at 13:52 -0500, Miner, Jonathan W (US SSA) wrote:
I understand the need for multiple lease files, based on network.
My concern was the two different directories being used. I was trying to
solve a network problem, and couldn't understand why my lease files were
several months old... Then I discovered that NM was putting lease files
somewhere else.
Persistence across boots would require some cooperation with the DHCP server,
which, in my case, may give me a new IP each time I boot. (It's some 3rd
party, Windows based DHCP/DNS solution, which I don't manage)
I'm not opposed to switching back to where dhclient really puts them if
that works better for people. I think the original reason to put them
in /var/run _was_ to blow them away on reboot, but since there's a lot
of suspend/hibernate going on these days thats no longer valid.
Dan
- Jon
-Original Message-
From: Dan Williams [mailto:[EMAIL PROTECTED]
Sent: Tue 11/4/2008 1:41 PM
To: Miner, Jonathan W (US SSA)
Cc: networkmanager-list@gnome.org
Subject: Re: location of DHCP lease files
On Tue, 2008-11-04 at 11:47 -0500, Miner, Jonathan W (US SSA) wrote:
Hi -
I've noticed that the native Fedora ifup-eth script puts its lease files
into
/var/lib/dhclient/dhclient-${DEVICE}.leases
but, NetworkManager puts the lease files into
/var/run/dhclient-${DEVICE}.lease
Correct. NM uses different lease files because in the near future,
we'll want to use separate lease files for _each connection_. Since
many machines move around, it's pretty pointless to use the same lease
file for your home AP as for your work AP.
What happens right now is that you'll get a lease from work, dhclient
will cache it, and then when you come home it'll try to renew that work
lease at home, leading to DHCP lag. That's bad.
So even if the lease files _did_ stay in the same place as dhclient puts
them, you'd have a lot more lease files anyway. But, once we modify NM
to handle leasefile-per-connection, we should probably move them back
to /var/lib/dhclient just to they are persistent.
I assume you're worried about persistence of the lease across boots?
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
On Tue, 2008-11-04 at 20:15 +0100, Alexander Sack wrote: On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote: On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: Hello, I am a new user to Linux and tried to find the proper resources before seeking help. I am using NM 0.7.0-lp.0025.o.4 I am using a Sierra Wireless 881 WCDMA modem with ATT As far as I can tell, I successfully installed the modem driver and it is listed as /dev/ttyUSB0 Unfortunately, when try to dial using wvdial, it says the device is busy. So I can't verify that it is working. Secondarily, if I open the NM window, I am only able to add a wired or WiFi connection. So I'm not sure why I can't add the 3G device that the docs refer to. Is this with Ubuntu? Ubuntu has changed the mobile broadband connection creation sequence so you may need to file a launchpad bug. the NM version from above doesnt look ubuntu/deb stylish. Its definitly not a version of the official archives ;). I guess I assumed that lp mean launchpad or something, but I'm wrong, it's always PPA :) My bad. And the winner is: Linpus Lite! (Acer Aspire). tcwalker, it's 100% likely that your modem is not correctly tagged by HAL, and thus is not recognized by NM. Can you attach the output of 'lshal' (typed into a terminal) to a reply when the 881 is plugged in? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 04, 2008 at 01:29:22PM +0200, Tambet Ingo wrote: On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote: Add a dispatcher script that runs xdg-open $url for a specific SSID you need it for and you're done. Do we have per-user dispatcher scripts or are you suggesting to open the browser as root here :) ? Ok, you're right, but listening for a DBus signal from a user process isn't all that hard either. Or do you prefer NM executing firefox directly (as root) like the original mail suggested? Dbus would work. However, I dont really understand the use-case this is supposed to cover. The browser usually redirects to the login site anyway? What benefit would the user by such a firefox extension? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager API review
On Tue, Nov 4, 2008 at 11:01 AM, Tomas Kovacik [EMAIL PROTECTED] wrote: and this is HAL .fdi problem?: dmesg: [82410.648181] usb 2-2: new full speed USB device using uhci_hcd and address 2 [82410.821948] usb 2-2: configuration #1 chosen from 1 choice [82411.050542] cdc_acm 2-2:1.1: ttyACM0: USB ACM device [82411.053368] cdc_acm 2-2:1.3: ttyACM1: USB ACM device [82411.055246] usbcore: registered new interface driver cdc_acm [82411.055256] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters SE w810i, usb cable No, you don't get HAL logging from dmesg. It's OK to have multiple serial devices per one physical modem, but it's a bug to have 'lshal | grep -i gsm | wc -l' print out higher number than one when you have a single modem. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 1:21 PM, Alexander Sack [EMAIL PROTECTED] wrote:
On Tue, Nov 04, 2008 at 01:29:22PM +0200, Tambet Ingo wrote:
On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack [EMAIL PROTECTED] wrote:
On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote:
Add a dispatcher script that runs xdg-open $url for a specific SSID
you need it for and you're done.
Do we have per-user dispatcher scripts or are you suggesting to open
the browser as root here :) ?
Ok, you're right, but listening for a DBus signal from a user process
isn't all that hard either. Or do you prefer NM executing firefox
directly (as root) like the original mail suggested?
Dbus would work. However, I dont really understand the use-case this
is supposed to cover. The browser usually redirects to the login site
anyway? What benefit would the user by such a firefox extension?
The benefit is that the user is not redirected to the hotspot webpage,
but is logged in automatically. It might seem a silly difference, but
is a requested feature. Our customer requires WISPr/WSP capabilities
and I'm very interested in the outcome of this thread.
Pablo
- Alexander
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager API review
Hi Tambet, So the first thing that draw me off is that we are stupidly mapping the HAL devices 1:1 to our devices. That is wrong. We should not do this. So for example my Option card has three TTYs and one network device. This all is one device. Currently it shows up as three devices. The number of TTY (control, data or whatever) is an implementation and should not be exposed via the API. So we have to be smart with this. With the generic implementation, MM maps a HAL device with modem.command_sets property as a single device. So if you got 3, it means your HAL .fdi file is incorrect. I don't see how that can be. It was the HSO card and it might need more tweaks than usual. Besides kernel patches ;) The second thing is that the Manager interface talks about devices, while the main interface to the hardware is called Modem. So that should be consistent. Either we call them devices or modems. Agreed. I initially had modems everywhere, but then thought it would be more consistent in the big picture if it resembled org.freedesktop.DeviceKit.Disks (http://hal.freedesktop.org/docs/DeviceKit-disks/) interface. So EnumerateModems was renamed to EnumerateDevices while the modem interfaces didn't change. Just the reason behind it. Then just rename the interface to Device and everything will be fine. The Modem interface has a Connect method call that takes a parameter number. This makes no sense whatsoever. Connect should not take any arguments it should connect with whatever has been configured or be smart and auto-configure it. Especially since you don't know if you are using a real number or actually an APN or something else. Modem interface is for all modems. Landline, GSM, CDMA, ... It is up to the specific implementation to validate and use the number. All the modems I've ever seen (and the dial command 'D' in the spec) take a number, so it makes perfect sense to me. Actually it doesn't. You should have some kind of method to setup your device. So for example call Device.Setup(dict). You can give it a key Number or key APN and then it will do the right calls. Actually the magic ATD*99*# crap is just something ETSI invented because every OS was using weird and broken dialer scripts at that time. There are proper commands when attaching a GPRS/UMTS link. Also the HSO based cards don't use numbers. If you do the Setup method call once, then you can call Connect/ Disconnect multiple times without modifying your setup or giving it a number all the time. It just no consistent to give the APN one way and the number the other way. And also some device don't use numbers at all. We should really hide this implementation detail. And then we have Enable with a parameter. Don't do that. Just add Enable and Disable methods. Otherwise the API looks weird. Also signals like Connected, Enabled etc. are missing. It doesn't look weird to me. In real life you don't have two switches to turn things on/off, and to me it would look weird if my modem has two physical buttons: one to turn it on, and another to turn it off. In short it's a personal opinion and doesn't make much sense to argue about. It is weird in conjunction with Connect/Disconnect and then Enable takes a parameter where TRUE means enable and FALSE means disble. There is no need for Connected and Enabled signals because the method to Enable/Connect doesn't return before it's done. That does not mean MM is not async, it accepts other commands and is responsive while Enable/Connect/any other method is pending. The async here means if other applications wants to monitor the status. For example if you have an applet just indicating if it is connected or not (but never calling Connect by itself). For that we need the signals. So the split between Modem interface and Gsm.Card make no real sense to me. I would just convert everything into properties or create a GetProperties method to retrieve one dictionary with all the information. All the GetImei, GetImsi calls only create round-trips to D-Bus that can be avoided. If one technology doesn't have IMSI, then this property is just missing. Again, it's your opinion. In my opinion, when I need IMEI, I don't want the modem to issue 50 AT commands to get all the properties. We can cache the properties. Since when doing Enable we can issue the AT commands for the values that are not changing and then just cache them. And for setting things like the APN etc, you can use writable properties or a SetProperty method. So you could just set all properties and then call Connect. To make this fully async, a signal PropertyChanged would be needed, too. So Enable(bool) looks weird to you and then you suggest the whole API to consist of 2 methods (SetStuff() and GetStuff()). Again, your personal opinion I don't agree with. I don't care about the Enable and how it is done, but you have to see the whole picture here. Doing
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 2:13 PM, Pablo Martí [EMAIL PROTECTED] wrote:
On Tue, Nov 4, 2008 at 1:21 PM, Alexander Sack [EMAIL PROTECTED] wrote:
On Tue, Nov 04, 2008 at 01:29:22PM +0200, Tambet Ingo wrote:
On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack [EMAIL PROTECTED] wrote:
On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote:
Add a dispatcher script that runs xdg-open $url for a specific SSID
you need it for and you're done.
Do we have per-user dispatcher scripts or are you suggesting to open
the browser as root here :) ?
Ok, you're right, but listening for a DBus signal from a user process
isn't all that hard either. Or do you prefer NM executing firefox
directly (as root) like the original mail suggested?
Dbus would work. However, I dont really understand the use-case this
is supposed to cover. The browser usually redirects to the login site
anyway? What benefit would the user by such a firefox extension?
The benefit is that the user is not redirected to the hotspot webpage,
but is logged in automatically. It might seem a silly difference, but
is a requested feature. Our customer requires WISPr/WSP capabilities
and I'm very interested in the outcome of this thread.
s/WSP//g mental corruption here :)
Pablo
- Alexander
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 2:46 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 02:13:37PM +0100, Pablo Martí wrote: The benefit is that the user is not redirected to the hotspot webpage, but is logged in automatically. It might seem a silly difference, but is a requested feature. Our customer requires WISPr/WSP capabilities and I'm very interested in the outcome of this thread. I agree that it would be nice to be automatically logged in, but I don't clearly see how why we need firefox to do that authentication. Another idea would be to write a tray applet that recognizes when NM goes online and the probes whether it gets redirected to hotspot site. If thats the case the tray thing would authenticate and would allow users also to end that session later (from the tray). This could be done by nm applet itself, but as we dont really have a plugin infrastructure for that yet I would suggest to make that a standalone tray tool until we have more experience on what we really want here. Would that work? I think the important question is: isn't this a direct violation of the ToS? By automatically doing something that was created to enforce user interaction you are creating a tool that silently accepts all licenses, terms and conditions without notifying the user. -- Patryk Zawadzki ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager API review
On Tue, Nov 4, 2008 at 3:54 AM, Marcel Holtmann [EMAIL PROTECTED] wrote: So the first thing that draw me off is that we are stupidly mapping the HAL devices 1:1 to our devices. That is wrong. We should not do this. So for example my Option card has three TTYs and one network device. This all is one device. Currently it shows up as three devices. The number of TTY (control, data or whatever) is an implementation and should not be exposed via the API. So we have to be smart with this. With the generic implementation, MM maps a HAL device with modem.command_sets property as a single device. So if you got 3, it means your HAL .fdi file is incorrect. The second thing is that the Manager interface talks about devices, while the main interface to the hardware is called Modem. So that should be consistent. Either we call them devices or modems. Agreed. I initially had modems everywhere, but then thought it would be more consistent in the big picture if it resembled org.freedesktop.DeviceKit.Disks (http://hal.freedesktop.org/docs/DeviceKit-disks/) interface. So EnumerateModems was renamed to EnumerateDevices while the modem interfaces didn't change. Just the reason behind it. The Modem interface has a Connect method call that takes a parameter number. This makes no sense whatsoever. Connect should not take any arguments it should connect with whatever has been configured or be smart and auto-configure it. Especially since you don't know if you are using a real number or actually an APN or something else. Modem interface is for all modems. Landline, GSM, CDMA, ... It is up to the specific implementation to validate and use the number. All the modems I've ever seen (and the dial command 'D' in the spec) take a number, so it makes perfect sense to me. And then we have Enable with a parameter. Don't do that. Just add Enable and Disable methods. Otherwise the API looks weird. Also signals like Connected, Enabled etc. are missing. It doesn't look weird to me. In real life you don't have two switches to turn things on/off, and to me it would look weird if my modem has two physical buttons: one to turn it on, and another to turn it off. In short it's a personal opinion and doesn't make much sense to argue about. There is no need for Connected and Enabled signals because the method to Enable/Connect doesn't return before it's done. That does not mean MM is not async, it accepts other commands and is responsive while Enable/Connect/any other method is pending. So the split between Modem interface and Gsm.Card make no real sense to me. I would just convert everything into properties or create a GetProperties method to retrieve one dictionary with all the information. All the GetImei, GetImsi calls only create round-trips to D-Bus that can be avoided. If one technology doesn't have IMSI, then this property is just missing. Again, it's your opinion. In my opinion, when I need IMEI, I don't want the modem to issue 50 AT commands to get all the properties. And for setting things like the APN etc, you can use writable properties or a SetProperty method. So you could just set all properties and then call Connect. To make this fully async, a signal PropertyChanged would be needed, too. So Enable(bool) looks weird to you and then you suggest the whole API to consist of 2 methods (SetStuff() and GetStuff()). Again, your personal opinion I don't agree with. And on that matter, please don't use enums since higher level languages don't really have the concept of includes from a C definition. So if you wanna give the band information you can just say gsm900, gsm1800 etc. Also for the mode having things like connect, connecting etc. make it a lot easier to develop and debug. And when using dbus-monitor is shows up in clear text. Every UI needs to translate enums to localized strings and back so all the possible values need to be defined anyway. It's easier to do it with integers than strings. Some things like GetRegistrationInfo are just better separated into properties or key/value pairs in a dictionary. That keeps the API small and also flexible for future changes. This is something I finally agree on! :) So the network details on GSM are not really that interesting at all. I would leave them out for now. However I do think that representing every network as object path would be a better approach here. Network details and the signal quality are the biggest reason I started ModemManager, the most often asked features in this list. Why would they need to be DBus objects with paths? What methods do you think a network would have? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: blank lines added to /etc/hosts [PATCH]
I think this will fix my issue... only append the newline if we're not parsing
the last line of the file.
--- src/NetworkManagerPolicy.c.orig 2008-11-03 09:33:08.0 -0500
+++ src/NetworkManagerPolicy.c 2008-11-04 17:02:39.0 -0500
@@ -306,7 +306,8 @@
if (add_line) {
g_string_append (new_contents, *line);
- g_string_append_c (new_contents, '\n');
+if (*(line+1)) /* if not the last line */
+ g_string_append_c (new_contents, '\n');
}
}
-Original Message-
From: [EMAIL PROTECTED] on behalf of Miner, Jonathan W (US SSA)
Sent: Tue 11/4/2008 4:54 PM
To: NetworkManager-list@gnome.org
Cc:
Subject:blank lines added to /etc/hosts
Hi -
Each time I unplug, or reconnect my network cable, a blank line gets added to
the end of /etc/hosts.
# wc -l /etc/hosts
4 /etc/hosts
(unplug my cable...)
# wc -l /etc/hosts
5 /etc/hosts
(plug cable back in...)
# wc -l /etc/hosts
6 /etc/hosts
Guessing that it is the g_string_append_c() call on line 309 of
src/NetworkManagerPolicy.c which could needlessly add '\n' characters?
___
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: Network Manager Autologin
On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote: Add a dispatcher script that runs xdg-open $url for a specific SSID you need it for and you're done. Do we have per-user dispatcher scripts or are you suggesting to open the browser as root here :) ? Ok, you're right, but listening for a DBus signal from a user process isn't all that hard either. Or do you prefer NM executing firefox directly (as root) like the original mail suggested? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote: On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: Hello, I am a new user to Linux and tried to find the proper resources before seeking help. I am using NM 0.7.0-lp.0025.o.4 I am using a Sierra Wireless 881 WCDMA modem with ATT As far as I can tell, I successfully installed the modem driver and it is listed as /dev/ttyUSB0 Unfortunately, when try to dial using wvdial, it says the device is busy. So I can't verify that it is working. Secondarily, if I open the NM window, I am only able to add a wired or WiFi connection. So I'm not sure why I can't add the 3G device that the docs refer to. Is this with Ubuntu? Ubuntu has changed the mobile broadband connection creation sequence so you may need to file a launchpad bug. the NM version from above doesnt look ubuntu/deb stylish. Its definitly not a version of the official archives ;). - Alexander Correct. As Dan noted in a subsequent post, this is Linpus Lite as bundled on the Aspire One. uname -a Linux localhost 2.6.23.9lw #105 SMP PREEMPT Fri Jun 27 18:56:59 EDT 2008 i686 i686 i386 GNU/Linux --Ted ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote: Add a dispatcher script that runs xdg-open $url for a specific SSID you need it for and you're done. Do we have per-user dispatcher scripts or are you suggesting to open the browser as root here :) ? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
On Tue, 2008-11-04 at 14:25 -0800, [EMAIL PROTECTED] wrote: Dan Williams [EMAIL PROTECTED] wrote: On Tue, 2008-11-04 at 20:15 +0100, Alexander Sack wrote: On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote: On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote: Hello, I am a new user to Linux and tried to find the proper resources before seeking help. I am using NM 0.7.0-lp.0025.o.4 I am using a Sierra Wireless 881 WCDMA modem with ATT As far as I can tell, I successfully installed the modem driver and it is listed as /dev/ttyUSB0 Unfortunately, when try to dial using wvdial, it says the device is busy. So I can't verify that it is working. Secondarily, if I open the NM window, I am only able to add a wired or WiFi connection. So I'm not sure why I can't add the 3G device that the docs refer to. Is this with Ubuntu? Ubuntu has changed the mobile broadband connection creation sequence so you may need to file a launchpad bug. the NM version from above doesnt look ubuntu/deb stylish. Its definitly not a version of the official archives ;). I guess I assumed that lp mean launchpad or something, but I'm wrong, it's always PPA :) My bad. And the winner is: Linpus Lite! (Acer Aspire). tcwalker, it's 100% likely that your modem is not correctly tagged by HAL, and thus is not recognized by NM. Can you attach the output of 'lshal' (typed into a terminal) to a reply when the 881 is plugged in? Dan Yes, it is Linpus Lite on an Aspire One. Not knowing the relevant bits of the output, I've copied it all below. Apologize in advance for the long string. Ok, the issue is that your modem is not recognized by the copy of HAL that Linpus Lite ships. Can you attach your copy of: /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi and also the output of /sbin/lsusb when the card is plugged in? Thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN Only for this address range equivalent
Dan Williams wrote: You can add custom routes in the IPv4 tab of the connection editor for the VPN connection. You can also check ignore automatically provided routes if you don't care what the server sends you. Dan, Would you please elaborate on how to do that? I just need to set up my network so that most of the traffic will go through a direct Internet connection while all the traffic for a small number of IP addresses (starting with 172.17.x.x in my case) will go through VPN. Only for this address range worked like a charm in the previous version of NM and now I am stuck trying to achieve the same thing with NM0.7. The UI of the Routes page is really confusing - what am I supposed to put as Prefix and Metric? So far, no matter what I enter all the traffic goes to VPN. I would be grateful for any help. Cheers, Piotr -- View this message in context: http://www.nabble.com/VPN-%22Only-for-this-address-range%22-equivalent-tp20236932p20333154.html Sent from the Gnome - NetworkManager mailing list archive at Nabble.com. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with NM seeing 3G modem
On Tue, 2008-11-04 at 15:18 -0800, [EMAIL PROTECTED] wrote:
Dan Williams [EMAIL PROTECTED] wrote:
On Tue, 2008-11-04 at 14:25 -0800, [EMAIL PROTECTED] wrote:
Dan Williams [EMAIL PROTECTED] wrote:
On Tue, 2008-11-04 at 20:15 +0100, Alexander Sack wrote:
On Tue, Nov 04, 2008 at 01:48:40PM -0500, Dan Williams wrote:
On Tue, 2008-11-04 at 00:58 -0800, [EMAIL PROTECTED] wrote:
Hello, I am a new user to Linux and tried to find the proper
resources before seeking help.
I am using NM 0.7.0-lp.0025.o.4
I am using a Sierra Wireless 881 WCDMA modem with ATT
As far as I can tell, I successfully installed the modem driver
and it is listed as /dev/ttyUSB0
Unfortunately, when try to dial using wvdial, it says the device
is busy. So I can't verify that it is working.
Secondarily, if I open the NM window, I am only able to add a
wired or WiFi connection. So I'm not sure why I can't add the 3G
device that the docs refer to.
Is this with Ubuntu? Ubuntu has changed the mobile broadband
connection
creation sequence so you may need to file a launchpad bug.
the NM version from above doesnt look ubuntu/deb stylish. Its
definitly not a version of the official archives ;).
I guess I assumed that lp mean launchpad or something, but I'm wrong,
it's always PPA :) My bad.
And the winner is: Linpus Lite! (Acer Aspire). tcwalker, it's 100%
likely that your modem is not correctly tagged by HAL, and thus is not
recognized by NM.
Can you attach the output of 'lshal' (typed into a terminal) to a reply
when the 881 is plugged in?
Dan
Yes, it is Linpus Lite on an Aspire One.
Not knowing the relevant bits of the output, I've copied it all below.
Apologize in advance for the long string.
Ok, the issue is that your modem is not recognized by the copy of HAL
that Linpus Lite ships. Can you attach your copy of:
/usr/share/hal/fdi/information/10freedesktop/10-modem.fdi
and also the output of
/sbin/lsusb
when the card is plugged in?
Thanks!
Dan
Hello Dan,
I don't have a file named 10-modem.fdi, however I have two that seem similar.
They are included below. The 10-usb-gsm.fdi file seems to have been added
as a part of the bundled mobile partner update from Acer/Linpus. To the
best of my knowledge, there is no Huawei modem in this notebook. The output
from lsusb is below.
[EMAIL PROTECTED] 10freedesktop]$ cat 10-usb-modem.fdi
?xml version=1.0 encoding=UTF-8?
deviceinfo version=0.2
device
match key=serial.device contains=/dev/ttyHS
append key=info.capabilities type=strlistmodem/append
append key=modem.command_sets type=strlistGSM-07.07/append
/match
/device
device
match key=info.linux.driver string=hso
merge key=info.product type=string3G modem/merge
merge key=usb.product type=string3G modem/merge
/match
/device
/deviceinfo
[EMAIL PROTECTED] 10freedesktop]$ cat 10-usb-gsm.fdi
!-- Huawei GSM mobile --
match key=@info.parent:usb.vendor_id int=0x12d1
match key=@info.parent:usb.product_id int=0x1003
match key=@info.parent:usb.interface.number int=0
append key=info.capabilities type=strlistmodem/append
append key=modem.command_sets type=strlistGSM-07.07/append
append key=modem.command_sets type=strlistGSM-07.05/append
/match
/match
/match
Paste the following in right after this section above:
!-- Sierra Wireless 881 --
match key=@info.parent:usb.vendor_id int=0x1199
match key=@info.parent:usb.product_id int=0x6856
match key=@info.parent:usb.interface.number int=0
append key=info.capabilities type=strlistmodem/append
append key=modem.command_sets type=strlistGSM-07.07/append
append key=modem.command_setstype=strlistGSM-07.05/append
/match
/match
/match
Then reboot and NM should see the card.
Dan
[EMAIL PROTECTED] 10freedesktop]$ lsusb
Bus 005 Device 001: ID :
Bus 004 Device 001: ID :
Bus 003 Device 005: ID 045e:00e1 Microsoft Corp.
Bus 003 Device 001: ID :
Bus 002 Device 010: ID 1199:6856 Sierra Wireless, Inc.
Bus 002 Device 001: ID :
Bus 001 Device 004: ID 064e:d101 Acer Crystal Eye Webcam
Bus 001 Device 001: ID :
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: VPN Only for this address range equivalent
On Tue, 2008-11-04 at 14:59 -0800, the_leech wrote: Dan Williams wrote: You can add custom routes in the IPv4 tab of the connection editor for the VPN connection. You can also check ignore automatically provided routes if you don't care what the server sends you. Dan, Would you please elaborate on how to do that? I just need to set up my network so that most of the traffic will go through a direct Internet connection while all the traffic for a small number of IP addresses (starting with 172.17.x.x in my case) will go through VPN. Only for this address range worked like a charm in the previous version of NM and now I am stuck trying to achieve the same thing with NM0.7. The UI of the Routes page is really confusing - what am I supposed to put as Prefix and Metric? This is fair criticism; we do need better explanations and help text. You enter the same information there that you entered in the Only for these addresses box. The Address range and prefix are required (just like they were before) but you can leave the Gateway and Metric boxes blank if you like. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Support for openvpn --auth option
Hello everybody,
this is my first post to this list, and it combines submitting a patch
for a new feature, and a request for help.
The attached patch is against NetworkManager-openvpn-0.7.0-16.svn4027
(Fedora 9) and adds support for the --auth option of openvpn. The
configuration import feature works, calling openvpn with the --auth
option works, creating and changing a VPN configuration using the
--auth option works, but one problem still exists: The GtkComboBox
for this option in the advanced popup does not show the current
state of this option. (But it works as expected when changing the
value.)
I've tried changing nm-openvpn-dialog.glade with glade-3 and vi many
times, and double- and triple-checked the code in auth-helpers.c,
which I've copied and modified from the handling of the cipher option.
But I'm stuck and didn't get any further for hours. So I'm asking
here for help.
Please, can some glade and gtk expert look at this and tell me
how this issue could be fixed?
I need this patch for compatibilty with the openvpn setup of an
Astaro firewall. The current state is enough to get a working
VPN connection, but I would rather have this feature completed
and included in the NetworkManager-0.7.0 release. ;-)
Thanks,
Robert
diff -u NetworkManager-openvpn-0.7.0/properties/auth-helpers.c.hmacauth
NetworkManager-openvpn-0.7.0/properties/auth-helpers.c
--- NetworkManager-openvpn-0.7.0/properties/auth-helpers.c.hmacauth
2008-08-29 15:30:50.0 +0200
+++ NetworkManager-openvpn-0.7.0/properties/auth-helpers.c 2008-11-02
23:47:27.0 +0100
@@ -585,6 +585,7 @@
NM_OPENVPN_KEY_TAP_DEV,
NM_OPENVPN_KEY_PROTO_TCP,
NM_OPENVPN_KEY_CIPHER,
+ NM_OPENVPN_KEY_AUTH,
NM_OPENVPN_KEY_TA_DIR,
NM_OPENVPN_KEY_TA,
NULL
@@ -734,6 +735,50 @@
g_strfreev (items);
}
+#define HMACAUTH_COL_NAME 0
+#define HMACAUTH_COL_DEFAULT 1
+
+static void
+populate_auth_combo (GtkComboBox *box, const char *hmacauth)
+{
+ GtkListStore *store;
+ GtkTreeIter iter;
+ gboolean user_added = FALSE;
+ gchar **item;
+ gchar *items[] = {
+ NM_OPENVPN_AUTH_NONE,
+ NM_OPENVPN_AUTH_MD5,
+ NM_OPENVPN_AUTH_SHA1,
+ NULL
+ };
+
+ store = gtk_list_store_new (2, G_TYPE_STRING, G_TYPE_INT);
+
+ /* Add default option which won't pass --auth to openvpn */
+ gtk_list_store_append (store, iter);
+ gtk_list_store_set (store, iter,
+ HMACAUTH_COL_NAME, _(Default),
+ HMACAUTH_COL_DEFAULT, TRUE, -1);
+
+ /* Add options */
+ for (item = items; *item; item++) {
+ gtk_list_store_append (store, iter);
+ gtk_list_store_set (store, iter,
+ HMACAUTH_COL_NAME, *item,
+ HMACAUTH_COL_DEFAULT, FALSE, -1);
+ if (hmacauth !strcmp (*item, hmacauth)) {
+ gtk_combo_box_set_active_iter (box, iter);
+ user_added = TRUE;
+ }
+ }
+
+ if (!user_added)
+ gtk_combo_box_set_active (box, 0);
+
+ gtk_combo_box_set_model (box, GTK_TREE_MODEL (store));
+ g_object_unref (store);
+}
+
static void
tls_auth_toggled_cb (GtkWidget *widget, gpointer user_data)
{
@@ -840,6 +885,10 @@
value = g_hash_table_lookup (hash, NM_OPENVPN_KEY_CIPHER);
populate_cipher_combo (GTK_COMBO_BOX (widget), value);
+ widget = glade_xml_get_widget (xml, hmacauth_combo);
+ value = g_hash_table_lookup (hash, NM_OPENVPN_KEY_AUTH);
+ populate_auth_combo (GTK_COMBO_BOX (widget), value);
+
widget = glade_xml_get_widget (xml, tls_auth_checkbutton);
value = g_hash_table_lookup (hash, NM_OPENVPN_KEY_TA);
if (value strlen (value))
@@ -944,6 +993,20 @@
}
}
+ widget = glade_xml_get_widget (xml, hmacauth_combo);
+ model = gtk_combo_box_get_model (GTK_COMBO_BOX (widget));
+ if (gtk_combo_box_get_active_iter (GTK_COMBO_BOX (widget),
iter)) {
+ char *hmacauth = NULL;
+ gboolean is_default = TRUE;
+
+ gtk_tree_model_get (model, iter,
+ HMACAUTH_COL_NAME, hmacauth,
+ HMACAUTH_COL_DEFAULT, is_default,
-1);
+ if (!is_default hmacauth) {
+ g_hash_table_insert (hash, g_strdup
(NM_OPENVPN_KEY_AUTH), g_strdup (hmacauth));
+ }
+ }
+
widget = glade_xml_get_widget (xml, tls_auth_checkbutton);
if (gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (widget))) {
