uPnP is not working properly since upgrade

OsmcUserSweden · 31 October 2020 19:45

Hi!

After the latest update it looks like the uPnp is not working. I use some apps on my mobile to listen to music and look at pictures from my Vero 4K+, but it is now stopped working.

Is there someone that has knowledge how to test these things on a network level? I mean what has to be present on the network for this to work?

Cheers!

Tom_Doyle · 31 October 2020 20:12

To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.

Depending on the used skin you have to set the settings-level to standard or higher, in summary:

enable debug logging at settings->system->logging
reboot the OSMC device twice(!)
reproduce the issue
upload the log set (all configs and logs!) either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A
publish the provided URL from the log set upload, here

Thanks for your understanding. We hope that we can help you get up and running again shortly.

OSMC skin screenshot:

OsmcUserSweden · 1 November 2020 08:24

I have been testning and it seems that the uPnP service announce it’s presence on the network, but very infrequent.

I started up my usual mobile apps for uPnP and then they suddenly showed OSMC after about 10-15 min aprox. So it’s working but not as before.

Is there some configuration to make this service announce it’s itself more often?

dillthedog · 1 November 2020 12:10

I can’t see a way to change the advertisement interval but a quick check using tshark shows that the interval is just 50 seconds.

osmc@osmc:~$ sudo tshark -i eth0 host 239.255.255.250
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
    1 0.000000000 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    2 0.000197499 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    3 50.027108084 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    4 50.027268656 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    5 100.034593939 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    6 100.034752272 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    7 150.053842841 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    8 150.054002788 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1

The rest of the time might be taken up downloading all of the directory and file metadata. (In the example above, the Pi3 doesn’t actually have any data to share.)

If you want to try it youtself, install tshark and repeat the above command.

OsmcUserSweden · 1 November 2020 21:20

I have installed tshark and came to the same results. The multicast-packets are sent every 50 seconds. The uPNP/DNLA-clients on my mobile are sending the M-SEARCH-packets every 10 seconds.

I think there is a problem with my local network that has nothing to do with OSMC. This is really strange.

I run the command: sudo tshark -i eth0 host 239.255.255.250 on my OSMC.
As soon as a M-SEARCH/SSPD-packet is registered by tshark (from client or server) the OSMC-icon pops up on my mobile app.

I tried running tshark on another computer which of course register the M-SEARCH-packets, but that doesn’t pop up the OSMC-icon on my mobile app. I have to specifically run tshark on my OSMC for this to happen.

Some possible explanations to this:

tshark sets the interface in some mode that propagates the packets better?
my router (with DD-WRT) is stopping some packets from reaching my WLAN (wifi-connected nodes)
My unmanaged Netgear switches are the problem

Network overview:

OSMC —> Netgear Switch --> Router --> Netgear Switch --> Linux Computer

Recap: I ssh from Linux Computer to OSMC. Run the tshark command and it works.

Anyone has any ideas on what is happening here?

(I have started a thread on DD-WRT-forum as well)

dillthedog · 1 November 2020 22:28

It could be a network problem but in your first post you said it looked like the UPnP problem started after the latest update – so it’s difficult to know where we should focus.

Regarding your possible explanations:

I’d place this last on the list of possibilities, though never say never.
That is possible. I remember a similar issue that involved Avahi mDNS broadcasts not propagating between wired and wireless parts of a local network. Zeroconf between rasbain and osmc - #12 by dillthedog The test results indicated that the router wasn’t bridging multicast traffic, though the reason was never established.
I double-checked and the consensus seems to be that if they’re fully unmanaged, it should work. If they’re “slightly” managed, you might need to enable IGMP snooping. What model(s) are the Netgear switches?

I’ll run a few more tests to see if I can understand what might be going on.

Update: On my LAN (actually a VLAN segment), everything works as I believe it should and there is no need to run tshark on the OSMC box for the multicast packets to arrive at other boxes on the (V)LAN. (You need to double-check if this particular problem can be reliably reproduced.) If you’re not running the 4.9 kernel and your Vero4K+ is up to date, the only significant difference on the OSMC side is that I’m using a non-plus Vero4K.

Placing a cheapo unmanaged switch (TP-Link TL-SF1008D) on the network also doesn’t stop the multicast packets from getting through.

From my limited experience of trying DD-WRT firmware, it can often have a few “rough edges”. If your router chipset can support it, OpenWRT can often be a better choice, IMO.

OsmcUserSweden · 2 November 2020 18:47

Hi!

I have done some more extensive testing and searched the internet for similare problem. I found that some has problem with the drivers of network interfaces with bad drivers and UDP-checksum offload.

On the OSMC I tried following commands:

* ethtool --offload eth0 rx off
* ethtool --offload eth0 tx off

With no change, but running following command

ifconfig eth0 promisc

makes the OSMC uPnp-service to immediately answer to clients M-SEARCH-packets.

So I would say this clears the router and the switches out of the loop and suggests that it is some problem with the upgrade of the drivers for the network card on the Vero 4K+ running OSMC.

sam_nazarko · 2 November 2020 19:04

That’s interesting. Does iperf show reduced performance after making this change?

dillthedog · 2 November 2020 19:30

Clearly, I can’t investigate any issues that might be specific to the plus version of the Vero4k, since I don’t have one. However, I thinks it’s worth recalling what you wrote in post #3:

Does this behaviour still occur when promiscuous mode is switched off?

OsmcUserSweden · 2 November 2020 19:31

Results:

iperf3 without eth0 set to promisc:

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.09 GBytes   939 Mbits/sec    0             sender
[  5]   0.00-10.05  sec  1.09 GBytes   932 Mbits/sec                  receiver

iperf3 with eth0 set to promisc:

As client:

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.09 GBytes   939 Mbits/sec    0             sender
[  5]   0.00-10.04  sec  1.09 GBytes   933 Mbits/sec                  receiver

As server:

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.03  sec  1.10 GBytes   939 Mbits/sec                  receiver

So, no performance change on the network level.

OsmcUserSweden · 2 November 2020 19:39

WIth the eth0 not running in PROMISC mode nothing happens. Below is the tshark log from another computer connected to the WLAN (Wifi) which have no problem seeing the M-SEARCH-packets:

1 0.000000000 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
2 0.000477645 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
3 5.120291881 OSMC uPnp-server → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
4 5.120735932 OSMC uPnp-server → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
5 10.035223336 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
6 10.035671018 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
7 20.070466914 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
8 20.070972704 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
9 30.105732061 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
10 30.106168638 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
11 40.140958924 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
12 40.141401438 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
13 50.176201560 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
14 50.176645891 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
15 55.296175775 OSMC uPnp-server → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
16 55.296581064 OSMC uPnp-server → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
17 60.006614488 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
18 60.007042685 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
19 70.041820436 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
20 70.042283763 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
21 80.077047397 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
22 80.077515612 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
23 89.293121079 MOBILEAPP CLIENT → 239.255.255.250 SSDP 235 NOTIFY * HTTP/1.1 
24 105.267552231 OSMC uPnp-server → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
25 105.267994745 OSMC uPnp-server → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
26 115.712437154 MOBILEAPP CLIENT → 239.255.255.250 SSDP 241 NOTIFY * HTTP/1.1 
27 116.736352512 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
28 116.736821146 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
29 126.771633344 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
30 126.772066429 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
31 136.602033276 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
32 136.602490387 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
33 146.637286503 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
34 146.637726503 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1 
35 155.443746131 OSMC uPnp-server → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
36 155.444171743 OSMC uPnp-server → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
37 156.672517581 MOBILEAPP CLIENT → 239.255.255.250 SSDP 205 M-SEARCH * HTTP/1.1 
38 156.672983562 MOBILEAPP CLIENT → 239.255.255.250 SSDP 238 M-SEARCH * HTTP/1.1

OsmcUserSweden · 2 November 2020 19:59

I have come to the conclusion that it has to be the network drivers for eth0 that was upgraded for Vero 4K+ and thus blocked MULTICAST-packets in normal mode. Could someone concur or verify this conclusion?

dillthedog · 2 November 2020 20:00

You didn’t answer the question.

OsmcUserSweden · 2 November 2020 20:08

Sorry,

Sorry, in short yes.

But to make extensive tests and just look at a mobile phone app is not an option. My cable connected LAN is running at 1Gb/s and I thought maybe the packets from OSMC got dropped over the WLAN because of this. But thats not the case as tests above show.

dillthedog · 2 November 2020 20:16

You should switch off promiscuous mode on the Vero and run tshark using the -p flag (its position is important) which will run tshark in non-promiscuous mode:

sudo tshark -p -i eth0 host 239.255.255.250

Does it see any SSDP multicast traffic from your mobile phone? If so, what is the interval between the first and second batch of messages?

Edit: Oops. Position of -p corrected.

dillthedog · 2 November 2020 21:52

Just a bit more info. While running Kodi with UPnP enabled on a Pi3, I ran tshark on my Vero4K both with and without promiscuous mode enabled (I think).

Promiscuous mode:

osmc@osmc-4k:~$ ifconfig
eth0: flags=-28349<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,DYNAMIC>  mtu 1500
...
osmc@osmc-4k:~$ sudo tshark -i eth0 host 239.255.255.250 
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
    1 0.000000000 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    2 0.000188086 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    3 300.193014042 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    4 300.193272669 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    5 350.238665266 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    6 350.238730100 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    7 400.266473963 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    8 400.266693882 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1

Non-promiscuous mode:

osmc@osmc-4k:~$ ifconfig
eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC>  mtu 1500
...
osmc@osmc-4k:~$ sudo tshark -p -i eth0 host 239.255.255.250 
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eth0'
    1 0.000000000 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    2 0.000068460 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    3 300.229996078 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    4 300.230091454 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    5 350.278980088 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1 
    6 350.279046423 192.168.8.33 → 239.255.255.250 SSDP 215 M-SEARCH * HTTP/1.1

In every case, after the first packets arrive, there is a 300-second delay before they resume, and then they arrive every 50 seconds. I double checked and the Pi3 is producing M-SEARCH packets every 50 seconds, so the reason for the 300-second break is unclear. (It might be specific to my switch, for example.)

OsmcUserSweden · 2 November 2020 23:06

I have run the command as suggested above with following result:

no SSDP packets from mobile client
no SSDP packets from VLC running in a Linux machine connected to LAN via cable
SSDP packets from OSMC are shown every 50 seconds.

But now I am back to square 1. I don’t think it’s the network interface but rather something to do with the Netgear Switches.

I have Netgear Unmanaged Switch GS108 and I think they are so stupid that the ports copy the mode of the Ethernet device connected on the other side of the RJ45-cable. Thus filtering the multicast packets.

I have to do more studies to see if this is the case.

OsmcUserSweden · 3 November 2020 05:15

Strangely when stopping and starting “Enable uPnP support” in the gui OSMC/Kodi-icon pops up on the wireless units. I see in tshark that multiple SSDP-packets are sent from OSMC. So what’s going on here I have to study. I have also connected the Vero 4K+ directly to the router without any change in this subject.

Next test will be to simulate a uPnP on another computer and see what happens.

OsmcUserSweden · 3 November 2020 06:32

Okey, friends!

For testing on my local network i installed Rygel, a mini-DNLA-server running on a laptop. It was no problem for my WLAN-clients to identify the service on my network.

So my final conclusion is that the uPnp-service on OSMC is broken in some way since the latest upgrade. There is no problem with switches and router. Multicast is working fine, as I can see it.

What is the next step? Upload logs?

dillthedog · 3 November 2020 21:39

I can see nothing in the Kodi 18.8 changelog that might have affected UPnP, though perhaps @sam_nazarko is aware of something.

As things stand, UPnP does work, but you say that the clients need 10-15 mins to pull down the metadata. UPnP doesn’t get much love from Kodi devs at the best of times, so I suspect that there will be a reluctance to devote limited resources fixing something that still basically works, even if imperfectly for you.

I think you’d have a much better chance of achieving your goal if you were to install a dedicated DLNA server on the Vero4K+. Two that I quickly found available on Debian are Gerbera and MiniDLNA, though there are likely to be more. Gerbera uses a Web UI and MiniDLNA seems to command-line based.