Hi,

I've got synchronet running on Debian 12 (x86_64) I am running fa91e9074 which i pulled a few days ago.

Everything works fine, except each evening the telnet server stops listening on ipv4. I can log in via ipv6 (localhost - i don't actually have ipv6 setup) but trying to log in via ipv4 results in connection refused.

Restarting sbbs brings the telnet server back up.

I'm not sure where to even begin troubleshooting this. My telnet is listening on port 23, it's odd that it happens about the same time each evening.

I've only been running for a few days now, perhaps it's something intermittent? I'll keep an eye on it the next few days and see if it does it again.

Andrew

Re: Telnet Server
By: Apam to All on Sun Apr 07 2024 04:39 am

Everything works fine, except each evening the telnet server stops listening on ipv4. I can log in via ipv6 (localhost - i don't actually have ipv6 setup) but trying to log in via ipv4 results in connection refused.

Restarting sbbs brings the telnet server back up.

I'm not sure where to even begin troubleshooting this. My telnet is listening on port 23, it's odd that it happens about the same time each evening.

Run 'netstat -lp' or 'ss -lp' to determine what is listening in port 23 when this happens (and is it sbbs?).

By default, the Synchronet ctrl/sockopts.ini file does not enable the REUSEADDR option. Is this option now enabled? If it is, then a second process (e.g. a second invocation of sbbs) could "take over" the port.
--
digital man (rob)

Breaking Bad quote #10:
Get a big old raging hard-on at the idea of catching this piece of shit! - Hank Norco, CA WX: 63.8°F, 37.0% humidity, 3 mph W wind, 0.00 inches rain/24hrs

Re: Telnet Server
By: Digital Man to Apam on Sun Apr 07 2024 01:33 pm

Howdy,

By default, the Synchronet ctrl/sockopts.ini file does not enable the REUSEADDR option. Is this option now enabled? If it is, then a second process (e.g. a second invocation of sbbs) could "take over" the port.

Cant remember if I've asked before or not - but why isnt this enabled by default. Seems to bite a lot of people...


...δεσ∩

---
■ Synchronet ■ AnsiTEX bringing back videotex but with ANSI

Re: Telnet Server
By: deon to Digital Man on Mon Apr 08 2024 07:52 am

By default, the Synchronet ctrl/sockopts.ini file does not enable the REUSEADDR option. Is this option now enabled? If it is, then a second process (e.g. a second invocation of sbbs) could "take over" the port.

Cant remember if I've asked before or not - but why isnt this enabled by default. Seems to bite a lot of people...

Because re-capturing a port that's already bound (e.g. to another server) can also bite people. It's generally something that's not enabled by default in TCP servers.
--
digital man (rob)

Steven Wright quote #23:
My mechanic told me, I couldn't repair your brakes, so I made your horn louder Norco, CA WX: 64.5°F, 41.0% humidity, 6 mph WNW wind, 0.00 inches rain/24hrs

Re: Telnet Server
By: Digital Man to deon on Sun Apr 07 2024 03:26 pm

Hi,

Because re-capturing a port that's already bound (e.g. to another server) can also bite people. It's generally something that's not enabled by default in TCP servers.

Oh really? What scenario?

IE: If I install SBBS (or a TCP server) and want it to use TCP port "x", why wouldnt I want it to re-capture that port if the server was recycled?


...δεσ∩

---
■ Synchronet ■ AnsiTEX bringing back videotex but with ANSI

Re: Telnet Server
By: Digital Man to Apam on Sun Apr 07 2024 01:33 pm

Run 'netstat -lp' or 'ss -lp' to determine what is listening in port 23 when this happens (and is it sbbs?).

By default, the Synchronet ctrl/sockopts.ini file does not enable the REUSEADDR option. Is this option now enabled? If it is, then a second process (e.g. a second invocation of sbbs) could "take over" the port.

Ok, Thankyou!

Andrew

Re: Telnet Server
By: deon to Digital Man on Mon Apr 08 2024 09:21 am

Re: Telnet Server
By: Digital Man to deon on Sun Apr 07 2024 03:26 pm

Hi,

Because re-capturing a port that's already bound (e.g. to another server) can also bite people. It's generally something that's not enabled by default in TCP servers.

Oh really? What scenario?

IE: If I install SBBS (or a TCP server) and want it to use TCP port "x", why wouldnt I want it to re-capture that port if the server was recycled?

For example, if you accidentally ran a second instead of that same TCP server (or another TCP server configured for the same TCP port number), even briefly, the first server would no longer have the port bound/listening. It would just sit there silenty waiting for a connection that will never happen. Kind of like what Apam is describing.
--
digital man (rob)

Synchronet/BBS Terminology Definition #49:
KD = King Drafus (Allen Christiansen)
Norco, CA WX: 59.4°F, 51.0% humidity, 10 mph NW wind, 0.00 inches rain/24hrs

Re: Telnet Server
By: Digital Man to deon on Sun Apr 07 2024 06:03 pm

Howdy,

For example, if you accidentally ran a second instead of that same TCP server (or another TCP server configured for the same TCP port number), even briefly, the first server would no longer have the port bound/listening. It would just sit there silenty waiting for a connection that will never happen. Kind of like what Apam is describing.

I guess I've never seen this scenario (on Linux anyway). I have started TCP server apps on a host, and have clashed on TCP ports often (happens more frequently that you would realise with docker), and I've never seen a server "silently waiting" because it opened the port first, and another application came along and took it.

I did some (albeit quick) reading today on TCP and SO_RESUSEADDR, and what you are describing seemed to be a known windows issue (that perhaps has been resolved?). Somebody made a reference to it anyway...

I'll keep an eye out on stuff I use, and see which apps dont use SO_RESUSEADDR by default (given I stop and restart stuff often and quickly it should be easy to identify). I understand why it helps to get around a TCP protocol issue (the old port going into TIME_WAIT when it is shut down) - and it is a pain for synchronet when it is recycled and not set.

Perhaps you could implement a startup delay/wait? - since it is quite easy to trip you up if you dont have it and its not the default.


...δεσ∩

---
■ Synchronet ■ AnsiTEX bringing back videotex but with ANSI

Re: Telnet Server
By: deon to Digital Man on Mon Apr 08 2024 02:24 pm

Perhaps you could implement a startup delay/wait? - since it is quite easy to trip you up if you dont have it and its not the default.

There already is a port bind retry/delay (upon failure), and it's configurable. See the settings in sbbs.ini.
--
digital man (rob)

Synchronet "Real Fact" #55:
Synchronet Terminal Server introduced RLogin support w/v3.00c (2000)
Norco, CA WX: 46.3°F, 80.0% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs

Re: Telnet Server
By: deon to Digital Man on Mon Apr 08 2024 02:24 pm

I guess I've never seen this scenari
(on Linux anyway). I have started TC

I was going to say: On Linux, wouldn't
the second instance or whatever else
trying to take port 23 fail, and give
an error that the port is already in
use? That's what happens to me any time
I try to run two things on the same
port, anyway.

---
■ Synchronet ■ TIRED of waiting 2 hours for a taco? GO TO TACOPRONTO.bbs.io

Re: Telnet Server
By: phigan to deon on Mon Apr 08 2024 06:25 pm

I was going to say: On Linux, wouldn't
the second instance or whatever else
trying to take port 23 fail, and give
an error that the port is already in
use? That's what happens to me any time
I try to run two things on the same
port, anyway.

Yeah, unless you set the REUSEADDR socket option i think, then it can reuse the socket.

I wasn't aware that it could take over a socket that was actually in use, I had thought it just reused ones that were in the process of closing, but it sounds like my thinking is wrong.

So I think, using that socket option could be a bad thing most likely with SSH as synchronet could clobber sshd if it's running. It's unlikely that your setup is running a telnetd server, so in that instance it's unlikely to be a problem - but from what i understand in this thread, it's better to be safe than sorry.

Andrew

Re: Telnet Server
By: Digital Man to Apam on Sun Apr 07 2024 01:33 pm

By default, the Synchronet ctrl/sockopts.ini file does not enable the REUSEADDR option. Is this option now enabled? If it is, then a second process (e.g. a second invocation of sbbs) could "take over" the port.

Setting this worked. I was a bit confused because IPv6 was still running, but now that I think about it, I've noticed in the past using the sockets makes them get released a bit later, so I guess because I use IPv4 and not IPv6 the old process was hanging on just a bit longer.

Andrew

---
■ Synchronet ■ HappyLand - happylnd.synchro.net

Re: Telnet Server
By: phigan to deon on Mon Apr 08 2024 06:25 pm

I guess I've never seen this scenari (on Linux anyway). I have started TC

I was going to say: On Linux, wouldn't the second instance or whatever else trying to take port 23 fail, and give an error that the port is already in use? That's what happens to me any time I try to run two things on the same port, anyway.

Yup, that's my experience.


...δεσ∩

---
■ Synchronet ■ AnsiTEX bringing back videotex but with ANSI

Re: Telnet Server
By: Apam to phigan on Mon Apr 08 2024 07:48 pm

Howdy,

So I think, using that socket option could be a bad thing most likely with SSH as synchronet could clobber sshd if it's running. It's unlikely that your setup is running a telnetd server, so in that instance it's unlikely to be a problem - but from what i understand in this thread, it's better to be safe than sorry.

My understanding and experience, is that this is doesnt happen on Linux, probably was an issue on Windows (I read references to it) - and possibly other OSes as well?

If my reading is correct, when a socket is closed (it goes into TIME_WAIT for upto a minute or two - depending on the OS) and *without* REUSEADDR, the OS will not let another process bind to the port.

With REUSEADDR, it ignores sockets in TIME_WAIT (on Linux anyway) and lets you bind to the port. (You still cant bind to a port that is already LISTENING by another process, but I guess you could on Windows?)


...δεσ∩

---
■ Synchronet ■ AnsiTEX bringing back videotex but with ANSI