VPN (PPTP) connection timeout
Dear all, I connect to my adsl modem (speedtouch 546 v6) with a VPN PPTP connection to establish the internet connection. Evrything works fine, but after a certain time of inactivity the connection doesn't work anymore, well to tell the truth application like torrents or VoIP still works but I can not browse pages (seems like that the dns is not working) Do you kindly have any idea on how I can solve the problem, I have tried to change the lcp-echo-failure and MTU MRU values but still have the problem. Thank you very much Enrico ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wpa_supplicant cli works, but NM insists "wireless is disabled"
On Tue, Sep 30, 2008 at 10:27 PM, Andrew <[EMAIL PROTECTED]> wrote: > (I say this in response to your mentioning "upstream" -- a word i've not > heard before but assume has something to do with committing code changes for > general use) This concept basically refers to the water flowing. Upstream is the place where the authors and maintainers do their magic to create software. Once released it is then taken by the downstream consisting of distribution packagers and sometimes users (depending on the type of software) for general use. Sorry for offtopic. -- Patryk Zawadzki ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wpa_supplicant cli works, but NM insists "wireless is disabled"
>On Tue, 2008-09-30 at 15:18 -0400, Andrew wrote: >> >On Tue, 2008-09-30 at 12:22 -0400, Andrew wrote: >> >> >On Tue, 2008-09-30 at 06:30 -0400, Andrew wrote: >> >> >> >On Mon, 2008-09-29 at 18:44 -0400, Andrew wrote: >> >> >> >> >>On Sun, 2008-09-28 at 19:21 -0400, Andrew wrote: >> >> >> >> >>> Hello, >> >> >> >> >>> >> >> >> >> >>> I have appealed to the Fedora Forum, but no one seems to have a > >> >clue >> >> > >> >> >> >> >there. >> >> >> >> >>> >> >> >> >> >>> Here is the thread: >> >> >> >> >>> http://forums.fedoraforum.org/showthread.php?t=199562 >> >> >> >> >>> >> >> >> >> >>> (A quick synopsis of the thread: >> >> >> >> >>> >> >> >> >> >>> I've activated/deactivated everything i could think of, related >to >> > >> >> >> >> >>NetworkManager; yet, everything wireless is grayed out in the >> >applet. >> >> >> >> >>> >> >> >> >> >>> But wpa_supplicant (cli) works! >> >> >> >> >>> >> >> >> >> >>> Additional info (beyond above thread): >> >> >> >> >>> >> >> >> >> >>> I compiled the latest NetworkManager svn; still same grayed out > >> >> >> >behavior. >> >> >> >> >>> >> >> >> >> >>> ) >> >> >> >> >>> >> >> >> >> >>> I tried looking in the source and tracing the calls to and from > >> >> >> >> >>nm_client_wireless_get_enabled (if that's even a function) but, >> >> >ignorant >> >> >> >of >> >> >> >> >C, >> >> >> >> >>didn't get far. >> >> >> >> >>> >> >> >> >> >>> Please help! >> >> >> >> >> >> >> >> >> >>Does NM think wireless is disabled because a HAL killswitch is >> >> >reporting >> >> >> >> > >> >> >> >> >Don't know enough about HAL to answer the above. (Where would i >> >look?) >> >> >> >> > >> >> >> >> >>that it's off? Could you post some logs from /var/log/messages >> >from >> >> >> >> >>when NM starts up? >> >> >> >> > >> >> >> >> >please see attachment. (i've X'ed out some addresses >> >(::) >> >> >> >> >> >> >> >> >> >> >> >> ooops. The list strips attachment. Here is a web link to the same > >> >> >> >/var/log/messages chunk: >> >> >> >> >> >> >> >> http://www.flight.us/bugs/var_messages_nm_chunk.txt >> >> >> > >> >> >> >What's the output of: >> >> >> > >> >> >> >dellWirelessCtl >> >> >> >> >> >> Here it is: http://www.flight.us/bugs/dellWirelessCtl.txt >> >> >> >> >> >> OK, it appears that the "problem"(?) /does/ originate in the BIOS (I >did >> > >> >> >present this hypothesis at the Fedora forum, but no one took that path, > >> >which >> >> >now seems correct) >> >> > >> >> >Yeah, if dellWirelessCtl says the WLAN is disabled, then that's what >the >> >> >BIOS thinks. The best thing I think you could do is file a bug against >> >> >'libsmbios' package in Fedora bugzilla and the Dell guys will try to >> >> >help you debug. >> >> >> >> Yes, of course, my **internal** wifi card /is/ disabled in the BIOS! >> >> (You may not have read my FedoraForum thread) >> >> >> >> dellWirelessCtl is reporting correctly regarding the internal card >(only). >> >> >> >> But why should this concern the external, removable cards?? >> > >> >Because you've flipped the "kill my wireless" button. If you didn't >> >want to kill your wireless, don't flip the button. It's a decision to >> >treat any killswitch as killing all wireless devices of the same class. >> >I don't believe it's useful to have individual killswitches apply to >> >individual devices of the same class. >> >> I certainly did not intentionally disable _ALL_ wifi devices; only the >onboard one is disabled. > >You flipped the "kill my wireless" switch which NetworkManager (by >design) takes as the sign you wish to disable all your wireless devices. > >> So, why does wpa_supplicant see my external wifi device (wlanX), and use and >connect with it happily, inspite of this killswitch? > >Because the kernel rfkill layer isn't completely integrated yet and thus >its not actually getting killed, though NM should be setting the >device's TX power off. > >> Does anyone know where in the NM code is the querying of the status at >issue? I would like to play with the code. >> >> (perhaps in src/nm-hal-manager.c ? There seems to be a kswitch_err method) > >That's the right place, but upstream isn't going to accept that code at >this time. It's a policy decision; I made the decision to keep things >simple and direct and interpret the user's intent as disabling wireless >when the rfkill switch is turned on. Dan, even if I were some sort of C and networking guru and veteran member of your development team, still i would not seek to impose any modifications to your code. (And I am light years away from all the above) (I say this in response to your mentioning "upstream" -- a word i've not heard before but assume has something to do with committing code changes for general use). Your generous contribution of skill has made things easier for millions. However, could you please provide a quick hack to meet my rare need, to keep my wifi class always enabled, regardless of what the BIOS
Re: wpa_supplicant cli works, but NM insists "wireless is disabled"
On Tue, 2008-09-30 at 15:18 -0400, Andrew wrote: > >On Tue, 2008-09-30 at 12:22 -0400, Andrew wrote: > >> >On Tue, 2008-09-30 at 06:30 -0400, Andrew wrote: > >> >> >On Mon, 2008-09-29 at 18:44 -0400, Andrew wrote: > >> >> >> >>On Sun, 2008-09-28 at 19:21 -0400, Andrew wrote: > >> >> >> >>> Hello, > >> >> >> >>> > >> >> >> >>> I have appealed to the Fedora Forum, but no one seems to have a > >clue > >> > > >> >> >> >there. > >> >> >> >>> > >> >> >> >>> Here is the thread: > >> >> >> >>> http://forums.fedoraforum.org/showthread.php?t=199562 > >> >> >> >>> > >> >> >> >>> (A quick synopsis of the thread: > >> >> >> >>> > >> >> >> >>> I've activated/deactivated everything i could think of, related > >> >> >> >>> to > > > >> >> >> >>NetworkManager; yet, everything wireless is grayed out in the > >applet. > >> >> >> >>> > >> >> >> >>> But wpa_supplicant (cli) works! > >> >> >> >>> > >> >> >> >>> Additional info (beyond above thread): > >> >> >> >>> > >> >> >> >>> I compiled the latest NetworkManager svn; still same grayed out > >> >> >behavior. > >> >> >> >>> > >> >> >> >>> ) > >> >> >> >>> > >> >> >> >>> I tried looking in the source and tracing the calls to and from > >> >> >> >>nm_client_wireless_get_enabled (if that's even a function) but, > >> >ignorant > >> >> >of > >> >> >> >C, > >> >> >> >>didn't get far. > >> >> >> >>> > >> >> >> >>> Please help! > >> >> >> >> > >> >> >> >>Does NM think wireless is disabled because a HAL killswitch is > >> >reporting > >> >> >> > > >> >> >> >Don't know enough about HAL to answer the above. (Where would i > >look?) > >> >> >> > > >> >> >> >>that it's off? Could you post some logs from /var/log/messages > >from > >> >> >> >>when NM starts up? > >> >> >> > > >> >> >> >please see attachment. (i've X'ed out some addresses > >(::) > >> >> >> > >> >> >> > >> >> >> ooops. The list strips attachment. Here is a web link to the same > >> >> >/var/log/messages chunk: > >> >> >> > >> >> >> http://www.flight.us/bugs/var_messages_nm_chunk.txt > >> >> > > >> >> >What's the output of: > >> >> > > >> >> >dellWirelessCtl > >> >> > >> >> Here it is: http://www.flight.us/bugs/dellWirelessCtl.txt > >> >> > >> >> OK, it appears that the "problem"(?) /does/ originate in the BIOS (I > >> >> did > > > >> >present this hypothesis at the Fedora forum, but no one took that path, > >which > >> >now seems correct) > >> > > >> >Yeah, if dellWirelessCtl says the WLAN is disabled, then that's what the > >> >BIOS thinks. The best thing I think you could do is file a bug against > >> >'libsmbios' package in Fedora bugzilla and the Dell guys will try to > >> >help you debug. > >> > >> Yes, of course, my **internal** wifi card /is/ disabled in the BIOS! > >> (You may not have read my FedoraForum thread) > >> > >> dellWirelessCtl is reporting correctly regarding the internal card (only). > >> > >> But why should this concern the external, removable cards?? > > > >Because you've flipped the "kill my wireless" button. If you didn't > >want to kill your wireless, don't flip the button. It's a decision to > >treat any killswitch as killing all wireless devices of the same class. > >I don't believe it's useful to have individual killswitches apply to > >individual devices of the same class. > > I certainly did not intentionally disable _ALL_ wifi devices; only the > onboard one is disabled. You flipped the "kill my wireless" switch which NetworkManager (by design) takes as the sign you wish to disable all your wireless devices. > So, why does wpa_supplicant see my external wifi device (wlanX), and use and > connect with it happily, inspite of this killswitch? Because the kernel rfkill layer isn't completely integrated yet and thus its not actually getting killed, though NM should be setting the device's TX power off. > Does anyone know where in the NM code is the querying of the status at issue? > I would like to play with the code. > > (perhaps in src/nm-hal-manager.c ? There seems to be a kswitch_err method) That's the right place, but upstream isn't going to accept that code at this time. It's a policy decision; I made the decision to keep things simple and direct and interpret the user's intent as disabling wireless when the rfkill switch is turned on. Dan > TIA > andrew > > >Dan > > > >> Why should NetworkManager get info from the BIOS regarding the *internal* > >device, and, based on that, disable Wifi globally, for ALL the cards, > >including the removable ones, which are configured and working perfectly > >(with > >wpa_supplicant) > >> > >> (the goal here is to use my external, removable Atheros card, and keep the > >built-in card disabled in the BIOS) > >> > >> This looks like an algorithmic oversight in the NM's code. Also, I would > >think, an easy fix (if only i knew C!) > >> > >> Thanks in advance! > >> > >> andrew > >> > >> > >> >Dan > >> > > >> >> For a quick & dirty fix: any way to force the disabled/enabl
Re: wpa_supplicant cli works, but NM insists "wireless is disabled"
>On Tue, 2008-09-30 at 12:22 -0400, Andrew wrote: >> >On Tue, 2008-09-30 at 06:30 -0400, Andrew wrote: >> >> >On Mon, 2008-09-29 at 18:44 -0400, Andrew wrote: >> >> >> >>On Sun, 2008-09-28 at 19:21 -0400, Andrew wrote: >> >> >> >>> Hello, >> >> >> >>> >> >> >> >>> I have appealed to the Fedora Forum, but no one seems to have a >clue >> > >> >> >> >there. >> >> >> >>> >> >> >> >>> Here is the thread: >> >> >> >>> http://forums.fedoraforum.org/showthread.php?t=199562 >> >> >> >>> >> >> >> >>> (A quick synopsis of the thread: >> >> >> >>> >> >> >> >>> I've activated/deactivated everything i could think of, related to > >> >> >> >>NetworkManager; yet, everything wireless is grayed out in the >applet. >> >> >> >>> >> >> >> >>> But wpa_supplicant (cli) works! >> >> >> >>> >> >> >> >>> Additional info (beyond above thread): >> >> >> >>> >> >> >> >>> I compiled the latest NetworkManager svn; still same grayed out >> >> >behavior. >> >> >> >>> >> >> >> >>> ) >> >> >> >>> >> >> >> >>> I tried looking in the source and tracing the calls to and from >> >> >> >>nm_client_wireless_get_enabled (if that's even a function) but, >> >ignorant >> >> >of >> >> >> >C, >> >> >> >>didn't get far. >> >> >> >>> >> >> >> >>> Please help! >> >> >> >> >> >> >> >>Does NM think wireless is disabled because a HAL killswitch is >> >reporting >> >> >> > >> >> >> >Don't know enough about HAL to answer the above. (Where would i >look?) >> >> >> > >> >> >> >>that it's off? Could you post some logs from /var/log/messages >from >> >> >> >>when NM starts up? >> >> >> > >> >> >> >please see attachment. (i've X'ed out some addresses >(::) >> >> >> >> >> >> >> >> >> ooops. The list strips attachment. Here is a web link to the same >> >> >/var/log/messages chunk: >> >> >> >> >> >> http://www.flight.us/bugs/var_messages_nm_chunk.txt >> >> > >> >> >What's the output of: >> >> > >> >> >dellWirelessCtl >> >> >> >> Here it is: http://www.flight.us/bugs/dellWirelessCtl.txt >> >> >> >> OK, it appears that the "problem"(?) /does/ originate in the BIOS (I did > >> >present this hypothesis at the Fedora forum, but no one took that path, >which >> >now seems correct) >> > >> >Yeah, if dellWirelessCtl says the WLAN is disabled, then that's what the >> >BIOS thinks. The best thing I think you could do is file a bug against >> >'libsmbios' package in Fedora bugzilla and the Dell guys will try to >> >help you debug. >> >> Yes, of course, my **internal** wifi card /is/ disabled in the BIOS! >> (You may not have read my FedoraForum thread) >> >> dellWirelessCtl is reporting correctly regarding the internal card (only). >> >> But why should this concern the external, removable cards?? > >Because you've flipped the "kill my wireless" button. If you didn't >want to kill your wireless, don't flip the button. It's a decision to >treat any killswitch as killing all wireless devices of the same class. >I don't believe it's useful to have individual killswitches apply to >individual devices of the same class. I certainly did not intentionally disable _ALL_ wifi devices; only the onboard one is disabled. So, why does wpa_supplicant see my external wifi device (wlanX), and use and connect with it happily, inspite of this killswitch? Does anyone know where in the NM code is the querying of the status at issue? I would like to play with the code. (perhaps in src/nm-hal-manager.c ? There seems to be a kswitch_err method) TIA andrew >Dan > >> Why should NetworkManager get info from the BIOS regarding the *internal* >device, and, based on that, disable Wifi globally, for ALL the cards, >including the removable ones, which are configured and working perfectly (with >wpa_supplicant) >> >> (the goal here is to use my external, removable Atheros card, and keep the >built-in card disabled in the BIOS) >> >> This looks like an algorithmic oversight in the NM's code. Also, I would >think, an easy fix (if only i knew C!) >> >> Thanks in advance! >> >> andrew >> >> >> >Dan >> > >> >> For a quick & dirty fix: any way to force the disabled/enabled switch in >the >> >NM source? Again, i tried to find this in the source and failed. Where is > >> >it? >> >> >> >> I wonder if this can be considered a bug or glitch -- my situation >> >apparently presents a need for NM to be more user-configurable here. >> >> >> >> Thanks. >> >> >> >> >HAL found a killswitch and NM is honoring the setting of that >killswitch >> >> >apparently. >> >> > >> >> >Dan >> >> > >> >> >> >> >> >> >> >> >> >NM keeps saying "wlan1: link is not ready" >> >> >> > >> >> >> >Yet, I can do "iwconfig" and "iwlist" with NO problem whatsoever, >with >> >good >> >> > >> >> >> >results. Plus, as i said earlier (this seems VERY significant), i >can >> >> >connect >> >> >> >with wpa_supplicant no prob (all the while NM is saying "wireless is > >> >> >> >disabled"!) >> >> >> > >> >> >> >>It could also be that you've disabled the devi
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
Dan The values are what is supplied to the computer from the modem as part of the standard. We cant change what the modem produces. See http://www.3gpp.org/ftp/Specs/html-info/27007.htm section 7.3 command +COPS -- Stuart Ward M +44 7782325143 On Tue, Sep 30, 2008 at 5:38 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > On Tue, 2008-09-30 at 16:58 +0100, Stuart Ward wrote: > > > > > > Because there is no case where a modem supports HSUPA but not > > HSDPA, and > > thus HSUPA and HSPA are essentially equal. Since HSPA _is_ > > HSDPA + > > HSUPA, it's pointless to have a separate HSUPA. > > > > This signal is sent by the modem to the computer to indicate the > > capability of the connection. So this is athe result of the > > negociation of the modem with the network to see what is supported. So > > even if the modem supports HSUPA the network may not, equally with > > HSDPA > > Right, but wouldn't that just mean the modem would send HSDPA or EDGE > then? > > > It is possible that an operator will offer different network > > capabilities to subs and it may be that HSUPA is supported but not > > HSDPA. > > Highly doubtful; but I guess it's possible. > > > Dose that clarify the situation? > > Yes, but the values in question are an enum and not a bitfield. If you > think it's really likely that HSUPA would be provided but not HSDPA, > then I guess it might be approprate to have both HSUPA and HSPA > separately. > > Dan > > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wpa_supplicant cli works, but NM insists "wireless is disabled"
On Tue, 2008-09-30 at 12:22 -0400, Andrew wrote:
> >On Tue, 2008-09-30 at 06:30 -0400, Andrew wrote:
> >> >On Mon, 2008-09-29 at 18:44 -0400, Andrew wrote:
> >> >> >>On Sun, 2008-09-28 at 19:21 -0400, Andrew wrote:
> >> >> >>> Hello,
> >> >> >>>
> >> >> >>> I have appealed to the Fedora Forum, but no one seems to have a
> >> >> >>> clue
> >
> >> >> >there.
> >> >> >>>
> >> >> >>> Here is the thread:
> >> >> >>> http://forums.fedoraforum.org/showthread.php?t=199562
> >> >> >>>
> >> >> >>> (A quick synopsis of the thread:
> >> >> >>>
> >> >> >>> I've activated/deactivated everything i could think of, related to
> >> >> >>NetworkManager; yet, everything wireless is grayed out in the applet.
> >> >> >>>
> >> >> >>> But wpa_supplicant (cli) works!
> >> >> >>>
> >> >> >>> Additional info (beyond above thread):
> >> >> >>>
> >> >> >>> I compiled the latest NetworkManager svn; still same grayed out
> >> >behavior.
> >> >> >>>
> >> >> >>> )
> >> >> >>>
> >> >> >>> I tried looking in the source and tracing the calls to and from
> >> >> >>nm_client_wireless_get_enabled (if that's even a function) but,
> >ignorant
> >> >of
> >> >> >C,
> >> >> >>didn't get far.
> >> >> >>>
> >> >> >>> Please help!
> >> >> >>
> >> >> >>Does NM think wireless is disabled because a HAL killswitch is
> >reporting
> >> >> >
> >> >> >Don't know enough about HAL to answer the above. (Where would i look?)
> >> >> >
> >> >> >>that it's off? Could you post some logs from /var/log/messages from
> >> >> >>when NM starts up?
> >> >> >
> >> >> >please see attachment. (i've X'ed out some addresses (::)
> >> >>
> >> >>
> >> >> ooops. The list strips attachment. Here is a web link to the same
> >> >/var/log/messages chunk:
> >> >>
> >> >> http://www.flight.us/bugs/var_messages_nm_chunk.txt
> >> >
> >> >What's the output of:
> >> >
> >> >dellWirelessCtl
> >>
> >> Here it is: http://www.flight.us/bugs/dellWirelessCtl.txt
> >>
> >> OK, it appears that the "problem"(?) /does/ originate in the BIOS (I did
> >present this hypothesis at the Fedora forum, but no one took that path,
> >which
> >now seems correct)
> >
> >Yeah, if dellWirelessCtl says the WLAN is disabled, then that's what the
> >BIOS thinks. The best thing I think you could do is file a bug against
> >'libsmbios' package in Fedora bugzilla and the Dell guys will try to
> >help you debug.
>
> Yes, of course, my **internal** wifi card /is/ disabled in the BIOS!
> (You may not have read my FedoraForum thread)
>
> dellWirelessCtl is reporting correctly regarding the internal card (only).
>
> But why should this concern the external, removable cards??
Because you've flipped the "kill my wireless" button. If you didn't
want to kill your wireless, don't flip the button. It's a decision to
treat any killswitch as killing all wireless devices of the same class.
I don't believe it's useful to have individual killswitches apply to
individual devices of the same class.
Dan
> Why should NetworkManager get info from the BIOS regarding the *internal*
> device, and, based on that, disable Wifi globally, for ALL the cards,
> including the removable ones, which are configured and working perfectly
> (with wpa_supplicant)
>
> (the goal here is to use my external, removable Atheros card, and keep the
> built-in card disabled in the BIOS)
>
> This looks like an algorithmic oversight in the NM's code. Also, I would
> think, an easy fix (if only i knew C!)
>
> Thanks in advance!
>
> andrew
>
>
> >Dan
> >
> >> For a quick & dirty fix: any way to force the disabled/enabled switch in
> >> the
> >NM source? Again, i tried to find this in the source and failed. Where is
> >it?
> >>
> >> I wonder if this can be considered a bug or glitch -- my situation
> >apparently presents a need for NM to be more user-configurable here.
> >>
> >> Thanks.
> >>
> >> >HAL found a killswitch and NM is honoring the setting of that killswitch
> >> >apparently.
> >> >
> >> >Dan
> >> >
> >> >>
> >> >>
> >> >> >NM keeps saying "wlan1: link is not ready"
> >> >> >
> >> >> >Yet, I can do "iwconfig" and "iwlist" with NO problem whatsoever, with
> >good
> >> >
> >> >> >results. Plus, as i said earlier (this seems VERY significant), i can
> >> >connect
> >> >> >with wpa_supplicant no prob (all the while NM is saying "wireless is
> >> >> >disabled"!)
> >> >> >
> >> >> >>It could also be that you've disabled the device in
> >> >> >>system-config-network, in which case the menu will say the device is
> >> >> >>"unmanaged".
> >> >> >
> >> >> >I have played with system-config-network every which way, before.
> >"wlan1"
> >> >(and
> >> >> >"wlan0") are both assigned to NM, ("Controlled by NM" is checked).
> >(wlan0
> >> >> >versus wlan1 is created depending on which atheros card i insert -- i
> >have
> >> >two
> >> >> >at my disposal)
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>dan
> >
___
NetworkManager-list mailin
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
On Tue, 2008-09-30 at 16:58 +0100, Stuart Ward wrote: > > > Because there is no case where a modem supports HSUPA but not > HSDPA, and > thus HSUPA and HSPA are essentially equal. Since HSPA _is_ > HSDPA + > HSUPA, it's pointless to have a separate HSUPA. > > This signal is sent by the modem to the computer to indicate the > capability of the connection. So this is athe result of the > negociation of the modem with the network to see what is supported. So > even if the modem supports HSUPA the network may not, equally with > HSDPA Right, but wouldn't that just mean the modem would send HSDPA or EDGE then? > It is possible that an operator will offer different network > capabilities to subs and it may be that HSUPA is supported but not > HSDPA. Highly doubtful; but I guess it's possible. > Dose that clarify the situation? Yes, but the values in question are an enum and not a bitfield. If you think it's really likely that HSUPA would be provided but not HSDPA, then I guess it might be approprate to have both HSUPA and HSPA separately. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with Networkmanager 0.7
On Tue, 2008-09-30 at 23:09 +0800, Ronald Wiplinger (Lists) wrote: > Dan Williams wrote: > > On Tue, 2008-09-30 at 09:30 +0800, Ronald Wiplinger (Lists) wrote: > > > >> Dan Williams wrote: > >> > >>> On Mon, 2008-09-29 at 07:18 +0800, Ronald Wiplinger (Lists) wrote: > >>> > >>> > I had to install 0.7 in order to get my E220 to work. Works fine! I use > Ubuntu 8.0.4 on my EeePC 1000 / 901 > > However, I got some other problems with it. > > 1. Each time I connect to the network I have to key in the Shared key, > although it is saved. I can go to Edit that connection and even show the > key. What gone wrong with that? Why does it not take the key > automatically? How to fix it? > > > >>> It might be that the card isn't connecting within the timeout, thus NM > >>> asks for a new key because it thinks your key is wrong. Does it connect > >>> the second time if you just hit "OK" without editing the key itself? > >>> This could indicate a driver problem. What driver is 8.04 using on your > >>> machine? > >>> > >>> > >> There is no "OK", there is a Cancel or type in Key and Connect. > >> > > > > Ah, I mean connect. Does it work if you just hit "Connect" again? NM > > only asks for keys if the driver fails to associate to the access point. > > > > > > Now I am getting totally frustrated! > I "had" to install Networkmanager 0.7, because I also use an E220 to > connect to the Internet. > > This morning an "update" arrived via Ubuntu updates. First smile after > rebooting was: GREAT it connects now automatically to the network again! > But I was / am very frustrated, because I have now to disconnect in > order to open an application. > While I am connected ANY (did I mention ANY) application, including > terminal, ... will just show "starting up ..." and die silently. I believe Alexander fixed that issue today already in an additional update. Dan > I have now to disconnect, open all applications I might need now and can > then connect again (no password question, it knows my password ;-) ) and > can continue to work. Not the way I like to work forever, hopefully > somebody finds the bug soon and gives me the solution how to install it, > because, if I am connected, I cannot open the update, and if I am not > connected, I cannot download the update, > > bye > > Ronald > > > > >> If I hit twice Cancel I get the icon of the Network manager in the top > >> bar with the information box, that I am not connected. > >> Left mouse button shows me my wireless connection as found, but not > >> connected. > >> Selecting it requires me to key in the key and connect. > >> > >> HOW can I avoid that? > >> There seems to be a lost of "communication" between the network > >> manager and my passwords, since Seahorse does know all my wireless > >> keys. > >> > >> How can I see which "driver" my system is using? Which driver do you > >> mean? > >> > > > > An '/sbin/lsmod' would show which modules are loaded from which we can > > deduce what driver is used. Otherwise, try '/usr/bin/nm-tool' which > > shows what NetworkManager thinks. > > > > > As mentioned above I have an EeePC 1000 and 901. While 901 does not ask > me for the key, 1000 does. The OS is on a SD card cloned to the other > one. Somewhere these two versions drifted apart. > > 2. I have two users, and I cannot get Networkmanager to work at the > second users account. I though it will be globally installed. > > > >>> Each user stores their own networks. Fast user switching probably > >>> doesn't work right now, but if you log in as the other user (without > >>> fast user switching) it should work. I'd probably need logs > >>> from /var/log/daemon.log to diagnose. > >>> > >>> > >>> > >> Cool! > >> > >> Serious, I do not get a Networkmanager icon there, so how can I start > >> a connection? > >> > > > > Fast user switching needs some work still. > > > > > 3. Most annoying is that, if for any reason I lose the wireless > connection, the icon changes to no connection. The right click on the > icon shows me ticked Enable Network. It cannot be unticked. There is no > Enable Wireless. And a ping to a remote site works with and without > plugged in Ethernet cable, so that I cannot say which connection it > actually is using, since the left click on the icon gives me only the > choice to use VPN, which I have not setup at all. > > > >>> Can you explain this a bit more? Are you plugged into both wired and > >>> wireless at the same time? If "Enable Wireless" doesn't exist, yet you > >>> see the wireless device in the menu when you left-click, that isn't > >>> something that upstream NetworkManager does. You might want to file a > >>> bug in Launchpad on that particular one. > >>> > >>> > >>> > >> Exactly! >
Re: wpa_supplicant cli works, but NM insists "wireless is disabled"
>On Tue, 2008-09-30 at 06:30 -0400, Andrew wrote:
>> >On Mon, 2008-09-29 at 18:44 -0400, Andrew wrote:
>> >> >>On Sun, 2008-09-28 at 19:21 -0400, Andrew wrote:
>> >> >>> Hello,
>> >> >>>
>> >> >>> I have appealed to the Fedora Forum, but no one seems to have a clue
>
>> >> >there.
>> >> >>>
>> >> >>> Here is the thread:
>> >> >>> http://forums.fedoraforum.org/showthread.php?t=199562
>> >> >>>
>> >> >>> (A quick synopsis of the thread:
>> >> >>>
>> >> >>> I've activated/deactivated everything i could think of, related to
>> >> >>NetworkManager; yet, everything wireless is grayed out in the applet.
>> >> >>>
>> >> >>> But wpa_supplicant (cli) works!
>> >> >>>
>> >> >>> Additional info (beyond above thread):
>> >> >>>
>> >> >>> I compiled the latest NetworkManager svn; still same grayed out
>> >behavior.
>> >> >>>
>> >> >>> )
>> >> >>>
>> >> >>> I tried looking in the source and tracing the calls to and from
>> >> >>nm_client_wireless_get_enabled (if that's even a function) but,
>ignorant
>> >of
>> >> >C,
>> >> >>didn't get far.
>> >> >>>
>> >> >>> Please help!
>> >> >>
>> >> >>Does NM think wireless is disabled because a HAL killswitch is
>reporting
>> >> >
>> >> >Don't know enough about HAL to answer the above. (Where would i look?)
>> >> >
>> >> >>that it's off? Could you post some logs from /var/log/messages from
>> >> >>when NM starts up?
>> >> >
>> >> >please see attachment. (i've X'ed out some addresses (::)
>> >>
>> >>
>> >> ooops. The list strips attachment. Here is a web link to the same
>> >/var/log/messages chunk:
>> >>
>> >> http://www.flight.us/bugs/var_messages_nm_chunk.txt
>> >
>> >What's the output of:
>> >
>> >dellWirelessCtl
>>
>> Here it is: http://www.flight.us/bugs/dellWirelessCtl.txt
>>
>> OK, it appears that the "problem"(?) /does/ originate in the BIOS (I did
>present this hypothesis at the Fedora forum, but no one took that path, which
>now seems correct)
>
>Yeah, if dellWirelessCtl says the WLAN is disabled, then that's what the
>BIOS thinks. The best thing I think you could do is file a bug against
>'libsmbios' package in Fedora bugzilla and the Dell guys will try to
>help you debug.
Yes, of course, my **internal** wifi card /is/ disabled in the BIOS!
(You may not have read my FedoraForum thread)
dellWirelessCtl is reporting correctly regarding the internal card (only).
But why should this concern the external, removable cards??
Why should NetworkManager get info from the BIOS regarding the *internal*
device, and, based on that, disable Wifi globally, for ALL the cards, including
the removable ones, which are configured and working perfectly (with
wpa_supplicant)
(the goal here is to use my external, removable Atheros card, and keep the
built-in card disabled in the BIOS)
This looks like an algorithmic oversight in the NM's code. Also, I would think,
an easy fix (if only i knew C!)
Thanks in advance!
andrew
>Dan
>
>> For a quick & dirty fix: any way to force the disabled/enabled switch in the
>NM source? Again, i tried to find this in the source and failed. Where is
>it?
>>
>> I wonder if this can be considered a bug or glitch -- my situation
>apparently presents a need for NM to be more user-configurable here.
>>
>> Thanks.
>>
>> >HAL found a killswitch and NM is honoring the setting of that killswitch
>> >apparently.
>> >
>> >Dan
>> >
>> >>
>> >>
>> >> >NM keeps saying "wlan1: link is not ready"
>> >> >
>> >> >Yet, I can do "iwconfig" and "iwlist" with NO problem whatsoever, with
>good
>> >
>> >> >results. Plus, as i said earlier (this seems VERY significant), i can
>> >connect
>> >> >with wpa_supplicant no prob (all the while NM is saying "wireless is
>> >> >disabled"!)
>> >> >
>> >> >>It could also be that you've disabled the device in
>> >> >>system-config-network, in which case the menu will say the device is
>> >> >>"unmanaged".
>> >> >
>> >> >I have played with system-config-network every which way, before.
>"wlan1"
>> >(and
>> >> >"wlan0") are both assigned to NM, ("Controlled by NM" is checked).
>(wlan0
>> >> >versus wlan1 is created depending on which atheros card i insert -- i
>have
>> >two
>> >> >at my disposal)
>> >> >
>> >> >
>> >> >>
>> >> >>dan
>
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
> > > Because there is no case where a modem supports HSUPA but not HSDPA, and > thus HSUPA and HSPA are essentially equal. Since HSPA _is_ HSDPA + > HSUPA, it's pointless to have a separate HSUPA. > This signal is sent by the modem to the computer to indicate the capability of the connection. So this is athe result of the negociation of the modem with the network to see what is supported. So even if the modem supports HSUPA the network may not, equally with HSDPA It is possible that an operator will offer different network capabilities to subs and it may be that HSUPA is supported but not HSDPA. Dose that clarify the situation? --stuart ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with Networkmanager 0.7
Dan Williams wrote: > On Tue, 2008-09-30 at 09:30 +0800, Ronald Wiplinger (Lists) wrote: > >> Dan Williams wrote: >> >>> On Mon, 2008-09-29 at 07:18 +0800, Ronald Wiplinger (Lists) wrote: >>> >>> I had to install 0.7 in order to get my E220 to work. Works fine! I use Ubuntu 8.0.4 on my EeePC 1000 / 901 However, I got some other problems with it. 1. Each time I connect to the network I have to key in the Shared key, although it is saved. I can go to Edit that connection and even show the key. What gone wrong with that? Why does it not take the key automatically? How to fix it? >>> It might be that the card isn't connecting within the timeout, thus NM >>> asks for a new key because it thinks your key is wrong. Does it connect >>> the second time if you just hit "OK" without editing the key itself? >>> This could indicate a driver problem. What driver is 8.04 using on your >>> machine? >>> >>> >> There is no "OK", there is a Cancel or type in Key and Connect. >> > > Ah, I mean connect. Does it work if you just hit "Connect" again? NM > only asks for keys if the driver fails to associate to the access point. > > Now I am getting totally frustrated! I "had" to install Networkmanager 0.7, because I also use an E220 to connect to the Internet. This morning an "update" arrived via Ubuntu updates. First smile after rebooting was: GREAT it connects now automatically to the network again! But I was / am very frustrated, because I have now to disconnect in order to open an application. While I am connected ANY (did I mention ANY) application, including terminal, ... will just show "starting up ..." and die silently. I have now to disconnect, open all applications I might need now and can then connect again (no password question, it knows my password ;-) ) and can continue to work. Not the way I like to work forever, hopefully somebody finds the bug soon and gives me the solution how to install it, because, if I am connected, I cannot open the update, and if I am not connected, I cannot download the update, bye Ronald >> If I hit twice Cancel I get the icon of the Network manager in the top >> bar with the information box, that I am not connected. >> Left mouse button shows me my wireless connection as found, but not >> connected. >> Selecting it requires me to key in the key and connect. >> >> HOW can I avoid that? >> There seems to be a lost of "communication" between the network >> manager and my passwords, since Seahorse does know all my wireless >> keys. >> >> How can I see which "driver" my system is using? Which driver do you >> mean? >> > > An '/sbin/lsmod' would show which modules are loaded from which we can > deduce what driver is used. Otherwise, try '/usr/bin/nm-tool' which > shows what NetworkManager thinks. > > As mentioned above I have an EeePC 1000 and 901. While 901 does not ask me for the key, 1000 does. The OS is on a SD card cloned to the other one. Somewhere these two versions drifted apart. 2. I have two users, and I cannot get Networkmanager to work at the second users account. I though it will be globally installed. >>> Each user stores their own networks. Fast user switching probably >>> doesn't work right now, but if you log in as the other user (without >>> fast user switching) it should work. I'd probably need logs >>> from /var/log/daemon.log to diagnose. >>> >>> >>> >> Cool! >> >> Serious, I do not get a Networkmanager icon there, so how can I start >> a connection? >> > > Fast user switching needs some work still. > > 3. Most annoying is that, if for any reason I lose the wireless connection, the icon changes to no connection. The right click on the icon shows me ticked Enable Network. It cannot be unticked. There is no Enable Wireless. And a ping to a remote site works with and without plugged in Ethernet cable, so that I cannot say which connection it actually is using, since the left click on the icon gives me only the choice to use VPN, which I have not setup at all. >>> Can you explain this a bit more? Are you plugged into both wired and >>> wireless at the same time? If "Enable Wireless" doesn't exist, yet you >>> see the wireless device in the menu when you left-click, that isn't >>> something that upstream NetworkManager does. You might want to file a >>> bug in Launchpad on that particular one. >>> >>> >>> >> Exactly! >> >> bye >> >> Ronald >> >> >> >>> Dan >>> >>> >>> 4. I got already several updates automatically via Ubuntu updates, but it remains always 0.7 and no apparently changes. bye R. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/ma
Re: wpa_supplicant cli works, but NM insists "wireless is disabled"
On Tue, 2008-09-30 at 06:30 -0400, Andrew wrote:
> >On Mon, 2008-09-29 at 18:44 -0400, Andrew wrote:
> >> >>On Sun, 2008-09-28 at 19:21 -0400, Andrew wrote:
> >> >>> Hello,
> >> >>>
> >> >>> I have appealed to the Fedora Forum, but no one seems to have a clue
> >> >there.
> >> >>>
> >> >>> Here is the thread:
> >> >>> http://forums.fedoraforum.org/showthread.php?t=199562
> >> >>>
> >> >>> (A quick synopsis of the thread:
> >> >>>
> >> >>> I've activated/deactivated everything i could think of, related to
> >> >>NetworkManager; yet, everything wireless is grayed out in the applet.
> >> >>>
> >> >>> But wpa_supplicant (cli) works!
> >> >>>
> >> >>> Additional info (beyond above thread):
> >> >>>
> >> >>> I compiled the latest NetworkManager svn; still same grayed out
> >behavior.
> >> >>>
> >> >>> )
> >> >>>
> >> >>> I tried looking in the source and tracing the calls to and from
> >> >>nm_client_wireless_get_enabled (if that's even a function) but, ignorant
> >of
> >> >C,
> >> >>didn't get far.
> >> >>>
> >> >>> Please help!
> >> >>
> >> >>Does NM think wireless is disabled because a HAL killswitch is reporting
> >> >
> >> >Don't know enough about HAL to answer the above. (Where would i look?)
> >> >
> >> >>that it's off? Could you post some logs from /var/log/messages from
> >> >>when NM starts up?
> >> >
> >> >please see attachment. (i've X'ed out some addresses (::)
> >>
> >>
> >> ooops. The list strips attachment. Here is a web link to the same
> >/var/log/messages chunk:
> >>
> >> http://www.flight.us/bugs/var_messages_nm_chunk.txt
> >
> >What's the output of:
> >
> >dellWirelessCtl
>
> Here it is: http://www.flight.us/bugs/dellWirelessCtl.txt
>
> OK, it appears that the "problem"(?) /does/ originate in the BIOS (I did
> present this hypothesis at the Fedora forum, but no one took that path, which
> now seems correct)
Yeah, if dellWirelessCtl says the WLAN is disabled, then that's what the
BIOS thinks. The best thing I think you could do is file a bug against
'libsmbios' package in Fedora bugzilla and the Dell guys will try to
help you debug.
Dan
> For a quick & dirty fix: any way to force the disabled/enabled switch in the
> NM source? Again, i tried to find this in the source and failed. Where is
> it?
>
> I wonder if this can be considered a bug or glitch -- my situation apparently
> presents a need for NM to be more user-configurable here.
>
> Thanks.
>
> >HAL found a killswitch and NM is honoring the setting of that killswitch
> >apparently.
> >
> >Dan
> >
> >>
> >>
> >> >NM keeps saying "wlan1: link is not ready"
> >> >
> >> >Yet, I can do "iwconfig" and "iwlist" with NO problem whatsoever, with
> >> >good
> >
> >> >results. Plus, as i said earlier (this seems VERY significant), i can
> >connect
> >> >with wpa_supplicant no prob (all the while NM is saying "wireless is
> >> >disabled"!)
> >> >
> >> >>It could also be that you've disabled the device in
> >> >>system-config-network, in which case the menu will say the device is
> >> >>"unmanaged".
> >> >
> >> >I have played with system-config-network every which way, before. "wlan1"
> >(and
> >> >"wlan0") are both assigned to NM, ("Controlled by NM" is checked). (wlan0
> >> >versus wlan1 is created depending on which atheros card i insert -- i
> >> >have
> >two
> >> >at my disposal)
> >> >
> >> >
> >> >>
> >> >>dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
On Tue, 2008-09-30 at 14:55 +0300, Tambet Ingo wrote: > On Tue, Sep 30, 2008 at 2:46 PM, Pablo Martí <[EMAIL PROTECTED]> wrote: > > On Tue, Sep 30, 2008 at 1:31 PM, Tambet Ingo <[EMAIL PROTECTED]> wrote: > >> No, but the argument type passed with the signal is not an integer, > >> it's NM_MODEM_GSM_NETWORK_MODE. That is, the same type that is used > >> for setting the network mode. And thus, that type needs all these > >> values. There is also no need to add another type which is just like > >> NETWORK_MODE, but doesn't include some of it's values. > > > > Oh yeah true. How about adding NO_SIGNAL, HSUPA and HSPA too? > > Dan already notified me that I'm missing HSPA. He also said we don't > need HSUPA for some reason (I don't remember why, Dan?). Because there is no case where a modem supports HSUPA but not HSDPA, and thus HSUPA and HSPA are essentially equal. Since HSPA _is_ HSDPA + HSUPA, it's pointless to have a separate HSUPA. Dan > In which case would you need to send a "NetworkMode" changed signal > with NO_SIGNAL argument? I must be misunderstanding something as I'd > just not emit the signal in that case? > > Tambet > ___ > 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: Applet keeps connected always
On Tue, 2008-09-30 at 10:47 +0800, fean wrote: > Hi, > I am developing the driver to support NM. > The driver can get connected with all kinds of security networks now. > But, I have a question , how to tell NM that the current network disconnected. > Then, it should try to reconnect or select another network. > With NetworkManager --no-daemon, I found the daemon will try to reconnect. > But, the applet (icon) is shown connected always even I unplug the AP. > I tried 'netif_carrier_off()' , wireless_send_event with SIOCGIWAP with > BSSID=zeros. > They can't make it to show correct icon. wireless_send_event() for IWAP with all zeros is the correct method. This will cause the supplicant to disconnect and attempt to re-connect, and if that fails for long enough, NM will disconnect as well. Can you use wpa_supplicant manually and provide some logs showing the disconnect behavior? Basically, if wpa_supplicant doesn't know about the disconnection, neither will NM. dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: german translation
On Tue, 2008-09-30 at 16:03 +0200, Christoph Höger wrote: > Hi folks, > > Ive updated the german translation (and screwed up the layout somehow > with that) of nm-openvpn. > > I am not a member of the gnome translation team and have no svn access. > So feel free to add it. You should file a bug under the l10n module in the GNOME Bugzilla, and select "German" as the component. People there will be able to vouch for your translation, and make sure it fits with the GNOME guidelines. Cheers ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network manager or application, but not both!!!
On Tue, 2008-09-30 at 15:47 +0200, Alexander Sack wrote: > On Mon, Sep 29, 2008 at 10:52:10PM -0400, Darren Albers wrote: > > Ronald, > > > > It sounds like you are running the prerelease Network Manager from the > > Network Manager PPA. I would recommend filing bugs on Launchpad or > > posting to this thread on Ubuntuforums: > > http://ubuntuforums.org/showthread.php?t=797059 The Ubuntu > > Maintainer does check there periodically. > > > > Specific to the problem you describe I think you are seeing a bug > > where NM changes the hostname so X can't launch any new applications. > > If you watch the log do you see the hostname change? > > I uploaded a quick fix for this (~nm3) to the PPA until we have the > real solution. > > The problem is that latest NM changes hostname unless you explicitly > tell him not to do that in a system config file. Discussion on #nm > revealed that ubuntu (debian?) doesnt update .Xauthority when the > hostname changes during a X session. > > From what I understood opensuse and fedora appear to automagically add > the new host name to .Xauthority. Dan, any idea what mechanism is done > to do that? Yep, but it's not that. The magic is in xinit to always allow connections from local unix domain sockets, which local clients use on the same machine to connect to the X server instead of TCP since it's ohsomuchfaster. Since it's a local unix domain socket, you _know_ it's not remote, and thus there's no point whatsoever to using hostname validation in .Xauthority. Xauth is completely unecessary with local users. The fact that Xauth depends on hostname is bogus and has always been bogus. http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-xinit/devel/localuser.sh?view=log Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
german translation
Hi folks, Ive updated the german translation (and screwed up the layout somehow with that) of nm-openvpn. I am not a member of the gnome translation team and have no svn access. So feel free to add it. reagards christoph # Language =de translations for PACKAGE package. # Copyright (C) 2007 THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # Thomas Gier <[EMAIL PROTECTED]>, 2007. # msgid "" msgstr "" "Project-Id-Version: NetworkManager HEAD\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2008-09-30 15:43+0200\n" "PO-Revision-Date: 2008-09-30 16:00+0100\n" "Last-Translator: Christoph Höger <[EMAIL PROTECTED]>\n" "Language-Team: German <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; pluarl=(n != 1);\n" "X-Poedit-Basepath: /home/choeger/dev/fedora/nm-openvpn/upstream-svn/po/\n" "X-Poedit-SearchPath-0: /home/choeger/dev/fedora/nm-openvpn/upstream-svn/src\n" "X-Poedit-SearchPath-1: /home/choeger/dev/fedora/nm-openvpn/upstream-svn/auth-dialog\n" "X-Poedit-SearchPath-2: /home/choeger/dev/fedora/nm-openvpn/upstream-svn/properties\n" #: ../auth-dialog/gnome-two-password-dialog.c:145 msgid "_Password:" msgstr "_Passwort:" # CHECK: Secondary => Zweit...? #: ../auth-dialog/gnome-two-password-dialog.c:146 msgid "_Secondary Password:" msgstr "_Zweitpasswort:" #: ../auth-dialog/gnome-two-password-dialog.c:263 msgid "_Username:" msgstr "_Benutzername:" #: ../auth-dialog/gnome-two-password-dialog.c:265 msgid "_Domain:" msgstr "_Domäne:" #: ../auth-dialog/gnome-two-password-dialog.c:357 msgid "Connect _anonymously" msgstr "_Anonym verbinden" # CHECK ACCELERATOR #: ../auth-dialog/gnome-two-password-dialog.c:362 msgid "Connect as _user:" msgstr "Als _Benutzer verbinden:" # CHECK ACCELERATOR #: ../auth-dialog/gnome-two-password-dialog.c:471 msgid "_Remember password for this session" msgstr "_Passwort in dieser Sitzung behalten" #: ../auth-dialog/gnome-two-password-dialog.c:473 msgid "_Save password in keyring" msgstr "Passwort im _Schlüsselbund speichern" #: ../auth-dialog/main.c:210 #, c-format msgid "You need to authenticate to access the Virtual Private Network '%s'." msgstr "Sie müssen sich authentifizieren, um auf das Virtual Private Network »%s« zuzugreifen." #: ../auth-dialog/main.c:211 msgid "Authenticate VPN" msgstr "VPN authentifizieren" #: ../auth-dialog/main.c:232 msgid "Certificate pass_word:" msgstr "Zertifikat Pass_wort:" #: ../auth-dialog/main.c:246 msgid "Certificate password:" msgstr "Zertifikat Passwort:" #: ../properties/auth-helpers.c:69 msgid "Choose a Certificate Authority certificate..." msgstr "Zertifikat der Zertifizierungsstelle auswählen..." #: ../properties/auth-helpers.c:88 msgid "Choose your personal certificate..." msgstr "Persönliches Zertifikat auswählen..." #: ../properties/auth-helpers.c:106 msgid "Choose your private key..." msgstr "Privaten Schlüssel auswählen..." #: ../properties/auth-helpers.c:159 msgid "Choose an OpenVPN static key..." msgstr "Statischen OpenVPN Schlüssel auswählen..." # CHECK keine/keiner #: ../properties/auth-helpers.c:183 #: ../properties/auth-helpers.c:862 #, fuzzy msgid "None" msgstr "keine" #: ../properties/auth-helpers.c:518 msgid "PEM certificates (*.pem, *.crt, *.key)" msgstr "PEM Zertifikate (*.pem, *.crt, *.key)" #: ../properties/auth-helpers.c:578 msgid "OpenVPN Static Keys (*.key)" msgstr "Statische OpenVPN Schlüssel (*.key)" #: ../properties/auth-helpers.c:689 msgid "Default" msgstr "Vorgabe" #: ../properties/nm-openvpn.c:52 msgid "OpenVPN" msgstr "OpenVPN-Client" #: ../properties/nm-openvpn.c:53 msgid "Compatible with the OpenVPN server." msgstr "Kompatibel zum OpenVPN Server" #: ../properties/nm-openvpn.c:310 #: ../properties/nm-openvpn-dialog.glade.h:8 msgid "Certificates (TLS)" msgstr "Zertifikate (TLS):" #: ../properties/nm-openvpn.c:322 msgid "Password" msgstr "Passwort" #: ../properties/nm-openvpn.c:336 msgid "Password with Certificates (TLS)" msgstr "Passwort und Zertifikate (TLS)" #: ../properties/nm-openvpn.c:348 msgid "Static Key" msgstr "Statischer Schlüssel" #: ../properties/nm-openvpn-dialog.glade.h:1 msgid " " msgstr " " #: ../properties/nm-openvpn-dialog.glade.h:2 msgid "Authentication" msgstr "Authentifizierung" #: ../properties/nm-openvpn-dialog.glade.h:3 msgid "General" msgstr "Allgemein" #: ../properties/nm-openvpn-dialog.glade.h:4 msgid "If key direction is used, it must be the opposite of that used on the VPN peer. For example, if the peer uses '1', this connection must use '0'. If you are unsure what value to use, contact your system administrator." msgstr "Falls eine Schlüsselrichtung verwendet werden soll, muss das Gegenteil der Verbindungsstelle gewählt werden. Falls die Gegenstelle zum Beispiel '1' benutzt, muss hier '0' gewählt werden. Sollten Sie sich nicht sicher sein, setzen Sie sich mit Ihrem Systemadministrator in Verbindung."
Re: Network manager or application, but not both!!!
On Mon, Sep 29, 2008 at 10:52:10PM -0400, Darren Albers wrote: > Ronald, > > It sounds like you are running the prerelease Network Manager from the > Network Manager PPA. I would recommend filing bugs on Launchpad or > posting to this thread on Ubuntuforums: > http://ubuntuforums.org/showthread.php?t=797059 The Ubuntu > Maintainer does check there periodically. > > Specific to the problem you describe I think you are seeing a bug > where NM changes the hostname so X can't launch any new applications. > If you watch the log do you see the hostname change? I uploaded a quick fix for this (~nm3) to the PPA until we have the real solution. The problem is that latest NM changes hostname unless you explicitly tell him not to do that in a system config file. Discussion on #nm revealed that ubuntu (debian?) doesnt update .Xauthority when the hostname changes during a X session. >From what I understood opensuse and fedora appear to automagically add the new host name to .Xauthority. Dan, any idea what mechanism is done to do that? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
tiny patch for openvpn properties
Hi, this patch makes Certificate chooser labels appear in the correct order. regards Christoph Index: properties/nm-openvpn-dialog.glade === --- properties/nm-openvpn-dialog.glade (Revision 4027) +++ properties/nm-openvpn-dialog.glade (Arbeitskopie) @@ -426,7 +426,7 @@ True 0 -CA Certificate: +User Certificate: 1 @@ -438,7 +438,7 @@ True 0 -User Certificate: +Ca Certificate: 2 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
On Tue, Sep 30, 2008 at 3:25 PM, Pablo Martí <[EMAIL PROTECTED]> wrote: > Option and Huawei devices emit that signal usually upon a > SetNetworkMode command. They'll temporally be in NO_SIGNAL and then > emit whatever mode they've switched to. Also that signal might be > emitted on scenarios where you specify 3GONLY and there's just 2G > coverage. Ok, I finally did understand it, thanks. I'll add it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
On Tue, Sep 30, 2008 at 1:55 PM, Tambet Ingo <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 30, 2008 at 2:46 PM, Pablo Martí <[EMAIL PROTECTED]> wrote:
>> On Tue, Sep 30, 2008 at 1:31 PM, Tambet Ingo <[EMAIL PROTECTED]> wrote:
>>> No, but the argument type passed with the signal is not an integer,
>>> it's NM_MODEM_GSM_NETWORK_MODE. That is, the same type that is used
>>> for setting the network mode. And thus, that type needs all these
>>> values. There is also no need to add another type which is just like
>>> NETWORK_MODE, but doesn't include some of it's values.
>
> In which case would you need to send a "NetworkMode" changed signal
> with NO_SIGNAL argument? I must be misunderstanding something as I'd
> just not emit the signal in that case?
Option and Huawei devices emit that signal usually upon a
SetNetworkMode command. They'll temporally be in NO_SIGNAL and then
emit whatever mode they've switched to. Also that signal might be
emitted on scenarios where you specify 3GONLY and there's just 2G
coverage.
--
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
[RFC, (buggy) PATCH] Importing systemwide wireless configuration from wpa_supplicant.conf
Hi, This is an idea I had yesterday. It starts from a problem statement: * Being able to use system-wide wireless keys is beneficial for several reasons: - able to connect before / without a GUI login - no need to unlock the GNOME keyring all the time - and other reasons as outlined at: http://bugzilla.gnome.org/show_bug.cgi?id=331529 http://live.gnome.org/NetworkManagerToDo and other places. * However, at least the Fedora ifcfg infrastructure only supports basic (and highly insecure) WEP, no WPA nor 802.1X. Faced with this, I thought of something: in fact, we already have a well-recognized format to specify WPA or 802.1X settings in: the /etc/wpa_supplicant/wpa_supplicant.conf config file. That file is normally ignored or overridden when wpa_supplicant is started through NM, but I can't think of any reason why we can't import its settings into NM and reuse them that way. The benefits from this approach: - it's an existing format, not a new NM-specific format which would have to be designed - well-known format, documented in tutorials all over the Internet - distro-independent, so we don't have to reinvent the wheel for each distro - can represent WPA and 802.1X (and WEP and unencrypted WiFi too) - settings can be tested rapidly without going through NM (just start wpa_supplicant directly with the config file) - NM uses wpa_supplicant internally, so the format maps well to NM's view of things So, as per the above, I got the idea for a nm-system-settings plugin using wpa_supplicant.conf. And in fact, I tried implementing it myself and ended up with this (buggy) patch (against the NM revision in current Fedora, revision 4022): http://www.tigen.org/kevin.kofler/pcprogs/NetworkManager-0.7.0-wpa.patch Unfortunately, the patch does not work at all for me: sometimes I get the "System myssid" connection, but can't do anything useful with it (in particular, can't connect to it, nor does it connect automatically), sometimes not even that (i.e. I don't get the connection at all), and unfortunately my skills at debugging NM stop there. :-( I also have this quick&dirty specfile to build the plugin as a separate Fedora package for testing: http://www.tigen.org/kevin.kofler/pcprogs/NetworkManager-wpa_supplicant.spec Unfortunately, the file /etc/NetworkManager/nm-system-settings.conf which specifies the plugins to load is not marked %config(noreplace) in the Fedora NM package, so editing that file is a bit of a hack (and the package which my specfile builds doesn't try to do that automatically, it has to be done by hand - alternatively, my patch can be applied to the regular NM package and the config file just edited there, but that's not so nice for testing/debugging). There are also other things in the patch which could use improvement: - The inotify stuff is adapted from the fedora-ifcfg plugin in a quick&dirty way. I'm sure we could simplify it a lot here, as we only have one file to monitor, not an entire directory. - 802.1X support is currently limited to LEAP. It is possible to parse all the advanced 802.1X stuff too, just not implemented yet because I think getting the rest (unencrypted, WEP, WPA and LEAP) to work first is more important. (And to be honest, also because WPA and LEAP are all I personally need at the moment. ;-) ) There's a FIXME for this, it's easy to spot because it's a function of its own which just returns NULL. ;-) - In some places, wpa_supplicant.conf supports lists of possible settings, but NM only supports one single setting at a time, so I'm throwing the excess ones out for lack of a better solution. As far as I can tell, improvements to the NM core would be needed to fix this problem. There are FIXME comments next to the affected places. Kevin Kofler ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
On Tue, Sep 30, 2008 at 2:46 PM, Pablo Martí <[EMAIL PROTECTED]> wrote: > On Tue, Sep 30, 2008 at 1:31 PM, Tambet Ingo <[EMAIL PROTECTED]> wrote: >> No, but the argument type passed with the signal is not an integer, >> it's NM_MODEM_GSM_NETWORK_MODE. That is, the same type that is used >> for setting the network mode. And thus, that type needs all these >> values. There is also no need to add another type which is just like >> NETWORK_MODE, but doesn't include some of it's values. > > Oh yeah true. How about adding NO_SIGNAL, HSUPA and HSPA too? Dan already notified me that I'm missing HSPA. He also said we don't need HSUPA for some reason (I don't remember why, Dan?). In which case would you need to send a "NetworkMode" changed signal with NO_SIGNAL argument? I must be misunderstanding something as I'd just not emit the signal in that case? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
On Tue, Sep 30, 2008 at 1:31 PM, Tambet Ingo <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 30, 2008 at 11:19 AM, Pablo Martí <[EMAIL PROTECTED]> wrote:
>> I think that Network.NetworkMode's enum has some values that should be
>> changed to something more realistic. The devices I have around (Option
>> and Huawei mainly) won't emit an 'ANY' signal, neither a 'PREFER_2G',
>> ditto with 'PREFER_3G'. I propose to change it to:
>>
>> MM_MODEM_GSM_NETWORK_MODE_NO = 0 # NO SIGNAL
>> MM_MODEM_GSM_NETWORK_MODE_GPRS = 1
>> MM_MODEM_GSM_NETWORK_MODE_EDGE = 2
>> MM_MODEM_GSM_NETWORK_MODE_3G = 3
>> MM_MODEM_GSM_NETWORK_MODE_HSDPA = 4
>> MM_MODEM_GSM_NETWORK_MODE_HSUPA = 5
>> MM_MODEM_GSM_NETWORK_MODE_HSPA = 6
>>
>> If the last three members seem to much info they could be marged into
>> a "3G+" although I prefer granularity and exactness :)
>
> No, but the argument type passed with the signal is not an integer,
> it's NM_MODEM_GSM_NETWORK_MODE. That is, the same type that is used
> for setting the network mode. And thus, that type needs all these
> values. There is also no need to add another type which is just like
> NETWORK_MODE, but doesn't include some of it's values.
Oh yeah true. How about adding NO_SIGNAL, HSUPA and HSPA too?
Pablo
--
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: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
On Tue, Sep 30, 2008 at 11:19 AM, Pablo Martí <[EMAIL PROTECTED]> wrote: > I think that Network.NetworkMode's enum has some values that should be > changed to something more realistic. The devices I have around (Option > and Huawei mainly) won't emit an 'ANY' signal, neither a 'PREFER_2G', > ditto with 'PREFER_3G'. I propose to change it to: > > MM_MODEM_GSM_NETWORK_MODE_NO = 0 # NO SIGNAL > MM_MODEM_GSM_NETWORK_MODE_GPRS = 1 > MM_MODEM_GSM_NETWORK_MODE_EDGE = 2 > MM_MODEM_GSM_NETWORK_MODE_3G = 3 > MM_MODEM_GSM_NETWORK_MODE_HSDPA = 4 > MM_MODEM_GSM_NETWORK_MODE_HSUPA = 5 > MM_MODEM_GSM_NETWORK_MODE_HSPA = 6 > > If the last three members seem to much info they could be marged into > a "3G+" although I prefer granularity and exactness :) No, but the argument type passed with the signal is not an integer, it's NM_MODEM_GSM_NETWORK_MODE. That is, the same type that is used for setting the network mode. And thus, that type needs all these values. There is also no need to add another type which is just like NETWORK_MODE, but doesn't include some of it's values. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wpa_supplicant cli works, but NM insists "wireless is disabled"
>On Mon, 2008-09-29 at 18:44 -0400, Andrew wrote:
>> >>On Sun, 2008-09-28 at 19:21 -0400, Andrew wrote:
>> >>> Hello,
>> >>>
>> >>> I have appealed to the Fedora Forum, but no one seems to have a clue
>> >there.
>> >>>
>> >>> Here is the thread:
>> >>> http://forums.fedoraforum.org/showthread.php?t=199562
>> >>>
>> >>> (A quick synopsis of the thread:
>> >>>
>> >>> I've activated/deactivated everything i could think of, related to
>> >>NetworkManager; yet, everything wireless is grayed out in the applet.
>> >>>
>> >>> But wpa_supplicant (cli) works!
>> >>>
>> >>> Additional info (beyond above thread):
>> >>>
>> >>> I compiled the latest NetworkManager svn; still same grayed out
>behavior.
>> >>>
>> >>> )
>> >>>
>> >>> I tried looking in the source and tracing the calls to and from
>> >>nm_client_wireless_get_enabled (if that's even a function) but, ignorant
>of
>> >C,
>> >>didn't get far.
>> >>>
>> >>> Please help!
>> >>
>> >>Does NM think wireless is disabled because a HAL killswitch is reporting
>> >
>> >Don't know enough about HAL to answer the above. (Where would i look?)
>> >
>> >>that it's off? Could you post some logs from /var/log/messages from
>> >>when NM starts up?
>> >
>> >please see attachment. (i've X'ed out some addresses (::)
>>
>>
>> ooops. The list strips attachment. Here is a web link to the same
>/var/log/messages chunk:
>>
>> http://www.flight.us/bugs/var_messages_nm_chunk.txt
>
>What's the output of:
>
>dellWirelessCtl
Here it is: http://www.flight.us/bugs/dellWirelessCtl.txt
OK, it appears that the "problem"(?) /does/ originate in the BIOS (I did
present this hypothesis at the Fedora forum, but no one took that path, which
now seems correct)
For a quick & dirty fix: any way to force the disabled/enabled switch in the NM
source? Again, i tried to find this in the source and failed. Where is it?
I wonder if this can be considered a bug or glitch -- my situation apparently
presents a need for NM to be more user-configurable here.
Thanks.
>HAL found a killswitch and NM is honoring the setting of that killswitch
>apparently.
>
>Dan
>
>>
>>
>> >NM keeps saying "wlan1: link is not ready"
>> >
>> >Yet, I can do "iwconfig" and "iwlist" with NO problem whatsoever, with good
>
>> >results. Plus, as i said earlier (this seems VERY significant), i can
>connect
>> >with wpa_supplicant no prob (all the while NM is saying "wireless is
>> >disabled"!)
>> >
>> >>It could also be that you've disabled the device in
>> >>system-config-network, in which case the menu will say the device is
>> >>"unmanaged".
>> >
>> >I have played with system-config-network every which way, before. "wlan1"
>(and
>> >"wlan0") are both assigned to NM, ("Controlled by NM" is checked). (wlan0
>> >versus wlan1 is created depending on which atheros card i insert -- i have
>two
>> >at my disposal)
>> >
>> >
>> >>
>> >>dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM and usb eth gadget
Dan Williams wrote: > > Not really, precisely because names are subject to change by udev and > whatnot. Names are even less stable than MAC addresses, and this is > really an abuse. Is OpenMoko seriously too lame to get a pool of MAC > addresses? Do they at least start with 00:02 or something like that? > I'm not really an expert on usb gadgets and I'm not sure how they assign mac in the first place. It seems, when you load g_ether module it's assigning pretty random mac address. You can of course specify it by passing arguments to the module. One can argue, you can define it based as you pointed USB vendor/device ID and serial or anything else, but I think it's offtopic discussion here. > Couldn't you use udev rules to always assign the same MAC address to the > phone based on USB vendor/device ID and serial #? Maybe it can be done using uved, but I couldn't find the way to do it yet. Anyway, thanks for an answer Dan! Rob ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: autoconnect was:networkmanager
On Tue, Sep 30, 2008 at 8:57 AM, Bjorge Solli <[EMAIL PROTECTED]> wrote: > Dan Williams wrote: >> NM will (by default) remember wifi access points you've connected to >> before, and if you come in range of one it'll try to automatically >> connect to that AP (unless you've told it not to). > If the cracker put up an encrypted (or unencrypted) network with ssid > Eduroam that accept all passwords, will NM connect to it? If your networks use WPA (or WPA2, both Personal and Enterprise) then a successful auth does not send your password over, instead it exchanges a number of secrets encrypted using the key generated basing on the password (and SSID) so in order to provide a fake (spoofed) access point you already need to know the password. If your networks use WEP or no security at all then, well, you are on your own :) -- Patryk Zawadzki ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
Hola,
I think that Network.NetworkMode's enum has some values that should be
changed to something more realistic. The devices I have around (Option
and Huawei mainly) won't emit an 'ANY' signal, neither a 'PREFER_2G',
ditto with 'PREFER_3G'. I propose to change it to:
MM_MODEM_GSM_NETWORK_MODE_NO = 0 # NO SIGNAL
MM_MODEM_GSM_NETWORK_MODE_GPRS = 1
MM_MODEM_GSM_NETWORK_MODE_EDGE = 2
MM_MODEM_GSM_NETWORK_MODE_3G = 3
MM_MODEM_GSM_NETWORK_MODE_HSDPA = 4
MM_MODEM_GSM_NETWORK_MODE_HSUPA = 5
MM_MODEM_GSM_NETWORK_MODE_HSPA = 6
If the last three members seem to much info they could be marged into
a "3G+" although I prefer granularity and exactness :)
Regards,
--
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: Support for bonding?
On Sun, Sep 28, 2008 at 9:49 PM, David Abrahams <[EMAIL PROTECTED]> wrote: > Has any thought been given to supporting a setup like the one described here: > http://www.debian-administration.org/articles/312#comment_9 ? I googled up > that > post when thinking about how to retain connectivity when moving from wired to > wireless and vice-versa. I'm happy to do the configuration manually (although > someone clearly wants NM to handle it: > http://brainstorm.ubuntu.com/idea/10534/) > but it seems at least likely that NM might interfere. If that's not the case, > so much the better; I'll try to set it up and see what happens. Regardless, > allowing people to dock/undock or plug-in/roam without interrupting their > connections seems like it's right up NM's alley. I have been thinking about supporting bonding in NetworkManager (personally, I'd _love_ to have it), some people even argue that the current multiple device support does not make sense without bonding. There's an issue though with using bonding with wpa_supplicant (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483207 , http://hostap.epitest.fi/bugz/show_bug.cgi?id=270) so that needs to get solved first. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: autoconnect was:networkmanager
Dan Williams wrote: > NM will (by default) remember wifi access points you've connected to > before, and if you come in range of one it'll try to automatically > connect to that AP (unless you've told it not to). Isn't this a security flaw? We have two vpn networks at campus: campusnet - no encryption, private net - you have to authenticate using vpn to get online or use web based logon Eduroam - encrypted, real address directly If a cracker put up an unencrypted network with ssid campusnet, our laptops would connect automatically to it exposing it to the crackers manipulated dns and other goodies, making hostile takeovers a breeze. You should try to prevent this, or is this something we should take into account when setting this up? Asking the user to "watch out" is like believing in Santa Claus.. If the cracker put up an encrypted (or unencrypted) network with ssid Eduroam that accept all passwords, will NM connect to it? Regards, Bjørge ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
