network is a complex thing to configure correctly and involve some files.
First, your wpa_supplicant is very clear about your troubles. Like said wat-now you have a another wpa_supplicant started before the one supervised by 66. So, the one managed by 66 refuse to start as long as you have an already wpa_supplicant daemon running.
To detect it you have several way, i prefer htop. Run it, found the process and kill it and look at the wpa_supplicant service if it start or not.

Now, you need to take care about your /etc/resolv.conf, /etc/hosts, /etc/hostname files.
Personally i use wpa_supplicant with dhclient. I also use the wpa_supplicant@ service with a specific interface. You can follow the Arch wiki about that.

A word about the environnement file. No bug here and expected behavior. The doted one is the original file created when the enable the service. If the frontend file contain a [environment] section, this file is automatically created. Now when you use the 66-env tool, a new environment file is created by a copy of the original one (the doted) with the same name WITHOUT the dot.
Now when you start the service the environment files found at the /etc/66/conf/<service>/<version> directory is read by alphabetical order. That means that for a same key=value pair the last one is picked, so your personnal modification is took.
Thanks for clearing up my misunderstanding of the environment file.

I've rebuilt my install, and I found that the -B switch on the wpa_supplicant line [which sends the process to the background] seems to have been te problem that made wpa_supplicant fight with itself. Removing it makes for a much calmer log. Maybe the supervisor was launching new instances when the process was no longer in the foreground?

I'm still stuck, however, on getting network service. It's pretty bizarre: my wired internet works fine, but when I'm on WiFi, wpa_supplicant automatically connects to the correct network, dhcpcd gets a working IP, and neither ping nor curl manages to connect to anything - except my gateway!

Weirdly, I can ping the machine successfully, but it can't ping other machines. I can't curl any other address or IP than my gateway, pacman can't download, nothing. This suggests that the network is indeed up, but I'm still miscommunicating somehow.

Any ideas?
Sounds like a problem with wpa_supplicant passing on DNS servers or dhcpcd getting DNS servers thru the wireless connection...however it works... try setting static DNS servers in /etc/dhcpcd.conf. or messing with /etc/resolv.conf
New twist to the story: I get problem-free internet access when I use a different WiFi router that plugs into the router that doesn't want to play nice with my laptop. There is a problem between my regular WiFi router and my laptop, it seems. Which is odd, because it's a problem-free router with all other WiFi devices in the house.

So the laptop WiFi is functioning, the regular WiFi router is functioning, but they won't function together. And they're the only pairing that malfunctions. What's more, after messing with the settings in the regular router, I can now ping via that thing - but I can't resolve domain names. At least, that is the point it fails at now, I don't know if there's more that fails behind that point. No other machines have any trouble, neither does my laptop under a Knoppix live USB.

Of course, I filled in a number of nameserver addresses in resolv.conf, but that doesn't seem to make a difference. Any ideals where to look?
After some experimentation, it seems that when I'm on the problem WiFi router, my DNS fails because it tries to contact 127.0.0.1:53. Which is where usually systemd-resolved is expected. Which I don't have, because Obarun.

To be perfectly clear, I want nothing to do with systemd-resolved, and I'm not in the market for suggestions how to get it going on my PC.

What *would* be nice, is to get rid of this behavior in my network utilities. Some examples:
$ dig google.com
;; communications error to 127.0.0.1# 53: connection refused

$ host google.com
;; communications error to 127.0.0.1# 53: connection refused

$ curl google.com
curl: (6) Could not resolve host: google.com

$ sudo ping -v -c 4 google.com
ping: google.com: System error
OK, solved! Kind of. Although this merits some more investigation.

It seems that when connecting to some routers, my network goes into systemd-mode and refuses to connect to any alternative I offer in resolv.conf. All I get is vague error messages as above. If I force dhcpcd to only use my own statically defined DNS servers, all is well and everything functions, also on the problem routers. So, for anyone else struggling with this problem, I added the line 
static domain_name_servers=217.160.70.42 91.239.100.100
to the end of /etc/dhcpcd.conf, and restarted dhcpcd. It seems to persist after rebooting.

The only thing that makes me hesitant to leave this whole thing behind me is the fact that somehow, routers are persuading my system to use systemd-resolved. Even if that fails. That routers can override settings on my machine seems like a security issue.

Powered by Obarun