Hi, Max...

On 08/15/25 05:21 am, Massimo S. wrote:

Il 30/07/2025 20:15, Steven Levine ha scritto:

In <list-13730074@2rosenthals.com>, on 07/30/25
    at 10:02 AM, "Massimo S." <ecs-isp@2rosenthals.com> said:

Hi Massimo,

        0 STREAM 42164        http..80 217.182.195.225  FIN_WAIT_2
        0 STREAM           56842      https..443 103.42.4.140 FIN_WAIT_2
        0 STREAM           18331        http..80 51.68.111.239 FIN_WAIT_2
        0 STREAM           62505        http..80 91.225.160.193 FIN_WAIT_2

all the FIN_WAIT_2 have 0 as socket number
if i use the scritp with:
soclose 0

Opps my bad.  I was not thinking clearly.  As you found, that's never
going to work even if try to use unsupported command line operands.

Netstat is not reporting the original socket number.  I have no idea if
this is by design or a netstat defect.

I wonder if a brute force approach might work - close the sockets that are
not listed as open as in

   run netstat -s to collect a list of open sockets
   for socket = 1 to 32767
     if socket not in list
       soclose socket
   end

The stack knows the FIN_WAIT_2 socket number or it would not be able to
prevent it from being reused.  The question is is there anything that can
be done to speed up to full release the socket resources.

Steven

hi all,

sorry, but, it do not work, it can't close stuff that it seems not to exist

i've seen this behaviour with eCS2.2b and AOS 503 under Vbox
maybe it is a sort of DDOS, or an issue of virtual box:

AOS 503:

1) the VM don't comunicate anymore with tcp/ip (in some case only icmp ping work),
i go into the vbox window, i start the reboot command (it close the services
and at the end do a setboot /b)

2) VM rebooted after some seconds the same behaviour happens again..

3) the same than 2 etc..

4) the VM restart i get a ring0 trap on OS2KRNL (too fast to read, i've no details)

5) at the next reboot all start to work well again


eCS 2.2b

1) the VM don't comunicate anymore with tcp/ip (neither icmp ping work),
i go into the vbox window, i start the reboot command (it close the services
and at the end do a setboot /b)

2) VM reboot, but stil do not communicate over tcp/ip, neither ping

3) setboot /b, same result

4) this situation last until i close in the bad way the VM, the red stop key

5) after it reboots and all work well again


what is the common point?
it's that in both cases i get "No buffer space available" on tcp/ip

It would help if you were more clear:

Are you:

1. rebooting the OS running in the VM; or

2. restarting the VM (which would be like power cycling a physical machine)?


It sounds to me like the OS is being restarted and not the VM. This keeps the virtual hardware "active" (powered on, with whatever hardware registers previously in use still in use).

If you are indeed restarting the VM (power cycle), next time try shutting it off, wait 10 seconds, and then start it again.

To be clear, buffers which do not clear during a reboot are generally something *above* the OS level (VM or hypervisor or physical hardware), and beyond the control of ArcaOS or the IP stack.