Smart TV cannot connect to internet via ethernet

dimaj

Hello All!

I was hoping you guys could help me out with a weird problem I am having with my Samsung Smart TV...

A few weeks ago, I switched over from MikroTik to pfSense. So far the experience has been great! One problem that I have though is that my tv won't connect to internet over ethernet.

My setup is as follows:

Hardware:
- Protectli 4 port firewall appliance
- UniFi UAP Pro
- Netgear managed switch
Configuration:
- Interfaces: WAN, LAN
- VLANS: WIFI, IOT
- Interface Groups: HomeLAN (LAN, WIFI)

When my TV connects to any of the wireless networks (one is mapped to IOT VLAN and another to the WIFI), everything works just fine. Firewall logs show a few requests being made to the broadcast address at some obscure port followed by a request to DNS server and then to some external IPs.

When I connect my TV using ethernet cable (which maps to the WIFI VLAN), I see DHCP entries in the log saying that IP is being issued. Firewall logs show the same requests to the broadcast address at the same obscure port and that's it.

I found a post on Lawrence Systems forum, but the problem there was old installation of UniFi, which does not apply to my case here.

To make troubleshooting easier, I've created 2 firewall rules - one per interface:
Allow all requests from TVs IP to any destination and log each request.

Thanks in advance for your help.

dimaj

Here are some more details of my setup:

I am running pfBlockerNg (devel, which is configured for all interfaces. Here are some images of my rules:
Floating

Debug Rule (same for both HomeNetwork and IOT)

stephenw10

Is it possible the WIFI is still enabled in the TV and connected to the same subnet creating a conflict? Both interfaces share the same MAC address? (unlikely).

Steve

SteveITS

@dimaj This probably isn't your issue but since you mentioned DNS rules I found that the Dish (satellite) hardware requires DNS over HTTPS for its On Demand functionality, even though all other functions work.

If it didn't work on either I'd ask if it was an old TV that was affected by the root cert expirations but that doesn't sound like your case if it works on Wi-Fi.

dimaj

@stephenw10 , Thank you for the reply!

No. It is not connected over wireless as there is a binary switch in the TV that would switch from Ethernet to Wireless. On top of that, I did a full networking reset in the TV and same results have been observed.

Both interfaces do not share the same MAC:

LAN: fc:03:9f:XX:YY:ZZ
Wireless: 70:2a:d5:XX:YY:ZZ

dimaj

This post is deleted!

dimaj

@steveits Thank you for your reply!

The TV is new-ish... it's couple of years old.

What is the order of firewall rule execution? Floating then interface-specific? The 2 debug rule I posted (specific to each interface) are the first rules in those lists.

The DNS_Ports in the floating rules are: 53 and 853.
I've also tried disabling pfBlockerNg and TV still could not get connected.

More pieces to the "puzzle". I haven't had these problems when I was on MikroTik. The only things that changed in my setup during the conversion (MikroTik -> pfSense) were:

Router and Access Point swap
Remapping of Firewall Rules
IP address swap. I went from 192.168.1.0/24 -> 10.50.10.0/24

I also thought that cable was at fault. So, I tested it and it's intact and in perfect condition.

stephenw10

Does the TV respond to ping on wifi and/or Ethernet?

Do you see it in the ARP table when it's failing? I would expect to since DHCP is working.

Steve

dimaj

@stephenw10

I can ping it over wifi, but not wired and device is present in the ARP table.

also, the "obscure broadcast port", if it makes a difference is 15600

stephenw10

Hmm, just to confirm this was working via Ethernet behind the Mikrotik? Was is pingable there?

What traffic are you actually seeing coming from it over Ethernet?

Steve

dimaj

Yes, when I was running MikroTik, TV was plugged in over ethernet (I really don't like wifi and prefer to keep all my device on ethernet) and it was working.
TV was ping-able, but I cannot confirm what type of traffic was happening there as I've wiped that MikroTik router's configuration.

TV does have a connectivity self-test. So, when I select Wired/Wireless mode (and in case of wireless, connect to a network), it does try to reach out somewhere to determine if it's online or not.

In my case right now, the image on the TV shows connectivity to the router, but a broken link between router and internet.

stephenw10

What traffic are you seeing over Ethernet now though? If you run a pcap for the TV's IP address what is it sending?

dimaj

The Packets Captured window shows:

12:23:07.112290 IP 10.50.10.1.67 > 10.50.10.8.68: UDP, length 300
12:23:07.160324 IP 10.50.10.1.67 > 10.50.10.8.68: UDP, length 300
12:23:07.286849 IP 10.50.10.8.48502 > 10.50.10.255.15600: UDP, length 284
12:23:07.286915 IP 10.50.10.8.42196 > 10.50.10.255.15600: UDP, length 38
12:23:07.364007 IP 10.50.10.8.46169 > 10.50.10.255.15600: UDP, length 287
12:23:07.530654 IP 10.50.10.1.67 > 10.50.10.8.68: UDP, length 300
12:23:09.073394 IP 10.50.10.8.44969 > 10.50.10.255.15600: UDP, length 35
12:23:15.074015 IP 10.50.10.8.55880 > 10.50.10.255.15600: UDP, length 35
12:23:21.076244 IP 10.50.10.8.33853 > 10.50.10.255.15600: UDP, length 35
12:23:27.076868 IP 10.50.10.8.49197 > 10.50.10.255.15600: UDP, length 35
12:23:33.077534 IP 10.50.10.8.36000 > 10.50.10.255.15600: UDP, length 35
12:23:39.078352 IP 10.50.10.8.59430 > 10.50.10.255.15600: UDP, length 35
12:23:45.078887 IP 10.50.10.8.54187 > 10.50.10.255.15600: UDP, length 35
12:23:51.079439 IP 10.50.10.8.39995 > 10.50.10.255.15600: UDP, length 35

This is from WireShark:
Screen Shot 2021-11-22 at 12.28.28 PM.png

stephenw10

Hmm, some asymmetry there? Where are you pcapping that?

I assume other devices using that same dhcp server work just fine?

It's hard to see what pfSense could be doing here to cause a problem.

Try running a longer pcap and doing the connectivity test on the TV. What is it sending to test?

Steve

dimaj

I was running pcap from the pfSense. Screen Shot 2021-11-22 at 1.49.30 PM.png

I performed the following:

Launched pcap using config above
Turned TV on
Ran connectivity test
Waited for connectivity test to conclude
Turned TV off
Stopped pcapping.

This is the output with full level of detail:

14:09:08.634358 00:e0:67:27:80:91 > fc:03:9f:7f:80:38, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    10.50.10.1.67 > 10.50.10.8.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x15504033, Flags [none] (0x0000)
	  Your-IP 10.50.10.8
	  Client-Ethernet-Address fc:03:9f:7f:80:38
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Offer
	    Server-ID Option 54, length 4: 10.50.10.1
	    Lease-Time Option 51, length 4: 7200
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Default-Gateway Option 3, length 4: 10.50.10.1
	    Domain-Name-Server Option 6, length 4: 10.50.10.1
	    Hostname Option 12, length 13: "lr-samsung-tv"
14:09:08.706265 00:e0:67:27:80:91 > fc:03:9f:7f:80:38, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    10.50.10.1.67 > 10.50.10.8.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x15504033, Flags [none] (0x0000)
	  Your-IP 10.50.10.8
	  Client-Ethernet-Address fc:03:9f:7f:80:38
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Server-ID Option 54, length 4: 10.50.10.1
	    Lease-Time Option 51, length 4: 7200
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Default-Gateway Option 3, length 4: 10.50.10.1
	    Domain-Name-Server Option 6, length 4: 10.50.10.1
	    Hostname Option 12, length 13: "lr-samsung-tv"
14:09:08.782392 fc:03:9f:7f:80:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 326: (tos 0x0, ttl 64, id 32485, offset 0, flags [DF], proto UDP (17), length 312)
    10.50.10.8.37547 > 10.50.10.255.15600: [udp sum ok] UDP, length 284
14:09:08.782488 fc:03:9f:7f:80:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 64, id 32486, offset 0, flags [DF], proto UDP (17), length 66)
    10.50.10.8.55743 > 10.50.10.255.15600: [udp sum ok] UDP, length 38
14:09:08.903009 fc:03:9f:7f:80:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0x0, ttl 64, id 32505, offset 0, flags [DF], proto UDP (17), length 315)
    10.50.10.8.38333 > 10.50.10.255.15600: [udp sum ok] UDP, length 287
14:09:09.018391 00:e0:67:27:80:91 > fc:03:9f:7f:80:38, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    10.50.10.1.67 > 10.50.10.8.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x4289d941, Flags [none] (0x0000)
	  Your-IP 10.50.10.8
	  Client-Ethernet-Address fc:03:9f:7f:80:38
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: ACK
	    Server-ID Option 54, length 4: 10.50.10.1
	    Lease-Time Option 51, length 4: 7200
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Default-Gateway Option 3, length 4: 10.50.10.1
	    Domain-Name-Server Option 6, length 4: 10.50.10.1
	    Hostname Option 12, length 13: "lr-samsung-tv"
14:09:11.388049 fc:03:9f:7f:80:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 32701, offset 0, flags [DF], proto UDP (17), length 63)
    10.50.10.8.41613 > 10.50.10.255.15600: [udp sum ok] UDP, length 35
14:09:17.388675 fc:03:9f:7f:80:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 33156, offset 0, flags [DF], proto UDP (17), length 63)
    10.50.10.8.57948 > 10.50.10.255.15600: [udp sum ok] UDP, length 35
14:09:23.393377 fc:03:9f:7f:80:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 33839, offset 0, flags [DF], proto UDP (17), length 63)
    10.50.10.8.35109 > 10.50.10.255.15600: [udp sum ok] UDP, length 35
14:09:29.394049 fc:03:9f:7f:80:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 34614, offset 0, flags [DF], proto UDP (17), length 63)
    10.50.10.8.38088 > 10.50.10.255.15600: [udp sum ok] UDP, length 35
14:09:35.395360 fc:03:9f:7f:80:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 35756, offset 0, flags [DF], proto UDP (17), length 63)
    10.50.10.8.37533 > 10.50.10.255.15600: [udp sum ok] UDP, length 35
14:09:41.395992 fc:03:9f:7f:80:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 36519, offset 0, flags [DF], proto UDP (17), length 63)
    10.50.10.8.34467 > 10.50.10.255.15600: [udp sum ok] UDP, length 35
14:09:47.397865 fc:03:9f:7f:80:38 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 37647, offset 0, flags [DF], proto UDP (17), length 63)
    10.50.10.8.41504 > 10.50.10.255.15600: [udp sum ok] UDP, length 35

Correct, all other hard-wired devices have no issues

stephenw10

Hmm, but it's working on the WIFI interface? And the test returned successful? Yet nothing was captured?

Or is that screenshot wrong and it should show the LAN interface?

Try pcaping on WIFI where it does work and see what it should be sending for the test.

Steve

dimaj

That pcap was from TV connected via ethernet cable.

My current configuration is such that hard-wired devices receive VLAN ID 10 (from a managed switch). My wireless devices receive the same id from UniFi AP.

Here's capture of when I'm connected wirelessly: https://pastebin.com/9iGnMmAP

stephenw10

Your screenshot above shows the pcap on the "WIFI" interface. It that correct? That's confusing me if so.

dimaj

yes, as of now it is correct.

WIFI = VLAN ID 10.

Over the coming weekend I'll be reconfiguring my switch to have all wired devices to be on the actual LAN interface (as they should've been).

Interfaces / Interface Assignments
Screen Shot 2021-11-22 at 3.01.25 PM.png

Screen Shot 2021-11-22 at 3.02.02 PM.png

stephenw10

Ok so that pcap shows a whole bunch of traffic to different places and on the Ethernet it's not even trying.

About the only thing I could imagine pfSense doing here that could cause it would be a static DHCP lease for the TV Ethernet MAC that was somehow sending it bad values. But the full pcap doesn't show anything wrong with what it's sending.

Steve