[rpjday]

A bit of a different question -- I want to know the behaviour I should expect from a Huawei E367 (12d1:1506) on a system that doesn't have usb_modeswitch installed. Let me explain.

First, by way of comparison, I have Ubuntu 12.10 running on a laptop, current kernel, software, udev, etc, and the E367 works just fine. I plug it in, and get three special device files /dev/ttyUSB[012]. I use minicom and a dialscript to configure /dev/ttyUSB0 for dialout at 38400, then start pppd, set the default route to the outside world and I'm online. Most importantly (and here's the issue), during all that setup time, I could query the modem using commands like "comgt" via the admin port /dev/ttyUSB2. That's critical -- the fact that even after PPP is running on /dev/ttyUSB0, I can prod the modem on /dev/ttyUSB2 with administrative commands like asking for info, the signal strength and so on. Now, the problem.

I want to use that same modem on an embedded ARM system, which is running an older kernel (2.6.37) and does *not* have usb_modeswitch installed on it, just the corresponding older udev software, and I'm wondering whether what I'm seeing is what I should *expect* without usb_modeswitch.

First, when I plug in the modem, I still get the same special device files and (curiously) I can query the modem on both of the ports /dev/ttyUSB0 and /dev/ttyUSB2 (not 1). OK, so far, so good.

Next, I run my /dev/ttyUSB0 setup script to configure that port, at which point I lose that port as a command port, but that's OK since I still have /dev/ttyUSB2 as a working command port. And here's the problem -- once I finally start "pppd" to run on /dev/ttyUSB0, it will run just fine, but I totally lose /dev/ttyUSB2 as an admin port. In other words, it seems that I can't have both PPP running on USB0 and a live admin port on USB2.

Obviously, that modem is capable of having both ports active at the same time, I proved that on my Ubuntu system. But given that the embedded ARM system has no usb_modeswitch installed, is that the cause of the modem acting the way it does on that system? Or am I missing something more obvious?

rday

[LOM]

I don't know what you mean with "corresponding older udev software" but something is switching the device from cd-rom only mode into modem mode otherwise there wouldn't been any ttyUSBx devices.
Your problem with using ttyUSB2 is not related to which software was used for switching the device, is probably a USB core problem. The system log ought to give info about the error.

[rpjday]

OK, I'll take a look at the log files. But one last question -- does this symptom at least sound familiar to anyone? That an older kernel would drop/deactivate /dev/ttyUSB2 as the admin channel, while newer kernels keep it up just fine? Would this have been a bug reported at some point, with a corresponding patch applied to the kernel to fix it in subsequent kernels? Thanks for any info.

rday

[LOM]

OK, I'll take a look at the log files. But one last question -- does this symptom at least sound familiar to anyone? That an older kernel would drop/deactivate /dev/ttyUSB2 as the admin channel, while newer kernels keep it up just fine? Would this have been a bug reported at some point, with a corresponding patch applied to the kernel to fix it in subsequent kernels? Thanks for any info.

rday

Newer kernel on the same ARM board?
If not then you are comparing apples with oranges.

Show me the output from lsusb -vd 12d1:1506 so I can see the type of interfaces the stick has.

[rpjday]

Sadly, I don't have access to the ARM board anymore. I'll do some more research this week to see if I can run across something similar. Thanks for the advice thus far, I can see I have some reading to do.

rday