Wireless Access

Hi,

We recently deployed Airtame devices to our network for screensharing/multicasting.

Our lan clients/wireless clients/airtame devices are all on different VLANs.

When on the LAN you can auto discover all the airtame devices.

When on a Windows machine and on our wireless the airtame devices will not auto discover.

When on a MacBook and on our wireless the airtame devices are discoverable.

It should be possible from the article below:

https://help.airtame.com/install-and-setup/deployment-guide/device-auto-discovery-multicast-routing-between-vlans

Has anyone seen this before?  

Airgroup has been set up for airtame and the Airtame service IDS added are: urn:airtame-com:device:airtame:1  

_airtame._tcp

Any help would be appreciated.

Hi Scott,

What's the output when you run the following commands while the Airtame and Windows Machine are both connected? I would hazard a guess the the Mac OS X is using mDNS for discovery while the Windows Machine is using SSDP:

show airgroup status
show airgroup blocked-service-id
show airgroup blocked-queries

cbjohns thanks for your reply.

The Windows machines discover when on the LAN (wired)

On the Wifi it doesn't discover any airtame devices.

Do you want me to run the commands when the Windows machine is connected via LAN to the Airtame ? Or should I manually type the IP into the airtame app to connect the Windows machine through WiFi and run these commands?

You are correct in that the airtames seem to be being discovered by the Macs over mDNS if you look at the airgroup servers table:

AirGroup Servers
----------------
MAC IP Type Host Name Service VLAN Wired/Wireless Role Group Username AP-Name
--- -- ---- --------- ------- ---- -------------- ---- ----- -------- -------
64:eb:8c:39:5d:fa 192.168.147.76 mDNS EPSON395DFA airprint 13 wireless kainos-guest UC_Reception_Port_G204_15115
38:4b:76:f0:41:c4 172.20.16.33 mDNS linux-15 airplay 12 N/A
a4:93:4c:aa:d0:01 172.20.160.54 DLNA Airtame 13 N/A
38:4b:76:f0:57:7a 0.0.0.0 mDNS Bytel.local airplay 0 N/A
38:4b:76:f0:43:ba 172.20.16.21 mDNS linux-6 airplay 12 N/A
38:4b:76:f0:44:b9 172.20.16.37 mDNS linux-16 airplay 12 N/A
38:4b:76:f0:57:13 172.20.16.23 mDNS linux-10 airplay 12 N/A
60:f8:1d:cd:7f:00 172.20.192.34 mDNS stone airprint 10 wireless kainos-corporate alisono UC_1-3_Port_G02_19192
38:4b:76:f0:4c:73 172.20.16.20 mDNS linux-11 airplay 12 N/A
Num Servers: 9.

The mac addresses starting 38:4b are all the airtame devices.

The mac address a4:93 with the DLNA type is actually the mac address of the firewall. 

I have attached the log files you have asked for also in a seperate file due to the length.

Appreciate your help so far.

Attachment(s)

logs.txt   451 KB 1 version

Thanks for including the "show airgroup servers" command. A few things I"m curious about:

1. Can you run the following command - I'd like to see the cached entries Airgroup is processing:

show airgroup cache entries | include 172.20.160.54 <or whatever ip-address may correspond with the show airgroup servers command for the DLNA Airtame>

2. With your Windows Machine on the LAN - can you run wireshark on the laptop and capture the discovery process of the Airtame App from first launch? You could do a capture-filter on "udp 1900" or a display-filter on "ssdp" and export the displayed packets that way to keep too much info from being exposed (or pm the capture).

OK so a little update: 

I am pleased to let you know that this has now been resolve.

I have been able to get this working by two steps:

Disabling our anti-virus software (which I had done before but it still was not working)

Also disabling on the Windows machines the SSDP service as Windows has the ability to run its on SSDP multicast group ( the same service that airtame uses) and this was grabbing the airtame multicast packets.

When both of these steps were completed the devices were then able to auto discover on wireless.

Now we are trying to get the airgroup to work with Remote APS.  Do you know if it is possible to get the airgroup stuff to work over RAPS which NAT behind a public IP?

Glad to hear you got it working. Interesting about the Anti-Virus and Windows SSDP Service -> I could understand the Anti-Virus if it was also functioning as a firewall (differentiating between two network type/locations and applying separate policies) - but the service is a bit perplexing since it worked on LAN but not WLAN. I was initially thinking they're was a "service id" issue - I saw that Airgroup was dropping "airtame:recv" service - I did a packet capture on my machine - and saw two M-Searches -> 1 for the "urn:airtame-com:device:airtame:1 " that you added - and 1 for that "airtame:recv" which is considered invalid with the uPnP Architecture as it doesn't contain the "URN:" prefix among other things - such as the Roku Remote Control app - which i see that your Airgroup is also dropping "roku:ecp". But didn't see that AirGroup received any queries for "urn:airtame-com:device:airtame:1".

As for the RAPs, I'm not sure on that. Are they operating in tunnel/split-tunnel mode?

The anti-virus has a built in firewall policies and it's policy is assigned by subnet.  The wireless subnet is different than the lan subnet which means the policies are different.  We will need to amend this.

I noticed that airtame:recv had massive dropped queries but i could not find this in the guide as to what this is even used for, we dont' even have this listed as a service ID as it is not a valid service ID.

The RAPs are operating in split tunnel mode.  The discovery will not work but if you type the IP in manually it will connect to the device.

Have you tried adding "permit" policies for SSDP-239.255.255.250 and mDNS-224.0.0.251 to send that discovery traffic over the tunnel to the controller for AirGroup processing instead of src-nat for SSDP/mDNS?

Yes we first tried the src-nat and that didn't work so we added this (screenshot attached)

However it still will not auto discover 

OK so here is a little update after thinking about the advice you gave me I allowed the UDP ports 1900-1901 and 5353 for SSDP discovery on the controller itself.  This means that now the RAP (the AP on the remote site) can discover all of the airtame devices on the site we have the controller (Back here at main office).

So now the auto discover works it just will not discover the airtame device that is on the remote site which would be local to the RAP.

The last step is to try and get the RAP to discover the local airtame on the remote site automatically.

Thanks

I cannot work out why the RAP can only discover the airtames that are local to the controller itself and not the airtames that are on the remote site (local to the AP).

I even discovered a setting under the AP system which says "Remote-AP local network access" and this is enabled.  So surely the RAP should see the local devices on that LAN?

---

@scottm wrote:

I cannot work out why the RAP can only discover the airtames that are local to the controller itself and not the airtames that are on the remote site (local to the AP).

I even discovered a setting under the AP system which says "Remote-AP local network access" and this is enabled.  So surely the RAP should see the local devices on that LAN?

---

How are the devices local to the RAP connecting? Wired or wireless? What is the forwarding mode? Tunnel, bridge, or split-tunnel?

Hi

Thanks for the reply.

The airtame devices are wired back to a local switch which the RAP is also connected to.  The RAPS are split tunneled.

Thanks

However static MDNS entries should still be shared by the controller? If the static MDNS entries are there then the connection should work as I can manually connect by typing the IP - this is the party I do not understand.

Thanks

---

@scottm wrote:

However static MDNS entries should still be shared by the controller? If the static MDNS entries are there then the connection should work as I can manually connect by typing the IP - this is the party I do not understand.

 

---

It's not a supported use-case for Airgroup. Because the RAP is operating in split-tunnel mode, there is a split between what is seen by the RAP and what is seen by the controller. Airgroup is not currently intended to operate in this scenario.

So what is the purpose of the static MDNS entries ? Because surely if they are able to be seen by the controller the auto discovery will work anyway so there would be no need for static entries?

Also I have tried to configure the static MDNS entries on our site with the Campus APs which are able to auto discover the Airtames.  However it does not display my static entires in airplay.

---

@scottm wrote:

So what is the purpose of the static MDNS entries ? Because surely if they are able to be seen by the controller the auto discovery will work anyway so there would be no need for static entries?

Also I have tried to configure the static MDNS entries on our site with the Campus APs which are able to auto discover the Airtames.  However it does not display my static entires in airplay.

---

If static mDNS entries aren't working, that is a separate issue and a case should be opened with TAC to investigate. 

Thanks for this.

I have opened a case so hopefully will get this resolved.

Just out of curiosity, have you worked with static MDNS entries before? I see not too much information online about these I guess most people don't use this feature. 

---

@scottm wrote:

Just out of curiosity, have you worked with static MDNS entries before? I see not too much information online about these I guess most people don't use this feature. 

---

Not personally, no. 

---

@scottm wrote:

The airtame devices are wired back to a local switch which the RAP is also connected to.  The RAPS are split tunneled.

 

---

That is not a supported configuration. If you are able to move the airtame devices behind the RAP so that the controller has visibility, that should work, but do to the NAT occuring at the RAP with split-tunneling it will not work.