Hey Peter, > > So removing the timing logic is not possible; but why not add an > > extremely longer value that will definitely be safe? E.g. why not set > > EXTRA_PROBING_TIME_MSECS to 60000 to make it wait up to 1 minute in > > between port additions in the same device? Well, if we wait so long, > > the modem won't be exposed in DBus during all that time, so it's a > > delay we introduce arbitrarily. Adjusting that timing to a safe enough > > value needs to be considered. > > No. and this is my annoyance with "waiting" in general, and this issue > specifically that I've repeated here many times already. There is no > value which is "long enough". > > An arbitrarily high value is going to cause problems, but it must be > long enough that it's caught most of the time. > > *BUT* if there's some situation where there's a disconnect, external > reset or other condition where the second port is not detected or it's > simply taking "too long", (and I promise you, such situations can and > do occur), then falling back to PPP is not any kind of solution, ever.
What's the solution then, when ModemManager doesn't know which kind of modem it's going to manage. You know you have a QMI modem, MM doesn't know it's a QMI modem until it has found a valid QMI+NET pair and has made sure it works. The way MM works is that it decides the type of connection setup to use based on the ports that have been detected. And for that it needs to know when all ports have been reported by the kernel, and we have timing logic associated for that. We can improve that timing logic, or we could even update MM to force a full reprobe of the device when new ports have been detected on an already existing modem, but the core 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. > > > > > There would be multiple ways to do that; you could modify > > mm_base_modem_organize_ports() so that it errors out when the data > > port is a TTY; > > I guess I will attempt that. > Ok. > > It really depends on what you expect to happen when PPP is assumed to be the > > only data connection mode available. > > Maye it's your English, but I don't want to get to this assumption. > English is not my main language, so it may be that I'm not explaining clearly enough, sorry if that's the case. I could also try to explain in Spanish or Basque if you prefer, but I don't think it would improve much :) > It's too late at that point. Yes, the error when the connection attempt is triggered is probably too late, I also agree with that. I was just giving you options. > Like I said, pretty tired of arguing this point. > I acknowledge we have different point of views; but please, try updating the EXTRA_PROBING_TIME_MSECS value to 3000ms, so that we don't miss the QMI port notifications. If MM detects valid QMI+NET ports, it won't try PPP. Cheers! -- Aleksander https://aleksander.es
