Skip to content

Troubleshooting

Unable to establish Ethernet connection

If you can’t connect to the LibreMesh router as indicated in How to connect to LibreMesh nodes opening http://thisnode.info you can try other ways.

First thing: wait 5 minutes

After powering up the router, up to 5 minutes can be needed for bringing up all the services including the DHCP server needed for receiving an IP when connecting. This is a known bug.

Do not use custom DNS servers

For using the http://thisnode.info address, the Domain Name System server have to be the one from the LibreMesh router you’re connecting to. Contrariwise, a fixed external DNS server would not recognize http://thisnode.info as an existing domain.

Verify the physical connection

If you are connecting by cable:

  • disconnect from any other network (e.g. wireless);

  • verify that the cable is well plugged and that the ethernet LED are blinking on the router and on the computer port;

  • verify that you’re connected to a LAN port on the router (or main) not to a WAN one (or secondary);

  • use a good quality cable, with intact connector, avoid half-duplex cables (with just 4 wires, low quality);

  • verify that the network manager on your computer is actually trying to connect by this cable;

  • if the network manager is down or not installed (very unlikely, every operating system has one enabled by default), connect activating the ethernet interface. Refer to your operating system documentation for detailed instructions. Using Linux terminal can be done with sudo ip link set dev eth0 up for activating the interface, eth0 could be named differently, like enp0s25 on your system, check with ip link show. Check next section on how to obtain an IP for this connection.

If you are connecting by wireless:

  • disconnect from any other network (e.g. ethernet cable);

  • check that the wireless physical switch is ON both on the LibreMesh router and on the computer;

  • verify that the network manager on your computer is actually trying to connect to the wireless network named as your network community (with default configuration is LibreMesh.org) or on the "named AP" (with default configuration is something like LibreMesh.org/abc123), connecting to the LiMe wireless SSID is not going to work as is used just for meshing;

  • if the network manager is down or not installed (very unlikely, every operating system has one enabled by default) just install one or enable the existing one. Connecting manually is doable on Linux, easy only if the AP is open, not WPA, with sudo ip link set dev wlan0 up; sudo iw dev wlan0 connect <your router ESSID> the ESSID could be your community network name or the default LibreMesh.org, wlan0 could be named differently, like wlp3s0 on your system, check with ip link show. Check next section on how to obtain an IP for this connection.

Verify the IPv4 connection

Once the physical layer is set (the previous section), you can try to connect the normal way (opening http://thisnode.info). If it does not work, before following with the next steps it’s needed to check if the LibreMesh router actually gave to our computer/smartphone an IPv4 to use for communicating on the network.

Every network manager on every operating system should request for an IPv4 to the LibreMesh router, acting as a so-called DHCP client.

The received local private IPv4 can be found following this guide for most operating systems. An additional method via Linux terminal is launching the command ip -4 address show scope global. The local private IP will look something like 10.13.123.123.

On the Linux terminal there’s the possibility to ask manually for an IPv4 with the commands sudo dhclient -x; sudo dhclient or sudo dhcpcd -x; sudo dhcpcd.

If no such address coming from the LibreMesh router can be encountered, or there’s only a Zeroconf IP starting with 169.254.x.x, means that the DHCP server on the router is not working (be sure to wait 5 minutes after the power up of the router, as explained above, and try connecting again) or the DHCP client on your computer/smartphone is not working. Make sure to verify the physical connection as described above, specifically make sure to connect to a LAN port on the router and not to a WAN port. In this case the method described on the next section "Connect using gateway IPv4" is not applicable, while the other methods should work anyway.

Connect using gateway IPv4

If trying to connect to http://thisnode.info (as explained in normal connection procedure) does not work AND an IPv4 was received for your computer/smartphone from the gateway as described in section Verify the IPv4 connection, you can take your gateway (default route) IPv4 address and connect to it. The address to use in not the one discovered in the previous section.

When you’re physically (either via ethernet cable or via wireless) connected to the router and you receive an IPv4 from it, you receive also the IPv4 direction of the gateway (default route). Please take care to disconnect from any other wireless or wired networks, otherwise a wrong gateway IPv4 can be obtained.

For obtaining the gateway direction using a Windows, Mac or Linux computer or Android smartphone refer to this guide.

If the above guide does not work for you and you’re on a Linux computer, the gateway (default route) IPv4 can be obtained using the terminal: open a terminal (open your Linux distro menu, type "terminal" and select the first result) and execute the command

ip -4 route show scope global

The output should be similar to: default via 10.13.0.1 dev enp0s0 proto static metric 100 so in this example our gateway IPv4 is 10.13.0.1. In case the output was instead command not found: ip you can find the same information using the older commands route -n | grep G or netstat -nr | grep G.

The obtained IPv4 is not relative of a specific LibreMesh router, indeed, because of a feature called anygw this IPv4 is common for all the routers. In our case this doesn’t matter because we just want connect to the directly connected one and this will work as expected.

For example let’s use 10.13.0.1 as the gateway address. You can open the IPv4 direction inserting it directly in the URL bar of the browser (not in the search bar): http://10.13.0.1

If we can’t access the web interface (can happen if we installed a LibreMesh version without web interface), we can try connecting via SSH:

ssh root@10.13.0.1

If no root password was set and the password login was not disabled by the network-profile, a blank password access is granted, otherwise the router root password is prompted.

You could get an error like this: Unable to negotiate with 10.13.0.1 port 22: no matching host key type found. Their offer: ssh-rsa. In this case, you just have to add two options to the SSH command: -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa, like this: ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa root@10.13.0.1

Discover IPv4 of your router

Do this only if the section Verify the IPv4 connection instructions failed and so the easy Connect using the gateway IPv4 is not a valid way. For following this specific way you likely need a Linux computer.

Install netdiscover package from your Linux distro repositories. Make sure to have a proper physical connection, re-read Verify the physical connection and disconnect from any other network. Run sudo netdiscover -f. Some IPv4 similar to 10.13.0.1 should appear. Add an IPv4 to your computer network interface used for connecting with the first three fields of the IP identical to the router one and the fourth different, for example 10.13.0.2 with netmask 255.255.255.0 or /24. Connect to the router inserting its IP in the browser or via SSH.

In case neither the normal connection procedure to http://thisnode.info nor the gateway IPv4 (as explained in Connect using gateway IPv4) are working for connecting to your node, you can use IPv6 link local.

This works even if no IPv4 was received from the gateway, as checked in section "Verify the IPv4 connection". Likely this works only on Linux, maybe also on Macintosh.

Each working network interface in your Linux system have a special IPv6 address configured automatically by the Kernel.
These are named IPv6 link-local and are inside the special prefix fe80::/10
The scope of these IPs is to communicate computers which are in the same collision domain, so translated to LibreMesh it would be the layer2 cloud.

If on Linux you use NetworkManager, you may create a custom profile to avoid its intervention on the ethernet interface without having to stop it:

  1. Right click the NetworkManager applet

  2. Edit connections → Add → Select Ethernet

  3. Give it any name you desire, such as eth0 manual

  4. General tab: deselect Automatic connect

  5. IPv4 tab: select Disabled

  6. IPv6 tab: select Link-Local only

Finally switch on your router and connect to it using an ethernet cable from its LAN port (WAN should also work) to the ethernet port of your computer, and select the new NetworkManager profile eth0 manual.

An alternative to create a NetworkManager profile is to stop it with sudo systemctl stop NetworkManager.service and bring up the network interface manually with sudo ip link set dev eth0 up (eth0 could be named differently, check with ip link show).

Then, how to discover the IPv6 link local address of the router we’re connected to?

Using ICMPv6 we can discover machines in our network thanks to the special Multicast address "ff02::".
To discover all the devices we can use the next command (using ping6 or ping depending on your Linux distro) where the appended %eth0 specifies which network interface to use (could be something like eth0 or enp0s25, you can see the interface names with the commands ip link show or ifconfig):

ping6 ff02::1%eth0

or just

ping ff02::1%eth0

Then each device connected to our collision domain, will reply the ICMP request with its own IPv6 link-local address.

The first answer to each ping usually is your own ethernet interface (you can see your own IPv6 link local address with ip -6 address show scope link) while the ones marked with DUP! are the connected devices, the first one is the fastest to answer, so the one you’re directly connected to. You can more or less recognize the routers IPv6 link local addresses comparing them with the final part of their physical MAC address (printed on the router label), which should be similar.

The router direction is a combination of the router’s IPv6 address, %, and your ethernet interface name. It should be something like fe90::aa20:66ff:fe4f:ae87%eth0. Do not include a trailing : or other text from the ping responses.

Now that you have the target IPv6 link local you can connect to the router:

  1. Try connecting via ssh: ssh root@fe90::aa20:66ff:fe4f:ae87%eth0. Remember to include both root@, otherwise it will attempt to connect using your personal username, and %eth0 (or whatever is the name of the interface you used for connecting, you can see all interface names with ip link show).

  2. If there’s not yet a root password set on the router and the password access was not disabled by the network-profile, a blank password access is granted.

  3. Otherwise try all the router root passwords you remember.

  4. If neither work, and you already tried with all the other methods, likely you will have to reflash your router (e.g. using TFTP) or to reset using OpenWrt failsafe mode (this last procedure could ask for the password anyway if this was set in the network-profile during compilation of the installation image).

If you managed to connect via ssh you can also copy files on the router using IPv6 link local and scp (for copying big files like firmware images use the /tmp directory as a destination):

scp LiMe-fw-sysupgrade.bin root@\[fe80::a2f3:c1ff:fe39:1cea%eth0\]:/tmp/

You could get an error like this:

ash: /usr/libexec/sftp-server: not found
scp: Connection closed

In this case, you just have to add a -O option to the ssh command, like this:

scp -O LiMe-fw-sysupgrade.bin root@\[fe80::a2f3:c1ff:fe39:1cea%eth0\]:/tmp/

for more details, see here.

Click here for downloading Pau’s script which check if there is some router attached to your network device and in case, try to connect to it.
If there are not routers it waits until some appears.

An example of execution:

p4u@nomada:~$ ./disc6 eth1

Still no access possible (e.g. access password lost)

If you tried all the instructions above without success, we suggest to ask for help via our contacts before trying anything else.

These situations of non-responsivity can arise from bad manual configurations and customizations (network-profile) or bad images being flashed or incompatible router model.

If you feel confident enough, you can try to boot your router in OpenWrt failsafe mode or to re-flash it using low level procedures e.g. TFTP (if available) or serial connection (risky) or other recovery procedures you can find on your router’s specific page.

Recover from bad configurations with Failsafe mode

Failsafe mode enables you to recover from bad configurations without much trouble. Learn how to access Failsafe mode here or on the specific router page in OpenWrt table of hardware. If you’re trying to reset the router after forgetting the password, this procedure could ask for the password anyway in case this was set in the network-profile during compilation of the installation image.

The generic procedure is to start pressing repeatedly the router reset button during the boot, the LEDs should start blinking and failsafe mode activated instead of normal boot.

Once in failsafe, connect by ethernet cable or by wireless to the router and try to connect to it as if was a freshly flashed LibreMesh router as explained in the connection procedure on this site. If that does not work, try connecting to 192.168.1.1 or 10.13.0.1 (the IP could be even different if you flashed an image compiled with the preset configuration from your community) inserting the http://192.168.1.1 or http://10.13.0.1 direction in the URL bar of the browser or via SSH:

ssh root@192.168.1.1
ssh root@10.13.0.1

If an error like Unable to connect or No route to host is obtained, likely you will have to set an IP for your computer, for example 192.168.1.2 or 10.13.0.2, before attempting to connect again. For setting an IP to your computer under Windows follow this guide, under Mac this guide, under Linux this guide and under Android this guide.

If you still cannot connect, make sure you are pressing the reset button at the right time, as explained in this guide. Then, if the problem persists, it’s likely that the IP is the one customized by your community (e.g. 10.XXX.0.1) so you can ask any member of your community or find it following the instructions above.

Re-flashing via TFTP

When the aforementioned connection procedures don’t work and Failsafe mode doesn’t help, likely we will have to reinstall a firmware image. As the normal way to reinstall, explained in Quick Starting Guide likely is not going to work, we can try communicating directly with the router bootloader. The bootloader is a tiny piece of software that never gets modified when flashing OpenWrt/LibreMesh and includes recovery functions. Usually it includes a TFTP (Trivial File Transfer Protocol) service, either server (e.g. on Ubiquiti routers) or client (e.g. on TP-Link routers), which can be activated keeping the reset button pressed for 10 seconds while plugging the router power cord (in Ubiquiti routers the success of this operation is confirmed by a nice blinking pattern of the LEDs) or is active for a short time after plugging the router (in some old Linksys routers). For specific instructions about how to activate the TFTP server or client in each router refer to OpenWrt table of hardware.

Procedure for routers with a TFTP server

Always read the OpenWrt table of hardware before attempting this procedure.

To prepare for a TFTP flashing procedure:

  • install a TFTP client on your PC, on Linux distros usually the package is named tftp-hpa;

  • connect your PC via an ethernet cable to a LAN ethernet port on the unpowered router;

  • use the connection manager of your PC to disconnect from any interface other than ethernet cable (e.g. wireless);

  • set up a profile for the ethernet interface with a manual IPv4, suggested configurations are IPv4 192.168.1.2, netmask 24, broadcast domain 255.255.255.0, gateway (not really needed) 192.168.1.1;

  • open a terminal and using the command cd enter the directory where you downloaded the image to flash;

  • issue the command tftp 192.168.1.1 which will open TFTP for connecting to 192.168.1.1 that is the most common router IP address in TFTP recovery mode;

  • in tftp execute the commands binary that sets the mode of transfer, trace on which enables a clearer output, rexmt 1 which specifies the retransmission timeout, timeout 60 which sets the total transmission timeout;

  • then enable the TFTP recovery mode in your router, depending on the specific model procedure;

  • execute in TFTP the command put <place here the name of the file -factory.bin>;

  • the output should be a long list of chunks being transferred;

  • wait 5 minutes for the flashing to be complete and reboot the router.

We recommend to follow these instructions only after verifying the goodness of it for the specific device to recover.

Procedure for routers with a TFTP client

In this case, the procedure can change by a wider extent so that the router-specific instructions need to be followed as reported on OpenWrt table of hardware.

Serial connection

Recovery through serial connection can be completely different from router to router and highly esoteric. A lot of digging into any form of human knowledge is suggested before attempting to recover a router this way.