My Arch Linux PC that is connected directly to the router through an Ethernet cable doesn't seem to be able to interact with other devices that are connected in the same network but with WiFi, for example, Smart TVs, Smartphones, a Steam Link that I have, and so on.

I know that it's not a router misconfiguration because Windows its able to do so, I just tried with the same PC but with a hard drive that has installed Windows on it.

On Windows, in every Youtube video I have an icon to broadcast the video to Smart TVs in the same network. That icon is not present on Linux.

When trying to scan the network with the Steam Link and Arch Linux running, Steam Link won't find anything, even if I give it the exact local IP of the PC (unlike on Windows, the Steam Link will find it automatically), and the In-Home streaming is enabled in Steam settings of course.

I haven't really tried with many other software's but I think this is pretty much all the evidence I need to believe that there is something wrong with the network configuration.

Although I find it weird because I have been using this Arch Linux system since the beginning of 2017, and it's even set up in the Steam Link, with hostname and all. That means, it worked at some point, maybe it stopped working after an upgrade and I didn't notice?

Hopefully you will be able to help me.

ip a:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 44:8a:5b:9e:da:b2 brd ff:ff:ff:ff:ff:ff
    inet brd scope global dynamic noprefixroute enp4s0
       valid_lft 3001sec preferred_lft 3001sec
    inet6 fe80::72b7:60b3:ab1:1112/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

resolvectl status:

       LLMNR setting: yes
MulticastDNS setting: yes
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 2 (enp4s0)
      Current Scopes: LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
  • It is probably your router security configuration, simply you are not broadcasting, but multicasting, which obeys to other rules. There could also be something else. Add to the question your router brand, model and OS in case you changed it. – Rui F Ribeiro Jul 25 '18 at 19:37
  • What firewall setup do you have in Arch, if any? What does ipconfig/route print show in Windows? Also, do you have Avahi/mDNS enabled? – ErikF Jul 25 '18 at 19:43
  • 1
    @ErikF I do agree that is either lack of avahi or router configuration OR both situations at the same time. – Rui F Ribeiro Jul 25 '18 at 19:48
  • Are the other devices also on 192.168.0.*? – xenoid Jul 25 '18 at 19:52
  • 1
    @RuiFRibeiro @ErikF I fixed Systemd-resolved, now when I take a look with resolvectl status I see that the global configuration has MulticastDNS setting enabled but the Link 2 (enp4s0) has it disabled. – Nicolás Santisteban Jul 26 '18 at 2:18

If a connection problem is firewall-related, which you noted it is, the first thing that I do is check to see if there is documentation available on the company's web site/support forums. Sometimes there isn't any available, but that's pretty rare nowadays. If you can't find any information, many firewalls, including UFW, will log denied traffic (and sometimes the program that generated the traffic), which you can then use to tailor your firewall.

For your Steam client, here are the ports needed:


  • TCP/80 (HTTP) and TCP/443 (HTTPS)
  • UDP/4380 (Steam client)
  • TCP+UDP/27015-27030 (Steam services)
  • UDP/27000-27015 (game client traffic)
  • UDP/27031-27036 (streaming)
  • TCP/27036-27037 (streaming)


  • UDP/3478 (P2P)
  • UDP/4v379 (P2P)
  • UDP/4380 (P2P)

If you still missing ports, check the UFW log to see what other ports/protocols (and in which direction) are being blocked.

Regarding the YouTube "broadcast to TV" feature, you need to make sure that mDNS works (I use Avahi's avahi-daemon for this) and you need the following ports open:

Inbound/outbound (local network only):

  • UDP/1900 (multicast: SSDP)
  • UDP/5353 (multicast: mDNS)
  • TCP/8008-8009


  • UDP/53 (DNS)
  • TCP/80 (HTTP)
  • UDP/123 (SNTP)
  • TCP/443 (HTTPS)
|improve this answer|||||
  • Thanks, but if I switch to Avahi would I need to disable Systemd-resolved and start using Avahi for hostname, DNS, etc? Also the Youtube broadcast feature is now working as intended (without Avahi) but on Google Chrome, it doesn't seem to work to work on Chromium or Firefox, maybe it's missing some feature that comes included with proprietary Google Chrome? – Nicolás Santisteban Jul 26 '18 at 23:37
  • No, Avahi and systemd-resolved work fine together (one's a server, the other's a client that's also a stub server): I have them both running on my machines. As for Chrome/Chromium: yes, Chrome has non-free extensions that do not ship with Chromium. – ErikF Jul 26 '18 at 23:43
  • So is there anyway to obtain such functionality other than using Chrome? Avahi plus Firefox combo? – Nicolás Santisteban Jul 27 '18 at 0:01
  • If the Cast extension isn't working, you may need to enable the Media Router Component Extension. The Arch Wiki is pretty good at noting stuff like this, if general documentation isn't working for some reason. – ErikF Jul 27 '18 at 0:11
  • Yeah I checked the wiki and did that, but it didn't work until I fully restarted my computer for some reason. I had confirmation when you pointed it out too that's when I noticed there was something odd. Weird. – Nicolás Santisteban Jul 27 '18 at 1:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.