Problems with ucom/uftdi and sendfax on 10.2 p12 (works like a charm with 7.4)
ian at freebsd.org
Tue Mar 1 20:50:24 UTC 2016
On Tue, 2016-03-01 at 19:58 +0000, Holger Kipp wrote:
> Hi all,
> I currently encounter a problem with sending faxes with new server
> and FreeBSD 10.2-RELEASE p12
> using mgetty+sendfax and RS232-Modems via USB to RS232-Adapter (com,
> Problem is that _after_ sending the first page, the reply of modem is
> not read correctly.
> In Error case, Faxlog says:
> 02/29 18:46:10 aU4 read 64, write 64
> 02/29 18:46:10 aU4 read 52, write 52
> 02/29 18:46:10 aU4 page complete, 40900 bytes sent
> 02/29 18:46:10 aU4 sending DLE ','
> 02/29 18:46:10 aU4 got:[0a][0d][0a]OK[0d]
> 02/29 18:46:18 aU4 got response: 'OK'
> 02/29 18:46:18 aU4 fax_send_page("f2.g3") started...
> 02/29 18:46:18 aU4 tio_set_flow_control( HARD )
> 02/29 18:46:18 aU4 fax_send: 'AT+FDT'
> 02/29 18:46:18 aU4 fax_wait_for(CONNECT)
> 02/29 18:46:18 aU4 got:[0a]
> 02/29 18:48:18 aU4 Warning: got alarm signal!
> So I run into timeout because the modem does not reply as expected
> after AT+FDT-command (maybe even after sending DLE ',‘ because the OK
> response seems to take some more time than under FreeBSD 7.4).
> if I issue "tip modem4" (which is /dev/cuaU4), I get the missing
> replies including CONNECT from the modem (then leaving tip with "~.“)
> root at faxserver:/usr/local/etc/mgetty+sendfax # tip modem4
> root at faxserver:/usr/local/etc/mgetty+sendfax #
> This works correctly with same modems and USB to RS232-Adapter
> (uftdi) under FreeBSD 7.4.
> 02/29 12:18:26 aU4 receiver cap.: '+FIS:1,5,0,2,1,1,0,3' -> fine 144
> 2D/MR ECM** found **
> 02/29 12:18:26 aU4 sendfax: IGNORE DCD (carrier) status
> 02/29 12:18:26 aU4 fax_send: 'AT+FDT'
> 02/29 12:18:26 aU4 fax_wait_for(CONNECT)
> 02/29 12:18:33 aU4 transmission par.: '+FCS:1,5,0,2,0,0,0,3'** found
> 02/29 12:18:33 aU4 sending f1.g3...
> 02/29 12:19:04 aU4 page complete, 34495 bytes sent
> 02/29 12:19:04 aU4 sending DLE ','
> 02/29 12:19:10 aU4 got response: 'OK'
> 02/29 12:19:10 aU4 fax_send: 'AT+FDT'
> 02/29 12:19:10 aU4 fax_wait_for(CONNECT)** found **
> 02/29 12:19:11 aU4 sending f2.g3...
> 02/29 12:19:55 aU4 page complete, 60064 bytes sent
> 02/29 12:19:55 aU4 sending DLE ','
> 02/29 12:20:01 aU4 got response: 'OK'
> 02/29 12:20:01 aU4 fax_send: 'AT+FDT'
> 02/29 12:20:01 aU4 fax_wait_for(CONNECT)** found **
> 02/29 12:20:01 aU4 sending f3.g3...
> 02/29 12:20:52 aU4 page complete, 71335 bytes sent
> 02/29 12:20:52 aU4 sending DLE ','
> 02/29 12:20:57 aU4 got response: 'OK'
> 02/29 12:20:57 aU4 fax_send: 'AT+FDT'
> 02/29 12:20:57 aU4 fax_wait_for(CONNECT)** found **
> 02/29 12:20:58 aU4 sending f4.g3...
> 02/29 12:21:40 aU4 page complete, 58628 bytes sent
> 02/29 12:21:40 aU4 sending DLE '.'
> 02/29 12:21:49 aU4 connection hangup: '+FHS:00'
> 02/29 12:21:49 aU4 got response: 'OK'
> 02/29 12:21:49 aU4 fax_send: 'AT+FCLASS=0'
> This is with devolo 56k i ISDN-modems, but it looks more like a USB
> interface communication issue to me.
> Modems and USB-to-RS232 are the same - connected to FreeBSD 7.4
> servers works (sends all pages), connected to 10.2 server does not
> work (sends first page only).
> I can also provide dmesg.boot details on request but didn’t want to
> pollute the list.
> Difference with stty -a /dev/cuaU4 seems to be clocal instead of
> -clocal which I can’t set for cuaU4, only for .init and .lock. which
> does not help.
> 7.4 Kernel comes with uftdi and ucom compiled in.
> 10.2 Kernel has the same issues with ucom and uftdi loaded as kernel
> modules or compiled in.
> mgetty+sendfax is version 1.1.35_1 on FreeBSD 7.4 and version 1.1.37
> on FreeBSD 10.2-RELEASE p12.
> Any other ideas where to look further or what to investigate?
> Many thanks and best regards,
Seeing "tio_set_flow_control( HARD )>" in your output, along with the
fact that you said the expected output finally appeared after you
connected with tip, makes me suspect that flow control is at the root
of this problem.
The biggest ftdi driver difference before/after freebsd 8 is that the
driver used to automatically re-intialize the chip on every open to set
up some arbitrary combination of comms parameters (baud, flow control,
etc) -- I forget all the details now, I'd have to do some digging
through logs to find exactly what it used to set. Now the driver
leaves the chip alone at open time, and the contents of the
/dev/cuaU#.init and cuaU#.lock files should be completely in control of
the serial parameters.
Is it possible that you set up the .init and/or .lock devices in some
rc script in freebsd 7 and forgot about it? If not, then maybe the
driver init changes are enough to explain the glitch.
I wonder if this would fix it:
stty -f /dev/cuaU4.init crtscts
If so, then put that command into an rc script, or maybe into a devd
rule that runs whenever that usb-serial is attached.
If not... then I guess we'll figure out what to try next. :)
More information about the freebsd-stable