Latest firmware update has created random exception errors

[admin]

That just sets the receiving buffer size. I would expect a larger value to have fewer problems, so this issue has nothing to do with data coming in too fast.

I need to figure out how to create the same setup you have for testing this. Can you describe your exact setup that is required to see this problem? I am guessing that maybe this is a Telnet command or something. Did you try with translation ON? If you are using a Telnet portal for any part of the communication link, then it is very likely that Telnet translation has to be ON.

We could play the game of going backwards in firmware versions until we figured out what change shows this issue. It would be a lot faster if I had a way to re-create this issue.

[mnewkirk]

Is there a clear cut definition of what constitutes a TELNET connection versus something else? I ask because I am running a BBS where people are telnetting in using various terminals (syncterm, CCGMS, Striketerm, etc). All function well except this one case we are seeing with muffinterm / mac.

I've not seen any other crash/exception since we resolved my original problem at the start of this thread, so I'm hesitant to change my configuration. Also, I want to say that I've tried having that set before and it caused connection problems for end users... I guess I could test it though and see....

It sounds like my exception issue may be different than bbsing's...?

[admin]

Telnet means that your BBS is going through a Telnet portal, and not using a RAW connection. How do you have your BBS setup through DNS?

The exception is a NULL pointer basically...something is trying to write to memory that does not exist. That typically occurs when there is a buffer overrun data past the end of the buffer is trying to be used. This would mean that something was holding off the WiModem from sending data and preventing new data from arriving (hence the question about AT&K1 because that does flow control for both directions).

[bbsing]

That just sets the receiving buffer size.  I would expect a larger value to have fewer problems, so this issue has nothing to do with data coming in too fast.

I need to figure out how to create the same setup you have for testing this.  Can you describe your exact setup that is required to see this problem?  I am guessing that maybe this is a Telnet command or something.  Did you try with translation ON?  If you are using a Telnet portal for any part of the communication link, then it is very likely that Telnet translation has to be ON.

We could play the game of going backwards in firmware versions until we figured out what change shows this issue. It would be a lot faster if I had a way to re-create this issue.

I was attempting to build an dialin server. I thought 2 of my 3 wimodems would come in handy for this. If I was successful I would segment my system and open it to the public. Maybe I can open it to the public for understanding how to fix this issue.
As far as I can tell the server with an older firmware is not having a problem. I haven't swapped modems between server and client yet. I felt it wasn't necessary yet because it looks very apparent the issues is with the wimodem with the later firmware.

My setup is a ubuntu 16 server with an mgetty service using wimodem connected to via RS232 port.

server:
mgetty is listening for an incoming call on /dev/ttyS01. Wimodem is set to answer. 

client:

raspberry pi 4, using wimodem via RS232 port. I'm using minicom as a terminal client. I make a call via atd to the mgetty modem IP like this:
sudo minicom -D /dev/ttyUSB0

once in minicom make a call to ubuntu server
atd 192.168.2.157:6400

on the server:
mgetty answers the call and presents a login prompt.

client:
via mincom 
provide credentials.
then attempt to use the server.


If you planning to build a similar system and need some config files I can probably get you mine.

[admin]

raspberry pi 4, using wimodem via RS232 port. I'm using minicom as a terminal client. I make a call via atd to the mgetty modem IP like this:
sudo minicom -D /dev/ttyUSB0

Wait a minute. This thread about the WiModem, NOT the WiModem232! Which are you actually using? If you are using a WiModem232, how are you attaching it to a C64? The WiModem and WiModem232 are very different! There are different versions of the WiModem232 hardware as well!

[bbsing]

raspberry pi 4, using wimodem via RS232 port. I'm using minicom as a terminal client. I make a call via atd to the mgetty modem IP like this:
sudo minicom -D /dev/ttyUSB0

Wait a minute.  This thread about the WiModem, NOT the WiModem232!  Which are you actually using?  If you are using a WiModem232, how are you attaching it to a C64?  The WiModem and WiModem232 are very different!  There are different versions of the WiModem232 hardware as well!

I have 3 modems.
wimodem232 (v4.x)
wimodem232 (v6.40)
wimodem (ver 6.20)

Every modem i have at vers 6.x is behaving this way.

When I use my c64 and dial as I said in prior posts the same thing happens.

[admin]

I sent you a PM about this... but I logged on to your server several times using the WiModem232 Pro, WiModem232, and WiModem. I had zero issues looking around, using ls, dir, help, etc. I could not get any type of failure.