[guybrushthreepwood]

Hello to everyone. I'm trying to cross-compile the latest usb-modeswitch v2.4.0 to extend the support to newer dongles (usb-modeswitch is already available but it is a very outdated version, the v1.1.5) but I'm facing a severe issue I can't solve.
First of all, the toolchain is fine and I regularly build other executables by it. I've added the latest libusb 1.0.20 (with udev support disabled because by what I've understood it is only meant to support hotplug which I'm not interested in) to satisfy what it seems to be the only prerequisite according to the site (but I could be completely wrong). I've built it fine and I've then passed to usb-modeswitch but when I give the make command I get this error:

mips-linux-gcc -o usb_modeswitch usb_modeswitch.c -I/opt/toolchains/uclibc-crosstools/include -Wall `pkg-config --libs --cflags libusb-1.0` -L/opt/toolchains/uclibc-crosstools/lib
/opt/toolchains/uclibc-crosstools/lib/libusb-1.0.so: undefined reference to `pthread_create'
/opt/toolchains/uclibc-crosstools/lib/libusb-1.0.so: undefined reference to `pthread_mutexattr_destroy'
/opt/toolchains/uclibc-crosstools/lib/libusb-1.0.so: undefined reference to `pthread_mutexattr_settype'
/opt/toolchains/uclibc-crosstools/lib/libusb-1.0.so: undefined reference to `pthread_mutexattr_init'
/opt/toolchains/uclibc-crosstools/lib/libusb-1.0.so: undefined reference to `pthread_mutex_trylock'
/opt/toolchains/uclibc-crosstools/lib/libusb-1.0.so: undefined reference to `pthread_join'
collect2: ld returned 1 exit status

It seems it has something to do with libpthread which I haven't added to the toolchain. Could this be the problem? It isn't reported to be a dependecy for libusb (only doxigen is reported to be but optional though the information I've found could be wrong too). I'm rather new to sources compilation and cross-compilation so please forgive me should my post here result dumb and useless but so far I've compiled quite a lot of stuff and dependencies for my router and I haven't ever faced this kind of issue.
Thanks in advance to everyone.

[LOM]

It seems it has something to do with libpthread which I haven't added to the toolchain. Could this be the problem?

libusb is dependant on pthread which is not in uclibc so I guess you'll have to find the source and make a mips pthread lib which you include when building the libusb.so

[guybrushthreepwood]

Hi and first of all thanks for your reply. I've done some digging around and it seems that pthread is made up by this header alone:

http://pubs.opengroup.org/onlinepubs/00 ... ead.h.html

What I find quite strange is that a single header could be enough though it contains the references to the functions which arise the errors I've outlined before. I see only their declaration though and I don't know if it would be enough.
To use that header adding the

Code: Select all

-lpthread

switch during compilation seems enough... I was wondering if adding it to the CFLAGS environment variable could be enough, I hope so and I'll try ASAP.
Also, I was wondering how could I have been able to compile libusb with no complaints about pthread. Maybe just adding the reference to its header when compiling usb-modeswitch is enough without the need for rebuilding libusb. I would try that too.
Thanks again and have a good day.

[guybrushthreepwood]

Hello to everyone! I've finally managed to find some spare time to make the necessary modifications and succesfully build the latest usb_modeswitch version (v2.40) for my router. As previously guessed, putting the pthread.h header together with the libusb sources and adding the -lpthread switch to the CFLAGS environment variable was enough to build libusb 1.0.20 with pthread support and after that the usb_modeswitch cross-compilation has gone perfectly fine.
As clearly explained in the main page for the project, the working dirs have changed so I've needed to change them accordingly and everything seems fine (though my testing has been very limited now).
The only part currently missing from my setup is the usb_modeswitch_dispatcher script which relies on tclsh which I couldn't succeed in cross-compiling (I get a strange error on the final linking stage of tcl and I still couldn't manage to solve it).
By what I've understood (but I could be wrong), the script is used along with udev to allow hot-plugging: I'd like to have it too to be able to take advantage of full usb_modeswitch capabilities but even now I'm quite satisfied because the new usb_modeswitch binary along with the data files in their new location do what they're supposed to do very well and I'm confident the supported dongles have broaden a lot since the ancient version previously included in my router firmware.
Should I succeed with the final step (building tcl to have tclsh and be able to take advantage of the usb_modeswitch_dispatcher; eventually, it's clear I would be forced to rebuild libusb with udev support which, as previously explained, I've excluded by now), I would post here the results.

[Josh]

I don't think you need udev support in libusb for usb_modeswitch to work automatically (I haven't even heard about such a support). The binary only uses some USB input/output functions, and the dispatcher doesn't have any relation to libusb at all.

udev depends on the kernel and is more and more linked to systemd. If it's not present on the router already, you might run into lots of walls trying to post-install it ...

[guybrushthreepwood]

First of all, many thanks for your reply. According to what you say, if I'm not mistaken the best solution for use under my current conditions is going on with usb_modeswitch binary alone (leaving apart usb_modeswitch_dispatcher) and the new configurations dir under /usr/share leaving apart also the udev rules. Am I right? Thanks again and have a good day!

[Josh]

It depends on the question if udev is installed in your system already.

Look for folders like /lib/udev or /etc/udev. If they exist and are populated, then udev is likely installed and active. Automatic mode-switching should then work as intended.

If that's not the case, it may still be possible that there is some other kind of hotplug mechanism that you could use. The system log and "dmesg" are your friends on that journey.

[guybrushthreepwood]

Hello again and thanks for your reply as always. udev support isn't present for sure indeed by now I've built libusb with udev disabled (at least, there is a switch for the libusb configure script to enable or disable it: I don't know what else to say apart from adding that I needed to disable it otherwise I had kept getting errors from the configure script itself): should something change in the near future, I would need to rebuild it too.
Eventually, I would need to add udev from scratch, this leading to the aforementioned complications to which I add the one linked with me being very tight on the space still available on the router eeprom (really a few Kbytes are left and I doubt they would be enough anyway).
By what I know, the router (a slightly outdated one that on the other hand still serves me very well) hasn't any mean of supporting hotplug (though I still need to check thoroughly following your advices like I can't do right now) so the best bet should be using the approach I was describing in my previous post which is the one used by the older versions if I'm not wrong or at least it was certainly the one previously used on my router where only the usb_modeswitch binary along with the usb_modeswitch.d dir under /etc were present.
I just wanted to be sure that it is a clean approach which should let me use newer usb_modeswitch versions without malfunctions of any kind (I don't think any should happen but I may be wrong) and I would lose 'only' hotplug support as it currently seems to me (please note the quotes: I'm not saying it is a useless feature; it is the exact contrary but I can live with the lack of it if it means being able to use the latest usb_modeswitch versions supporting more and more dongles every day).
Thanks for your help!

[guybrushthreepwood]

I can confirm that I have succeeded in taking advantage of the latest usb_modeswitch v2.40 on my router following the guidelines I've given in my previous posts (I was forced to use the 'quick and dirty' approach with only the binary and the configurations dir under /usr/share because of my environment characterized by very low space available on the eeprom and missing udev support).
I'm facing only an odd issue. It hasn't certainly anything to do with usb_modeswitch (or at least I don't think so) but I ask you an hint on what could be causing it. You know usb mode switching better than anyone else so you're the best person to ask.
The premise is that this issue wasn't present at all with the previous usb_modeswitch version installed on the router (v1.1.5). When I turn the router on for the first time, the serial interface isn't detected and I can't successfully establish the mobile connection but ON A REGULAR BASIS (I've been testing it for a week now), rebooting the router is just enough to have the serial interface correctly detected and the connection established in a breeze. To summarize, what I need to do EVERY TIME I turn on the router to have the connection established is turning it on, waiting the end of the boot stage, accessing its web interface and rebooting it.
I'm surely missing something but I don't see the difference between turning the router on by its switch and rebooting it (software wise, that's clear).
What do you think about that? Thanks in advance and have a good day!

[LOM]

I guess:

You probably call usb_modeswitch too soon after power-on before the modem has finished its internal startup.
The gui reboot cmd does not remove usb power so the modem does not reset and is therefore instantly ready.

[guybrushthreepwood]

Hi and first of all thanks for your advice. It makes sense and I've tried to rebuild the firmware adding a delay but unfortunately to no avail. I don't know if this is a relevant information (I think so though) but I've noticed that the led patterns on the key (an 'ancient' Huawei E172 from Vodafone but unlocked and debranded with hw id 12d1:1003) are EXACTLY the same both when powering on and rebooting.
Thanks to everyone for your advices!

[guybrushthreepwood]

I've finally found a workaround but I'm not satisfied at all because it is only a mere workaround and it doesn't solve the problem at its roots. The router provides means for executing a startup script: while leaving all the mobile configuration unaltered, I've added to the startup script the command:

usb_modeswitch -c /usr/share/usb_modeswitch/12d1\:1003 -v 12d1 -p 1003

and now mobile connection can be successfully established even after powering the router on without the need for rebooting it.
This leaves me even more puzzled if possible because it's clear that the connection handling by the mobile connection routines from the router itself is completely correct even after renewing usb_modeswitch version (otherwise the connection couldn't be ever established, even after a reboot) and I don't understand why giving the mode switching command twice at different stages solves everything when just adding a delay (a trick which should have likely solved everything) wasn't just enough.
I'd like to understand what's going on but unfortunately dmesg output is very limited and it doesn't give me any hint and on the other hand I understand that the topic has very low interest because it isn't linked to usb_modeswitch itself (maybe its functional timeline but nothing more than that) but to my particular scenario.
Thanks anyway to everyone who has given me an hint, each one of them has been really useful and sincerely appreciated!

[Josh]

Have you ever tried playing around with the "delay_use" attribute of the usb-storage driver?

There have been reports that increasing this has solved issues - it's the time between the storage driver loading/binding and the moment where the new storage device is made available to the system.

When the default in the kernel changed from 5 to 1 seconds, some people suddenly had trouble with mode-switching.

[guybrushthreepwood]

First of all thanks for your advice and please accept my sincere apologies for replying so late. It makes sense but unfortunately I don't have an idea on how to do it. Where and what am I supposed to look for? The Linux kernel built into the router software is very very old (2.6.8.1) and I don't even know if the possibility to tweak this option is either offered.
Apart from this, has something changed in the meantime with usb_modeswitch to justify the fact that the the delay could be the cause for the issues with the newer v2.4.0 while the ancient v1.1.5 was perfectly fine given that everything else surrounding (libs etc.) is left untouched? I don't think so but I could be completely wrong.
Have a good day!