Posts: 3
Threads: 1
Joined: May 2021
05-01-2021, 11:06 PM
(This post was last modified: 05-02-2021, 09:53 AM by John Polka.)
Hi,
I just received my WIMODEM232 with OLED. Everything is working great except one issue.
Some BBSs will print a quick one line message and disconnect when they are busy (e.g., "Sorry, someone else is using the BBS. Please try again later"). When I try to connect to a busy BBS, I am not getting the expected "busy message." The WIMODEM232 will print a "CONNECT" message and immediately print "NO CARRIER". The busy message is never displayed. It's as if the modem failed to flush an input buffer before printing "NO CARRIER" and returning to command mode.
I tried this on two different Atari 800XLs and an Atari Mega ST 2. Same results. I also tried baud rates 300, 2400, and 9600 which made no difference. On the Atari 800XL, I also tried three different serial devies (i.e., a P:R: Connection, 850 Interface, and an MIO) but had the same results.
This device was recommended by a friend who owns one. I spoke with him and he sees the busy messages with his Wimodem232.
Is there a setting I should try? The only setting I could find in the docs that remotely sounded like something that might help is AT*BL. But changing it did not have any effect.
I'm running Firmware v3.41-04/12/21
My AT&V settings are below:
B0 C0 E1 L0 M0 Q0 V1 X0 S0:0 S1:0 S2:43 S3:13 S4:10 S5:8 S6:2 S7:60 S8:2 S9:6
S10:15 S11:90 S12:50 S25:0 S30:0 S37:6 *B9600 *BL512 *C0 *D1 *L6400 *LED0 *P15
41 *R0 *T0 &C1 &D0 &G0 &K0 &Q0 &S0
Thanks,
JP
Posts: 2,853
Threads: 148
Joined: Nov 2013
The “busy” message comes from the connection you make. There is no flushing done on either a connection or disconnection. I did recently add the ability to block IP addresses on incoming connections, but that should not affect any outgoing connection or message, but I will check this out.
Posts: 3
Threads: 1
Joined: May 2021
05-02-2021, 09:44 AM
(This post was last modified: 05-02-2021, 10:11 AM by John Polka.)
Hi,
To clarify my original post... When I connect to a BBS, say the Basement (basementbbs.ddns.net:9000), and someone else is already on that BBS (because it is a single user system), I will see the following message with other telnet modem devices (such as Syncterm, Lantronix UDS-10, Fujinet, etc.):
Sorry, someone else is using the BBS. Try southernamis.ddns.net:23 while you wait.
The above message is sent by the Basement BBS. The BBS will then disconnect immediately after that message is dsplayed. I do not get this message with my Wimodem232. Instead, all I see is:
CONNECT
NO CARRIER
To reproduce the problem:
1. Connect to the Basement BBS (basementbbs.ddns.net:9000).
2. Disconnect from the Basement BBS.
3. Connect to the Basement BBS (basementbbs.ddns.net:9000) again.
You should see the busy message after step 3 since the previous connection remains busy for about 30 seconds after a user logs off. If you just see "CONNECT" followed by "NO CARRIER" then you are seeing the same thing I am seeing.
As an FYI, The Basement is my personal BBS, so I can confirm that the BBS is sending the busy message but the Wimodem232 is not displaying it. I also have confirmed this same behavior on other BBSs such as:
Southern Amis (southernamis.ddns.net:23)
Amis XE (amis86.ddns.net:9000)
Alcatraz BBS (alcatrazbbs.ddns.net:9000)
Part-Time BBS (ptbbs.ddns.net:8000)
Thanks for looking into this,
-JP
Posts: 2,853
Threads: 148
Joined: Nov 2013
Yes, I understand what you are saying. However, if the disconnection of the TCP socket occurs before the completion of the message then it will definitely do exactly as you describe. There would have to be a delay by the sender between sending the last message and actually terminating the socket. I don't think I can delay anything on my end since I don't have control over that part of the stack, but I will take a look.
Posts: 2,853
Threads: 148
Joined: Nov 2013
Ok, I am able to reproduce this issue. However, I went back to several previous versions of the firmware, and they all have the same issue. So, this problem could likely be because of upgrading the Arduino libraries, the ESP8266 library in particular. It might be that the connection termination stops the data flow, and if that happens before the serial data is checked then the data would never be seen. I am not sure if there is anything I can do to work around this, as I don't handle that part of the code at all Going backwards in ESP8266 library versions is not an option as we would lose some features and speed increases. I will have to investigate this further.
Posts: 2,853
Threads: 148
Joined: Nov 2013
Ok, so as an experiment I don't allow the disconnection of the socket on my end (it's still gone on the router side). I now get Sorry, or Sor, or just So, of the message and that's it. The socket connection from the router side is gone before all of the data can be received by the ESP8266 module. I can look at a few things, but this is probably something that I will not be able to fix without re-writing that part of the ESP8266 library.
Posts: 2,853
Threads: 148
Joined: Nov 2013
Well... this seems to be a baud rate based race condition. If I run the WiModem232 at 57600 or 115200 baud I see the busy message perfectly. I see it almost perfectly at 9600 baud (I lose the last couple of words). At 2400 baud I get something between "S" and the full word "Sorry".
Posts: 2,853
Threads: 148
Joined: Nov 2013
I am going to have to re-write part of the socket layer (which I already re-wrote) so that disconnections are not handled asynchronously. Right now, it's a race to see what occurs first - the serial data being pulled from the ESP8266 or the loop getting back around to checking the disconnection. Slow baud rates lose, high baud rates win. If I don't have the asynchronously capability then file transfers are severely limited because ACK's have to occur in a very short period of time and the stock ESP8266 libraries do not allow for reads and writes (full duplex) from/to the ESP8266 at the same time. I fixed this, but this also affects the return message.
Posts: 3
Threads: 1
Joined: May 2021
I just tried the latest firmware (4.0) and confirmed that the bug is now fixed. Thank you so much for making this change! I very much appreciate it!
-JP
Posts: 2,853
Threads: 148
Joined: Nov 2013
Great! Thanks for confirming!
|