Re: Fedora16 - Brain dead wireless network manager
On 01/17/2012 10:45 AM, Martin Langhoff wrote: OTOH, reconnection to wlans seems to be faster than F15, which had some crazy long timeouts. Still slower than iOS, perhaps almost on par w Android devices. cheers, m 802.11ai is looking at how to streamline the whole setup process. You can access the documents for this wg via: https://mentor.ieee.org/802.11/documents?is_group=00ai Still no agreement on way forward, so relief is a while off. Sigh. And yes, I have my proposals here. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fedora16 - Brain dead wireless network manager
On 01/17/2012 08:29 AM, Robert Moskowitz wrote: On 01/17/2012 08:38 AM, Dan Winship wrote: On 01/17/2012 08:14 AM, Robert Moskowitz wrote: Oh, this is on a Lenovo x120e where I see the following in the log messages: Jan 16 22:16:42 lx120e kernel: [81433.007709] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin The driver for that chipset is apparently broken in the current kernel: https://bugzilla.redhat.com/show_bug.cgi?id=729618 (There are links to various testing kernels with different patches in that bug, but it's hard to tell from the comments if they fix the problem...) Now why does that not supprise me? I did notice one update to the driver a while back. And I have 'real work' (spec writing!) to do to test f17... But it does not address the removal of information from the UI nor the control over SSID selection/control. That Fedora bug report has nothing to do with this problem - that bug was mostly due to placing the firmware loading message in the wrong place. Larry ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fedora16 - Brain dead wireless network manager
On Tue, Jan 17, 2012 at 9:29 AM, Robert Moskowitz wrote: > But it does not address the removal of information from the UI nor the > control over SSID selection/control. Agreed. NM-client on F15 and now F16 is a perceptible downgrade over F14. The brave new world of Gnome 3 has reduced networking usability -- I hope it's not here to stay. Here's my short list of surprises; I've found my workarounds, I just hope it's useful feedback. - Can't click an existing, established connection to re-connect on the nm-client-applet list - Can't easily open the networks view/edit dialog from nm-client-applet - "Network Settings", activated from nm-client-applet menu, lets me view/edit a wlan config only once it completes a connection successfully -- picking a wlan config tries to activate it. This drove me crazy until I realized that it was not the only settings app... - There are 2 network settings -- "network" and "network connections" -- when I use the gnome app chooser. Which one should I use? Answer: "network connections", the harder to find one, is the sane one, where you can look at a wlan configuration and edit it without requesting that NM tries to associate to it. OTOH, reconnection to wlans seems to be faster than F15, which had some crazy long timeouts. Still slower than iOS, perhaps almost on par w Android devices. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: How to generate "Auto eth0" from command line ?
Hi Mathieu, Thanks for the "uuidgen". Regarding no "Auto eth0" initially, my task is to make it work in embedded board, so there's no GUI. step 1: I tried from scratch, no "Auto eth0", it's in DHCP mode, it works. Then from GUI i set it to static ip. It generates "auto eth0". I keep this file in another place call it "mycfg.static". Then move back to DHCP from GUI, then remove the /etc/NetworkManager/Auto eth0. step 2: After reboot, the system is in a fresh new state, no "Auto eth0". copy "mycfg.static" to /etc/NetworkManager/Auto eth0. step 3: from "network configurations" i saw 2 interfaces, somehow it takes a default somewhere again. So my question is, can i switch from dhcp to static without GUI, as this is our requirement ? Thanks very much ! > Date: Mon, 16 Jan 2012 23:28:58 +0100 > Subject: Re: How to generate "Auto eth0" from command line ? > From: mathieu...@gmail.com > To: nin...@hotmail.com > > On Sat, Jan 14, 2012 at 11:16 PM, ning ji wrote: > > Hi i'm new to NetworkManager. > > > > In ubuntu 10.4, if i remember this correctly, by default, > > there's NO "Auto Eth0" under /etc/NetworkManager/... > > > > If in the menu i edit eth0 to use static ip, there'll be a "Auto Eth0“ file. > > > > 1. My question is how to generate this file from command line ? > > > > 2. How to generate uuid for eth0, heard there's a "blkid" command, > > but /dev/eth0 is not available in linux ? > > There already should be one -- but it won't show in > /etc/NetworkManager, because it's automatically created by NM when > used. In other words, make sure nm-applet is running, then plug in a > cable and things should just work. > > In 10.04, you might be able to use cnetworkmanager (from the > cnetworkmanager package) to do this. > > As for your question about UUIDs, try 'uuidgen -r'. > > Mathieu Trudel-Lapierre > Freenode: cyphermox, Jabber: mathieu...@gmail.com > 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fedora16 - Brain dead wireless network manager
On 01/17/2012 08:38 AM, Dan Winship wrote: On 01/17/2012 08:14 AM, Robert Moskowitz wrote: Oh, this is on a Lenovo x120e where I see the following in the log messages: Jan 16 22:16:42 lx120e kernel: [81433.007709] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin The driver for that chipset is apparently broken in the current kernel: https://bugzilla.redhat.com/show_bug.cgi?id=729618 (There are links to various testing kernels with different patches in that bug, but it's hard to tell from the comments if they fix the problem...) Now why does that not supprise me? I did notice one update to the driver a while back. And I have 'real work' (spec writing!) to do to test f17... But it does not address the removal of information from the UI nor the control over SSID selection/control. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fedora16 - Brain dead wireless network manager
On 01/17/2012 08:14 AM, Robert Moskowitz wrote: > Oh, this is on a Lenovo x120e where I see the following in the log > messages: > > Jan 16 22:16:42 lx120e kernel: [81433.007709] rtl8192c_common: Loading > firmware file rtlwifi/rtl8192cfw.bin The driver for that chipset is apparently broken in the current kernel: https://bugzilla.redhat.com/show_bug.cgi?id=729618 (There are links to various testing kernels with different patches in that bug, but it's hard to tell from the comments if they fix the problem...) -- Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Fedora16 - Brain dead wireless network manager
f16 and gnome 3. I don't know what ver of Network Manager... Now I know a little bit about 802.11. I am currently at the IEEE 802 wireless interim meeting in Jacksonville, FL. Most of my time is in 802.15.9 (I am the chair), but I still attend 802.11 sessions. That is I know something about the guts of 802.11 setup... So here I am switching between the hotel's questionably usable ESS and the conference's ESS. Of course both have different SSIDs (SSID defines an ESS, generally) and each has lots of Access Points many on the same channel. So I am in a meeting room on the VeriLAN SSID. I suspend my system and go to my room to the Hyatt SSID. The icon shows the SSID selected and a signal strength but has 'unavailable' after the word 'Wireless'. What is going on here? There is no easy way to restart the connection. I have to go into Network Settings, turn off wireless and turn it on. ARGH! Then I am not getting anything to work on the Hyatt SSID, yet it is showing 3 bars of signal strength. But is there any textual info on S/N or anything worthwhile? Of course not. WiFi is suppose to be used by cellphone users that only know to look at bars on their cellphones, so that must be good enough? When you are working on multiple ESSes as you will in a hotel (many have a different SSID for the lobby from the rooms from the meeting rooms even without the meeting having its own!), you need better. Or at least what I had with f14 and Gnome 2. Oh, this is on a Lenovo x120e where I see the following in the log messages: Jan 16 22:16:42 lx120e kernel: [81433.007709] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin I would like some help on getting things to work better... ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bearers in mixed CDMA+LTE modems
>>> I believe we need a MMBearerType enum in the 0.6 API, so that we can >>> tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS) >>> bearer. This property would be redundant for 3GPP-only, CDMA-only or >>> POTS-only modems, but would be mandatory if we have a mixed >>> 3GPP(LTE)+CDMA bearer. This value would also be shown as a property in >>> the Bearer interface, so that we can know the type of the bearer behind >>> a given DBus path. Another possibility to avoid the new enum would be to >>> assume that if "apn" is given when creating the bearer, we want a 3GPP >>> bearer, while if no "apn" is given we really want a CDMA bearer. But not >>> sure I like to rely just on this "apn"-based logic. What do others >>> think? >> >> The problem with that approach is handoffs. If you create a 3GPP/LTE >> bearer and then leave LTE coverage where the device hands off to EVDO, >> now your 3GPP bearer is a CDMA bearer. In this scenario there's no >> interruption of packet data service and you don't even know anything >> happened except that the access technology changed from LTE to EVDO. > > Well, that is already some indication that we can use. If we had a 3GPP > bearer connected, and suddenly the access technology changed to EV-DO, > then we could internally mark the CDMA bearer as connected and mark the > 3GPP one as disconnected. If done in that order, we wouldn't be issuing > any state change notification. This, assuming that for mixed technology > modems we have different technology-specific bearers. The only drawback > of having technology-specific bearers is that for the user not using the > Simple interface, it would mean needing to create two bearers with two > CreateBearer() calls. But I don't think that that is a big deal; if the > user of a mixed CDMA+LTE modem just creates a 3GPP bearer and gets it > connected, and then we detect the connection handed off to CDMA, we can > request the disconnection of the bearer and that's it. If the user > didn't create a CDMA bearer, we would need to assume she didn't want a > CDMA connection. If using the Simple interface, all that would be > automatic, different bearers would be created automatically. there is no guarantee that the IP connection details stay the same. Before everybody goes crazy here you might wanna check if Verizon even provides the same IP address when falling back to CDMA from LTE. >>> >>> It's supposed to work that way according to the eHRPD docs. I tried to >>> drivetest this Friday but due to my own stupidity I forgot to take the >>> modem out of LTE+HRPD mode and into AUTO+eHRPD so I couldn't capture the >>> handoff and then I ran out of battery. My bad, I'll try again. >>> >> >> Needless to say that I would love to see the logs :-) >> >>> But at least the UE is supposed to make this transparent according to >>> 3GPP2 X.S0057-A. If the ME already has IP address information from the >>> network, in the VSNCP Configure-Request packet it sets the Attach-Type >>> configuration option to "handoff" and includes the existing IP >>> information (10.1.4.2). >>> >>> Section 13 (Handoff from E-UTRAN to eHRPD) states: >>> >>> "For optimized handoff, when the UE accesses eHRPD via the E-UTRAN radio >>> and the S101 tunnel, it shall send a VSNCP Configure-Request message >>> with Attach-Type set to handover to the HSGW for each of it's existing >>> PDN connections in the EPS system that it intends to maintain in eHRPD." >>> >>> Section 13.1.1 step 7 says: >>> >>> "The UI exchanges VSNCP messages with the HSGW for each PDN connection >>> that it currently has attachments to within E-UTRAN and that it wants to >>> maintain on eHRPD. The UI sets the Attach-Type to "handoff" in the >>> VSNCP Configure-Request message. Also, the UI includes the IP >>> address(es) it obtained via LTE in the VSNCP Configure-Request message." >>> >>> See also section 13.1.1 where it details what happens for optimized >>> handoff; non-optimized handoff is supposed to be the same, more or less. >>> >>> So let's assume that the IP address is supposed to stay the same. Next, >>> the standard talks in various places about separate bearers for EPS and >>> eHRPD, like 13.2.1: "When the UE returns to eHRPD to resume the existing >>> eHRPD session, the PDN connections are created per the context that the >>> UI had on E-UTRAN. Likewise, bearers are established to match those >>> that were available on E-UTRAN." >>> >>> Basically, it appears that bearers may change at various times, but the >>> IP addresses may stay the same across bearer changes in some cases too. >>> The problem is that we don't really want to expose that to clients much, >>> because it's not really that useful to know that bearers are dancing >>> around. You really just want to know if one of your existing bearers >>> *changed* attributes
Re: Bearers in mixed CDMA+LTE modems
Hi Aleksander, > > I believe we need a MMBearerType enum in the 0.6 API, so that we can > > tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS) > > bearer. This property would be redundant for 3GPP-only, CDMA-only or > > POTS-only modems, but would be mandatory if we have a mixed > > 3GPP(LTE)+CDMA bearer. This value would also be shown as a property in > > the Bearer interface, so that we can know the type of the bearer behind > > a given DBus path. Another possibility to avoid the new enum would be to > > assume that if "apn" is given when creating the bearer, we want a 3GPP > > bearer, while if no "apn" is given we really want a CDMA bearer. But not > > sure I like to rely just on this "apn"-based logic. What do others > > think? > > The problem with that approach is handoffs. If you create a 3GPP/LTE > bearer and then leave LTE coverage where the device hands off to EVDO, > now your 3GPP bearer is a CDMA bearer. In this scenario there's no > interruption of packet data service and you don't even know anything > happened except that the access technology changed from LTE to EVDO. > >>> > >>> Well, that is already some indication that we can use. If we had a 3GPP > >>> bearer connected, and suddenly the access technology changed to EV-DO, > >>> then we could internally mark the CDMA bearer as connected and mark the > >>> 3GPP one as disconnected. If done in that order, we wouldn't be issuing > >>> any state change notification. This, assuming that for mixed technology > >>> modems we have different technology-specific bearers. The only drawback > >>> of having technology-specific bearers is that for the user not using the > >>> Simple interface, it would mean needing to create two bearers with two > >>> CreateBearer() calls. But I don't think that that is a big deal; if the > >>> user of a mixed CDMA+LTE modem just creates a 3GPP bearer and gets it > >>> connected, and then we detect the connection handed off to CDMA, we can > >>> request the disconnection of the bearer and that's it. If the user > >>> didn't create a CDMA bearer, we would need to assume she didn't want a > >>> CDMA connection. If using the Simple interface, all that would be > >>> automatic, different bearers would be created automatically. > >> > >> there is no guarantee that the IP connection details stay the same. > >> > >> Before everybody goes crazy here you might wanna check if Verizon even > >> provides the same IP address when falling back to CDMA from LTE. > > > > It's supposed to work that way according to the eHRPD docs. I tried to > > drivetest this Friday but due to my own stupidity I forgot to take the > > modem out of LTE+HRPD mode and into AUTO+eHRPD so I couldn't capture the > > handoff and then I ran out of battery. My bad, I'll try again. > > > > Needless to say that I would love to see the logs :-) > > > But at least the UE is supposed to make this transparent according to > > 3GPP2 X.S0057-A. If the ME already has IP address information from the > > network, in the VSNCP Configure-Request packet it sets the Attach-Type > > configuration option to "handoff" and includes the existing IP > > information (10.1.4.2). > > > > Section 13 (Handoff from E-UTRAN to eHRPD) states: > > > > "For optimized handoff, when the UE accesses eHRPD via the E-UTRAN radio > > and the S101 tunnel, it shall send a VSNCP Configure-Request message > > with Attach-Type set to handover to the HSGW for each of it's existing > > PDN connections in the EPS system that it intends to maintain in eHRPD." > > > > Section 13.1.1 step 7 says: > > > > "The UI exchanges VSNCP messages with the HSGW for each PDN connection > > that it currently has attachments to within E-UTRAN and that it wants to > > maintain on eHRPD. The UI sets the Attach-Type to "handoff" in the > > VSNCP Configure-Request message. Also, the UI includes the IP > > address(es) it obtained via LTE in the VSNCP Configure-Request message." > > > > See also section 13.1.1 where it details what happens for optimized > > handoff; non-optimized handoff is supposed to be the same, more or less. > > > > So let's assume that the IP address is supposed to stay the same. Next, > > the standard talks in various places about separate bearers for EPS and > > eHRPD, like 13.2.1: "When the UE returns to eHRPD to resume the existing > > eHRPD session, the PDN connections are created per the context that the > > UI had on E-UTRAN. Likewise, bearers are established to match those > > that were available on E-UTRAN." > > > > Basically, it appears that bearers may change at various times, but the > > IP addresses may stay the same across bearer changes in some cases too. > > The problem is that we don't really want to expose that to clients much, > > because it's not really that useful to know that bearers are dancing > > around. You really just want to know if one of your existing bearers >
Re: Bearers in mixed CDMA+LTE modems
>> I believe we need a MMBearerType enum in the 0.6 API, so that we can >> tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS) >> bearer. This property would be redundant for 3GPP-only, CDMA-only or >> POTS-only modems, but would be mandatory if we have a mixed >> 3GPP(LTE)+CDMA bearer. This value would also be shown as a property in >> the Bearer interface, so that we can know the type of the bearer behind >> a given DBus path. Another possibility to avoid the new enum would be to >> assume that if "apn" is given when creating the bearer, we want a 3GPP >> bearer, while if no "apn" is given we really want a CDMA bearer. But not >> sure I like to rely just on this "apn"-based logic. What do others think? > > The problem with that approach is handoffs. If you create a 3GPP/LTE > bearer and then leave LTE coverage where the device hands off to EVDO, > now your 3GPP bearer is a CDMA bearer. In this scenario there's no > interruption of packet data service and you don't even know anything > happened except that the access technology changed from LTE to EVDO. Well, that is already some indication that we can use. If we had a 3GPP bearer connected, and suddenly the access technology changed to EV-DO, then we could internally mark the CDMA bearer as connected and mark the 3GPP one as disconnected. If done in that order, we wouldn't be issuing any state change notification. This, assuming that for mixed technology modems we have different technology-specific bearers. The only drawback of having technology-specific bearers is that for the user not using the Simple interface, it would mean needing to create two bearers with two CreateBearer() calls. But I don't think that that is a big deal; if the user of a mixed CDMA+LTE modem just creates a 3GPP bearer and gets it connected, and then we detect the connection handed off to CDMA, we can request the disconnection of the bearer and that's it. If the user didn't create a CDMA bearer, we would need to assume she didn't want a CDMA connection. If using the Simple interface, all that would be automatic, different bearers would be created automatically. >>> >>> there is no guarantee that the IP connection details stay the same. >> >> There is no IP connection detail stored in the ModemManager bearers, so >> that wouldn't be a big deal for us I guess. Maybe I'm missing something. > > Except for Static mode :) > Indeed, yes. Which reminds me I need to allow subclasses of the bearers to report the static IP addresses. -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bearers in mixed CDMA+LTE modems
> I believe we need a MMBearerType enum in the 0.6 API, so that we can > tell in CreateBearer() whether we want a 3GPP or CDMA (well, or POTS) > bearer. This property would be redundant for 3GPP-only, CDMA-only or > POTS-only modems, but would be mandatory if we have a mixed > 3GPP(LTE)+CDMA bearer. This value would also be shown as a property in > the Bearer interface, so that we can know the type of the bearer behind > a given DBus path. Another possibility to avoid the new enum would be to > assume that if "apn" is given when creating the bearer, we want a 3GPP > bearer, while if no "apn" is given we really want a CDMA bearer. But not > sure I like to rely just on this "apn"-based logic. What do others think? The problem with that approach is handoffs. If you create a 3GPP/LTE bearer and then leave LTE coverage where the device hands off to EVDO, now your 3GPP bearer is a CDMA bearer. In this scenario there's no interruption of packet data service and you don't even know anything happened except that the access technology changed from LTE to EVDO. >>> >>> Well, that is already some indication that we can use. If we had a 3GPP >>> bearer connected, and suddenly the access technology changed to EV-DO, >>> then we could internally mark the CDMA bearer as connected and mark the >>> 3GPP one as disconnected. If done in that order, we wouldn't be issuing >>> any state change notification. This, assuming that for mixed technology >>> modems we have different technology-specific bearers. The only drawback >>> of having technology-specific bearers is that for the user not using the >>> Simple interface, it would mean needing to create two bearers with two >>> CreateBearer() calls. But I don't think that that is a big deal; if the >>> user of a mixed CDMA+LTE modem just creates a 3GPP bearer and gets it >>> connected, and then we detect the connection handed off to CDMA, we can >>> request the disconnection of the bearer and that's it. If the user >>> didn't create a CDMA bearer, we would need to assume she didn't want a >>> CDMA connection. If using the Simple interface, all that would be >>> automatic, different bearers would be created automatically. >> >> there is no guarantee that the IP connection details stay the same. >> >> Before everybody goes crazy here you might wanna check if Verizon even >> provides the same IP address when falling back to CDMA from LTE. > > It's supposed to work that way according to the eHRPD docs. I tried to > drivetest this Friday but due to my own stupidity I forgot to take the > modem out of LTE+HRPD mode and into AUTO+eHRPD so I couldn't capture the > handoff and then I ran out of battery. My bad, I'll try again. > Needless to say that I would love to see the logs :-) > But at least the UE is supposed to make this transparent according to > 3GPP2 X.S0057-A. If the ME already has IP address information from the > network, in the VSNCP Configure-Request packet it sets the Attach-Type > configuration option to "handoff" and includes the existing IP > information (10.1.4.2). > > Section 13 (Handoff from E-UTRAN to eHRPD) states: > > "For optimized handoff, when the UE accesses eHRPD via the E-UTRAN radio > and the S101 tunnel, it shall send a VSNCP Configure-Request message > with Attach-Type set to handover to the HSGW for each of it's existing > PDN connections in the EPS system that it intends to maintain in eHRPD." > > Section 13.1.1 step 7 says: > > "The UI exchanges VSNCP messages with the HSGW for each PDN connection > that it currently has attachments to within E-UTRAN and that it wants to > maintain on eHRPD. The UI sets the Attach-Type to "handoff" in the > VSNCP Configure-Request message. Also, the UI includes the IP > address(es) it obtained via LTE in the VSNCP Configure-Request message." > > See also section 13.1.1 where it details what happens for optimized > handoff; non-optimized handoff is supposed to be the same, more or less. > > So let's assume that the IP address is supposed to stay the same. Next, > the standard talks in various places about separate bearers for EPS and > eHRPD, like 13.2.1: "When the UE returns to eHRPD to resume the existing > eHRPD session, the PDN connections are created per the context that the > UI had on E-UTRAN. Likewise, bearers are established to match those > that were available on E-UTRAN." > > Basically, it appears that bearers may change at various times, but the > IP addresses may stay the same across bearer changes in some cases too. > The problem is that we don't really want to expose that to clients much, > because it's not really that useful to know that bearers are dancing > around. You really just want to know if one of your existing bearers > *changed* attributes like IP addressing or QoS/TFT, since the modem and > network appear to do all they can to maintain characteristics between > E-UTRAN and eHRPD. I also still don't kno
