Having trouble connecting (Code 26)? TCP Port requirements in FBOS 13.0.1 have changed

FarmBot OS v13.0.1 incorporates updates that will improve connection reliability. If you had a FarmBot setup that recently stopped working after a FarmBot OS update, you may need to enable access to TCP port 8883 on your local area network. This previously unused port is now required to operate FBOS.

Please see this guide for a list of required TCP ports.

2 Likes

Hello @RickCarlino, hoping you can assist. The auto-update to 13.0.1 must have failed back on March 4th because our FarmBot was offline for 9 days (seemed to sync with logs and connectivity issues). Ironically, the 13.0.1 was supposed to improve reliability and it’s just the opposite now. The version before 13.0.1 had no issues, at least none that stopped our testing . I re-flashed the microSD card this past Saturday and all seemed to be OK (was able to run a sequence, etc…). Later that night, once home, said FarmBot was offline and was flickering between sync and sync unknown. Our network team reported that attempts to resolve DNS at 4.4.4.4 and 8.8.8.8 (Google’s DNS servers) were being attempted (not allowed) even though DHCP was used. In short, should be using our DNS vs. others. Any ideas? At this stage, we have checked ports in the security documentation and have disabled auto-update. Since the previous version was working fine, would feel more comfortable reverting back to last one. When we access os.farm.bot, only see 13.0.1. Thanks in advance for any assistance.

@SGTX

There’s no indication of global problems with the current FBOS release, but there is a new port requirement (8883).

This sounds a lot like your schools network has port 8883 blocked.

Are you sure that was us and not some other device? We don’t use either of those.

Are you certain you weren’t reading old documentation for FBOS v12? The most recent port list can be found here. As mentioned, port 8883 is the new one that some schools have not added to the allow list yet.

I’m certain we will be able to fix the issue, but please do let me know if you’re still having trouble after enabling port 8883. We won’t support old versions after 60 days of a new release (the documentation explains why we don’t allow old versions on the official server).

If you are absolutely certain that you have port 8883 enabled and are still hitting issues, let me know and I can try to remote in to your device to see what is going on. Please provide your device ID if it gets to that point.

Thanks @RickCarlino, appreciate your help as always. I have no explanation re: the 4.4.4.4 and 8.8.8.8 but was connected to the IP address. We’re back in business. Port 8883 was the issue. I must have been looking at the incorrect documentation. Also, thanks for the update re: 60-days and old versions. In this case, we were unaware of the port requirement in 13.0.1. When FB attempted the auto-update, port 8883 wasn’t open. Since I couldn’t reset and activate the Configurator from the Web app (or forced power off/on aka: unplugging device), flashing the microSD was the only option.

1 Like

Always happy to help @SGTX :tada:.
Glad that your device is back online.

Thanks @RickCarlino, we’re glad it’s back. Quick question… is FarmBot using any fixed DNS settings at all (e.g. OpenDNS @ 1.1.1.1)?

@SGTX Not that I’m aware of. FBOS is a Linux system built on top of hundreds if not thousands of Open Source networking libraries, so it’s possible, though unlikely, that one of them is trying to contact a hard-coded DNS.

To be sure, I have contacted some of the maintainers of our WiFi library. I can’t guarantee that they respond, and the likelihood that they are using a hard coded DNS server is extremely low (this is unheard of to me, but not impossible).

I will let you know if they respond to my inquiry.

@SGTX I just found out that in the early stages of initialization, the WiFi setup wizard has a library that will ping 1.1.1.1 to see if the internet is up. This code is not maintained by FarmBot, Inc. I believe that this can be overiddden (have you tried changing the “NAMESERVERS” option in advanced network settings?)

I’m still awaiting a reply from the maintainer.

@SGTX Quick question about the unexpected requests to public DNS servers: Can your IT department confirm that actual DNS requests were made, or did they just assume that since the IP was a well-known DNS server, we must have been trying to use it as such?

After talking to the library maintainer some more, I found that although the library does connect to certain well-known IP addresses, it is not trying to actually use DNS. It is just trying to connect to a server that has a stable IP. This is used by the library to confirm that there is an internet connection without needing to use DNS (since DNS could possibly be misconfigured locally).

I hope this gives you a better understanding of the situation.