Re: Instantiating rmnet devices for data ports on QRTR-based modems
Hi, Il giorno lun 19 ott 2020 alle ore 09:57 Aleksander Morgado ha scritto: > > Hey, > > > > > I seem we have done for "QMI based on QTRT" in libqmi. > > > > For QUALCOMM's data services, there are lots of QMI library, > > > > and libqmi used a more simply solution. (in fact, if just send QMI, > > > > QTRT is also not a good idea) > > > > > > Why do you say QRTR is not a good idea? Isn't QMI over QRTR the only way > > > to > > > handle the communication in certain setups? > > [carl.yin] 1. QRTR codes is much complex than direct send QMI message via > > QMI channel like /dev/cdc-wdm0 > > And it is not easy to find real hardware device for the > > QTRT node. > > No matter the hardware interface between AP and Qualcomm > > modem is USB/PCIE/SMD, > > (SMD is for QUALCOMM inter-AP, like MDM, APQ,MSM chipset.) > > There always have QMI channel can be used to send QMI > > message. > > If use these QMI channel, very few modifies is need apply > > to libqmi and MM > > I cannot comment on this, probably @Eric Caruso has a better point of view. > > > > This logic you're suggesting, except for step 5 I think, is what we > > > already had in > > > mind more or less. I think we could have that done by ModemManager, and > > > connection managers like NetworkManager will get that working > > > automatically, > > > but now I also fear that if we change the default QMI modem behavior > > > w.r.t. > > > which is the connected network interface, we may be breaking user setups > > > out > > > there that rely on fixed interface names (e.g. for iptables rules). > > > > > > > rmnet_dataX is not a good name, there may be rment_usb0, > > > rment_mhi0 exist at the same time, so can named as rment_usb0_X. > > > > > > In qmi_wwan, the muxed interfaces are named qmimux0, qmimux1 ... And if > > > you > > > have 5 different modems, each of them instantiating muxed virtual > > > interfaces, > > > they'll just get assigned sequential interface names, without any > > > reference in the > > > interface name to which physical interface they're mapped to. I don't > > > think the > > > name of the interface matters much at this point, as long as we can know > > > which > > > virtual interface maps to which physical interface. > > > > > > E.g. qmi_wwan adds a "lower_wwan0" file in the virtual interface sysfs > > > contents > > > pointing to the physical interface: > > > # ls -ltr /sys/class/net/qmimux0/lower_wwan0 > > > lrwxrwxrwx1 root root 0 Oct 17 20:52 > > > /sys/class/net/qmimux0/lower_wwan0 -> > > > ../../../pci:00/:00:16.0/usb1/1-1/1-1.2/1-1.2:1.8/net/wwan0 > > > > > > And it adds a "upper_qmimux0" file in the physical interface sysfs > > > pointing to the > > > virtual device: > > > # ls -ltr /sys/class/net/wwan0/upper_qmimux0 > > > lrwxrwxrwx1 root root 0 Oct 17 20:53 > > > /sys/class/net/wwan0/upper_qmimux0 -> > > > ../../../../../../../../virtual/net/qmimux0 > > > > > > As long as we have this kind of relationship between the virtual and > > > physical > > > interfaces, we're good to go, regardless of the actual naming of the > > > interface. > > [carl.yin] developer can find the relationship of wwanX and qmimuxX. > > But for the end customers, maybe it is difficult, maybe he > > want to setup data call on PDN-x on modem y. > > It will be Very intuitive if we can make PDN-x to muxid-X > > to rmnet_modemY_X. > > I truly don't have a strong opinion on that, kernel devs probably have > a better idea on what the naming should look like. Either way, it is > true that the current kernel implementation for the muxing in qmi_wwan > already relies on that naming mechanism, so not sure if that could be > changed right now without breaking the API. > Maybe a possibility to align things is to add rmnet support to qmi_wwan? In the past there was an attempt for this (see https://www.mail-archive.com/netdev@vger.kernel.org/msg239867.html), but not completed. Regards, Daniele > -- > 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: Instantiating rmnet devices for data ports on QRTR-based modems
Hey, > > > I seem we have done for "QMI based on QTRT" in libqmi. > > > For QUALCOMM's data services, there are lots of QMI library, > > > and libqmi used a more simply solution. (in fact, if just send QMI, > > > QTRT is also not a good idea) > > > > Why do you say QRTR is not a good idea? Isn't QMI over QRTR the only way to > > handle the communication in certain setups? > [carl.yin] 1. QRTR codes is much complex than direct send QMI message via QMI > channel like /dev/cdc-wdm0 > And it is not easy to find real hardware device for the QTRT > node. > No matter the hardware interface between AP and Qualcomm > modem is USB/PCIE/SMD, > (SMD is for QUALCOMM inter-AP, like MDM, APQ,MSM chipset.) > There always have QMI channel can be used to send QMI message. > If use these QMI channel, very few modifies is need apply to > libqmi and MM I cannot comment on this, probably @Eric Caruso has a better point of view. > > This logic you're suggesting, except for step 5 I think, is what we already > > had in > > mind more or less. I think we could have that done by ModemManager, and > > connection managers like NetworkManager will get that working automatically, > > but now I also fear that if we change the default QMI modem behavior w.r.t. > > which is the connected network interface, we may be breaking user setups out > > there that rely on fixed interface names (e.g. for iptables rules). > > > > > rmnet_dataX is not a good name, there may be rment_usb0, > > rment_mhi0 exist at the same time, so can named as rment_usb0_X. > > > > In qmi_wwan, the muxed interfaces are named qmimux0, qmimux1 ... And if you > > have 5 different modems, each of them instantiating muxed virtual > > interfaces, > > they'll just get assigned sequential interface names, without any reference > > in the > > interface name to which physical interface they're mapped to. I don't think > > the > > name of the interface matters much at this point, as long as we can know > > which > > virtual interface maps to which physical interface. > > > > E.g. qmi_wwan adds a "lower_wwan0" file in the virtual interface sysfs > > contents > > pointing to the physical interface: > > # ls -ltr /sys/class/net/qmimux0/lower_wwan0 > > lrwxrwxrwx1 root root 0 Oct 17 20:52 > > /sys/class/net/qmimux0/lower_wwan0 -> > > ../../../pci:00/:00:16.0/usb1/1-1/1-1.2/1-1.2:1.8/net/wwan0 > > > > And it adds a "upper_qmimux0" file in the physical interface sysfs pointing > > to the > > virtual device: > > # ls -ltr /sys/class/net/wwan0/upper_qmimux0 > > lrwxrwxrwx1 root root 0 Oct 17 20:53 > > /sys/class/net/wwan0/upper_qmimux0 -> > > ../../../../../../../../virtual/net/qmimux0 > > > > As long as we have this kind of relationship between the virtual and > > physical > > interfaces, we're good to go, regardless of the actual naming of the > > interface. > [carl.yin] developer can find the relationship of wwanX and qmimuxX. > But for the end customers, maybe it is difficult, maybe he > want to setup data call on PDN-x on modem y. > It will be Very intuitive if we can make PDN-x to muxid-X to > rmnet_modemY_X. I truly don't have a strong opinion on that, kernel devs probably have a better idea on what the naming should look like. Either way, it is true that the current kernel implementation for the muxing in qmi_wwan already relies on that naming mechanism, so not sure if that could be changed right now without breaking the API. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Instantiating rmnet devices for data ports on QRTR-based modems
Hey, > > > So the process can next: > > > 1. rmnet physic driver probe, create netcard > > > rmnet_usb0/rmnet_mhi0/rmnet_ipa0, and call register_rmnet_data > > > 2. rmnet data driver create rmnet_data0 > > > > Are you suggesting that there is always a virtual network interface > > created for the physical network interface? In terms of qmi_wwan, are > > you suggesting a virtual qmimux0 is always created when the physical > > wwan0 interface is exposed? What would be the benefit of doing that? > > > > One of the benefits is dl throughput for high-cat modems, since > enabling data aggregation is mandatory to get the most out of the > modem. > That's a good point. > > > 3. MM query qmap-version, ep-type, iface-id, > > > dll_data_aggregation_max_size from rmnet physic driver > > > 4. MM send QMIWDS_ADMIN_SET_DATA_FORMAT_REQ to modem. > > > 5. MM get ul_data_aggregation_max_size from > > > QMIWDS_ADMIN_SET_DATA_FORMAT_RESP, and send to rmnet physic driver. > > > > @Bjørn Mork @Daniele Palmas is that step 5 something we're not > > currently doing and we may need to do? Does the physical wwan > > interface truly need to know the ul_data_aggregation_max_size? > > > > I can't find this WDS request, or do you mean QMI_WDA_SET_DATA_FORMAT? Yes, that's what he refers to. > Anyway, the driver is not dealing with ul values: so far I did not > receive complaints on upload performance, even with high-cat modems, > so I'm not sure this is something that should be fixed at the moment. > I'm more concerned about the dl aggregation, whose setting is still a > manual process. > Carl, could you elaborate on why the kernel driver would need to know about ul_data_aggregation_max_size? What is the downside of not implementing it? > By the way, not strictly related to this thread, but there is a very > good effort ongoing for upstreaming mhi driver, mainly targeted on > SDX55, see for example > https://patchwork.kernel.org/project/linux-arm-msm/patch/1602258664-9980-1-git-send-email-loic.poul...@linaro.org/ > and https://www.spinics.net/lists/netdev/msg692557.html > > The uci driver is still missing, but I think it will be just a matter > of time: the interesting part is that with uci a char qmi device is > exposed that, according to my current tests, is behaving at the high > level just like the cdc-wdm device. I believe Carl is already testing a setup like that one as well. https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/254 -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager Process is shutting down
Thanks Aleksander. Will update and try on it On Fri, Oct 16, 2020 at 9:20 PM Aleksander Morgado wrote: > Hey, > > > Before Logs: > > > > ModemManager[104]: Signal strength (umts): -79 dBm > > ModemManager[104]: Signal strength: -79 dBm --> 55% > > ModemManager[104]: Modem /org/freedesktop/ModemManager1/Modem/1: > access technology changed (unknown -> umts) > > ModemManager[104]: Modem /org/freedesktop/ModemManager1/Modem/1: > signal quality updated (55) > > ModemManager[104]: Periodic signal quality checks scheduled in > 30s > > ModemManager[104]: Running registration checks (CS: 'yes', PS: > 'yes', EPS: 'yes') > > ModemManager[104]: [/dev/cdc-wdm0] sent message...#012<< > RAW:#012<< length = 13#012<< data = > 01:0C:00:00:03:03:00:1B:00:24:00:00:00 > > ModemManager[104]: [/dev/cdc-wdm0] sent generic request > (translated)...#012<< QMUX:#012<< length = 12#012<< flags > = 0x00#012<< service = "nas"#012<< client = 3#012<< > QMI:#012<< flags = "none"#012<< transaction = > 27#012<< tlv_length = 0#012<< message = "Get Serving > System" (0x0024) > > ModemManager[104]: building consolidated registration state: cs > 'idle', ps 'unknown', eps 'unknown' --> 'idle' > > ModemManager[104]: Modem /org/freedesktop/ModemManager1/Modem/0: > 3GPP Registration state changed (unknown -> idle) > > ModemManager[104]: building consolidated registration state: cs > 'idle', ps 'idle', eps 'unknown' --> 'idle' > > ModemManager[104]: building consolidated registration state: cs > 'idle', ps 'idle', eps 'idle' --> 'idle' > > > > dbus[1073]: [system] Rejected send message, 2 matched rules; > type="method_return", sender=":1.140" (uid=0 pid=104 > comm="/usr/sbin/ModemManager ") interface="(unset)" member="(unset)" error > name="(unset)" requested_reply="0" destination=":1.142" (uid=0 pid=240 > comm="/usr/bin/ApplnManagerd ") > > > > After this : > > No logs but the ModemManager restarts, in fact there is a crash and the > core is dumped. > > The ModemManager does restart after that and recovers. > > > > Ok, so my assumption was right I think. This is just the daemon > crashing and restarted afterwards by systemd, and in between some MM > client (likely NetworkManager) asked DBus to initiate it, but DBus > activation isn't enabled for MM. > > > Also this happens after the ModemReset in all cases. > > > > I would suggest to upgrade your ModemManager. 1.10.8 is not even the > latest release in the 1.10.x series. > This PPA has a much newer MM version for Ubuntu 16.04: > https://launchpad.net/~aleksander-m/+archive/ubuntu/modemmanager-xenial > > -- > Aleksander > https://aleksander.es > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Instantiating rmnet devices for data ports on QRTR-based modems
Hi all, Il giorno sab 17 ott 2020 alle ore 23:05 Aleksander Morgado ha scritto: > > Hey Carl, > > > Some ideas from me. > > Thanks for your comments, very much appreciated. > > > The discussion is based on QUALCOMM's rmnet driver and his data > > services. > > We are discussing how porting these software to MM and libqmi. > > But I think QUALLCOMM's solution is too complex, porting is > > impossible. > > What we have to do is re-implementation. > > > > I seem we have done for "QMI based on QTRT" in libqmi. > > For QUALCOMM's data services, there are lots of QMI library, and > > libqmi used a more simply solution. (in fact, if just send QMI, QTRT is > > also not a good idea) > > Why do you say QRTR is not a good idea? Isn't QMI over QRTR the only > way to handle the communication in certain setups? > > > > > So, others part of QUALCOMM's data services and QUALCOMM's rmnet > > drvier, we also can simplify. > > > > I'm all for simplifying :D > > > Take rmnet driver for example: > > QUALCOMM;s rmnet driver consist of two parts. > > 1. physic netcard part, name as > > rmnet_usb.c/rmnet_mhi.c/rmnet_ipa.c,, depend on the hardware interface used. > > this driver response for transfer QMAP packet to modem. > > 2. virtual nectar part, name as rmnet_data.c, this driver response > > for: rx IP packets from tcp/ip stack, and add QMAP header to IP packet, and > > sent to rmnet physic driver. > > > > Ok, understood. > > > So the process can next: > > 1. rmnet physic driver probe, create netcard > > rmnet_usb0/rmnet_mhi0/rmnet_ipa0, and call register_rmnet_data > > 2. rmnet data driver create rmnet_data0 > > Are you suggesting that there is always a virtual network interface > created for the physical network interface? In terms of qmi_wwan, are > you suggesting a virtual qmimux0 is always created when the physical > wwan0 interface is exposed? What would be the benefit of doing that? > One of the benefits is dl throughput for high-cat modems, since enabling data aggregation is mandatory to get the most out of the modem. > > 3. MM query qmap-version, ep-type, iface-id, > > dll_data_aggregation_max_size from rmnet physic driver > > 4. MM send QMIWDS_ADMIN_SET_DATA_FORMAT_REQ to modem. > > 5. MM get ul_data_aggregation_max_size from > > QMIWDS_ADMIN_SET_DATA_FORMAT_RESP, and send to rmnet physic driver. > > @Bjørn Mork @Daniele Palmas is that step 5 something we're not > currently doing and we may need to do? Does the physical wwan > interface truly need to know the ul_data_aggregation_max_size? > I can't find this WDS request, or do you mean QMI_WDA_SET_DATA_FORMAT? Anyway, the driver is not dealing with ul values: so far I did not receive complaints on upload performance, even with high-cat modems, so I'm not sure this is something that should be fixed at the moment. I'm more concerned about the dl aggregation, whose setting is still a manual process. > > 6. MM want to setup data call on PDN-x. MM send muxid-X to rmnet > > physic driver, rmnet physic driver tell rmnet data driver to create > > rmnet_dataX. > > > > This logic you're suggesting, except for step 5 I think, is what we > already had in mind more or less. I think we could have that done by > ModemManager, and connection managers like NetworkManager will get > that working automatically, but now I also fear that if we change the > default QMI modem behavior w.r.t. which is the connected network > interface, we may be breaking user setups out there that rely on fixed > interface names (e.g. for iptables rules). > > > rmnet_dataX is not a good name, there may be rment_usb0, rment_mhi0 > > exist at the same time, so can named as rment_usb0_X. > > In qmi_wwan, the muxed interfaces are named qmimux0, qmimux1 ... And > if you have 5 different modems, each of them instantiating muxed > virtual interfaces, they'll just get assigned sequential interface > names, without any reference in the interface name to which physical > interface they're mapped to. I don't think the name of the interface > matters much at this point, as long as we can know which virtual > interface maps to which physical interface. > > E.g. qmi_wwan adds a "lower_wwan0" file in the virtual interface sysfs > contents pointing to the physical interface: > # ls -ltr /sys/class/net/qmimux0/lower_wwan0 > lrwxrwxrwx1 root root 0 Oct 17 20:52 > /sys/class/net/qmimux0/lower_wwan0 -> > ../../../pci:00/:00:16.0/usb1/1-1/1-1.2/1-1.2:1.8/net/wwan0 > > And it adds a "upper_qmimux0" file in the physical interface sysfs > pointing to the virtual device: > # ls -ltr /sys/class/net/wwan0/upper_qmimux0 > lrwxrwxrwx1 root root 0 Oct 17 20:53 > /sys/class/net/wwan0/upper_qmimux0 -> > ../../../../../../../../virtual/net/qmimux0 > > As long as we have this kind of relationship
