Ser2Net Telnet Mode

[quangn92]

Hello @cminyard,

I'm using NetSerial to connect to Ser2Net in a Linux embedded device through Telnet mode.

Everything connects and transmits fine except if I idle for 2 minutes, the Ser2Net starts to see 0xFF as a (IAC - Interpret As Command) byte. Is there an option to increase this timeout or an option to turn off Telnet Negotiation after the connection is made?

If a code change is needed to customize this feature, which file should I look into?

Thank you for your insight!

[quangn92]

After 2 minutes, the 0xFF get omitted together with 0x81 (Interpret As Command), and the other side does not see 0xFF 0x81 as sync words.

[cminyard]

On a telnet connection, 0xff is always an IAC. There is no way around it, telnet commands can occur at any time.

If you have something on the other end that is sending a 0xff as data, it needs to send "0xff 0xff" to send an "0xff" across telnet. This is standard telnet.

[quangn92]

I agree with what you stated.

However, as you can see in the picture, I can send the 0xFF without the need to escape it "0xFF 0xFF" at first. And as long as I keep communication busy (not idle for 120 seconds), I can keep sending 0xFF as data without it being an IAC.

I tried to look for this timeout in gensio library but no luck.

[cminyard]

Ah, so you are saying that you are sending data on a telnet connection, and at first it sends "0xff" as "0xff 0xff", but if it sits idle for a while sending "0xff" is not doubled.

I am not sure what I am looking at in the picture you posted, what is transmit, and what is receive, but I don't see any issue. All the lines look like the same sequence to me. There is one that is split into two lines, but that is normal.

[quangn92]

The data is being sent over to Ser2Net is in Blue. It sends "0xFF" as single all the time. The first few times the other side was able to see the "0xFF 0x81" and response back in Red.

If I wait over 120 seconds (as you can see in the timestamp between the last 2 Blue lines), the "0xFF 0x81" is considered as a telnet command and does not send to the COM port. Therefore, the receive side thinks this is corrupted message and does not response back. I used the Ser2Net trace-write to capture what is being sent to the COM port.

[cminyard]

Can you post a trace of what comes in to the telnet gensio at the top and what comes out below it?

As you have reviewed in the code, and I just looked to, there is nothing that will make this stop happening. So something else must be going on.

[quangn92]

ser2net_log.zip

Thank you for the suggestion.

I recorded the TCP communication between NetSerial and Ser2Net. It seems there is an issue on NetSerial side rather than Ser2Net as it actually did send "0xFF 0xFF" at first. For some reason, it does not escape "0xFF" anymore after 120 seconds.

[cminyard]

Ok, I'm going to try to re-create what you are doing. Let me go over what I think you network configuration is.

You have a machine at 192.168.240.243 that is running ser2net. Can you give me the type of machine that is and the version of ser2net running there?

You have a machine at 192.160.240.45 that is a windows machine. You have NetSerial running on that. What version of windows and NetSerial are you using?

You have a program connected to the virtual com port on the windows machine.

Periodically the windows machine sends a message containing a 0xff through NetSerial, which then goes to ser2net. ser2net sends that out a serial port, I assume, then something on the other side of the serial port responds with a message containing 0xff. This works fine for a while, up to time 16.38 in the pcap trace.

After a while, at time 151.89, the windows machine sends a message containing a 0xff. The same thing happens, but ser2net sends a response that does not double the 0xff.

After verifying that the IP addresses are on the right machine and the versions of things, I'll try to set things up to duplicate this.

[quangn92]

NetSerial double the "0xFF" on the first 4 messages. After 120 seconds of idling, NetSerial does not double the "0xFF" anymore.

[cminyard]

NetSerial double the "0xFF" on the first 4 messages. After 120 seconds of idling, NetSerial does not double the "0xFF" anymore.

Wait, I'm confused now. Is NetSerial not doubling the 0xff, or is ser2net not doubling the 0xff?

Looking at the pcap trace again, it looks like the machine at 192.168.240.243 is not doubling the 0xff.

[quangn92]

At time 151.89, the NetSerial (192.168.240.45) sends out "0xFF 0x81 0x00 ..." to Ser2Net (192.168.240.243) when it supposed to sends "0xFF 0xFF 0x81 0x00 ...".

So NetSerial is the one not double the "0xFF" anymore.

[cminyard]

I mean, after you verify that the IP addresses are correct and send me the versions of things, I'll try to reproduce.

[quangn92]

Yes, it is a Linux embedded device at 192.168.240.243, with Ser2Net v4.6.5.
Windows 11 with IP address 192.160.240.45 and NetSerial v4.32.0.

[cminyard]

On Mon, Apr 13, 2026 at 5:32 PM Quang Nguyen ***@***.***> wrote: At time 151.89, the NetSerial (192.168.240.45) sends out "0xFF 0x81 0x00 ..." to Ser2Net (192.168.240.243) when it supposed to sends "0xFF 0xFF 0x81 0x00 ...".

Ah, yes, you are right, I misread that. There's no command to turn off telnet on a connection, and obviously no command that could have done this was sent. It looks like the problem is in NetSerial, then. Which is unfortunate, perhaps, because I can't fix that for you.

…

Message ID: <cminyard/ser2net/repo-discussions/153/comments/16549465@ github.com>

[quangn92]

Thank you so much for the support as it points me to where the issue is.