TZUTC: -0800   
   MSGID: 56708.sync_sys@1:103/705 2b94dc94   
   PID: Synchronet 3.20a-Linux master/9d3a8113d Nov 04 202 GCC 12.2.0   
   TID: SBBSecho 3.21-Linux master/8aea7d593 Nov 06 2024 00:24 GCC 12.2.0   
   BBSID: VERT   
   CHRS: ASCII 1   
   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)   
   SEEN-BY: 90/1 103/705 105/81 106/201 124/5016 128/187 153/757 7715   
   SEEN-BY: 154/10 30 203/0 218/700 221/0 226/30 227/114 229/110 114   
   SEEN-BY: 229/206 317 400 426 428 470 550 700 705 240/1120 5832 266/512   
   SEEN-BY: 280/464 5003 5006 282/1038 291/111 292/8125 301/1 320/219   
   SEEN-BY: 322/757 341/66 234 342/200 396/45 423/120 460/58 256 1124   
   SEEN-BY: 467/888 633/280 712/848 770/1 5020/400 8912 5054/30 5075/35   
   PATH: 103/705 280/464 460/58 229/426