Problems connecting with BBSs

[mleair]

Hi,

I received my Fujinet from The Brewing Academy yesterday. Great device overall, however, I am having trouble with BBSs.

When I connect to Atari BBSs, I find that there are either intermittent delays in receiving characters or lock ups.

My Fujinet is at version 0.5.77c13818 2020-10-05 01:27:16

I tried a couple different term programs that used the Altirra R: Handler that works with the Fujinet. I first tried the modem-programs.atr from atari-apps.irata.online. I tried both Bobterm and ICE-T. I also tried ICE-T and Bobterm from tnfs.atari8bit.net. The same thing happens with all these term programs.

The BBSs I tested include:

basementbbs.ddns.net:9000 ptbbs.ddns.net:8000 southernamis.ddns.net:23 alcatrazbbs.ddns.net:9000 bfbbs.no-ip.com:8888

It did not matter if I logged on using ATASCII or ASCII. I would still see intermittent delays and/or lock ups. Once the device locks up, I have to reboot to use it again. Also Fujinet's webserver does not come up in a web browser when the device locks up.

It does not matter which baud rate I use on the term program. I still experience these problems.

I first reported this to Marlin at The Brewing Academy. He does not believe it is a hardware problem and suggested I file a bug.

After some experimentation, I found that I had a little bit of success if I adjust Fujinet's HSIO setting to 9 and set the term program's baud rate to 2400. However, I still occasionally get delays and lock ups when I do this. Alcatraz BBS will always lock up after you login. I think it's due to the complex ATASCII welcome screen.

I reproduced this problem on two different computers, so I suspect it's not a problem with the computer. I reproduced it on an Ultimate 1MB Atari 800XL and a 64K 600XL. A friend of mine also reproduced the problem on his Fujinet with a stock Atari 800XL. So, it does not appear to be dependent on the computer nor the individual Fujinet since there's at least two users who have seen the same problem.

Let me know if I need to provide additional information. Hopefully this is a simple problem to fix.

Best,

Mark

[mleair]

Also, I should add that this functionality appeared to work in January of this year when this youtube video was made. Note that there's no problems logging onto the Basement BBS in this video using Fujinet.

https://youtu.be/k8-XBbteakQ

-Mark

[tschak909]

Logged and looking into it.

On Thu, Oct 8, 2020 at 9:11 PM mleair notifications@github.com wrote:

Also, I should add that this functionality appeared to work in January of this year when this youtube video was made. Note that there's no problems logging onto the Basement BBS in this video using Fujinet.

https://youtu.be/k8-XBbteakQ

-Mark

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-platformio/issues/371#issuecomment-705925183, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBYZQ3PIIB6R56XUQEOW3SJZWOBANCNFSM4SJPLVLQ .

[tschak909]

@mleair when it hangs, are you able to do +++ ? -Thom

[mleair]

@tschak909

Usually I can type +++ when it hangs. But when I do that, it disconnects from the BBS and I get a NO CARRIER message.

Sometimes it will hang to the point where typing +++ will not give me any response. In that case, I have to reboot.

[mleair]

@tschak909 I should also add that after I type +++ and get a NO CARRIER message, I usually cannot connect to another BBS.

For example, after issuing the +++ and getting the NO CARRIER message, if I enter a command such as the following, I get no response, just NO CARRIER (even though I know the BBS is available for connection):

atdtbasementbbs.ddns.net:9000 Connecting to basementbbs.ddns.net:9000 NO CARRIER

When this happens, I have to reboot in order to connect to another BBS.

[tschak909]

Yes. I can see that.. this is going to take some time to untangle and debug, as I am not sure what is causing the input buffer to stop receiving characters, yet.

I am only seeing this though, explicitly on hosts that are at the other end of a Lantronix UDS device...

-Thom

On Fri, Oct 9, 2020 at 5:26 PM mleair notifications@github.com wrote:

@tschak909 https://github.com/tschak909 I should also add that after I type +++ and get a NO CARRIER message, I usually cannot connect to another BBS.

For example, after issuing the +++ and getting the NO CARRIER message, if I enter a command such as the following, I get no response, just NO CARRIER (even though I know the BBS is available for connection):

atdtbasementbbs.ddns.net:9000 Connecting to basementbbs.ddns.net:9000 NO CARRIER

When this happens, I have to reboot in order to connect to another BBS.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-platformio/issues/371#issuecomment-706424180, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBYZV4GGBEOBJGK4VXRZLSJ6EYXANCNFSM4SJPLVLQ .

[mleair]

So, you have no problem connecting to any of the following BBSs?

basementbbs.ddns.net:9000 ptbbs.ddns.net:8000 southernamis.ddns.net:23 alcatrazbbs.ddns.net:9000 bfbbs.no-ip.com:8888

Those BBSs do not use a Lantronix box. They are all running on the Altirra emulator. All of these give me delays and/or lockups.

The Atari BBSs that I'm aware of that are connected to Lantronix Boxes are The Resistance, Dark Force, and Star Fleet Command. Are you having problems with these BBSs?

I successfully connected to all three of the Lantronix BBSs at 2400 baud and had no delays nor lockups. If I connect at 9600 baud, I get character loss. So, I still can't use anything above 2400 on those BBSs.

-Mark

[tschak909]

I thought all of these were on the other end of a Lantronix UDS? Hm. If what you say is the case, I'll try to set up a test harness with tcpdump and try to get some meaningful data. -Thom

On Sat, Oct 10, 2020 at 2:48 AM mleair notifications@github.com wrote:

So, you have no problem connecting to any of the following BBSs?

basementbbs.ddns.net:9000 ptbbs.ddns.net:8000 southernamis.ddns.net:23 alcatrazbbs.ddns.net:9000 bfbbs.no-ip.com:8888

Those BBSs do not use a Lantronix box. They are all running on the Altirra emulator. All of these give me delays and/or lockups.

The Atari BBSs that I'm aware of that are connected to Lantronix Boxes are The Resistance, Dark Force, and Star Fleet Command. Are you having problems with these BBSs?

I successfully connected to all three of the Lantronix BBSs at 2400 baud and had no delays nor lockups. If I connect at 9600 baud, I get character loss. So, I still can't use anything above 2400 on those BBSs.

-Mark

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-platformio/issues/371#issuecomment-706506532, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBYZRG7RE43BHXSJC5ZQ3SKAGVVANCNFSM4SJPLVLQ .

[mleair]

So, the issue probably is more of an Altirra emulator versus native hardware problem. The BBSs running on the Lantronix boxes are also running native hardware (The Resistance is an Atari 8 bit BBS and the other two, Dark Force and SFHQ, are Atari ST BBSs). Perhaps Altirra is sending data faster than native hardware? Is there a large enough input buffer in the firmware?

-Mark

[tschak909]

The input buffer is VERY large, large enough that I just did a test between Altirra, and the FujiNet, running Bobterm, sending files at 9600bps, without issue...

...so I'm REALLY.....REALLY starting to wonder wtf the issue is. Because THERE IS ONE...

-Thom

On Sat, Oct 10, 2020 at 5:12 PM mleair notifications@github.com wrote:

So, the issue probably is more of an Altirra emulator versus native hardware problem. The BBSs running on the Lantronix boxes are also running native hardware. Perhaps Altirra is sending data faster than native hardware? Is there a large enough input buffer in the firmware?

-Mark

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-platformio/issues/371#issuecomment-706618358, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBYZX3MBHOKWEK4DTMBKDSKDL6BANCNFSM4SJPLVLQ .

[mleair]

Southern AMIS, which is one of the BBSs that's having issues, is running the original BBS Express! Since that's widely available, maybe you can try setting it up in Altirra and see if you can reproduce the problem locally. That might make things easier for testing.

[tschak909]

Yes, I am actually doing that right now. I have to be very careful, because of certain people who watch AtariAge specifically for people copying BBS Express, who was screaming at Albert to ban me because I was instigating trying to get copies of the software for preservation. (Thankfully, Albert likes me.)

[mleair]

Original BBS Express is now public domain. I think that's all you need. BBS Express! Pro! is the version that's still commercial.

[mleair]

I fired up an old copy of original BBS Express under Altirra 3.90 on my end. I was able to reproduce the issue with this setup. One interesting thing to note, when there is a delay in receiving characters, I can look over at my Altirra screen, press a key on the Atari with the FN, and the BBS receives it. The delays are one sided. If I do this enough during a delay, FN will eventually drop carrier though. When carrier is dropped, the FN is locked up and I have to type +++.

So, my guess is that you too can probably reproduce this same issue locally with Altirra + original BBS Express.

Attached is a photo with my Altirra settings for the modem.

-Mark

[tschak909]

Can I get a copy of the BBS setup you're using? thom.cherryhomes@gmail.com -Thom

On Sat, Oct 10, 2020 at 6:31 PM mleair notifications@github.com wrote:

I fired up an old copy of original BBS Express under Altirra 3.90 on my end. I was able to reproduce the issue with this setup. One interesting thing to note, when there is a delay in receiving characters, I can look over at my Altirra screen, press a key on the Atari with the FN, and the BBS receives it. So the delays are one sided. If I do this enough during a delay, FN will eventually drop carrier though.

So, my guess is that you too can probably reproduce this same issue locally with Altirra + original BBS Express.

Attached is a photo with my Altirra settings for the modem.

[image: settings] https://user-images.githubusercontent.com/20933436/95667086-d32b9680-0b15-11eb-8157-38002f7f1ff7.JPG

-Mark

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-platformio/issues/371#issuecomment-706625572, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBYZSRFSVVS2BV6RLCY7DSKDVFLANCNFSM4SJPLVLQ .

[tschak909]

@mleair in each stall, there is a corresponding series of duplicate ACKs, but I have yet to know whether this is caused by over-eager nagle'ing OR if it's caused by a bug in lwip with regards to fast-retransmission...sigh.

[tschak909]

stall.zip Here's the packet dump from wireshark.

[tschak909]

Now, on the other hand, if I just do a file transfer between the same two Atari systems, in the same direction (just bobterm to bobterm), then I get the following PERFECT packet dump, and I mean PERFECT.

perfect.zip

[tschak909]

The main thing, is that BBS Express switches between Concurrent I/O and block write AT WILL.

I think this is somehow exercising a bug in Altirra where the packet sequence counter gets mangled.

-Thom

[mleair]

I sent you an original BBS Express ATR.

[tschak909]

I have been able to exercise the problem with the following code.

10 OPEN #1,13,0,"R:"
20 FOR X=1 to 999
30 PRINT #1;"testing testing testing testing testing testing testing testing testing testing testing testing testing testing testing testing testing testing testing testing testing"
40 NEXT X
50 CLOSE #1 

This does not happen when concurrent mode is engaged, which means there is some odd interaction with the Altirra R: handler, Altirra, and the FujiNet where Altirra is trying to nagle packets together and somehow stumbling over the fast retransmission part.

Hopefully this will be fixed.

-Thom

[mleair]

Glad you got it down to a small test case!

[mleair]

@tschak909 I wrote a simple telnet tunnel that accepts a port/socket connection from Fujinet and connects to a BBS' port/socket. After it establishes a connection, it then sends/receives the data between Fujinet and the BBS. Using this tunnel, Fujinet connects perfectly to all Altirra based BBSs at 2400 baud (including ASCII and ATASCII modes). Any idea why this is the case? I wonder if there may be an input buffering problem on the Fujinet device. The tunnel, of course, acts as a buffer between Fujinet and Altirra. It also sends the acknowlegement of received packets to Altirra.

I am attaching the Windows tunnel code I used (source code and a precompiled 64-bit executable). Below is the compile-line I used and the run line (feel free to use Visual Studio if you don't want to use the command-line).

C:>cl mytunnel.c /link -defaultlib:ws2_32.lib Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27039 for x86 Copyright (C) Microsoft Corporation. All rights reserved.

mytunnel.c Microsoft (R) Incremental Linker Version 14.16.27039.0 Copyright (C) Microsoft Corporation. All rights reserved.

/out:mytunnel.exe -defaultlib:ws2_32.lib mytunnel.obj

C:>mytunnel usage: mytunnel server-name port my-port

C:>mytunnel basementbbs.ddns.net 9000 8888

The above starts the tunnel and has it listen to port 8888.

On Fujinet, issue the ATDT command to connect to your tunnel on port 8888 (or whichever port you choose). When the connection is made, it will connect to the Basement BBS on port 9000. You will then be connected to the Basement BBS.

The tunnel code isn't very robust. It's just a quick test code I wrote. You may need to ^C and stop it after you disconnect from a BBS. You also will need to restart it after each connection.

mytunnel.zip

[mleair]

@tschak909

Question on the code at line 1403 of modem.cpp.

Shouldn't this be a while loop? For example,

    while ((bytesAvail = tcpClient.available()) > 0)

instead of

    if ((bytesAvail = tcpClient.available()) > 0) 

It seems to me more bytes can come in after the read at line 1407 and maybe not processing these right away is the cause of Altirra resending packets.

[tschak909]

Definitely worth a try. Do you have an env set up to build and upload?

[mleair]

Sorry, I don't have a dev environment. It should be a safe change to make though.

[tschak909]

Ok, tried it on Basement BBS, didn't seem to make a difference, but I've folded it in, anyway. :) https://github.com/FujiNetWIFI/fujinet-platformio/commit/c143b4d6ffea52394eb5452412a39b13bb3c9d06

-Thom

[mleair]

Bummer. Thanks for trying that change.

[tschak909]

An update, @mozzwald has altered the following sdkconfig parameters, and it seems to have helped some, but we still need to do more tweaking and experimenting. https://github.com/FujiNetWIFI/fujinet-platformio/commit/d664bf26376abf9dd311e89b88aa37806821927e

-Thom

[mozzwald]

@mleair I've just pushed another change d664bf2 that is working very good for me. I've been able to connect to multiple ATASCII BBSs consistently without issue. Please test if you can. Be sure to remove sdkconfig and clean before building / flashing the new firmware.

[mleair]

@mozzwald I tried out your change. Thanks! It's an improvement, however, I still get an occasional delay and/or lockup. When I connect to Alcatraz BBS (alcatrazbbs.ddns.net:9000) under ATASCII and hit '?' for the main menu, it sometimes locks up. There are sometimes delays with Alcatraz BBS' logon screen too (which has lots of ATASCII).

[tschak909]

It worked! Tested and merged. calling this one fixed. Thanks @mleair !