Re: Is there support for modem with a single UART port ? (SIM5320A with usb disconnected)
Hello! Out of curiosity - how did it happen the USB port isn't wired? Plain curiosity. :) Enrico On Mon, 18 Nov 2019, Andrés Calderón wrote: Date: Mon, 18 Nov 2019 17:50:43 From: Andrés Calderón To: modemmanager-devel@lists.freedesktop.org Subject: Is there support for modem with a single UART port ? (SIM5320A with usb disconnected) Hi, I'm connected to a modem with a *single* serial port (Simcom SIM5320A with the USB port unwired) I can connect to Internet using the old way (writing my own chat scripts). But I couldn't do it using modemmanager. I have a lot of error messages from ModemManeger like that: "Couldn't refresh signal quality: 'No AT port available to run command'" Can ModemManager work with a single physical UART port? any guide here? Below I share more information about the issue Best regards, Andres Calderon = # udevadm info /dev/ttyAMA0 P: /devices/platform/soc/3f201000.serial/tty/ttyAMA0 N: ttyAMA0 L: 0 S: serial0 E: DEVPATH=/devices/platform/soc/3f201000.serial/tty/ttyAMA0 E: DEVNAME=/dev/ttyAMA0 E: MAJOR=204 E: MINOR=64 E: SUBSYSTEM=tty E: USEC_INITIALIZED=5122363 E: ID_MM_CANDIDATE=1 E: ID_MM_TTY_FLOW_CONTROL=none E: ID_MM_TTY_BAUDRATE=115200 E: ID_MM_DEVICE_PROCESS=1 E: ID_MM_PLATFORM_DRIVER_PROBE=1 E: DEVLINKS=/dev/serial0 E: TAGS=:systemd: = # mmcli -m 0 -- General | dbus path: /org/freedesktop/ModemManager1/Modem/0 | device id: 23b798cdd09c78be14e231127c48d70f5307a48e -- Hardware | manufacturer: SIMCOM INCORPORATED | model: SIMCOM_SIM5320A | revision: 1575B13SIM5320A | supported: gsm-umts | current: gsm-umts | equipment id: 012813008537617 -- System | device: /sys/devices/platform/soc | drivers: uart-pl011 | plugin: Generic | primary port: ttyAMA0 | ports: ttyAMA0 (at) -- Numbers | own: +573176760667 -- Status | unlock retries: sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10) | state: disabled | power state: on | signal quality: 0% (cached) -- Modes | supported: allowed: 2g, 3g; preferred: none | current: allowed: 2g, 3g; preferred: none -- IP | supported: ipv4, ipv6 -- 3GPP | imei: 012813008537617 -- Andrés Calderón MODEMMANAGER LOG ModemManager[1133]: [1574094017.402205] No specific IP family requested, defaulting to ipv4 ModemManager[1133]: [1574094017.402298] No specific IP family requested, defaulting to ipv4 ModemManager[1133]: [1574094017.402439] Looking for best CID... ModemManager[1133]: [1574094017.402551] (ttyAMA0) device open count is 6 (open) ModemManager[1133]: [1574094017.402722] (ttyAMA0) device open count is 5 (close) ModemManager[1133]: [1574094017.402865] (ttyAMA0): --> 'AT+COPS=3,0' ModemManager[1133]: [1574094017.420240] (ttyAMA0): <-- 'OK' ModemManager[1133]: [1574094017.420584] (ttyAMA0) device open count is 4 (close) ModemManager[1133]: [1574094017.420786] (ttyAMA0): --> 'AT+COPS?' ModemManager[1133]: [1574094017.435034] (ttyAMA0): <-- '+COPS:' ModemManager[1133]: [1574094017.435707] (ttyAMA0): <-- ' 0,0,"mo' ModemManager[1133]: [1574094017.436395] (ttyAMA0): <-- 'vistar",' ModemManager[1133]: [1574094017.437102] (ttyAMA0): <-- '2OK' ModemManager[1133]: [1574094017.437484] (ttyAMA0): <-- '' ModemManager[1133]: [1574094017.438034] loaded Operator Name: movistar ModemManager[1133]: [1574094017.438332] Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (registering -> home) ModemManager[1133]: [1574094017.438692] Will start keeping track of state for subsystem '3gpp' ModemManager[1133]: [1574094017.438854] (ttyAMA0) device open count is 3 (close) ModemManager[1133]: [1574094017.439624] (ttyAMA0): --> 'AT+CIND?' ModemManager[1133]: [1574094017.455505] (ttyAMA0): <-- '+CIND:' ModemManager[1133]: [1574094017.456197] (ttyAMA0): <-- ' 4,4,1,0' ModemManager[1133]: [1574094017.456876] (ttyAMA0): <-- ',0,1,1,0' ModemManager[1133]: [1574094017.457569] (ttyAMA0): <-- 'OK' ModemManager[1133]: [1574094017.458379] Modem /org/freedesktop/ModemManager1/Modem/0: signal quality updated (80) ModemManager[1133]: [1574094017.458750] (ttyAMA0) device open count is 2 (close) ModemManager[1133]: [1574094017.459450] Polling to refresh access technologies is unsupported ModemManager[1133]: [1574094017.459576] Periodic signal quality checks scheduled in 30s ModemManager[1133]: [1574094017.459730]
Re: Is there support for modem with a single UART port ? (SIM5320A with usb disconnected)
Hey > > "Couldn't refresh signal quality: 'No AT port available to run command'" > The previous log message is expected once the TTY goes into connected mode. > Can ModemManager work with a single physical UART port? any guide here? > Yes it can, you should not need any special setup to handle that, as long as you have already sorted out e.g. baudrate settings and such. > ModemManager[1133]: [1574094017.501539] (ttyAMA0): --> > 'ATD*99***1#' > ModemManager[1133]: [1574094017.520418] (ttyAMA0): <-- > 'CONNEC' > ModemManager[1133]: [1574094017.521287] (ttyAMA0): <-- 'T 115200' > ModemManager[1133]: [1574094017.522064] (ttyAMA0): <-- '' > ModemManager[1133]: [1574094017.522990] (ttyAMA0): port now connected > ModemManager[1133]: [1574094017.523252] Connected bearer > '/org/freedesktop/ModemManager1/Bearer/0' > ModemManager[1133]: [1574094017.524890] Modem > /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> > connected) > ModemManager[1133]: [1574094017.526928] Simple connect state (8/8): > All done All the previous logs look good up until the TTY gets in connected mode. > ModemManager[1133]: [1574094017.528284] (ttyAMA0) device open count > is 2 (close) > ModemManager[1133]: [1574094022.884121] Couldn't load network > timezone: No AT port available to run command > ModemManager[1133]: [1574094022.884301] Couldn't load network > timezone from the current network > ModemManager[1133]: [1574094047.903513] loading signal quality... > ModemManager[1133]: [1574094047.904192] Couldn't refresh signal > quality: 'No AT port available to run command' > ModemManager[1133]: [1574094047.904316] Periodic signal quality > checks scheduled in 30s > ModemManager[1133]: [1574094047.905267] Connection monitoring is > unsupported by the device > ModemManager[1133]: [1574094077.908613] Signal quality value not > updated in 60s, marking as not being recent > ModemManager[1133]: [1574094077.909225] loading signal quality... > ModemManager[1133]: [1574094077.912293] Couldn't refresh signal > quality: 'No AT port available to run command' > ModemManager[1133]: [1574094077.913112] Periodic signal quality > checks scheduled in 30s > ModemManager[1133]: [1574094107.909341] loading signal quality... > ModemManager[1133]: [1574094107.910887] Couldn't refresh signal > quality: 'No AT port available to run command' > ModemManager[1133]: [1574094107.911877] Periodic signal quality > checks scheduled in 30s > ModemManager[1133]: [1574094137.909770] loading signal quality... > ModemManager[1133]: [1574094137.910968] Couldn't refresh signal > quality: 'No AT port available to run command' > ModemManager[1133]: [1574094137.99] Periodic signal quality > checks scheduled in 30s > ModemManager[1133]: [1574094167.909603] loading signal quality... > ModemManager[1133]: [1574094167.910793] Couldn't refresh signal > quality: 'No AT port available to run command' > ModemManager[1133]: [1574094167.910940] Periodic signal quality > checks scheduled in 30s > ModemManager[1133]: [1574094197.909420] loading signal quality... > ModemManager[1133]: [1574094197.910612] Couldn't refresh signal > quality: 'No AT port available to run command' > ModemManager[1133]: [1574094197.910761] Periodic signal quality > checks scheduled in 30s > ModemManager[1133]: [1574094227.908847] loading signal quality... > ModemManager[1133]: [1574094227.910030] Couldn't refresh signal > quality: 'No AT port available to run command' > ModemManager[1133]: [1574094227.910179] Periodic signal quality > checks scheduled in 30s > All previous logs are expected in MM because the TTY is now "owned" by upper layers (e.g. NM, that should run pppd). You need to debug further what happens at NetworkManager/pppd layer. Is this issue being reported here the same as this one here? https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/157#note_300284 -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Is there support for modem with a single UART port ? (SIM5320A with usb disconnected)
Hi, I'm connected to a modem with a *single* serial port (Simcom SIM5320A with the USB port unwired) I can connect to Internet using the old way (writing my own chat scripts). But I couldn't do it using modemmanager. I have a lot of error messages from ModemManeger like that: "Couldn't refresh signal quality: 'No AT port available to run command'" Can ModemManager work with a single physical UART port? any guide here? Below I share more information about the issue Best regards, Andres Calderon = # udevadm info /dev/ttyAMA0 P: /devices/platform/soc/3f201000.serial/tty/ttyAMA0 N: ttyAMA0 L: 0 S: serial0 E: DEVPATH=/devices/platform/soc/3f201000.serial/tty/ttyAMA0 E: DEVNAME=/dev/ttyAMA0 E: MAJOR=204 E: MINOR=64 E: SUBSYSTEM=tty E: USEC_INITIALIZED=5122363 E: ID_MM_CANDIDATE=1 E: ID_MM_TTY_FLOW_CONTROL=none E: ID_MM_TTY_BAUDRATE=115200 E: ID_MM_DEVICE_PROCESS=1 E: ID_MM_PLATFORM_DRIVER_PROBE=1 E: DEVLINKS=/dev/serial0 E: TAGS=:systemd: = # mmcli -m 0 -- General | dbus path: /org/freedesktop/ModemManager1/Modem/0 | device id: 23b798cdd09c78be14e231127c48d70f5307a48e -- Hardware | manufacturer: SIMCOM INCORPORATED | model: SIMCOM_SIM5320A | revision: 1575B13SIM5320A | supported: gsm-umts |current: gsm-umts | equipment id: 012813008537617 -- System | device: /sys/devices/platform/soc |drivers: uart-pl011 | plugin: Generic | primary port: ttyAMA0 | ports: ttyAMA0 (at) -- Numbers |own: +573176760667 -- Status | unlock retries: sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10) | state: disabled |power state: on | signal quality: 0% (cached) -- Modes| supported: allowed: 2g, 3g; preferred: none |current: allowed: 2g, 3g; preferred: none -- IP | supported: ipv4, ipv6 -- 3GPP | imei: 012813008537617 -- Andrés Calderón MODEMMANAGER LOG ModemManager[1133]: [1574094017.402205] No specific IP family requested, defaulting to ipv4 ModemManager[1133]: [1574094017.402298] No specific IP family requested, defaulting to ipv4 ModemManager[1133]: [1574094017.402439] Looking for best CID... ModemManager[1133]: [1574094017.402551] (ttyAMA0) device open count is 6 (open) ModemManager[1133]: [1574094017.402722] (ttyAMA0) device open count is 5 (close) ModemManager[1133]: [1574094017.402865] (ttyAMA0): --> 'AT+COPS=3,0' ModemManager[1133]: [1574094017.420240] (ttyAMA0): <-- 'OK' ModemManager[1133]: [1574094017.420584] (ttyAMA0) device open count is 4 (close) ModemManager[1133]: [1574094017.420786] (ttyAMA0): --> 'AT+COPS?' ModemManager[1133]: [1574094017.435034] (ttyAMA0): <-- '+COPS:' ModemManager[1133]: [1574094017.435707] (ttyAMA0): <-- ' 0,0,"mo' ModemManager[1133]: [1574094017.436395] (ttyAMA0): <-- 'vistar",' ModemManager[1133]: [1574094017.437102] (ttyAMA0): <-- '2OK' ModemManager[1133]: [1574094017.437484] (ttyAMA0): <-- '' ModemManager[1133]: [1574094017.438034] loaded Operator Name: movistar ModemManager[1133]: [1574094017.438332] Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (registering -> home) ModemManager[1133]: [1574094017.438692] Will start keeping track of state for subsystem '3gpp' ModemManager[1133]: [1574094017.438854] (ttyAMA0) device open count is 3 (close) ModemManager[1133]: [1574094017.439624] (ttyAMA0): --> 'AT+CIND?' ModemManager[1133]: [1574094017.455505] (ttyAMA0): <-- '+CIND:' ModemManager[1133]: [1574094017.456197] (ttyAMA0): <-- ' 4,4,1,0' ModemManager[1133]: [1574094017.456876] (ttyAMA0): <-- ',0,1,1,0' ModemManager[1133]: [1574094017.457569] (ttyAMA0): <-- 'OK' ModemManager[1133]: [1574094017.458379] Modem /org/freedesktop/ModemManager1/Modem/0: signal quality updated (80) ModemManager[1133]: [1574094017.458750] (ttyAMA0) device open count is 2 (close) ModemManager[1133]: [1574094017.459450] Polling to refresh access technologies is unsupported ModemManager[1133]: [1574094017.459576] Periodic signal quality checks scheduled in 30s ModemManager[1133]: [1574094017.459730] (ttyAMA0): --> 'AT+CGDCONT?' ModemManager[1133]: [1574094017.477723] (ttyAMA0): <-- '+CGDCO' ModemManager[1133]: [1574094017.478841] (ttyAMA0): <-- 'NT: 1,"I' ModemManager[1133]: [1574094017.479712] (ttyAMA0): <-- 'P","inte' ModemManager[1133]: [1574094017.480486] (ttyAMA0): <-- ' rnet.movistar.co' ModemManager[1133]: [1574094017.481402] (ttyAMA0): <-- 'm.co","0'
Re: Built-in plugins?
> > But if you wanted to, you > could pass --enable-plugins=X,Y,Z or something and end up with a > smaller binary. I like that. It put's the optimization in the hands of the builder which seems more than fair to have integrator's figure out what goes in or out & dependency chains. It also will sit better in build systems like Yocto IMO since you are only building installing what is needed during make. On Mon, Nov 18, 2019 at 9:31 AM Aleksander Morgado wrote: > Hey Dan! > > > > > > 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. > > > > That's definitely something we could have, yes. Actually, I recall a > patch doing that from Gimp's mitch, but that got lost in some old > Lanedo git repo. > > As long as the plugins hierarchy is enforced by the build system (e.g. > see this commit for the dependencies between them: > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209/diffs?commit_id=93123d7665da1bd6b6765dfe92a71f2ff125d41f > ) > we should be able to have selectable plugins during configure, which > is definitely a much saner thing to do than cherry-picking which > plugins are installed during the install phase. >
Re: Built-in plugins?
Hey Dan! > > > > 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. > That's definitely something we could have, yes. Actually, I recall a patch doing that from Gimp's mitch, but that got lost in some old Lanedo git repo. As long as the plugins hierarchy is enforced by the build system (e.g. see this commit for the dependencies between them: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209/diffs?commit_id=93123d7665da1bd6b6765dfe92a71f2ff125d41f) we should be able to have selectable plugins during configure, which is definitely a much saner thing to do than cherry-picking which plugins are installed during the install phase. -- Aleksander https://aleksander.es ___ 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: ModemManager and modems discovery in OpenWRt
Ok, I'll now will try to see if i can break it. BTW - is there any plan to try backporting MM OpenWRt feeds to 19.07? A good number of feeds is being backported it seems, so it may still be possible. On Mon, 18 Nov 2019, Aleksander Morgado wrote: Date: Mon, 18 Nov 2019 12:25:39 From: Aleksander Morgado To: Enrico Mioso Cc: "ModemManager (development)" , Bjørn Mork Subject: Re: ModemManager and modems discovery in OpenWRt Hey! Aleksander and Bjørn, I am CC'ing you since this question came up reading your discussion about udev rules usage. So, modems discovery mechanism in ModemManager is implemented via --report-kernel-event. And we have --report-kernel-event-auto-scan as well. the current method of reporting even tough, is not as robust: and sometimes it may happen a modem is present but not detected. That would be a bug to analyze. Do you have details on how that happened? With all the respect, while --report-kernel-event seems to be a very good decision / design choice, I don't like as much the current hotplug--based method / scripts we use to report for modem events. The cache, and all that, they seem too fragile to me. What's your opinion on that? Well, as long as hotplug events happen when they should, the logic should be consistent IMO. There's one thing I don't like, though, and I may be wrong about how it works, but if for any reason there is another hotplug script taking too much time to run, the reporting of the events to MM may happen with a lot of time in between events, and the port probing mechanism may get delayed too much. I have a MR trying to mitigate that, please see: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/207 I would be set out to replace that, maybe implementing some code to listen to netlink events and directly "inject" events in MM, or something like that. I would like to have your opinion on that, and directions on the best way to proceed. Not sure what to say :) IMO, if the hotplug scripts is the way openwrt has to report device events to userspace, we should stick to that. If that is not working well, we should fix it. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager and modems discovery in OpenWRt
Hey! > Aleksander and Bjørn, I am CC'ing you since this question came up reading > your discussion about udev rules usage. > > So, modems discovery mechanism in ModemManager is implemented via > --report-kernel-event. > And we have --report-kernel-event-auto-scan as well. > > the current method of reporting even tough, is not as robust: and sometimes > it may happen a modem is present but not detected. That would be a bug to analyze. Do you have details on how that happened? > With all the respect, while --report-kernel-event seems to be a very good > decision / design choice, I don't like as much the current hotplug--based > method / scripts we use to report for modem events. > The cache, and all that, they seem too fragile to me. What's your opinion on > that? Well, as long as hotplug events happen when they should, the logic should be consistent IMO. There's one thing I don't like, though, and I may be wrong about how it works, but if for any reason there is another hotplug script taking too much time to run, the reporting of the events to MM may happen with a lot of time in between events, and the port probing mechanism may get delayed too much. I have a MR trying to mitigate that, please see: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/207 > I would be set out to replace that, maybe implementing some code to listen to > netlink events and directly "inject" events in MM, or something like that. > I would like to have your opinion on that, and directions on the best way to > proceed. > Not sure what to say :) IMO, if the hotplug scripts is the way openwrt has to report device events to userspace, we should stick to that. If that is not working well, we should fix it. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
ModemManager and modems discovery in OpenWRt
Hello guys! Aleksander and Bjørn, I am CC'ing you since this question came up reading your discussion about udev rules usage. So, modems discovery mechanism in ModemManager is implemented via --report-kernel-event. And we have --report-kernel-event-auto-scan as well. the current method of reporting even tough, is not as robust: and sometimes it may happen a modem is present but not detected. With all the respect, while --report-kernel-event seems to be a very good decision / design choice, I don't like as much the current hotplug--based method / scripts we use to report for modem events. The cache, and all that, they seem too fragile to me. What's your opinion on that? I would be set out to replace that, maybe implementing some code to listen to netlink events and directly "inject" events in MM, or something like that. I would like to have your opinion on that, and directions on the best way to proceed. Enrico___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
