Smart TV cannot connect to internet via ethernet

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).

stephenw10

Maybe check the AP. Make sure the TV is no longer associated with it when it's set to Ethernet.

Steve

biggsy

Interesting thread. I was just trying to fix a similar issue with a Samsung "smart" TV. It just keeps ARPing the gateway, despite the fact that it gets a response. Maybe the response is just too quick for it. It reports connected to LAN but no Internet access.

Anyway, all my web searching leads me to believe that the network stacks in these things are crap.

@dimaj said:

prefer to keep all my device on ethernet

100% agree. Wired when you can, wireless when you can't.

I did find this suggestion for "disabling" the WiFi (a factory reset apparently won't clear the network config) but haven't had chance to try it:

I was able to turn off my Samsung Smart TV's WiFi by using the TV's Wifi configuration.
Depending on your model and menu functions look for network setup.
Click on set up network or search for new network.
After it searches for available wireless networks chose "ADD NETWORK" then enter a bogus name – a name that did not appear in the selection list.
Then choose "OPEN" for security type. The TV will search for that network you named and won’t be able to connect to it. It will however keep the settings. Once the configuration is finished it will display network address as 0.0.0.0 for all fields.
Turn the TV off. The next time you turn the tv on it will briefly search for the network and when it doesn't find it the wifi shuts off by default.

dimaj

@biggsy, thank you for the suggestion! Just went through that and, sadly, same results.

@stephenw10 , Just checked in my UniFi controller. Device is no longer associated.

biggsy

@dimaj

Thanks for trying. Maybe saves me some time on my friend's problem.

dimaj

@biggsy, you bet! But, I still think you should go through the same steps with your friend's TV as well... sadly (or luckily), even if this didn't work for me, doesn't mean that it'll work for you :)