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. So I think (as you suggest below) that by default MM should make a best guess based on the current registration of the device and the mode preference. If you're registered on the LTE network and your mode pref is 4G_PREFERRED then of course we'd start an EPS bearer. If your mode pref is 3G_4G and you're registered with CDMA then we'd try to start a CDMA bearer. There are some carrier-specific issues with this however; an ATD#777 CDMA PPP bearer cannot hand off to LTE on Verizon devices, but handoff is supposed to be transparent when you use QMI instead of PPP. In that case, if we suddenly found that we can connect in the LTE network, we can always disconnect the CDMA bearer ourselves and launch the LTE connection as a single operation (i.e. merging all the state changes connected-disconnecting-registered-connecting-connected and not notifying any of them). Not really transparent for ModemManager, but quite transparent for the user. What you're asking about is what bearer to create if the device is registered with (or can register with) two 3G networks that use different access technology. For example, in Canada, Bell Mobility and Telus run both EVDO and HSPA networks. If you're a user, do you care which one you connect to with your Gobi card? Maybe you do. If you do care which network to use, then using technology-specific bearers is the way to go. If you only want to use the HSPA network, the user would create only a 3GPP bearer, and connect it. If using the simple interface, where we automatically create the bearers, we could receive a 'bearer-type' entry which would tell us that we only want to create a single bearer, instead of automatically deciding how many to create. So the bearer type property should certainly be a *suggestion*, not mandatory. At least for now I don't think most people will use it, but it doesn't hurt anything to add it. But the next question is if you request a 3GPP bearer and the device later hands off to CDMA, do you terminate the connection? I would say no, since the device is making the decision to hand off based on your subscriber data (ie, SIM and/or ESN/MEID) and that's supposed to be automatic. Well, why not? If your modem supports 3GPP and CDMA, and you just created a 3GPP bearer, if it automatically hands off to CDMA I would really disconnect it. That is anyway a very specific use case; in the general case, when using the Simple interface, we would have created both a 3GPP bearer and a CDMA bearer, and we would do the hand off internally without going away from the connected state. On a side note, during the Simple interface's Connect(), for the case of mixed 3GPP+CDMA modems, we would create both a 3GPP and a CDMA bearer, and then connect one or the other based on allowed/preferred modes preferences and based on our registration status in each
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. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bearers in mixed CDMA+LTE modems
Hey Marcel, 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. Before everybody goes crazy here you might wanna check if Verizon even provides the same IP address when falling back to CDMA from LTE. They probably don't give the same IP address, so if the hand off is really transparent (i.e. not getting disconnected and then connected again), I assume we rely on the modem itself to detect that and handle the IP switch at PPP session level. I cannot really do any such test, so cannot tell :-/ -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Error when trying to access nm with vala and gdbus
Le jeudi 12 janvier 2012 à 19:01 -0600, Dan Williams a écrit : conn = Bus.get_proxy_sync(BusType.SYSTEM, org.freedesktop.NetworkManager.Settings.Connection, /org/freedesktop/NetworkManager/Settings/15); Here's the problem: you still need to use the NetworkManager dbus service name, which is org.freedesktop.NetworkManager. What you're passing in here looks like the *interface* name you want to use when talking to the /org/freedesktop/NetworkManager/Settings/15 object. So remove the .Settings.Connection bit from that and you should get your proxy. The interface name is already specified at the top where you define the interface for the Connection object. Dan Ok I modified it and it works, next time I'll read the documentation better :-) Thanks a lot Florent ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trying to use the DBus API with QtDBus - does the example work?
Em Wednesday 21 December 2011, devine-ml...@ddevnet.net escreveu: On Wed, 21 Dec 2011 10:21:45 -0200, Lamarque V. Souza wrote: You should use the Settings path to get the settings for a connection: I figured that out minutes before I saw your reply :S DBUS Service: org.freedesktop.NetworkManager DBUS Object Path: /org/freedesktop/NetworkManager DBUS Interface: org.freedesktop.NetworkManager This little snippet made me think. Depending which Object you're working with you have different Interfaces available to manipulate the object. I found the Settings object, eventually. Initially I was trying to work with a Devices object. Now that I know this, I went over the example again and did see getConnection was indeed returning a settings path. You should try QtNetworkManager instead of creating your program from scratch: https://projects.kde.org/projects/kdereview/libnm-qt QtNetworkManager make those details transparent. Unfortunately there is not small example of how to use it. I use it in Plasma NetworkManagement, but Plasma NM is a big program. If you want to try take a look at manager.h and connection.h, those probably contain the methods you are looking for. This is great news. The bad news is that I am very new to Qt and C++ so it may be too tricky for me to get started without examples. The functionality I need is the basic set: getting interfaces, IP addresses, default gateway, setting an IP addresses... Not much past that. Do you think you could put together a small example that lists interfaces and sets an IP address on an interface? I added one example of how to list interfaces and retrieve the IP configuration (for static and dhcp). Git pull the repository and look at the examples directory. I still need to create the example for setting a IP address, which is not that simple since with NM you have to create a connection with the IP configuration first. The GObject and Python APIs look so simple :( Well, QtNetworkManager is a working in progress and as so it is not finished yet. -- Lamarque V. Souza KDE's Network Management maintainer http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
