Have dhcpcd start wpa_supplicant with -s to enable logging

[b-schliessmann]

dhcpcd5 8.1.2-1+rpt1, when a wifi interface comes up, calls /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant to start wpa_supplicant like so: wpa_supplicant -B -c"$wpa_supplicant_conf" -i"$interface" "$driver" 2>&1

This results in wpa_supplicant's stdout and stderr to be redirected to /dev/null, which I verified in /proc/[pid]/fd. This way, no troubleshooting information can be obtained from the logs. (Only indirectly by dhcpcd entries, search the internets for "dhcpcd: carrier lost".)

Proposed change: add -s option to wpa_supplicant call to have it log to syslog:

wpa_supplicant -B -s -c"$wpa_supplicant_conf" -i"$interface" "$driver" 2>&1

Using this change, it logs nicely alongside dhcpcd in /var/log/syslog, easing troubleshooting.

[b-schliessmann]

patch.txt

(Cannot attach a .diff file, not supported. How strange is that.)

[XECDesign]

I don't think it's common practice to throw all of wpa_supplicants messages to syslog by default like that. It's not what dhcpcd does by default anywhere else and AFAIK it's not what NetworkManager does. I'm a bit hesitant to divert from that given this is the first time this has come up since we switched to dhcpcd 6 years ago.

You can run wpa_cli -i wlan0 to more effectively troubleshoot wpa_supplicant issues.

[b-schliessmann]

Ok, just a few thoughts, but YMMV of course:

• IMHO, errors should never pass silently. By default, dhcpcd seems to redirect its hooks' stdout to /dev/null and hopes that everything will be fine. On top of that, stderr is explicitly redirected into the bin (see above).
• wpa_supplicant generates 6 (six) log lines in default log level (without -d[d]) whilst connecting to the wifi network.
• dhcpcd itself logs 20-ish lines at the same time, and from then on one line for every router advertisement, in my case about 10 lines/h (could be called fringe spam :) )
• For me personally, running wpa_cli like that is not quite prudent since my Pi is headless and administered by ssh (no space for screen and keyboard). Also, I care for some Pis across the country, also using ssh. There might be a significant danger of locking myself out. :) And it's convenient to have past wifi disconnect circumstances logged when connecting to a Pi I haven't attended to for months.

(The main reason for me to create this issue was that, during my wifi troubleshooting, I encountered numerous forum threads about "wlan0: carrier lost" issues, most involving to have inexperienced users that already have invested time in troubleshooting start wpa_supplicant manually -- just to diagnose the issue. Personally, I'm fine with it if you decline. With two-figure years Debian GNU/Linux experience, Raspbian is familiar ground for me, but this may not apply to all Pi users.)

[seamusdemora]

@XECDesign

Apologies for the interruption, but I'd like to submit a pull request against dhcpcd5. I've made the change on my local system & tested it, and Roy Marples has committed the PR against his downstream branch. The problem is that I cannot find the source package here on the rpi github site.

On my 'bullseye' system, apt-cache showsrc dhcpcd5 shows two sources: 7.1.0-2 and 1:8.1.2-1+rpt5. I don't understand why or how there are 2 sources, but I am unfamiliar with how these things work in RPi. More confusing to me is that the 8.1.2 branch is absent from the dhcpcd5 "salsa" repo for some reason. I have guessed that it must be here on the RPi GitHub site, but I've been unable to find it.

Can you help me sort my confusion? Where should I submit my PR to get dhcpcd updated asap?

[XECDesign]

The problem is that I cannot find the source package here on the rpi github site.

Yeah, it's not. It's just available as a debian source package in the repo.

I don't understand why or how there are 2 sources

You'll see they come from different repos. One is from Debian/Raspbian, while the other one is ours.

More confusing to me is that the 8.1.2 branch is absent from the dhcpcd5 "salsa" repo for some reason.

Our packaging comes mostly from Debian, but we bump dhcpcd itself once in a while, whenever there's a reason to do so.

Can you help me sort my confusion? Where should I submit my PR to get dhcpcd updated asap?

I've uploaded a build with your patch to the 'untested' component of the repo. You can add 'untested' after 'main' to /etc/apt/sources.list.d/raspi.list and upgrade to give it a go and confirm it works as you expect.

Cheers

[seamusdemora]

@XECDesign

Thanks for that. To clear up some other points of confusion for me & further my education:

1. When you say you've "uploaded a build with your patch to the 'untested' component of the repo", where is that repo? Can anyone upload untested builds there? By "build" - do you mean a binary (.deb), or sources?

2. I d/l (via apt source dhcpcd5), patched, built (via debuild -b -uc -us) & tested dhcpcd5 a few days ago. Testing is easy - you can see "log flooding" before the fix & normal logging after the fix. I've run some other experiments to assure myself that it works. Would adding the untested component fo the repo to my sources list result in getting other untested packages - in addition to dhcpcd5?

3. And finally, any idea as to when this will make it into the 'main' repo for update by apt?

~ Le taing

[XECDesign]

where is that repo?

It's a part of https://archive.raspberrypi.org/debian/

Can anyone upload untested builds there?

Nope

By "build" - do you mean a binary (.deb), or sources?

Both

Would adding the untested component fo the repo to my sources list result in getting other untested packages - in addition to dhcpcd5?

Not right now, but you should remove that component afterwards so that other packages don't get installed later.

And finally, any idea as to when this will make it into the 'main' repo for update by apt?

When I have confidence and independant verification that it does what's intended and doesn't cause other issues.

[seamusdemora]

OK - thanks for your help with this.

Just two other questions :)

1. How does Roy Marples' dhcpcd repo/source tree flow down to the one used in RPi? In other words, is it 'direct':

RM dhcpcd repo ==> RPi source tree , or is it 'indirect' via Debian

RM dhcpcd repo ==> Debian source tree/salsa ==> RPi source tree

2. How can I get the latest version of the RM dhcpcd repo running on my RPi? I'm very new at this 'build from sources' business, and I have "guessed" that there will be differences between (for example) the Makefile from RM's dhcpcd repo, and the one needed for RPi. Any pointers on that?

[XECDesign]

RM dhcpcd repo ==> RPi source tree

Kind of that one, but using the tarballs uploaded here https://roy.marples.name/projects/dhcpcd/downloads/, if I recall correctly.

2. How can I get the latest version of the RM dhcpcd repo running on my RPi? I'm very new at this 'build from sources' business, and I have "guessed" that there will be differences between (for example) the Makefile from RM's dhcpcd repo, and the one needed for RPi. Any pointers on that?

I can't cover all the steps here, but I can point you in the right direction. You can use the debian directory from our source package with a newer upstream tarball. Use dch to update the changelog appropriately. debian/patches contains all the patches (so if we've modified the Makefile, it would be through that). debian/rules contains the build instructions, so you'll see whatever flags we pass to configure or make steps there. debian/control defines relationships between packages, like dependencies and descriptions. It should all be relatively self-explanatory.

[seamusdemora]

You can use the debian directory from our source package with a newer upstream tarball.

That's a big help - thanks again.

[seamusdemora]

@b-schliessmann

Ok, just a few thoughts, but YMMV of course:

First of all, apologies for hijacking your issue, but it appeared to have ended.

Your thoughts on enabling logging for wpa_supplicant seem reasonable to me. Instead of another one-size-fits-all script, would you consider it a reasonable compromise to perhaps do something along these lines???:

1. Use the -e --env value option defined in man dhcpcd to declare a value for something like wpa_logging=YES
2. Check that value in 10-wpa_supplicant to make a decision whether to use the -s or -c options

There may be other options to provide this flexibility.

[b-schliessmann]

Hi @seamusdemora

Your thoughts on enabling logging for wpa_supplicant seem reasonable to me. Instead of another one-size-fits-all script, would you consider it a reasonable compromise to perhaps do something along these lines???:

1. Use the `-e  --env value` option defined in `man dhcpcd` to declare a value for something like `wpa_logging=YES`

2. Check that value in `10-wpa_supplicant` to make a decision whether to use the `-s` or `-c` options

In principle, yes. Unfortunately, it's not my decision however.

I still don't understand why one would want to exclude wpa_supplicant's few messages (sometimes critical for identifying issues) from syslog, when at the same time other services (like dhcpcd and especially rngd) are tolerated to flood syslog regularly with nearly meaningless clutter.

[seamusdemora]

@b-schliessmann

Right - I was thinking along the lines of making this change in an unofficial repo. It's a bit of an experiment, but the idea was to create a GitHub repo that allows one to clone the GH repo & build the .deb locally - effectively the same way you build a .deb from the source package now.