Adapter eats up UDP ports #282
Comments
|
At the first look I cannot reproduce this. I've 2 instances running at my production system. They use exactly one udb port per configured device. The are running since weeks... Do you have any relevangt logs (exceptions, errors) which might be related? |
|
Code Review noticed for internal purpose only: Line 1401 in a8abe79 |
|
I have two different iobroker installations and both show up the same behavior. I just checked the use of the USP port after the restart in the afternoon when I wrote the error report. |
|
I've asked at forum test thread. Until now I did not get any feedback. Currently only one code part could cause lost udb port. In this case you should have a warning logged: ````device ${pCTX.name} (${pCTX.ipAddr}) reported error ${pErr.toString}``` Could you please check you logs (including older logs if possible) if you have such warnings logegd from snmp adapter. Each such warning could possibly result in one lost udp port. |
|
Unfortunately I could not reproduce that problem again. I had it before a few times with having traced it down to the SNMP adapter. I have also mis-configured one of the installations with an ip that does not exist and an ip without a running snmp daemon just in case it a bad line is the reason for that problem. Backgound: I do have a wireless connection between two buildings and this might have bad connections sometimes. Regards |
|
Yes i would keep the ossue open any2ay. Could you please check if older logs exist and scsn for ghe warning i mentioned befote. Maybe an instable line could cause udp errors. On he other side i do not gave a real idea how to force errors at udp port as its connectionless. |
|
After I wrote my comment this morning without any new issues I have just ran into the problem now again on both machines.
Now I created a log file with all SNMP adapter message which I will attach here. Be aware that the compressed file is only 13MB but the uncompressed file is about 500MB. Maybe that help to track down the problem. This log file is NOT from the system with the wireless connection. So that seem not to be the problem. |
|
Thanks i ll check the log. |
|
Just take your time. For your information also a screenshot of the top processes. Please note the CPU percentage.
|
|
Just a short snippet from the log. No other messages between.
Similar messages on both installations. |
|
Thanks for investigation. And there seems to be a second error there - normally there should be an error text output... I'll correct the code and give feedback as soon as it is testable. |
mcm1957
added
bug
next release
|
The SNMP instance polls my network components (access points) regularly. These AP do have the mini_snmpd running. Would you need the config files of them to eventually run a virtual machine? Some other note: after a while the adapter seems to release all the ports and the same repeats. |
|
should be fixed with 2.4.8 @TheKilroy a) normalle the errortext should be output with the warning filtered by you. Du to atyp this was not the case. Starting with 2.4.8 the error text delivered by node-net-snmp should be visible now. In addition the complete stringified arror objet is output when enebling debug logging. This should enable you (or me?) to solve the original problem causing the errors b) whenever an error was signalled the udp port was not close but a new one was opended. Thus for every error one udp port got lost. This should be fixed now to - although I hope the errors occure at your system still to verify this. So please test 2.4.8 id possible at one of your systems. The release is available at github and will be available at latest repository tomorrow. Please be aware that this is a beta/latest release so do not use it at productive systems or take at least special care and ensure that you have a working (and restoreable) backup. Thanks for any feedback. |
|
Thank you for your effort. I have installed the new version directly from github and will observe it the next time. |
|
Some new info and and a snipped from the log file. Checked the log file today and the number of used UDP ports. Here a snippet from the system with the 2.4.8 version. Result: no missing ports, but an error message.
It seems to be solved but I will observe it for a few days. The error probably comes from the use of the mini_smpd on my OpenWrt router. As far as I have seen are all values limited to 32bit numbers, but I will double check it. |
|
Ok, What I'm missing is a create session afterwards, This should occure after the retry timeout (I think 5 sec per default). Without this createSession no future data would be recorded for this device. Please verify that the device is not dead after an error forever. By checking use raw states and use type states you should be able to see which data type and which (binary) data is transmitted - but only if the data can be read and passed to the adapter. Mayby this can help diagnosing the oid with problems. The -5108 could either be an overflow or the type of the oid should be signed int32. There could be an error at node-net-snmp too, but befor opening a issue there more data would be required. Thanks for testing. |
|
I've created a new release 2.4.9 -) the extended json stringified dump of the error will now be displyed (at least I hope so :-) )
I'm not sure if closing the session is really required or node-net-snmp (the layer provising the snmp encoding/decoding) could continue without a reset of the session. With this option both possibilities are available now. So please try disabling closing the session. The main difference will be that an active read block will not be aborted and that no retry wait time is set up. |
|
Ypu are right, that a new session is created. I just did not copy the lines from the log file.
I have checked both options and will observe the behavior and tomorrow I will install 2.4.9. Great job done. |
|
Ports will be closed already with 2.4.8. |
|
Thanks for the update |
|
Here finally some info about the logging output of version 2.4.9 That is the part of the log file showing the error output. Still the range check error about the "unsigned 32bit integer" which is fairly easy to understand that a negative number does not work with it. I will also attach the a file holding some more lines. These are all lines logged by the SNMP adapter from 14:00 until I copied the file - so about 45 minutes continues log. For your explanation: Thank your for all your effort. I really appreciate your work. |
|
Thanks for the feedback. So 2.4.10 should no longer display |
|
I will test it and will report |
|
Here is the latest output to the log file showing the error message I will attach also a bigger part of the log file where the error message disappears after the value turns positive again. That behavior makes me curious to investigate and I will try to figure out what might be the reason for it. Thanks and greetings to Austria |
|
Thanks for Info. BUT As a PR exists I would expect an improved release within a few months. The reason could be (and this would be fixed by the PR) that you snmp client sends incorrect data. A big unit32 number seems to need a leading zero byte (if the MSB of the real data is set) otherwiese ist is assumed to be negative. So I see the following real solutions: -) you cantact the development of your snmp cleint and ask them to check / fix the issue I do not see any change to work around the problem at ioBroker.snmp adapter. |
|
Well, the first issue loosing the UDP ports is solved. |
|
As a new version of node-net-snmp is on the way I'll keep this open to track implementing ist at iobroker.snmp adapter soon. |
mcm1957
added
dependencies
* (McM1957) Node-net-snmp has been updated to improve uint32 handling (#282) * (McM1957) Several other dependencies have been updated
|
@TheKilroy Feel free to test the new release and let me know if the problem is fixed completly if you have time for a test. Adapter version 2.4.11 will be available at latest repo tomorrow. |
|
Thank you. Will install it right away now and let you know. |
|
@TheKilroy |
|
Sorry for the late reply.I have updated both installations and all seems to be fixed. No error anymore - not the original one and not the resulting. So you may close it from my point of view. |
|
Fixed with 2.4.11 |
** Adapter eats UPD ports **
Having a problem on a Raspberry Pi4 that a simple ping command gave the error message "ping: connect: Resource temporarily unavailable"
root@shsrv01:~# ping 192.168.99.1ping: connect: Resource temporarily unavailableTracing the error I used the command
# lsof -i -n | grep snmpwhich gave me an endless list of entries like
io.snmp.0 17911 iobroker *092u IPv4 1366517 0t0 UDP *:37626So I used to the command
# lsof -i -n | grep snmp | wc -l28237to count the lines. The result was 28237 open UDP sockets by the io.smp process.
To reproduce I restarted because a simple
iob stop snmp.0did not make it. After a few days I got the same result. After a few days again I triediob stopandiob startand that worked. But that can not be a solution.Versions:
$ lsb_release -aNo LSB modules are available.Distributor ID: DebianDescription: Debian GNU/Linux 11 (bullseye)Release: 11Codename: bullseyeHere the configuration of the SNMP Adapter
The text was updated successfully, but these errors were encountered: