New pfSense Install Issues with 1 of 3 Samsing TVs. Cannot establish an internet connection
-
@provels Thanks for the reply. There must be some interaction with this TV an My pfsence config because if worked just before it moved from my old zywall firewall to pfsence. It works if I connect it directly to the cable modem too.
-
@frr “all correct” including gateway, mask, DNS?
Any packages running on pfSense?
-
@frr said in New pfSense Install Issues with 1 of 3 Samsing TVs. Cannot establish an internet connection:
with this TV an My pfsence
Pfsense has no clue that its a tv.. It sees traffic it either allows it or doesn't.. If it doesn't it should be in the logs.
-
@SteveITS No packages installed. It's as plain vanilla config as I think it could be.
-
@johnpoz Thanks I agree. I think the same may be true for the TV. It has no clue that pfsence is routing the traffic to it. (or does it) The things that puzzle me are that the TV works when I plug it directly into the cable modem and on my old firewall. Also each time shortly after I cleared the pfsense ARP table, the TV would work for a few seconds.
There are only two devices and 3 cables between the TV and the cable modem in my normal set up. The pfsene and a switch. Two of the 3 cables are common to all traffic to all devices on my network which are working so those cables are good. The 3rd cable is from the switch to the TV and is the same exact cable that I plugged into the modem during troubleshooting so it works. The tv has been proven to work on my old firewall and when plugged into the modem. That leaves the switch and the firewall. I moved the problem tv cable into a switch port where a working Samsung TV (indicates that the sw port is ok) was plugged into. The problem tv still doesn't work. That seems to indicate that the switch is OK. I'm left with suspecting there is something wrong with the configuration I set on the pfsens system.
The only thing I can think of from a hardware pov, is to unplug everything from the switch except for the problem tv and plug the switch directly into the modem. This would confirm that the switch works but I think I have already done that with the working tv which is a DIFFERENT model Samsung tv.
I'm not sure what troubleshooting to do next. Reccomendations?
-
@frr it gets an IP, gateway, DNS?
Try connecting it directly to pfSense.
If not what DHCP server are you running in pfSense? Kea is in preview.
-
@SteveITS I am using Kea. I believe the set up wizard said the other was deprecated.
When I set the TV to dhcp it gets assigned it's ip, mask, gateway and dns correctly. I have a static reservation in pfsens for it. I also have set this statically in the tv (without removing the static res in pfsens). I also have tried setting the dns on the tv to 8.8.8.8 vs the pfsens ip. All of theses methods have the same symptoms.
That's a great idea to plug the TV directly into pfsens. I will do that later when I return home.
Should I also try a different dhcp service instead of kea?
-
Yes try going back to ISC dhcpd. Hard to imagine what might be missing from Kea for that but easy to test.
If it has local access but can't reach the internet it either has a bad gateway or (more likely) some DNS issue. Because in these situations...it's always DNS!
Perhaps it has some hard coded DNS server it's trying to reach.
-
Well, this smells like an IPv6 DNS problem. Try stopping all IPv6 on LAN1 and see. The ARP table loses the TV because (having a Samsung TV I have myself seen this), when those buggers cannot find internet via ethernet they power down the ethernet port and periodically (~30s) turn it on again to check connectivity.
-
Thanks for everyones help. Still debugging...
FYI: pfsense ver 2.7.2: Problem TV Samsung (UN55KS800D). Working TV Samsung (QN43LS03TAFXZA).
-
I changed the DNS Server to ICP dhcp - same issue. (I did get a warning that ICP dhcp is depreciated.) I did verify that the problem TV does get the correct network settings from ICP dhcp. Set them manually too. Same issue. The network settings are identical to the working TV except for the IP.
-
I swapped ports on the switch with the working Tv and it still works and the problem tv still does not. It's not a switch issue.
-
I plugged the problem TV directly into pfsense LAN port and same issue.
-
The working TV works with both dynamic and static network settings using ICP dhcp.
-
I changed the static IP assignments in pfsense and swapped the IP assignment for the problem tv and the working tv. They were assigned each other's Ip now and the working tv is still working with the other IP and the problem tv is not. So there is likely not some rule blocking the IP address.
-
Unchecked System > Advanced > Networking > IPv6 Options > Allow IPv6
-
Verified there are no IP6. > Services> DHCPv6 Server > Message: "The DHCPv6 Server can only be enabled on interfaces configured with a static IPv6 address. This system has none."
-
Plugged the problem tv directly into the cable modem, restarted the modem and the problem tv works. Fourth time I've verified this.
-
Plugged pfsense back directly into the cable modem, restarted the modem and the working tv is working and problem tv does not work.
-
The error on the tv is generic. "Connected to your local network, but cannot connect to the internet. Check the DNS settings in the IP settings, or ciontact your ISP to access the internet"
-
Power cycled the tv again... no help.
-
Added ARP Table Static Entry Create an ARP Table Static Entry for this MAC & IP Address pair.
-
If I bring up the static IP mapping edit screen; Services > DHCP Server > LAN1 >Static Mapping > Edit for the problem TV's IP and save it without changes, click apply then in several seconds the TV works for about 30 seconds then loses internet connection. This is inconsistently repeatable.
-
Also if I go to Services > DHCP Server > LAN1 > and click save and apply changes, sometimes but not always, in several seconds the tv works for about 30 seconds.
In both cases above, I think when it does not play video the connection is established for too short of a period.
- Thanks for all the suggestions; Now what should I try next?
-
-
@frr most of that seems like waste of time.
But I liked the test of switching the port on the switch with the working tv.. Assume you used the working tvs ethernet cable? And I liked the test swapping the IPs of the working tv with the broken tv.. But you shouldn't have to set a static arp, and while you can set static arp on pfsense so it always knows the mac of the TV.. If the TV is not finding the mac of pfsense your out of luck most likely.
Why don't you just sniff on pfsense and see what its trying to do.. If its asking for dns you would clearly see that.. Unless its attempting to use doh.. But you should still see some https connection that doesn't get an answer.
Is it asking pfsense for dns?
Is it listed in pfsense arp table.. You shouldn't need to set static arp.. And have seen issues of late that setting static arp doesn't actually stay static. Look in your pfsense arp table - do you see the mac..
Why are you allow 443 to anything on your wan? That makes no sense.
The thing does some sort of test to check if its on the internet or not.. Be it a dns query, a ping test.. I it would have no clue that internet is not working unless it was trying something that wasn't working... So the trick is to figure out what that is.. Hard to fix something if you don't actually know what is broken..
Doing a packet capture on pfsense under diagnostic menu for the TVs IP should help you figure out what its trying to do that is not working. You could also verify arps are being seen and answered, etc.
edit: have you tried if via wireless? That would just be a some more info, have not seen a TV these days that doesn't have a wireless interface. Maybe its wired interface is just flaky?
-
Thanks for the response! I agree about the waste of time, a lot of time. Especially since it has not led me to root cause and corrective action.
I disabled the static APR, and deleted the ARP entry and initiated a connection retry on the TV. The tv is again listed in the ARP table with the correct MAC and IP.
Unfortunately, I do not know enough about network traffic to effectively use the capture tools but I'm willing to learn.
I took a stab at capturing some info but I'm not sure if I captured it in the correct way or what the results mean. It seems that there is a "who has" request initiated by the tv, and it is answered what looks to be correct.
Below is the capture parameters and example of the output. The output seems to repeat this pattern. Any guidance on how to best capture the traffic that would be insightful would be appreciated.
19:27:04.046182 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:04.046195 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:04.362583 IP 192.168.1.201.8001 > 224.0.0.7.8001: UDP, length 175
19:27:05.436623 IP 192.168.1.201.57268 > 192.168.1.255.15600: UDP, length 35
19:27:06.070761 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:06.070773 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:06.364107 IP 192.168.1.201.8001 > 224.0.0.7.8001: UDP, length 175
19:27:07.300111 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:07.300125 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:08.103181 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:08.103195 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:08.296685 IP 192.168.1.201.46847 > 192.168.1.1.53: UDP, length 46
19:27:08.330949 IP 192.168.1.1.53 > 192.168.1.201.46847: UDP, length 275
19:27:08.366406 IP 192.168.1.201.8001 > 224.0.0.7.8001: UDP, length 175
19:27:08.437276 IP 192.168.1.201.54760 > 239.255.255.250.15600: UDP, length 35
19:27:08.812595 IP 192.168.1.201.41835 > 192.168.1.1.53: UDP, length 46
19:27:08.812793 IP 192.168.1.1.53 > 192.168.1.201.41835: UDP, length 275
19:27:08.818309 IP 192.168.1.201.38142 > 23.64.114.213.80: tcp 0
19:27:08.832398 IP 23.64.114.213.80 > 192.168.1.201.38142: tcp 0
19:27:08.833196 IP 192.168.1.201.38142 > 23.64.114.213.80: tcp 0
19:27:08.833990 IP 192.168.1.201.38142 > 23.64.114.213.80: tcp 97
19:27:08.852305 IP 23.64.114.213.80 > 192.168.1.201.38142: tcp 0
19:27:08.853412 IP 23.64.114.213.80 > 192.168.1.201.38142: tcp 509
19:27:08.854078 IP 192.168.1.201.38142 > 23.64.114.213.80: tcp 0
19:27:08.860071 IP 192.168.1.201.38142 > 23.64.114.213.80: tcp 0
19:27:08.874994 IP 23.64.114.213.80 > 192.168.1.201.38142: tcp 0
19:27:08.875758 IP 192.168.1.201.38142 > 23.64.114.213.80: tcp 0
19:27:10.130462 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:10.130477 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:10.368617 IP 192.168.1.201.8001 > 224.0.0.7.8001: UDP, length 175
19:27:11.437870 IP 192.168.1.201.48648 > 192.168.1.255.15600: UDP, length 35
19:27:12.166973 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:12.166987 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:12.370378 IP 192.168.1.201.8001 > 224.0.0.7.8001: UDP, length 175
19:27:14.202395 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:14.202408 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:14.372369 IP 192.168.1.201.8001 > 224.0.0.7.8001: UDP, length 175
19:27:14.438575 IP 192.168.1.201.59176 > 239.255.255.250.15600: UDP, length 35
19:27:16.227529 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:16.227543 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:16.374756 IP 192.168.1.201.8001 > 224.0.0.7.8001: UDP, length 175
19:27:17.439229 IP 192.168.1.201.36904 > 192.168.1.255.15600: UDP, length 35
19:27:18.255518 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:18.255537 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:18.376238 IP 192.168.1.201.8001 > 224.0.0.7.8001: UDP, length 175
19:27:20.278344 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:20.278358 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:20.376494 IP 192.168.1.201.8001 > 224.0.0.7.8001: UDP, length 175
19:27:20.439798 IP 192.168.1.201.57930 > 239.255.255.250.15600: UDP, length 35
19:27:21.878861 IP 3.19.205.174.443 > 192.168.1.201.33165: tcp 31
19:27:21.878877 IP 3.19.205.174.443 > 192.168.1.201.33165: tcp 0
19:27:21.879513 IP 192.168.1.201.33165 > 3.19.205.174.443: tcp 0
19:27:21.918091 IP 192.168.1.201.33165 > 3.19.205.174.443: tcp 0
19:27:22.306929 ARP, Request who-has 192.168.1.1 tell 192.168.1.201, length 46
19:27:22.306943 ARP, Reply 192.168.1.1 is-at bc:24:11:bd:e9:ac, length 28
19:27:22.379299 IP 192.168.1.201.8001 > 224.0.0.7.8001: UDP, length 175 -
Hmm, that seems to imply the TV is not receiving the ARP replies.
Except that it does then send DNS requests to 192.168.1.1 so it much have an ARP value for it at that point.
I would either download that pcap and open it in Wireshark or just set the View Options to full on the pcap page and check the MAC addresses on those DNS requests are correct.
-
@frr yeah doesn't make any sense that it would arp for 192.168.1.1 that much and clearly 192.168.1.1 is sending an answer.
But then how would it send this?
19:27:21.879513 IP 192.168.1.201.33165 > 3.19.205.174.443: tcp 0 19:27:21.918091 IP 192.168.1.201.33165 > 3.19.205.174.443: tcp 0If it didn't have the mac of 1.1 to send it too? I would yeah download that pcap and see what mac that was sent too. I would have to assume its pfsense mac - or pfsense shouldn't of not ever seen that traffic.
edit; so that is what like 18 seconds worth and we have 12 arps for 1.1 from 1.201? There for sure something not right with that - but every arp does get a response
-
Something else sending responses too? I expect to see pfSense complaining loudly if something else was using 192.168.1.1 but maybe if it somehow wasn't seeing them....
-
@stephenw10 in that short snip not seeing any different macs for 1.1
I did a quick gui and found this
https://eu.community.samsung.com/t5/tv/arp-spamming-from-samsung-tvs/td-p/1276766
Curious do you have wifi enabled as well on the TV?
But seems lots of arps from samsung is not a new thing.. Do your other TVs send that much arp?
-
FYI I am traveling and will log some additional traffic on the other tv's when I return tomorrow. Thanks so much for all the debugging help.
-
OK, this is even more interesting to me to find the root cause.
Thanks for all your help so far. Just need a little more which will help me learn more about network communications.
Remember that;
(ptv wifi not enabled)
-
When the problem TV (ptv) was connected via a cable directly to the modem, it worked, and this was repeated many times, including modem reboots. Worked = ptv reported an internet connection, hulu streaming and Samsung TV Plus (stvp) worked.
ptv > Modem -
When the ptv was wired directly to the pf's LAN port, it did not work. No internet connection at all.
ptv > pf > Modem -
When the ptv was to my switch connected to pf, it did not work.
ptv > SW > pf > Modem -
When I would re-save the static IP reservation in pf, even though no changes had been made to it, the ptv would stream sptv for a few seconds. This was inconsistent. I think it would only shoe video if the connection was long enough to fill the buffer.
ptv > SW > pf > Modem -
The second two points were true when;
There was a static reservation and the ptv was set to dynamic.
The ptv network settings were set to static
When the ptv IP was swapped with the working tv.
And in all cases the Gateway = pf IP, DNS was set to either pfs, 8,8.8.8, 75.75.75.75(comcast dns) or 1.1.1.1.
Ok now the new, news....
-
I set the ptv to wireless and it was able to establish an internet connection and sustain it. IP Network settings = Dynamic. Gateway = pf IP, DNS = pf IP
ptv > AP > SW > pf > Modem -
Hulu worked, however Samsung TV Plus would not. Tried this several times.
-
I changed the ptv DNS setting to 8.8.8.8 The ptf now worked completely including, Samsung TV Plus!
ptv > AP > SW > pf > Modem
Ok, now to the more interesting part for me ...
-
I changed the ptv back to wired and kept the network tv setting static on the ptv and it still works
ptv > SW > pf > Modem -
I changed the ptv back to Dynamic settings which set the DNS back to the pf IP and it is still working
-
The ptv settings are back to where I initially started, and it has survived tv ov/off cycles
-
If I set the ptv network settings to static with the settings same as dynamic (Same IP, Gateway & DNS = pf IP), it still works.
-
I unplugged the ptv network cable and the ptv lost connection as expected. When I plugged the cable back in, it came quickly back to life.
-
Pulled the ptv power cord and waited a minute and plugged back in and the ptv came quickly back again.
So, I am at point where I cannot reproduce the problem and can't identify root cause and a permanent corrective action. Even though the ptv is now just tv, not knowing what caused this issue and what the corrective action should be, is not a space that I like.
Below is the capture of the ptv starting with it off and when I turned it on and its working. It looks quite different that the capture in my earlier post when it could not establish a internet connection.
It seems that the ptv needed to establish an internet connection wirelessly before wired worked but wired did work worked when plugged directly into the modem. No updated to the TV were done as far as I know. Automatic updates are disabled and the reported firmware ver didn't change.
Questions;
-
What could cause this behavior?
-
What can I do to make sure this issue does not return, especially when I'm gone and there are many very unhappy people watching a nearly blank screen that says no internet connection?
-
How best to learn more about network traffic, packets, etc. I know this is probably like asking you guys, how to be a brain surgeon, but I would like to be in a better spot then I am now.
Thanks
Frank -
-
Hers the packet capture file...packetcapture-tv working wired dyanic IP DNS pfsense.pcap
Not sure if I captured enough. Seem that there is a 2k file size upload limit.
PS: My old firewall (Zywall UGS) did not have this issue.
-
Did you have a DHCP static mapping in place for the wifi MAC address when you switched to wifi?
Do (or did) you have 'ARP Table Static Entry' set on the static mapping for the Ethernet MAC?
This feels like once it was able to connect it may have updated and corrected whatever issue it was hitting. I could believe a bad clock in the TV might cause the continuous ARP requests for example.
