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.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
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.
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.
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.
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.
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.
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.
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:
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?
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.
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).
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.
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.
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.
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.
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 is the Amazon listing.
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.
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.
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.
I received the serial/USB cable/adapter today from Amazon.
I have 4 USRobotics external modems with which to test:
Courier V.92 (model 5686G, circa 2006)
Courier 56K Business Modem (model 3453B, circa 2004)
Sportster 56K (model 0701, circa 1998)
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.
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.
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!
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?
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?
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.
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.
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.
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.
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.
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.
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.
I received the RS-232 breakout tester today and it confirms what the modem lights (and behavior) report: the DTR signal doesn't work correctly on this USB/serial adapter cable.
I don't have any explanation for why sexpots-Linux is able to initialize the modem (when set to DTR always on/override via dip-switch) for me but not for you. Here are my Linux driver details for this USB/serial adapter as reported by dmesg:
[372590.584647] usb 1-6: new full-speed USB device number 9 using xhci_hcd[372590.733459] usb 1-6: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00[372590.733463] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0[372590.733464] usb 1-6: Product: USB-Serial Controller[372590.733464] usb 1-6: Manufacturer: Prolific Technology Inc.[372590.734607] pl2303 1-6:1.0: pl2303 converter detected[372590.735161] usb 1-6: pl2303 converter now attached to ttyUSB0
But without proper DTR control, this adapter cable is kind of useless for sexpots anyway (whether the modem can be initialized or not).
It was fun to break out the modems again to play with this and it did result in a couple of bugs found and fixed in sexpots for *nix:
Signals (e.g. Ctrl-C keypress) weren't be handled and (others) ignored
Port baud rate of 0 was being set by default (on Linux)
Unfortunately, these bug fixes bring you no closer to getting sexpots to work with this/that cable.
Since I observed the same DTR problem with the Windows driver and you said that you had to flip the DTR dip-switch to get it to work on Windows as well, that just confirms this is a bad USB/serial adapter and shouldn't be used for modems.
We gave it a shot, thank you for your patience and information, but I think I'll be closing this issue since it doesn't appear there's any more I can do with it.