open https://gitlab.synchro.net/main/sbbs/-/issues/813

When I run freshly downloaded sexpots with my USRobotics modem on Linux, try as I may the commands never get sent to the modem. When I use screen, minicom, or mgetty the modem works. And when I copy my sexpots.ini file to Windows and use sexpots.exe, it works perfectly. Is there anything I can do to fix this? Thank you.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5884

root 695252 1 0 Oct18 ttyACM0 03:07:23 /usr/local/bin/sexpots /usr/local/etc/sexpots-line1.ini -syslog=sexpots-line1
root 695253 1 0 Oct18 ttyACM1 03:07:03 /usr/local/bin/sexpots /usr/local/etc/sexpots-line2.ini -syslog=sexpots-line2
root 695254 1 0 Oct18 ttyACM2 03:06:46 /usr/local/bin/sexpots /usr/local/etc/sexpots-line3.ini -syslog=sexpots-line3
root 695255 1 0 Oct18 ttyACM3 03:07:17 /usr/local/bin/sexpots /usr/local/etc/sexpots-line4.ini -syslog=sexpots-line4
root 695256 1 0 Oct18 ttyUSB0 03:03:39 /usr/local/bin/sexpots /usr/local/etc/sexpots-local.ini -syslog=sexpots-local -null -baud 9600


works just fine here, both for modem and serial port. Can you paste your .ini file maybe?

Also, do the sexpots permissions permit access to the modem?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5884

```
root 695252 1 0 Oct18 ttyACM0 03:07:23 /usr/local/bin/sexpots /usr/local/etc/sexpots-line1.ini -syslog=sexpots-line1
root 695253 1 0 Oct18 ttyACM1 03:07:03 /usr/local/bin/sexpots /usr/local/etc/sexpots-line2.ini -syslog=sexpots-line2
root 695254 1 0 Oct18 ttyACM2 03:06:46 /usr/local/bin/sexpots /usr/local/etc/sexpots-line3.ini -syslog=sexpots-line3
root 695255 1 0 Oct18 ttyACM3 03:07:17 /usr/local/bin/sexpots /usr/local/etc/sexpots-line4.ini -syslog=sexpots-line4
root 695256 1 0 Oct18 ttyUSB0 03:03:39 /usr/local/bin/sexpots /usr/local/etc/sexpots-local.ini -syslog=sexpots-local -null -baud 9600
```

works just fine here, both for modem and serial port. Can you paste your .ini file maybe?

Also, do the sexpots permissions permit access to the modem?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5885

"Freshly downloaded" from where? Please include the version information displayed when running sexpots, e.g.
```
Synchronet External POTS Support/Linux v2.0 Copyright 2024 Rob Swindell https://gitlab.synchro.net - master/803ef7605 Nov 04 2024 15:24
```
And for that matter, the output of sexpots when it's run on Linux and you have this issue would be helpful as well.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5886

Right, here is my \`.ini file:

```
LogLevel = INFO
Debug = TRUE
PauseOnExit = FALSE
CLS = TRUE
Prompt = "Welcome"
PromptTimeout = 60

[COM]
Device = /dev/ttyUSB1
BaudRate = 115200
Hangup = TRUE
IgnoreDCD = FALSE
DCDTimeout = 10
DTRDelay = 100
NullModem = FALSE
Parity = FALSE
ParityOdd = FALSE
ByteSize = 8
StopBits = 1

[Modem]
Init = ATZ
AutoAnswer = ATS0=1
CleanUp = ATS0=0
EnableCallerID = AT+VCID=1
Timeout = 30
ReInit = 10
Answer = ATA
Ring = RING
ManualAnswer = TRUE

[TCP]
Host = 127.0.0.1
Port = 23
NoDelay = TRUE
Telnet = TRUE

[Telnet]
Debug = FALSE
AdvertiseLocation = FALSE
TermType = SEXPOTS
TermSpeed = 28800,28800

[Ident]
Enabled = FALSE
Port = 113
Interface = 0
Response = CALLERID:SEXPOTS
```
And yeah, I tried doing a `chmod 777` on the modem's `/dev` entry for testing but it still doesn't seem to be able to send commands.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5887

Sure, the version info is:
```
Synchronet External POTS Support/Linux v2.0 Copyright 2024 Rob Swindell https://gitlab.synchro.net - master/ba8fdb5a7 Oct 17 2024 00:37
```

and the output from running it is:
```
11/5 16:41:20 Reading ./sexpots.ini
11/5 16:41:20 Synchronet Communications I/O Library for Linux v1.19
11/5 16:41:20 Build Oct 17 2024 13:39:37 GCC 11.4.1
11/5 16:41:20 TCP Host: 127.0.0.1
11/5 16:41:20 TCP Port: 23
11/5 16:41:20 Opening Communications Device (COM Port): /dev/ttyUSB1
11/5 16:41:20 COM Port device handle: 3
11/5 16:41:20 COM Port DTE rate: 115200 bps
11/5 16:41:20 Initializing modem:
11/5 16:41:20 Modem Command: ATZ
11/5 16:41:20 Waiting for Modem Response ...
11/5 16:41:50 Modem Response TIMEOUT (30 seconds) on /dev/ttyUSB1
11/5 16:41:50 Retry #1: sending modem command (ATZ) on /dev/ttyUSB1
11/5 16:41:50 Dropping DTR on /dev/ttyUSB1
11/5 16:41:50 Raising DTR on /dev/ttyUSB1
11/5 16:41:50 Modem Command: ATZ
11/5 16:41:50 Waiting for Modem Response ...
11/5 16:42:20 Modem Response TIMEOUT (30 seconds) on /dev/ttyUSB1
11/5 16:42:20 Retry #2: sending modem command (ATZ) on /dev/ttyUSB1
11/5 16:42:20 Dropping DTR on /dev/ttyUSB1
11/5 16:42:20 Raising DTR on /dev/ttyUSB1
11/5 16:42:20 Modem Command: ATZ
11/5 16:42:20 Waiting for Modem Response ...
11/5 16:42:50 Modem Response TIMEOUT (30 seconds) on /dev/ttyUSB1
11/5 16:42:50 Modem command (ATZ) failure on /dev/ttyUSB1 (3 attempts)
11/5 16:42:50 Cleaning up ...
11/5 16:42:50 Done (handled 0 calls).
```
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5886

Right, here is my \`.ini file:

```
LogLevel = INFO
Debug = TRUE
PauseOnExit = FALSE
CLS = TRUE
Prompt = "Welcome"
PromptTimeout = 60

[COM]
Device = /dev/ttyUSB1
BaudRate = 115200
Hangup = TRUE
IgnoreDCD = FALSE
DCDTimeout = 10
DTRDelay = 100
NullModem = FALSE
Parity = FALSE
ParityOdd = FALSE
ByteSize = 8
StopBits = 1

[Modem]
Init = ATZ
AutoAnswer = ATS0=1
CleanUp = ATS0=0
EnableCallerID = AT+VCID=1
Timeout = 30
ReInit = 10
Answer = ATA
Ring = RING
ManualAnswer = TRUE

[TCP]
Host = 127.0.0.1
Port = 23
NoDelay = TRUE
Telnet = TRUE

[Telnet]
Debug = FALSE
AdvertiseLocation = FALSE
TermType = SEXPOTS
TermSpeed = 28800,28800

[Ident]
Enabled = FALSE
Port = 113
Interface = 0
Response = CALLERID:SEXPOTS
```
And yeah, I tried doing a `chmod 777` on the modem's `/dev` entry for testing but it still doesn't seem to be able to send commands.
Also note, when it worked on Windows, I used the exact same config file, save for the `Device` line.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5888

USRobotics makes a USB modem? Or it's an external modem connected with a USB<->RS-232 adapter?

If other programs (e.g. minicom) work, then certainly SexPOTS can be made to work (likely through modification of the C source code). I'll add more follow-up questions shortly to hopefully understand more about how/why those other programs work fine with the same serial port/modem.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5889

It is a USB to RS232 adapter, they do make USB modems though. I was debating getting one to try using for this.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5890

Try commenting out the `BaudRate = 115200` line in your sexpots.ini file and see if that makes any difference.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5891

Also, if you could provide the output of `stty -F /dev/ttyUSB1 -a`, that could be helpful.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5892

With the BaudRate line commented it shows 0 bps (as expected) but still doesn't achieve communication with the modem.
The output of that command is as follows:
```
speed 0 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc
```
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5893

Can you provide the output of `setserial -a /dev/ttyUSB1`?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5894

Sure,
```
/dev/ttyUSB1, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 24000000, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal
```
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5895

maybe experiment with other baud rate settings in the sexpots.ini or passed no the sexpots command-line?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5895

maybe experiment with other baud rate settings in the sexpots.ini or passed on the sexpots command-line?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5896

I used `sexpots -baud` with a for loop in bash with a couple common baud rates:
`for speed in 1200 2400 4800 9600 19200 38400 57600 115200 ; do ./sexpots -baud $speed ; done`
None of these speeds worked. What might have caused this to work on Windows where it doesn't on Linux? Is there anything I might try changing about my environment?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5896

I used `sexpots -baud` with a for loop in bash with a couple common baud rates:
`for speed in 1200 2400 4800 9600 19200 38400 57600 115200 ; do ./sexpots -baud $speed ; done`.
None of these speeds worked. What might have caused this to work on Windows where it doesn't on Linux? Is there anything I might try changing about my environment?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5899

Do you see (e.g. LED lights blinking) or hear (e.g. clicking) anything happening with the modem when sexpots is trying to initialize the modem?

I'm trying to determine if this is a send/write issue or a receive/read issue. --- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5900

Good question actually. I just tried it and the modem's serial send/receive lights don't blink at all, which they normally do (e.g. using screen or minicom).
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5901

I use 4 USR5637 modems connected to a USB hub connected to my PC and they work well. Stupid question, your modem is actually /dev/ttyUSB1 right?

Are there any switches on your modem? If so you could see if there's one to turn off hardware handshaking. If you're not seeing lights on the modem then it would suggest that DSR/DTR aren't set correctly for you to send to the modem for some reason.

fwiw, my setserial is slightly different.

```
# setserial -a /dev/ttyACM0
/dev/ttyACM0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0
Baud_base: 0, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal
```

Your Baud_base looks a little on the high side.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5902

Yeah, I have another USR modem for answering PPP calls which is ttyUSB0. There are switches on the modem, however none of them are for changing flow control settings. There *are* however settings accessible by AT commands for that, which I have not tried changing. That being said, the modem used for PPP calls is using the same USB to serial adapter and is a very very similar modem to the one I'm using for sexpots, and the software for answering that modem does just fine with hardware flow control. I've copied all the settings over one-by-one and even tried swapping the two modems to no avail.

How would I change the Baud_base setting?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5902

Yeah, I have another USR modem for answering PPP calls which is ttyUSB0.

There are switches on the modem, however none of them are for changing flow control settings. There *are* however settings accessible by AT commands for that, which I have not tried changing. That being said, the modem used for PPP calls is using the same model of USB to serial adapter and is a very very similar modem to the one I'm using for sexpots, and the software for answering that modem does just fine with hardware flow control. I've copied all the settings over one-by-one and even tried swapping the two modems to no avail.

How would I change the Baud_base setting?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5904

Try setserial /dev/ttyUSB1 baud_base 115200

fwiw, I don't specify the baud rate for the modem, only the direct serial connection, when running sexpots.

```
root 695252 1 0 Oct18 ttyACM0 03:07:23 /usr/local/bin/sexpots /usr/local/etc/sexpots-line1.ini -syslog=sexpots-line1
root 695253 1 0 Oct18 ttyACM1 03:07:03 /usr/local/bin/sexpots /usr/local/etc/sexpots-line2.ini -syslog=sexpots-line2
root 695254 1 0 Oct18 ttyACM2 03:06:46 /usr/local/bin/sexpots /usr/local/etc/sexpots-line3.ini -syslog=sexpots-line3
root 695255 1 0 Oct18 ttyACM3 03:07:17 /usr/local/bin/sexpots /usr/local/etc/sexpots-line4.ini -syslog=sexpots-line4
root 695256 1 0 Oct18 ttyUSB0 03:03:39 /usr/local/bin/sexpots /usr/local/etc/sexpots-local.ini -syslog=sexpots-local -null -baud 9600
```

Still, maybe bringing the baud_base setting down may help.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5905

Well I did try changing that setting, but the baud_base value reported isn’t changing. I’ll be leaving home soon so I don’t want to mess with the modem right now, but later I’ll try messing with hardware/software flow control to see if that makes any difference.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5906

I looked up the commands for modifying flow control, my modem provides `AT&F1` for using the factory settings with hardware flow control, and `AT&F2` for software. I loaded both and immediately ran sexpots with no luck on either.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5907

Which LED lights are lit and not lit on your modem when:
1. it's working with software (e.g. minicom)
2. it's not working with sexpots

?

I'm particularly interested in the TR/DTR light (if it has one).

This might give us a clue.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5908

The lights on the modem are as follows: AA/Auto Answer, CD/Carrier Detect, RD/Receive Data, SD/Send Data, TR/Terminal Ready, CS/Clear to Send, and ARQ/Error Control.
When I turn off the modem at its switch, turn it back on, and run minicom, by default only TR and CS are on. When I type any character, the RD and SD lights blink shortly at the same time.
When I run sexpots, nothing changes about the lights from the default state of TR and CS being lit.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5909

One thing to note is that there's a switch on the modem for "Data Terminal Ready Override" which, if set to off, prevents me from interacting with the modem using *any* software.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5909

One thing to note is that there's a switch on the modem for "Data Terminal Ready Override" which, if set to off, prevents me from interacting with the modem using *any* software. I can still send characters to it, but commands don't get run when pressing enter and it doesn't send any output back for anything.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5910

The log output: `11/5 16:41:20 COM Port DTE rate: 115200 bps` is an indicator that SexPOTS is successfully changing the port bit rate when instructed to do so, so that's likely not the issue.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5911

A likely area of the cause of issue is `comOpen()` in `src/comio/comio_nix.c`.

If you don't mind experimenting, you could print out the values returned from `tcgetattr()`, by modifying this code in `comio_nix.c`, e.g. adding
```
printf("c_iflag = %x\n", t.c_iflag);
printf("c_oflag = %x\n", t.c_oflag);
printf("c_cflag = %x\n", t.c_cflag);
printf("c_lflag = %x\n", t.c_lflag);
```
At about line 218, before any changes to these values are made. This would be particularly interesting to see *after* running any programs that successfully communicate with the modem (e.g. minicom).

I would expect the `write()` function calls from this same file to be failing (i.e. from `comWriteByte()` which is used when sending commands to the modem from sexpots), but based on the log output you pasted here, no errors are seen. Instrumenting `comWriteByte()` might provide some sanity checking:
e.g.
```
bool comWriteByte(COM_HANDLE handle, BYTE ch)
{
int ret = write(handle, &ch, 1);
printf("write returned %d\n", ret);
return ret==1;
}
```
In working scenario, that should just print a bunch of "write returned 1" lines to stdout. Any value other than 1 would be interesting.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5912

BTW, I suspect the issue has more to do with the serial port / USB adapter (and/or device driver) than the modem. That same modem with a different serial port would probably work fine. I'm not saying there's nothing to be fixed in sexpots (or the Synchronet comio library) to accommodate that serial port. If you could provide details on this USB serial port/adapter (I have a few USRobotics external modems already), I could purchase one for myself and make quicker debug of the issue.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5913

1: I can't say I know what I'm doing in C but I managed to modify that file and rebuild it, and when I run sexpots I get this:

```
c_iflag = 406
c_oflag = 0
c_cflag = 18b2
c_lflag = 8a30
```

Also, the returns on `comWriteByte()` are indeed all 1.

The adapter very well might be at fault here, the issue I found when ordering it was that the modem has a female DB25 connector which I couldn't find on any other adapter. It's an FTDI chip, [here](https://www.amazon.com/dp/B08J2VMNFY) is the Amazon listing.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5913

1: I can't say I know what I'm doing in C but I managed to modify that file and rebuild it, and when I run sexpots I get this:

```
c_iflag = 406
c_oflag = 0
c_cflag = 18b2
c_lflag = 8a30
```

Also, the returns on `comWriteByte()` are indeed all 1.

2: The adapter very well might be at fault here, the issue I found when ordering it was that the modem has a female DB25 connector which I couldn't find on any other adapter. It's an FTDI chip, [here](https://www.amazon.com/dp/B08J2VMNFY) is the Amazon listing.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5914

If it's useful, the software I'm using on my first modem to handle PPP calls is mgetty. I had to contact the maintainer for troubleshooting but eventually got things working.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5919

Thanks. I ordered one of those cables. If we can't root-cause and resolve the issue through this discussion, I'll have some hands-on debugging with it this weekend.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5920

Is your first modem using the same USB<->serial adapter cable?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5921

Mhm, same model, I did try swapping them as well.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5922

Wow, thank you! I appreciate the dedication
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5923

Did the mgetty maintainer have to make any code changes or provide special configuration or usage instructions to accommodate the serial cable?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5924

Actually yes, digging into my email history, he had me edit the `policy.h` file and switch the line `#define DATA_FLOW FLOW_HARD` to `FLOW_SOFT`. However I do remember one time after that started working, I accidentally ran the OS packaged version using hardware flow control and that worked. I don’t really know what’s going on here to be honest.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5932

I received the serial/USB cable/adapter today from Amazon.

I have 4 USRobotics external modems with which to test:
1. Courier V.92 (model 5686G, circa 2006)
2. Courier 56K Business Modem (model 3453B, circa 2004)
3. Sportster 56K (model 0701, circa 1998)
4. Sportster 56K (model 0701, circa 1998, Canadian version)

On Debian Linux 12.7, initially only the Courier 56K initially worked with sexpots (notably, its DTR light was lit at first), but after unplug/replugging the serial cable, this modem's DTR light light would not light and it would not respond to AT commands: I tried screen, minicom, and of course sexpots. The other modems never would respond to AT commands and their TR (aka DTR) lights never lit except to briefly flash during sexpots attempted initialization.

Sexpots makes the appropriate ioctl calls to raise DTR before sending commands to the modem, so it is weird that the signal doesn't seem to be working as normal through this cable. With that as a clue, I flipped the modem's dip switch 1 down (for "DTR always on" or "DTR override", same difference), and after doing so, minicom and sexpots were able to communicate with each modem. This is not a "solution" as it would prevent sexpots from reliably disconnecting the modem-connected terminal by dropping DTR, but it is a big clue: we need DTR to work normally.

I've yet to test this cable with Windows, but I'll do that and continue to play with different Linux software and changes to sexpots (and the Synchronet "comio" library that is uses) and see if I can get the DTR signal (modem lights) to react as expected.

I suspect it might have something to do with the driver trying enable/use DSR/DTR hardware flow control, but querying the driver and making the appropriate calls to force it to CTS/RTS hardware flow control (which it reports it is already using) doesn't seem to be a fix.

I'll continue playing with it.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5933

Ha! I plugged this USB/serial adapter into my Windows (11) system and the device driver name for the newly created COM port becomes "PL203TA DO NOT SUPPORT WINDOWS 11 OR LATER, PLEASE CONTACT YOUR SUPPLIER" [sic].

... so I won't be testing this on Windows I guess. :shrug:
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5934

The modem I have is also a 5686G, so that's probably most accurate for testing. That's really weird that it worked once and then stopped. I have been using it with dip switch 1 down the whole time, and tools like minicom work but sexpots doesn't for me.

Also, I didn't happen to notice the device name, but it did work for me on Windows 11, I'd say give it a shot. That is pretty funny though!
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5935

I couldn't open COM4 with it (the port that reported being created on Windows). Did you download any additional Windows drivers for it or just plug and play?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5936

Since I don't really see any difference in behavior with the modems and this USB/Serial adapter, I don't think the modem is a factor. Dip-switch 1 down allows the modem to receive and respond to AT commands (with all of them), but would be a problem for sexpots since it couldn't disconnect the caller in that configuration. Dip-switch 1 defaults to up (off, "DTR normal") for all of these modems - so you changed it or bought it that way?
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5938

Hmm, I don't think I downloaded any drivers but I'm not entirely sure. There's 4 drivers listed for the cable, all within system32, but 3 of them have FTDI listed as the "provider". I'm not sure if these came with the system or not. If it would help I can attach screenshots.

And I agree that the modem isn't the problem here. I don't remember how the switch was when I bought it but I remember messing with it when I first got it and noticing quickly that I couldn't interact with it properly without that switch down. Maybe if I had a *normal* cable I wouldn't need that.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5939

Focusing on Linux, if I raise (set) and lower (clear) DTR and query the driver via IOCTL calls, it always reports the signal in the state I set, but yet the modem's TR/DTR light doesn't reflect it (it's always off, though I swear sometimes I see it briefly flash). I haven't tried a break-out box or multimeter to see what's happening with the actual pin on the DB25 connector, but maybe the DTR line just isn't changing to the right voltage. I wonder if there's some extended or advanced configuration somewhere to control that... the mystery continues.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5940

And BTW, for me, minicom and screen working/not-working with the modem always matches sexpots success or failure. When sexpots is working (initializing the modem), minicom and screen can too, and when sexpots isn't working, neither do they.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5941

1: I'm wondering if I should just try ordering some other kind of cable. I had found another one in my initial search, but it was USB to DB9 and then DB9 to DB25.

2: That's weird. Are you using one of the default profiles from the modem's ROM? Also, what are your other di switches set to? Maybe I can mimic your setup.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5941

1: I'm wondering if I should just try ordering some other kind of cable. I had found another one in my initial search, but it was USB to DB9 and then DB9 to DB25.

2: That's weird. Are you using one of the default profiles from the modem's ROM? Also, what are your other dip switches set to? Maybe I can mimic your setup.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5942

Maybe compare your device manager settings in windows and see if you're using the same driver files.

In Linux check your dmesg because the driver may be a different version depending on the kernel version.

Later tomorrow i can try my modem and serial adapter and see what results i get, it may or may not help.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5953

I plugged the USB/serial adapter into a Windows 10 system and was able to use the port (e.g. with SyncTERM) via COM4 and it presents exactly the same problem I see with the Linux driver: the DTR signal is not raised and so the modem(s) won't respond unless I change dip switch 1 to "DTR always on/override".

I did purchase an RS-232 breakout/tester that it'll be here to tomorrow (I certainly have owned one or two of these over the years, but couldn't find one in my stash). I don't have high hopes that it's a device driver issue or even really resolvable via software at this point.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5954

Well if that holds true, I’ll try ordering another cable (I really like modems with a speaker so I’m reluctant to just get a USB dongle modem). I did think of a temporary sort of solution, in which I instructed mgetty to spawn a telnet process if I log in with the username “bbs”. Not perfect but pretty good!

As for the driver issue, I’ll be home within a few hours, I can attach output from dmesg and screenshots of the drivers dialog on Windows then.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5955

My experience with USB dongle modems is not good. The USRobotics are really the best of the best in terms of compatibility and reliability.

But even with mgetty, if you flip dip-switch 1 down (to force DTR always on), mgetty won't be able to disconnect the modem user/caller either. That's not really a solution.
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/813#note_5965

Fair enough. Thank you for all your help, I really appreciate it!
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

close https://gitlab.synchro.net/main/sbbs/-/issues/813
--- SBBSecho 3.21-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)