New pfSense Install Issues with 1 of 3 Samsing TVs. Cannot establish an internet connection
-
Changed wires and switch ports? Not config if everything else works.
-
What error is shown on the TV? Is it maybe pulling an IPv6 address and trying to use that?
-
@stephenw10 thanks for the reply.
The TV only says it has a local network connection and no internet access. It reports all the correct IP4 configuration if i set it to dhcp.
Actually I don't think it's IP6 capable. There are not settings beyond the typical IP4 settings. -
@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.
