UPnP & Chromecast

Chuckarama

I'm trying to run my new chromecast device on my home network. PFSense is all infrastructure on my home network. Everything except my wireless, but my AP is simply a dumb radio with an ethernet cable in one side - it does not do dhcp or provide any other network services. It is an Engenius ECB350 set in AP mode. My pfsense is:
Current version: 2.1-RC0
Built On: Fri Jul 5 06:53:46 EDT 2013

My problem seems to be, as reported by Google here, at google, is that I didn't have UPnP enabled. I know about the dangers of UPnP, but this is my small home network and I can live with it there. I have enabled UPnP and see it is working.
Aug 16 18:58:59 miniupnpd[17604]: HTTP listening on port 2189
Aug 16 18:58:59 miniupnpd[17604]: Listening for NAT-PMP traffic on port 5351

To start I have enabled it with pretty much everything running and will dial back from there. I opened up pretty much all ports on the full class C:
allow 1-65535 192.168.0.0/24 1-65535

A bit about how it appears chromecast does it's setup. The chromecast device broadcasts a very low powered 802.11 network - very short range and I have to stand pretty much right next to it. The install software is run on your laptop or phone. The setup software connects your phone/laptop to the chromecast network (yes, you get disconnected from your other wireless networks) and they connect up. After you verify you're connected to the right device with a code acknowledgement, you select on your phone/laptop which wireless network the chromecast device will ultimately connect to. Select your home wireless network, enter passphrases etc. You tell it to connect and the chromecast device begins trying to connect to your home wireless network and your phone/laptop disconnects from the chromecast wireless and tries to reconnect to your home wireless again. At this point I presume the setup software running on your phone/laptop begins searching your home wireless network for the device. If they fail to find each other, the chromecast setup fails and backs out.

Now on the home network side, I can see that my chromecast device shows up in arp (it shows the mac it is using in the setup software briefly) and it successfully hits dhcp and is given a lease. Services on the network are performing as expected to this point, but alas, the chromecast softwares cannot find or discover the device on the network and so setup fails. I check the status of UPnP in pfsense and see that one of my ReadyNAS devices (an embedded Linux device) is registered, so something is working somewhere inside pfsense, I presume at this point. I check the Routing System Logs and see a couple of these messages, but I can't really tell which network device may be doing it:
Aug 16 19:03:59 miniupnpd[17604]: upnp_event_recv: recv(): Connection reset by peer
Aug 16 19:11:09 miniupnpd[17604]: upnp_event_recv: recv(): Connection reset by peer

It would appear that something wants to register, but no way to know if it's even my chromecast device so I do a forum search and find that at least as of sometime late last year, miniupnpd was not functioning correctly in 2.1 yet and I find no follow-up indicating when it might have become properly functional. So I guess my final question would be, is it functional yet as of the newer RC0 builds? If it is, can someone maybe point me where to poke around next in pfsense or on my network to find my chromecast issue?

stephenw10

Hmm, my knowledge of UPNP is perhaps not what it could be but I have a number of problems with this.
I fail to see why your two devices can not find each other if they are on the same network subnet, which they are. Traffic between the two devices does not go through the pfSense box at all so any settings you might make will do nothing.
The above would be true if the devices were using broadcast to find one another. I speculate that they require the SSDP part of UPNP to work. UPNP is in fact a large collection of things and unfortunately miniupnpd only implements the IGDP part. That means that if your NAS is registered in the upnp table in pfSense it probably means it's opened up a connection to itself directly from the internet. You may not want that. ;)
Mostly I have a problem with this:
@https://support.google.com/chromecast/answer/3213086:

UPnP (Universal Plug and Play), also known as multicast,….

Say what! UPNP is not the same as multicast, at least not in my world!

This is not helping you with your Chromecast though. To make this work, this way, would probably require miniipnpd's sister daemon minissdpd. There was some discussion on adding that some time ago, I'm not sure if anything was done.

I would look into ways of doing this without using SSDP, though I have no idea if it can be done.

Steve

Edit: One thing, do you have 'station separation' enabled on the access point? That would cause this.

Chuckarama

One thing, do you have 'station separation' enabled on the access point? That would cause this.

Good question. That is actually the first thing I checked on the AP and isolation is not enabled.

I suspect these chromecast devices are going to be more and more popular and I expect to start seeing lots of them soon. I keep hoping it's something simple and obvious that I just don't know about or see…

stephenw10

Here is a relevant reddit thread: http://www.reddit.com/r/Chromecast/comments/1j77yz/my_chromecast_issues_experience_with_google/

Most people, of those who did resolve the problem, seemed to find it was some sort of wifi client isolation.

Thinking about this it shouldn't matter that pfSense doesn't support SSDP that would only stop clients finding the pfSense box by that method. They should still find each other.

It seems like a poor decision if Chromecast requires a full upnp implementation on the router to work. Particularly in light of this: http://forum.pfsense.org/index.php/topic,58270.0.html

Steve

Edit: typo

kejianshi

I'm not a big fan of do nothing dongles that should just be a piece of software on a machine.
Like steve10 said, there is nothing that the pfsense is doing or not doing that would effect communication between a couple of devices on the same subnet of the same LAN and on the same switch. Its probably either your AP, one of the devices its self of perhaps they are not on the same subnet of same LAN and same switch?

stephenw10

I would need to read up on this further but I could imagine a situation where both the Chromecast device and the Chromecast setup software are both SSDP clients. In such a situation something else would have to act as an SSDP server in order for the discovery information to be stored and forwarded between them. pfSense does not do that (I think!). One way around this would be to introduce something else that does. The wiki page is confusing here. Both the device and the software seem like they should be 'control points' that would do this already.

I'd still suspect some isolation issue. Pretty easy to test if you can ping between two wifi devices. Also if the Chromecast device has obtained an IP address via DHCP, can you ping it?

Steve

kejianshi

So, I'm reading this:

http://en.wikipedia.org/wiki/Miracast

But this line makes little sense to me:

Miracast allows a portable device or computer to send, securely, up to 1080p HD video and 5.1 surround sound. However, it works only over Wi-Fi and cannot be used to stream to a router access point.

Does this simply mean that it doesn't traverse NAT well?

stephenw10

Seems more like a licensing restriction. It was dreamt up by the wifi alliance. ;) Or it could be reliant on some layer 2 technology that is only present in wifi.

Steve

kejianshi

I feel I've missed something. Isn't AP wifi?

The Wi-Fi Alliance defines Wi-Fi as any "wireless local area network (WLAN) products that are based on the Institute of Electrical and Electronics Engineers' (IEEE) 802.11 standards".

So, still confused by their statement. I think they are confused by their statement also.

Assuming their is no isolation going one, and two machines are on the same network, same LAN, same subnet etc and all their ports are essentially open to each other, I don't understand how support or lack of support of any piece of uPNP would effect communication between those two devices? I do understand how it effects the opening of ports on pfsense (or not). Am I missing something?

jporter

This doesn't answer the problem, but 802.11(aka wifi), is a layer 2 network. If the 802.11 Access Point is connected to a pfSense box, its hard to see how UPnP going through the box could be impacted. The wireless access point can have a number of features that could impact functionality, i.e. client isolation, multicast support and rate limiting, QOS settings, etc.

Now if the traffic was somehow going through the pfSense box, (i.e. a bridged network in pfsense), that could be a issue.

If client isolation is not on, (test that you can ping from one wireless device to another), perhaps the AP multicast is not working?
You should be able to do a wireshark capture on a host, (laptop) and a packet capture on pfsense and see multicast traffic between the
devices. Windows systems are particularly chatty when starting up. A packet capture of the chromecast traffic would be helpful in diagnosing the problem, if it is related to pfSense.

stryfe

What if you're using an internal wifi device instead of an AP? Does it seem to work then? I'm debating on swapping to the pfsense and if this is an issue I don't want to invest into everything and not be able to use my chromecast.

jsquyres

I am seeing a very similar situation: I have a pfsense connected to a switch, which, in turn, has an AP hanging off it. Client isolation is disabled.

When going through the Chromecast setup, I can see that it gets a DHCP lease for a short period of time, and I can even nmap it:

Starting Nmap 6.25 ( http://nmap.org ) at 2013-09-03 22:02 EDT
Nmap scan report for chromecast.example.com (192.168.10.112)
Host is up (0.024s latency).
Not shown: 998 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
8008/tcp open  http
MAC Address: D0:E7:82:BC:2B:CF (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 5.19 seconds

I can see that it has a DHCP lease from pfsense; I can even telnet to 192.168.10.112:8080 and elicit basic HTTP responses.

But the Chromecast setup app then says it can't find the Chromecast, and gives up. Eventually, the Chromecast itself gives up (I guess it times out waiting for the Chromecast setup app to contact it) and goes back to flashing its LED and initiating the startup process again.

It very much looks like the Chromecast setup app simply cannot find the Chromecast once the Chromecast joins the wifi and is ready to accept incoming connections.

Is there something special that needs to be done in the pfsense configuration?

jimp

If the communication is between devices in the same subnet, then no, it wouldn't ever hit the firewall.

As others mentioned, it really does sound like AP Client isolation is on, but if your AP claims it is off, you may want to test that another way: Take any two devices on wireless and see if you and ping/reach each other.

I just got a notice that my Chromecast shipped today, should have it on Monday (give or take, if the estimate is right). I have the same sort of setup you have - pfSense at the edge, switch with AP and other things involved. I'll give it a spin and see what I can do.

jsquyres

FWIW, I have done multiple things to prove to myself that wifi client isolation is off:

ping one wifi host from another
ping the broadcast address, see several wifi clients reply
telnet to my chromecast port 8080 from another wifi device (in the brief window where it consumes a DHCP address before it goes back to setup mode)

Let us know what you find when you get yours.

Thanks!

kejianshi

Has it occurred to anyone that Chromecast might be a broken POS that isn't quite ready for the world?

jimp

@kejianshi:

Has it occurred to anyone that Chromecast might be a broken POS that isn't quite ready for the world?

I'm sure it has, though it's still rather new/early. Google has been pushing updates for it "improving" it as they go.

So I wouldn't say "broken POS" but more like "in the early adopter stage of its lifetime".

Po-tay-to, po-tah-to… :-)

kejianshi

Well - So long as they don't start selling ChromcastReady routers and APs that you MUST use for the service to magically work…

doktornotor

@kejianshi:

So long as they don't start selling ChromcastReady routers and switches that you MUST use for the service to magically work…

Not needed. Providing no content outside of U.S. serves this purpose just fine. They even blocked streaming content from Android phones.

jimp

They didn't block it, they updated the API and the streaming apps needed to catch up to the new API.

Still, it's all beyond the scope of this thread - this is just trying to make it work, not debating its merits.

stephenw10

I'll be following this closely. No chance of getting a Chromecast though, yet.
I could believe it's an issue with the AP somehow interfering with broadcast or multicast.
Since most of what the chromecast is meant to do is stream stuff directly, rather than from another wifi device, I could also believe it wants to open firewall holes and be accessible from Google HQ via UPNP.
I could just about believe the setup app. just asks some google server 'is there a chromecast at my address?' and the server looks for it. If UPNP isn't working it won't find one. Seems like asking for a huge number of support calls though. ;)

Steve