From owner-freebsd-stable@freebsd.org Tue Mar 1 20:50:24 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB512ABEB14 for ; Tue, 1 Mar 2016 20:50:24 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2BD8172A for ; Tue, 1 Mar 2016 20:50:24 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6eb370b2-dfef-11e5-8de6-958346fd02ba X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 1 Mar 2016 20:51:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u21KoEae014361; Tue, 1 Mar 2016 13:50:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1456865414.13785.119.camel@freebsd.org> Subject: Re: Problems with ucom/uftdi and sendfax on 10.2 p12 (works like a charm with 7.4) From: Ian Lepore To: Holger Kipp , "freebsd-stable@freebsd.org" Date: Tue, 01 Mar 2016 13:50:14 -0700 In-Reply-To: References: Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 20:50:24 -0000 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, > uftdi). > > 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@faxserver:/usr/local/etc/mgetty+sendfax # tip modem4 > connected > AT+FDT > CONNECT > > +FHS:43 > > OK > AT+FCLASS=0 > OK > ~ > [EOT] > root@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, > Holger 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. :) -- Ian