Issue - "Unable to connect" when connecting to WiFi (SOLVED)

[TheSteelRider]

And here's the LAN DHCP log:

Apr 13 02:28:16 2021dhcpdinfo<158>192.168.1.204 is leased for 86400 seconds, renew in 0 seconds, rebind in 0 seconds
Apr 13 02:28:16 2021dhcpdinfo<158>DHCPACK on 192.168.1.204 to 78:55:cd:e5:a2:03 (mdm9650-tcu) via br-lan
Apr 13 02:28:16 2021dhcpdinfo<158>DHCPREQUEST for 192.168.1.204 from 78:55:cd:e5:a2:03 (mdm9650-tcu) via br-lan

Looks like the same behavior those of us with Ubiquiti USG routers are seeing ... the Mach E requests a DHCP address, is given one, then does nothing with it and gives up.

See this post for my trace: https://www.macheforum.com/site/thr...en-connecting-to-wifi-solved.3044/post-122313

Sponsored

 

[dml105]

Looks like the same behavior those of us with Ubiquiti USG routers are seeing ... the Mach E requests a DHCP address, is given one, then does nothing with it and gives up.

See this post for my trace: https://www.macheforum.com/site/thr...en-connecting-to-wifi-solved.3044/post-122313

You're still dealing with the issue, right? No solution?

 

[TheSteelRider]

You're still dealing with the issue, right? No solution?

Correct. If you read back in this thread, I have devised an experiment to substitute out a different DHCP server, but unfortunately that is enough churn and work on my network I have been unable to attempt it (I need to be careful, my work from home depends integrally on my network, and I need to be available 24x7 on my corporate network at the moment).

 

[dml105]

Correct. If you read back in this thread, I have devised an experiment to substitute out a different DHCP server, but unfortunately that is enough churn and work on my network I have been unable to attempt it (I need to be careful, my work from home depends integrally on my network, and I need to be available 24x7 on my corporate network at the moment).

Same. If I upset the network for my new toy, and break the Kindergarten downstairs, I'll never hear the end of it.

For a network running so smoothly with at least 50 devices coming and going, I'm really surprised to have this much trouble with the mach-e.

 

[methorian]

Could always use an old Wifi router to make a new network? If any of you with issues has one laying around...

 

[Finkerton]

Same. If I upset the network for my new toy, and break the Kindergarten downstairs, I'll never hear the end of it.

For a network running so smoothly with at least 50 devices coming and going, I'm really surprised to have this much trouble with the mach-e.

I mean it's not that surprising. "Hey, it works with my WRT54G!" "SHIPIT"

 

[OldEVGuy]

I just got my MME 2 days ago. I’m not able to connect to my home WiFi network, or even Bluetooth. My network is using a Netgear Orbi mesh network. Both the modem and main router are in the garage with MME, so the signal is excellent. Since I can’t connect to Bluetooth either, does this sound like a connectivity issue the dealer needs to address?
Thanks!

 

[dml105]

Could always use an old Wifi router to make a new network? If any of you with issues has one laying around...

This has not worked for me.

 

[hitchhiker]

Still a couple days before I bring my Mach-e home for good, but I've got it here for an overnight test drive, and went deep down the rabbit hole on this.

I'm also using a Ubiquiti USG and could not get it to connect to any of my networks. My primary network DHCP is served by my Synology NAS, and IoT/guest/etc DHCP is served by the USG. I ran into this issue with both.

At least in my case, the problem is DHCP option 119, domain-search. This is only needed when you want your DHCP server to send multiple domains as a DNS search path.

Clearing the domain name setting on either platform allows the Mach-e to connect for me. For Unifi, edit the network you're connecting to, scroll down to Domain Name, and clear any value in the box. On Synology, go to DHCP settings, edit the appropriate interface, and clear the domain name there.

If you never use short hostnames and always use FQDNs when connecting to resources in your local network, you should be fine to just leave it that way. Doing this will also cause the DHCP server not to send the domain-name option, so you'll have no search suffix at all.

I wanted to be a bit more selective. Under the hood on the Unifi side, a perl script generates a dhcpd.conf for ISC dhcpd. There's no way to make it omit the domain-search option. While I was digging, I noticed that the Unifi also supports dnsmasq as a DHCP server, and the config generator for this one doesn't include the offending option. You can switch to dnsmasq using a custom config.gateway.json. This goes on your Unifi controller, check the linked article to find out where. In my case it was /usr/lib/unifi/data/sites/default/config.gateway.json. Either create the file with the following content, or add this to your existing config:

{
  "service": {
    "dhcp-server": {
      "use-dnsmasq": "enable"
    }
  }
}

Then run a force provision on your USG, and when it's done try connecting your Mach-e.

There may be a way to selectively disable the domain-search option on the Synology, I poked around a bit but ultimately didn't bother as it's getting late and I didn't need this functionality. I do know that you can create extra dnsmasq config in /etc/dhcpd/dhcpd-vendor.conf and it will be added to the end of the generated config (I use this technique to add options needed to netboot Raspberry Pis).

Hopefully this fixes the problem for some of you, or at least sets you on the right path!

 

[Finkerton]

At least in my case, the problem is DHCP option 119, domain-search. This is only needed when you want your DHCP server to send multiple domains as a DNS search path.

Clearing the domain name setting on either platform allows the Mach-e to connect for me. For Unifi, edit the network you're connecting to, scroll down to Domain Name, and clear any value in the box. On Synology, go to DHCP settings, edit the appropriate interface, and clear the domain name there.

If you never use short hostnames and always use FQDNs when connecting to resources in your local network, you should be fine to just leave it that way. Doing this will also cause the DHCP server not to send the domain-name option, so you'll have no search suffix at all.

Amazing writeup, thank you!

I tested this out by removing this option entirely and by using "home.com" instead of "home" as I had it before. It doesn't work with "home.com"; it only works with removing the value entirely (but it actually works!).

 

[hitchhiker]

Amazing writeup, thank you!

I tested this out by removing this option entirely and by using "home.com" instead of "home" as I had it before. It doesn't work with "home.com"; it only works with removing the value entirely (but it actually works!).

Yup, it looks like any presence of option 119 in the response will cause it to fail, regardless of value. This DHCP option just controls the DNS search path on clients. If you tried to hit "www" and your search path is "home.com", it would try to resolve "www.home.com". With no search path, you'd just always have to use the full "www.home.com". Normally, DHCP option 15 is used to specify a single domain name. Option 119 is used to be able to specify multiple domains in this path. The problem here is these implementations always set option 119 even for a single domain.

My home network is nerdy and abnormal so I wanted to keep my domain suffix path via option 15. Unless you are running things like internal web servers, most home networks should be OK without this. Things like printers, NAS servers etc typically rely on other mDNS (or WINS) based resolution.

TL;DR - If it doesn't seem to be causing you any problems, you should be fine just leaving this field empty for now.

 

[Finkerton]

Yup, it looks like any presence of option 119 in the response will cause it to fail, regardless of value. This DHCP option just controls the DNS search path on clients. If you tried to hit "www" and your search path is "home.com", it would try to resolve "www.home.com". With no search path, you'd just always have to use the full "www.home.com". Normally, DHCP option 15 is used to specify a single domain name. Option 119 is used to be able to specify multiple domains in this path. The problem here is these implementations always set option 119 even for a single domain.

My home network is nerdy and abnormal so I wanted to keep my domain suffix path via option 15. Unless you are running things like internal web servers, most home networks should be OK without this. Things like printers, NAS servers etc typically rely on other mDNS (or WINS) based resolution.

TL;DR - If it doesn't seem to be causing you any problems, you should be fine just leaving this field empty for now.

Yep -- I'm also a (semi-lapsed) home network nerd as I used to deal with networks day in and day out in my job. I didn't really dig into this myself because, honestly, DHCP is something I used a lot but the intricacies of it were never my specific forte -- I dealt more with Ethernet, and TCP/IP, DNS, and BGP. As a perfect example, until you mentioned it above, I hadn't realized (or had forgotten) there were two different DHCP options controlling domain names. It makes total sense now that I know it's there, but I likely wouldn't have caught that detail.

Thanks for catching it :-D

 

[kf_man]

@hitchhiker Thanks for digging into this! I had done some initial research and was planning to try out DNSmasq for DHCP, but haven't had the time to explore it. For now I've just removed the domain setting from my IoT network and the car connected immediately! How has your experience been with DNSmasq? I found the beta forum post from 2 years ago where they suggested trying it out, but it seems like they must have decided it wasn't worth the effort.

It seems like there's enough information to pass along to Ford, does anyone know the best way to do so?

 

[SoriceConsulting]

I get my MME in about a week and have been reading this thread for ideas. Hoping that the car likes my setup...

I have Unifi equipment as well (USG, CloudKey, Switches and AP's). However, I am using my Windows Server 2019 for DHCP (10.9.8.x). Also have a segregated test network (on 10.0.0.x) that has DHCP handled by (depending on which is active) one of several Server 2016 VMs running under Hyper-V.

I'm hoping my MME will like my 10.9.8.x network. If anyone has worked with something resembling this type of setup I'd love to hear of your horror stories experiences!

 

[TheSteelRider]

Still a couple days before I bring my Mach-e home for good, but I've got it here for an overnight test drive, and went deep down the rabbit hole on this.

I'm also using a Ubiquiti USG and could not get it to connect to any of my networks. My primary network DHCP is served by my Synology NAS, and IoT/guest/etc DHCP is served by the USG. I ran into this issue with both.

At least in my case, the problem is DHCP option 119, domain-search. This is only needed when you want your DHCP server to send multiple domains as a DNS search path.

Clearing the domain name setting on either platform allows the Mach-e to connect for me. For Unifi, edit the network you're connecting to, scroll down to Domain Name, and clear any value in the box. On Synology, go to DHCP settings, edit the appropriate interface, and clear the domain name there.

If you never use short hostnames and always use FQDNs when connecting to resources in your local network, you should be fine to just leave it that way. Doing this will also cause the DHCP server not to send the domain-name option, so you'll have no search suffix at all.

I wanted to be a bit more selective. Under the hood on the Unifi side, a perl script generates a dhcpd.conf for ISC dhcpd. There's no way to make it omit the domain-search option. While I was digging, I noticed that the Unifi also supports dnsmasq as a DHCP server, and the config generator for this one doesn't include the offending option. You can switch to dnsmasq using a custom config.gateway.json. This goes on your Unifi controller, check the linked article to find out where. In my case it was /usr/lib/unifi/data/sites/default/config.gateway.json. Either create the file with the following content, or add this to your existing config:

{
  "service": {
    "dhcp-server": {
      "use-dnsmasq": "enable"
    }
  }
}

Then run a force provision on your USG, and when it's done try connecting your Mach-e.

There may be a way to selectively disable the domain-search option on the Synology, I poked around a bit but ultimately didn't bother as it's getting late and I didn't need this functionality. I do know that you can create extra dnsmasq config in /etc/dhcpd/dhcpd-vendor.conf and it will be added to the end of the generated config (I use this technique to add options needed to netboot Raspberry Pis).

Hopefully this fixes the problem for some of you, or at least sets you on the right path!

Fantastic find! Color me suprised, because the Mach-E is specifically requesting option 119 in it's request !!!

17:39:51.639579 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 28:38:5c:XX:XX:XX (oui Unknown), length 300, xid 0x2894b86d, Flags [none] (0x0000)
          Client-Ethernet-Address 28:38:5c:XX:XX:XX (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Hostname Option 12, length 4: "SYNC"
            Parameter-Request Option 55, length 8:
              Subnet-Mask, BR, Time-Zone, Default-Gateway
              Domain-Name, Domain-Name-Server, Hostname, Option 119

Sponsored