---
title: Troubleshooting
ref: troubleshooting
lang: en
fontawesome_icon: fa-wrench
---

== Unable to establish Ethernet connection
If you can't connect to the LibreMesh router as indicated in link:en_connecting_nodes.html[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 https://www.howtogeek.com/236838/how-to-find-any-devices-ip-address-mac-address-and-other-network-connection-details/[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 https://en.wikipedia.org/wiki/Zero-configuration_networking[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 link:en_connecting_nodes.html[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 https://www.howtogeek.com/233952/how-to-find-your-routers-ip-address-on-any-computer-smartphone-or-tablet/[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.

[IMPORTANT]
=========================
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.

=== Connect using IPv6 link local

In case neither the link:en_connecting_nodes.html[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:

. Right click the NetworkManager applet
. Edit connections -> Add -> Select _Ethernet_
. Give it any name you desire, such as _eth0 manual_
. General tab: deselect _Automatic connect_
. IPv4 tab: select _Disabled_
. 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 -v ff02::1%eth0
```

or just

```bash
ping -v 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:

. 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+).
. 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.
. Otherwise try all the router root passwords you remember.
. 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):

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

You could get an error like this:

```bash
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:

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

for more details, link:https://github.com/openwrt/openwrt/issues/9889[see here].

link:disc6[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:

```bash
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 link:../communication.html[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 link:https://openwrt.org/toh/start[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 https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset[here] or on the specific router page in https://openwrt.org/toh/start[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 link:en_connecting_nodes.html[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:

```bash
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 https://www.howtogeek.com/howto/19249/how-to-assign-a-static-ip-address-in-xp-vista-or-windows-7/[this guide], under Mac https://www.howtogeek.com/howto/22161/how-to-set-up-a-static-ip-in-mac-os-x/[this guide], under Linux https://www.linuxhint.com/change-from-dhcp-to-static-ip-address-ubuntu/[this guide] and under Android http://tunecomp.net/static-ip-android/[this guide].

If you still cannot connect, make sure you are pressing the reset button at the right time, as explained https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset[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 link:en_quick_starting_guide.html[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 https://openwrt.org/toh/start[OpenWrt table of hardware].

==== Procedure for routers with a TFTP server

Always read the https://openwrt.org/toh/start[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 https://openwrt.org/toh/start[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.