RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 868309 - KVM guest unable to reliably communicate with USB modem (MT9234ZBA-USB-CDC)
Summary: KVM guest unable to reliably communicate with USB modem (MT9234ZBA-USB-CDC)
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-19 13:28 UTC by James B. Byrne
Modified: 2016-04-15 11:43 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-15 11:43:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description James B. Byrne 2012-10-19 13:28:06 UTC 
Description of problem:
A guest vm can connect to, but not reliably communicate with, a MultiTech MT9234ZBA-USB-CDC modem that has been passed through the host to the guest using virt-manager -> add hardware => usb


Version-Release number of selected component (if applicable):
 qemu-kvm-0.12.1.2-2.295.el6_3.2.src.rpm
 virt-manager-0.9.0-14.el6.src.rpm


How reproducible:
Always


Steps to Reproduce:
1. Add USB modem to host. Verify connection from host with terminal emulator (picocom)
2. Add USB Modem to virtual guest and restart guest.
3. Verify connection from guest with terminal emulator (picocom)
4. USe wvdialconf to find modem
  

Actual results:

From guest connection to modem from picocom -b 115200 /dev/ttyACM0 causes modem TR to go high. However ATI command returns string of non-displayable characters similar to that encountered with a baud rate mismatch.

Wvdialconf can find modem but cannot communicate with it:

<pre>
Editing `/etc/wvdial.conf'.

Scanning your serial ports for a modem.

ttyS0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud
ttyS0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud
ttyS0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up.
Modem Port Scan<*1>: S1   S2   S3
WvModem<*1>: Cannot get information for serial port.
ttyACM0<*1>: ATQ0 V1 E1 -- OK
ttyACM0<*1>: ATQ0 V1 E1 Z -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK
ttyACM0<*1>: Modem Identifier: ATI -- Agere OCM V.92 MT9234ZBA-USB
Data/Fax Modem Version 1.02l
ttyACM0<*1>: Speed 4800: AT -- OK
ttyACM0<*1>: Speed 9600: AT -- OK
ttyACM0<*1>: Speed 19200: AT -- OK
ttyACM0<*1>: Speed 38400: AT -- OK
ttyACM0<*1>: Speed 57600: AT -- OK
ttyACM0<*1>: Speed 115200: AT -- OK
ttyACM0<*1>: Speed 230400: AT -- OK
ttyACM0<*1>: Speed 460800: AT -- Speed 460800: AT -- Speed 460800: AT
-- Max speed is 230400; that should be safe.
ttyACM0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- and failed too at
115200, giving up.

Sorry, no modem was detected!  Is it in use by another program?
Did you configure it properly with setserial?
</pre>

Expected results:
Should be able to communicate with modem via terminal emulator and issue AT commands.  Wvdialconf should be able to configure /etc/wvdial.conf/.

Additional info:
Comment 3 Ademar Reis 2012-10-22 13:01:58 UTC 
Deferring to RHEL7 because this is a complex fix.
Comment 8 Gerd Hoffmann 2013-05-14 13:36:47 UTC 
Any chance you can retest with upstream qemu 1.5 (-rc or final)?
Comment 9 James B. Byrne 2013-05-14 14:12:43 UTC 
Where do I get the software and is it installed via yum/rpm?  If so then yes I can certainly modify at test KVM and test the modem.
Comment 10 Ronen Hod 2013-10-30 10:06:27 UTC 
Hi James,

Thank you for taking the time to enter a bug report with us. We appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to  guarantee the timeliness or suitability of a resolution.
 
If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain  it receives the proper attention and prioritization to assure a timely resolution. 
 
For information on how to contact the Red Hat production support team, please visit:
https://www.redhat.com/support/process/production/#howto
Comment 12 Hans de Goede 2013-10-30 13:06:55 UTC 
This should really be retested with RHEL-7, there are a lot of fixes in RHEL-7 which could / should help.
Comment 13 James B. Byrne 2013-11-18 17:43:04 UTC 
(In reply to Ronen Hod from comment #10)
> Hi James,
> 
> Thank you for taking the time to enter a bug report with us. We appreciate
> the feedback and look to use reports such as this to guide our efforts at
> improving our products. That being said, this bug tracking system is not a
> mechanism for requesting support, and we are not able to  guarantee the
> timeliness or suitability of a resolution.

I was not looking for support.  At the time I had access to a suitable modem and system to test any changes had I been given some precise guidance as to what software to test and where to obtain it.  That window of opportunity has now closed and I am unable to do so.
Comment 23 Gerd Hoffmann 2016-04-15 11:43:32 UTC 
usb passthrough code has been put upside down (rewritten to use libusb) since this was reported.  So it's not clear at all whenever the issue is still present.

Given the original reporter can't test this any more and we don't own the
hardware in question I'm going to close this now.  Feel free to re-open if
there are new informations.
Note You need to log in before you can comment on or make changes to this bug.