Smart TV cannot connect to internet via ethernet

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

dimaj

I just deleted my static lease for wired connection, but the problem still remains...

I can try experimenting later with another small managed switch and force TV to go on another VLAN and see what happens there.

Thank you very much for your help with this! I really appreciate it.

stephenw10

So the wired traffic from the TV comes into the same interface? Same subnet?

Looking at the IPs I guess that must be true.

If the the wifi interface in the TV does not actually disconnect that would present a routing conflict that could produce exactly what you are seeing here.

When it was connected via the Mikrotik were those interfaces also on the same subnet?

I would try turning off the wifi entirely as a test.

Steve

dimaj

correct. both wired and wireless come into the same interface. same subnet. MikroTik was configured exactly the same.

The reason for the new WIFI interface name now is because I saw in some video or blog post that separating wireless traffic from wired traffic could make it easier to quickly identify what device is connected to. So, I started doing prep work in pfSense to implement that. As this week will come to an end, I'll reconfigure my switch to map to LAN and wireless to WIFI interfaces. The LAN group has been created to group firewall rules together and allow lan-wifi communication.

Just did network reset on the TV and, unfortunately, problem persists (without static mapping).