(02-11-2025, 11:48 AM)admin Wrote: 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.