Hi everyone,
I've got a FreeBSD 12.1-RELEASE-p5 which will be used for some legacy but still needed modem/fax software. My problem with that is to hanging up dialed or answered connections. The application only supports to toggle DTR to hang-up established connections
So to mimic that behavior I run cu:
at the stage when "123456789 TEST" data is received from the other side, cu gets closed to trigger DTR signal (~. to quit cu) but after reconnecting new cu session to the modem it is still connected, so the modem did not drop the established connection due DTR drop (which is configured with &C1&D2 defaults that would set this behavior). Once connected again with cu, I do the same cu quit at the other side (actually same system, just executing cu against /dev/cuaU1 pointing to a FTDI base Serial-to-USB and physical serial attached USR Modem).
so the hardware with non-working DTR is:
while the FTDI that works is:
First, I thought that maybe the USB dongle Modem doesn't real have the DTR capability due its compact design, but connecting the same USB modem into MacOS or Linux and retry the same using e.g. cu the DTR toggle on exit works to hangup the connection.
Is there anything I might have overseen or need to setup for "umodem" devices to activate DTR capability? Apparently the H/W supports it and FreeBSD in general does seem to support DTR on the /dev/cuaUX devices.
Cheers,
Yze
I've got a FreeBSD 12.1-RELEASE-p5 which will be used for some legacy but still needed modem/fax software. My problem with that is to hanging up dialed or answered connections. The application only supports to toggle DTR to hang-up established connections
So to mimic that behavior I run cu:
Code:
cu -s 115200 -l /dev/cuaU0
ATDT123
CONNECT 33600/ARQ/V34/LAPM/V42BIS
~23456789 TEST data
[EOT]
root@freebielab:~ # cu -s 115200 -l /dev/cuaU0
Connected
NO CARRIERat the stage when "123456789 TEST" data is received from the other side, cu gets closed to trigger DTR signal (~. to quit cu) but after reconnecting new cu session to the modem it is still connected, so the modem did not drop the established connection due DTR drop (which is configured with &C1&D2 defaults that would set this behavior). Once connected again with cu, I do the same cu quit at the other side (actually same system, just executing cu against /dev/cuaU1 pointing to a FTDI base Serial-to-USB and physical serial attached USR Modem).
so the hardware with non-working DTR is:
Code:
ugen0.2: <U.S.Robotics USB Modem> at usbus0
umodem0 on uhub0
umodem0: <AltIf0> on usbus0
umodem0: data interface 1, has CM over data, has breakwhile the FTDI that works is:
Code:
ugen0.3: <FTDI FT232R USB UART> at usbus0
uftdi0 on uhub0
uftdi0: <FT232R USB UART> on usbus0First, I thought that maybe the USB dongle Modem doesn't real have the DTR capability due its compact design, but connecting the same USB modem into MacOS or Linux and retry the same using e.g. cu the DTR toggle on exit works to hangup the connection.
Is there anything I might have overseen or need to setup for "umodem" devices to activate DTR capability? Apparently the H/W supports it and FreeBSD in general does seem to support DTR on the /dev/cuaUX devices.
Cheers,
Yze