Problem with Wi-Fi connection between Model S and Ubiquiti AP AC Pro Access Point

[berkeley_ecar]

I own a Mar 2017 Model S 90D. Several months after purchase, I updated my home wireless setup with two Ubiquiti AP AC Pro access points (APs), one on my townhouse, and another in the garage, primarily to support the Model S. The Model S and the garage AP communicated brilliantly for at least 19 months, but somewhere around Nov. of 2019, the Model S started behaving as if it was not connected to a Wi-Fi access point, although the web-based administrative interface to the Ubiquiti equipment showed the garage AP as being connected to the Model S, with excellent signal strength, and showed hard numbers for bytes exchanged in both directions. The garage AP has continued to work flawlessly with all other Wi-Fi capable devices that I and visitors have used. Some research using Google and the web, as well as this posting in the TMC forum, as well as a posting I made in a Ubiquiti user's forum, led me to experiment with various settings for the AP, to no avail. Although I strongly suspect that something must have changed in the Model S, perhaps as a consequence of a software update, I have had no success in convincing my local Tesla Service Center that this is a Tesla-related problem which they should help solve -- and in fact got billed $200 for a (totally unhelpful) Mobile Service visit when I complained about the issue. Another Model S owner on the Ubiquiti forum has experienced similar problems. Are there others out there who are using Ubiquiti APs, who have either figured out a clean fix, or might want to participate in a group effort to get Tesla to provide a fix? Apologies in advance if I have somehow missed a definitive fix somewhere in the TMC forum (references to Ubiquiti are scattered and numerous, but I have not found anything addressing this particular issue). I have had to resort to going to either friends' homes or my local Service Center to get the Wi-Fi needed to download firmware updates. Thanks in advance for any helpful responses. I'm grateful to have my vehicle, and want Tesla to succeed, so let's please orient this thread toward positive problem solving, and not let it turn into yet another flame war.

 

[DOCAL]

Unfortunately I don't have a solution for you, but I can tell you what's working for me.
I have the same sort of setup you described, both at home and work, and don't have any problems at either location.

I assume you have MCUv1 so will only be operating on the 2.4Ghz band. Which may well be saturated if you've got enough neighbors around you with wifi setup. The first thing I'd do is have the AP near the car do a scan, and look for the cleanest channel in the 2.4Ghz band and lock the AP to that channel.

The settings I have on my setup (and also work) are the defaults. 2.4Ghz channel width is 20, transmit power is on auto.
I have meshing disabled as both APs are hard wired.
I'm using WPA personal, CCMP is on. Under advanced/misc, refresh secret and combine SSID is on, everything else is off.
Wifi AI is off, hotspot 2.0 is off.

 

[luckyj]

I have an AP AC Pro too. So far I have not seen any issues. I use the 2GHz side, which I'm guessing you do too. I have no special settings in my AP. I am on the latest firmware from Ubiquity. My car is currently on 2020.12.10.

What's the "Experience" for that client? This may differ significantly from the Signal.

I assume you've already done an RF environment scan on the AP?

 

[boaterva]

The first thing to have done is forget the wifi setup in the car and reconnect to it from scratch. You don’t state this obvious troubleshooting step but I assume either you or Tesla mobile service did this?

I point this out since all your other wifi clients are fine and the other posters are using the same hardware with no issues (network engineer and tech support person here ).

I also had an MCU1 car and had a few issues with wifi. I also assume you have good signal strength in the garage (since the AP is in the garage)? At one point I had to experiment with mirrors folded and unfolded as they are somewhat directional.

 

[whitex]

First, have you rebooted both the car and the AP and problem persists? I know it sounds like an obvious thing, but I like to start from a known baseline.

Debugging this would take forever to document, as I found that Tesla WiFi implementation is not great and definitely not tested exhaustively (both MCU1 and MCU2) - WiFi is not Tesla specialty, so it seems they just slapped on something inexpensive 3rd party solution they found.

I use Ubiquity in my house, including AP-AC-Pro in the garage. I've had multiple issues with our cars connecting, sometimes things would work for months and then stop. Similar to what @DOCAL above, I can share with you the solution that I ended up after trying all kinds of things, which "knock on wood" has been working reliably (well, every few months I notice the MCU2 doesn't connect, but a two thumb salute fixes it for another few months). Basically I ended up setting up two isolated networks, one per car, and enabling them only on the garage AP (so they don't get confused with roaming or other such features Tesla probably never tests, or connect to the far one it hears but not be able to transmit back far enough). The network for MCU1 is only enabled on 2.4GHz band, that's because some time around MCU2 release Tesla messed up the WiFi firmware so that MCU1 thought it had 5GHz radio, so it would tell my AP, and the AP would attempt band steering by disconnecting the MCU1 from 2.4GHz since it had full strength signal (that indicates to the AP that the device is close, so band steering will issue a disconnect, hoping the device will reconnect on 5GHz) - that would result in a constant Wifi connect-disconnect looping (you can see it sitting in a car, the main screen will show you alternating WiFi/LTE connectivity). The network for MCU2 has both bands enabled, so the MCU2 can connect to 5GHz (which it doesn't do every time, but I don't really care if it wants to camp out on 2.4GHz instead). The other thing I did is set the garage AP transmit power to 18dbm as with max power sometimes when I parked next to a mailbox down the street, the car would see the network but doesn't have WiFi good enough to transmit back that far. Lastly, I setup each of the car networks with their own subnet and added some firewall rules to prevent any traffic between any of the car networks and any other network in the house (including the other car network).

So in your case, I would just setup a separate dedicated wireless network for the car (make a guest network for max isolation), with its own subnet, then enable it only on 2.4GHz and only on AP in the garage, disable fast-roaming and any advanced features. At least with Unifi it's relatively easy to add such new networks, no physical wiring changes needed.

 

[rooter]

No problems here for years with a UniFi AC Pro, with Feb 2015 MCU1, original Parrot, and firmware 18.36.2. Car associates, reaches into the LAN DHCP VM for an IP and gets it. Traffic results. (although blocked by Shorewall most of the time)

Exactly what is the problem? Is it associating but not getting IP? Are you running a DHCP server in the Pro or elsewhere? Do you see Tx or Rx errors? Check the UBNT logs.

 

[berkeley_ecar]

First off, my sincere thanks for your helpful thoughts thus far (and apologies for not mentioning the last two very informative messages, which arrived after I composed what follows -- I will
respond to those last two postings a bit later, and try out whitex's suggestions!).

The first thing to have done is forget the wifi setup in the car and reconnect to it from scratch. You don’t state this obvious troubleshooting step but I assume either you or Tesla mobile service did this?

It's always good to go back to the basics (I can tell you've done tech. support ). Yes, I have asked the WiFi setup on the S to "forget" my Wi-Fi network, and re-entered the SSID and password so many times I'm surprised I still have fingerpads left to type with.

I also had an MCU1 car and had a few issues with wifi. I also assume you have good signal strength in the garage (since the AP is in the garage)? At one point I had to experiment with mirrors folded and unfolded as they are somewhat directional.

There is a clear line of sight of about 15' from the AP to the passenger mirror of the car, and signal strength was always super high while Wi-Fi was still working.

I assume you have MCUv1 so will only be operating on the 2.4Ghz band. Which may well be saturated if you've got enough neighbors around you with wifi setup. The first thing I'd do is have the AP near the car do a scan, and look for the cleanest channel in the 2.4Ghz band and lock the AP to that channel.

Excellent suggestion. I did a scan last night (Sunday) and again this morning. Both show a pretty uncongested situation (see image).


The Model S seems to connect to the AP using channel 4 (the least congested) most of the time (according to the UniFi Controller interface -- the Model S indicates that it never connects at all). Here is an image of the stats for the Model S from the Controller, indicating upload/download of gigabytes of information (over what time period is unclear).

The settings I have on my setup (and also work) are the defaults. 2.4Ghz channel width is 20, transmit power is on auto.
I have meshing disabled as both APs are hard wired.
I'm using WPA personal, CCMP is on. Under advanced/misc, refresh secret and combine SSID is on, everything else is off.
Wifi AI is off, hotspot 2.0 is off.

Here is where I must admit I find aspects of the Controller interface confusing. I am also using channel width of 20 for the 2.4GHz band, with auto transmit power. Meshing was enabled but I turned it off (with no effect on the car). I don't recall where to set the authentication but believe I was using WPA2? I do not know what CCMP refers to, and can not find it in the interface, nor where "refresh secret," "combine SSID," "WiFi AI," and "hotspot 2.0" are controlled. I do recall somehow turning off public display of my SSID, as an effort to discourage pranksters/hackers (thus one has to know the SSID and type it in manually to try to connect the first time).

What's the "Experience" for that client? This may differ significantly from the Signal.

I've rarely seen it dip below 100%, and never below 96%.


Thanks, all. I remain baffled.

 

[whitex]

The Model S seems to connect to the AP using channel 4 (the least congested) most of the time (according to the UniFi Controller interface -- the Model S indicates that it never connects at all).

Fyi, for 20MHz 2.4GHz band channels, best practice is to stick to channel 1,6 or 11. By using channel 4, you overlap with 1,2,3,4,5,6,7,8 (you can see it in your picture). With channel 1 for example, you'd only overlap with 1,2,3,4,5.

Also, for unifi product line, "auto" power means maximum power (they never implemented any smarts for that).

 

[Obsoletion]

I have the same issue and know what the problem is...

I have a 2014 Model S(MCU 1), 2017 Model S (AP2 MCU1), 2020 Model X (AP3 MCU2) and have 2 Model 3's at the office. The network setup is (at home and my office)Ubiquiti Edgerouter Pro-8 and UAP-AC access points. One access point ceiling-mounted in the garage right above the cars. Been the same network infrastructure for many years and never had an issue connecting with the 2014 or 2017 Tesla's on this network/wifi setup. When I got the Model X last November I noticed right when I brought it home I couldn't connect. I am parked right next the 2017 model S and it is connected fine. Assumed the car had an issue and took it to the service center the next day and right as I put it in park, it connected to the Tesla wifi. Huh. Took it to the mall and it connected to the mall wifi. Took It home and it wouldn't connect. Took it to the office, wouldn't connect. Asked about the Models 3's at my office, they can't connect to the office network but no issue with cable company provided router/wifi. I tried everything, firmware updates, setting changes, googled and tried different things for hours. Finally decided to pull out an old netgear router/ap and plugged it in and made a test wifi network, and the model X connected right away. The next weekend we took it to our 2nd home which has the same Ubiquiti access points but a cradlepoint router and it connected right up again. The next trip to the 2nd home I took a spare edgerouter and swapped out the cradlepoint, and the car would not connect.




TMDR: For me, it turned out to be an issue with Ubiquiti edge routers, not their access points. So what router are you using?

 

[SeminoleFSU]

Haven't read this whole thread (sorry) but try using just alphanumeric in your SSID name and wifi password

 

[luckyj]

Channel 4... Using 40MHz channels is asking for trouble in most areas. Have you tried going to 20MHz channels?

 

[powaking]

2 things that come to mind is have you tried disabling the Tesla client from using mesh or try disabling fast roaming? I have some old devices that just do not like it when I have Fast Roaming enabled.

Also are you limiting your DHCP ip pool or have you assigned an IP to your Tesla's wifi adapter?

 

[berkeley_ecar]

Having posted to several online forums about a very annoying Wi-Fi problem involving my Tesla Model S and my home network, I wanted to provide a summary of our investigations and the solution we found for the problem, in the hope that it may be of help to others. I shall also be communicating with Tesla. My thanks to everyone who chimed in with suggestions for a fix.

Quick summary: the problem was caused by a subtle configuration error in our gateway router, which interacted with some poor design decisions buried in Tesla's Wi-Fi software, which constitute a bug in my opinion.

DESCRIPTION OF TESLA WI-FI PROBLEM, AND THE SOLUTION

The following describes a problem encountered with a Tesla Model S (firmware 2020.24.6.1) attempting to use a Ubiquiti AC AP Pro Wi-Fi access point. I provide this in the hope that it may help others with similar problems. Apologies for any imprecision of language here, as I am not a Wi-Fi expert. The problem was resolved by careful inspection of packet traffic on my internal network (performed by a capable and determined colleague) as well as reviewing the settings on the gateway router for my internal network:

THE PROBLEM

1. The Tesla operator enters a SSID and password for the Wi-Fi wireless network to be used, using the form provided on the MCU display. Acting as a Wi-Fi client, the Tesla attempts to establish an "association" with the specified access point (AP) via radio.
2. The AP has been configured to use the local network's gateway router to obtain the information it provides to Wi-Fi clients in providing a "lease" (including an IP address for the client, the lease duration time, and a list of DNS servers needed to resolve host names to IP addresses). The AP "associates" with the Tesla and provides this information. The connection "spinner" on the Tesla's MCU display turns green for a fraction of a second.
3. The Tesla, using the local IP address assigned to it by the gateway router via the AP, immediately tries to communicate with a service on the public Internet, but because the first DNS server on the list provided by the AP is set up to resolve only addresses on the internal network, the name resolution fails.
4. The Tesla then goes to the second DNS server on the list, and at this point it is unclear what happens -- some packets are exchanged, then the Tesla appears to give up, drop its AP "lease," and disassociate from the AP, and the MCU displays a popup message:
   Could not join [SSID of Wi-Fi network shown here]
   The Internet is unreachable. Please check your
   firewall setting and Internet connection
   Except for the fleetingly green connection indicator on the MCU display, it would appear to the casual user that the Tesla could not connect to the AP at all (not true). During the entire process to this point, the Tesla Wi-Fi displays on the MCU indicate a low signal strength associated with the AP.
5. Thereafter, the operator can leave the car, but the Tesla continues trying to re-associate with the AP every minute or so, with small amounts of packet traffic in both directions on the internal network (essentially, repeating steps 2-4). This was only evident from inspecting packet traffic.

THE SOLUTION

The problem was solved by exchanging the order of the first and second DNS servers provided by the gateway router to the AP. After this change, when the Tesla first attempts to resolve public network IP addresses, the resolution works and the Tesla remains happily associated with the AP, and fully functional on the network. All MCU Wi-Fi displays then show the AP to be communicating with high signal strength. Thus, this aspect of the problem was due to a
gateway router configuration error on our part. But read on...​

THE UNRESOLVED (TESLA) PROBLEM

A large number of other devices were successfully used with the original setup of the gateway router and AP; when the initial DNS access failed, they quickly and invisibly moved on to the second DNS server in the list, and established full access to the public Internet via the AP. The only device of the many we tested that failed to do so was the Model S. Why the Tesla Wi-Fi setup failed is a mystery; it did communicate with the secondary DNS server; perhaps a timeout of some sort got triggered? Perhaps a knowledgeable Wi-Fi expert reading this can clue us in. This behavior occurred both under my former MCU1/HW2 ("ParrotSA" Wi-Fi hardware) setup as well as my current MCU2/HW3 ("LgInnote" Wi-Fi hardware) setup, thus I assume this is likely a software (not a hardware) issue. This Wi-Fi behavior is sufficiently idiosyncratic as to constitute a "bug" in my estimation. Tesla should address this problem by updating their WiFi software in a future firmware update. It's probably a simple fix, and it should make the Tesla's Wi-Fi system much more robust. The wording of the MCU popup message is also somewhat misleading, and should be made much more specific, as in:

Established a connection with [SSID of Wi-Fi network shown here]
but the DNS server information provided via Wi-Fi does not allow
successful access to the public Internet. Please check your
firewall/router settings and Internet connection.
[better yet: include the offending DNS server address]​

 

[bmah]

Nice analysis @berkeley_ecar!

Although I'm wondering what you expect the Tesla to do in this situation? If you have a normal UNIX computer, and it tries to do a DNS resolution that returns an error for a non-existent name, it's not going to try every configured nameserver until it gets a real answer. Specifying multiple nameservers guards against a nameserver being down or unreachable (no answer)...it's not supposed to support multiple nameservers that can give different answers.

To me it's more confusing that other devices worked, than that the Tesla failed.

Bruce.

 

[berkeley_ecar]

I'm an empiricist: if ten devices work fine in a given setting, and one does not, it's the one that is the outlier, not the ten. Tesla should make its Wi-Fi support more robust.

 

[bmah]

I'm an empiricist: if ten devices work fine in a given setting, and one does not, it's the one that is the outlier, not the ten. Tesla should make its Wi-Fi support more robust.

Well, I can't argue with the results you got, it somehow doesn't fit my mental model of how DNS resolution works. Anyways, you got things working, so good on you!

This reminds me of another weird thing in Tesla's DNS client resolver library. It had something to do with not being able to handle response packets of a certain size. Tesla did fix that one, I think. There was a thread on that here on TMC a few years ago.

Bruce.

 

[whitex]

Nice analysis @berkeley_ecar!

Although I'm wondering what you expect the Tesla to do in this situation? If you have a normal UNIX computer, and it tries to do a DNS resolution that returns an error for a non-existent name, it's not going to try every configured nameserver until it gets a real answer. Specifying multiple nameservers guards against a nameserver being down or unreachable (no answer)...it's not supposed to support multiple nameservers that can give different answers.

To me it's more confusing that other devices worked, than that the Tesla failed.

Bruce.

I don't think you're correct here. I just tested it on my Windows box. "Unable to resolve" is not considered an conclusive answer - it's treated similar as if the DNS server cannot be reached. If a name cannot be resolved on one DNS server, Windows it will try the other DNS servers. Now, if a DNS responds with an actual IP address, and that address is bad, then yes, Windows will not keep on trying other DNS servers.

I don't have a Linux box handy configured to talk to multiple DNS's where each can resolve exclusive internal domains which the other server don't know about (how I tested it in Windows), but I would be surprised if it just failed if the first dns returns "unable to resolve".

My guess is the aforementioned Tesla behavior is just a poorly written "internet connectivity check" code, never exhaustively tested for corner cases like this.

 

[rooter]

I finally evicted Ubiquiti when their latest control software -mandates- that you log in to their servers. Why do they want to know this? What are they doing with this information? What goes on in my LAN is none of anyone's business but mine.

So I tried a Grandstream GWN7630 which has the controller built-in and can handle up to 256 slaves, but the latest firmware is just not ready for Prime Time, and their Support was unresponsive.

I ended up with a (discontinued) Cisco WAP581, which is superb. It is $200 for one AP but that beats all hell out of their Aironet or Catalyst lines which are $500. The WAP581 does what it should and wifi calling finally works. Another candidate was Engenious for $300.

 

[bmah]

I don't think you're correct here. I just tested it on my Windows box. "Unable to resolve" is not considered an conclusive answer - it's treated similar as if the DNS server cannot be reached. If a name cannot be resolved on one DNS server, Windows it will try the other DNS servers. Now, if a DNS responds with an actual IP address, and that address is bad, then yes, Windows will not keep on trying other DNS servers.

I don't have a Linux box handy configured to talk to multiple DNS's where each can resolve exclusive internal domains which the other server don't know about (how I tested it in Windows), but I would be surprised if it just failed if the first dns returns "unable to resolve".

My guess is the aforementioned Tesla behavior is just a poorly written "internet connectivity check" code, never exhaustively tested for corner cases like this.

I just did some checks on a test machine (FreeBSD 11.4-RELEASE). It works the way I expected. A failure to resolve (specifically a NXDomain response) does not cause the resolver to try the next configured nameserver. However, if there's a timeout or an ARP failure trying to reach a nameserver, it will try the next configured nameserver. I'm going to wave my hands in the air and claim that most Linux resolvers will do something similar. I've learned through experience (which predates Tesla) to be sure that all the nameservers that could be queried by a host need to return consistent data...to do so otherwise is asking for problems.

A couple minutes of searching led me to an article that states that Windows does something more complex, which might explain differing results.

I don't know what Tesla is using for their client resolver library...I would have guessed it's something that comes with their Linux distribution, but I have no authoritative (haha authoritative DNS get it?) information on that. The behavior that OP described is kinda consistent with my guess but I'm not sure.

Well that was fun.

Bruce.

 

[SmartElectric]

Finally decided to pull out an old netgear router/ap and plugged it in and made a test wifi network, and the model X connected right away

I have put in an old Tomato firmware wifi router in my outbuilding/garage and have only the Tesla connected to it, worked great.
Avoids connecting to house wifi and it's security and vpn's, etc.
Sometimes simpler is better.