Hi, Max...

On 07/28/25 05:52 am, Massimo S. wrote:

Hi all,

sometime this happens on a couple of VMs here:

netstat -r (or other commands) give the output in the subject.


Of course is there anything that i can do other than the setboot /b ?
Any suggestion?
Thanks.

(This happens on an AOS VM and also on eCS2.2b VM)

This is an elephant gun solution (reboot) to a very common problem.

When you run out of network buffers, something is likely leaking network buffers (i.e., using them and not returning them to the pool when finished).

You should start closing applications one at a time until the number of available buffers returns to a more normal level (netstat -m is your friend), then restart those applications. Either there is a configuration setting which might be changed or a defect in the code causing this.

Buffer usage is often hard to predict, but it should ebb and flow with network traffic. If it doesn't, there is something not giving them back to the pool for some reason.

Also, netstat -i will give you a count of packets lost due to no buffers available (and other unusual happenings).

Something else you can try (half an elephant gun) is running socktidy and stopping it. This will close those unused sockets consuming buffer space. However, this will not fix the underlying problem (too many connections allowed for something?). It will save you a reboot. As a working kludge, you could run socktidy once every few hours to dump the cruft.

As a rule, I do not run socktidy on servers because it can interrupt the flow of some slow connections which might need to remain open a bit longer. It's fine on workstations, however.

A final thought would be to trim your tcprwinsize. If you are using something above the default, then lower it a few bytes at a time while monitoring the situation over the course of a few days. Larger window sizes consume more buffers.

The OS/2 IPv4 stack is quite robust. The venerable BSD on which it is based (in fact, from which it was ported nearly verbatim) runs many, many boxes to this day. Sadly, as with old car restoration, there are fewer and fewer of us around who have taken the time over the years to learn the basic concepts of the system and who understand how the various parts of the stack fit together (not the "Windows way").

HTH Food for thought, at least.

Cheers