Daniele,
On Sun, Jul 12, 2020 at 4:45 PM Daniele Palmas <dnl...@gmail.com> wrote: > > Hi Aleksander and Mark, > > Il giorno dom 12 lug 2020 alle ore 09:08 Aleksander Morgado > <aleksan...@aleksander.es> ha scritto: > > > > Hey! > > > > > I've attached a patch which uses the "custom regex" feature of the > > > existing parser in order to detect PPP and say that things are good. > > > A few things to note: > > > > > > * I created the regex based on data I saw output from my modem. At > > > best it is correct, at worst it won't do any harm. > > > > I find this regex is extremely specific to your usecase. As you said > > it may be a fix, or it may not do anything, that isn't a complete > > solution, and I think we should try to find some other way to handle > > this if possible. > > > > I find it very very weird that the modem doesn't reply a CONNECT > > response after the ATD, that would be a very weird firmware bug! Maybe > > the TTY we're using for connection isn't the correct one? @Daniele > > Palmas @Carlo Lobrano Do you guys have any idea of why this may be > > happening in the ME310? > > > > I recently used a ME910G1, which should be the same as the 310, > besides the form factor, but I do not remember such an issue. I'm > going to check again in the first days of the week. > > @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.210000, 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. > > > * Ideally I would only use this for the ME310 modem, but I didn't see > > > a way to do that in the plugin. I'm certainly open to suggestions. > > > > If we needed a quirk like this one, we could flag via udev with a new udev > > tag. > > > > > This particular device has a second port configuration (1bc7:1102), > > > which which looks like this: > > > > > > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=atmel-ehci/3p, 480M > > > |__ Port 2: Dev 7, If 0, Class=Vendor Specific Class, Driver=option, > > > 480M > > > |__ Port 2: Dev 7, If 1, Class=Vendor Specific Class, Driver=option, > > > 480M > > > |__ Port 2: Dev 7, If 2, Class=Vendor Specific Class, Driver=option, > > > 480M > > > |__ Port 2: Dev 7, If 3, Class=Communications, Driver=cdc_ether, 480M > > > |__ Port 2: Dev 7, If 4, Class=CDC Data, Driver=cdc_ether, 480M > > > > > > I've not been able to get the cdc_ether portion working yet, although > > > I am hopeful. If both ECM and "option" serial interfaces are > > > available, how does ModemManager choose between them? > > > > MM doesn't have any implementation yet to handle ECM interfaces in > > Telit modems, but that would definitely be preferred over PPP in a > > TTY. > > > > Not sure that ECM is better than PPP for this modem, since > connection/disconnection requires a reboot of the modem. Ah, I was unaware of this, thanks for the information. > > Regarding the patch itself, you shouldn't add the regex to the primary > > port. You should run mm_base_modem_peek_data_ports() and add the regex > > to all data ports that are TTYs (MM_IS_PORT_SERIAL()). But as said, I > > would totally prefer to have this solved somehow without needing to > > detect the PPP stream, because it is pppd the only one who should be > > touching that (MM yields the control of the TTY to pppd as soon as the > > port is in data mode). -M _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
