Process physical interface only.

[catro]

When VPN is established in Ubuntu, the first connected interface is ppp0 and MAC is 00:00:00:00:00:00. AirTunes/Airplay use MAC of first connected interface. Airplay device can not discover Kodi when the deviceid is all zeros.

[Memphiz]

I am fine with this in general - but please change the comment to something easier like "only add interfaces with non-zero mac addresses" - your comment is a bit complex imo. Also are you sure that there is no use case were we would need those interfaces (i mean beside airplay - some other network service in kodi maybe?)

[catro]

Thanks for reviewing the pull request. I have modified the comment as you said.
I searched 'queryInterfaceList' and 'GetFirstConnectedInterface'. UPnP module uses the first connected interface too. But I don't think it will be affect by using first physical interface.

[Paxxi]

Wouldn't this depend on what the vpn tunnel is used for? If there's a kodi instance at the other end they won't be able to share libraries over upnp with this change?

[Memphiz]

Yes thats what i meant. Maybe we need to adapt the interface so that a bool flag decides if the first interface or the first physical interface is to be queried. And then in the airplay code explicitley ask for the first physcial device and leav the other places unchanged in behavior.

[Montellese]

I've seen similar issues when testing my media importing over UPnP. If I had a VPN connection open (for something else) while testing our UPnP code would randomly choose to use the VPN connection during startup and would then start announcements etc on that interface and my tests would fail. On windows you get a lot of virtual network interfaces (from VMWare, VirtualBox etc) which can all interfer with code that locks on to a specific interface.

But I'm not sure what the best way to solve this problem is because there may be use cases where someone wants to connect to Kodi instances over a VPN connection (as mentioned before).

[Paxxi]

I'm thinking we would need to actually use all interfaces and keep track of which one a response came in on and reply back on the correct interface

[Montellese]

@Paxxi: AFAIK the upnp library is written in a way that it can only handle one interface. The same holds true for some other upnp libraries I looked into. And you can't even start multiple instances of it because a lot of things are global (at least in Platinum SDK).

[wsnipex]

Imho we need a setting that allows selecting an interface for kodi to bind on.

[Paxxi]

@wsnipex a setting seems like the only option currently but I'd rather try and find another solution as it's not something a user should know or will know anything about

[Memphiz]

I already hear it "I need to bind to the network and the wan interface at the same time for beeing able to access my kodi installation from inside and outside. I am using a dsl modem directly connected to my pc via pppoe" :D

[wsnipex]

its really common place for any kind of "server" software to allowing for binding to specific interfaces(or all) and there are good reasons to e.g. bind to internal IP only.

[Memphiz]

Yes it is. Airplay for example can only bind to one device though. (because there is only one bonjour announcement which can only hold 1 mac address).

[Paxxi]

@wsnipex you said it, for server software, we're targeting another type of user entirely.

@Memphiz it might be that current implementation only handles one interface but it should certainly be possible to use for several interfaces sending bonjour announcement per interface

[wsnipex]

@Paxxi not really. We provide a webserver, upnp server, airplay etc. Those are classical server services.

[Paxxi]

@wsnipex but our main userbase isn't server admins so I don't see the point and as I mentioned a setting may be the only possible solution.

To get things back on track, will this pr make things better or worse for linux users? Is it worth merging or should we aim for a better solution?

[mk01]

@Memphiz

this problem will disappear with the new network code. currently the interfaces are read from /proc/net/dev and sorted who knows how (kodi is not reordering later, all iterations through the array of interfaces happens in the order as they were red).

in the new code the interfaces are specifically ordered by addr family (AF_PACKET(network card), AF_INET, AF_INET6, within same family the order is based on mutual dependency, then at last alphabetically).

in case of let's say one network card and wifi, ipv4/ipv6 configuration, having bridge, virtual interface, then 6to4 tunnel and let's say finally on top ppp0 dialup, the order would be (skipping loopback configurations in the list and wlan0 is not part of bridge):

eth0, wlan0, br0, virb0, sit0, 6to4 with AF_PACKET (so MAC and other physical information),
br0, wlan0, virb0, ppp0 with AF_INET
br0, wlan0, virb0, sit0, 6to4 with AF_INET6 (if ppp would have ip6 config, it would be last again).

so in that particular situation of @catro ethX (or brX) will be returned instead of ppp0.

btw: by excluding IFs without MAC, all URI.cpp dependent code will completely break for media targets being accessed over interfaces like many kind of tunnels (as ppp, v6 point-point.... 6to4 should be fine). there is call to IsOnLan() all over the place (even unpacking of subtitles and similar) which ends up at specific platform network code implementation and it's HasInterfaceForIP().
just quickly looking into URI and URIUtils I have even seen that a negative response to IsOnLan() is used to define the URI being a local file (not a network connection).

[mk01]

just one more comment - and I might be wrong - but MAC address in the workflow of mDNS is irrelevant for IP resolution of the target and protocol uses it only to assemble a 'name' (probably unique). during negotiation and resolution the multicast packets do not cary this information at all and if it is broadcasted then as part of something like user-agent.

also the 'primary' or 'binding' interface for mDNS service is not much relevant as this is multicasting, packets are sent on all interfaces to all directions and the mDNS info being inside consist of hostname and ALL locally configured IP's on all (allowed) interfaces. so the client side picks up the one specific IP it can connect to.

it should be tested but I honestly think that the AirServer (being Kodi) is not shown / recognised because it sends nonsense info (MAC being all zeroes what is against specs). the same reason as when one can change hwaddr on interface to anything but not all zeroes.

[Memphiz]

You might be right that the mac address issue is in the higher level protocol of airplay in this case. Though IIRC when looking at bonjour announcements via bonjourbrowser i see a mac address in the lower layer aswell - might be that bonjourbrowser determines it via arp lookup though.

[mk01]

@Memphiz

You compile your Kodi against system wide accessible mDNS server like Avahi-daemon or the mDNSembeded is compiled and linked in ?

@catro

can you please answer the same question and also - regardless of answer - install tcpdump and start it like this:

root@cubh ~ # tcpdump -vvv port mdns and multicast and host hum | grep 36667

and replace "hum" in this text with hostname of the Ubuntu system (or it's IP). then wait until you get the mDNS announcement and post it. Please do the same with ppp0 being active. the announcement should be one-liner like this:

    hum.private.mdns > 224.0.0.251.mdns: [bad udp cksum 0xa3c1 -> 0xd4bd!] 0*- [0q] 6/0/0 _services._dns-sd._udp.local. [0s] PTR _airplay._tcp.local., _airplay._tcp.local. [0s] PTR cuph._airplay._tcp.local., cuph._airplay._tcp.local. (Cache flush) [0s] SRV cubh.local.:36667 0 0, cubh.local. (Cache flush) [2m] AAAA 2002:5410:265c:0:200:ff:fe00:1, cubh.local. (Cache flush) [2m] A 192.168.1.23, cuph._airplay._tcp.local. (Cache flush) [0s] TXT "features=0x77" "srcvers=101.28" "model=Xbmc,1" "deviceid=00:00:00:00:00:01" (237)

Also can you be more specific if you don't see the Kodi as Airplay destination only, but you can still see it via any kind of Bonjour browser. If it is embedded closed device (so you can't put browser on it) you can check on any pc, even the Ubuntu itself.

[Memphiz]

@mk01 - neither - osx uses the cfnetservice api from CoreServices framework

[mk01]

@Memphiz

ah ok. osx(bsd) uses that code already. and the ordering is the same as with it's glibc counterpart - so correct.
I just looked into osx/Kodi running with AirPlay service and the mDNS announcements coming from apple's native provider are inline with those from avahi-daemon. The hwaddr info is not embedded by API and it multicasts 1:1 what Kodi bundles in the request.
I checked how it works with two enX interfaces active having two not bridged segments. While Kodi started with one of them primary and announcing it's hwaddr, iPhone plays via Kodi while being attached on the other segment (so attached to different enX with different hwaddr).

...

Recompiled Kodi/linux with hardcoded 10:00:00:00:00:00 and I can play from mac/iphone with no issues. This means hwaddr is irrelevant to this service, as much as it is valid. Otherwise the mDNS messages are not parsed by mDNS API provider and client sees no device available.

This could be a way until the permanent fix:

mk01@edd28fd

@catro
can you compile your Kodi with that patch and test/report back?

[Memphiz]

yes that would be an acceptable workaround because it only alters behavior for airplay.

[catro]

@mk01, thanks for your patch. But I'm not at home for few days. I will let you know the test result.

[catro]

@mk01, I compiled your patch and AirPlay doesn't work when VPN is connected. Here's the tcpdump result.
When VPN is disconnected, AirPlay works. Here's the tcpdump result

[mk01]

@catro

recompile please with this new commit
mk01@18b3c47

(AirTunesServer updated the same way - to lookup macaddr != 0 - mk01@18b3c47#diff-b7fef91ff63844bd107a04e719b39ab2R551)

[catro]

@mk01 , with another one line fix, airplay works well. See the commit https://github.com/catro/xbmc/commit/11e818250edaf9a69dcf477993aa1e2cff741ca7
Thanks!

[mk01]

@catro

ok, then it will get fixed automatically with the new networking (once merged).
thanks for feedback.

[catro]

Thanks

[razzeee]

So should this be closed in favor of the new networking, which might one day get merged or what are we doing with this?

[wsnipex]

we should probably merge this until the new networking finally is ready

[razzeee]

jenkins build this please

I will merge this tomorrow if nothing pops up.

[razzeee]

jenkins build this please