Hi Amuza! So the other Nanostation is an XM one, right? Sounds like you're using the right image for that model, at least according to the OpenWrt wiki page: https://openwrt.org/toh/ubiquiti/nanostationm5 The only thing I noticed which could (?) cause a failure in the upgrade is that you're flashing the "factory" image using the sysupgrade tool instead of the "sysupgrade" image. Did you compile using OpenWrt 19.07.7 as a base? Please avoid flashing images based on OpenWrt trunk unless you're sure of what you're doing (there is some risk involved in upgrading to images with DSA switch driver and even more in downgrading afterwards). You could also try with the image taken from here: http://repo.libremesh.org/expansive_emancipation/2020.1/targets/ath79/gener… these are images I compiled and uploaded on the LibreMesh servers (recently devs gave me access) but I did not announce them as I have not yet tested them... Ciao! Ilario On 4/5/21 11:08 AM, amuza wrote: -- Ilario iochesonome(a)gmail.com ilario(a)sindominio.net

Hey Amuza! Nope, those images do not include babeld-auto-gw-mode as it was not included in the LibreMesh 2020.1 release. And, I fear you will not be able to install it via OPKG or LuCI, as it is not included in the 2020.1 packages repository, please try and let us know. What you can do is download it from the master branch packages repository and install it manually using OPKG. You can find the compiled package here: https://github.com/libremesh/lime-feed/tree/gh-pages/master Ciao! Ilario On 4/29/21 6:50 PM, amuza wrote: -- Ilario iochesonome(a)gmail.com ilario(a)sindominio.net

On 4/29/21 9:01 PM, amuza wrote: Verry goodd questionn. Looking quickly on the internet seems that you can check the processor and the RAM size for understanding if it is XM or XW. The reference values are here: https://openwrt.org/toh/ubiquiti/nanostationm5#hardware_highlights https://openwrt.org/toh/hwdata/ubiquiti/ubiquiti_nanostation_m5_xw https://openwrt.org/toh/hwdata/ubiquiti/ubiquiti_nanostation_m5_xm Yess, the XM has just 32 MB of RAM (the flash memory is not a problem, 8 MB are enough), while the latest OpenWrt release recommends at least 64 and the next OpenWrt release will not even be compiled for 4/32 devices: https://openwrt.org/supported_devices/432_warning#supportability_issues Yesssss, good idea. What takes a lot of RAM I suppose is the web interface. You can compile taking just the first packages from the development page (i.e. do not install check-date-http and all the other packages listed after this): https://libremesh.org/development.html#compiling_libremesh_from_source_code BUT *avoiding to select lime-app*. This way, you should have an image without uhttpd. Nice! Using old hardware is cheaper and way more sustainable than buying new stuff :D Hugs, Ilario

So, compiling with 19.07.6 (as suggested at libremesh.org) is ok and compiling with 19.07.7 is not? Is that correct?

Ilario Gelmetti: Ok, I misunderstood, now I understand you mean I should avoid master branch. Yes, I'm starting to use 19.07.7 and will report any issue. If this new 21.02 release stops supporting old hardware I would be very happy if Libremesh takes this into consideration in order to find a solution compatible with a healthy planet. I don't want to throw away my old routers and buy new ones!

On 5/1/21 12:40 AM, amuza wrote: Hey Amuza! Interesting that the wifi is not working... :/ Could you upload somewhere (any pastebin service will do) the output of the lime-report command? Maybe it is not present in your device as it was not included in the really minimal install... In this case, take the installable package from here (and install it with opkg): https://github.com/libremesh/lime-feed/tree/gh-pages/v2020.1 or just download the only lime-report file from here: https://github.com/libremesh/lime-packages/tree/master/packages/lime-report… Hopefully this will help understanding what's happening there... And also check running "opkg list-installed" if uhttpd is installed. It should not be there, as all the LibreMesh-related packages depending on it are deselected (lime-app, check-date-http and firstbootwizard). In case it is, means that the ".config" file in your compilation directory needs to be deleted and the "make menuconfig" issued again selecting again the minimal packages set. Yesss, I also hope we can do that. Reading the OpenWrt website it is unclear to me if they will not distribute the binary images for the 4/32 routers or if they will completely remove the profiles needed for compiling such images. I think that the first option is the most likely, so that we will still be able to compile LibreMesh images for those routers :) Ciao! Ilario

amuza: Right now I'm freaking out with this Nanostation M5 XM, I always thought Nanostations Main port was a DHCP client, but now it is a DHCP server! That is the way I connect to it. What the root is going on???

On 5/2/21 12:33 AM, amuza wrote: The lime-report output looks good to me... The other mesh nodes are even possible to reach through the wifi mesh interface. Please remember that the AP interface is on the 5 GHz band, so that for seeing it you'll need a 5 GHz-capable client device. Perfect :) Still, from the "free" command in lime-report seems that there are just 4 MB of free RAM, I'm not sure if that's enough when the antenna will have some activity... Maybe disabling the AP and APname (if you don't use it anyway...) could save more RAM? The way to disable AP and APname is to add a configuration line in /etc/config/lime-node in the wireless section, like this: config lime wifi list modes 'ieee80211s' which will overwrite the whole "modes" list effectively removing the other two default entries (ap and apname). Another interesting option for having lower RAM usage (and a simpler architecture) would be to have a network with only one of the two routing protocols but this currently does not work. If you're interested in this check out some related issues: https://github.com/libremesh/lime-packages/issues/666 https://github.com/libremesh/lime-packages/issues/468 I tried to verify this checking in the OpenWrt code, and it looks like this changed over time, can anyone confirm?? In the original implementation (I just found it for the XW model) seems that the Main (eth0.1?) was LAN and Secondary (eth0.2?) was WAN: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blobdiff;f=target/linux/ar… but at some point seems that this got inverted (is Main eth0 and Secondary eth1?): https://github.com/openwrt/openwrt/blob/openwrt-19.07/target/linux/ath79/ba… Is this right?? Weird and annoying that these things can change. Ciao! Ilario -- Ilario iochesonome(a)gmail.com ilario(a)sindominio.net

amuza: I still do not understand what happens... I understand the Secondary port is a DHCP client, that's good to be used as a WAN port, as you Ilario mentioned. But, if Main port of a Nanostation M5 XM has a DHCP server, how is it possible that I connect to it one end of an Ethernet cable and the other end to a LAN port of a different LiMe node and both nodes talk to each other without a problem? Aren't they two DHCP servers? Isn't it a problem?

On 5/26/21 1:19 AM, amuza wrote: No idea. Sounds like one of those ideas that should work in theory but are a "Titanic" when you actually implement them. In brief, I don't think it's worth trying. Ciao! Ilario

On 5/25/21 4:54 PM, amuza wrote: Wow, very weird. I don't have with me any Nanostation XM for reproducing :/ Yep. Meh, you can try to install htop and check how much memory each software uses. The default top (from BusyBox) is not very reliable for that, see https://forum.archive.openwrt.org/viewtopic.php?id=38234 If you don't have installed the respective lime-proto-* packages, those options will do nothing. If you prefer, you can eliminate those options. They are there just in case people decide to replace X by Y (e.g. there are some adhoc options that are useless unless you select the mode adhoc, of there are BMX7 options that are useless unless you replace Babeld with BMX7). Yes. But I suspect there are people out there using different sets of routing protocols or adhoc/ieee802.11s choices. Ciao! Ilario -- Ilario iochesonome(a)gmail.com ilario(a)sindominio.net

Ilario Gelmetti: Yes, very weird. But as my problem is solved, we can forget it. There is also is a chance I was doing something wrong, I don't know. It's crystal clear now, I think I'll comment them out for clarity sake. Thank you very much! I think I have a working Nanostation M5 XM now, only for mesh, but I think it works fine, so thank you very much for all the answers and for discovering mesh was hiddenly working! Now I can flash my several Nanostations M5 XM.