Bug 723346 - mgetty / vgetty can't communicate with my MT5634ZPX-PCI-V92
Summary: mgetty / vgetty can't communicate with my MT5634ZPX-PCI-V92
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: mgetty
Version: rawhide
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Michal Sekletar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-19 20:13 UTC by Ryan
Modified: 2013-03-19 19:01 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-19 19:01:02 UTC
Type: ---


Attachments (Terms of Use)
Log file with debug to high of vgetty process. (30.37 KB, text/plain)
2011-07-19 20:13 UTC, Ryan
no flags Details

Description Ryan 2011-07-19 20:13:22 UTC
Created attachment 513877 [details]
Log file with debug to high of vgetty process.

Description of problem:
When trying to run vgetty it can't get the modem to respond with an OK

Version-Release number of selected component (if applicable):
mgetty-voice-1.1.36-8.fc15.i686
mgetty-1.1.36-8.fc15.i686


How reproducible:
Install both packages, have a MT5634ZPX-PCI-V92 and try to use.  If need an account to a system can be provided.

Steps to Reproduce:
1. Install RPMs
2. run /sbin/vgetty <ttyS[0-9] of your modem>
3. Modem will not repond with OK
  
Actual results:
7/18 16:53:49 yS2  check for lockfiles
07/18 16:53:49 yS2  locking the line
07/18 16:53:50 yS2  lowering DTR to reset Modem
07/18 16:53:50 yS2  send: \d\d\d+++\d\d\dATH0&F[0d]
07/18 16:53:53 yS2  waiting for ``OK''
07/18 16:54:13 yS2  timeout in chat script, waiting for `OK'
07/18 16:54:13 yS2  init chat timed out, trying force-init-chat
07/18 16:54:13 yS2  send: \d[10][03]\d\d\d+++\d\d\d[0d]\dATQ0V1H0[0d]
07/18 16:54:17 yS2  waiting for ``OK''
07/18 16:54:37 yS2  timeout in chat script, waiting for `OK'
07/18 16:54:37 yS2  init chat failed, exiting...: Interrupted system call
07/18 16:54:37 ##### failed in mg_init_data, dev=ttyS2, pid=28171nstall RPMs

Attached full log

Comment 1 Fedora Admin XMLRPC Client 2011-08-08 08:12:58 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Michal Sekletar 2011-10-31 13:23:21 UTC
Hello, 

I've reported your issue upstream. Bottom line in log you've provided says "modem detection failed", it's because modem you are using is currently not supported by mgetty. There was discussion [1] about pretty much the same issue on mgetty newsgroup. Unfortunately I am unable to address this issue any further because lack of hardware itself. It seems like that implementing support for this particular modem won't be hard problem to solve, I hope we will resolve this issue upstream first afterwards I will re-base mgetty package or backport upstream patch. 

References: 
[1] http://www.alphanet.ch/~schaefer/cgi-bin/search.cgi?max_results=10&type=long&msgid=F41hRDT6Z3LstPGtPrP0000010b%40hotmail.com&domain=ml-mgetty

Comment 3 Ryan 2011-10-31 16:38:46 UTC
This modem is supported.  It work fine in prior versions of Fedora.

I've also been able to get it to function by removing hardware flow control and using software only. When it worked fine prior with hardware flow control.

--snip cmd--
[root@rnelnet mgetty-1.1.36]# diff /root/rpmbuild/SOURCES/mgetty-1.1.36/policy.h-dist /root/rpmbuild.fc10/SOURCES/mgetty-1.1.36/policy.h-dist 
416c416
< #define DATA_FLOW     FLOW_SOFT
---
> #define DATA_FLOW     FLOW_HARD
--end snip--

Aside from this being a hardware problem, which I'm unable to test due to only have this one modem.

So I'm not sure what to say, either close this or not.  It does work fine in minicom with hardware flow enabled.  So I lead to believe that its more of an mgetty+vgetty problem or a change in the kernel/serial driver.

Comment 4 Michal Sekletar 2011-11-01 13:31:52 UTC
Hello,

I'm sorry for mystification. I got confused by log. Removing HardwareEnablement keyword. I will keep this one open, your findings might by useful for someone else.

Comment 5 Michal Sekletar 2013-03-19 19:01:02 UTC
I don't know what might be the cause, since it worked fine with minicom while hardware flow control was enabled. I am closing this bug as CANTFIX. If this is still an issue feel free to reopen it. As mentioned previously, I don't have the hardware so probably I will be the little help here.


Note You need to log in before you can comment on or make changes to this bug.