Cannot stream media to internet enabled tv
-
For the TV to see the server you can not have any firewall/NAT/routing in place between the client and the server.
How is The TP-router connected to PFSense. TP-link WAN-port or LAN-port?
That may be a problem then, since I have a firewall rule that forces all LAN traffic through an OpenVPN connection (it's set that way because of a tutorial I found on here on how to set up OpenVPN with an exisiting VPN provider). The set up goes like this: One cable runs from my Linksys CM100 Cable Modem to the onboard NVidia NForce430 adapter (WAN), then I run a cable from the pfSense box to the #1 port on the LAN switch (no WAN on the TP-Link), then I run a cable from LAN switch port #2 to my desktop (Fedora 17 on a Realtek RTL8168 chipset), and the wireless is handled by the TP-Link as just an access point, but all routing and DHCP duties are done by pfSense.
-
so DLNA uses UPnP and SSDP correct - part of this is multicast is it not? You sure your not blocking multicast at the switch level with say IGMP snooping?
Pretty sure they discover each other via traffic port 1900 and 239.255.255.250 (multicast address)
This could cause some issues over wireless could it not? I would do a sniff at the devices to see, do you see this multicast traffic on your linux box from your TV? From a different wireless client do you see the SSDP going out from your linux box?
Would explain why they can not find each other.
So for example here is packet from one of my directv dvrs, seeing this on my desktop. But all wired and turned off igmp on my switch, normally its on and don't see this traffic
I wold fire up capture on your linux box - are you seeing this kind of traffic from your TV? Is your server sending this kind of traffic out - is it being seen on the wireless network?
-
If these two devices, your Fedora server and the TV, are in the same subnet and you only have one LAN interface in your pfSense box then traffic between them is not going via pfSense at all. Whatever rules or proxies you have setup in pfSense cannot affect that traffic.
As Johnpoz said you usually need multicast traffic for the server discovery to work correctly. Look for this being blocked at your access point somehow.Steve
-
so DLNA uses UPnP and SSDP correct - part of this is multicast is it not? You sure your not blocking multicast at the switch level with say IGMP snooping?
Pretty sure they discover each other via traffic port 1900 and 239.255.255.250 (multicast address)
This could cause some issues over wireless could it not? I would do a sniff at the devices to see, do you see this multicast traffic on your linux box from your TV? From a different wireless client do you see the SSDP going out from your linux box?
Would explain why they can not find each other.
So for example here is packet from one of my directv dvrs, seeing this on my desktop. But all wired and turned off igmp on my switch, normally its on and don't see this traffic
I wold fire up capture on your linux box - are you seeing this kind of traffic from your TV? Is your server sending this kind of traffic out - is it being seen on the wireless network?
I ran a Wireshark capture from Fedora, and I got the SSDP packet like your screenshot above shows (I've attached my own screenshot). I can't get access to either of the wireless machines until tomorrow though, so if I need to get access to wi-fi for further testing, it'll have to wait. I also saw a lot of broadcast packets from the TV itself saying "Who has 192.168.0.1? Tell 192.168.0.106". Anything having to do with the TP-Link's firewall is disabled. I've attached a screenshot of that as well. The funny thing is when I was just using the TP-Link router (no pfSense), the DLNA server worked just fine, the TV was discovered, and I could stream all day with no issues. The TP-Link also had UPnP enabled as well. I also just noticed that when I restarted the DLNA server, I saw a few packets fly by that said "192.168.0.101 192.168.0.106 Destination Unreachable (Host administratively prohibited).
-
Here is the thing - pfsense has NOTHING to do with what your doing. Packets are not going to pfsense, pfsense would not even be aware of the traffic.. If your doing a sniff on pfsense, it would see the broadcast packets sure - but directed traffic between a wireless client and a lan client would not be seen by pfsense.
Unplug pfsense from your switch - does it work now? You don't need to get on the internet for this to work, do you? If not then pfsense does not need to even be on or connected for what your doing to work.
Just unplug pfsense from the lan port on your tplink. Does it start working now??
-
Here is the thing - pfsense has NOTHING to do with what your doing. Packets are not going to pfsense, pfsense would not even be aware of the traffic.. If your doing a sniff on pfsense, it would see the broadcast packets sure - but directed traffic between a wireless client and a lan client would not be seen by pfsense.
Unplug pfsense from your switch - does it work now? You don't need to get on the internet for this to work, do you? If not then pfsense does not need to even be on or connected for what your doing to work.
Just unplug pfsense from the lan port on your tplink. Does it start working now??
Without pfSense, with a static IP set through the TP-Link, the server just blatantly refuses to start. I've tried deleting and recreating the folder, I've tried rebooting, nothing. So I'm not sure what to think now…
-
Do you have more than one TP-link device? Because….
@randythecomputerman:no WAN on the TP-Link
and yet…
The funny thing is when I was just using the TP-Link router (no pfSense), the DLNA server worked just fine, the TV was discovered, and I could stream all day with no issues.
I've never seen a soho router that didn't have a WAN port. Typo?
You are going to have to test that multicast messages are making it across the wifi bridge. Also check that the pfSense box is handing out the correct subnet mask.
Steve
-
"with a static IP set through the TP-Link"
What? So the way I am picturing your setup
internet – pfsense (lan) --- (lan)tp-link(lan)-- linuxserver
Then wireless your TV and other clients connect to your tp-link which is being used as switch and wireless AP.
So your pfsense is on 192.168.0.1 on its LAN, your choice of default gateway a bit confusing there - lan interfaces would not have a gateway set. So I take it this is the IP of your lan inteface on your wan.. Other devices on your network use this .0.1 address as the default gateway to get to the internet.
So your TV is at 192.16.0.106 and wireless, and this is how? Static? With gateway of .0.1
Now your linux box is set how? dhcp or static? And its address is 192.168.0.? with a gateway of .0.1
And meaningless info is your tp-link IP for management of wireless is .0.2, but its dhcp server is OFF!!
Now I would assume your dns points to your pfsense .0.1 address?
What server is not starting your linux box? When the pfsense is unplugged? That makes little sense, why would it not start just because its gateway is not available - does it need the internet for something to start, dns maybe?
Notice in your sniff - that multicast is sent to mac of 01: which is correct its a multicast, so mac would first have to end in 1 to say hey I am multicast. I would really check to see if your wireless clients are seeing this traffic sent to this sort of address?
I am going verify with a wireless laptop when I get home, I run the same sort of setup - but old linksys router running tomato as my AP. But don't do anything with multicast on my network, and normally have igmp snooping enabled on my core switch to block the traffic - because on my network its just noise that I don't need to see.
But if devices are assigned statically - I don't see why they wouldn't work just because your gateway is not there. What do these services do that they need to get off the network for? If they hang because not talking to dns, have seen this before - then just bring up a dns server on your local network and point to that for the testing.. Your using local domain?? For example I use local.lan for all my devices dns. Serve that up off say your linux box if dns is needed for stuff to start.
-
"with a static IP set through the TP-Link"
What? So the way I am picturing your setup
internet – pfsense (lan) --- (lan)tp-link(lan)-- linuxserver
Then wireless your TV and other clients connect to your tp-link which is being used as switch and wireless AP.
So your pfsense is on 192.168.0.1 on its LAN, your choice of default gateway a bit confusing there - lan interfaces would not have a gateway set. So I take it this is the IP of your lan inteface on your wan.. Other devices on your network use this .0.1 address as the default gateway to get to the internet.
So your TV is at 192.16.0.106 and wireless, and this is how? Static? With gateway of .0.1
Now your linux box is set how? dhcp or static? And its address is 192.168.0.? with a gateway of .0.1
And meaningless info is your tp-link IP for management of wireless is .0.2, but its dhcp server is OFF!!
Now I would assume your dns points to your pfsense .0.1 address?
What server is not starting your linux box? When the pfsense is unplugged? That makes little sense, why would it not start just because its gateway is not available - does it need the internet for something to start, dns maybe?
Notice in your sniff - that multicast is sent to mac of 01: which is correct its a multicast, so mac would first have to end in 1 to say hey I am multicast. I would really check to see if your wireless clients are seeing this traffic sent to this sort of address?
I am going verify with a wireless laptop when I get home, I run the same sort of setup - but old linksys router running tomato as my AP. But don't do anything with multicast on my network, and normally have igmp snooping enabled on my core switch to block the traffic - because on my network its just noise that I don't need to see.
But if devices are assigned statically - I don't see why they wouldn't work just because your gateway is not there. What do these services do that they need to get off the network for? If they hang because not talking to dns, have seen this before - then just bring up a dns server on your local network and point to that for the testing.. Your using local domain?? For example I use local.lan for all my devices dns. Serve that up off say your linux box if dns is needed for stuff to start.
No, I would only use the static IP if something were to happen to my pfSense box, and I needed to set it back up to be a router again, instead of a Wireless AP and switch. (I don't trust the onboard networking on the pfSense box that far). The setup goes like this:
Linksys CM100 (Cable) –-> Nvidia nForce 430 Onboard LAN Adapter (WAN in this setup) ---> Rosewill RC100 PCI LAN Adapter (LAN in this setup) ---> Port #1 on the TP-LINK WR841ND (that used to function as a Wireless Router, now functions as both a Wireless AP and switch) and then my computer (Fedora 17 desktop) connects to port #2 on the TP-LINK WR841ND.
Right, pfSense's default gateway is 192.168.0.1, and if I pull up ifconfig on Fedora, it shows a default gateway of 192.168.0.1, and I set the TP-LINK as 192.168.0.2 (as per the "Using pfSense with an existing router" how-to).
All devices on the network (my computer (currently 192.168.0.100), 2 wireless desktops (currently 192.168.0.103 and 192.168.0.104 respectively), a Samsung Galaxy Tab 7 (currently 192.168.0.105) and the TV (currently 192.168.0.106) are all set up through DHCP.
Exactly, default DNS shows as 192.168.0.1 in ifconfig and in the Windows IP Configuration.
PS3 Media Server (the one I've used for streaming since I got the TV last year) refused to start at all. No errors or anything. Just sat there and did nothing. When I reconnected pfSense after trying to test just the TV and my computer on the TP-LINK (set up at that point through static addresses because the DHCP server is disabled over there as per the "Using pfSense with an existing router" how-to", I reset the connection to use DHCP, and it started again. It was weird.
-
Alright, so I feel kind of stupid and bad that I wasted everyone's time with this…it turns out that pfSense was not at fault for this, it was my Fedora box. iptables was blocking the port used for streaming, and once I opened up that port for usage, it works fine. So I'm sorry for wasting everyone's time there. Also, I did some more testing with the pinging of the wireless clients from the AP (since it has built in Diagnostics like Ping and Traceroute), and the AP cannot ping the wireless clients either. So I fixed the streaming problem, but if anyone has any more ideas about the pinging, I'm open to them. If nothing else, I may have to contact TP-LINK's technical support.
-
Well if your pfsense is dhcp, and you disconnect it then no nothing is going to work.
I can download ps3 media server and test it using my network and since I am setup same as use, old wireless router being used as AP we can do some testing.
Setup your box as STATIC on that 192.168.0.0/24 network and don't even put a gateway. Same for your other devices - I don't believe that internet is required to do what you want. So pfsense is not even required.
Your connecting to a wireless switch - gateway off your network has what to do with your UPnP streaming to work?? So pfsense does not even come into play with your boxes sending out multicast to find each other - NOTHING!!
So how is it that you think pfsense is your problem? What I want you do to is prove that to yourself by disconnecting it from your network. Your devices are on the same switch - with wireless being bridged to the switch. Pfsense has NOTHING to do with connectivity between these devices - NOTHING!
Only if dns or internet would come into play for your service to run would pfsense come into play.
-
Well if your pfsense is dhcp, and you disconnect it then no nothing is going to work.
I can download ps3 media server and test it using my network and since I am setup same as use, old wireless router being used as AP we can do some testing.
Setup your box as STATIC on that 192.168.0.0/24 network and don't even put a gateway. Same for your other devices - I don't believe that internet is required to do what you want. So pfsense is not even required.
Your connecting to a wireless switch - gateway off your network has what to do with your UPnP streaming to work?? So pfsense does not even come into play with your boxes sending out multicast to find each other - NOTHING!!
So how is it that you think pfsense is your problem? What I want you do to is prove that to yourself by disconnecting it from your network. Your devices are on the same switch - with wireless being bridged to the switch. Pfsense has NOTHING to do with connectivity between these devices - NOTHING!
Only if dns or internet would come into play for your service to run would pfsense come into play.
I actually got it fixed. It turns out that iptables in Fedora was blocking port 5001, which PS3 Media Server uses to stream from. After opening up the ports, I'm streaming now :D. I still can't ping the wireless clients using the access point's diagnostics, but I'll probably have to contact TP-Link about that. So for now, the main problem is fixed :D
-
so can you ping the wireless clients from your other boxes - forget the tp-link diag, I assume that is meant for troubleshooting internet connections and uses the wan interface that your not using.
-
so can you ping the wireless clients from your other boxes - forget the tp-link diag, I assume that is meant for troubleshooting internet connections and uses the wan interface that your not using.
Alright, I just tried pinging from one of the two wireless desktops, and it went as follows:
This wireless desktop has an IP of 192.168.0.103, assigned by DHCP.
I tried pinging the other wireless desktop at 192.168.0.104 (assigned by DHCP), and all four attempts timed out. I tried it again, and it timed out once again.
I then tried pinging my wired desktop at 192.168.0.100 (assigned by DHCP). I did this twice, and it did not time out.
I then tried pinging the TV at 192.168.0.106 (assigned by DHCP). I did this twice, and it did not time out.
Going on the success of me reaching my wired machine from the wireless desktop, I tried pinging the wireless desktop I used previously at 192.168.0.103, and had 8 attempts, and 8 timeouts.
I also tried pinging the wireless desktop used previously from pfSense's command line, and it timed out as well.I went into the Windows IP Configuration to check for any errors, and everything looks good.
-
Do you have a setting for wireless client isolation in you access point?
Steve
-
So pinging to wireless clients from wired should work, but make sure your resolving the mac. After you trying pinging a wireless client from a wired client. Check the mac for that IP in your arp table
arp -a from a cmd prompt on the box your pinging from.
As stated quite often with wireless to wireless you could have Isolation setup so wireless clients can not talk to each other. And depending on the wireless router, and if using say a guest wireless network. You could be preventing wireless from talking to wired.
First thing I would do when attempting ping is verify MAC is resolved. And that mac is correct, if correct and still not working - verify host firewall allows icmp/ping – this is common for that to be blocked on say windows default firewall settings. If firewall is ok, and mac is ok - I would sniff on both pinger and pingee and verify your seeing the traffic go out the wire, and that the pingee is seeing the traffic.
This really is just basic network troubleshooting 101.
