Behaviour on TCP disconnect

[ltning]

Hi,

received my two 232+OLEDs today, thanks!
Attempting to use it for inbound telnet to the old "Simplex BBS" software, I'm getting pretty far, but when nc'ing (netcat - so not telnet) to the BBS and then ctrl-C-ing netcat - which closes the connection and presumably sends TCP RST and all that - I see the BBS receiving a "NO CARRIER" string from the modem, and then the software goes into a loop where it says carrier was dropped, and then attempts to reset the modem - which again brings it to the "carrier was dropped" message, ad infinitum.

If I allow the BBS software itself to do the disconnect (timeout or whatnot), it manages just fine.

The OLED reads "Ready" when this happens.

I've tried all variants of AT&Dx, but haven't played much with other settings.

I find it hard to debug what's going on here, so I'm humbly(?) asking for some ideas of what to look for, and how. It could be a hardware (serial ports?), driver (OS/2 1.3 + Digi ClassicBoard serial card driver), software (Simplex for OS/2) or config problem.. I just don't know where to look.

Thanks again,
/Eirik
http://floppy.museum/

[admin]

Do you know what commands the BBS is sending to the modem and what it should be expecting? Typically, this type of problem is due to the BBS not receiving something that it expects to see. It could be that the BBS is sending some odd (unsupported) modem command and that is generating ERROR as a return. It could also be a stacked command (ie. ATZ0H0M0.. etc. where commands are all put together) that is not supported in the immediate mode. The only way to really diagnose these types of problems is by using a serial sniffer program or by connecting the serial port to another serial (via hardware) and watching the data.

I have no idea what "netcat" is. The WiModem232 supports RAW and TELNET modes.

[ltning]

Hola,

Do you know what commands the BBS is sending to the modem and what it should be expecting? Typically, this type of problem is due to the BBS not receiving something that it expects to see. It could be that the BBS is sending some odd (unsupported) modem command and that is generating ERROR as a return. It could also be a stacked command (ie. ATZ0H0M0.. etc. where commands are all put together) that is not supported in the immediate mode. The only way to really diagnose these types of problems is by using a serial sniffer program or by connecting the serial port to another serial (via hardware) and watching the data.

The commands being sent are pretty standard: ATZ|S0=0| for init (| = CR), with variations as I try different AT&Dx values. ATA for picking up, RING and CONNECT for the relevant events, and ~~~~+++~~~~ATH0| for hangup (which is only used if dropping DTR fails), and no busy string set (makes no sense here). I've locked the baud to 19200 for now (but it does work up to 115k).

I have no idea what "netcat" is. The WiModem232 supports RAW and TELNET modes.

The "nc" command - simply establishes a TCP socket - so RAW, not TELNET.

/Eirik

[admin]

So, the commands are sent individually, etc:

ATZ<CR>
ATS=0<CR>
etc.??

AT&D requires DTR being toggled by the BBS. Typically AT&D2 is used for a BBS that even supports DTR disconnect at all.

Is the "~~~~" in your ~~~~~+++~~~~~ATH0 actually being sent, or does the BBS recognize those characters are 1 second pauses? You can't send the "~" character.

[ltning]

Hi, sorry for my late reply. Work and life got in the way.

The commands currently being sent during startup/init are:
ATH<CR>
ATZ<CR>
ATS0=0<CR>
AT&D2<CR

For hangup and any other place, ~ represents a 0.5s pause, to allow for the forced return to command mode or other timing sensitive init commands.

Is there any way I can get you a log of what's going on?

[ltning]

Btw, here's a screenshot of what the BBS software sees.

   

/Eirik

[admin]

Hi, sorry for my late reply. Work and life got in the way.

The commands currently being sent during startup/init are:
ATH<CR>
ATZ<CR>
ATS0=0<CR>
AT&D2<CR

For hangup and any other place, ~ represents a 0.5s pause, to allow for the forced return to command mode or other timing sensitive init commands.

Is there any way I can get you a log of what's going on?

The only way to get a "log" is by using a serial sniffer - basically, another computer connected to the same RS232 lines where you can receive what is being transmitted.  There is not enough memory in the WiModem232 to capture a lot of data.

The NO CARRIER message occurs when the Telnet connection is terminated.

ATH doesn't do anything, so you can remove the line if you want. That just means "hang up", which it already is to even be able to enter commands. ATZ resets the settings. ATS0=0 enables auto answer on first "ring". AT&D2 enables hanging up the modem when DTR is toggled. Unless you have a valid reason to do this (like the BBS uses this to hang up on purpose), then I would omit this line. Do you know if the BBS monitors the DCD line to determine if there is a connection? It could be that you have the DCD state backwards?

[ltning]

Hi,
at&c? = 1
at*d? = 1
Contrary to what the documentation for wimodem232 says (doc says at*d defaults to 0, but I guess this is down to hardware revisions), both of these are default values.

If I set at*d=0 (normal polarity), or at&c0 (always connected), the BBS fails to "force modem hangup", and upon ring/answer it says "unable to detect baud rate of connect" and proceeds to (fail to) hang up and re-init. Note that the behaviour is the same in both cases.

Using AT&D0 (default) doesn't make any difference in this scenario; it may make a difference depending on how the BBS handles BBS-initated logouts: The config indicates that it uses DTR to kick people out, and only resorts to the ~~~+++~~~ATH approach if dropping DTR fails.

I've never built/used a serial sniffer before, and while I have been involved in building a serial console "bridge" at a point, I don't think that approach would be useful as any change to DTR/DCD/CTS/RTS/whatever states would not be picked up. Do you have any suggestions for what kind of hardware/software I would need?

[admin]

AT&D0 doesn't use DTR at all, so that can not be a setting expected to hang up the modem.  There are only 3 ways to disconnect once a connection is established:


1) Use AT&D2 and toggle the DTR line.

2) Use +++ to enter command mode, and then ATH to terminate the connection.

3) The remote side terminates connection.



This is the only way a real (or emulated) modem can disconnect.



The default value for *D should be 1 (inverted) for the WiModem232.  I will change that in the documentation.  If your programs looks for the DCD signal, then &C should be 1.

You would need a NULL modem cable connected to a 'Y' cable.  The NULL modem end would plug into any PC.