Re: T-Mobile Contributions
On Fri, 2023-09-08 at 13:42 -0700, matthew stanger wrote: > Greetings MM, > > I'm excited to announce that T-Mobile US is now using > ModemManager/libMBIM/libQMI > for our 5G Fixed Wireless products > [https://www.t-mobile.com/home-internet]. We > are currently the largest FWA ISP in the world with well over 3 > Million > subscribers, i.e., lots of ModemManager users! We did this via an > architectural > contribution in partnership with the RDK community, a popular > STB/Router Linux > distro running on over 100 Million devices. > > MM is now supported in RDK via a FOSS MM connection manager, > CellularManager > [ > https://code.rdkcentral.com/r/plugins/gitiles/collaboration/rdkb/compo > nents/ > opensource/ccsp/RdkCellularManager-MM/+/refs/heads/main] > (need to signup for a free login), and is being worked on by dozens > of major OEMs > & ISPs. If anyone wants to provide feedback or reviews, please let me > know. > > We're working hard to realize the full potential of this community by > providing > quality merge requests, via our partners & RDK, and guiding modem > makers towards > standards like QMI/MBIM. Please keep an eye out for us and our > partners on the > ML & Gitlab! That's awesome! Never imagined the kind of reach MM has achieved when the project got started long long ago... Dan
Re: mbim, signal quality atds_signal_query vs. signal_state_query
On Mon, 2023-01-02 at 13:40 +0100, Aleksander Morgado wrote: > Hey, > > > quite a while ago, I reported inconsistencies with Telit LE910Cx > > signal quality query when using mbim (see > > https://www.mail-archive.com/modemmanager-devel@lists.freedesktop.org/msg06990.html > > ). Now I had to get back to this issue, since our customers heavily > > complain about the bad signal quality shown (although the > > connection is good and fast). > > > > While trying to find a solution I stumbled across the > > atds_signal_query message and experimentally used it instead the > > signal_state_query mbim message. The result is, that the signal > > quality is now much higher and matches what we see when not using > > mbim (and matches what we see on the same location using other LTE > > modems). > > > > So my questions are: > > > > Is there any documentation about the atds_signal_query command? I > > did not find any. > > ATDS is an AT specific extension that most manufacturers implement. > I truly don't recall where I found it, but it is likely somewhere out > there. I originally got it from the Wireshark MBIM dissector: https://github.com/freedesktop/libmbim/commit/1f86135579311bb22d391bde39024f8fb1d014b8 which was based on "AT Windows 8 Extended API Requirements" which is no longer easily available (that I can find). https://github.com/wireshark/wireshark/commit/6c0972bcd6e76bb4e22f729463ccfa5dad84eaff I don't think ATDS really advanced much so standard MBIM is probably a better bet these days. Dan > > > Do I have to expect problems when I prefer using atds_signal_query > > over signal_state_query > > If you're doing a query, operation-wise it should be equivalent. > > > How to submit that change to modemmanager so that it can be used by > > others? > > Please note that you can also enable the "extended signal quality > support" in the Signal interface. If you do that on a MBIM capable > modem, it will default to use either Microsoft extensions service or > otherwise the ATDS service. So there is already some support there if > you want to use it. > > If you would like to change the default signal quality loading logic > in MBIM so that it uses ATDS instead of the original MBIM service, > this one is trickier, because, which one would you use? What if some > other modem has the original MBIM command working better than the > ATDS > one? The ATDS one also lacks support for threshold configuration so > no > indication support, it is exclusively a polling-based operation which > isn't ideal. I'd suggest you try with the Signal interface first to > see if that fits your needs. > > Also, why would those values be so different? This is something Telit > should probably investigate. > > > Should the command be used for this particular modem only, for all > > telit modems or even for all mbim modems? (In the patch I currently > > use, I use that command on all mbim modems that have the command > > available) > > > > Is the patch completely removing the original method? Or do you apply > the ATDS method instead of the original one for your device? > Something > like this could be gated via a new udev tag that modifies the default > behavior (e.g. see ID_MM_QMI_CONNECTION_STATUS_POLLING_ENABLE for a > similar thing with a different default behavior change in QMI > modems). >
Re: Can't connect using ModemManager when modem is in QMI mode
On Wed, 2022-01-19 at 17:25 +, Bushman, Jeff wrote: > Hi Aleksander, > > I am revisiting this with a little more information, and a better > understanding of what you wrote. > > A simple-connect from ModemManager always fails. I can always connect > from qmicli (Abbreviated log below; stripped out raw data in this > trace) > > But as you say, when connecting via ModemManager, the modem sends > indications that the Preferred Data System goes to 'unknown' and the > ps_attach_state goes to 'detached' > > Is there any way to manually turn on indications and monitor them from > qmicli or get ModemManager to ignore these indications just to see if > it's just a bug in the modem firmware? Could there be some other > initialization of the modem by ModemManager that triggers this > behavior? > > Jeff > > root@wwan:/$ qmicli -d /dev/cdc-wdm0 --wds-start- > network=apn='broadband' --client-no-release-cid I see you have --client-no-release-cid however: [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Releasing 'wds' client with flags 'none'... [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Unregistered 'wds' client with ID '36' [12 Jan 2022, 01:23:09] [Debug] Client released [12 Jan 2022, 01:23:09] [Debug] Closed which would terminate the data connection... not sure what the solution is, but that's likely the cause. Dan > --device-open-proxy --verbose > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Opening device with > flags 'proxy, auto'... > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] automatically selecting > QMI mode > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] created endpoint > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Sent generic request > (translated)... > << QMUX: > << length = 27 > << flags = 0x00 > << service = "ctl" > << client = 0 > << QMI: > << flags = "none" > << transaction = 1 > << tlv_length = 16 > << message = "Internal Proxy Open" (0xFF00) > << TLV: > << type = "Device Path" (0x01) > << length = 13 > << value = 2F:64:65:76:2F:63:64:63:2D:77:64:6D:30 > << translated = /dev/cdc-wdm0 > > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Received generic > response (translated)... > << QMUX: > << length = 18 > << flags = 0x80 > << service = "ctl" > << client = 0 > << QMI: > << flags = "response" > << transaction = 1 > << tlv_length = 7 > << message = "Internal Proxy Open" (0xFF00) > << TLV: > << type = "Result" (0x02) > << length = 4 > << value = 00:00:00:00 > << translated = SUCCESS > > [12 Jan 2022, 01:23:09] [Debug] QMI Device at '/dev/cdc-wdm0' ready > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Assuming service 'wds' > is supported... > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Allocating new client > ID... > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Sent generic request > (translated)... > << QMUX: > << length = 15 > << flags = 0x00 > << service = "ctl" > << client = 0 > << QMI: > << flags = "none" > << transaction = 2 > << tlv_length = 4 > << message = "Allocate CID" (0x0022) > << TLV: > << type = "Service" (0x01) > << length = 1 > << value = 01 > << translated = wds > > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Received generic > response (translated)... > << QMUX: > << length = 23 > << flags = 0x80 > << service = "ctl" > << client = 0 > << QMI: > << flags = "response" > << transaction = 2 > << tlv_length = 12 > << message = "Allocate CID" (0x0022) > << TLV: > << type = "Result" (0x02) > << length = 4 > << value = 00:00:00:00 > << translated = SUCCESS > << TLV: > << type = "Allocation Info" (0x01) > << length = 2 > << value = 01:24 > << translated = [ service = 'wds' cid = '36' ] > > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Registered 'wds' > (version unknown) client with ID '36' > [12 Jan 2022, 01:23:09] [Debug] Network start parameters set (apn: > 'broadband', 3gpp_profile: '0', 3gpp2_profile: '0', auth: > 'unspecified', ip-type: 'unspecified', username: 'unspecified', > password: 'unspecified', autoconnect: 'unspecified') > [12 Jan 2022, 01:23:09] [Debug] Asynchronously starting network... > [12 Jan 2022, 01:23:09] [Debug] [/dev/cdc-wdm0] Sent generic request > (translated)... > << QMUX: > << length = 28 > << flags = 0x00 > << service = "wds" > << client = 36 > << QMI: > << flags = "none" > << transaction = 1 > << tlv_length = 16 > << message = "Start Network" (0x0020) > << TLV: > << type = "IP Family Preference" (0x19) > << length = 1 >
Re: ANN: ModemManager 1.18.4 released / Avoiding PPP
On Tue, 2022-01-18 at 09:57 +0100, Aleksander Morgado wrote: > Hey Dan! > > > > > > If MM detects a single TTY port, it's going to default to use > > > > > PPP. > > > > > It's not a fallback to PPP, it's using whatever it has for > > > > > data > > > > > connection, if PPP is the only way forward, PPP will be. > > > > > > > > I don't want PPP, ever. I don't know how many times I can > > > > repeat > > > > that. Please stop saying this and arguing with me about it. > > > > > > > > > > I know you don't want PPP in your setup, you have made that > > > clear. > > > I'm > > > not arguing with you about that. I get it. You don't want PPP. > > > > Yeah, MM has to work for a lot of people, some who want PPP and > > many > > who don't. But there's still enough PPP going around that it must > > continue to be supported for a while. > > > > Plus, I don't think this is something we can just optionally remove > from the build, just the PPP part. This is not like QMI or MBIM where > we can disable the full QMI or MBIM protocol, both control and data. > The equivalent thing would be to fully disable AT+PPP; but just > disabling PPP is not a good idea IMO, because we could end up leaving > not-connectable AT-only modems around (unless we want to allow such a > thing) Yeah, I don't think it should be removed entirely; it's really not a lot of code over-and-above AT itself. Which is still used for a *lot* of stuff. > > > > > > > Now, the way to fix that should be by making sure ModemManager > > > gets > > > notified of the QMI/NET port before it creates a modem object > > > only > > > with TTY ports. I understand that you don't like this approach, > > > but > > > ModemManager doesn't receive a fixed list of ports to work with, > > > as > > > many other modem management setups. MM tries to dynamically > > > adjust to > > > what it finds, and that is a core feature of ModemManager that is > > > not > > > going to change. > > > > In the past IIRC we've seen bad udev rules or scripts taking > > multiple > > seconds to evaluate or do something (I think usb_modeswitch was a > > problem here once upon a time) and delaying updates for specific > > ports > > of a device. Not sure if that's a problem here, or if the system is > > just slow. > > > > The problem is the system being slow plus needing mmcli to report the > kernel events when openwrt hotplug scripts are run, which make it > even > slower. This issue won't apply to udev based systems, I think it's > applicable only to openwrt. Ah, ok. > > > > > > > So again, and don't hate me for repeating this, if MM gets > > > notified > > > of > > > one single AT capable TTY port and nothing else, it will default > > > to > > > use PPP. If you don't like that, please patch your ModemManager > > > to > > > fit > > > your needs. Or try moving to uqmi, which requires you to specify > > > which > > > is the cdc-wdm port path explicitly, although that approach has > > > its > > > own problems, but maybe not the ones you're worried about. > > > > I haven't read the whole thread in detail, so forgive me if this > > was > > covered. Perhaps a way of tagging a modem/driver/whatever with > > "never > > use PPP" would be workable. Off by default of course. > > > > The problem with that is what you do when you have a modem exposed > with one single AT port, which is what ended up happening in Peter's > setup. Do we expose the modem in DBus but not connectable? Do we > expose it in Failed state? Do we just not expose the modem in DBus? > The problem here is not a QMI+AT modem that sometimes falls back to > PPP; the problem here is an AT-only No-QMI (because it failed > probing) > modem that falls back to PPP. I'd just expose the modem as failed and let the admin/framework/whatever handle it by power-cycling the modem or machine. If we didn't expose it then it would be more complicated with timeouts or something on whatever is above MM. > > My suggestion has always been to fix the probing logic so that the > QMI > ports are properly detected always; and once that is done and is > reliable, there would be no need to take care of whether PPP is used > or not, as QMI would always be preferred. PPP is only the fallback if > QMI is unusable for any reason. Trying to remove PPP without fixing > the probing logic leads nowhere. And once probing logic is fixed, > removing PPP would not be needed. Yeah, clearly if we can fix or work around slow probing, that's preferable. Dan
Re: ANN: ModemManager 1.18.4 released / Avoiding PPP
On Tue, 2022-01-18 at 05:35 -0500, Peter Naulls wrote: > On 1/17/22 2:06 PM, Dan Williams wrote: > own problems, but maybe not the ones you're worried about. > > > > I haven't read the whole thread in detail, so forgive me if this > > was > > covered. Perhaps a way of tagging a modem/driver/whatever with > > "never > > use PPP" would be workable. Off by default of course. > > If you like. Whatever is going to work for the general use case. > > However, no matter how you finely tune it, no matter how you choose > values, > there's always a chance of detection failure (which is OK), but > falling > back to PPP is never going to be acceptable, certainly not in what > I'm > building. I don't need to be debugging such situations in the field; > there's no justification for it. What's your desired error state when detection fails? Just mark the whole modem as failed, and you'd have some custom logic to twiddle modem power and/or reboot the machine? or something else? Dan > > I'd prefer to pursue removing PPP dependency entirely as I'm doing; > that saves space, and reduces complexity. Let me know if is going > to be something that works for you. I just wish I'd done this 6 > months ago; would have saved myself a lot of grief. > > > > >
Re: ANN: ModemManager 1.18.4 released / Avoiding PPP
On Fri, 2022-01-14 at 16:29 +0100, Aleksander Morgado wrote: > Hey Peter, > > On Fri, Jan 14, 2022 at 4:14 PM Peter Naulls > wrote: > > > > On 1/14/22 10:09 AM, Aleksander Morgado wrote: > > logic is not going to change. > > > > > > If MM detects a single TTY port, it's going to default to use > > > PPP. > > > It's not a fallback to PPP, it's using whatever it has for data > > > connection, if PPP is the only way forward, PPP will be. > > > > I don't want PPP, ever. I don't know how many times I can repeat > > that. Please stop saying this and arguing with me about it. > > > > I know you don't want PPP in your setup, you have made that clear. > I'm > not arguing with you about that. I get it. You don't want PPP. Yeah, MM has to work for a lot of people, some who want PPP and many who don't. But there's still enough PPP going around that it must continue to be supported for a while. > > Now, the way to fix that should be by making sure ModemManager gets > notified of the QMI/NET port before it creates a modem object only > with TTY ports. I understand that you don't like this approach, but > ModemManager doesn't receive a fixed list of ports to work with, as > many other modem management setups. MM tries to dynamically adjust to > what it finds, and that is a core feature of ModemManager that is not > going to change. In the past IIRC we've seen bad udev rules or scripts taking multiple seconds to evaluate or do something (I think usb_modeswitch was a problem here once upon a time) and delaying updates for specific ports of a device. Not sure if that's a problem here, or if the system is just slow. > > So again, and don't hate me for repeating this, if MM gets notified > of > one single AT capable TTY port and nothing else, it will default to > use PPP. If you don't like that, please patch your ModemManager to > fit > your needs. Or try moving to uqmi, which requires you to specify > which > is the cdc-wdm port path explicitly, although that approach has its > own problems, but maybe not the ones you're worried about. I haven't read the whole thread in detail, so forgive me if this was covered. Perhaps a way of tagging a modem/driver/whatever with "never use PPP" would be workable. Off by default of course. Dan
Re: Telit LE910Cx, MBIM vs AT
On Thu, 2021-12-02 at 15:57 +0100, Ulrich Mohr wrote: > Hi there, > I got a Telit LE910C1-EU attached to an embedded device, using > ModemManager 1.19.0 (main branch, 2 commits behind) and libmbim > 1.27.3 (main branch, 1 commit behind). Linux Kernel is v5.12. > I was able connect successfully to an LTE network using both PPP (USB > profile 0x1201, 3 AT ports) and MBIM (USB profile 0x1252, MBIM + 2AT > ports). Both configurations seem to work -- I was able to ping a > server using those interfaces. > But there are some inconsistencies that I see: > * While PPP shows a signal quality of 85%, MBIM only shows between 9 > and 19 % signal quality. (When I use a AT+CSQ command in MBIM mode, > the result is 20 which is in the middle of the range, so I that > should be more than 20%) AT+CSQ and MBIM are different ways of measuring, so it depends on what the numbers you get are. Are you able to run mbimcli's "query-signal- state" option on the device? What do you see? What is the raw value from CSQ? In the end, it may just be a difference in how the firmware calculates and reports the value. > * While PPP does not show any sim lock, MBIM shows a SimPin2 lock > (although we are connected). This is normal, the PIN2 lock controls stuff that isn't necessary for normal operation. > So my question are: > * Is it normal / ok to see those inconsistencies? Yes. > * Where do these inconsistencies come from? The firmware implementation of AT (PPP) vs. MBIM is different. > * Where to start looking to fix those inconsistencies? By asking the manufacturer to change the firmware, unfortunately. > * Can I safely ignore the SimPin2 lock? Yes. > * What limitations do I get when I use PPP instead MBIM? Mostly speed. PPP will be pretty bandwidth limited and you won't be able to achieve anywhere near full LTE speeds without MBIM. MBIM is also typically more reliable than AT+PPP since it talks to the modem more directly and the control path is simpler. Dan > I have no experience with MBIM at all, so perhaps I got something > wrong completely? > BTW: I also tried RNDIS, but that is ignored by MM completely. > Instead, the AT ports are used for PPP connection. I assume there is > no support for RNDIS within the telit plugin? > Thank you in advanced, any help appreciated :-)
Re: ANN: ModemManager 1.18.4 released
On Mon, 2021-11-29 at 10:52 -0500, Peter Naulls wrote: > On 11/26/21 4:52 AM, Aleksander Morgado wrote: > > Hey hey, > > > > This is the second bugfix release in the 1.18.x series, built from > > the mm-1-18 > > branch. > > > > Thanks! > > I've been chasing, as I mentioned a while ago, where "sometimes" the > modem > connection will be brought up as PPP, not qmi. This kind of > connection fails > in our setup for a bunch of reasons, and is not desirable. > > I know that PPP is woven into ModemManager for several reasons, and > building > without is some work - I've seen several prior discussions on this > topic. > > I'm using a custom version of OpenWrt which is approximately the > current > release. I've mitigated the problem somewhat by removing the PPP > connection > scripts (/lib/netif/ppp*), which helps a little. I'm using > ModemManager > 1.18.2 presently, which seems to work pretty well against kernel > 4.14.256. > Some versions of the kernel (perhaps due to timing or whatever) seem > to > trigger the problem more often, although it's hard to confirm that > one > way or another. > > The QMI driver I have is highly customized, and may well be the root > of the > problem - recent kernels seem to have some validation around USB > devices > and whatnot. > > In any case, I tested 1.18.4 today, and 100% of the time the > connection > now comes up in PPP. It's not clear from the changes why this might > now happen - perhaps there's extra validation or something. But I'd > really like to get to the bottom of this - any suggestions in the > current > changes that I should look at? Do you have debug logs from MM? At the very least MM has to find a netdevice for the modem, otherwise it would fall back to an available AT port for PPP. Does MM find one? Dan
Re: Need help troubleshooting Quectel EG25 modem in Pine64 Pinephone
On Mon, 2021-06-14 at 10:55 +0200, Aleksander Morgado wrote: > Hey, > > > > > > Can you run "AT+CGDCONT?" with minicom (or otherwise, running> > > > ModemManager with --debug and then mmcli --command="AT+CGDCONT?") > > > > Here's the output of atinout: > > > > ``` > > $ echo "AT+CGDCONT?" | sudo atinout - /dev/ttyUSB2 - > > > > ERROR > > ``` > > This does not make any sense Sometimes AT ports run limited parsers, but I've only seen that on older modems where the limited AT port was for PPP and nothing else. Are there any other ttys that respond to AT commands? Does this port respond to AT+GCAP or AT+CLAC ? Dan > > > > > I confirmed that /dev/ttyUSB2 is the right device, as it responds > > with > > "OK" to "AT". > > > > > > > > > > Can you run these qmicli commands? > > > qmicli -p -d /dev/cdc-wdm0 --wds-get-profile-list=3gpp > > > > $ sudo qmicli -p -d /dev/cdc-wdm0 --wds-get-profile-list=3gpp > > Profile list retrieved: > > [1] 3gpp - > > APN: '' > > PDP type: 'ipv4-or-ipv6' > > PDP context number: '1' > > Username: '' > > Password: '' > > Auth: 'none' > > No roaming: 'no' > > APN disabled: 'no' > > [2] 3gpp - > > APN: 'ims' > > PDP type: 'ipv4-or-ipv6' > > PDP context number: '2' > > Username: '' > > Password: '' > > Auth: 'none' > > No roaming: 'no' > > APN disabled: 'no' > > [3] 3gpp - > > APN: '' > > PDP type: 'ipv4-or-ipv6' > > PDP context number: '3' > > Username: '' > > Password: '' > > Auth: 'none' > > No roaming: 'no' > > APN disabled: 'no' > > > > > > Well that looks pretty empty... Is this user-configurable, or does > > mmcli fill these in for me? > > > > Those are the settings stored inside the module. They should have > reported the same info as "AT+CGDCONT?". > > > > > > qmicli -p -d /dev/cdc-wdm0 --wds-get-lte-attach-pdn-list > > > > $ sudo qmicli -p -d /dev/cdc-wdm0 --wds-get-lte-attach-pdn-list > > Attach PDN list retrieved: > > Current list: '1' > > Pending list: n/a > > > > > > > > If your SIM card is O2 but the registration in the O2 network is > > > not > > > working, it may still be the initial EPS bearer settings, I think > > > you > > > should focus on debugging that. > > > > > > > That's what "--3gpp-set-initial-eps-bearer-settings" is for, right? > > Is > > there any other command that deals with the initial EPS bearer > > settings? > > > > It seems to me that merely entering the APN for the initial bearer > > settings doesn't change anything, and I don't know which ip-types > > or > > authentications this provider supports. > > You need to know what your provider expects as initial APN settings. > > > I have tried some, and for some > > combinations a "--3gpp-register-home" tells me it connected > > successfully, while in mmcli I still see that it's connected to the > > wrong operator. > > The "--3gpp-register-home" option instructs the modem to > automatically > select which is the best network to register to. If there are more > than one suitable networks and it failed to register in one of them > it > may have tried to register in a different one. > > > In fact today it has already connected to every > > operator except the one I'd need it to. I also still can't enforce > > it. > > > > The registration in a given operator is mandated by what your SIM > card > dictates. ModemManager doesn't do any explicit attempt to register in > a given operator by itself; if you set it to "auto" > (--3gpp-register-home), the modem will try to do what's best for you. > > > > > Is there something like a command to generate a full dump of all > > settings that mmcli works with, such that I could ask someone with > > a > > working modem on the same provider to show me their settings? > > There is no such thing as "settings mmcli works with"; all the > settings are inside the modem, and you already listed the ones in > yours with the qmicli wds profile list. The settings being used for > initial APN are the ones in profile #1 (as per your > --wds-get-lte-attach-pdn-list call). > > So what you're using as settings is the empty APN and IPv4v6. If your > network requires an specific initial APN you need to configure that > in > that profile, with --3gpp-set-initial-eps-bearer-settings > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: AW: QMI protocol error (14): 'CallFailed''
On Mon, 2021-03-01 at 11:11 +, Federico Murciano wrote: > The same happens if I try with: > > sudo qmi-network /dev/cdc-wdm0 start > > Profile at '/etc/qmi-network.conf' not found... > Checking data format with 'qmicli -d /dev/cdc-wdm0 --wda-get-data- > format '... > Device link layer protocol retrieved: raw-ip > Getting expected data format with 'qmicli -d /dev/cdc-wdm0 --get- > expected-data-format'... > Expected link layer protocol retrieved: raw-ip > Device and kernel link layer protocol match: raw-ip > Starting network with 'qmicli -d /dev/cdc-wdm0 --wds-start-network= > --client-no-release-cid '... > error: couldn't start network: QMI protocol error (14): 'CallFailed' > call end reason (1): generic-unspecified > verbose call end reason (2,208): [internal] pdn-ipv4-call-disallowed This says you can't use IPv4 on this APN. Try setting the IP family to v6 only, or v4v6 (maybe?). sudo mmcli -m 1 --simple-connect="apn=internet.telekom,ip-type=ipv6" sudo START_NETWORK_ARGS="ip-type=6" qmi-network or something like that. In the mmcli case earlier, it the verbose error code was "verbose call end reason (2,241): [internal] interface-in-use- config-match" which might indicate that the connection was already active but using different settings than you asked MM to use. Dan > Saving state at /tmp/qmi-network-state-cdc-wdm0... (CID: 17) > error: network start failed, no packet data handle > Clearing state at /tmp/qmi-network-state-cdc-wdm0... > edge2@dai-edge2:~$ > > > Federico Murciano > > B.Sc. Telecommunications Engineer > federico.murci...@dai-labor.de > Tel. +49 (0) 30/314 -74 025 > Future in touch > DAI-Labor > Technische Universität Berlin > Fakultät IV – Elektrotechnik & Informatik Sekretariat TEL 14 Ernst- > Reuter-Platz 7 > 10587 Berlin, Germany > > http://www.dai-labor.de/ > DAI-Labor - Distributed Artificial Intelligence Laboratory Chief > Executive Director: Prof. Dr. Dr. h.c. Sahin Albayrak > > > Von: ModemManager-devel < > modemmanager-devel-boun...@lists.freedesktop.org> im Auftrag von > Federico Murciano > Gesendet: Montag, 1. März 2021 11:20 > An: Giacinto Cifelli > Cc: modemmanager-devel@lists.freedesktop.org > Betreff: AW: QMI protocol error (14): 'CallFailed'' > > Hello everyone, > > Could someone help me with what is going wrong? I am still having > problems when I try to connect the Modem. I follow the steps: > > Sudo mmcli -i 0 -- > pin= > Enter PIN SIM > Sudo mmcli -m 1 --enable -- > timeout=120 > Enable Modem > sudo mmcli -m 1 --simple- > connect="apn=internet.telekom" > Connect modem to APN > > After this step I always get the error: > > error: couldn't connect the modem: > 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.CallFailed: QMI > protocol error (14): 'CallFailed'' > > It looks like it is connecting right but then this error happens and > I dont achieve to set the status = Connected, even if I have already > an IP from the operator: > > at+cgpaddr=1 > +CGPADDR: > 1,"10.174.67.152,42.1.5.152.177.132.73.56.0.1.0.0.134.113.2.203" > > I get the following logs from ModemManager: > > ModemManager[485235]: [1614593449.789165] [modem0] user > request to connect modem > ModemManager[485235]: [1614593449.789225] [modem0] simple > connect started... > ModemManager[485235]: [1614593449.789242] [modem0] PIN: > unspecified > ModemManager[485235]: [1614593449.789255] [modem0] > operator ID: unspecified > ModemManager[485235]: [1614593449.789267] [modem0] allowed > roaming: yes > ModemManager[485235]: [1614593449.789277] [modem0] APN: > internet.telekom > ModemManager[485235]: [1614593449.789289] [modem0] IP > family: unspecified > ModemManager[485235]: [1614593449.789300] [modem0] allowed > authentication: unspecified > ModemManager[485235]: [1614593449.789310] [modem0] User: > unspecified > ModemManager[485235]: [1614593449.789320] [modem0] > Password: unspecified > ModemManager[485235]: [1614593449.789330] [modem0] simple > connect state (4/8): wait to get fully enabled > ModemManager[485235]: [1614593449.789356] [modem0] simple > connect state (5/8): register > ModemManager[485235]: [1614593449.789379] [modem0] already > registered automatically in network '26201', automatic registration > not launched... > ModemManager[485235]: [1614593449.789400] [modem0] simple > connect state (6/8): bearer > ModemManager[485235]: [1614593449.789414] [modem0] creating > new bearer... > ModemManager[485235]: [1614593449.789602] [modem0] simple > connect state (7/8): connect > ModemManager[485235]: [1614593449.789673] [modem0/bearer2] > connecting... > ModemManager[485235]: [1614593449.789698] [modem0] state > changed (registered -> connecting) >
Re: [RFC] What to do by default with DIAG/QCDM ports
On Mon, 2020-12-14 at 09:50 +0100, Aleksander Morgado wrote: > Hey Dan and all, > > The DIAG/QCDM ports were extremely important in some old CDMA modems > that required them for control instead (or in addition to) the AT > ports, at least for several purposes like gathering access tech info > and such. Due to that, MM has been attempting QCDM probing by default > in all TTYs without explicit hints, and also obviously in the ports > flagged as QCDM. > > In the past years, this need of the QCDM port during runtime has > been, > I believe, non-existent; at least for all new modules. There has been > a real usecase, though, that our automatic port probing has been > interfering with, which is the ability to gather QXDM logs by the > users when the vendor requires them to do so in order to debug > problems. These logs are gathered via QXDM, and ModemManager touching > the port has been interfering with that operation in a bad way, > forcing all users to explicitly ID_MM_PORT_IGNORE those ports on top > of our default rules. > > My suggestion, let me know what you all think, would be to: > 1) No longer automatically probe for QCDM capabilities in the TTY > ports that are not flagged with port type hints. Sounds fine to me. It's probably "easy" to figure out which devices/drivers can benefit from QCDM, except that (unfortunately) many of those will be driven by 'option'. Is it possible to only probe QCDM for certain modems, and only if AT+GCAP returns 3GPP2 responses? > 2) If the TTY is flagged with QCDM port type hint, also avoid the > explicit probing, just assume it is capable of doing QCDM/DIAG. I'm less sure about this. But most cases I can think of that need this are old 2-port devices, one AT and one QCDM, so if we find an AT port, the other is most likely QCDM. > 3) Avoid using the QCDM ports during runtime in all 3GPP capable > modules, and only use them in 3GPP2-only modules. Probably OK. Some old Qualcomm devices (mdm6x range? and some old 2G phones) IIRC only had two ports, AT+PPP and QCDM and you needed DM to get system state and signal status while connected. But it's probably safe to assume that anything UMTS or later doesn't need QCDM, and special-case those that do. > I'm sure we would be losing support for some old modules if we do > that > above, as we don't have explicit port type hints for all modules, so > not sure what you all think. > > Ideally, we would have a list of known CDMA modules that do require > the QCDM port for sure (i.e. that require QCDM for operations that > are > not possible with AT or QMI). Maybe it's not that difficult to build > that list? We can start to build that list, at least? Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Help on an invalid modem case
On Wed, 2020-08-12 at 12:10 +, Louis-Alexis Eyraud wrote: > Hi Aleksander, > > cool that the setup has been useful for your debugging > I have 4 other Huawei models (3 of them are E352 variants) and an > Alcatel. I will test your branch this afternoon with these modems > and give you some feedback. I'll test the branch this week with my devices as well. I thought I had a 352 somewhere, but it's hard to keep all their model numbers straight. Dan > Louis-Alexis > > From: Aleksander Morgado > Sent: 12 August 2020 13:33 > To: Louis-Alexis Eyraud > Cc: ModemManager (development) < > modemmanager-devel@lists.freedesktop.org> > Subject: Re: Help on an invalid modem case > > Hey Louis-Alexis, > > > sorry for the delay, I was on holiday the past weeks. > > I've retrieved the "faulty" 3G modem device from my office. For > > information, the exact model is Huawei e352u-21 (other e352 > > variants I tested do not seem to provoke the issue). > > > > I did a more standard setup at home to reproduce it: a RPI3 with > > Raspbian, ModemManager compiled from sources and various system > > configuration tweaks to force broadband management. > > The setup also allowed me to verify that in CDC mode, it does not > > appear. > > > > If you need to do some debug or test a fix for any of the two bugs > > you opened, feel free to contact me privately to give you access to > > this setup. > > > > Thanks for the access to your remote setup, that was very helpful. > > I've prepared a branch with several changes, including a big > GETPORTMODE logic upgrade: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmobile-broadband%2FModemManager%2F-%2Fmerge_requests%2F335data=02%7C01%7Clouis-alexis.eyraud%40sigfox.com%7Cbacaf731dae04aa2223b08d83eb39687%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637328288328929987sdata=dniU3Yh%2BUKCJc6jOMC02yfRLPI50MX0uWUBpsGzEP2k%3Dreserved=0 > > This branch should solve the issues you had in the E352, please > confirm. Also, if you can test the branch yourself with additional > Huawei devices, it would be nice (please grab debug logs while doing > so just in case). > > -- > Aleksander > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faleksander.es%2Fdata=02%7C01%7Clouis-alexis.eyraud%40sigfox.com%7Cbacaf731dae04aa2223b08d83eb39687%7Cfcbc8bb1061e4b949f703ad917b0c8d3%7C0%7C0%7C637328288328929987sdata=t%2B9zWk5LtyqymKSw83hk8xEDEFcCXOqkf3sSGPDGvlQ%3Dreserved=0 > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Adding Telit ME310G1-WW support
On Tue, 2020-07-14 at 14:59 -0400, Mark Deneen wrote: > On Mon, Jul 13, 2020 at 1:13 PM Mark Deneen > wrote: > > On Mon, Jul 13, 2020 at 1:04 PM Daniele Palmas > > wrote: > > > Hi Mark, > > > > > > Il giorno lun 13 lug 2020 alle ore 15:17 Mark Deneen > > > ha scritto: > > > > Daniele, > > > > > > > > > @Mark, did you check if there's a more recent firmware update > > > > > than the > > > > > one you are using? > > > > > > > > I'm running 37.00.210-B038-P0C.21, but I'm having trouble > > > > understanding if any of the available firmware releases apply > > > > to the > > > > model number that I have. Regardless, the firmware seems only > > > > made > > > > available as Windows binaries and my modem is soldered to a > > > > board with > > > > an ARM processor. Is there a way to update the firmware in > > > > Linux? I > > > > have used the HE910 module in the past and was able to flash > > > > firmware > > > > from an ARM-based Linux platform, but perhaps they do things > > > > differently now. > > > > > > > > > > better reach directly Telit TS for both the things. > > > > Indeed -- I am awaiting a response. Thanks again for your help! > > I received word from Telit support -- the missing "CONNECT" message > is > a known issue. While there is no release as of yet to correct this, > it is slated for August. > > I'm thinking that the answer here is to forget this patch, knowing > that it will be fixed in the not-too-distant future in a firmware > release. Thoughts? I agree. Could you reply to this thread if/when that firmware is released so we close the loop on it? Thanks! Dan > -M > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: libmbim 1.24.0 slowing down MM startup
On Fri, 2020-07-10 at 10:28 +0200, Aleksander Morgado wrote: > Hey Amol, > > > > Did you got a chance to see those logs? Please let me know if any > > > other information is needed. > > > > > > > Not yet, sorry. Will let you know as soon as I find anything. > > > > Here's the fix: > https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/28 > > I'll release a new 1.24.2 with this and other fixes. Ouch, nice catch :) Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Sims card informations
On Wed, 2020-07-08 at 14:43 -0400, David Khouya wrote: > Hi, > > I'm working on an embedded device and I would like to handle > correctly the > preferred modes with different sim cards. E.g. If I have a 3G sim > card, I > would like to set preferred mode to 3G instead of 4G. > My use case is that I need to support,with the same filesystem, 3G > and 4G > sims. > > I was wondering , except ICCID, if there's other information > available from > the sim card that could help to set the preferred mode. I'm sure there is that kind of information, but it may not be the case that ModemManager or libqmi expose it (yet). We'd need to figure out what SIM file has the right information. Dan > Thanks, > > On Wed, Jul 8, 2020 at 2:31 PM Mrkiko Rs wrote: > > > Hello! If I understand this right, you may get the ICCID and > > distinguish > > SIM cards. > > Or do you need something different? > > > > > > > > > > Hi, > > > > Is someone know or have a strategy to select the right mode > > (4G/3G/2G) for > > a specific sim card? Is it possible from the sim card information? > > > > Thanks, > > > > -- > > *David Khouya* > > > > > > ___ > > ModemManager-devel mailing list > > ModemManager-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel > > > > > > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Fibocom L850-GL / Intel XMM7360
On Mon, 2020-06-22 at 09:42 +0200, Aleksander Morgado wrote: > Hey, > > > > Anyway, FWIW, I'd explore the PCIe driver option first if I were > > > you. > > > That's the only mode tested by anyone, so it is more likely to > > > work. > > Is there anybody reading this willing and knowlegable enough to > > work on > > a kernel driver for inclusion in mainline? I'm able to provide > > funding > > and hardware for testing... > > > > If I'm not mistaken, Intel themselves are working on implementing the > PCIe driver for these XMM based modules, but I don't know how well > that is going, or when it's going to happen. I'll ask Fibocom to see > if they have updates. It exists, is for 7560 and later, and may be proposed soon. Not sure how hard it would be adapt to earlier devices, but that would probably require some community input. Dan > If switching the L850-GL to USB mode works, though, that would > probably work very well. The Dell DW5820e is a L850-GL in USB mode, > and I added a lot of support for that module in the past years. > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Fibocom L850-GL / Intel XMM7360
On Mon, 2020-06-22 at 10:45 +0200, Reinhard Speyerer wrote:
> On Mon, Jun 22, 2020 at 06:51:50AM +, Wassenberg, Dennis wrote:
> > Hi all,
> >
> > I tested the PCI approach.
> >
> > Unfortunately I had no luck. The kernel PCI driver at
> > https://github.com/xmm7360/xmm7360-pci can not initiale the modem
> > correctly. The modem stays at status=0xfeedb007. This seems to mean
> > that the modem is (still) booting. After 20 seconds
> > probing fails. The kernel driver gives up waiting for the device to
> > boot.
> >
> > So, both options: usb switch and native pci driver will not work.
> >
> > Are there any ideas how to continue?
> >
>
> Hi Dennis,
>
> some time ago Johannes Berg was working on a WWAN subsystem for the
> Linux
> kernel (
> https://lore.kernel.org/netdev/20200225100053.16385-1-johan...@sipsolutions.net/T/#t
> ) which also mentioned the 'upcoming Intel 4G modem driver ("iosm")'.
That effort is currently stalled. And the pci-based driver you mention
supports 7560 and later, not earlier devices. Not sure how hard it
would be to adapt to earlier devices though.
It does exist, but it's not quite ready for upstreaming yet.
Dan
> Perhaps it might help to ask him what the current status of this
> project is.
>
> Regards,
> Reinhard
>
> > Thank you & best regards,
> >
> > Dennis
> >
> >
> > On Thu, 2020-06-18 at 16:24 +0200, Dennis Wassenberg wrote:
> > > Hi Bjørn,
> > >
> > > thank you for your estimation.
> > >
> > > > Do you have any confirmation that it is actually possible to
> > > > switch this
> > > > firmware into USB mode? Are there other firmwares available
> > > > with
> > > > (possible) USB support?
> > > >
> > >
> > > I don't have a confirmation that the USB mode will really work,
> > > especially on the new models.
> > >
> > > Last year (Lenovo Thinkpad Whiskey Lake series) there was the
> > > possibility to choose between the slow modem (Fibocom
> > > L830-EB) and the faster option Fibocom L850-GL. This year the
> > > slow modem ist the fast modem of the last year and the
> > > fast modem is CAT16 Fibocom L860-GL.
> > >
> > > Regarding the Lenovo Thinkpad Whiskey Lake series models I found
> > > some threads where the USB mode switch worked:
> > >
> > > https://forums.lenovo.com/t5/Other-Linux-Discussions/WWAN-Fibocom-L850-GL-and-Linux-support/m-p/4318903?page=1#4327397
> > > https://gmt-24.net/archives/1461
> > >
> > > Thats why I assumed that this might work at newer Thinkpads as
> > > well.
> > >
> > > Especially https://gmt-24.net/archives/1461 shows that your
> > > assumption regarding the bootloader and application mode
> > > seems to be correct.
> > >
> > > This comes out directly after disabling the PCIe link and
> > > directly after that:
> > > [ 162.799214] usb 1-6: new high-speed USB device number 5 using
> > > xhci_hcd
> > > [ 162.940604] usb 1-6: New USB device found, idVendor=8087,
> > > idProduct=07f5, bcdDevice= 0.00
> > > [ 162.940612] usb 1-6: New USB device strings: Mfr=0, Product=0,
> > > SerialNumber=0
> > > [ 169.651754] usb 1-6: USB disconnect, device number 5
> > >
> > > Now bcdDevice changed to real device id.
> > >
> > > [ 175.462630] usb 1-6: new high-speed USB device number 6 using
> > > xhci_hcd
> > > [ 175.620153] usb 1-6: New USB device found, idVendor=2cb7,
> > > idProduct=0007, bcdDevice= 3.33
> > > [ 175.620162] usb 1-6: New USB device strings: Mfr=1, Product=2,
> > > SerialNumber=3
> > > [ 175.620167] usb 1-6: Product: L850-GL
> > > [ 175.620172] usb 1-6: Manufacturer: Fibocom Wireless Inc.
> > > [ 175.620176] usb 1-6: SerialNumber: 00499901064
> > >
> > >
> > > > Anyway, FWIW, I'd explore the PCIe driver option first if I
> > > > were you.
> > > > That's the only mode tested by anyone, so it is more likely to
> > > > work.
> > >
> > > Ok, I will try that approach and let you know my results.
> > >
> > > Thank you & best regards,
> > >
> > > Dennis
> > >
> > >
> > > On Thu, 2020-06-18 at 15:36 +0200, Bjørn Mork wrote:
> > > > "Wassenberg, Dennis" writes:
> > > >
> > > > > After that dmesg shows this:
> > > > > [ 930.843781] usb 1-7: new high-speed USB device number 16
> > > > > using xhci_hcd
> > > > > [ 930.996572] usb 1-7: New USB device found, idVendor=8087,
> > > > > idProduct=07f5, bcdDevice= 0.00
> > > > > [ 930.996577] usb 1-7: New USB device strings: Mfr=0,
> > > > > Product=0, SerialNumber=0
> > > > > [ 937.683939] usb 1-7: USB disconnect, device number 16
> > > > >
> > > > > So, in general I think there should be USB lines routed to
> > > > > the M.2 slot but I have no idea why the device leaves
> > > > > the
> > > > > bus. It is possible to run the script again and again but in
> > > > > the end it will always disconnect automatically.
> > > >
> > > > I know nothing about these modems, but my guess is that this is
> > > > a
> > > > bootloader mode. Mostly based on the assumption that there will
> > > > be one,
> > > > and that the vendor-id will be something non-Intel in
> > > >
Re: Question about dual qmi/mbim modems
On Thu, 2020-06-04 at 17:11 -0500, Alex Ballmer wrote: > On 2020-06-04 02:08, Aleksander Morgado wrote: > > Hey, > > > > On Wed, Jun 3, 2020 at 9:51 PM Alex Ballmer > > wrote: > > > I have noticed that Sierra Wireless MC4755 modems can operate in > > > both > > > QMI and MBIM modes. Modemmanager seem to try to use the modem as- > > > is in > > > whatever mode it is currently operating in. > > > > > > However, some features are only available in QMI mode. In my > > > experience > > > I could not reset a modem in MBIM mode. It resulted in > > > > > > mmcli -m 0 -r > > > error: couldn't reset the modem: 'GDBus.Error:org.freedesktop. > > > ModemManager1.Error.Core.Unsupported: Cannot reset the modem: > > > operation > > > not supported' > > > > > > > That changes in ModemManager 1.14, the reset operation is > > implemented > > in MBIM modems and will use either the Intel reset operation or the > > QMI based one internally, whatever fits the device. > > > > Is there a specific commit that I could look at where the MBIM reset > support is added? 9dc26cc44d79f18789a510e050fc899b680587ec 6026c99f2ec99e2721356ee645472d8403676bf6 Dan > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [RFC] Changing filter policy to 'strict' by default
On Thu, 2020-05-28 at 15:09 +0200, Aleksander Morgado wrote: > Hey all, > > I'm going to suggest we change the filter policy to 'strict' when > none > explicitly requested. In the past 1.12 release we already suggested > distributions to request 'strict' explicitly, so it's probably a good > idea to move on and just make it the new default for 1.14. > > Under the 'strict' filter, TTYs are only probed if there is clear > indication that the device may be a modem. Also worth noting that the > shipped udev tags that blacklist explicit devices per vid:pid are > ignored under this mode. > > The old default is renamed to 'legacy', and can still be selected > with > --filter-policy=LEGACY. > > What do you all think? Please reply to the mailing list or add your > comments in the gitlab merge request. Works for me. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Quectel EC25 bug - interaction between generic/3GPP and QMI connection methods
On Thu, 2020-04-16 at 15:20 +0100, Tim Small wrote: > Hello, > > We've got some EC25, and found the following bug... > > On all tested EC25 firmware versions. > > With ModemManager 1.10.0 and libqmi 1.22.0 and also with > ModemManager > 1.12.6 and libqmi 1.24.8. > > Due to the QMI bug recently described on this list, these modems have > previously been occasionally running with the generic / 3GPP plugin, > and > occasionally with the quectel / QMI plugin. > > Things were working OK, up until the time that the modems were > switched > to a different SIM card. > > The modems continuously timed out during the "connecting" phase. > > They appear to have retained the settings from the previous SIM card > (appears to be stored in non volatile memory), and that remembered > connection seems to stop the new connection (different SIM / APN). I'm pretty sure that's how all modems work. The PDP contexts are in the modem NVRAM and have nothing to do with the SIM card. That's per the 3GPP standards and have always been that way. What might be different is that with LTE default bearer autoconnect each modem can decide what context to use for the autoconnect. Maybe the EC25 just uses context #1 and that sets up something in the firmware that makes it fail when trying to activate context 2 with MM. Dan > The following workaround gets it to connect: > > > > AT+CGDCONT? > > << +CGDCONT: > 1,"IPV4V6","EEM2M","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0 > << +CGDCONT: 2,"IP","giffgaff.com","0.0.0.0",0,0,0,0 > << > << OK > > > > AT+CGDCONT=1,"IP","" > > << OK > > > > AT+CGDCONT? > > << +CGDCONT: 1,"IP","","0.0.0.0",0,0,0,0 > << +CGDCONT: 2,"IP","giffgaff.com","0.0.0.0",0,0,0,0 > << > << OK > > i.e. undefine the first PDP, and it will then connect via QMI. > > Not sure if this is a modem firmware bug, or MM? Any thoughts? > > Tim. > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [RFC] Bumping minimum glib2 required version to 2.48
On Fri, 2020-01-10 at 15:05 +0100, Aleksander Morgado wrote: > Hey Dan & all! > > I'm thinking in bumping the minimum glib2 required version from 2.36 > to 2.48 in all libmbim, libqmi and ModemManager, in order to be able > to start using e.g. G_DECLARE_FINAL_TYPE(), > G_DECLARE_DERIVABLE_TYPE(), g_autoptr() and such. > > GLib 2.48.0 was released on Mar 22nd 2016. Works for me, and all the OS versions I care a bunch about (Fedora, RHEL) have 2.48 for a long time. I assume this lets us get rid of the autoptr hacks I put in a while back? Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Fibocom L850-GL / Intel XMM7360 support
On Wed, 2020-01-08 at 10:00 +0100, Bjørn Mork wrote: > James Wah writes: > > > Hi gang, > > > > I've been working on a PCI driver for the Fibocom L850-GL, and > > while > > it's very rough at this point, it sure does transfer data. > > > > If anyone is interested in developing support in MM, or in shaping > > the kernel driver into something people might actually want to use, > > now > > would be a good time to get involved. MM integration is well beyond > > my > > available time & expertise - I've just been doing this reverse > > engineering for fun - but I'd be very happy to contribute what I > > can. > > > > The modem does not speak MBIM over PCI, though it does expose some > > AT > > ports. Most tasks eg. PIN management can be done via AT commands. > > > > In order to initialise the modem, though, or to bring up a raw IP > > interface, it's necessary to speak a custom RPC protocol. This is > > unpleasant, but not unpossible; the driver I have uses a Python > > userspace component to do so. The protocol is ugly but not > > complicated, > > so a C port wouldn't be too involved. > > > > The driver, and associated RPC tooling, are currently available > > here: > > > > https://github.com/xmm7360/xmm7360-pci > > > > A little documentation on the RPC protocol is also available: > > > > https://github.com/xmm7360/xmm7360-pci > > Great stuff! Almost makes me want to buy a device to play with ;-) > > Being responsible for a number of historical userspace API mistakes I > should probably just shut up now But just in case you haven't > been > following this discussion: > > https://www.spinics.net/lists/linux-wireless/msg186483.html > > I have no idea where this has led. But you should probably discuss > the > userspace API with Johannes and Marcel (I assume Dan and Aleksander > is > already on the task) before introducing the new driver. Johannes says the Intel folks will be submitting drivers to staging "any time now" for that family of devices (7360, 7460, 7560). What the actual architecture of those drivers is and how you communicate with them, I don't recall. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Cannot send message: QMI service 'pdc' version '1.15' required, got version '1.0'
On Fri, 2019-12-13 at 18:37 +0100, Aleksander Morgado wrote: > > > I’m testing mm 1.12.2 + libqmi 1.24.2 on sierra EM7565 (openwrt). > > > Please see last line of log. Is this ok? > > > > > > > > > > > > I do not see this in mm 1.12.0 + libqmi 1.24.0 > > > > > > > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Enabling QMI > > > indications via MBIM... > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] enabled QMI > > > indications via MBIM > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [cdc-wdm0] MBIM device is > > > QMI capable > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new > > > client ID... > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'dms' > > > (version 1.0) client with ID '1' > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new > > > client ID... > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'nas' > > > (version 1.25) client with ID '2' > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new > > > client ID... > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'loc' > > > (version 2.0) client with ID '1' > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new > > > client ID... > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'pdc' > > > (version 1.0) client with ID '1' > > > > > > Dec 13 15:51:39 OpenWrt [5904]: QMI-based capability and > > > mode switching support enabled > > > > > > Dec 13 15:51:39 OpenWrt [5904]: couldn't load carrier > > > config: 'Cannot send message: QMI service 'pdc' version '1.15' > > > required, got version '1.0'' > > > > > > > I believe the issue is unrelated to the MM/libqmi version. It would > > be > > very strange that the modem replies differnet things when using > > different libqmi versions really. > > > > The problem, though, is something we should fix. The version checks > > done by libqmi are truly broken, because they rely on the version > > info > > for each message that is defined in our message database, and that > > information is far from good or up to date. If the message is not > > supported by the device, we'll get an error when trying to use it. > > Trying to return an early error before sending the request assuming > > our information of when it was introduced is good is not the way to > > go. > > > > See > https://gitlab.freedesktop.org/mobile-broadband/libqmi/merge_requests/80 > > Comments welcome I see you merged it 6 hours ago, but FWIW it looks good to me :) Dan > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Built-in plugins?
On Sun, 2019-11-17 at 15:16 +0100, Aleksander Morgado wrote: > > > Is there any benefit in keeping per-vendor plugins installed as > > > separate .so files and loaded during runtime? > > > > I think it'd be a shame to lose this architecture. On embedded > > systems saving resources is always desirable and I remove > > all vendor plugins that do not apply to an embedded hardware > > footprint. The most common complaints that get raised to me to > > avoid use MM for embedded systems is footprint. I'd hate to give > > reasons to communities like OpenWRT to make a point out of that. > > > > > Thinking of installed size, I believe we may end up duplicating a > > > lot > > > of code when plugins share common code, as the utils libraries > > > are not > > > installed, they get incorporated in the plugins themselves. This > > > also > > > makes some unexpected runtime errors if a plugin tries to > > > register a > > > type that some other plugin has already registered (just had this > > > one > > > today with the new Foxconn plugin in git master, which shares > > > code > > > with the Dell plugin). > > > > Respectfully this just seems like poor plugin design. Why should it > > be okay to create dependencies between plugins. Shouldn't shared > > logic be in a share location if it really is common code? And if > > it's > > shared but not applicable to all then maybe it should just be > > copied. > > > > You're right, that was indeed poor plugin design. Up until now we > were > "copying" as you said, but that would break the GType system when > multiple plugins tried to create objects of the same type. I've tried > to fix the plugin design my creating a new set of installed modules > that provide the shared utils to the plugins, please see: > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209 > > Due to the copy no longer being done, the overall size of all .so > files installed in /usr/lib/ModemManager went from 7MB to 5.5MB in my > machine, even with the new shared modules installed. Comments > welcome! > > > > I would bet there isn't any as we truly haven't kept a stable > > > plugin > > > API like never ever. > > > > Ya but industrial users, for the worst, often tend to get a certain > > version and stick with it. The API changing in that case doesn't > > matter. > > With 5G on the door step there may be some new vendors that want to > > have a proprietary plugin while they think their new API is god's > > gift > > to humanity, cough cough hint hint. I love the GPL but losing the > > plugin > > framework feels bad as someone who's had to deal with the bidding's > > of mega-corp's and legal team's choices bases on lawyer bro's > > understanding of software. > > > > As long as they don't update the ModemManager version, that would > work. But note that not even stable MM updates (e.g. 1.10.0->1.10.2) > the plugin API is maintained. Of course, if they are the ones > building > MM as well, that's a different story, but then I wouldn't call that > an > external plugin, it really would be a totally different MM in my > opinion. The fact that it's developed as a plugin doesn't make it a > "proper plugin" if you know what I mean. Another option to address Matthew's concern would be compile-time selectable plugins. We would still keep the general plugin architecture (eg the concept of separate/encapsulated code modules for each type of hardware) since I think that's a good thing to do from a software engineering and architecture point of view. But if you wanted to, you could pass --enable-plugins=X,Y,Z or something and end up with a smaller binary. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Built-in plugins?
On Fri, 2019-11-15 at 16:10 +0100, Aleksander Morgado wrote: > Hey, > > Is there any benefit in keeping per-vendor plugins installed as > separate .so files and loaded during runtime? > > Does anyone know of any out-of-tree MM plugin out there? I would bet > there isn't any as we truly haven't kept a stable plugin API like > never ever. > > Thinking of installed size, I believe we may end up duplicating a lot > of code when plugins share common code, as the utils libraries are > not > installed, they get incorporated in the plugins themselves. This also > makes some unexpected runtime errors if a plugin tries to register a > type that some other plugin has already registered (just had this one > today with the new Foxconn plugin in git master, which shares code > with the Dell plugin). > > What if we just simplify the setup and get all incorporated in the > daemon binary itself (for MM 1.14 for example)? It seems OK, but what's the size difference of MM binary with no plugins, and with all plugins? Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0
On Fri, 2019-11-15 at 10:33 +0100, Aleksander Morgado wrote: > Hey, > > > > On Thu, Nov 14, 2019 at 06:57:54PM +0100, Aleksander Morgado > > > wrote: > > > > > Has the interpretation of the ip_type > > > > > MM_BEARER_IP_FAMILY_IPV4V6 > > > > > changed when performing the connect? > > > > > > > > > > > > > No it hasn't really. I really think you need to know whether > > > > the > > > > network supports ipv4v6 for a given APN before attempting to > > > > use > > > > it. > > > > > > For writing end user oriented software where the networks and > > > operators > > > that will be used are unknown when implementing it this becomes a > > > big > > > problem. > > > > I'm not sure I see how. If you pass MM_BEARER_IP_FAMILY_ANY then > > you > > will get some kind of connectivity, most often V4 because that's > > what > > most networks provide. > > > > If you pass V4, V6, or V4V6 then MM will fail if the network cannot > > provide that connectivity. Presumably you are passing these options > > because you require the connectivity each one provides, otherwise > > if > > all you care about is "can I get to the Internet" you could pass > > ANY. > > > > > Wouldn't that mean one has to try a connect with all bearer types > > > in > > > whatever the preferred order is? > > > > Or pass ANY and you'll get some kind of connection to the internet > > at > > least? > > > > Aleksander: we should probably fine-tune the logic something like > > this: > > > > 1) bearer default_ip_family follows what the modem is capable of > > via > > AT+CGDCONT=? or the equivalent; eg if the modem has V4V6 contexts > > then > > we default to IPV4V6. > > The "default IP family" is IPv4 for all modems, there's no +CGDCONT=? > check changing that. > > The +CGDCONT=? check helps build the "supported IP families" list > that > we expose in the Modem interface when the device uses AT protocol. > For > MBIM and QMI modems, the list of supported IP families includes all > IPv4, IPv6 and IPv4v6. > > > 2) If the user passes a specific IP family for the bearer, fail if > > that > > family is not successfully connected (as we do now?) > > More or less. If user asks for IPv4 or IPv6 and that fails, we fail > always regardless of the modem type. > > In QMI modems, where we control the IPv4 and IPv6 setups separately > via different QMI clients, if the user asks for IPv4v6 and any of > them > succeeds, we succeed. So if user asks for IPv4v6 and we get IPv4 > only, > we would not trigger an error. Maybe we should? It's definitely > easier > for us to just succeed here, because otherwise it would mean that if > IPv6 setup fails we would need to then disconnect the IPv4 setup > manually before reporting the connection error. > > For other modems (AT or MBIM) there is one single command requesting > IPv4v6 and that is left to the modem to decide whether the connection > command succeeds or not. This is the key point I believe. If we > default ANY to IPv4v6 and we ask IPv4v6 by default when no explicit > ip-type provided, and the modem decides to fail the connection if we > can only setup IPv4, wouldn't that be a very bad thing? > > > 3) If the user passes ANY: > > 3a) use the default_ip_family (no change) > > That is what we're doing right now, but because default IP family is > IPv4, we fallback to IPv4. Well, there's no fallback, passing ANY always means V4 because default_ip_family is hardcoded to V4 AFAICT. > > 3b) the modem accepts whatever connect result happens, eg if v4 > > or > > v6-only that's fine, don't fail. > > 3c) if the connection result failed because the network rejected > > a > > V4V6 request for example, or the default_ip_family is V4 but the > > APN > > only accepts V6, then should we retry with V4? > > Are you suggesting we improve the ANY handling in order to attempt > different IP type connections automatically if they fail? E.g. if the > user asks for ANY, try first with IPv4v6 and if anything succeeds > we're good. If it fails, try with IPv4-only, and if it fails, try > with > IPv6. That would make the ANY name much more meaningful actually. Yes, basically :) But I'm also suggesting that we change default_ip_family to something other than V4 when the modem supports it. eg maybe we set it to V4V6 and if one of the V4 or V6 methods fails we just proceed with single-stack connectivity? But the user explicitly requests V4V6 type we fail if we don't get both v4 and v6. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0
On Thu, 2019-11-14 at 21:59 +0100, Andreas Fett wrote: > Hi Aleksander, > > On Thu, Nov 14, 2019 at 06:57:54PM +0100, Aleksander Morgado wrote: > > > Has the interpretation of the ip_type MM_BEARER_IP_FAMILY_IPV4V6 > > > changed when performing the connect? > > > > > > > No it hasn't really. I really think you need to know whether the > > network supports ipv4v6 for a given APN before attempting to use > > it. > > For writing end user oriented software where the networks and > operators > that will be used are unknown when implementing it this becomes a big > problem. I'm not sure I see how. If you pass MM_BEARER_IP_FAMILY_ANY then you will get some kind of connectivity, most often V4 because that's what most networks provide. If you pass V4, V6, or V4V6 then MM will fail if the network cannot provide that connectivity. Presumably you are passing these options because you require the connectivity each one provides, otherwise if all you care about is "can I get to the Internet" you could pass ANY. > Wouldn't that mean one has to try a connect with all bearer types in > whatever the preferred order is? Or pass ANY and you'll get some kind of connection to the internet at least? Aleksander: we should probably fine-tune the logic something like this: 1) bearer default_ip_family follows what the modem is capable of via AT+CGDCONT=? or the equivalent; eg if the modem has V4V6 contexts then we default to IPV4V6. 2) If the user passes a specific IP family for the bearer, fail if that family is not successfully connected (as we do now?) 3) If the user passes ANY: 3a) use the default_ip_family (no change) 3b) the modem accepts whatever connect result happens, eg if v4 or v6-only that's fine, don't fail. 3c) if the connection result failed because the network rejected a V4V6 request for example, or the default_ip_family is V4 but the APN only accepts V6, then should we retry with V4? Dan > Surely this information cannot be expected to be known > by the user and is not even listed in registries like > https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info > > Or are there any "cheaper" ways to probe for this than attempting a > connect? > > Andreas > > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: mmcli 3gpp network scan
On Thu, 2019-10-10 at 11:26 +, Amol Lad wrote: > mbimcli actually shows more detailed output but it also has got RSSI > and Error Rate field incorrect... I don't think I've ever seen an accurate signal strength for scanned networks :) Either with data cards or phones... Dan > [/dev/cdc-wdm0] Visible providers (6): > Provider [0]: > Provider ID: '405861' > Provider name: 'Jio 4G' > State: 'home, preferred, visible, > registered' > Cellular class: 'gsm' >RSSI: '99' > Error rate: '99' > Provider [1]: > Provider ID: '40445' > Provider name: 'IND airtel' > State: 'forbidden, visible' > Cellular class: 'gsm' >RSSI: '99' > Error rate: '99' > Provider [2]: > Provider ID: '40486' > Provider name: 'Vodafone IN' > State: 'forbidden, visible' > Cellular class: 'gsm' >RSSI: '99' > Error rate: '99' > Provider [3]: > Provider ID: '40510' > Provider name: '405 10' > State: 'forbidden, visible' > Cellular class: 'gsm' >RSSI: '99' > Error rate: '99' > Provider [4]: > Provider ID: '40471' > Provider name: 'CellOne' > State: 'forbidden, visible' > Cellular class: 'gsm' >RSSI: '99' > Error rate: '99' > Provider [5]: > Provider ID: '404999' > Provider name: '404 999' > State: 'forbidden, visible' > Cellular class: 'gsm' >RSSI: '99' > Error rate: '99' > > > The information in this email communication (inclusive of > attachments) is confidential to 4RF Limited and the intended > recipient(s). If you are not the intended recipient(s), please note > that any use, disclosure, distribution or copying of this information > or any part thereof is strictly prohibited and that the author > accepts no liability for the consequences of any action taken on the > basis of the information provided. If you have received this email in > error, please notify the sender immediately by return email and then > delete all instances of this email from your system. 4RF Limited will > not accept responsibility for any consequences associated with the > use of this email (including, but not limited to, damages sustained > as a result of any viruses and/or any action or lack of action taken > in reliance on it).-Original Message- > From: Aleksander Morgado > Sent: Thursday, 10 October 2019 2:05 PM > To: Amol Lad > Cc: ModemManager (development) < > modemmanager-devel@lists.freedesktop.org> > Subject: Re: mmcli 3gpp network scan > > Hey, > > > I’m using almost the latest modemmanager from master (commit hash: > > 0a85254d1765db6e55770d36e24b1e6349e789f4). When starting network > > scan using mmcli, the availability field is always “unknown” > > whereas for qmicli the “Status” is reported with more details. > > Please advise if this is desired behaviour in mmcli output? > > > > I recall this being a limitation of the "MBIM Query Visible > Providers" > implementation in some modules, which is what ModemManager does when > the modem is managed in MBIM mode. You can see qmicli providing > better data because it's doing "QMI NAS Network Scan" over MBIM > instead. > > -- > Aleksander > https://aleksander.es > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: hp-lt4132 'unavailable' in NetworkManager on Debian 10
On Wed, 2019-09-11 at 17:50 +0200, Christian Focke wrote: > Hi Dan, > > cfocke@hp-eb-x360-1030-g3:~$ nmcli radio > WIFI-HW WIFI WWAN-HW WWAN > enabled enabled enabled disabled > > cfocke@hp-eb-x360-1030-g3:~$ nmcli radio wwan on > cfocke@hp-eb-x360-1030-g3:~$ nmcli radio > WIFI-HW WIFI WWAN-HW WWAN > enabled enabled enabled enabled > cfocke@hp-eb-x360-1030-g3:~$ > > Works now; I feel embarrassed ... > > Since when must I explicitly enable radio? Never had to in the past > ... To be fair, there's likely a bug here that NM shouldn't ever get as far as starting the WWAN connection if the device is unavailable. I'm pretty sure I saw that in the logs somewhere. The non-HW state is saved in the NM state file so maybe it got toggled at some point via a GUI (like gnome-settings), or a bug in NM, or something like that. Glad we solved it though! Dan > Thanks, Christian > > -Original Message- > From: Dan Williams > To: Christian Focke , Aleksander Morgado < > aleksan...@aleksander.es> > Cc: Lubomir Rintel , Thomas Haller < > thal...@redhat.com> > , modemmanager-devel@lists.freedesktop.org < > modemmanager-devel@lists.freedesktop.org> > Subject: Re: hp-lt4132 'unavailable' in NetworkManager on Debian 10 > Date: Wed, 11 Sep 2019 10:08:10 -0500 > > On Wed, 2019-09-11 at 16:13 +0200, Christian Focke wrote: > > Hi Dan, > > Thanks; here's what I did: > > How about: > nmcli radio > ? > Dan > > > 1. reboot > > 2. 1st shellcfocke@hp-eb-x360-1030-g3:~$ sudo journalctl -fl |tee > > simple-connect_then_simple-disconnect_2.log > > 3. 2nd shellcfocke@hp-eb-x360-1030-g3:~$ sudo systemctl stop > > ModemManagercfocke@hp-eb-x360-1030-g3:~$ sudo systemctl restart > > NetworkManagercfocke@hp-eb-x360-1030-g3:~$ sudo nmcli gen log > > level > > tracecfocke@hp-eb-x360-1030-g3:~$ sudo systemctl start > > ModemManagercfocke@hp-eb-x360-1030-g3:~$ mmcli -m 0 --simple- > > connect="apn=a1.net,user=p...@a1plus.at,password=ppp"successfully > > connected the modemcfocke@hp-eb-x360-1030-g3:~$ nmcli > > devDEVICETYPE STATE CONNECTION > > wlp108s0 wifi disconnected -- cdc- > > wdm0 gsm unavailable > > -- loloopback unmanaged -- > > cfocke@hp-eb-x360-1030-g3:~$ mmcli -m 0 --simple- > > disconnectsuccessfully disconnected all bearers in the > > modemcfocke@hp-eb-x360-1030-g3:~$ > > 'simple-connect_then_simple-disconnect_2.log' is attached. > > -- Should I unloop modemmanager-devel@lists.freedesktop.org? > > Thanks, Christian > > -Original Message-From: Dan Williams To: > > Focke Christian , > > AleksanderMorgado Cc: Lubomir Rintel < > > lkund...@v3.sk>, Thomas Haller , > > modemmanager-devel@lists.freedesktop.org < > > modemmanager-devel@lists.freedesktop.org>Subject: Re: hp-lt4132 > > 'unavailable' in NetworkManager on Debian 10Date: Wed, 11 Sep 2019 > > 08:07:46 -0500 > > On Wed, 2019-09-11 at 10:10 +, Focke Christian wrote: > > > Hi Aleksander,Thanks; I have no idea how to do that because NM is > > > brokenwithregardto the hp-lt4132.-- I already shared the NM logs; > > > should I possibly also share theNMconfiguration? Which files? > > > > Can you start up fresh, and then:systemctl stop > > ModemManagersystemctl > > restart NetworkManagernmcli genlog level tracesystemctl start > > ModemManagerand then grab logs again? I'd like to see things from > > the > > start ofwhenNM finds the modem.Also, when you connect the modem > > through NM, does 'nmcli dev'stillshowthe cdc-wdm device as > > "unavailable"?Dan > > > Kind regards, Christian-Original Message-From: Aleksander > > > Morgado > > aleksander%20morgado%20%3caleksan...@aleksander.es%3e>>To: > > > FockeChristian > > focke%20christian%20%3cchristian.fo...@mail.fernfh.ac.at%3e>>Cc:L > > > ub > > > omir Rintel > > lubomir%20rintel%20%3clkund...@v3.sk%3e>>, Dan Williams < > > > d...@redhat.com<mailto:dan%20williams%20%3cd...@redhat.com%3e>>,T > > > ho > > > mas Haller > > thomas%20haller%20%3cthal...@redhat.com%3e>>, > > > modemmanager-devel@lists.freedesktop.org < > > > modemmanager-devel@lists.freedesktop.org > > %22modemmanager-de...@lists.freedesktop.org > > > %22%20%3cmodemmanager-de...@lists.freedesktop.org%3e>>Subject: > > > Re:hp-lt4132 'unavailable' in NetworkManager on Debian 10Date: > > > Wed, > > > 11Sep 201
Re: hp-lt4132 'unavailable' in NetworkManager on Debian 10
On Wed, 2019-09-11 at 16:13 +0200, Christian Focke wrote: > Hi Dan, > > Thanks; here's what I did: How about: nmcli radio ? Dan > 1. reboot > > 2. 1st shell > cfocke@hp-eb-x360-1030-g3:~$ sudo journalctl -fl |tee simple- > connect_then_simple-disconnect_2.log > > 3. 2nd shell > cfocke@hp-eb-x360-1030-g3:~$ sudo systemctl stop ModemManager > cfocke@hp-eb-x360-1030-g3:~$ sudo systemctl restart NetworkManager > cfocke@hp-eb-x360-1030-g3:~$ sudo nmcli gen log level trace > cfocke@hp-eb-x360-1030-g3:~$ sudo systemctl start ModemManager > cfocke@hp-eb-x360-1030-g3:~$ mmcli -m 0 --simple-connect="apn=a1.net, > user=p...@a1plus.at,password=ppp" > successfully connected the modem > cfocke@hp-eb-x360-1030-g3:~$ nmcli dev > DEVICETYPE STATE CONNECTION > wlp108s0 wifi disconnected -- > cdc-wdm0 gsm unavailable -- > loloopback unmanaged -- > cfocke@hp-eb-x360-1030-g3:~$ mmcli -m 0 --simple-disconnect > successfully disconnected all bearers in the modem > cfocke@hp-eb-x360-1030-g3:~$ > > 'simple-connect_then_simple-disconnect_2.log' is attached. > > -- Should I unloop modemmanager-devel@lists.freedesktop.org? > > Thanks, Christian > > -Original Message- > From: Dan Williams > To: Focke Christian , Aleksander > Morgado > Cc: Lubomir Rintel , Thomas Haller < > thal...@redhat.com> > , modemmanager-devel@lists.freedesktop.org < > modemmanager-devel@lists.freedesktop.org> > Subject: Re: hp-lt4132 'unavailable' in NetworkManager on Debian 10 > Date: Wed, 11 Sep 2019 08:07:46 -0500 > > On Wed, 2019-09-11 at 10:10 +, Focke Christian wrote: > > Hi Aleksander, > > Thanks; I have no idea how to do that because NM is broken > > withregard > > to the hp-lt4132. > > -- I already shared the NM logs; should I possibly also share the > > NMconfiguration? Which files? > > Can you start up fresh, and then: > systemctl stop ModemManagersystemctl restart NetworkManagernmcli gen > log level tracesystemctl start ModemManager > and then grab logs again? I'd like to see things from the start of > whenNM finds the modem. > Also, when you connect the modem through NM, does 'nmcli dev' > stillshow > the cdc-wdm device as "unavailable"? > Dan > > Kind regards, Christian > > -Original Message-From: Aleksander Morgado < > > aleksan...@aleksander.es > aleksander%20morgado%20%3caleksan...@aleksander.es%3e>>To: Focke > > Christian > focke%20christian%20%3cchristian.fo...@mail.fernfh.ac.at%3e>>Cc: > > Lubomir Rintel > lubomir%20rintel%20%3clkund...@v3.sk%3e>>, Dan Williams < > > d...@redhat.com<mailto:dan%20williams%20%3cd...@redhat.com%3e>>,Tho > > ma > > s Haller > thomas%20haller%20%3cthal...@redhat.com%3e>>, > > modemmanager-devel@lists.freedesktop.org < > > modemmanager-devel@lists.freedesktop.org > %22modemmanager-de...@lists.freedesktop.org > > %22%20%3cmodemmanager-de...@lists.freedesktop.org%3e>>Subject: Re: > > hp-lt4132 'unavailable' in NetworkManager on Debian 10Date: Wed, 11 > > Sep 2019 11:38:16 +0200 > > > > Hey! > > > > On Wed, Sep 11, 2019 at 11:22 AM Focke Christian > > < > > <mailto:christian.fo...@mail.fernfh.ac.at> > > christian.fo...@mail.fernfh.ac.at > > > > > wrote: > > > > Yes I know, but with NM-GNOME and nmcli it doesn't work at > > all;that's > > where I started from. > > > > Actually it was you who instructed me to use mmcli to analyse > > theissue on MM side. > > > > > > Oh, ok, sorry for the confusion then :) > > > > The MM analysis is done already, e.g. we can see how the whole > > connection sequence works ok with mmcli --simple-connect. Now, the > > missing part is the integration with NM. That is why > > Lubomirrequested > > for *NetworkManager* logs while reproducing the issue. Could you > > follow his steps to get the logs and try to repro the problem using > > nmcli? > > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: hp-lt4132 'unavailable' in NetworkManager on Debian 10
On Wed, 2019-09-11 at 10:10 +, Focke Christian wrote: > Hi Aleksander, > > Thanks; I have no idea how to do that because NM is broken with > regard to the hp-lt4132. > > -- I already shared the NM logs; should I possibly also share the NM > configuration? Which files? Can you start up fresh, and then: systemctl stop ModemManager systemctl restart NetworkManager nmcli gen log level trace systemctl start ModemManager and then grab logs again? I'd like to see things from the start of when NM finds the modem. Also, when you connect the modem through NM, does 'nmcli dev' still show the cdc-wdm device as "unavailable"? Dan > Kind regards, Christian > > -Original Message- > From: Aleksander Morgado aleksander%20morgado%20%3caleksan...@aleksander.es%3e>> > To: Focke Christian focke%20christian%20%3cchristian.fo...@mail.fernfh.ac.at%3e>> > Cc: Lubomir Rintel lubomir%20rintel%20%3clkund...@v3.sk%3e>>, Dan Williams < > d...@redhat.com<mailto:dan%20williams%20%3cd...@redhat.com%3e>>, > Thomas Haller thomas%20haller%20%3cthal...@redhat.com%3e>>, > modemmanager-devel@lists.freedesktop.org < > modemmanager-devel@lists.freedesktop.org %22modemmanager-de...@lists.freedesktop.org > %22%20%3cmodemmanager-de...@lists.freedesktop.org%3e>> > Subject: Re: hp-lt4132 'unavailable' in NetworkManager on Debian 10 > Date: Wed, 11 Sep 2019 11:38:16 +0200 > > > Hey! > > > On Wed, Sep 11, 2019 at 11:22 AM Focke Christian > > < > > <mailto:christian.fo...@mail.fernfh.ac.at> > > christian.fo...@mail.fernfh.ac.at > > > wrote: > > Yes I know, but with NM-GNOME and nmcli it doesn't work at all; > that's where I started from. > > > Actually it was you who instructed me to use mmcli to analyse the > issue on MM side. > > > > Oh, ok, sorry for the confusion then :) > > > The MM analysis is done already, e.g. we can see how the whole > > connection sequence works ok with mmcli --simple-connect. Now, the > > missing part is the integration with NM. That is why Lubomir > requested > > for *NetworkManager* logs while reproducing the issue. Could you > > follow his steps to get the logs and try to repro the problem using > > nmcli? > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [PATCH] mm-modem-helpers-qmi: avoid SIGSEGV with mmcli --set-current-bands
On Mon, 2019-08-19 at 16:31 +0200, Reinhard Speyerer wrote:
> For devices which do not provide feature_extended_lte_band_preference
> mm_modem_bands_to_qmi_band_preference() gets called from
> mm_shared_qmi_set_current_bands() with extended_qmi_lte_bands
> set to NULL which may cause a SIGSEGV in the memset() call in
> mm_modem_bands_to_qmi_band_preference().
>
> Avoid this by checking whether extended_qmi_lte_bands is non-NULL
> before calling memset().
Thanks, pushed as MR:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/140
along with the other 2 mm-modem-helpers-qmi patches you posted this
week.
Dan
> Reported-by: Nick
> ---
> diff --git a/src/mm-modem-helpers-qmi.c b/src/mm-modem-helpers-qmi.c
> index 86e1803b..a0bc4f4a 100644
> --- a/src/mm-modem-helpers-qmi.c
> +++ b/src/mm-modem-helpers-qmi.c
> @@ -567,7 +567,8 @@ mm_modem_bands_to_qmi_band_preference (GArray
> *mm_bands,
>
> *qmi_bands = 0;
> *qmi_lte_bands = 0;
> -memset (extended_qmi_lte_bands, 0, extended_qmi_lte_bands_size *
> sizeof (guint64));
> +if (extended_qmi_lte_bands)
> +memset (extended_qmi_lte_bands, 0,
> extended_qmi_lte_bands_size * sizeof (guint64));
>
> for (i = 0; i < mm_bands->len; i++) {
> MMModemBand band;
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: dhcpcd: raw-ip support
On Mon, 2019-08-19 at 16:20 +0200, Yegor Yefremov wrote: > On Mon, Aug 19, 2019 at 2:57 PM Bjørn Mork wrote: > > Yegor Yefremov writes: > > > On Mon, Aug 19, 2019 at 10:49 AM Bjørn Mork > > > wrote: > > > > Yegor Yefremov writes: > > > > > > > > > I have a project where I'm using dhcpcd client. It is working > > > > > without > > > > > any problems with older modems like Quectel UC20 etc. But now > > > > > we want > > > > > to switch to SIM7600G-H and it is working in raw-ip mode. So > > > > > far only > > > > > udhcpc can handle such MAC address-less interfaces. > > > > > > > > > > Do you know what is so special about udhcpc compared to other > > > > > DHCP > > > > > clients? > > > > > > > > It's mostly L2 agnostic, meaning that it will work on non- > > > > ethernet > > > > interfaces. > > > > > > > > "Fixing" this for other clients isn't really that hard, if > > > > required. I > > > > did this proof-of-concept for ISC dhclient for example: > > > > > > > > > > > > https://mail.gnome.org/archives/networkmanager-list/2015-December/msg00044.html > > > > > > Thanks for the patch. But looks like it hasn't been upstreamed > > > yet :-( > > > > Upstreaming anything to ISC is not possible in my experience. See > > https://lists.isc.org/pipermail/dhcp-users/2011-August/013926.html > > > > Or at least not worth the extra effort required. > > > > And I don't think raw-ip support is all that useful, to be > > honest. The > > DHCP server in the modem is a hack anyway. You should use the > > modem > > management channel to get IP config from the modem. I.e. QMI. > > How one supposed to set the IP configuration via QMI? I can connect > using: > > qmicli --device=/dev/cdc-wdm0 --device-open-proxy > --wds-start-network="ip-type=4,apn=www.bla.com" > --client-no-release-cid > > and get IP config via: > > # qmicli -d /dev/cdc-wdm0 --device-open-proxy > --wds-get-current-settings --client-cid=17 > [/dev/cdc-wdm0] Current settings retrieved: >IP Family: IPv4 > IPv4 address: 10.33.151.131 > IPv4 subnet mask: 255.255.255.248 > IPv4 gateway address: 10.33.151.132 > IPv4 primary DNS: 62.109.121.17 > IPv4 secondary DNS: 62.109.121.18 > MTU: 1430 > Domains: none > > How can these settings be automatically applied to wwan0? Am I > missing > related MM options here? The thing that tells ModemManager to start the connection is usually what is responsible for applying the IP configuration. That would either be something like NetworkManager or custom scripting. Dan > Yegor > > > > But DHCPv6 support on PPP links is something else. It's an > > essential > > feature for a DHCPv6 client. As you may or may not know, IPV6CP is > > very > > different from IPCP when it comes to address negotiation. It will > > only > > negotiate an interface-id and leave the remaining address config to > > the > > normal autoconf protocols. I.e. you need to run SLAAC and/or > > DHCPv6 on > > the link if you want a global address. > > > > Somewhat off-topic here. Unless you have a modem with support for > > IPv6 > > over PPP, which I recently learned actuall exists: > > https://forum.openwrt.org/t/ipv6-with-ppp-with-3g-modem/39071 > > > > I'll stop babbling now > > > > > > Bjørn > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Modemmanager significant startup delay
On Wed, 2019-08-21 at 12:23 +, Amol Lad wrote: > Please help with this. What could be the cause of significant MM > startup delay? When started, or when a new modem is plugged attached, ModemManager runs through a hardware detection sequence to figure out whether the thing you attached is actually a modem and what ports it has and what protocols those ports speak. Is this the full probing log? This modem should be driven with QMI but the log only shows probing for the serial ttys. Dan > From: ModemManager-devel < > modemmanager-devel-boun...@lists.freedesktop.org> On Behalf Of Amol > Lad > Sent: Monday, 19 August 2019 4:05 PM > To: modemmanager-devel@lists.freedesktop.org > Subject: Modemmanager significant startup delay > > Hi, > > I'm using Solidrun's clearfog-base plarform with Sierra Wireless > EM7430 LTE chipset. I'm running OpenWRT 18.06 with ModemManager feed > from > https://gitlab.freedesktop.org/mobile-broadband/mobile-broadband-openwrt > > It is taking around 20 seconds for modemanager to bring up the LTE IP > interface (i.e. after around 20 seconds 'wwan1' interface is up and I > can ping external world). With uqmi the interface comes up instantly. > Please refer to below logs (captured in -debug mode). It seems most > of this delay is because of "serial command timeout". As you can see > from the last time "[plugin manager] task 0: finished in '17.149826' > seconds > " > > Please advise what is going wrong. > > ... > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.535657] (ttyUSB2): <-- '' > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.535956] (ttyUSB2): <-- 'OK' > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.536110] (tty/ttyUSB2) port is AT-capable > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.536188] [plugin manager] task 0,ttyUSB2: found best > plugin for port (Sierra) > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.536269] [plugin manager] task 0,ttyUSB2: finished in > '1.604063' seconds > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.536348] [plugin manager] task 0,ttyUSB2: best plugin > matches device reported one: Sierra > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.536433] [plugin Manager] task 0: still 2 running probes > (2 active): ttyUSB1, ttyUSB0 > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.536565] (ttyUSB2) device open count is 0 (close) > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.536702] (ttyUSB2) closing > port... > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.537143] (ttyUSB2) serial port closed > Mon Aug 19 10:11:05 2019 daemon.debug [2086]: > [1566209465.537304] (ttyUSB2) forced to close port > Mon Aug 19 10:11:06 2019 daemon.debug [2086]: > [1566209466.220126] [plugin manager] task 0: min probing time elapsed > Mon Aug 19 10:11:06 2019 daemon.debug [2086]: > [1566209466.220187] [plugin Manager] task 0: still 2 running probes > (2 active): ttyUSB1, ttyUSB0 > Mon Aug 19 10:11:08 2019 daemon.debug [2086]: > [1566209468.868113] Parsing AT got: 'Serial command timed out' > Mon Aug 19 10:11:08 2019 daemon.debug [2086]: > [1566209468.868197] Parsing AT got: 'Serial command timed out' > Mon Aug 19 10:11:08 2019 daemon.debug [2086]: > [1566209468.868282] (ttyUSB1): --> 'AT' > Mon Aug 19 10:11:08 2019 daemon.debug [2086]: > [1566209468.868351] (ttyUSB0): --> 'AT' > Mon Aug 19 10:11:11 2019 daemon.debug [2086]: > [1566209471.869749] Parsing AT got: 'Serial command timed out' > Mon Aug 19 10:11:11 2019 daemon.debug [2086]: > [1566209471.869831] Parsing AT got: 'Serial command timed out' > Mon Aug 19 10:11:11 2019 daemon.debug [2086]: > [1566209471.869917] (ttyUSB1): --> 'AT' > Mon Aug 19 10:11:11 2019 daemon.debug [2086]: > [1566209471.869984] (ttyUSB0): --> 'AT' > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.869689] Parsing AT got: 'Serial command timed out' > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.869745] (tty/ttyUSB1) port is not AT-capable > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.869806] Parsing AT got: 'Serial command timed out' > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.869834] (tty/ttyUSB0) port is not AT-capable > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.869884] (tty/ttyUSB1) probing QCDM... > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.869916] (ttyUSB1) device open count is 0 (close) > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.869943] (ttyUSB1) closing serial port... > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.870349] (ttyUSB1) serial port closed > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.870415] (ttyUSB1) forced to close port > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.870517] (ttyUSB1) opening serial port... > Mon Aug 19 10:11:14 2019 daemon.debug [2086]: > [1566209474.870779] (ttyUSB1) device open
Re: dhcpcd: raw-ip support
On Mon, 2019-08-19 at 14:57 +0200, Bjørn Mork wrote: > Yegor Yefremov writes: > > On Mon, Aug 19, 2019 at 10:49 AM Bjørn Mork wrote: > > > Yegor Yefremov writes: > > > > > > > I have a project where I'm using dhcpcd client. It is working > > > > without > > > > any problems with older modems like Quectel UC20 etc. But now > > > > we want > > > > to switch to SIM7600G-H and it is working in raw-ip mode. So > > > > far only > > > > udhcpc can handle such MAC address-less interfaces. > > > > > > > > Do you know what is so special about udhcpc compared to other > > > > DHCP > > > > clients? > > > > > > It's mostly L2 agnostic, meaning that it will work on non- > > > ethernet > > > interfaces. > > > > > > "Fixing" this for other clients isn't really that hard, if > > > required. I > > > did this proof-of-concept for ISC dhclient for example: > > > > > > > > > https://mail.gnome.org/archives/networkmanager-list/2015-December/msg00044.html > > > > Thanks for the patch. But looks like it hasn't been upstreamed yet > > :-( > > Upstreaming anything to ISC is not possible in my experience. See > https://lists.isc.org/pipermail/dhcp-users/2011-August/013926.html > > Or at least not worth the extra effort required. > > And I don't think raw-ip support is all that useful, to be > honest. The > DHCP server in the modem is a hack anyway. You should use the modem > management channel to get IP config from the modem. I.e. QMI. > > But DHCPv6 support on PPP links is something else. It's an essential > feature for a DHCPv6 client. As you may or may not know, IPV6CP is > very > different from IPCP when it comes to address negotiation. It will > only > negotiate an interface-id and leave the remaining address config to > the > normal autoconf protocols. I.e. you need to run SLAAC and/or DHCPv6 > on > the link if you want a global address. > > Somewhat off-topic here. Unless you have a modem with support for > IPv6 > over PPP, which I recently learned actuall exists: > https://forum.openwrt.org/t/ipv6-with-ppp-with-3g-modem/39071 Nokia 21M-02 (Icera HSPA chipset) is what I used to develop + verify the PPPv6 support in ModemManager and NetworkManager a number of years ago. They do exist but in my experience are pretty rare as IPv6 only because common with LTE networks and almost nobody should be using PPP with LTE. And yes there the procedure is to acquire the Interface ID (IID) from IPV6CP, use that to generate the IPv6 Link-Local address and assign it to the PPP interface, then run SLAAC to get your prefix and (if SLAAC tells you to) DHCPv6 for DNS servers. The 21M-02 (or T-Mobile US) didn't implement DNSSD or RDNSS options for RAs so for me static DNS or DHCPv6 was necessary. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [RFC] TTY port locked problems when using PPP
On Thu, 2019-06-27 at 11:12 +0200, Thomas Haller wrote: > On Thu, 2019-06-27 at 10:40 +0200, Piotr Figiel wrote: > > Hi, > > > > czw., 27 cze 2019 o 10:20 Aleksander Morgado > > napisał(a): > > > The main issue with this approach is that ModemManager would do a > > > lot > > > of tasks that were exclusively done by NetworkManager before, > > > like > > > IP > > > addressing setup or IP routing setup. I'm sure we can instruct NM > > > to > > > play nicely with those being done by MM, but not sure how easy > > > that > > > would be. > > > > Alternatively pppd could be instructed to not actually configure IP > > or > > routes, but with the plug-in pass the IPCP negotiated data to NM > > via > > MM. Then the NM could either use those data if the interface is > > configured for "auto" configuration or enforce connection IP > > settings. > > Not sure though what actually is less complicated here. > > Hi, > > I missed your email before sending mine. > > I agree with this suggestion. Yes, this approach has my vote. It is consistent with how other IP handling in MM works where it asks the modem for the details and then makes them available via D-Bus for NM or other connection managers to use. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: "Connected" state after losing signal
On Mon, 2019-06-10 at 07:03 +1000, Nick wrote: > Hey, > > A couple of other testers and myself are seeing a minor issue with > ModemManager (on OpenWrt). The simplest way to describe it is if the > modem loses signal or connectivity, the wwan interface still shows as > connected. I have seen this myself, and wrote a hot plug script[1] > to work around the issue, and I think I have seen it mentioned in the > mailing list before. There is also one report of it in the OpenWrt > forum thread[2] for modem manager. > > It’s fairly easy to reproduce in most cases, just remove the > antennas, or if needed put attenuators on and observe. If the modem > did not change base stations it usually can reconnect, but not > always. > > Is there any more information on this out there about why this > happens? Any ideas for what we can do about it? If you can get debug logs from ModemManager we may be able to identify a signal from the modem that connectivity has been lost. However, it's not uncommon for devices to continue saying they are "connected" when they actually cannot pass traffic to the base station, like when you're going through a tunnel and they'll reconnect on the other side. But if the modem does report some state that MM can use to identify that it really is disconnected then we can fix that in MM. Dan > [1] > https://gitlab.freedesktop.org/mips171/modem-manager-keepalive/blob/master/13-keepalive_modemmanager > [2] Forum > https://forum.openwrt.org/t/new-luci-protocol-luci-proto-modemmanager-testing/23696/38 > > All the best, > Nicholas > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: u-blox SARA R410M CAT M1 modem
On Tue, 2019-06-04 at 14:11 -0700, Tim Harvey wrote: > On Fri, Oct 26, 2018 at 3:17 PM Tim Harvey > wrote: > > Greetings, > > > > I'm working with a u-blox SARA R410M CAT M1 modem > > (https://www.u-blox.com/en/product/sara-r4n4-series) using Linux > > 4.15 > > and modem-manager-1.9.0 / libqmi-utils-1.21.4 from Aleksander's > > next > > PPA. My SIM is a Verizon 4G LTE Cat M1 SIM Card from Nibelink > > ( > > https://nimbelink.com/Documentation/Sim_Cards/NL-SIM-VER-M1/1001410_NL-SIM-VER-M1_Datasheet.pdf > > ) > > and I've activated it with Nibelink. > > > > While modemmanager is able to detect, enable, and successfully scan > > it > > won't connect. > > > > root@bionic-armhf:~# uname -r > > 4.15.0-36-generic > > root@bionic-armhf:~# cat /etc/lsb-release > > DISTRIB_ID=Ubuntu > > DISTRIB_RELEASE=18.04 > > DISTRIB_CODENAME=bionic > > DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS" > > root@bionic-armhf:~# dpkg -s modemmanager | grep Version > > Version: 1.9.0.next-20181010-1-0aleksander1 > > root@bionic-armhf:~# dpkg -s libqmi-utils | grep Version > > Version: 1.21.4.next-20181010-1-0aleksander1 > > > > root@bionic-armhf:~# mmcli --list-modems > > > > Found 1 modems: > > /org/freedesktop/ModemManager1/Modem/0 [u-blox] SARA-R410M-52B > > > > root@bionic-armhf:~# mmcli -m 0 > > > > /org/freedesktop/ModemManager1/Modem/0 (device id > > '9469a10655ec4f4d00c5ebad896376291d2a563b') > > - > > Hardware | manufacturer: 'u-blox' > >| model: 'SARA-R410M-52B' > >| revision: 'L0.0.00.00.06.05 1 [Aug 01 2018 > > 14:05:07]' > >| H/W revision: '1' > >| supported: 'lte' > >|current: 'lte' > >| equipment id: '357812090839082' > > - > > System | device: > > '/sys/devices/soc0/soc/210.aips- > > bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.2/1-1.2.3' > >|drivers: 'qmi_wwan, option1' > >| plugin: 'Generic' > >| primary port: 'cdc-wdm0' > >| ports: 'ttyUSB1 (qcdm), ttyUSB2 (at), cdc- > > wdm0 > > (qmi), wwan0 (net)' > > - > > Numbers | own : 'unknown' > > - > > Status | lock: 'sim-pin2' > >| unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk > > (10), > > sim-puk2 (10)' > >| state: 'disabled' > >|power state: 'on' > >|access tech: 'unknown' > >| signal quality: '0' (cached) > > - > > Modes| supported: 'allowed: 4g; preferred: none' > >|current: 'allowed: 4g; preferred: none' > > - > > Bands| supported: 'eutran-1, eutran-2, eutran-3, eutran- > > 4, > > eutran-5, eutran-8, eutran-12, eutran-13, eutran-17, eutran-18, > > eutran-19, eutran-20, eutran-39' > >|current: 'eutran-1, eutran-2, eutran-3, eutran- > > 4, > > eutran-5, eutran-8, eutran-12, eutran-13, eutran-17, eutran-18, > > eutran-19, eutran-20, eutran-39' > > - > > IP | supported: 'ipv4, ipv6, ipv4v6' > > - > > 3GPP | imei: '357812090839082' > >| enabled locks: 'none' > >|operator id: 'unknown' > >| operator name: 'unknown' > >| subscription: 'unknown' > >| registration: 'unknown' > >|EPS UE mode: 'csps-2' > >|PCO: 'n/a' > > - > > SIM | path: '/org/freedesktop/ModemManager1/SIM/0' > > > > - > > Bearers | paths: 'none' > > > > root@bionic-armhf:~# mmcli -m 0 --enable > > successfully enabled the modem > > root@bionic-armhf:~# mmcli --modem 0 --3gpp-scan --timeout=300 > > > > Found 3 networks: > > 311480 - 311 480 (lte, current) > > 313100 - 313 100 (lte, available) > > 310410 - 310 410 (lte, available) > > > > root@bionic-armhf:~# mmcli --modem 0 --simple- > > connect="apn=vzwinternet" > > > > Stopping ModemManager and using qmicli in every way I currently > > know > > how yields this: > > > > root@bionic-armhf:~# systemctl stop ModemManager > > root@bionic-armhf:~# qmicli -d /dev/cdc-wdm0 --uim-get-card-status > > [/dev/cdc-wdm0] Successfully got card status > > Provisioning applications: > > Primary GW: slot '0', application '2' > > Primary 1X: session doesn't exist > > Secondary GW: session doesn't exist > > Secondary 1X: session doesn't exist > > Card [0]: > > Card state: 'present' > > UPIN state: 'not-initialized' > > UPIN retries: '0' > > UPUK retries: '0' > > Application [0]: > > Application type: 'csim (4)' > > Application state: 'detected' > > Application ID: > > A0:00:00:03:43:10:02:F3:10:FF:FF:89:02:00:00:FF > > Personalization state: 'unknown' > > UPIN replaces PIN1: 'no' >
Re: --list-bearers option errors in 1.10
On Mon, 2019-06-03 at 17:15 +0200, Aleksander Morgado wrote: > > To answer my own question to get current band ID you can use the > > new (1.10) option: > > > > qmicli -p -d /dev/cdc-wdm0 --nas-get-rf-band-info > > [/dev/cdc-wdm0] Successfully got RF band info > > Radio Interface: 'lte' > > Active Band Class: 'eutran-20' > > Active Channel:'6400' > > > > Please note that qmicli is not really part of MM, so this is not new > in MM 1.10. That qmicli command was introduced in the stable libqmi > 1.18.0 version. > Anyway, this is probably something we could expose in the > ModemManager > APIs as well, maybe in the Modem.Signal interface. Agreed. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] Fix sending/storing SMS messages when other AT commands get in the way
On Sun, 2019-05-19 at 09:42 +0200, Aleksander Morgado wrote: > Hey Dan & all, > > The original fix I had for this issue was to always add raw commands > to the head of the queue inside the serial port: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/103 > > The new fix I have for this issue is to setup a new queue of > operations at modem object level, so that no AT command/sequence can > be run if another AT command/sequence is running, and then I ported > the SMS send/store operations to be run as a sequence instead of > independent commands: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/105 > > I'm not sure, but looking at both MRs as if I hadn't written them > myself, I think that the original fix in MR#103 is much simpler, the > second one introduces another level of complexity that not sure if > it's needed. > > What do you think? I reviewed and merged #103. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: E173s-1 stops working after weeks of uptime
On Fri, 2019-05-31 at 11:18 +0200, Ladislav Michl wrote: > On Thu, May 30, 2019 at 09:46:01PM -0500, Dan Williams wrote: > > On Fri, 2019-05-31 at 00:01 +0200, Ladislav Michl wrote: > [...] > ...and I'll eventually create new thread to not continue hikacking > this one. > > > I'm using MM restart and if that doesn't help, then modem > > > powercycle and > > > then daemon restart. Boards do have modem power supply controlled > > > by > > > gpio, > > > so that's easy to do, but rather hackish. Is there any plan to > > > add > > > some > > > "modem hw reset" infrastructure here? > > > > We've thought about it before, but the problem is that it's pretty > > unreliable for USB ports on most machines that aren't embedded. > > Basically, you cannot guarantee that the USB host controller > > supports > > the command to power cycle a port, and a lot of them just don't. > > > > You can't expect the USB port reset to work, because that's a USB > > request to the firmware running on the device IIRC and if the > > device is > > already hung it's surely not going to pay attention to a reset > > request. > > Even worse, many quectels have nRST and PWR_KEY pins which name > suggests > to reset or power down/up them, but those are just gpios for them, so > the > only reliable way to reset is power cycle. And most of sane hardware > designers are creating their hardware with that in mind. > > > So basically yes, that infrastructure could be added, but there's > > no > > way you can depend on the request actually succeeding especially on > > x86 > > machines. > > I'm not talking about making it anyhow mandatory and not even about > ordinary laptops or PCs with frustrated user always able to replug > poor > USB modem once their favourite web page stops loading. > > ModemManager hit OpenWrt recently and is in PTXdist for ages, so > number > of "embedded" instalations could easily overgrow those "ordinary" > ones. > And each that embedded device have to deal with unreliable modem > somehow, > so I'd say it could be usefull to have at least some recomendation > how to handle such powercycles. Yes, definitely useful there if the platform has a way of actually killing power to the device, whether that's USB or GPIO or whatever. And I think it would be fine to add a method to the Modem object to do this. If there's a lot of variability in platforms (and I think there is :) we could theoretically have MM call out to a script to poke GPIOs or sysfs or run some other program. A start would be gathering the data on the different ways that platforms allow killing power to modems. TO start with, if it's USB and the hub reports per-port power control in wHubCharacteristic via lsusb -v then we might be able to power cycle. Dan > The thing is that those devices often do not have enough storage to > run > MM with debug log level, are otherwise unreachable, their CPU is > often > less powerfull than those used in modems (which could teoretically > run > all that software running on the board they are plugged into, but > that's > different story) and hangs does not occur so often, to be reasonably > debuggable. All that makes modem device power cycling the only > reliable > way to recover in field (except whole machine power on reset, of > course) ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: pppd timed out or didn't initialize our dbus module
On Mon, 2019-05-20 at 12:02 +0200, Przemyslaw Galazka wrote: > Hi Dan, > this question regarding bearer timeout is sorted out. It seems that > bigger > timeout will not fix the issue. It is all about configuring ppp > daemon > correctly. > > Adding this line to /etc/ppp/options resolved the issue - IP was > granted. > > root@7d15519:~# cat /etc/ppp/options > dump remotename 3gppp nocrtscts modem asyncmap 0 ipcp-accept-local > ipcp-accept-remote ipparam 3gppp usepeerdns noccp noipx NM will attempt to add some options to pppd for you, so that you can use different options on different devices if needed. Do you know which of the options here are required to make it work? Dan > Device will get IP address and ppp0 interface. I am not sure if net > is > working cos when we remove cable for Ethernet it goes offline in > Balena > Dashboard. Ping is working > > root@7d15519:~# ping o2.pl -Ippp0 > PING o2.pl (212.77.100.61): 56 data bytes > 64 bytes from 212.77.100.61: seq=0 ttl=55 time=909.741 ms > 64 bytes from 212.77.100.61: seq=1 ttl=55 time=389.459 ms > 64 bytes from 212.77.100.61: seq=2 ttl=55 time=325.432 ms > 64 bytes from 212.77.100.61: seq=3 ttl=55 time=446.667 ms > 64 bytes from 212.77.100.61: seq=4 ttl=55 time=425.208 ms > ^C > --- o2.pl ping statistics --- > 6 packets transmitted, 5 packets received, 16% packet loss > round-trip min/avg/max = 325.432/499.301/909.741 ms > root@7d15519:~# > > > But this is different story. > Thank you all for help and I hope that magic options set will help > others > to use M66 > > > > > wt., 14 maj 2019 o 18:04 napisał(a): > > > Hi, > > It seems that this was answered on a different support thread as > > well. > > Give us a note if there is a pending question in this thread. > > > > Kind regards, > > Thodoris > > > > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: pppd timed out or didn't initialize our dbus module
On Tue, 2019-05-14 at 16:44 +0200, Przemyslaw Galazka wrote: > Thanks for input. > > After changing logging level to debug for ppp demon, I can tell that > it is > trying to go through LCP phase and get IP address but ModemManager > has > configured 20 seconds timeout for this. > It seems like NetworkManager is killing pppd in the middle of > session, > always after 20seconds. Are you able to manually run pppd, without NetworkManager, to figure out how long the PPP link setup actually takes? It's pretty unusual for it to take 20+ seconds. MM sends the timeout to NetworkManager, so NM should be waiting at least 20s before terminating the connection attempt. Dan > How we can change that timeout then? It seems that is is hardcoded in > https://github.com/freedesktop/ModemManager/search?q=BEARER_IP_TIMEOUT_DEFAULT_q=BEARER_IP_TIMEOUT_DEFAULT > > > > pt., 15 lut 2019 o 16:51 Reinhard Speyerer > napisał(a): > > > On Fri, Feb 15, 2019 at 11:25:04AM +0100, Przemyslaw Galazka wrote: > > > This is BalenaOS (resinOS) so probably yes it may be custom. I > > > add > > BalenaOS > > > Support to this thread. > > > > > > Florin, could you let us know what options are used for NM and > > > ppp build > > > regarding your OS? > > > > > > pt., 15 lut 2019 o 10:25 Aleksander Morgado < > > > aleksan...@aleksander.es> > > > napisa??(a): > > > > > > > Hey, > > > > > > > > > > Jan 04 17:28:36 f8c790d NetworkManager[690]: Plugin > > > > /usr/lib/pppd/2.4.5/nm-pppd-plugin.so loaded. > > > > > > Jan 04 17:28:36 f8c790d pppd[2596]: nm-ppp-plugin: > > > > > > (plugin_init): > > > > initializing > > > > > > Jan 04 17:28:36 f8c790d pppd[2596]: nm-ppp-plugin: > > > > > > (nm_phasechange): > > > > status 3 / phase 'serial connection' > > > > > > Jan 04 17:28:57 f8c790d NetworkManager[690]: > > [1546622937.1715] > > > > ppp-manager: pppd timed out or didn't initialize our dbus > > > > module > > > > > > Jan 04 17:28:57 f8c790d pppd[2596]: nm-ppp-plugin: > > > > > > (nm_phasechange): > > > > status 1 / phase 'dead' > > > > > > > > Is this a custom system that you build? if so, which are the > > > > configure > > > > options you use for NM and ppp? > > > > > > > > Hi, > > > > in case NM and ppp configure options look normal my suggestion for > > narrowing down the problem would be to use the pppd command line > > from the NetworkManager log without the "plugin > > /usr/lib/pppd/2.4.5/nm-pppd-plugin.so" part and check if pppd also > > times > > out > > when you start it manually. If it does try adding the options read > > from > > /etc/ppp/peers/gprs one after another. A common problem with some > > TS 27.060 > > IP relay implementations in mobiles is the lack of proper VJ/CCP > > support. > > Please try adding novj noccp first. > > > > Regards, > > Reinhard > > > > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [PATCH] broadband-modem-mbim: parse nw_error in register_state_set_ready only if MBIM_STATUS_FAILURE
On Thu, 2019-04-25 at 12:33 +0200, Aleksander Morgado wrote: > Hey! > > > Any update on the patch? :) > > In the meantime I got response from Telit that they won't fix the > > original problem which made me create this patch. > > > > Oh wow, I forgot about it, sorry... > I have pushed it to a new merge request in gitlab now: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/97 > > @Dan Williams @Ben Chan any comments on this? Looks good to me, I merged it. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Do you need hardware to develop ModemManager?
On Fri, 2019-04-05 at 11:36 +0200, Aleksander Morgado wrote: > Hey, > > If anyone is interested in contributing more to ModemManager and > would > like to have more test devices to play with, please drop me a private > email and we'll try to fix that. I also have some devices that I would be willing to send to developers. Send mail to Aleksander and he and I can work it out :) Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Problems compiling with clang (3.8.21)
On Tue, 2019-04-02 at 15:34 +0200, Torsten Hilbrich wrote: > Hello, > > I tried to compile libmbim (1.16.0), libqmi (1.20.0) and ModemManager > (1.8.0) with clang and got strange results. > > I set the environment variables CC=clang and CXX=clang++ and ran the > autogen.sh, configure, and make steps. > > Then the configure noticed that clang was used and checked for the > supported warning options: > > CC='clang' > configure:3408: checking for gcc > configure:3435: result: clang > ... > configure:17644: checking whether gcc understands -Wno-unused-but- > set-variable > configure:17657: clang -c -Wall -std=gnu89 -g -O2 -Wmissing- > declarations -Wmissing-prototypes -Wdeclaration-after-statement > -Wstrict-prototypes -Wno-unused-parameter -Wno-sign-compare -Wno- > deprecated-declarations -Wno-unused-but-set-variable conftest.c >&5 > warning: unknown warning option '-Wno-unused-but-set-variable'; did > you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option] > 1 warning generated. > configure:17657: $? = 0 > configure:17666: result: yes I think -Wno-unused-but-set-variable is actually a mistake and it should be "-Wunused-but-set-variable". But that causes build errors that we should fix. Does clang support -Wunused-but-set-variable? Also, does making this change in m4/compiler_warnings.m4 of ModemManager sources help? - CFLAGS="$CFLAGS $option" + CFLAGS="$CFLAGS $option -Werror" Dan > > However, when compiling the code I got the following error messages: > > make[4]: Entering directory > '/build/client/clang/freedesktop/modemmanager/work/modemmanager/libqc > dm/src' > CC libqcdm_la-com.lo > error: unknown warning option '-Wno-unused-but-set-variable'; did you > mean '-Wno-unused-const-variable'? > [-Werror,-Wunknown-warning-option] > Makefile:516: recipe for target 'libqcdm_la-com.lo' failed > make[4]: *** [libqcdm_la-com.lo] Error 1 > > I assume that checking in configure is done without -Werror, but > compilation at least in libqdcdm is done with -Werror. > > > It this a known problem? Are fixes welcome to support compilation > with clang? > > The same problem happened in libmbim and libqmi. > > With regards, > > Torsten Hilbrich > > > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Where are you using ModemManager?
On Mon, 2019-03-25 at 18:14 +0100, Aleksander Morgado wrote: > Hey! > > If you or your company are using ModemManager in a professional > product, would you mind sharing your experience in the mailing list? > > Even generic descriptions would be appreciated, but if you can share > also platform details that would be great. Of course, only asking for > information that can be published, please don't break any NDA :D The NetworkManager/ModemManager team at Red Hat was recently involved in a project that deployed Sierra 7608 devices to track trains in real- time on Indian Railways. https://www.hindustantimes.com/india-news/railways-to-install-gps-devices-on-2-700-electric-locomotives/story-P5Hteh8khvB7yHYcZmLKzI.html https://www.governancenow.com/news/regular-story/tracking-locomotives-in-real-time- Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: How other applications use the ports that occupied by MM
On Mon, 2019-03-18 at 11:24 +0100, Aleksander Morgado wrote: > Hey, > > > I am trying to find a way to use the AT ports or mbim ports that > > occupied by MM as all the device ports were used by MM. eg. I want > > send AT command to the modem, but MM occupies the AT port. Is there > > any way to make MM stop using the AT port for a while but not kill > > the MM? To do that, maybe the application can send a D-bus signal > > or request a method to MM, then MM stop the AT port for a while, > > after application finish its work, send a D-bus info to MM, MM > > continue use the AT port. > > If the AT port is not the primary control port, you could add the > ID_MM_PORT_IGNORE udev tag on the specific TTY so that MM ignores it. > > > And I know in MM debug mode, mmcli could use --command to send the > > AT command. Is there normal mode way to send AT command from MM? > > Right now --command only works while in debug mode, so that the user > doesn't send commands that may interfere with the control logic of > MM... > > But truth be told, we're already allowing QMI and MBIM commands to be > sent through the proxies while MM is running anyway... > > @Dan Williams what would you think if we open up the Modem.Command() > method also while not in debug mode? We could explicitly warn that MM > will treat all these commands as transparent, so if the state of > modem > changes as a result of these commands, MM may get out of sync. > Another > option I'm thinking about is to make it a configure option instead. > Don't know, mixed feelings. Yeah, mixed feelings from me too. I guess before we do that, can we ask what commands people want to use? I'd rather it not be used a short circuit for stuff that could be fixed in MM or implemented fairly easily for a device. That's my only reservation, that having it may reduce the incentive to fix/enhance MM itself. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Connect Cinterion modem with SWWAN fails with unknown error
On Fri, 2019-03-15 at 16:34 +0100, Sven Schwermer wrote: > Hi all, > > > On 15 Mar 2019, at 16:03, matthew stanger > > wrote: > > > > Anyway, the only thing I can think of is a timing issue with the > > modem > > firwmare and network registration or initial bearer setup or > > something > > like that. Perhaps MM isn't querying some ready state well enough, > > or > > the modem isn't fully set up when we're querying because MM isn't > > asking the right question. NOt sure what else it could be. > > Wonderful observation there. Just realized this modem's boot ready > > URC is '+PBREADY'. There's nothing in MM to support(minus ublox > > plugin) this cmd, which would imply that MM would be sending cmd's > > before the module is ready. > > > > I made sure that the modem was freshly booted in both cases. > > That'd be the main difference, you waited. > > > > To test this theory out all you need to do is stop MM, plugin/start > > your modem give it ~20 sec's to be sure. Then start MM and see if > > the connection now works. Let me know if that work and then we can > > go from there. > > I actually tried exactly this: I restarted the modem without > ModemManager running, sent AT to the modem until I got +PBREADY as > part of the reply and then started ModemManager. Unfortunately, this > leads to the same behaviour. Same old +CEER: "SM > deactivation",187,"Last PDN disconnection not allowed” Might this imply that we're talking about the initial bearer and that when MM tries to connect, because it will attempt to close any existing connection, the modem is telling MM "no"? We already know we need to be better about auto-detecting that the initial bearer is active and should probably create a Bearer object to represent it when we can figure it out. Then perhaps a connection request for the same APN would just be NOP and return that already created bearer? (perhaps Aleksander already implemented that, I recall some discussion about it late last year) Dan > Sven > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Connect Cinterion modem with SWWAN fails with unknown error
On Fri, 2019-03-15 at 14:20 +0100, Sven Schwermer wrote: > Hi again, > > I did some more work and now I am able to connect manually (without > ModemManager). All that’s required is the AT^SWWAN=1,1 command if the > APN is already correctly configured. I checked this via AT+CGDCONT?. > Note, that this only works for CID=1. After changing the APN for > CID=1, the modem must be forced to re-attach since the modem auto- > attaches after power-up. More on this can be found in the chapter > “Attaching to LTE Networks” in AT manual. Another interesting fact is > that the modem appends a string to the APN after it has attached, in > my case “.mnc009.mcc242.gprs”. I’m not sure if this is common. > > In order to debug the command sequence issued by ModemManager, I > extracted all commands sent by the ModemManager from the debug logs > incl. their timing. I then replayed them with the same (similar) > timing manually from a script, i.e. without ModemManager running. I > made sure that the modem was freshly booted in both cases. Curiously, > when replaying the commands, the AT^SWWAN commands succeeds. This > leaves me a little puzzled. Great debugging strategy actually :) This is something I had wanted to do for MM testing too, record the commands, responses, and timing to a file so we could use them later for unit tests. Anyway, the only thing I can think of is a timing issue with the modem firwmare and network registration or initial bearer setup or something like that. Perhaps MM isn't querying some ready state well enough, or the modem isn't fully set up when we're querying because MM isn't asking the right question. NOt sure what else it could be. > Does ModemManager issue commands concurrently? I saw in the logs both > “device open count is 2 (open)” and “device open count is 3 (open)”. > Could that mean that sometimes two AT commands are sent at the same > time? MM serializes commands on the same port using an internal queue to hold pending commands, and will not issue the next command until the response to the first has either arrived or timed out. While connected on a serial port with PPP MM will try to send commands (signal strength, access tech, etc) on a secondary AT port while the main one is occupied with PPP. Dan > Best regards, > Sven > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [EXTERNAL] Re: connect using a specific PDP CID
On Thu, 2019-03-14 at 16:53 +, Taff, Philip wrote: > > From: Aleksander Morgado > > Sent: Friday, March 08, 2019 2:01 PM > > > > I have mixed feelings about this patch :) in one side, it's not the > > best way to do it, as a proper profile management API would be > > best, > > but from the other side it's a quick way to get the issue resolved > > until that API is developed; if ever! > > @Dan Williams what do you think? should we think in integrating > > this > > workaround until the profile management API is done? > > > > The patch would work for us. Do we need permission to use it? It's > GPL? > > > > On Fri, Mar 8, 2019 at 11:40 AM Aleksander Morgado > > wrote: > > > > Right now, you could manually create the PDP context with the > > > > settings > > > > you want, and MM should re-use the already created context if > > > > the > > > > settings requested match the existing ones. > > > > > > I did try letting MM find the right PDP context this way, but the > recommendation > I got from Sierra Wireless was to leave the APN blank when connecting > to CAT-M > networks and allow the network to provide the APN name during network > registration. > Since PDP context #1 was also blank, MM tried that, which didn't > work. > > Calling pppd directly using context #3 with a blank APN works fine. In these scenarios, does anybody know if the issues with a random context # are: (a) the modem itself caring about the context # (b) or somehow the network caring about the context # (which I didn't think was passed to the network at all) (c) or is it settings on the PDP Context itself that are wrong and if the settings were correct any context # would work (d) or something else entirely? I was under the impression that a context is a context is a context, and as long as the APN, auth, traffic template, etc were all correct then it shouldn't matter what context # you pick. Obviously some contexts are special (like the default/initial bearer/#0 one) but I didn't think that extended beyond the initial bearer/#0. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Sierra HL7692
On Wed, 2019-03-13 at 08:36 +0100, Sven Schwermer wrote: > Hi, > > I’m currently trying to get the Sierra HL7692 up and running. In my > first attempt, I set the USB composition to AT+KUSBCOMP=2 so that I > would get 1x MBIM + 3x CDC-ACM. This worked but the modem was only > recognised as “generic” which didn’t allow for extended signal query, > etc. If all you're looking for is the extended signal query, the MBIM driver does support this if the modem implements the ATDS (AT Device Services) UUID. What do you get for: mbimcli -p -d /dev/cdc-wdm --atds-query-signal Dan > Next, I set the USB composition to AT+KUSBCOMP=0 which enumerates 4x > CDC-NCM + 3x CDC-ACM. The USB enumeration works ok: > > usb 1-1: new high-speed USB device number 6 using ci_hdrc > cdc_acm 1-1:1.0: ttyACM0: USB ACM device > cdc_acm 1-1:1.2: ttyACM1: USB ACM device > cdc_acm 1-1:1.4: ttyACM2: USB ACM device > cdc_ncm 1-1:1.6: MAC-Address: 00:00:11:12:13:14 > cdc_ncm 1-1:1.6: setting rx_max = 16384 > cdc_ncm 1-1:1.6 wwan0: register 'cdc_ncm' at usb-ci_hdrc.0-1, Mobile > Broadband Network Device (NO ARP), 00:00:11:12:13:14 > cdc_ncm 1-1:1.8: MAC-Address: 00:00:11:12:13:16 > cdc_ncm 1-1:1.8: setting rx_max = 16384 > cdc_ncm 1-1:1.8 wwan1: register 'cdc_ncm' at usb-ci_hdrc.0-1, Mobile > Broadband Network Device (NO ARP), 00:00:11:12:13:16 > cdc_ncm 1-1:1.10: MAC-Address: 00:00:11:12:13:18 > cdc_ncm 1-1:1.10: setting rx_max = 16384 > cdc_ncm 1-1:1.10 wwan2: register 'cdc_ncm' at usb-ci_hdrc.0-1, Mobile > Broadband Network Device (NO ARP), 00:00:11:12:13:18 > cdc_ncm 1-1:1.12: MAC-Address: 00:00:11:12:13:1a > cdc_ncm 1-1:1.12: setting rx_max = 16384 > cdc_ncm 1-1:1.12 wwan3: register 'cdc_ncm' at usb-ci_hdrc.0-1, Mobile > Broadband Network Device (NO ARP), 00:00:11:12:13:1a > > The ModemManager also detects the modem correctly: > > /org/freedesktop/ModemManager1/Modem/2 (device id > '50bd7c933398deee2cfebb3b26c0bc554cf8ccdd') > - > Hardware | manufacturer: 'Sierra Wireless' >| model: 'HL7692' >| revision: > 'RHL769x.2.26.180400.201802141030.x7120m_1' >| H/W revision: 'unknown' >| supported: 'gsm-umts, lte' >|current: 'gsm-umts, lte' >| equipment id: ‘xxx' > - > System | device: > '/sys/devices/platform/soc/3080.aips- > bus/30b1.usb/ci_hdrc.0/usb1/1-1' >|drivers: 'cdc_acm, cdc_ncm' >| plugin: 'Generic' >| primary port: 'ttyACM0' >| ports: 'wwan3 (net), ttyACM0 (at), wwan0 (net), > wwan1 (net), wwan2 (net), ttyACM2 (at)' > - > Numbers | own : 'unknown' > - > Status | lock: 'none' >| unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk > (10), sim-puk2 (10)' >| state: 'registered' >|power state: 'on' >|access tech: 'lte' >| signal quality: '0' (cached) > - > Modes| supported: 'allowed: 2g, 3g, 4g; preferred: none' >|current: 'allowed: 2g, 3g, 4g; preferred: none' > - > Bands| supported: 'unknown' >|current: 'unknown' > - > IP | supported: 'ipv4, ipv6, ipv4v6' > - > 3GPP | imei: ‘xxx' >| enabled locks: 'none' >|operator id: 'unknown' >| operator name: 'unknown' >| subscription: 'unknown' >| registration: 'home' >|EPS UE mode: 'csps-1' > - > SIM | path: '/org/freedesktop/ModemManager1/SIM/2' > > - > Bearers | paths: > '/org/freedesktop/ModemManager1/Bearer/2’ > > I can even connect via --simple-connect. The problem is that > NetworkManager always connects via pppd over the CDC-ACM port. I > would have expected to establish the connection via one of the CDC- > NCM ports (wwan0..4). When I create a connection like so > > nmcli c add type gsm ifname wwan0 apn apn.mydomain.com > > I’m getting “Error: Connection activation failed: No suitable device > found for this connection.” > > When no interface is specified, NetworkManager selects ttyACM0. How > do I make NetworkManager select the CDC-NCM port? > > I realise that this may be more related to NetworkManager but hope > that I find better answers here. I’m using ModemManager 1.8.2, > NetworkManager 1.12.2 and Linux 4.1.32. > > Best regards, > Sven > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list
Re: Signal Quality value with LTE modems
On Tue, 2019-03-12 at 08:31 +0100, Sven Schwermer wrote: > Hi, > > I’m wondering what factors into the Signal Quality value for LTE > modems. My suspicion is that only the “Signal” field of the +CIND ModemManager, by default, asks the modem what it thinks it's signal quality is via CIND. That gives a number 0-5, and MM reports that as a percentage. ETSI 27.007 says for the "signal" CIND indicator: "signal" signal quality (0-5) so if the modem isn't presenting something useful here, I'm not sure why it's implementing this indicator in the first place :) Random question, what does +CSQ report? MM uses +CIND because it gives async notifications, which +CSQ does not. CSQ is usually tied to RSSI though, which still isn't as useful for LTE. > message is used, but if I understood the manual for the ublox LARA- > R211 correctly, that’s a poor quantity to use for this purpose as it > only represents the RSSI. A better quantity would be the RSRP (and/or > SNR). On my modem I’m getting a Signal Quality value between 0 and > 20%, but the RSRP is better than -100dBm. On Android ( > https://android.googlesource.com/platform/frameworks/base/+/master/telephony/java/android/telephony/CellSignalStrengthLte.java#160 > ) this would have resulted in 2 out of 4 bars, i.e. ~60%. > > I’m using ModemManager 1.8.2. What’s the best way of dealing with > this? Should I use the signal API and do the conversion to a > percentage/bar count myself? You can use the Signal interface of ModemManager to pull out all lower- level values from the modem. "mmcli -m X --signal-setup=" starts and refreshes the signal values and "mmcli -m X -- signal-get" gets the current signal values. While this is supported for many modems, for some modems we either don't have the AT or other commands that report things like RSRP or ECIO, or it hasn't been implemented for those devices. It looks like the ModemManager 'ublox' plugin has support for extended signal reporting through the ETSI 27.007 "+CESQ" command, assuming the R211 supports it. Give the --signal-* stuff a try and see if that works for you. It's also available via the D-Bus interface which gives you event notifications on changes, if you're writing a custom app. If it doesn't work for the R211 let us know and we can possibly debug further. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager: symbol lookup error: ModemManager: undefined symbol: qmi_client_loc_register_events_finish
On Tue, 2019-03-05 at 11:55 -0500, Cathy Logan wrote: > Hi All - > New to ModemManager and this list. Got ModemManager to successfully > make > and make install with no errors. > > Can't seem to get it to start correctly though. Trying to run > ModemManager > --debug gives me the error "ModemManager: symbol lookup error: > ModemManager: undefined symbol: > qmi_client_loc_register_events_finish" . That function exists in libqmi 1.22 and later. Perhaps your ModemManager build was done against a recent-enough libqmi, but now at runtime it's only finding an older one? What does: ldd /usr/sbin/ModemManager | grep libqmi say? For example, mine says: /lib64/libqmi-glib.so.5 so then I: objdump -T /lib64/libqmi-glib.so.5 | grep qmi_client_loc_register_events_finish If you don't get a hit in that libqmi-glib.so then yeah, it's using the wrong library version at runtime. Did you also install the updated libqmi with the right --prefix specified at configure time? (if any of this is unclear, let me know and I can explain more) Dan > The service also fails to start with the following error: " Active: > failed > (Result: exit-code) since Mon 2019-03-04 21:41:09 EST; 14h ago > Main PID: 10196 (code=exited, status=127)" > > Running on Ubuntu 18.04 LTS. > > Any help would be greatly appreciated! > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Any special reason set cid=0 as invalid CID
On Wed, 2019-02-27 at 14:55 +0800, 王道之 wrote:
> Hey
> When I read the MM code, the bearer treat the cid=0 as a invalid CID
> confused me. But I think there may be some special reasons.
> In the MM Ver1.10.0 source code, src/mm-broadband-bearer.c
Older versions of the ETSI 27.007 spec specified the minimum PDP
context number as 1. But at least v11+ says:
"The range of permitted values (minimum value = 1 or if the
initial PDP context is supported (see subclause 10.1.0), minimum value
= 0) is returned by the test form of the
command."
MM didn't get updated to account for that. So there is no special
reason except history, and that can change :)
Dan
> *static guint*
> *cid_selection_3gpp_finish (MMBroadbandBearer *self,*
> * GAsyncResult *res,*
> * GError**error)*
> *{*
> *gssize cid;*
>
> */* We return 0 as an invalid CID, not -1 */*
> *cid = g_task_propagate_int (G_TASK (res), error);*
> *return (guint) (cid < 0 ? 0 : cid);*
> *}*
>
> As my Intel 7560 module(not in Mbim on Linux), after set AT+COPS=0 ,
> it
> would auto get IP on the cid=0 PDP.
> Then the MM logic would treat the cid=0 as invalid, after that MM
> would
> creat a new PDP context with +CGDCONT=1,*,*.
> Though it works at the end. But I think it is better to use the auto
> connect one that cid=0.
> So what are the special reasons for the cid=0 invalid? Or maybe can
> we use
> *#define INVALID_CID G_MAXUINT*
> as a invalid cid?
>
> Quincy
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: How to add a button for ModemManager on Ubuntu GUI
On Tue, 2019-02-26 at 14:23 +0800, 王道之 wrote: > Hey > Recently I am doing some test development on ModemManager. > There is a requirement that add a button on the Ubuntu GUI to set IP > family(ipv4 or ipv6) of the ModemManager.(Just for test now) > Here are my questions: > 1.The Ubuntu desktop GUI button should be a Dbus client? Or how the > button > communication with the ModemManager? UIs typically communicate with NetworkManager (or if KDE, then KDE's plasma-nm) and tell NetworkManager to update the connection details. NetworkManager is what actually sends configuration to ModemManager when the connection is requested. > 2.After a Modem be created in ModemManager, we can find the menu for > MM in > the GUI. Is the menu as a Dbus client connect to NetworkManager or > just > connect with ModemManager? The menu is a DBus client of NetworkManager and ModemManager. But the bits that would do v4/v6 interact with NetworkManager. > 3.How to judge the GUI setting has sent to ModemManager? I have no > idea to > read the what is going on in the ModemManager Dbus session. The process that happens is usually this... - ModemManager finds a new modem; NetworkManager listens to MM and creates a new NMDevice object for the modem - a UI applet listens to NetworkManager for the Device object and then displays the modem in the menu. - the UI applet listens to ModemManager for signal and carrier information. - when the user wants to connect WWAN the first time, the UI applet will ask for some additional information like carrier name and plan so that it can determine which APN to use - when the UI knows what APN to use, it then asks NM to create a new Connection for the modem (using that APN) and connect the device - NM then handles connecting WWAN, including asking ModemManager to start the packet data connection, and then performs IP address configuration If you need to modify the v4/v6 preference, the place to do that would typically be in the UI that asks for the APN, since that's where the Connection object details are requested from the user. You need to be a bit careful though, since not all modems support v6 or mixed v4v6 PDP contexts. ModemManager indicates what the modem supports on D-Bus, so the UI you construct should also query ModemManager for the modem's capability and only present choices that will actually succeed. Dan > I have search the questions on Internet, but not get the > answer.(Maybe the > search info not exact) Thanks for your any help information! > > Quincy > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Analysing boot time
On Wed, 2019-02-13 at 16:01 +0100, W. Martin Borgert wrote: > Hi, > > on my embedded system, "systemd-analyze blame" says: > > 15.254s ModemManager.service > 10.562s NetworkManager.service > ... > > I.e. MM and NM are the two slowest services in terms of start time. > Is there anything I can do about it or try to find out, why they > take so much time? Which versions of both? MM is likely the probing delay, and recent versions of MM have stricter rules on what gets probed and what doesn't, which could cut down its startup time. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Planning for MM 1.10
On Tue, 2018-12-04 at 11:50 +0100, Aleksander Morgado wrote: > Hey Dan and all, > > I've been asked whether we can have MM 1.10 soon, to get it > integrated > in Debian early enough and ready for Ubuntu 19.04. Canonical may even > work on backporting this version to the 18.04 LTS. I've always > complained about Ubuntu having very old MM versions (which is why I > kept doing the PPAs), so I'm personally happy if all this happens. > > So, I'd like to suggest we have MM 1.10 released by the end of this > year, and for that we could have the list of features closed earlier, > e.g. mid-December. What do you all think? > > In my pending list of things I still have two additional features I'd > like to suggest, although maybe it's too late? I believe I can work > on > these in the next weeks and probably ready by mid-December. > * New APIs to integrate with fwupd > ( > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/95 > ) > * New APIs to report multiple detected SIM cards and to switch SIM > from one to another (dual SIM single active), implemented for > QMI-capable modems with the UIM service. > > Comments? Suggestions? +1 Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Huawei ME906s-158 (a.k.a. HP lt4132) IPv6 support
On Sat, 2018-12-01 at 11:37 +0100, Tore Anderson wrote: > * Tore Anderson > > > I'm having problems making IPv6 work with this device. Even though > > Huawei's home page[1] claims it supports IPv6, the "AT+CGDCONT=?" > > only > > gives a single response line with the "IP" PDP type. > > Just in case anyone with the same problem happens to stumble across > this > old thread: I've finally figured out how to enable IPv6 support in > the > Huawei ME906s-158 / HP lt4132. For the details, see: > > https://toreanderson.github.io/2018/12/01/huawei-me906s-hp-lt4132-enabling-ipv6.html Facepalm... Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: u-blox R410M modem (QMI) configuration with modern Network-manager
On Fri, 2018-11-30 at 11:24 -0800, Tim Harvey wrote: > On Fri, Nov 30, 2018 at 3:12 AM Aleksander Morgado > wrote: > > Hey, > > > > > I'm trying to use a u-blox QMI R410M with network manager on > > > Ubuntu > > > bionic witht he following which works fine on Ubuntu xenial: > > > > > > # nmcli connection add type gsm ifname cdc-wdm0 con-name mymodem > > > apn $APN > > > # nmcli connection up id mymodem > > > > > > The modem's QMI interface is indeed /dev/cdc-wdm0, my APN is > > > correct, > > > and I can connect just fine using mmcli or qmicli directly. > > > > > > On Xenial with network-manager-1.2.6 this works fine but on > > > Bionic > > > with network-manager-1.10.6 this results in 'Error: Connection > > > activation failed: No suitable device found for this > > > connection.'. > > > > > > I'm thinking the connection configuration syntax has likely > > > changed > > > I'm I'm simply using the wrong syntax? > > > > > > Note that I'm using libqmi-1.20.2 and modemmanager-1.8.2 from > > > Aleksander's Ubuntu PPA's in both cases. > > > > > > > I'm not totally sure what might have changed in NM, but have you > > tried > > creating the connection *without ifname*? > > You can have "gsm" connection settings not bound any interface, NM > > will try to find a suitable device when connecting. > > > > hmm... I wonder if that's not available until a newer version of NM? > > root@bionic-newport:~# nmcli --version > nmcli tool, version 1.10.6 > root@bionic-newport:~# nmcli connection add type gsm con-name mymodem > apn $APN > Error: 'ifname' argument is required. Yeah, that's a bug in nmcli: https://bugzilla.gnome.org/show_bug.cgi?id=780323 I think you can delete the ifname after you create the connection though. > I've always thought the 'gsm' and 'cdma' types are a bit outdated for > modern LTE modems but it looks like that is what your supposed to > continue using according to the NM docs. These days "gsm" means any GSM, UMTS, and LTE provider, even if the LTE provider still runs a CDMA network. The modem hides the details of CDMA for you. We may be able to deprecate it in a few years when most of the CDMA/EVDO networks are shut down. The NM distinction for cdma & gsm existed before LTE was a thing, and NM values backwards compatibility, so it's still there. > I wonder if there is something wrong with NM here as it doesn't even > seem to be even managing my wired connections: IIRC on Ubuntu (and perhaps Debian?) if you have anything in /etc/network/interfaces, then the distro configures NM to ignore those interfaces. I think if you remove anything related to eth0 from /e/n/i then NM will be able to manage them. Dan > root@bionic-newport:~# ifconfig > eth0: flags=4163 mtu 1500 > inet 172.24.25.23 netmask 255.240.0.0 broadcast > 172.24.255.255 > inet6 fe80::2d0:12ff:fe0f:f583 prefixlen 64 scopeid > 0x20 > ether 00:d0:12:0f:f5:83 txqueuelen 1000 (Ethernet) > RX packets 66096 bytes 18460509 (18.4 MB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 3726 bytes 299073 (299.0 KB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > loop txqueuelen 1000 (Local Loopback) > RX packets 58 bytes 5562 (5.5 KB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 58 bytes 5562 (5.5 KB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > root@bionic-newport:~# cat /etc/network/interfaces > # ifupdown has been replaced by netplan(5) on this system. See > # /etc/netplan for current configuration. > # To re-enable ifupdown on this system, you can run: > #sudo apt install ifupdown > allow-hotplug eth0 > auto eth0 > iface eth0 inet dhcp > > root@bionic-newport:~# nmcli device status > DEVICETYPE STATE CONNECTION > can0 can unmanaged -- > eth0 ethernet unmanaged -- > eth1 ethernet unmanaged -- > eth2 ethernet unmanaged -- > eth3 ethernet unmanaged -- > eth4 ethernet unmanaged -- > loloopback unmanaged -- > cdc-wdm0 modem unmanaged -- > > Instead on xenial I get: > root@xenial-newport:~# nmcli --version > nmcli tool, version 1.2.6 > root@xenial-newport:~# nmcli device status > DEVICETYPE STATE CONNECTION > eth4 ethernet connected Wired connection 1 > cdc-wdm0 modem disconnected -- > eth1 ethernet unavailable -- > eth2 ethernet unavailable -- > eth3 ethernet unavailable -- > can0 can unmanaged -- > eth0 ethernet unmanaged -- > loloopback unmanaged -- > > By the way, thank you again for your modemmanager PPA's, they are > doing wonders for us ARM/ARM64 users! > > Regards, > > Tim > ___ > networkmanager-list mailing list >
Re: [review] LTE attach config and status
On Fri, 2018-11-23 at 18:01 +0100, Aleksander Morgado wrote: > Hey hey, > > See the following MR: > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/52 I merged the K/V PR so this one needs a rebase now. Dan > The changes will update the 3GPP interface with: > * A new read-only property "InitialEpsBearer", which points to a > Bearer object that will be automatically created and exposed in DBus > when registered in LTE. This bearer object will define the > settings/status of the initial LTE default bearer in effect at any > given time during runtime. > * A new read-only property "InitialEpsBearerProperties", a > dictionary > which contains the user-defined settings for the initial LTE default > bearer. These settings MAY NOT be the ones effectively used at the > end > (e.g. if the network decides to use others, or if none provided by > the > user). > * A new method "SetInitialEpsBearerProperties", which allows users to > update the InitialEpsBearerProperties settings. > > The changes also include a new "bearer type" enumeration. The normal > user-created bearers will be "default" bearers, while the initial > automatically created bearer will be a "default initial" bearer. We > also define an enum for "dedicated" bearers but we don't have APIs to > support those yet . > > The logic is first implemented for MBIM devices, following the > commands defined by Microsoft in the Basic Connect Extensions > service: > > https://docs.microsoft.com/en-us/windows-hardware/drivers/network/mb-lte-attach-operations > The ModemManager integration only changes the "home" network > settings, > we leave the "partner" and "non-partner" specific settings defined in > the MBIM operations unchanged. > > NOTE! The commits are implemented right now on top of the mmcli > key/value output changes, I pushed a MR which also contains those > commits, just to avoid unnecessary rebase work. > > Comments welcome! > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: IPv4 config for QMI modem
On Mon, 2018-11-12 at 14:02 +0100, Sven Schwermer wrote: > Hi again! > > > I’m currently using a 4.1.x kernel. I’ll try with a 4.18.x kernel > > now. I’ll keep you posted. > > I have gotten a step further with a newer kernel. DNS works as well > as simple pinging (ICMP). However, when trying to establish a TCP > connection, the connection times out. I then went ahead and captured > the packets both on the modem’s system side as well as on the > cellular operator side. There I could see that the TCP handshake > never completes because the modem complains with “Fragmentation > needed”. When looking at the modem’s MTU, I could see that the IPv4 > settings in the bearer called for a 68 byte MTU. That seems very Yeah, 68 byte MTU is the minimum IPv4 Ethernet MTU per RFC791. That's quite odd and likely way too small. Most of the MTUs I've seen reported from modems are in the 1400-1500 range. MM/NM usually try to follow what the firmware tells them to do. I don't know how the modem firmware gets that MTU, but that sounds like a firmware or network-side bug to me. Perhaps the thing that configures the interface (NM or whatever) could enforce a minimum MTU, but it would be interesting to know if very low MTUs are used in practice too. Dan > small—is that common for modems like this? I also noticed that the > NetworkManager doesn’t query the MTU from the ModemManager and so the > MTU was incorrectly set to 1500. I corrected this via the > NetworkManager connection configuration file (in the [gsm] section), > but this prevented all communication from working. > > The modem I’m using still has the “engineering sample” status, so > maybe this can be blamed on faulty firmware, but it’s not looking too > good. > > Sven > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Problem with reconnecting when using Ericsson H5321 modem and Aero2 BDI network
On Sat, 2018-11-10 at 16:34 +0100, Mateusz P wrote: > Hi, > I have a problem with modemmangager 1.6.8-2ubuntu1 and 1.8.2-1. > > Modem: Ericsson H5321. > Computer: Lenovo ThinkPad X230. > Network: Aero2 BDI (Polish, APN darmowy). > > The network (according to obtained licence for using radio spectrum > frequencies) is obliged to provide a service of a free Internet > access > with a few limits. > One of those limits is an automatic disconnection every (about) 1 > hour. > In order to access the Internet again one needs to reconnect and > solve > the Captcha. > > The first problem with the mentioned modem is that the disconnection > is > not visible to the user - the Network Manager works as if the > connection > would be still active - the Network Manager shows the connection as > still active and one needs to disconnect manually as there is no > Internet access. Looks like the modem doesn't indicate disconnection via MBIM Basic Connect Packet Service State. When you think it's disconnected, could you run: mbimcli -p -d /dev/cdc-wdm3 --query-connection-state=0 I'm curious what the "Activation State" property will be when the modem is disconnected. If it reports that the activation state is disconnected, then we probably need to implement support for the MBIM Basic Connect "Connect" notification, or implement polling the state via load_connection_status. Dan > The problem is there is no way to reconnect to the network as after > disconnecting Network Manager only flashes connecting icon and shows > disconnected icon. > After restarting Network Manager or modemmanager services the > problem > still persists. It can be solved by suspending or rebooting the > computer. > The problem exists on both Linux Mint 19 Xfce (1.6.8-2ubuntu1) and > Manjaro 17.1.12 OS-es (1.8.2-1). > > Related logs (dpkg -l, mmcli, modemmanager, NetworkManager): > https://gist.github.com/mp107/238e6d745770a4f666902fd45a8de95e > Timestamps of some of the trials of reconnecting to the network: > 1541701353, 1541701417. > > Best regards, > Mateusz > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New key-value output in mmcli
On Fri, 2018-11-09 at 18:31 +0100, Aleksander Morgado wrote: > Hey, > > > > > > See this MR: https://gitlab.freedesktop.org/mobile-broadband/Mode > > > mMan > > > ager/merge_requests/51 > > > > > > This enables a new "-K" (or longer, "--output-keyvalue") that > > > allows > > > all operations that print some kind of modem info (e.g. modem > > > list, > > > modem info, sim info, bearer info, sms info, 3gpp scan...) to be > > > dumped in a simple "key-value" pair format. > > > > > > Along with these changes, I've also made some additional changes: > > > deprecating ListBearers() method and removing the redundant > > > --simple-status and --location-get-XXX actions. > > > > > > Worth noting: the original human-friendly output is more or less > > > maintained but it is NOT equal to the old one. Applications (e.g. > > > the > > > openwrt integration) that were parsing that original output > > > should > > > switch to the new key-value pair output. > > > > Do you have a before/after example of the tabular output? > > > > Attached Thanks; looks like the main difference is long lines are intelligently wrapped now, so code expecting one-value-per-line will break. I haven't checked the implementation in detail, but does it hardcode the wrapping at a certain point or determine it based on terminal size or something? Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New key-value output in mmcli
On Sat, 2018-11-03 at 16:04 +0100, Aleksander Morgado wrote: > Hey! > > See this MR: https://gitlab.freedesktop.org/mobile-broadband/ModemMan > ager/merge_requests/51 > > This enables a new "-K" (or longer, "--output-keyvalue") that allows > all operations that print some kind of modem info (e.g. modem list, > modem info, sim info, bearer info, sms info, 3gpp scan...) to be > dumped in a simple "key-value" pair format. > > Along with these changes, I've also made some additional changes: > deprecating ListBearers() method and removing the redundant > --simple-status and --location-get-XXX actions. > > Worth noting: the original human-friendly output is more or less > maintained but it is NOT equal to the old one. Applications (e.g. the > openwrt integration) that were parsing that original output should > switch to the new key-value pair output. Do you have a before/after example of the tabular output? Dan > Comments welcome! > > $ mmcli -L -K > modem-list.length : 2 > modem-list.value[1] : /org/freedesktop/ModemManager1/Modem/0 > modem-list.value[2] : /org/freedesktop/ModemManager1/Modem/6 > > $ mmcli -m 0 -K > modem.dbus-path : > /org/freedesktop/ModemManager1/Modem/0 > modem.generic.device-identifier : > 1a48f1180f1fb0166d91f7b139d027136b59ba63 > modem.generic.manufacturer: Sierra Wireless Inc. > modem.generic.model : Sierra Wireless > EM7345 4G LTE > modem.generic.revision: > FIH7160_V1.1_MODEM_01.1349.12 > modem.generic.hardware-revision : > XMM7160_V1.1_MBIM_GNSS_NAND_RE > modem.generic.supported-capabilities.length : 1 > modem.generic.supported-capabilities.value[1] : gsm-umts, lte > modem.generic.current-capabilities.length : 1 > modem.generic.current-capabilities.value[1] : gsm-umts, lte > modem.generic.equipment-identifier: 013937003110648 > modem.generic.device : > /sys/devices/pci:00/:00:14.0/usb2/2-4 > modem.generic.drivers.length : 1 > modem.generic.drivers.value[1]: cdc_mbim > modem.generic.plugin : Sierra > modem.generic.primary-port: cdc-wdm0 > modem.generic.ports.length: 2 > modem.generic.ports.value[1] : cdc-wdm0 (mbim) > modem.generic.ports.value[2] : wwan0 (net) > modem.generic.own-numbers : -- > modem.generic.unlock-required : -- > modem.generic.unlock-retries.length : 1 > modem.generic.unlock-retries.value[1] : sim-pin (3) > modem.generic.state : connected > modem.generic.state-failed-reason : -- > modem.generic.power-state : on > modem.generic.access-technologies.length : 1 > modem.generic.access-technologies.value[1]: lte > modem.generic.signal-quality.value: 22 > modem.generic.signal-quality.recent : no > modem.generic.supported-modes.length : 1 > modem.generic.supported-modes.value[1]: allowed: 2g, 3g, 4g; > preferred: none > modem.generic.current-modes : allowed: 2g, 3g, 4g; > preferred: none > modem.generic.supported-bands : -- > modem.generic.current-bands : -- > modem.generic.supported-ip-families.length: 3 > modem.generic.supported-ip-families.value[1] : ipv4 > modem.generic.supported-ip-families.value[2] : ipv6 > modem.generic.supported-ip-families.value[3] : ipv4v6 > modem.3gpp.imei : 013937003110222 > modem.3gpp.enabled-locks.length : 1 > modem.3gpp.enabled-locks.value[1] : fixed-dialing > modem.3gpp.operator-code : 21407 > modem.3gpp.operator-name : Movistar > modem.3gpp.registration-state : home > modem.3gpp.eps-ue-mode-operation : -- > modem.3gpp.pco: -- > modem.cdma.meid : -- > modem.cdma.esn: -- > modem.cdma.sid: -- > modem.cdma.nid: -- > modem.cdma.cdma1x-registration-state : -- > modem.cdma.evdo-registration-state: -- > modem.cdma.activation-state : -- > modem.generic.sim : > /org/freedesktop/ModemManager1/SIM/0 > modem.generic.bearers.length : 1 > modem.generic.bearers.value[1]: > /org/freedesktop/ModemManager1/Bearer/0 > > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: MMCLI debug mode
On Wed, 2018-10-31 at 09:45 -0700, Srinivasan Jagannadhan wrote: > Thanks Dave! It connects with your suggestion. But there is no > IPAddr/Gateway assigned Ok, it looks like ModemManager is attempting to use PPP on the device because MM doesn't handle the Telit cdc-ncm ethernet-like interface that the modem provides. Ideally we'd like to use that interface, rather than PPP but that's unimplemented for now, it seems. But with your current setup, MM is waiting for you to start pppd on the data port to configure the IP details. Dan > root@localhost:/var/log/inode# mmcli -m 1 --simple-status > /org/freedesktop/ModemManager1/Modem/1 > - > Status | state: 'connected' > | signal quality: '85' (recent) > | bands: 'eutran-ii, eutran-iv, eutran-xiii' > |access tech: 'unknown' > - > 3GPP | registration: 'home' > | operator code: '311480' > | operator name: 'Verizon' > | subscription: 'unknown' > > > > root@localhost:/var/log/inode# mmcli -b 19 > Bearer '/org/freedesktop/ModemManager1/Bearer/19' > - > Status | connected: 'yes' > | suspended: 'no' > | interface: 'ttyACM0' > | IP timeout: '20' > - > Properties | apn: 'VZWINTERNET' > | roaming: 'allowed' > | IP type: 'ipv4v6' > |user: 'none' > |password: 'none' > | number: 'none' > | Rm protocol: 'unknown' > - > IPv4 configuration | method: 'ppp' > | address: 'unknown' > | prefix: '0' > | gateway: 'unknown' > | DNS: none > - > IPv6 configuration | method: 'ppp' > | address: 'unknown' > | prefix: '0' > | gateway: 'unknown' > | DNS: none > - > Stats | Duration: '180' > |Bytes received: 'N/A' > | Bytes transmitted: 'N/A' > > > root@localhost:/var/log/inode# mmcli -m 1 > > /org/freedesktop/ModemManager1/Modem/1 (device id > '3b7220ee774f413d7be53e974a94c04f89a8b2b8') > - > Hardware | manufacturer: 'Telit' >| model: 'LE910-SV V2' >| revision: '20.00.002' >| supported: 'gsm-umts, lte' >|current: 'gsm-umts, lte' >| equipment id: '351994070026033' > - > System | device: > '/sys/devices/pci:00/:00:14.0/usb1/1-4/1-4.1' >|drivers: 'cdc_acm, cdc_ncm' >| plugin: 'Dell' >| primary port: 'ttyACM0' >| ports: 'ttyACM3 (at), ttyACM4 (unknown), > ttyACM5 > (unknown), wwx11121314 (unknown), ttyACM0 (at), ttyACM1 > (unknown), > ttyACM2 (unknown)' > - > Numbers | own : '+14086051571' > - > Status | lock: 'none' >| unlock retries: 'sim-pin (3), sim-puk (10)' >| state: 'connected' >|power state: 'on' >|access tech: 'unknown' >| signal quality: '85' (recent) > - > Modes| supported: 'allowed: 4g; preferred: none' >|current: 'allowed: 4g; preferred: none' > - > Bands| supported: 'eutran-ii, eutran-iv, eutran-xiii' >|current: 'eutran-ii, eutran-iv, eutran-xiii' > - > IP | supported: 'ipv4, ipv6, ipv4v6' > - > 3GPP | imei: '351994070026033' >| enabled locks: 'none' >|operator id: '311480' >| operator name: 'Verizon' >| subscription: 'unknown' >| registration: 'home' > - > SIM | path: '/org/freedesktop/ModemManager1/SIM/1' > > - > Bearers | paths: > '/org/freedesktop/ModemManager1/Bearer/19' > > > Thanks > Srini > > On Wed, Oct 31, 2018 at 7:46 AM Dan Williams wrote: > > > On Wed, 2018-10-31 at 06:43 -0700, Srinivasan Jagannadhan wrote: >
Re: MMCLI debug mode
evice open > > count is 1 > > (close) > > Oct 31 13:37:01 localhost ModemManager[1988]: > > [1540993021.676515] > > [mm-base-bearer.c:578] connect_ready(): Couldn't connect bearer > > '/org/freedesktop/ModemManager1/Bearer/1': 'Operation not allowed' > > Oct 31 13:37:01 localhost ModemManager[1988]: > > [1540993021.677020] > > [mm-iface-modem.c:1431] __iface_modem_update_state_internal(): > > Modem > > /org/freedesktop/ModemManager1/Modem/1: state changed (connecting > > -> > > registered) > > Oct 31 13:37:01 localhost ModemManager[1988]: > > [1540993021.678607] > > [mm-iface-modem-simple.c:221] connect_bearer_ready(): Couldn't > > connect > > bearer: 'Operation not allowed' > > Oct 31 13:37:06 localhost ModemManager[1988]: > > [1540993026.719837] > > [mm-port-serial.c:1288] mm_port_serial_open(): (ttyACM0) device > > open count > > is 2 (open) > > Oct 31 13:37:06 localhost ModemManager[1988]: > > [1540993026.720165] > > [mm-port-serial-at.c:459] debug_log(): (ttyACM0): --> > > 'AT+CCLK?' > > Oct 31 13:37:06 localhost ModemManager[1988]: > > [1540993026.745426] > > [mm-port-serial-at.c:459] debug_log(): (ttyACM0): <-- '' > > Oct 31 13:37:06 localhost ModemManager[1988]: > > [1540993026.745738] > > [mm-port-serial-at.c:459] debug_log(): (ttyACM0): <-- '+CCLK: > > "18/10/31,06:37:12-28"OK' > > Oct 31 13:37:06 localhost ModemManager[1988]: > > [1540993026.746379] > > [mm-port-serial.c:1345] _close_internal(): (ttyACM0) device open > > count is 1 > > (close) > > > > > > On Wed, Oct 31, 2018 at 6:36 AM Dan Williams > > wrote: > > > > > On Wed, 2018-10-31 at 04:18 -0700, Srinivasan Jagannadhan wrote: > > > > I was trying to bringup Dell 5000 Gateway with > > > > 1) Modem: 'Telit model: 'LE910-SV V2' rev: '20.00.002' > > > > 2) Sim: Verizon > > > > > > > > Following were the commands executed > > > > 1. mmcli -m 0 -v --simple-connect="apn=VZWINTERNET" > > > > > > > > [31 Oct 2018, 11:11:10] [Debug] Forcing request to be run > > > > asynchronously > > > > [31 Oct 2018, 11:11:10] [Debug] Assuming '0' is the modem index > > > > [31 Oct 2018, 11:11:10] [Debug] ModemManager process found at > > > > ':1.3' > > > > [31 Oct 2018, 11:11:10] [Debug] Modem found at > > > > '/org/freedesktop/ModemManager1/Modem/0' > > > > > > > > [31 Oct 2018, 11:11:10] [Debug] Asynchronously connecting the > > > > modem... > > > > error: couldn't connect the modem: > > > > 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipmen > > > > t.NotA > > > > llowed: > > > > Operation not allowed' > > > > > > > > 2. /var/log/syslog > > > > Oct 31 11:01:54 localhost ModemManager[804]: Modem > > > > /org/freedesktop/ModemManager1/Modem/0: state changed (disabled > > > > -> > > > > enabling) > > > > > > ModemManager debug logging would be useful here. You can enable > > > that > > > with "mmcli --set-logging=DEBUG" and then reproduce the > > > issue. Then > > > /var/log/syslog will contain quite a bit more information that we > > > can > > > use to debug the problem. > > > > > > Thanks! > > > Dan > > > > > > > > > > Oct 31 11:01:55 localhost ModemManager[804]: Modem > > > > /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state > > > > changed > > > > (unknown -> registering) > > > > Oct 31 11:01:55 localhost ModemManager[804]: Modem > > > > /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state > > > > changed > > > > (registering -> home) > > > > Oct 31 11:01:55 localhost ModemManager[804]: Modem > > > > /org/freedesktop/ModemManager1/Modem/0: state changed (enabling > > > > -> > > > > registered) > > > > Oct 31 11:01:55 localhost ModemManager[804]: Simple > > > > connect > > > > started... > > > > Oct 31 11:01:55 localhost ModemManager[804]: Simple > > > > connect > > > > state > > > > (4/8): Wait to get fully enabled > > > > Oct 31 11:01:55 localhost ModemManager[804]: Simple > > > > connect > > > > state > > > > (5/8): Register > > > > O
Re: MMCLI debug mode
On Wed, 2018-10-31 at 04:18 -0700, Srinivasan Jagannadhan wrote: > I was trying to bringup Dell 5000 Gateway with > 1) Modem: 'Telit model: 'LE910-SV V2' rev: '20.00.002' > 2) Sim: Verizon > > Following were the commands executed > 1. mmcli -m 0 -v --simple-connect="apn=VZWINTERNET" > > [31 Oct 2018, 11:11:10] [Debug] Forcing request to be run > asynchronously > [31 Oct 2018, 11:11:10] [Debug] Assuming '0' is the modem index > [31 Oct 2018, 11:11:10] [Debug] ModemManager process found at ':1.3' > [31 Oct 2018, 11:11:10] [Debug] Modem found at > '/org/freedesktop/ModemManager1/Modem/0' > > [31 Oct 2018, 11:11:10] [Debug] Asynchronously connecting the > modem... > error: couldn't connect the modem: > 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.NotA > llowed: > Operation not allowed' > > 2. /var/log/syslog > Oct 31 11:01:54 localhost ModemManager[804]: Modem > /org/freedesktop/ModemManager1/Modem/0: state changed (disabled -> > enabling) ModemManager debug logging would be useful here. You can enable that with "mmcli --set-logging=DEBUG" and then reproduce the issue. Then /var/log/syslog will contain quite a bit more information that we can use to debug the problem. Thanks! Dan > Oct 31 11:01:55 localhost ModemManager[804]: Modem > /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state > changed > (unknown -> registering) > Oct 31 11:01:55 localhost ModemManager[804]: Modem > /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state > changed > (registering -> home) > Oct 31 11:01:55 localhost ModemManager[804]: Modem > /org/freedesktop/ModemManager1/Modem/0: state changed (enabling -> > registered) > Oct 31 11:01:55 localhost ModemManager[804]: Simple connect > started... > Oct 31 11:01:55 localhost ModemManager[804]: Simple connect > state > (4/8): Wait to get fully enabled > Oct 31 11:01:55 localhost ModemManager[804]: Simple connect > state > (5/8): Register > Oct 31 11:01:55 localhost ModemManager[804]: Simple connect > state > (6/8): Bearer > Oct 31 11:01:55 localhost ModemManager[804]: Simple connect > state > (7/8): Connect > Oct 31 11:01:55 localhost ModemManager[804]: Modem > /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> > connecting) > Oct 31 11:01:55 localhost ModemManager[804]: Couldn't > initialize > PDP context with our APN: 'Operation not allowed' > Oct 31 11:01:55 localhost ModemManager[804]: Modem > /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> > registered) > Oct 31 11:11:10 localhost ModemManager[804]: Simple connect > started... > Oct 31 11:11:10 localhost ModemManager[804]: Simple connect > state > (4/8): Wait to get fully enabled > Oct 31 11:11:10 localhost ModemManager[804]: Simple connect > state > (5/8): Register > Oct 31 11:11:10 localhost ModemManager[804]: Simple connect > state > (6/8): Bearer > Oct 31 11:11:10 localhost ModemManager[804]: Simple connect > state > (7/8): Connect > Oct 31 11:11:10 localhost ModemManager[804]: Modem > /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> > connecting) > Oct 31 11:11:10 localhost ModemManager[804]: Couldn't > initialize > PDP context with our APN: 'Operation not allowed' > > Questions: > 1. Does this require explicit AT commands to be passed through MMCLI? > 2. What AT Commands to must be used? > 3. How do we compile MMCLI in debug mode to issue AT Commands? > > Thanks > -Srini- > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: System Daemon or DBus activated service?
On Wed, 2018-10-31 at 15:37 +0800, Jonathan Kang wrote: > Hi Dan > > On Wed, Oct 31, 2018 at 12:39 AM Dan Williams > wrote: > > > On Tue, 2018-10-30 at 12:42 +0100, Aleksander Morgado wrote: > > > Hey! > > > > > > > According to this[1], it says > > > > > ModemManager is a system daemon > > > > > > > > and > > > > > ModemManager is a DBus system bus activated service (meaning > > > > > it's > > > > > started automatically when a request arrives). > > > > > > > > A system daemon means that MM is running all the time. Doesn't > > > > that > > > > conflict with DBus activated service? Besides, can ModemManager > > > > quit when let's say, it's not needed, just like what PackageKit > > > > does. Is it possible? > > > > > > > > *[1] https://www.freedesktop.org/software/ModemManager/api/late > > > > st/r > > > > ef-overview-introduction.html > > > > > > > > > > This depends on how the system works. In the pre-systemd setups > > > MM > > > was > > > DBus-activated by NetworkManager on boot, but in all new setups > > > using > > > systemd the ModemManager process is managed via a systemd service > > > so > > > the lifecycle of the process is that of a system daemon. It would > > > probably be wise to stop talking about DBus activation for MM I > > > assume, we should update the docs. > > > > Yeah. Also in the pre-systemd world, NM needed to start MM very > > early > > to detect modems anyway. So it was effectively a system daemon, > > just > > that it wasn't started by a SYSV initscript or upstart job or > > whatever. > > > > > > The ideal system would be that MM would be started whenever certain > > hardware was inserted (or cold-detected), eg whenever any device > > driven > > by cdc-acm, qmi_wwan, cdc-mbim, cdc-wdm, sierra, qcserial, etc was > > found by the kernel. MM would run and if it found a modem would > > keep > > running, otherwise it would quit. > > > This sounds quite promising. Yeah, it's the ideal, but for various reasons it's a bunch of work for somewhat minimal benefit. > > > But reality is that this is too > > complicated to get reliably correct, and clients (NetworkManager, > > mmcli, etc) can't distinguish between "MM couldn't find any modems > > and > > quit" and "MM wasn't started at all due to misconfiguration". > > > > PackageKit somehow manage this, maybe that's because they provide > > libraries instead of DBus Calls? PackageKit doesn't deal with hardware though, which is the big difference. Yes, all the issues can be worked around, it just takes effort that (I personally) would rather put into making modems themselves work better. But I'd certainly be happy if somebody else looked into the MM lifecycle and posted improvements. Dan > - Jonathan > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: System Daemon or DBus activated service?
On Tue, 2018-10-30 at 12:42 +0100, Aleksander Morgado wrote: > Hey! > > > According to this[1], it says > > > ModemManager is a system daemon > > > > and > > > ModemManager is a DBus system bus activated service (meaning it's > > > started automatically when a request arrives). > > > > A system daemon means that MM is running all the time. Doesn't that > > conflict with DBus activated service? Besides, can ModemManager > > quit when let's say, it's not needed, just like what PackageKit > > does. Is it possible? > > > > *[1] https://www.freedesktop.org/software/ModemManager/api/latest/r > > ef-overview-introduction.html > > > > This depends on how the system works. In the pre-systemd setups MM > was > DBus-activated by NetworkManager on boot, but in all new setups using > systemd the ModemManager process is managed via a systemd service so > the lifecycle of the process is that of a system daemon. It would > probably be wise to stop talking about DBus activation for MM I > assume, we should update the docs. Yeah. Also in the pre-systemd world, NM needed to start MM very early to detect modems anyway. So it was effectively a system daemon, just that it wasn't started by a SYSV initscript or upstart job or whatever. The ideal system would be that MM would be started whenever certain hardware was inserted (or cold-detected), eg whenever any device driven by cdc-acm, qmi_wwan, cdc-mbim, cdc-wdm, sierra, qcserial, etc was found by the kernel. MM would run and if it found a modem would keep running, otherwise it would quit. But reality is that this is too complicated to get reliably correct, and clients (NetworkManager, mmcli, etc) can't distinguish between "MM couldn't find any modems and quit" and "MM wasn't started at all due to misconfiguration". Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: TOBY-L210 does not detected by ModemManager deamon at boot time
On Mon, 2018-10-29 at 17:27 +0100, Aleksander Morgado wrote: > Hey, > > > > -Original Message- > > > From: Aleksander Morgado > > > Sent: Monday, October 29, 2018 9:48 AM > > > To: Baryshnikov, Maxim (Digiteq Automotive) > > > ; modemmanager- > > > de...@lists.freedesktop.org > > > Subject: Re: TOBY-L210 does not detected by ModemManager deamon > > > at boot > > > time > > > > > > On 10/23/18 8:19 PM, Baryshnikov, Maxim (Digiteq Automotive) > > > wrote: > > > > Hello all, > > > > I'm struggling with the following issue. On my > > > > system, the > > > > > > ModemManager (1.8.2) cannot detect TOBY-L2 modem at boot time. I > > > have > > > allowed all "filter rules", but the situation is the same as for > > > the default rules set. > > > However, if I manually reset the modem with detaching it from the > > > system (send > > > AT+CFUN=16 to it), the ModemManager successfully detects it. > > > > ModemManager is compiled with --without-mbim and > > > > -without-qmi, but > > > > > > there should be no influence on detection, I guess.. > > > > Do you have any ideas what to check to solve this? > > > > Is there something > > > > > > wrong with udev? Thank you in advance for any piece of > > > information.. > > > > Kind regards, > > > > > > How are you sending AT+CFUN=16 to the modem while ModemManager is > > > running? Please understand that no other program can be using the > > > TTY port if you > > > expect ModemManager to use it. Maybe you have a minicom session > > > open while > > > MM should be probing the port at the same time? > > > > I don't think that this is happenning at the boot time. I've found > > a workaround - to retrigger udev event on my device right after the > > ModemManager service starts. > > > > ExecStart=@sbindir@/ModemManager > > ExecStartPost=/bin/udevadm trigger > > /sys/devices/soc0/amba/e0002000.usb/ci_hdrc.0/usb1/1-1/1-1.2 > > > > > > > Without looking at the ModemManager debug log it's hard to say > > > what's really > > > happening. Could you get it? > > > https://www.freedesktop.org/wiki/Software/ModemManager/Debugging/ > > > > I've found nothing much interesting there, it just does not probe > > ttyACM ports without having an udev event detected first.. > > > > Oct 29 09:30:54 zynq7 ModemManager[179]: > > [1540805454.220980] (tty/ttyACM0): adding device at sysfs path: > > /sys/devices/soc0/amba/e0002000.usb/ci_hdrc.0/usb1/1-1/1-1.2/1- > > 1.2:1.2/tty/ttyACM0 > > Oct 29 09:30:54 zynq7 ModemManager[179]: > > [1540805454.221302] (tty/ttyACM0): port not candidate > > Oct 29 09:30:54 zynq7 ModemManager[179]: > > [1540805454.221565] (tty/ttyACM1): adding device at sysfs path: > > /sys/devices/soc0/amba/e0002000.usb/ci_hdrc.0/usb1/1-1/1-1.2/1- > > 1.2:1.2/tty/ttyACM1 > > Oct 29 09:30:54 zynq7 ModemManager[179]: > > [1540805454.221874] (tty/ttyACM1): port not candidate > > Oct 29 09:30:54 zynq7 ModemManager[179]: > > [1540805454.222126] (tty/ttyACM2): adding device at sysfs path: > > /sys/devices/soc0/amba/e0002000.usb/ci_hdrc.0/usb1/1-1/1-1.2/1- > > 1.2:1.2/tty/ttyACM2 > > Oct 29 09:30:54 zynq7 ModemManager[179]: > > [1540805454.222410] (tty/ttyACM2): port not candidate > > > > That is probably a problem in udev on my system. It behaves wierd.. > > > > That totally looks like some udev related issue indeed. The "port not > candidate" logs will happen if the ttyACM ports aren't flagged with > ID_MM_CANDIDATE, which is one of the tags added by the ModemManager > udev rules in /lib/udev/rules.d/. When the system boots and udev > detects the devices, the rules should be executed and the tag added, > and for some reason that is not happening in this setup. udevadm control --log-priority=debug and replug the device will let you see what udev is doing and why certain ports may/may not be getting tagged correctly. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [PATCH] ublox: fix username and password passed to +UAUTHREQ
On Fri, 2018-10-26 at 10:59 -0700, Ben Chan wrote:
> ---
> plugins/ublox/mm-broadband-bearer-ublox.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
LGTM
> diff --git a/plugins/ublox/mm-broadband-bearer-ublox.c
> b/plugins/ublox/mm-broadband-bearer-ublox.c
> index 1adcaa26..76f307c8 100644
> --- a/plugins/ublox/mm-broadband-bearer-ublox.c
> +++ b/plugins/ublox/mm-broadband-bearer-ublox.c
> @@ -457,8 +457,8 @@ out:
> cmd = g_strdup_printf ("+UAUTHREQ=%u,%u,%s,%s",
> ctx->cid,
> ublox_auth,
> - quoted_password,
> - quoted_user);
> + quoted_user,
> + quoted_password);
>
> g_free (quoted_user);
> g_free (quoted_password);
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager-devel Digest, Vol 64, Issue 19
On Tue, 2018-10-02 at 07:45 -0400, Michael pang wrote: > do you mind sharing how to ask modemmanager for IP? Is it automated > process? Thank you. Each network connection has a corresponding "bearer" object, which you ask for IP details. mmcli -m 0 --list-bearers (usually there will only be one) mmcli -b and that will print out the IP information. Dan > On Mon, Oct 1, 2018 at 10:10 PM Dan Williams wrote: > > > On Sun, 2018-09-30 at 20:39 -0400, Michael pang wrote: > > > I did create one network interface named broadband according to > > > the > > > website. I am missing the DHCP client network interface. My > > > EM7455 > > > is in > > > MBIM mode. Does that matter? After I created two interface, still > > > > MBIM mode does not support DHCP. Instead, you'd ask ModemManager > > for > > the IP information (which it retrieves from the modem via MBIM) or > > query the IP info directly with mbimcli and set the info on the net > > interface directly. > > > > Dan > > > > > same > > > problem. I did notice some message in system log. Thank you for > > > your > > > help. > > > This is my first time compile openwrt package with modemmanager. > > > Sun Sep 30 20:30:03 2018 daemon.notice netifd: broadband (2089): > > > Device not > > > found in sysfs > > > Sun Sep 30 20:30:03 2018 kern.info kernel: [ 13.878492] IPv6: > > > ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > > Sun Sep 30 20:30:03 2018 kern.info kernel: [ 13.885034] IPv6: > > > ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready > > > Sun Sep 30 20:30:03 2018 daemon.notice netifd: wan (2124): > > > udhcpc: > > > started, > > > v1.28.3 > > > Sun Sep 30 20:30:03 2018 daemon.notice netifd: broadband (2140): > > > stopping > > > network > > > Sun Sep 30 20:30:03 2018 daemon.notice netifd: wwan (2164): > > > udhcpc: > > > started, v1.28.3 > > > Sun Sep 30 20:30:03 2018 daemon.notice netifd: broadband (2140): > > > error: > > > couldn't get bus: Could not connect: No such file or directory > > > Sun Sep 30 20:30:03 2018 daemon.notice netifd: broadband (2140): > > > couldn't > > > load bearer path > > > Sun Sep 30 20:30:03 2018 daemon.notice netifd: Interface > > > 'broadband' > > > is now > > > down > > > > > > On Sun, Sep 30, 2018 at 7:33 PM Nick wrote: > > > > > > > Did you set up the appropriate network interfaces in > > > > /etc/config/network? > > > > You need one for the modem, which uses the modemmanager > > > > protocol, > > > > and one > > > > DHCP client interface which gets the IP from the modemmanager > > > > interface > > > > after it connects to the cellular network. Check alexander0m’s > > > > bitbucket > > > > profile with the modemmanager-openwrt repository, there is an > > > > example > > > > config there. After you get that all set up, assuming your > > > > wwan0 > > > > interface > > > > is in raw_ip mode, which I think is required for 7455’s in QMI > > > > mode, then > > > > you should simply be able to connect using ifup broadband && > > > > ifup > > > > wwan. > > > > > > > > > > > > Best, > > > > > > > > Nicholas > > > > > > > > > On 30 Sep 2018, at 22:00, > > > > > > > > modemmanager-devel-requ...@lists.freedesktop.org wrote: > > > > > > > > > > Send ModemManager-devel mailing list submissions to > > > > > modemmanager-devel@lists.freedesktop.org > > > > > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > > https://lists.freedesktop.org/mailman/listinfo/modemman > > > > > ager > > > > > -devel > > > > > or, via email, send a message with subject or body 'help' to > > > > > modemmanager-devel-requ...@lists.freedesktop.org > > > > > > > > > > You can reach the person managing the list at > > > > > modemmanager-devel-ow...@lists.freedesktop.org > > > > > > > > > > When replying, please edit your Subject line so it is more > > > > > specific > > > > > than "Re: Contents of ModemManager-devel digest..." > > &g
Re: [review v2] Voice implementation fixes (with audio channel setup handlers)
On Fri, 2018-08-10 at 15:31 +0200, Aleksander Morgado wrote: > Hey Dan, Bob & all, > > I've updated the "aleksander/voice-fixes" branch to include the > "AT^CVOICE based support for Huawei modems that Dan worked on a while > ago in his "dcbw/huawei-voice" branch. > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/2 This is now merged. Dan > The Huawei USB dongles that support voice require a command > (AT^DDSETEX=2) to be executed when the call is established, and also > need to report which port is being used for audio. In order to > support > that, instead of subclassing all start/accept/hangup methods, I > extended the MMBaseCall class with two new handlers that allow > setting > up and cleaning up the audio channel however the plugin needs it. > Bob, > you could use these two methods for the custom AT commands you > require > for the SIMCom implementation, right? > > Dan's original changes also include support for reporting which port > and which audio format to use in the call, so plugins may use that to > report to upper layers that required information. Instead of updating > that information within the Huawei implementation, that is now > managed > by the base call object. > > Not all Huawei modems require all this setup with CVOICE and the > port/format reporting, as the original voice implementation didn't > require it, so it has been made optional. > > I have NOT tested this Huawei logic though, still need to find a > device that can work in that way. Dan could you give it a try > yourself? :) Also, once you have the audio TTY setup, how do you make > that audio port work in the PC? Maybe we should add some explanation > for that in the API? > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] Voice implementation fixes
On Tue, 2018-10-16 at 12:10 -0500, Dan Williams wrote: > On Fri, 2018-06-15 at 01:05 +0200, Aleksander Morgado wrote: > > Hey, > > > > I've pushed a branch to gitlab for review: > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_ > > re > > quests/2 > > > > It includes several fixed and improvements in the voice API > > implementation for generic and huawei modems. I've been able to > > validate and test all APIs successfully now with a u-blox TOBY-L4. > > Merged. Well, to be precise, the "v2" version with audio setup stuff got merged. Same MR though. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] Voice implementation fixes
On Fri, 2018-06-15 at 01:05 +0200, Aleksander Morgado wrote: > Hey, > > I've pushed a branch to gitlab for review: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/2 > > It includes several fixed and improvements in the voice API > implementation for generic and huawei modems. I've been able to > validate and test all APIs successfully now with a u-blox TOBY-L4. Merged. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [PATCH] sim-qmi: avoid unnecessary MM_SIM_QMI() call on MMSimQmi object
On Wed, 2018-10-10 at 23:11 -0700, Ben Chan wrote:
> ---
> src/mm-sim-qmi.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
LGTM
> diff --git a/src/mm-sim-qmi.c b/src/mm-sim-qmi.c
> index 725e073e..e8c0afef 100644
> --- a/src/mm-sim-qmi.c
> +++ b/src/mm-sim-qmi.c
> @@ -449,7 +449,7 @@ uim_verify_pin (MMSimQmi *self,
> QmiClient *client = NULL;
>
> if (!ensure_qmi_client (task,
> -MM_SIM_QMI (self),
> +self,
> QMI_SERVICE_UIM, ))
> return;
>
> @@ -504,7 +504,7 @@ dms_uim_verify_pin (MMSimQmi *self,
> QmiClient *client = NULL;
>
> if (!ensure_qmi_client (NULL,
> -MM_SIM_QMI (self),
> +self,
> QMI_SERVICE_DMS, )) {
> /* Very unlikely that this will ever happen, but anyway, try
> with
> * UIM service instead */
> @@ -605,7 +605,7 @@ uim_unblock_pin (MMSimQmi *self,
> UnblockPinContext *ctx;
>
> if (!ensure_qmi_client (task,
> -MM_SIM_QMI (self),
> +self,
> QMI_SERVICE_UIM, ))
> return;
>
> @@ -664,7 +664,7 @@ dms_uim_unblock_pin (MMSimQmi *self,
> UnblockPinContext *ctx;
>
> if (!ensure_qmi_client (NULL,
> -MM_SIM_QMI (self),
> +self,
> QMI_SERVICE_DMS, )) {
> /* Very unlikely that this will ever happen, but anyway, try
> with
> * UIM service instead */
> @@ -772,7 +772,7 @@ uim_change_pin (MMSimQmi *self,
> ChangePinContext *ctx;
>
> if (!ensure_qmi_client (task,
> -MM_SIM_QMI (self),
> +self,
> QMI_SERVICE_UIM, ))
> return;
>
> @@ -831,7 +831,7 @@ dms_uim_change_pin (MMSimQmi *self,
> ChangePinContext *ctx;
>
> if (!ensure_qmi_client (NULL,
> -MM_SIM_QMI (self),
> +self,
> QMI_SERVICE_DMS, )) {
> /* Very unlikely that this will ever happen, but anyway, try
> with
> * UIM service instead */
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Configuration for Quectel 3G and 4G modem
On Mon, 2018-10-15 at 17:28 +1100, Brendan Simon (eTRIX) wrote: > I have a linux filesystem (Debian based) for an embedded board which > uses a Quectel UC20 3G modem via NetworkManager/ModemManager. > > I want to upgrade to use a Quectel EC21 4G modem and want to know if > I > can use the same "system-connections" configuration file for both > modems. e.g. so that same software can run on new and old hardware - > or > do I have to have separate config/connection files for each modem? This connection file looks fine for both modems. NetworkManager allows the file to apply to any device of the type unless it is explicitly restricted to a specific device, which this one is not because it doesn't have the 'device-id' and/or 'sim-id' keys in the [gsm] section. > > My 3G configuration looks like this: > > id=telstra-mobile-broadband-1 > uuid=---- > type=gsm > permissions=user:root:; > autoconnect=true > > [gsm] > number=*99# > password-flags=1 > apn-telstra.extranet > > [ipv4] > method=auto > > [serial] > baud=115200 > > > Should this same config file work with a 4G modem (EC21) ? Yes. > Can I have the one configuation file that will work on 4G and 3G > (e.g. > if only 3G is available). I'm *assuming* yes. If so, how to > configure it. This file should work on both 3G & 4G, because the modem will actually determine which of the two access technologies it wants to use and when it wants to switch between them based on coverage and signal. You almost never need to bother thinking about specific access technologies. > And 3G fallback also. Is there anything special I need to do in > configuration, or will ModemManager just wield its magic. That's actually all done inside the modem itself and mostly transparent to ModemManager and NetworkManager. (yes, you can tell the modem to prefer a specific access technology, but that's an unusual case and very few need to do that.) Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: MC7750 missing SIM until ModemManager restart
On Thu, 2018-10-11 at 00:37 +0200, Aleksander Morgado wrote: > On Thu, Oct 11, 2018 at 12:32 AM Bowden, Brendan m> wrote: > > > > > > > >Out of curiosity, have you tried different SIM cards? > > >Also, is the firmware you're using the latest one available > > > for the MC7750? > > > > > > > Multiple SIM cards on multiple machines are acting the same way. We > > were originally running FW 3.5.10.6; behavior didn't change going > > to the last available FW 3.5.10.13. > > > > Ok, then the optional recheck loop, as we do for MBIM modems, could > help here. > Tracking it here: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/8 > 9 I don't recall ever seeing this issue with my MC7750, but it's been at least a year or so since I tried it. My VZW SIMs were all from the 2010 - 2012 timeframe though, perhaps newer SIMs are different and have some effect here. We've had that kind of problem before, where newer SIMs interact badly with older firmware (Icera devices and ISIS-enabled SIMs). Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: The loading order of plugins
On Mon, 2018-10-08 at 18:16 +0200, Aleksander Morgado wrote: > Hey, > > > I'm now working on a modem "Cinterion Gemalto ELS61". And I tried > > to use it with ModemManager. > > ModemManager suggests the "Cinterion" plugin. But somehow, the AT > > command set and some response message format of "Cinterion Gemalto > > ELS61" is different from other modems supported by the "Cinterion" > > plugin. So I wrote a plugin named "G-ELS61" especially for it. > > > > The question is, both "Cinterion" plugin and "G-ELS61" plugin > > support modem "Cinterion Gemalto ELS61". ModemManager will select > > the prior loaded plugin as best-plugin. > > While the order of loading plugins is not fixed in ModemManager > > (Since "readdir()" returns entries in the order that files are > > linked in filesystem). That means ModemManager may use different > > plugin for the same modem on different devices. > > > > Currently, I use a simple workaround to solve the issue. I sort the > > loading order by the plugins' filename before loading. So that I > > can control the loading order of my plugin by its filename. The > > diff log is attached below: > > > > Plugins can say "I don't support this specific device", and so in > your > case you could update the Cinterion plugin so that the specific > vid:pid is listed in MM_PLUGIN_FORBIDDEN_PRODUCT_IDS, and then the > order of loading of plugins is irrelevant, see: > https://www.freedesktop.org/software/ModemManager/api/latest/ref-over > view-modem-port-probing.html#id-1.2.5.4. > > BUT, why is it that the modem cannot be supported by the Cinterion > plugin? Which are the commands that are different? Can the Cinterion > plugin not be updated to support this new model as well? If it helps to figure that out: https://developer.gemalto.com/sites/default/files/els61-e2_atc_01000.pdf Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: bearer mbim: ipv6_config set to dhcp when no ipv6 is available
On Fri, 2018-10-05 at 11:39 +0200, Andreas Fett wrote: > Hi list, > > I noticed, that in ip_configuration_query_ready() ipv6_config will be > allocated and method will be set to MM_BEARER_IP_METHOD_DHCP even > when > ipv6configurationavailable is false, just based on the value of > ctx->ip_type. > > So essentially every bearer which was *configured* with ip_type v6 or > v4+v6 before connecting will report that v6 may be available via > SLACC. > This is even the case when the mbim ip configuration response > explicitly > says that no ipv6 is available. > > Is this intentional or should I submit a patch that takes the > information from the mbim message into consideration when reporting > the > ip6_config? I could be mis-remembering, but I don't think this was intentional and if MBIM says IPv6 isn't available, then MM shouldn't say it's available either. Bjorn or Aleksander, do you have more experience here that you could share? Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager-devel Digest, Vol 64, Issue 19
On Sun, 2018-09-30 at 20:39 -0400, Michael pang wrote: > I did create one network interface named broadband according to the > website. I am missing the DHCP client network interface. My EM7455 > is in > MBIM mode. Does that matter? After I created two interface, still MBIM mode does not support DHCP. Instead, you'd ask ModemManager for the IP information (which it retrieves from the modem via MBIM) or query the IP info directly with mbimcli and set the info on the net interface directly. Dan > same > problem. I did notice some message in system log. Thank you for your > help. > This is my first time compile openwrt package with modemmanager. > Sun Sep 30 20:30:03 2018 daemon.notice netifd: broadband (2089): > Device not > found in sysfs > Sun Sep 30 20:30:03 2018 kern.info kernel: [ 13.878492] IPv6: > ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > Sun Sep 30 20:30:03 2018 kern.info kernel: [ 13.885034] IPv6: > ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready > Sun Sep 30 20:30:03 2018 daemon.notice netifd: wan (2124): udhcpc: > started, > v1.28.3 > Sun Sep 30 20:30:03 2018 daemon.notice netifd: broadband (2140): > stopping > network > Sun Sep 30 20:30:03 2018 daemon.notice netifd: wwan (2164): udhcpc: > started, v1.28.3 > Sun Sep 30 20:30:03 2018 daemon.notice netifd: broadband (2140): > error: > couldn't get bus: Could not connect: No such file or directory > Sun Sep 30 20:30:03 2018 daemon.notice netifd: broadband (2140): > couldn't > load bearer path > Sun Sep 30 20:30:03 2018 daemon.notice netifd: Interface 'broadband' > is now > down > > On Sun, Sep 30, 2018 at 7:33 PM Nick wrote: > > > Did you set up the appropriate network interfaces in > > /etc/config/network? > > You need one for the modem, which uses the modemmanager protocol, > > and one > > DHCP client interface which gets the IP from the modemmanager > > interface > > after it connects to the cellular network. Check alexander0m’s > > bitbucket > > profile with the modemmanager-openwrt repository, there is an > > example > > config there. After you get that all set up, assuming your wwan0 > > interface > > is in raw_ip mode, which I think is required for 7455’s in QMI > > mode, then > > you should simply be able to connect using ifup broadband && ifup > > wwan. > > > > > > Best, > > > > Nicholas > > > > > On 30 Sep 2018, at 22:00, > > > > modemmanager-devel-requ...@lists.freedesktop.org wrote: > > > > > > Send ModemManager-devel mailing list submissions to > > > modemmanager-devel@lists.freedesktop.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://lists.freedesktop.org/mailman/listinfo/modemmanager > > > -devel > > > or, via email, send a message with subject or body 'help' to > > > modemmanager-devel-requ...@lists.freedesktop.org > > > > > > You can reach the person managing the list at > > > modemmanager-devel-ow...@lists.freedesktop.org > > > > > > When replying, please edit your Subject line so it is more > > > specific > > > than "Re: Contents of ModemManager-devel digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Openwrt with EM7455 connecting issue (Michael pang) > > > > > > > > > --- > > > --- > > > > > > Message: 1 > > > Date: Sat, 29 Sep 2018 21:30:13 -0400 > > > From: Michael pang > > > To: modemmanager-devel@lists.freedesktop.org > > > Subject: Openwrt with EM7455 connecting issue > > > Message-ID: > > >> > > ahmz0h...@mail.gmail.com> > > > Content-Type: text/plain; charset="utf-8" > > > > > > Hello > > > I am using OpenWrt 18.06.1 r7258-5eb055306f on linksys > > > AC1900V2 > > > router. EM7455 Generic firmware with M.2 usb enclosure and > > > modemmanager > > > 1.8.2. I followed instruction on your website to compile the > > > package. > > > > But I > > > can't get any connection. I have to issue 3 commands in order to > > > get IP > > > address(no internet though). Did I do something wrong during the > > > compiling process? Thank you. > > > > > > mmcli -e -m 0 > > > mmcli -m 0 --create-bearer="apn=Broadband" > > > mmcli -c -b 0 > > > -- next part -- > > > An HTML attachment was scrubbed... > > > URL: < > > > > https://lists.freedesktop.org/archives/modemmanager-devel/attachmen > > ts/20180929/6bc4f5f3/attachment-0001.html > > > > > > > > > -- > > > > > > Subject: Digest Footer > > > > > > ___ > > > ModemManager-devel mailing list > > > ModemManager-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel > > > > > > > > > -- > > > > > > End of ModemManager-devel Digest, Vol 64, Issue 19 > > > ** > > > > > > ___ > ModemManager-devel mailing list >
Re: HP lt4120 failing to make single-stack connections on LTE using MM
On Fri, 2018-09-07 at 09:26 +0200, Bjørn Mork wrote: > Dan Williams writes: > > > Not sure this does exactly what we want though, as the Telit xN930 > > documentation for CID_MODEM_REBOOT says: > > > > "This command reboots the device into firmware update mode. After > > the > > command is sent the device shuts down and reboots in firmware > > update > > mode." > > Ah, didn't know that. Thanks. No, that's definitely not something > we'd > want for a normal "reset" operation. > > There's one of the problems trying to figure out stuff by observing > behaviour: It's easy to miss important details. I am pretty sure my > modem rebooted and ended up running the already installed application > firmware. But I might have missed a delay where it waited for > firmware > update. And that timeout could very well be specific to the > vendor/modem/firmware, so it's not something to depend on But it might be useful to use CID_MODEM_REBOOT on a case-by-case basis where we know it'll just restart into the existing firmware. I didn't mean to say we *shouldn't* use it, just that we should be careful :) Dan > And I had completely forgotten about the xN930 docs, which I see that > I > also have. Should read more of that and less of my own experimental > notes ;-) > > > > Bjørn > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: HP lt4120 failing to make single-stack connections on LTE using MM
On Thu, 2018-09-06 at 11:02 +0200, Aleksander Morgado wrote: > On Thu, Sep 6, 2018 at 10:46 AM, Bjørn Mork wrote: > > Aleksander Morgado writes: > > > > > Oh wait, this is a Intel based MBIM modem, right? If so, we need > > > AT-based reset operations. I believe I still have the HPlt4120 > > > around > > > here, will try to implement that. Tracking it here: > > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issu > > > es/86 > > > > Don't know if we've discussed this before, but based on testing > > with the > > EM7345 and looking at the Windows stuff, I believe it supports a > > vendor > > MBIM service usable for reset: > > > > UUID_FWUSVC => UNKNOWN (0ed374cb-f835-4474-bc11-3b3fd76f5641) > > DssPayload: 0x > > MaxDssInstances:0 > > CidCount: 1 > > CidList:1 > >CID_MODEM_REBOOT(1) > > > > > > My notes are a bit sketchy as always, and the modem is stowed away, > > but > > I believe that was the only CID of that service and that it only > > supported SET requests. With immediate modem reset as a result. > > > > Ah, even better, thanks for the pointer :) > https://gitlab.freedesktop.org/mobile-broadband/libmbim/issues/3 Not sure this does exactly what we want though, as the Telit xN930 documentation for CID_MODEM_REBOOT says: "This command reboots the device into firmware update mode. After the command is sent the device shuts down and reboots in firmware update mode." Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review v2] New 'fibocom' plugin (with a new Intel XMM modem class)
On Wed, 2018-08-08 at 17:14 +0200, Aleksander Morgado wrote: > > > > > > I've now pushed an updated MR to suggest the Fibocom plugin, this > > > time > > > including a new "Icera-like" Intel XMM chipset detection. If the > > > modem > > > is found to be based on Intel XMM, supporting the "AT+X.." > > > commands, > > > then we will use them for things like mode switching. This > > > updated MR > > > includes mode/band selection as well as additional power related > > > operations like "off" or "reset". > > > > > > The new XMM-specific operations are implemented in a > > > "MMSharedXmm" > > > interface, which is used by both the MMBroadbandXmm and > > > MMBroadbandMbimXmm objects. > > > > > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merg > > > e_requests/12 > > > > > > Comments? > > > > IIRC, Huawei ME936 is based on Intel XMM7160, but implements a > > different set of AT commands that align mostly with other Huawei > > modems. If you have such a modem, you may want to check if those > > AT+X* > > commands exist and behave as expected. I may be able to find one > > to > > test and will let you know. > > > > u-blox also does basically the same thing, they're based on Intel XMM > modems but they provide custom AT commands on top (e.g. UACT and URAT > instead of XACT, or UCALLSTAT instead of XCALLSTAT). This generic XMM > implementation could be applied to all modems that don't provide > customized AT commands instead of the original Intel AT+X commands. Merged to git master, FWIW. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] USSD support for MBIM
On Wed, 2018-08-08 at 17:18 +0200, Aleksander Morgado wrote: > Hey, > > This MR adds USSD support for MBIM devices, and while at it, also > ported the original MMBroadbandModem USSD support to GTask: > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/23 > > The MBIM USSD logic basically matches what we had for the AT+CUSD > based logic. The main difference being that the actual strings are > always encoded (GSM7 or UCS2) in the MBIM USSD logic while the > strings > passed to AT+CUSD were all in the current modem charset, except for > Huawei modems (which are also always in GSM7/hex). > > Comments? Merged to git master. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] MBIM ATDS service based 3GPP location and extended Signal interface support
On Thu, 2018-08-09 at 13:45 +0200, Aleksander Morgado wrote: > Hey, > > The following MR introduces support for using the MBIM ATDS service > extensions to query for 3GPP location (LAC/TAC/CID) as well as > extended signal information (RSRP, RSRQ, RSSI...). > > The MR contains 3 commits but only the last 2 are relevant. The first > one is a commit cherry-picked from the aleksander/mbim-ussd support > to > avoid many conflict resolutions later on. > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/25 > > Comments? Nope. Merged to git master last week. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New 'MMSharedCinterion' interface
On Mon, 2018-08-13 at 19:25 +0200, Aleksander Morgado wrote: > Hey, > > See this MR: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/26 > > It implements a new shared interface containing the code shared > between the Cinterion modem objects, similar to what's been suggested > for Qmi and Xmm in other MRs. > > It also fixes the logic behind the parent interface management: we > cannot get a single static pointer pointing to the parent interface > because this will be different depending on the object hierarchy > (e.g. > the location interface of the parent of MMBroadbandModemCinterion is > the location interface of the MMBroadbandModem; while the location > interface of the parent of the MMBroadbandModemQmiCinterion is the > location interface of the MMBroadbandModemQmi). This issue would make > ModemManager crash if a MMBroadbandModemQmiCinterion and a > MMBroadbandModemCinterion modem were managed at the same time. Merged to git master. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] QMI LOC based GPS positioning for QMI and Qualcomm-based MBIM devices
On Mon, 2018-08-13 at 15:06 +0200, Aleksander Morgado wrote: > Hey all, > > > > > See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/me > > rge_requests/10 > > > > The MR implements QMI LOC based GPS positioning, including SUPL- > > server > > based A-GPS and some new support for injecting "assistance data" > > (e.g. > > Qualcomm gpsOneXtra files), useful when the device doesn't have a > > mobile network coverage. > > > > The implementation moves all the QMI LOC management to a separate > > "MMSharedQmi" interface, that is used by both the QMI and MBIM > > mobile > > broadband objects, so the GNSS positioning support (both QMI PDS > > and > > QMI LOC) is now also available in Qualcomm-based MBIM devices. > > > > I have re-created and re-pushed this branch after fixing up how the > "parent interface" is obtained by the new MMSharedQmi implementation. Merged to git master. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] ICCID related improvements
On Tue, 2018-08-21 at 16:41 +0200, Aleksander Morgado wrote: > Hey all, > > This MR includes some improvements for ICCID reporting: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/29 > > Fixes several things found recently with China Mobile ICCIDs. Do we need testcases on this one? Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review v2] Voice implementation fixes (with audio channel setup handlers)
On Thu, 2018-08-16 at 17:30 +0100, Bob Ham wrote: > On 10/08/18 14:31, Aleksander Morgado wrote: > > > The Huawei USB dongles that support voice require a command > > (AT^DDSETEX=2) to be executed when the call is established, and > > also > > need to report which port is being used for audio. In order to > > support > > that, instead of subclassing all start/accept/hangup methods, I > > extended the MMBaseCall class with two new handlers that allow > > setting > > up and cleaning up the audio channel however the plugin needs it. > > Bob, > > you could use these two methods for the custom AT commands you > > require > > for the SIMCom implementation, right? > > Possibly, yes. The SimTech (== SIMCom) plugin is using the > MMBroadbandModemQmi class which means I either need to (1) subclass > MMBroadbandModemQmi and mix in AT commands, or (2) use the plugin's > AT-only MBroadbandModemSimtech class and add to it. I'd rather stick > with QMI but I don't know how well the modem will cope with it so I > need > to experiment. I'd be very curious if the modem supports the QMI Voice service and if so, how that interacts with the actual audio ports the modem exposes. Or if you do indeed need to use AT commands to do the voice operations, and QMI is completely unaware. > > Dan's original changes also include support for reporting which > > port > > and which audio format to use in the call, so plugins may use that > > to > > report to upper layers that required information. Instead of > > updating > > that information within the Huawei implementation, that is now > > managed > > by the base call object. > > My intention was to handle the audio completely outside of > ModemManager. > Out of interest, what upper layers make use of this information? Any kind of dialer implementation. The idea is to make the ModemManager API as generic as possible, though we understand that this won't always be possible. The only other example I have of a voice-capable modem is an AT-based Huawei device that switches its DIAG tty from QCDM to raw PCM frames when a voice call is active. You literally read the PCM data off the USB tty or write PCM to it as a Linux character device. Obviously that's not how they all work, especially in setups where the DAC is handled by the modem board. Some older Sierras were like that too; they had a headphone jack on the card that magically became active during voice calls. The point is there are a number of ways audio is exposed by the hardware, and ModemManager should try to expose those in an informative, marginally consistent way so that userspace applications can find and/or control the audio. Dan > Cheers, > > Bob > > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Fibocom L850-GL hangs upon connect.
On Wed, 2018-08-15 at 20:50 +0200, Vincent Bernat wrote: > ❦ 13 août 2018 21:02 +0200, Aleksander Morgado r.es>: > > > > If this modem is going to end up stuck with pure PPP and > > > therefore maxing > > > out at 25Mbps, then I'm not too concerned anyways since its use > > > is rather > > > limited. I just wish I could figure out how to switch this thing > > > to MBIM > > > (Tried everything listed in the AT Command reference guide, > > > including > > > factory resets and defaults.). > > > > > > > Talked to Fibocom engineers and unfortunately that firmware version > > you're using cannot do MBIM :/ > > On the latest Lenovo X1/T580/T480, this modem is plugged on a > PCIe-enabled M2 port and boots as a PCI device. It seems Linux isn't > able to handle that. People tried to tape the PCIe pins to make it > boot > as USB, but it's then blacklisted in the BIOS. Maybe you have some > hints > on how to make this modem switch to USB after booting? > > I don't own one yet, so I cannot really help with the specifics. > > Relevant thread: > https://forums.lenovo.com/t5/Linux-Discussion/Linux-support-for-WWAN > -LTE-L850-GL-on-T580-T480/m-p/4067969 Yeah, looking at the Hardware User Manual it does indeed look like the modem provides a PCIe interface rather than a USB one. cdc-mbim does not support PCIe, since cdc-mbim is a USB specification. It would be very interesting to snoop the PCI traffic for this device. But in the end, somebody needs to write a driver to talk to the modem via PCIe rather than USB. The only other device I have ever encountered that uses PCI directly is the Option "nozomi" UMTS devices from 10 years ago before USB became popular for modems. See the kernel's source in drivers/tty/nozomi.c for that, but it would obviously be different for the Fibocom device. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] Use AT+CESQ for signal interface in MBIM modems if TTY available
On Thu, 2018-08-09 at 13:47 +0200, Aleksander Morgado wrote: > Hey, > > > > > This MR enables support for the "Signal" interface in MBIM modems > > if > > they expose an AT-capable TTY port and AT+CESQ is supported. If no > > AT > > port is available in the device, the modem will report no extended > > signal capabilities, as it was doing until now for all MBIM modems. > > > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_ > > requests/18 > > > > I've closed this MR because I think using the MBIM AT extensions > service to get the same information fits much better in the MBIM > modem > object: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/25 I think that's probably fine for now, though I would bet there will be modems that don't implement ATDS and do implement CESQ in the future, if they don't exist already. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [RFC] Deprecate SubscriptionState?
On Tue, 2018-08-07 at 01:07 +0200, Aleksander Morgado wrote:
> Hey,
>
> > >
> > > At some point we need to handle network-initiated bearers in MM
> > > though.
> > >
> >
> > Given that the SessionId reported in a MBIM_CID_PCO notification
> > may
> > not be associated with any CID managed/known to ModemManager, we
> > may
> > simply expose a PCO property under the Modem3gpp interface. The PCO
> > property can be a list of (session_id, raw_pco_data_in_hex_str)
> > pair
> > (i.e. a(is) or a{is} as the D-Bus type). Does that make sense?
>
> Why raw PCO data in hex string? Why not directly the binary data?
> e.g.
> "ay" instead of "s". The signature could be then "a(iay)"
Yeah I'd vote for byte array eg "a(iay)" (eg array of struct of integer
+ byte array).
Dan
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] MBIM: show USB product attribute as model
On Wed, 2018-07-18 at 23:27 +0200, Aleksander Morgado wrote: > Hey Dan, Ben and all, > > See this quick MR for review: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/11 LGTM; merged to git master. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New 'fibocom' plugin
On Thu, 2018-07-19 at 21:10 +0200, Aleksander Morgado wrote: > > On Chrome OS, we simply use ID_MM_PORT_IGNORE to ignore all AT > > ports > > on the L850-GL module (e.g. > > https://chromium.googlesource.com/chromiumos/overlays/chromiumos-ov > > erlay/+/master/net-misc/modemmanager-next/files/77-mm-fibocom-port- > > types.rules). > > > > The modem is functional with just MBIM and supported via the > > generic > > plugin, which is the approach we took on Chrome OS. IMHO, there is > > little added benefit with a new modem plugin. More importantly, AT > > probing takes quite some time, and I observed it often took 7 > > seconds. > > We've been trying hard for some time to move everything to purely > > MBIM > > or QMI :) > > > > I'm going to extend this plugin in the following weeks with more > features that will require the use of the AT port, e.g. GPS location > and such. I agree that probing is a bit slow right now, but that is > just because the DIAG port goes first through a series of AT probing > steps which are not needed. For devices with fixed layouts like this > one, adding udev tags to specify port types isn't bad IMO, and we > should probably do that for the DIAG port (i.e. flag it as "not AT" > for example). Agreed; ideally we can begin to restrict which ports we bother probing for DIAG, since with QMI and MBIM DIAG is much less useful these days. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] u-blox auth settings fix
On Fri, 2018-06-22 at 16:57 +0200, Aleksander Morgado wrote: > Hey, > > I've pushed a new MR to gitlab fixing the authentication settings > request used in u-blox so that it always contains user/pass string > fields, even if empty, as per the AT command reference. > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/3 Merged to git master. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] skip concatenated AT commands
On Fri, 2018-06-22 at 16:58 +0200, Aleksander Morgado wrote: > Hey, > > I've pushed a MR to gitlab to avoid using concatenated AT commands in > the generic plugin: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/4 > > Looks like there are modems out there (u-blox TOBY-L4 the only one I > know of for now) that don't support these properly; as explicitly > stated in the corresponding AT command reference. Merged to git master. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] skip unneeded extra modem references on async actions
On Fri, 2018-06-22 at 17:00 +0200, Aleksander Morgado wrote: > Hey, > > Since we use GTask and the g_task_get_source_object() is a quick way > to retrieve the source object owning the async action, there's no > point in having an additional object reference in the private context > associated to the task. > > This MR solves this issue in the simple interface: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_re > quests/5 Merged to git master. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [PATCH] udev: add tags also on bind action
On Sun, 2018-05-27 at 17:03 +0200, Aleksander Morgado wrote:
> When a new USB device is hotplugged, e.g. a USB<->RS232 converter
> that
> exposes a single ttyUSB0, these udev events happen:
>
> add /devices/pci:00/:00:14.0/usb2/2-1 (usb/usb-device)
> add /devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-
> interface)
> add /devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0
> (usb-serial)
> add /devices/pci:00/:00:14.0/usb2/2-1/2-
> 1:1.0/ttyUSB0/tty/ttyUSB0 (tty)
> bind /devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0
> (usb-serial)
> bind /devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-
> interface)
> bind /devices/pci:00/:00:14.0/usb2/2-1 (usb/usb-device)
>
> Our udev rules in MM only added tags in the 'add' events, and it
> looks
> like the only ones 'persistent' after this sequence are those of the
> last event happening on the specific path.
>
> This meant that all TTY subsystem rules (e.g. ID_MM_CANDIDATE) would
> be stored for later check (e.g. if ModemManager is started after
> these
> rules have been applied), which was ok. "udevadm info -p ..." would
> show these tags correctly always.
>
> But this also meant that the 'bind' udev event happening for the USB
> device didn't get any of our device-specific tags, and so we would be
> missing them (e.g. ID_MM_DEVICE_MANUAL_SCAN_ONLY) if MM is started
> after the last event has happened. "udevadm info -p ..." would
> not show these tags.
>
> Modify all our rules to also run at the 'bind' events.
Unfortunate, but LGTM.
Dan
> ---
>
> Hey Bjørn, Dan, Ben and all,
>
> I have no idea if this is something that has recently changed in
> systemd/udev (I'm using systemd 236.81-1 in Arch Linux), or if it's
> some other issue triggered by my setup, so I would like to ask you
> all a favor and review if this makes sense or if you can reproduce
> it...
>
> The thing is, with our current set of rules, I could see how the
> port-specific udev tags (those applied in the ttyUSBx device for
> example) would be persistent and browsable with "udevadm info -p
> /sys...". But the device-specific tags (those applied to the "usb-
> device") wouldn't be persistent.
>
> The outcome of this is that if ModemManager gets the events while
> it's running, everything works perfectly, because for the 'udev-
> device' we would be notified of both 'add' and 'bind' events. But if
> MM starts after the events have happened, ModemManager only gets the
> last event ('bind' in this case) and so we would lose the device-
> specific tags because we were not adding them in the bind event. Does
> this make sense?
>
> There's no need to reboot laptop to test this ;) you can just: stop
> ModemManager, plug in e.g. a USB<->serial adapter (which shouldn't be
> probed automatically), and then start ModemManager. If the port is
> probed automatically, the tag wasn't applied. Running "udevadm
> monitor -e" during the hotplug event also helps to see the contents
> of each of the events.
>
> What do you all think?
>
> ---
> plugins/cinterion/77-mm-cinterion-port-types.rules | 2 +-
> plugins/dell/77-mm-dell-port-types.rules | 2 +-
> plugins/haier/77-mm-haier-port-types.rules | 2 +-
> plugins/huawei/77-mm-huawei-net-port-types.rules | 2 +-
> plugins/longcheer/77-mm-longcheer-port-types.rules | 2 +-
> plugins/mbm/77-mm-ericsson-mbm.rules | 2 +-
> plugins/mtk/77-mm-mtk-port-types.rules | 2 +-
> plugins/nokia/77-mm-nokia-port-types.rules | 2 +-
> plugins/sierra/77-mm-sierra.rules | 2 +-
> plugins/simtech/77-mm-simtech-port-types.rules | 2 +-
> plugins/telit/77-mm-telit-port-types.rules | 2 +-
> plugins/ublox/77-mm-ublox-port-types.rules | 2 +-
> plugins/x22x/77-mm-x22x-port-types.rules | 2 +-
> plugins/zte/77-mm-zte-port-types.rules | 2 +-
> src/77-mm-pcmcia-device-blacklist.rules| 2 +-
> src/77-mm-usb-device-blacklist.rules | 2 +-
> src/77-mm-usb-serial-adapters-greylist.rules | 2 +-
> src/80-mm-candidate.rules | 2 +-
> 18 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/plugins/cinterion/77-mm-cinterion-port-types.rules
> b/plugins/cinterion/77-mm-cinterion-port-types.rules
> index 7c63a1aa..7ef80719 100644
> --- a/plugins/cinterion/77-mm-cinterion-port-types.rules
> +++ b/plugins/cinterion/77-mm-cinterion-port-types.rules
> @@ -1,6 +1,6 @@
> # do not edit this file, it will be overwritten on update
>
> -ACTION!="add|change|move", GOTO="mm_cinterion_port_types_end"
> +ACTION!="add|change|move|bind", GOTO="mm_cinterion_port_types_end"
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="1e2d",
> GOTO="mm_cinterion_port_types"
> GOTO="mm_cinterion_port_types_end"
>
> diff --git a/plugins/dell/77-mm-dell-port-types.rules
> b/plugins/dell/77-mm-dell-port-types.rules
> index 206fb6e1..eb271fc7 100644
> ---
