On August 15, 2025 12:32:31 PM EDT, "Massimo S." <ecs-isp@2rosenthals.com> wrote:
>
>
>Il 15/08/2025 17:56, Lewis G Rosenthal ha scritto:
>> 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
>
>the cmd close all applications and after do a setboot /b
>so, i'd say inside
>
Yes, that's inside the VM, which may not actually clear what needs to be cleared in this case.
I'm not overly familiar with how the hypervisor itself buffers network traffic. It may actually hold connections open in case the VM does not have focus just so that such sockets aren't closed prematurely (WAG - i.e., we know that we can set max execution time for a specific VM, which would not impact a client trying to talk to it, wo *something* most likely is keeping the connection ipen until the VM once again gets CPU time).
>> 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.
>
>thank you, good to know
>
>"acpistat poweroff" turn off only the "inside VM" or it's like virtual box machine power off?
>
Anything software controlled from the OS/2 side is going to take place inside the VM. So, I would look at scripting something to do a VBoxManage controlvm <vm> reset which will have the same effect as power cycling a physical box.
back to list