Once the network interface is properly configured, you can begin to probe for the presence of the Fuchsia target device.
Note: The Fuchsia emulator (both AEMU and QEMU) uses different discovery mechanisms, which are out of scope in this documentation.
The examples on this page use avahi to inspect mDNS records. The avahi toolchain communicates with a local daemon, which may or may not be running. If the daemon is not running, avahi commands will generally fail with a message saying Daemon not running.
When needed, you can start a daemon as a foreground process. In a terminal, run the following command:
sudo avahi-daemon
The daemon will cache mDNS queries as they are encountered, and it can be safely killed when finished.
Device discovery uses multicast DNS (mDNS) to determine the IP address of the Fuchsia target device. Fuchsia target devices broadcast their IP information to mDNS with a service type of _fuchsia._udp.
To query this information with avahi, run the following command:
avahi-browse --resolve _fuchsia._udp
This command will appear to hang. It first dumps any records in the avahi cache, and then sits and listens for mDNS broadcasts. If you use the --resolve flag, avahi subsequently tries to resolve any records encountered. Resolution yields the IPv6 address of the Fuchsia target device. For example:
$ avahi-browse --resolve _fuchsia._udp + zx-c863147051da IPv6 fuchsia-c863-1470-51da _fuchsia._udp local = zx-c863147051da IPv6 fuchsia-c863-1470-51da _fuchsia._udp local hostname = [fuchsia-c863-1470-51da.local] address = [fe80::ca63:14ff:fe70:51db] port = [5353] txt = []
In this example, you can see that a host record was found that contains the hostname of fuchsia-c863-1470-51da which then resolved to fe80::ca63:14ff:fe70:51db. This is the address of the connected Fuchsia target device.
If no records are found, you can look to see if the target device is replying to mDNS queries. mDNS operates on port 5353, which can be inspected with tcpdump. When you run this command, restrict the command to your target interface and filter the results by the IPv6 protocol and mDNS port. For example:
sudo tcpdump -n -i zx-c863147051da "ip6 && port 5353"
This command prints output similar to the following, which shows an mDNS query and the response cycle:
$ sudo tcpdump -n -i zx-c863147051da "ip6 && port 5353" 13:32:41.725007 IP 169.254.31.167.58994 > 224.0.0.251.5353: 0 PTR (QU)? _fuchsia._udp.local. (37) 13:32:41.725057 IP 169.254.31.167.58994 > 224.0.0.251.5353: 0 PTR (QU)? _fastboot._tcp.local. (38) 13:32:43.724131 IP6 fe80::ca63:14ff:fe70:51da.34810 > ff02::fb.5353: 0 PTR (QU)? _fuchsia._udp.local. (37) 13:32:43.724183 IP6 fe80::ca63:14ff:fe70:51da.34810 > ff02::fb.5353: 0 PTR (QU)? _fastboot._tcp.local. (38) 13:32:43.725635 IP6 fe80::ca63:14ff:fe70:51db.5353 > fe80::ca63:14ff:fe70:51da.34810: 0*- [0q] 1/0/3 PTR fuchsia-c863-1470-51da._fuchsia._udp.local. (152)
In some cases, you may be a need to check the kernel’s netfilter rules to discover a device through mDNS.
ufw is a utility for managing the kernel's netfilter rules. If you have this installed on your machine, you can check that your firewall is properly set up, run the following:
sudo ufw status
This should return something similar to the following:
Status: active To Action From -- ------ ---- Anywhere (v6) ALLOW fe80::/10 5353/udp # Fuchsia MDNS 33331:33340/udp ALLOW fe80::/10 # Fuchsia Netboot Protocol 8083/tcp ALLOW fe80::/10 # Fuchsia Package Server Anywhere (v6) ALLOW fe80::/10 33340/udp # Fuchsia Netboot TFTP Source Port 33331:33340/udp ALLOW fc00::/7 # Fuchsia Netboot Prot ocol 8083/tcp ALLOW fc00::/7 # Fuchsia Package Server Anywhere (v6) ALLOW fc00::/7 33340/udp # Fuchsia Netboot TFTP Source Port Anywhere (v6) ALLOW fc00::/7 5353/udp # Fuchsia MDNS
If this isn't the case (i.e. the output is empty), run the following command:
fx setup-ufw
Running this command sets up several UFW rules for netfilter.
There may also be additional netfilter restrictions in place.
To check the rules that are running on your machine, run the following:
sudo nft list tables
You may need to adjust rules if the output looks like the following:
$ sudo nft list tables
table ip filter
table ip nat
table inet firewalld
Most setups will likely have the first two rules:
table ip filter
table ip nat
To remove the firewalld rule, you can run the following commands:
sudo systemctl stop firewalld sudo systemctl disable firewalld sudo nft delete table inet firewalld
mDNS traffic occurs on port 5353 over the 224.0.0.251 and fe02::fb multicast addresses (IPv4 and IPv6 respectively). It may be worth inspecting the filter table, looking for any policy applied to port 5353 or these addresses. For example:
$ sudo nft list table ip filter table ip filter { ... }
If you've tried the above and the following is true:
ufw installed on your machine. See ufw rules.firewalld running on your machine. See firewalld.ffx target list.avahi. See Multicast DNS resolution.You may still have some firewall rule blocking unicast mDNS messages. You may need to add exceptions iptables manually in order to allow mDNS for link-local IPv6 messages:
sudo ip6tables -A INPUT -p udp -s fe80::/10 --sport 5353 -m comment --comment 'Fuchsia MDNS' -j ACCEPT sudo ip6tables -A INPUT -p udp -s fc00::/7 --sport 5353 -m comment --comment 'Fuchsia MDNS' -j ACCEPT
If this does not work, you may want to observe what kinds of firewall rules might be affecting IPv6 traffic and address them accordingly:
sudo iptables -L -n
Another option to discover the target’s IPv6 address is to ping the local multicast ff02::1 device address. For example:
ping6 ff02::1%zx-c863147051da
This is a predetermined address specified by IANA. For more information, see section 2.7.1 of ch 2.7.1 of RFC-4291.
Note that the local network interface was designated using the scope-id component of an IPv6 address, which is a requirement of pinging a multicast address. The -I flag could have been used to similar effect. Ping responses come from the Fuchsia device and include their IP address information. For example:
$ ping6 ff02::1%zx-c863147051da PING ff02::1%zx-c863147051da (ff02::1%zx-c863147051da) 56 data bytes 64 bytes from fe80::ca63:14ff:fe70:51da%zx-c863147051da: icmp_seq=1 ttl=64 time=0.088 ms 64 bytes from fe80::ca63:14ff:fe70:51db%zx-c863147051da: icmp_seq=1 ttl=64 time=0.958 ms
Be aware that the localhost may itself reply to the multicast ping. In this example, fe80::ca63:14ff:fe70:51da is the address of the host-side interface (as determined above), and fe80::ca63:14ff:fe70:51db is the address of the Fuchsia target device.
A good rule of thumb is that the device responding in far less than a millisecond is generally the localhost responding, and anything approaching one or more milliseconds to respond is likely the Fuchsia target device.