I have not observed this problem (Telnet server not responding while SSH does)
nor heard any reports of it, besides yours. I would expect the use of tools like netstat to help identify the real cause of that issue.

If I can restart synchronet and it goes away, I think that tells me
something.


* SLMR 2.1a * Oh, I see, said the blind man to his deaf wife
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: Automatically blocking co
By: Dumas Walker to DIGITAL MAN on Wed Jun 05 2024 08:54 am

I have not observed this problem (Telnet server not responding while SSH does)
nor heard any reports of it, besides yours. I would expect the use of tools like netstat to help identify the real cause of that issue.

If I can restart synchronet and it goes away, I think that tells me something.

It tells me that the TCP port was rebound. If the socket is configured for address/port reuse (in ctrl/sockopts.ini), then one could artifically create this exact scenario by starting and stopping a second process (after sbbs) that bound to TCP port 23. It could even be a second instance of sbbs. No "crashing" of the Synchronet telnet server would be required.
--
digital man (rob)

Sling Blade quote #12:
Karl (re hammer): I don't rightly know. I just kinda woke up holding it.
Norco, CA WX: 74.6øF, 67.0% humidity, 9 mph WSW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Automatically blocking co
By: Dumas Walker to DIGITAL MAN on Tue Jun 04 2024 09:34 am

I ran into issues (with 3.19 and before, anyway) where people or bots were hitting the telnet port rapidly and apparently not trying to log in, which meant they were not being throttled.

It would eventually "crash" telnet. I would have expected it to take down the whole terminal server but SSH would still be working. I would only
find out about it when a user complained that the BBS was down. A recycle of sbbs would fix it.

I did not have this issue specifically, but I had an issue where running telnet on port 23 led to me being unable to connect to my own system while no real users were connected multiple times over the past 3 days.

My solution was the old-school "press escape twice to enter the system" prompt that times out in 15 seconds. I keep track of people that hit that screen. I check for connections for each IP and then see how many times they have connected in the past ten minutes. Anything older than ten minutes gets deleted. If they fail that screen 20 times in ten minutes they get added to ip.can and are effectively banned.

I realize the amount of bots and scripts running these scans is basically endless...but it is keeping nodes freed up about as well as I expected. About half the nodes are occupied by bots, and I have not been blocked yet. So far manual checks of all of the IP addresses in the ip.can file are all Lithuania, Turkey, China, and Russia... The code is a bit messy (I have not really coded for several years)...but so far I am pleased with it.

---
þ Synchronet þ crisis/line úù [ crisisbbs.net ]

Re: Automatically blocking co
By: fluid to Dumas Walker on Wed Jun 05 2024 03:34 pm

Re: Automatically blocking co
By: Dumas Walker to DIGITAL MAN on Tue Jun 04 2024 09:34 am

I ran into issues (with 3.19 and before, anyway) where people or bots were hitting the telnet port rapidly and apparently not trying to log in, which meant they were not being throttled.

It would eventually "crash" telnet. I would have expected it to take down the whole terminal server but SSH would still be working. I would only
find out about it when a user complained that the BBS was down. A recycle of sbbs would fix it.

I did not have this issue specifically, but I had an issue where running telnet on port 23 led to me being unable to connect to my own system while no real users were connected multiple times over the past 3 days.

My solution was the old-school "press escape twice to enter the system" prompt that times out in 15 seconds.

I think the better solution is to use ANSI terminal detection. This is how the login.js auto-reduces the inactivity timeout for bots (which don't support ANSI). It's better to make everything these things transparent to users.
--
digital man (rob)

Steven Wright quote #16:
When everything is coming your way, you're in the wrong lane.
Norco, CA WX: 81.3øF, 55.0% humidity, 13 mph W wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

I have not observed this problem (Telnet server not responding while SSH does)
nor heard any reports of it, besides yours. I would expect the use of tools like netstat to help identify the real cause of that issue.

If I can restart synchronet and it goes away, I think that tells me something.

It tells me that the TCP port was rebound. If the socket is configured for address/port reuse (in ctrl/sockopts.ini), then one could artifically create this exact scenario by starting and stopping a second process (after sbbs) tha
bound to TCP port 23. It could even be a second instance of sbbs. No "crashing
of the Synchronet telnet server would be required.

Hmmmm... which setting would I want to set if I wanted to tell synchronet
not to allow the port to be reused by another process?

Currently, the only two options I have set in sockopts.ini are:

KEEPALIVE = TRUE
TCP_NODELAY = TRUE

I also see that IPV6_V6ONLY = 1 . What does that one do?

I suspect that these are all defaults as I don't remember changing anything
in this ini file, and the modify date is 8/20/2015.

Thanks!


* SLMR 2.1a * If you stomp gripes, do you get whine?
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

I realize the amount of bots and scripts running these scans is basically endless...but it is keeping nodes freed up about as well as I expected. About half the nodes are occupied by bots, and I have not been blocked yet. So far manual checks of all of the IP addresses in the ip.can file are all Lithuania,
Turkey, China, and Russia... The code is a bit messy (I have not really coded for several years)...but so far I am pleased with it.

A bunch of mine are from China and Russia also. Ukraine and Korea (not
sure which one) also get lots of bans.


* SLMR 2.1a * I still miss my Ex... But my aim _is_ improving!
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: Automatically blocking co
By: Dumas Walker to DIGITAL MAN on Thu Jun 06 2024 09:23 am

I have not observed this problem (Telnet server not responding while SSH does)
nor heard any reports of it, besides yours. I would expect the use of tools like netstat to help identify the real cause of that issue.

If I can restart synchronet and it goes away, I think that tells me something.

It tells me that the TCP port was rebound. If the socket is configured for address/port reuse (in ctrl/sockopts.ini), then one could artifically create this exact scenario by starting and stopping a second process (after sbbs) tha
bound to TCP port 23. It could even be a second instance of sbbs. No "crashing
of the Synchronet telnet server would be required.

Hmmmm... which setting would I want to set if I wanted to tell synchronet not to allow the port to be reused by another process?

On Linux, that'd be REUSEADDR = FALSE

Currently, the only two options I have set in sockopts.ini are:

KEEPALIVE = TRUE
TCP_NODELAY = TRUE

I also see that IPV6_V6ONLY = 1 . What does that one do?

From https://www.man7.org/linux/man-pages/man7/ipv6.7.html

IPV6_V6ONLY (since Linux 2.4.21 and 2.6)
If this flag is set to true (nonzero), then the socket is
restricted to sending and receiving IPv6 packets only. In
this case, an IPv4 and an IPv6 application can bind to a
single port at the same time.

If this flag is set to false (zero), then the socket can
be used to send and receive packets to and from an IPv6
address or an IPv4-mapped IPv6 address.

The argument is a pointer to a boolean value in an
integer.

The default value for this flag is defined by the contents
of the file /proc/sys/net/ipv6/bindv6only. The default
value for that file is 0 (false).

I suspect that these are all defaults as I don't remember changing anything in this ini file, and the modify date is 8/20/2015.

Yes, looks like defaults.
--
digital man (rob)

This Is Spinal Tap quote #26:
David St. Hubbins: They were still booing him when we came on stage.
Norco, CA WX: 80.9øF, 57.0% humidity, 9 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net