Remote Access

In a web browser navigate to your router’s IP address e.g. http://192.168.1.1, which is usually printed on a label on your router; this will take you to a control panel. Then log in using your credentials, which is usually also printed on the router or sent to you in the accompanying paperwork. Browse to the list of connected devices or similar (all routers are different), and you should see some devices you recognise. Some devices are detected as PCs, tablets, phones, printers, etc. so you should recognise some and rule them out to figure out which is your Raspberry Pi. Also note the connection type; if your Raspberry Pi is connected with a wire there should be fewer devices to choose from.

On Raspberry Pi OS, multicast DNS is supported out-of-the-box by the Avahi service.

If your device supports mDNS, you can reach your Raspberry Pi by using its hostname and the .local suffix. The default hostname on a fresh Raspberry Pi OS install is raspberrypi, so by default any Raspberry Pi running Raspberry Pi OS responds to:

If the Raspberry Pi is reachable, ping will show its IP address:

If you change the system hostname of the Raspberry Pi (e.g., by editing /etc/hostname), Avahi will also change the .local mDNS address.

If you don’t remember the hostname of the Raspberry Pi, but have a system with Avahi installed, you can browse all the hosts and services on the LAN with the avahi-browse command.

The nmap command (Network Mapper) is a free and open-source tool for network discovery, available for Linux, macOS, and Windows.

To use nmap to scan the devices on your network, you need to know the subnet you are connected to. First find your own IP address, in other words the one of the computer you’re using to find your Raspberry Pi’s IP address:

Now you have the IP address of your computer, you will scan the whole subnet for other devices. For example, if your IP address is 192.168.1.5, other devices will be at addresses like 192.168.1.2, 192.168.1.3, 192.168.1.4, etc. The notation of this subnet range is 192.168.1.0/24 (this covers 192.168.1.0 to 192.168.1.255).

Now use the nmap command with the -sn flag (ping scan) on the whole subnet range. This may take a few seconds:

Ping scan just pings all the IP addresses to see if they respond. For each device that responds to the ping, the output shows the hostname and IP address like so:

Here you can see a device with hostname raspberrypi has IP address 192.168.1.8. Note, to see the hostnames, you must run nmap as root by prepending sudo to the command.

First find your own IP address(es), in other words the one of the computer you’re using to find your Raspberry Pi’s IP address by hostname -I

fd00::ba27:ebff:feb6:f293 2001:db8:494:9d01:ba27:ebff:feb6:f293

The example shows two IP addresses. The first one is a so called unique local unicast address(fc00::/7). The second one is the global unicast address(2000::/3). It is also possible to see only one of them depending on your network (router) configuration. Both addresses are valid for reaching the Raspberry Pi within your LAN. The address out of 2000::/3 is accessible world wide, provided your router’s firewall is opened.

Now use one of IPs from the first step to ping all local nodes:

-c 2 stands for sending two echo requests

-I with the IP address, it sets the interface and the source address of the echo request, it is necessary to choose the interface’s IP address, eth0 isn’t sufficient - the answer would be the local link address(fe80::/10), we need the global or local unicast address

ff02::1 is a well known multicast address for all nodes on the link, so it behaves like a local broadcast, usually it is defined in /etc/hosts so you can also use the name (ip6-allnodes or ipv6-allnodes) instead of the literal address

Some newer systems expect the interface ID behind the multicast address.

This should result in replies from all the nodes on your (W)LAN link, with associated DNS names.

Exclude your own IP( here 2001:db8:494:9d01:ba27:ebff:feb6:f293 ), then check the others by trying to connect them via SSH.

The Fing app is a free network scanner for smartphones. It is available for Android and iOS.

Your phone and your Raspberry Pi have to be on the same network, so connect your phone to the correct wireless network.

When you open the Fing app, touch the refresh button in the upper right-hand corner of the screen. After a few seconds you will get a list with all the devices connected to your network. Scroll down to the entry with the manufacturer "Raspberry Pi". You will see the IP address in the bottom left-hand corner, and the MAC address in the bottom right-hand corner of the entry.

The files on your NFS are open to anyone on the network. As a security measure, you can restrict access to specified clients.

Add the following line to /etc/hosts.deny:

By blocking all clients first, only clients in /etc/hosts.allow (added below) will be allowed to access the server.

Now add the following line to /etc/hosts.allow:

where <list of IPv4s> is a list of the IP addresses of the server and all clients. (These have to be IP addresses because of a limitation in rpcbind, which doesn’t like hostnames.) Note that if you have NIS set up, you can just add these to the same line.

Please ensure that the list of authorised IP addresses includes the localhost address (127.0.0.1), as the startup scripts in recent versions of Ubuntu use the rpcinfo command to discover NFSv3 support, and this will be disabled if localhost is unable to connect.

Finally, to make your changes take effect, restart the service:

Add the following line to /etc/hosts.deny:

By blocking all clients first, only clients in /etc/hosts.allow (added below) will be allowed to access the server.

Now add the following line to /etc/hosts.allow:

where <NFS server IP address> is the IP address of the server.

A user’s file access is determined by their membership of groups on the client, not on the server. However, there is an important limitation: a maximum of 16 groups are passed from the client to the server, and if a user is member of more than 16 groups on the client, some files or directories might be unexpectedly inaccessible.

Add any client name and IP addresses to /etc/hosts. (The IP address of the server should already be there.) This ensures that NFS will still work even if DNS goes down. Alternatively you can rely on DNS if you want - it’s up to you.

This applies to clients using NIS. Otherwise you can’t use netgroups, and should specify individual IPs or hostnames in /etc/exports. Read the BUGS section in man netgroup for more information.

First, edit /etc/netgroup and add a line to classify your clients (this step is not necessary, but is for convenience):

where myclients is the netgroup name.

Next run this command to rebuild the NIS database:

The filename yp refers to Yellow Pages, the former name of NIS.

Add the following line to /etc/hosts.deny:

By blocking all clients first, only clients in /etc/hosts.allow (added below) will be allowed to access the server.

Consider adding the following line to /etc/hosts.allow:

where <list of IPs> is a list of the IP addresses of the server and all clients. These have to be IP addresses because of a limitation in rpcbind. Note that if you have NIS set up, you can just add these to the same line.

Install the necessary packages:

Edit /etc/exports and add the shares:

The example above shares /home and /usr/local to all clients in the myclients netgroup.

The example above shares /home and /usr/local to two clients with static IP addresses. If you want instead to allow access to all clients in the private network falling within a designated IP address range, consider the following:

Here, rw makes the share read/write, and sync requires the server to only reply to requests once any changes have been flushed to disk. This is the safest option; async is faster, but dangerous. It is strongly recommended that you read man exports if you are considering other options.

After setting up /etc/exports, export the shares:

You’ll want to run this command whenever /etc/exports is modified.

By default, rpcbind only binds to the loopback interface. To enable access to rpcbind from remote machines, you need to change /etc/conf.d/rpcbind to get rid of either -l or -i 127.0.0.1.

If any changes are made, rpcbind and NFS will need to be restarted:

Aside from the UID issues discussed above, it should be noted that an attacker could potentially masquerade as a machine that is allowed to map the share, which allows them to create arbitrary UIDs to access your files. One potential solution to this is IPSec. You can set up all your domain members to talk to each other only over IPSec, which will effectively authenticate that your client is who it says it is.

IPSec works by encrypting traffic to the server with the server’s public key, and the server sends back all replies encrypted with the client’s public key. The traffic is decrypted with the respective private keys. If the client doesn’t have the keys that it is supposed to have, it can’t send or receive data.

An alternative to IPSec is physically separate networks. This requires a separate network switch and separate Ethernet cards, and physical security of that network.

You can share any folder you want, but for this example, simply create a folder called share.

The folder should now be shared.

On Windows 10 there is a Sharing Wizard that helps with some of these steps.

Mounting in Linux is the process of attaching a folder to a location, so firstly we need that location.

Now, we need to mount the remote folder to that location. The remote folder is the host name or IP address of the Windows PC, and the share name used when sharing it. We also need to provide the Windows username that will be used to access the remote machine.

You should now be able to view the content of the Windows share on your Raspberry Pi.

This error is caused by a combination of two things: A SMB protocol version mismatch, and the CIFS client on Linux returning a misleading error message. In order to fix this a version entry needs to be added to the mount command. By default Raspberry Pi OS will only use versions 2.1 and above, which are compatible with Windows 7 and later. Older devices, including some NAS, may require version 1.0:

You may need to try different versions to match up with the server version. Possible values are:

You can enable VNC Server at the command line using raspi-config:

Now, enable VNC Server by doing the following:

Direct connections are quick and simple providing you’re joined to the same private local network as your Raspberry Pi. For example, this might be a wired or wireless network at home, at school, or in the office.

You are entitled to use RealVNC’s cloud service for free, provided that remote access is for educational or non-commercial purposes only.

Cloud connections are convenient and encrypted end-to-end. They are highly recommended for connecting to your Raspberry Pi over the internet. There’s no firewall or router reconfiguration, and you don’t need to know the IP address of your Raspberry Pi, or provide a static one.

To complete either a direct or cloud connection, you must authenticate to VNC Server.

If you’re connecting from the compatible VNC Viewer app from RealVNC, enter the user name and password you normally use to log in to your user account on the Raspberry Pi. By default, these credentials are pi and raspberry.

If you’re connecting from a non-RealVNC Viewer app, you’ll first need to downgrade VNC Server’s authentication scheme, specify a password unique to VNC Server, and then enter that instead.

This default web page is just an HTML file on the filesystem. It is located at /var/www/html/index.html.

Navigate to this directory in a terminal window and have a look at what’s inside:

This will show you:

This shows that by default there is one file in /var/www/html/ called index.html and it is owned by the root user (as is the enclosing folder). In order to edit the file, you need to change its ownership to your own username. Change the owner of the file (the default pi user is assumed here) using sudo chown pi: index.html.

You can now try editing this file and then refreshing the browser to see the web page change. If you know HTML you can put your own HTML files and other assets in this directory and serve them as a website on your local network.

Before the Raspberry Pi 3 Model B will network boot it needs to be booted from an SD Card with a config option to enable USB boot mode. This will set a bit in the OTP (One Time Programmable) memory in the Raspberry Pi SoC that enables network booting. Once this is done, the Raspberry Pi 3B will attempt to boot from USB, and from the network, if it cannot boot from the SD card.

Install Raspberry Pi OS Lite, or Raspberry Pi OS with desktop, on the SD card in the usual fashion. Next, enable USB boot mode with the following command:

This adds program_usb_boot_mode=1 to the end of /boot/config.txt. Reboot the Raspberry Pi with sudo reboot. Once the client Raspberry Pi has rebooted, check that the OTP has been programmed with:

Ensure the output 0x3020000a is correct.

The client configuration is almost done. The final thing to do is to remove the program_usb_boot_mode line from config.txt. You can do this with sudo nano /boot/config.txt, for example. Finally, shut the client Raspberry Pi down with sudo poweroff.

Network boot can be enabled on the Raspberry Pi 4 using the raspi-config tool. First, run raspi-config as follows:

Within raspi-config, choose Advanced Options, then Boot Order, then Network Boot. You must then reboot the device for the change to the boot order to be programmed into the bootloader EEPROM. Once the Raspberry Pi has rebooted, check that the boot order is now 0xf21:

For further details of configuring the Raspberry Pi 4 bootloader, see Raspberry Pi 4 Bootloader Configuration.

This should now allow your Raspberry Pi client to attempt to boot through until it tries to load a root file system (which it doesn’t have).

At this point, export the /nfs/client1 file system created earlier, and the TFTP boot folder.

Restart RPC-Bind and the NFS server in order to have them detect the new files.

Edit /tftpboot/cmdline.txt and from root= onwards, and replace it with:

You should substitute the IP address here with the IP address you have noted down. Also remove any part of the command line starting with init=.

Finally, edit /nfs/client1/etc/fstab and remove the /dev/mmcblk0p1 and p2 lines (only proc should be left). Then, add the boot partition back in:

Good luck! If it doesn’t boot on the first attempt, keep trying. It can take a minute or so for the Raspberry Pi to boot, so be patient.

The first thing the bootloader does is send a router solicitation to get the details of the network. The router responds with an advertisement packet identifying its ethernet address, which the bootloader might need if the TFTP server is on a different network.

The router advertisement includes a flag which tells it whether to use stateful (managed) or stateless (unmanaged) configuration for its IP address. Stateless configuration means that the device configures its own IP address. Currently the bootloader generates an address derived from its ethernet MAC address and a network prefix supplied by the router.

If the router indicates that stateful configuration is enabled DHCP is used to obtain the IP address of the device. This involves the device sending a solicitation request to a DHCP server which responds with an advertisement. The client then requests the address before getting a reply acknowledgement from the server.

DHCP Servers and clients identify themselves with variable length DUID (Device Unique ID). On the Raspberry Pi this is derived from the MAC address (DUID_LL).

Whether using stateless or stateful configuration, the DHCP server is used to obtain the TFTP server address. This is encoded in the BOOTFILE-URL parameter. We send the client architecture type value 0x29 to identify a device.

See RFC 5970 and the IANA Dynamic Host Configuration Protocol for IPv6 documentation.

The device should now have an IP address and TFTP details. It downloads the firmware binary start4.elf from the TFTP server and continues running with this. The firmware is passed the IP address and TFTP server details so it can download the kernel and boot the rest of the system.

With IPv4 netboot, nfsroot is used to mount rootfs over the network. This doesn’t support IPv6 so another solution is required. It might involve a small RAM file system that can mount the appropriate network location before switching to the proper rootfs contents.

If you have a working IPv4 network boot setup you can reuse the TFTP server in dnsmasq to supply the files (it can talk to both IPv4 and IPv6).

Alternatively you can use a standalone TFTP server like tftpd-hpa.

DHCP in IPv6 has changed a lot. We need DHCP to at least tell us the address of the TFTP server, which in this case is the same machine.

Modify the configuration in /etc/default/isc-dhcp-server

In /etc/dhcp/dhcpd6.conf you need to specify the TFTP server address and setup a subnet. Here the DHCP server is configured to supply some made up unique local addresses (ULA). The host test-rpi4 line tells DHCP to give a test device a fixed address.

Your server has to be assigned the IPv6 address in /etc/dhcpcd.conf

Now start the DHCP server.

Modify the configuration to tell it to attempt network boot via IPv6 rather than IPv4.

To revert to IPv4 network boot just remove the USE_IPV6 line from boot.conf.

To use IPv6 you really need a router and ISP that supports IPv6. There are sites on the internet that can check this for you or alternatively run the following command.

This sends a router solicitation to your router asking for your network details such as the network prefix, router ethernet address and whether to use DHCP for addressing. If there’s no response to this command it’s likely your network and ISP only supports IPv4. If IPv6 is supported it’s most likely that it will be configured to use stateless configuration where clients generate their own addresses.

You might be able to configure your router for stateful configuration, which means it will use DHCP to obtain an IP address.

If the boot uart is enabled you should see something like this from the serial port. The lines starting RX6 indicate that IPv6 is in use.

Here dc:a6:32:6f:73:f4 is the MAC address of the TFTP server and it has an IPv6 address of fd49:869:6f93::1. The device itself has a MAC address e4:5f:01:20:24:0b and an IPv6 address of fd49:869:6f93::1000

Finally the bootloader hands over to firmware which should load the kernel.

You can examine network activity with tcpdump.

Below is an extract of a TCP dump where the router is configured to use stateful (DHCP) network configuration.

Device sends a router solicitation.

Router sends a response telling the device to use stateful configuration.

Device sends a DHCP solicitation.

The DHCP server replies with an advertisement.

The device sends a request for an address and TFTP details to the DHCP server.

The DHCP server replies, opt_59 is used to pass the address of the TFTP server.

The device sends a neighbour solicitation to the FTP server because it needs its MAC address.

The FTP server replies with its MAC address.

TFTP requests are made by the device which should now boot over the network.

Below is an extract of a tcp dump for a stateless (non-DHCP) network configuration.

The device sends a router solicitation.

The router replies with the network details.

The device sends an information request to the DHCP multicast address asking for the TFTP details.

The DHCP server replies with the TFTP server details (opt_59).

The device asks for the TFTP server MAC address since it can tell it’s on the same network.

The FTP server replies with its MAC address.

The device starts making TFTP requests.