[Solved] Denon AVR Multiple Open HTTP Connections

---

I just checked my network connections on the raspberry when investigating an other problem…

32 open http connections to the receiver, doesn’t sound right and could be responsible for some problems as the receiver has very low processing power.

Ither the connections are not properly closed or not properly reused. You could take a look at my Harmony plugin, had similar problems and introduced some kind of connection pooling. This also made it faster for me as you don’t need to create a new connection everytime a command is sent or some value is polled.

@thex I’ll have look into this, which maybe no earlier than next week, however, as I am busy at the moment.

Btw, the plugin already uses connection pooling! What is the interval you have set and how many devices do you have? The plugin should only use one connection at a time to query the state, however, when the interval is short closing connections may pile up. Does the number grow further over time? What is the state of the connection entries?

If you can tell how to check the amount of opened connections I also can provide some information to solve the problem. I’m using the plugin very often by having a

• DenonAvrMuteSwitch
• DenonAvrZoneVolume
• DenonAvrInputSelector
• DenonAvrPowerSwitch

all with an interval of 10 seconds.

@Fabian Thanks. The netstat command can be used for that, for example, netstat -tn. You also need to have the IP-address of your AVR at hand to check the number of connection entries for connections to the the AVR. I use the following for continous online monitorring:

while true; do clear; sudo netstat -tn | grep 192.168.178.88; sleep 2;  done

However, the command sequence above may not capture short-lived connections as I only check every 2 seconds. Therefore I have also used a variant which continously logs the connection state to a file at a short interval.

The summary of my findings. There is no more than a single connection at a time in my tests with 6 devices and also experimenting with short update intervals.

@thex Please provide more input on the matter if you issue is remaining at your end.

Hi @mwittig;
i just recorded 3 minutes and this is the result. But beside to your plugin I’m also using some shellsensors to get some more infos.

pi@raspberrypi:~ $ while true; do sudo netstat -tn | grep 192.168.2.12:80 ; sleep 0.1; done
tcp        0    109 192.168.2.100:57262     192.168.2.12:80         VERBUNDEN
tcp        0    109 192.168.2.100:57272     192.168.2.12:80         VERBUNDEN
tcp      214      0 192.168.2.100:57274     192.168.2.12:80         VERBUNDEN
tcp      137      0 192.168.2.100:57304     192.168.2.12:80         VERBUNDEN
tcp        0    121 192.168.2.100:57334     192.168.2.12:80         VERBUNDEN
tcp        0      0 192.168.2.100:57360     192.168.2.12:80         VERBUNDEN
tcp        0      0 192.168.2.100:57370     192.168.2.12:80         VERBUNDEN
tcp        0      0 192.168.2.100:57400     192.168.2.12:80         VERBUNDEN
tcp        0      1 192.168.2.100:57412     192.168.2.12:80         SYN_SENT
tcp        0    109 192.168.2.100:57454     192.168.2.12:80         VERBUNDEN
tcp        0      1 192.168.2.100:57468     192.168.2.12:80         LAST_ACK
tcp      283      0 192.168.2.100:57476     192.168.2.12:80         VERBUNDEN
tcp        0    109 192.168.2.100:57498     192.168.2.12:80         VERBUNDEN
tcp      283      0 192.168.2.100:57528     192.168.2.12:80         VERBUNDEN
tcp        0      1 192.168.2.100:57558     192.168.2.12:80         SYN_SENT
tcp        0      1 192.168.2.100:57576     192.168.2.12:80         SYN_SENT
tcp        0      1 192.168.2.100:57576     192.168.2.12:80         SYN_SENT
tcp        0      1 192.168.2.100:57576     192.168.2.12:80         SYN_SENT
tcp        0      1 192.168.2.100:57578     192.168.2.12:80         SYN_SENT
tcp        0      1 192.168.2.100:57576     192.168.2.12:80         SYN_SENT
tcp        0      1 192.168.2.100:57580     192.168.2.12:80         SYN_SENT
tcp        0      1 192.168.2.100:57578     192.168.2.12:80         SYN_SENT
tcp        0      1 192.168.2.100:57582     192.168.2.12:80         SYN_SENT
tcp        0      0 192.168.2.100:57684     192.168.2.12:80         VERBUNDEN
tcp        1      0 192.168.2.100:57692     192.168.2.12:80         CLOSE_WAIT
tcp        0      1 192.168.2.100:57780     192.168.2.12:80         SYN_SENT
^C

@Fabian said in New Plugin for Denon/Marantz AVRs:

i just recorded 3 minutes and this is the result. But beside to your plugin I’m also using some shellsensors to get some more infos.

Thanks!

• Does the number of connection entries grow over time?
• Is it possible to deactivate the ShellSensors for some time to see which connection(s) originatie from the plugin?

Hi @mwittig,

Yes, definitely. If I start this command there is at first only one connection listet! I tried to put a timestamp in front of the output, but I had to delete all rows without an output of netstat by myself. So perhaps this helps…

pi@raspberrypi:~ $ while true; do i=$(date +%H:%M:%S)' '$(sudo netstat -tn | grep 192.168.2.12:80); echo $i; sleep 0.1; done
19:05:59
19:05:59
19:05:59
19:05:59
19:06:00
.......
...
..
19:06:08 tcp 0 0 192.168.2.100:46798 192.168.2.12:80 VERBUNDEN
19:06:13 tcp 0 0 192.168.2.100:46804 192.168.2.12:80 VERBUNDEN
19:06:29 tcp 0 1 192.168.2.100:46866 192.168.2.12:80 SYN_SENT
19:06:37 tcp 0 1 192.168.2.100:46884 192.168.2.12:80 LAST_ACK
19:06:40 tcp 0 121 192.168.2.100:46898 192.168.2.12:80 VERBUNDEN
19:06:45 tcp 0 0 192.168.2.100:46910 192.168.2.12:80 VERBUNDEN
19:06:54 tcp 0 1 192.168.2.100:46940 192.168.2.12:80 SYN_SENT
19:07:01 tcp 325 0 192.168.2.100:46964 192.168.2.12:80 VERBUNDEN
19:07:01 tcp 0 0 192.168.2.100:46968 192.168.2.12:80 VERBUNDEN

I also can try to deactivate my other connections. So, is it easily possible to uncomment oder deactivate some devices in the config?

@Fabian said in New Plugin for Denon/Marantz AVRs:

Thanks!

If I start this command there is at first only one connection listet!

This matches with my findings.

@thex any news / update from your side? I am still not able to reproduce the issue.

EDIT: Here is the command I am currently using. The command adds a timestamp if the grep on the netstat output produces a non-empty result. As you can see there is no more than one active connection at a time and closing connections are released quickly. Well the latter might be due to some tweaks of the stack configuration. I’ll review that to check whether or not my configuration deviates from the raspbian/debian defaults.

pi@raspi3:~ $ while true; do i=$(date +%H:%M:%S.%N); sudo netstat -tna | grep 192.168.178.88 | sed -e "s/^\(.\)/$i: \1/g";  sleep 0.1; done
11:57:55.455796655: tcp        0    204 192.168.178.85:46322    192.168.178.88:80       VERBUNDEN
11:58:15.644976480: tcp        0      0 192.168.178.85:46350    192.168.178.88:80       VERBUNDEN
11:58:20.779080242: tcp      407      0 192.168.178.85:46356    192.168.178.88:80       CLOSE_WAIT
11:58:25.865097068: tcp        0      0 192.168.178.85:46368    192.168.178.88:80       CLOSE_WAIT
11:58:30.858977009: tcp      407      0 192.168.178.85:46378    192.168.178.88:80       CLOSE_WAIT
11:58:45.957610682: tcp      407      0 192.168.178.85:46398    192.168.178.88:80       CLOSE_WAIT
11:58:48.707766795: tcp      407      0 192.168.178.85:46408    192.168.178.88:80       CLOSE_WAIT
11:58:51.104203005: tcp      407      0 192.168.178.85:46410    192.168.178.88:80       CLOSE_WAIT
11:58:51.256271166: tcp      407      0 192.168.178.85:46410    192.168.178.88:80       CLOSE_WAIT
11:58:51.747561011: tcp      407      0 192.168.178.85:46412    192.168.178.88:80       CLOSE_WAIT
11:59:01.027079364: tcp        0      0 192.168.178.85:46434    192.168.178.88:80       VERBUNDEN
11:59:01.187096535: tcp        0      0 192.168.178.85:46434    192.168.178.88:80       CLOSE_WAIT
11:59:06.103884012: tcp      407      0 192.168.178.85:46438    192.168.178.88:80       CLOSE_WAIT
11:59:11.283184064: tcp      407      0 192.168.178.85:46446    192.168.178.88:80       CLOSE_WAIT
11:59:16.178888191: tcp        0      1 192.168.178.85:46452    192.168.178.88:80       SYN_SENT
11:59:21.367397936: tcp      407      0 192.168.178.85:46460    192.168.178.88:80       CLOSE_WAIT
11:59:26.375913274: tcp        0      0 192.168.178.85:46470    192.168.178.88:80       VERBUNDEN
11:59:37.288145608: tcp        0      0 192.168.178.85:46486    192.168.178.88:80       CLOSE_WAIT
11:59:42.265101336: tcp        0      1 192.168.178.85:46492    192.168.178.88:80       SYN_SENT
11:59:48.946275886: tcp      407      0 192.168.178.85:46508    192.168.178.88:80       CLOSE_WAIT
12:00:02.435822549: tcp        0      0 192.168.178.85:46534    192.168.178.88:80       VERBUNDEN
12:00:02.593658560: tcp      407      0 192.168.178.85:46534    192.168.178.88:80       CLOSE_WAIT
12:00:07.432669288: tcp        0      0 192.168.178.85:46540    192.168.178.88:80       VERBUNDEN
12:00:12.593366835: tcp        0      0 192.168.178.85:46550    192.168.178.88:80       VERBUNDEN
12:00:12.756108330: tcp        0      0 192.168.178.85:46550    192.168.178.88:80       CLOSE_WAIT
12:00:17.572067946: tcp        0      0 192.168.178.85:46554    192.168.178.88:80       CLOSE_WAIT

@thex As I have heard back from you I assume the issue has been solved