Author Message

<  Setup Discussion  ~  1.1.5 is broken

PostPosted: Tue Dec 07, 2010 3:06 pm
Posts: 11Location: AustraliaJoined: Tue Dec 07, 2010 2:52 pm
I have just upgraded from 1.1.4 to 1.1.5. Running Puppy Linux.

I am currently using a Vodafone ZTE Z3571-Z. When I hotplug it with 1.1.4, it works, however with 1.1.5 everything seems to work, the 'option' module loads, but the /dev/ttyUSB[n] ports are not created.

The logs report a bug in libusb1:

/var/log/messages:

Code:
Dec  7 20:30:29 puppypc syslog.notice usb_modeswitch: switching 19d2:1009 (Vodafone (ZTE): Vodafone Mobile Broadband K3571-Z)
Dec  8 11:30:31 puppypc user.info kernel: usb 1-2: USB disconnect, address 4
Dec  7 20:30:31 puppypc syslog.notice usb_modeswitch: switched to new device, but hit libusb1 bug
Dec  8 11:30:36 puppypc user.info kernel: usb 1-2: new high speed USB device using ehci_hcd and address 5
Dec  8 11:30:36 puppypc user.info kernel: usb 1-2: configuration #1 chosen from 1 choice
Dec  8 11:30:37 puppypc user.info kernel: usbcore: registered new interface driver usbserial
Dec  8 11:30:37 puppypc user.info kernel: USB Serial support registered for generic
Dec  8 11:30:37 puppypc user.info kernel: usbcore: registered new interface driver usbserial_generic
Dec  8 11:30:37 puppypc user.info kernel: usbserial: USB Serial Driver core
Dec  8 11:30:37 puppypc user.info kernel: USB Serial support registered for GSM modem (1-port)
Dec  8 11:30:37 puppypc user.info kernel: usbcore: registered new interface driver option
Dec  8 11:30:37 puppypc user.info kernel: option: v0.7.2:USB Driver for GSM modems
Dec  7 20:30:37 puppypc syslog.notice root: usb_modeswitch: adding device ID 19d2/1010/0: to driver "option"


/var/log/usb_modeswitch_1-2:1.0:

Code:
USB_ModeSwitch log from Tue Dec  07 20:30:29 GMT-8 2010

raw args from udev: /1-2:1.0

Using global config file: /etc/usb_modeswitch.conf
Bus ID for device not given by udev.
 Trying to determine it from kernel name (1-2:1.0) ...
USB dir exists: /sys/bus/usb/devices/1-2
----------------
USB values from sysfs:
  manufacturer   Vodafone (ZTE)
  product   Vodafone Mobile Broadband K3571-Z
  serial   P680A8VDFD000000
----------------
SCSI attributes not needed, moving on
checking config: /etc/usb_modeswitch.d/19d2:1009
! matched, now switching
 (running command: /usr/sbin/usb_modeswitch -I -W -c /etc/usb_modeswitch.d/19d2:1009)

verbose output of usb_modeswitch:
--------------------------------
Reading config file: /etc/usb_modeswitch.d/19d2:1009
 * usb_modeswitch: handle USB devices with multiple modes
 * Version 1.1.5 (C) Josua Dietze 2010
 * Based on libusb0 (0.1.12 and above)

 ! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor=  0x19d2
DefaultProduct= 0x1009
TargetVendor=   0x19d2
TargetProduct=  0x1010
TargetClass=    not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
GCTMode=0
KobilMode=0
MessageEndpoint=  not set
MessageContent="5553424312345678000000000000061b000000020000000000000000000000"
NeedResponse=1
ResponseEndpoint= not set
Interface=0x00

InquireDevice disabled
Success check enabled, max. wait time 20 seconds
System integration mode enabled


Looking for target devices ...
  searching devices, found USB ID 19d2:1009
   found matching vendor ID
 No devices in target mode or class found
Looking for default devices ...
  searching devices, found USB ID 19d2:1009
   found matching vendor ID
   found matching product ID
   adding device
 Found devices in default mode or class (1)
Accessing device 004 on bus 001 ...
Getting the current device configuration ...
 OK, got current device configuration (1)
Using endpoints 0x01 (out) and 0x81 (in)
Using endpoints 0x01 (out) and 0x81 (in)

USB description data (for identification)
-------------------------
Manufacturer: Vodafone (ZTE)
     Product: Vodafone Mobile Broadband K3571-Z
  Serial No.: P680A8VDFD000000
-------------------------
Looking for active driver ...
 OK, driver found ("usb-storage")
 OK, driver "usb-storage" detached
Setting up communication with interface 0 ...
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
 OK, message successfully sent
Reading the response to the message (CSW) ...
 OK, response successfully read (13 bytes).
Resetting response endpoint 0x81
Resetting message endpoint 0x01

Checking for mode switch (max. 20 times, once per second) ...
 Waiting for original device to vanish ...
 Waiting for original device to vanish ...
 Original device can't be accessed anymore. Good.
 Searching for target devices ...
Error: libusb1 bug, no more searching, try to work around
ok:no_data
--------------------------------
(end of usb_modeswitch output)

Device directory in sysfs is gone! Something went wrong, aborting


...I double-checked, changed files back to v1.1.4, modem works, all /dev/ttyUSB[n] ports get created.

What is this libusb1 bug, and why doesn't it occur in v1.1.4?

Regards,
Barry Kauler


Offline Profile WWW
PostPosted: Tue Dec 07, 2010 3:10 pm
Posts: 11Location: AustraliaJoined: Tue Dec 07, 2010 2:52 pm
I mean, it is a K3571-Z.

I should add that Puppy has libusb0, version 0.1.12.
Puppy does NOT have libusb1.

Regards,
Barry Kauler


Offline Profile WWW
PostPosted: Tue Dec 07, 2010 9:09 pm
Site AdminPosts: 4905Joined: Sat Nov 03, 2007 12:30 am
I just re-tested version 1.1.5 with a ZTE device on an old Debian system with libusb-0.1.12 and had no problems ...

The only difference between versions at the point in question is that 1.1.5 reacts to errors returned by "usb_find_busses" and "usb_find_devices". I hit errors like this in libusb when accessing the re-appeared device - and only with the ZTE stick so far:
"libusb:error [__open_sysfs_attr] open /sys/bus/usb/devices/(null)/descriptors failed ret=-1 errno=2"

There is a very similar error mentioned here, related to unplugging and replugging devices:
http://www.libusb.org/ticket/70
Since this whole mode-switching mechanism looks to the system like removing and replacing a device, I assume there is a connection with the error from the ticket.

With libusb1, the error happens when the switched device is appearing on the bus and can therefore be accessed via sysfs. So I just skipped further searching and let the wrapper script determine the new device ID.
On your system, the very first device search is already failing. At that moment, the device is not back yet and the sysfs access fails as well, aborting the whole procedure.

You could apply this patch (with -p1) to see what error you get specifically:
http://www.draisberghof.de/usb_modeswit ... hbus-error

There are no other reports about similar problems yet, but that may be due to the spreading of libusb1 installations.

BTW, the limitation to ZTE (I have five different sticks for testing) may point to a firmware-specific problem.



Offline Profile
PostPosted: Wed Dec 08, 2010 1:49 am
Posts: 11Location: AustraliaJoined: Tue Dec 07, 2010 2:52 pm
Sorry, I just realised that you have a different section of the forum for reporting bugs.

I have a nicely working system now, at least with my ZTE K3571-Z modem. I have usb-modeswitch 1.1.5 except that I have substituted the /usr/sbin/usb_modeswitch from 1.1.4. I am also using the usb_modeswitcher_dispatcher with the JimTcl patches. Also the latest database.

Anyway, I did try the patch that you posted in the previous post. Here is the result in /var/log/usb_modeswitch_1-2:1.0:


Code:
USB_ModeSwitch log from Wed Dec  08 06:31:48 GMT-8 2010

raw args from udev: /1-2:1.0

Using global config file: /etc/usb_modeswitch.conf
Bus ID for device not given by udev.
 Trying to determine it from kernel name (1-2:1.0) ...
USB dir exists: /sys/bus/usb/devices/1-2
----------------
USB values from sysfs:
  manufacturer   Vodafone (ZTE)
  product   Vodafone Mobile Broadband K3571-Z
  serial   P680A8VDFD000000
----------------
SCSI attributes not needed, moving on
checking config: /etc/usb_modeswitch.d/19d2:1009
! matched, now switching
 (running command: /usr/sbin/usb_modeswitch -I -W -c /etc/usb_modeswitch.d/19d2:1009)

verbose output of usb_modeswitch:
--------------------------------
Reading config file: /etc/usb_modeswitch.d/19d2:1009
 * usb_modeswitch: handle USB devices with multiple modes
 * Version 1.1.5 (C) Josua Dietze 2010
 * Based on libusb0 (0.1.12 and above)

 ! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor=  0x19d2
DefaultProduct= 0x1009
TargetVendor=   0x19d2
TargetProduct=  0x1010
TargetClass=    not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
GCTMode=0
KobilMode=0
MessageEndpoint=  not set
MessageContent="5553424312345678000000000000061b000000020000000000000000000000"
NeedResponse=1
ResponseEndpoint= not set
Interface=0x00

InquireDevice disabled
Success check enabled, max. wait time 20 seconds
System integration mode enabled


Looking for target devices ...
  searching devices, found USB ID 19d2:1009
   found matching vendor ID
 No devices in target mode or class found
Looking for default devices ...
  searching devices, found USB ID 19d2:1009
   found matching vendor ID
   found matching product ID
   adding device
 Found devices in default mode or class (1)
Accessing device 004 on bus 001 ...
Getting the current device configuration ...
 OK, got current device configuration (1)
Using endpoints 0x01 (out) and 0x81 (in)
Using endpoints 0x01 (out) and 0x81 (in)

USB description data (for identification)
-------------------------
Manufacturer: Vodafone (ZTE)
     Product: Vodafone Mobile Broadband K3571-Z
  Serial No.: P680A8VDFD000000
-------------------------
Looking for active driver ...
 OK, driver found ("usb-storage")
 OK, driver "usb-storage" detached
Setting up communication with interface 0 ...
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
 OK, message successfully sent
Reading the response to the message (CSW) ...
 OK, response successfully read (13 bytes).
Resetting response endpoint 0x81
Resetting message endpoint 0x01

Checking for mode switch (max. 20 times, once per second) ...
 Waiting for original device to vanish ...
 Waiting for original device to vanish ...
 Original device can't be accessed anymore. Good.
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
 Searching for target devices ...
 find_busses returned error -2
fail:
--------------------------------
(end of usb_modeswitch output)


All done, exiting


Offline Profile WWW
PostPosted: Wed Dec 08, 2010 3:28 am
Posts: 11Location: AustraliaJoined: Tue Dec 07, 2010 2:52 pm
Removed.

I need to do more testing.

I had it working, it is working right now, but earlier I was testing, unplugging and replugging the modem, each time I observed /dev/ttyUSB* disappear and reappear -- but then, for no apparent reason they did not reappear when I replugged the modem -- conditions same as before.

I will test more thoroughly before posting here again.


Offline Profile WWW
PostPosted: Wed Dec 08, 2010 2:21 pm
Site AdminPosts: 4905Joined: Sat Nov 03, 2007 12:30 am
I checked here too with the original version 1.1.4. The error is alike but the program does not abort like 1.1.5 does. The result is the same as with the patched 1.1.5 - "fail" after the checking loop ends.

Not the least problem with the original libusb-0.1.12.

However, I found that while I thought I had libusb1 replaced by 0.1.12, the libusb1 files were still sitting in "/lib" and were preferred over 0.1.12, which was in "/usr/lib".

The debug output of libusb-0.1.12 seems to be slightly different; it reports details when finding devices:
Code:
usb_os_find_devices: Found 001 on 004
usb_os_find_devices: Found 001 on 003
usb_os_find_devices: Found 001 on 001
...
When debugging you may get a slightly more detailed output with a manual switching call (disable automatic switching globally in "/etc/usb_modeswitch.conf" first):
Code:
usb_modeswitch -I -W -c /etc/usb_modeswitch.d/19d2:1009


Offline Profile
PostPosted: Wed Dec 08, 2010 11:57 pm
Posts: 11Location: AustraliaJoined: Tue Dec 07, 2010 2:52 pm
A progress report.

I have my ZTE K3571-Z working reliably now.

Apart from having to roll /usr/sbin/usb_modeswitch back to version 1.1.4, there is another problem...

I have been plagued with this problem ever since I bought this modem. Sometimes it works, sometimes not. I would plug it in, and the /dev/ttyUSB* ports appeared. Another time they do not. There never seemed to be any logic to it.

Well, I have located the cause of the problem. It seems that sometimes usbserial.ko attaches to 19d2:1010, sometimes not.

I can't read Tcl code, well, barely, and I do see some code in your dispatcher that seems to be loading usbserial with the appropriate parameters, however that is not being executed.

I now have the modem working reliably after I created /etc/modprobe.d/usbserial.conf with this in it:

Code:
options usbserial vendor=0x19d2 product=0x1010


Regards,
Barry Kauler


Offline Profile WWW
PostPosted: Thu Dec 09, 2010 9:12 am
Site AdminPosts: 4905Joined: Sat Nov 03, 2007 12:30 am
The Linux USB developers are discouraging from using "usbserial" directly. The "option" driver is optimized for high speed serial connections; and since kernel 2.6.27 it has the ability to take new device IDs at runtime. So this is what I'm using for modems not known to any driver yet.

Only if this approach does not work (no module or kernel too old) the "usbserial" fallback will kick in.

I would have to see the log of failed switch (no driver binding) to determine the cause.

If you want to try the binding procedure for "option" manually, load the module and say:
Code:
echo "19d2 1010" > /sys/bus/usb-serial/drivers/option1/new_id

One more thing: is there any possibilty for me to get my hand on the binary "libusb" file that you are using ? I would really like to be able to reproduce your problem here.



Offline Profile
PostPosted: Thu Dec 09, 2010 11:05 am
Posts: 11Location: AustraliaJoined: Tue Dec 07, 2010 2:52 pm
Josh,
I have emailed the binary libusb to you.

Regards,
Barry Kauler


Offline Profile WWW
PostPosted: Thu Dec 09, 2010 9:30 pm
Site AdminPosts: 4905Joined: Sat Nov 03, 2007 12:30 am
Thanks for these. I installed them and tested all my modems with it, on two kernels (2.6.34.1 and 2.6.35.7), to no avail - everything's working without a hitch ...

I am going to try all my machines and find out if I can provoke what you are seeing.



Offline Profile
PostPosted: Fri Dec 10, 2010 12:03 am
Posts: 11Location: AustraliaJoined: Tue Dec 07, 2010 2:52 pm
Ah, I wonder... I am using kernel 2.6.31.14.

Wary Puppy is using an older kernel as that is the most recent that is able to compile our full suite of analog dialup modem drivers. Wary is intended to support older hardware, including those still using analog modem dialup.

Not the most recent udev either: version 151.

I will be uploading the latest Wary in a few days, so if you wish, you can grab that to test. It is the usual small approx 100MB live-CD (actually, the old analog modem drivers are huge, bulk the live-CD iso file out to 123MB).

Regards,
Barry Kauler


Offline Profile WWW

Display posts from previous:  Sort by:

All times are UTC + 1 hour [ DST ]
Page 1 of 1
11 posts
Users browsing this forum: Google [Bot] and 1 guest
Search for:
Post new topic  Reply to topic
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum