Express connected to WIFI network, not showing in my.farm.bot

So today i’ve powered on my Farmbot Express for the first time, and tried to get it to connect to the https://my.farm.bot/ portal. My problem is that allthough it seems to connect to my wifi network, it doesn’t seem to ever show up in my.farm.bot, no logs, and Connectivity indicates that last farm bot message was seen 10 years ago.

I think because the farm bot can connect to the network, it never recreates the farmbot-XXXX access-point, but i’ve been able to access the configurator by navigating to the IP of the farmbot on my LAN.

So far i’ve tried:

  • Connecting to my WIFI network
  • Changing the channel of my Wifi network
  • Using a repeater in the shed next to the farm bot
  • Manually entering AP name in the configurator
  • Using advanced settings to give Farmbot a static IP
  • Reflashing micro SD card with 10.1.2
  • SSH-ing into farm bot and viewing the logs / network config (See output below)

At this point i’m kind of out of ideas and open to hear what else i can try.

farmbot logs
18:56:58.826 [info]  Firmware needs flash still. Not opening
18:57:03.897 [info]  Firmware needs flash still. Not opening
18:57:05.980 [info]  Attempting to get OTA certs from AMQP.
18:57:06.046 [info]  No credentials yet. Can't connect to OTA Server.
18:57:08.969 [info]  Firmware needs flash still. Not opening
18:57:14.046 [info]  Firmware needs flash still. Not opening
18:57:19.117 [info]  Firmware needs flash still. Not opening
18:57:21.089 [info]  Attempting to get OTA certs from AMQP.
18:57:21.152 [info]  No credentials yet. Can't connect to OTA Server.
18:57:24.188 [info]  Firmware needs flash still. Not opening
18:57:29.263 [info]  Firmware needs flash still. Not opening
18:57:34.340 [info]  Firmware needs flash still. Not opening
18:57:36.194 [info]  Attempting to get OTA certs from AMQP.
18:57:36.256 [info]  No credentials yet. Can't connect to OTA Server.
18:57:39.413 [info]  Firmware needs flash still. Not opening
18:57:44.483 [info]  Firmware needs flash still. Not opening
18:57:49.554 [info]  Firmware needs flash still. Not opening
18:57:51.299 [info]  Attempting to get OTA certs from AMQP.
18:57:51.363 [info]  No credentials yet. Can't connect to OTA Server.
18:57:54.636 [info]  Firmware needs flash still. Not opening
18:57:59.709 [info]  Firmware needs flash still. Not opening
18:58:04.783 [info]  Firmware needs flash still. Not opening
18:58:06.406 [info]  Attempting to get OTA certs from AMQP.
18:58:06.470 [info]  No credentials yet. Can't connect to OTA Server.
18:58:09.858 [info]  Firmware needs flash still. Not opening
18:58:14.929 [info]  Firmware needs flash still. Not opening
18:58:20.001 [info]  Firmware needs flash still. Not opening
18:58:21.513 [info]  Attempting to get OTA certs from AMQP.
18:58:21.578 [info]  No credentials yet. Can't connect to OTA Server.
18:58:25.073 [info]  Firmware needs flash still. Not opening
18:58:30.145 [info]  Firmware needs flash still. Not opening
18:58:35.216 [info]  Firmware needs flash still. Not opening
18:58:36.621 [info]  Attempting to get OTA certs from AMQP.
18:58:36.688 [info]  No credentials yet. Can't connect to OTA Server.
18:58:40.287 [info]  Firmware needs flash still. Not opening
Network config
[
  {["available_interfaces"], ["wlan0"]},
  {["connection"], :internet},
  {["interface", "eth0", "connection"], :disconnected},
  {["interface", "eth0", "state"], :configured},
  {["interface", "eth0", "type"], FarmbotOS.Platform.Target.Network.PreSetup},
  {["interface", "lo", "addresses"],
   [
     %{
       address: {0, 0, 0, 0, 0, 0, 0, 1},
       family: :inet6,
       netmask: {65535, 65535, 65535, 65535, 65535, 65535, 65535, 65535},
       prefix_length: 128,
       scope: :host
     },
     %{
   address: {127, 0, 0, 1},
       family: :inet,
       netmask: {255, 0, 0, 0},
       prefix_length: 8,
       scope: :host
     }
   ]},
  {["interface", "lo", "lower_up"], true},
  {["interface", "lo", "mac_address"], "00:00:00:00:00:00"},
  {["interface", "lo", "present"], true},
  {["interface", "usb0", "connection"], :disconnected},
  {["interface", "usb0", "state"], :retrying},
  {["interface", "usb0", "type"], VintageNetEthernet},
  {["interface", "wlan0", "addresses"],
   [
     %{
       address: {192, 168, 178, 30},
       family: :inet,
       netmask: {255, 255, 255, 0},
       prefix_length: 24,
       scope: :universe
     }
   ]},
  {["interface", "wlan0", "connection"], :internet},
  {["interface", "wlan0", "lower_up"], true},
  {["interface", "wlan0", "mac_address"], "b8:27:eb:ad:9f:08"},
  {["interface", "wlan0", "present"], true},
  {["interface", "wlan0", "state"], :configured},
  {["interface", "wlan0", "type"], VintageNetWiFi},
  {["interface", "wlan0", "wifi", "access_points"],
   [
     %VintageNetWiFi.AccessPoint{
       band: :wifi_2_4_ghz,
       bssid: "b0:4e:26:75:XX:XX",
       channel: 5,
       flags: [:wpa2_psk_ccmp, :ess],
       frequency: 2432,
       signal_dbm: -84,
       signal_percent: 22,
       ssid: "TP-LINK_XXXX"
     }
   ]},
  {["interface", "wlan0", "wifi", "clients"], []},
  {["interface", "wlan0", "wifi", "current_ap"],
   %VintageNetWiFi.AccessPoint{
     band: :wifi_2_4_ghz,
     bssid: "b0:4e:26:75:XX:XX",
     channel: 5,
     flags: [:wpa2_psk_ccmp, :ess],
     frequency: 2432,
     signal_dbm: -85,
     signal_percent: 20,
     ssid: "TP-LINK_XXXX"
   }}
]
1 Like

Firewall, maybe? You may have hit these already, but since there’s lots of docs, maybe not yet. Troubleshooting:

@rme_2001 This is usually the result of a local network configuration problem or a lack of WiFi signal. We have never seen an RPi0 with a bad WiFi module and there is no evidence of a network outage on our end.

To fix the issue, we will need to remove as many factors as possible and then step things out from there.

Some troubleshooting tips:

  1. very carefully unscrew the RPi0 from the electronics box and move it inside as close as possible to the WiFi router. You can power the RPi0 using any USB adapter that you already own.
  2. Using Balena Etcher, re-flash the SD card and start configuration over. Do not attempt to re-use the existing image on your card, it is important that you completely re-flash the SD card from a desktop computer.
  3. After running configurator, wait 3-5 minutes for the device to come online, ignoring any errors you may see regarding firmware (the device is detached from the Farmduino, so this is to be expected).
  4. If the device comes online at this point, then the issue is a WiFi range problem. You may need to install a WiFi range extender.
  5. If the device is still unable to come online, then the issue is most likely a network configuration problem. My recommendation is to repeat this process on a mobile hot spot, different access point, etc… to rule out problems with the local router.

The most common causes for connectivity problems are:

  • Running content blockers, firewalls, family filter, etc… We have written a guide for IT security professionals on ports / hosts that FarmBot needs access to.
  • Using a bad email/password in configurator. Configurator does not have access to the internet, so it will not detect a bad password at the time of data entry. Your logs don’t seem to indicate this, but it is one of the most common errors (and I will leave it here for anyone finding this issue via search).
  • Running multiple switches / routers in the same LAN. This is will cause problems that only show up for FarmBot, but don’t necessarily affect other devices like laptops or smart phones.
  • Assuming that the RPi0 has the same operating requirements as other consumer electronics. This is an important distinction. The RPi is not the same thing as a desktop computer and FBOS has operating requirements that are vastly different than a desktop computer doing common tasks like web browsing. Many folks are able to use their home network for things like email and Youtube over WiFi, but still have issues connecting their device due to local settings that are out of our control. Unlike many other WiFi devices, the WiFi on an RPi is not able to switch bands when there is too much congestion on the 2.4 GHz spectrum, for example.

Please let me know if that helps.

1 Like

Just the opposite. The Factory Reset timer ( running while it has no useable Internet connections to Web App, etc ) is 7200 minutes = 5 days and needs to be enabled.
Maybe wait longer :slight_smile: or just re-flash FBOS, as @RickCarlino suggested.

See it on the Web App Power and Reset section =>

@RickCarlino Thank you for your detailed reply. @jebba @jsimmonds thank you for your input.

This morning i started with re-flashing the microSD and then re-inserting it into the farmbot while using my phone as a hotspot next to it. Meanwhile i used my laptop to connect to the farmbot-xxxxx network and access the configurator. Selected my phone hotspot (no advanced settings) and put in my account details.

This resulted in a good connection and a working farmbot. This leads me to the conclusion that it is a problem with my wifi network/repeater that does not allow the farmbot to connect when on this network.

Now i’m onto debugging/experimenting around with the network to see if i can get it to have a (reliable) connection without having my phone next to it.

1 Like

@rme_2001 Glad to hear you’re getting closer. FarmBot does not officially help with LAN setup, but please do continue to post details and we (FarmBot staff) and other members of the community can make a “best effort” attempt to help you.

Hi @rme_2001,

A few things to check:

  1. It may be worth trying your WiFi again. For example, if you mis-typed your FarmBot Webapp credentials the first time then the device would indeed connect to your Wifi but it wouldn’t show up in the application.

  2. If your WiFi AP has a firewall capability, that of course is worth checking. I tend to disable my WiFi AP’s firewall because I have a firewall protecting my whole network and i like to have a single set of policies to manage.

  3. Another thing to consider is that the Raspberry Pi has pretty low-end WiFi. I made a 100 foot long Ethernet cable which gave me a good baseline that everything was working.

Then, I purchased a directional panel antenna. The model I chose was a Tupavco TP511 Panel Antenna 2.4 Ghz. At the time, I was trying to get a solid connection to my Farmbot and hence 2.4 Ghz made sense. And, this made a big impact. My signal strength indicator as measured on the Pi went from a few percent to over 25%. When looking from my AP management software, RSSI also went up considerably. However, the Raspberry Pi WiFi was still not reliable.

Finally, I used an EnGenius Enstation-AC (I had the original - the current model is Enstation5-AC). This is a single radio device (5 Ghz) so I am not getting any benefit of my panel antenna from it.
Since I have an access point outside already and the 5 Ghz radio has good omnidirectional antennas, I tried using only one endpoint of the Enstation. It has 4 modes of operation. I configured it as a client bridge which allows the device to act like a WiFi adapter. It connects to my Farmbot via Ethernet. After deploying the Enstation and connecting to the Raspberry Pi via Ethernet, my system has been solid. RSSI is measured at -51 dBm and the Enstation Pings are usually 2-4 ms.

If I were starting over, I’d skip the panel antenna, only because the Enstation is already a directional solution. If using one side of the Enstation wasn’t enough, I would use both sides of the Enstation.

BTW, there may be other comparable systems out there. I happened to have an Enstation already.

My wife tolerated the Ethernet cable running through our study, hall, bedroom, and out into the yard for about a month. I’m pleased to say we are done with that . . .

Jack

3 Likes

My Farmbot is on a hill behind our house. In order to improve the WiFi Signal I use a Linksys Mesh System that expands the coverage with separate Nodes. I then installated one of the nodes in a waterproof box next to my Farmbot (Amazon sells these boxes).

4 Likes

Very cool. I’ll have to check out the box. My AP is mounted in the open - which its designed for - but I think a box would provide longevity. And it looks cool :smiley:

1 Like

Here is the link from Amazon:
https://www.amazon.com/gp/product/B07RVN91WB/ref=ppx_yo_dt_b_asin_title_o09_s00?ie=UTF8&psc=1

$27.99

1 Like

After a busy few days, today i was able to spend more time figuring out what is going wrong.
My first step was to use two wifi repeaters (insteaf of one), not quite the mesh network, but it seems to be enough to give the farm bot a good network connection. This resulted in a strong connection, but farmbot still wasn’t able to connect to my.farm.bot

By accessing the logger on http:///logger i was able to see that now i’m left with the following message:
password auth failed: {:error, {:failed_connect, [{:to_address, {'my.farm.bot', 443}}, {:inet, [:inet], :nxdomain}]}}

This seems like a DNS problem, Since i have some experience with Linux/Unix and programming i decided to dive into Elixir/Erlang and see if i could debug it on the Farmbot self.

After setting up a SSH connection to the farmBot i used the following commands to reproduce a request to my.farm.bot

iex(farmbot@farmbot-0000000099f8ca5d.local)1> :httpc.request(["https://my.farm.bot"])

Which gave the following output

     {:failed_connect,
      [{:to_address, {'my.farm.bot', 443}}, {:inet, [:inet], :nxdomain}]}}

Then i decided to try a request to a device on the LAN network (in this case my router)

iex(farmbot@farmbot-0000000099f8ca5d.local)2> :httpc.request(["http://192.168.178.1"])
        {:ok,
         {{'HTTP/1.1', 200, 'OK'},
          [
            {'cache-control', 'no-cache, must-revalidate'},
            {'date', 'Tue, 07 Jul 2020 14:14:52 GMT'},
            {'accept-ranges', 'bytes'},
            {'etag', '"1536038092"'},
            {'server', 'lighttpd'},
            {'content-length', '9270'},
            {'content-type', 'text/html'},
            {'last-modified', 'Mon, 08 Jul 2019 14:57:17 GMT'},
            {'x-frame-options', 'SAMEORIGIN'}
           ],
          '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"\n

This works fine and fast. I also tried some other external requests (like google.com etc), all resulting in the nxdomain error.

This leads me to believe this is a DNS issue for any domain outside of my LAN. I’m currently trying to figure out how DNS resolving is done within httpc.request, so i can dig even deeper and eventually find the root cause.

1 Like

@RickCarlino Do you happen to know how httpc.requests resolves it’s domains?

iex(farmbot@farmbot-0000000099f8ca5d.local)74> DNS.resolve("google.com")
{:ok, [{216, 58, 214, 14}]}
iex(farmbot@farmbot-0000000099f8ca5d.local)75> DNS.resolve("my.farm.bot")
{:ok,
[
  'my.farm.bot.herokudns.com',
  {54, 152, 45, 100},
  {52, 201, 33, 182},
  {34, 227, 164, 168},
  {34, 196, 154, 11},
  {52, 203, 131, 51},
  {107, 21, 11, 91},
  {3, 223, 118, 45},
  {52, 1, 26, 21}
]}
iex(farmbot@farmbot-0000000099f8ca5d.local)76>

works fine. but

iex(farmbot@farmbot-0000000099f8ca5d.local)76> :httpc.request(["https://google.com"])
{:error,
 {:failed_connect,
  [{:to_address, {'google.com', 443}}, {:inet, [:inet], :nxdomain}]}}
iex(farmbot@farmbot-0000000099f8ca5d.local)77> :httpc.request(["https://my.farm.bot"])
{:error,
 {:failed_connect,
  [{:to_address, {'my.farm.bot', 443}}, {:inet, [:inet], :nxdomain}]}}

doesn’t.
This is really confusing me.

@rme_2001 We’ve seen this happen a lot when people put multiple switches onto a LAN. A quick look at the source code indicates that DNS.resolve/1 users Google’s public DNS servers. :httpc is using the DNS servers provided by your network settings, which I imagine are having some sort of configuration issue (I can’t help with that part, unfortunately).

Since 8.8.8.8 (Google’s public DNS) seems to work for you, you could try putting that IP into the NAMESERVERS section of configurator. There might be more issues beyond DNS after that.

@RickCarlino Solved it!

It seems it was indeed a DNS issue.
I viewed the nameserver config by using:

iex(farmbot@farmbot-0000000099f8ca5d.local)32> :inet.get_rc()
[
  {:host, {127, 0, 0, 1}, ['localhost']},
  {:nameservers, {192, 168, 178, 1}},
  {:resolv_conf, '/etc/resolv.conf'},
  {:hosts_file, []},
  {:lookup, [:file, :dns]}
]

This seems the DNS queries are sent to my router, which is where there seems to be an issue.
I then noticed that /etc/resolv.conf was a link to /tmp/resolv.conf
and used an SFTP client (WinSCP) to edit the /tmp/resolv.conf to contain:

nameserver 1.1.1.1

And soon after i see my farm.bot connecting to my.farm.bot.

The only thing that puzzles me, is that i’m sure i’ve put in 1.1.1.1 at in the advanced config options before. So as a sanity check i will now power off the farmbot and re-flash the microSD and see if putting 1.1.1.1 (or 8.8.8.8) into advanced options during seting is enough to make it work without further tinkering.

1 Like

@RickCarlino I think there might be an issue with the nameservers from the Configurator not being used properly.

Reproduction steps:

  1. Flash mircoSD with 10.1.2 image
  2. Put mircoSD in farmbot and power on
  3. Connect to farmbot-xxx network, open configurator
  4. Select access point, fill in psk.
  5. Only fill in 2 advanced settings: public key and nameservers value 8.8.8.8
  6. http:///logger shows error (probably hard to reproduce unless DHCP sends you the IP of a broken DNS server) :
password auth failed: {:error, {:failed_connect, [{:to_address, {'my.farm.bot', 443}}, {:inet, [:inet], :nxdomain}]}}
  1. SSH into farmbot
  2. Validate Farmbot config saved the 8.8.8.8:
iex(farmbot@farmbot-0000000099f8ca5d.local)1> FarmbotCore.Config.get_all_network_configs()
[
  %FarmbotCore.Config.NetworkInterface{
    __meta__: #Ecto.Schema.Metadata<:loaded, "network_interfaces">,
    domain: nil,
    id: 1,
    identity: nil,
    ipv4_address: "0.0.0.0",
    ipv4_gateway: "0.0.0.0",
    ipv4_method: "dhcp",
    ipv4_subnet_mask: "255.255.0.0",
    name: "wlan0",
    name_servers: "8.8.8.8",
    password: nil,
    psk: "<SNIP>",
    regulatory_domain: "NL",
    security: "WPA-PSK",
    ssid: "<SNIP>",
    type: "wireless"
  }
]
  1. See that 8.8.8.8 is not part of the inet nameservers:
:inet.get_rc()
[
  {:host, {127, 0, 0, 1}, ['localhost']},
  {:nameservers, {192, 168, 178, 1}},
  {:resolv_conf, '/etc/resolv.conf'},
  {:hosts_file, []},
  {:lookup, [:file, :dns]}
]
  1. See the contents of /tmp/resolv.conf
nameserver 192.168.178.1

I tried finding the cause in https://github.com/FarmBot/farmbot_os but i guess i’m too new to Elixir to figure out where nameservers get written/used.

A temporary solution for me is to manually edit /tmp/resolv.conf with any other DNS server IP as long as it’s not the broken DNS server in the router i got from my ISP.

Let me know if i can do anything to be of assistance in figuring out why the configurator nameserver value does not seem to be used.

When you ran that, it returned that your IP address is 0.0.0.0, which is definitely wrong.

I am using a self-hosted WebApp with local DNS. From memory: when you do the initial setup of the FarmBot network, you can have it automatically get an IP (DHCP) or set it statically. If you set it statically, you can also give an IP address for DNS. If you set it via DHCP, the DHCP server sends the FarmBot the DNS IP to use. So you could set the network up statically, or you could log into your router and in the DHCP server section, tell it to give out 8.8.8.8 for DNS.

Actually this is Ok. For DHCP configured IPv4 address, the persisted Config is not updated with the actual lease detail.

1 Like

This is your big clue. Choosing dhcp for your IPv4 addressing method means that you hand control of /etc/resolv.conf completely to VintageNet inside FBOS.
Any edit of resolv.conf will be wiped.

As @jebba commented, you’ll need to “fix” the DHCP Server ( in your gateway (?) ) to issue correct addresses for your Farmbot LAN.

static IPv4 addressing works just fine for wireless ( I’m using it now ) but you do need to Configurate a NameServer and a Gateway.

|

I counted 3 settings :slight_smile: Regulatory Domain

This might well the case, but in my opinion then the Nameserver configuration should then only be visible when selecting static IP in the advanced options. Notice that @RickCarlino also did not mention that setting a static IP was required.

While i understand the the best option would be to adjust the DNS IP that the DHCP server sends to the client. Unfortunately, the DHCP server is on the router from my ISP, which is kind of a black box and only allows me to turn DHCP on/of and set the IP range available. No settings for DNS available there.
I did not have previous problems with it, but this makes me consider turning DHCP off on the ISP router and running a raspberryPI or equiv. with DHCP server that i have full control over.

No I missed that. IMHO static addressing is just a workaround.

In my limited experience here in AU with my ISP I’ve not seen their gateway hand out Private IPv4 addresses that you can’t configure to suit your local LAN !