Bug 449211 - wpa_cli and wpa_gui fail to connect to supplicant in dbus mode without "-i" flag
wpa_cli and wpa_gui fail to connect to supplicant in dbus mode without "-i" flag
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: wpa_supplicant (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-31 07:25 EDT by Pavel Polischouk
Modified: 2009-07-14 13:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 13:53:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Add a proper README file to docdir (873 bytes, patch)
2008-06-03 22:57 EDT, Pavel Polischouk
no flags Details | Diff
Man page update highlighting per-interface options. (1.75 KB, patch)
2008-06-03 23:31 EDT, Pavel Polischouk
no flags Details | Diff

  None (edit)
Description Pavel Polischouk 2008-05-31 07:25:02 EDT
Description of problem:
When wpa_supplicant is started with -u switch (dbus mode), both wpa_cli and
wpa_gui fail to connect to it.

Version-Release number of selected component (if applicable):

wpa_supplicant-gui-0.6.3-5.fc9.i386
wpa_supplicant-0.6.3-5.fc9.i386

How reproducible:
Always.

Steps to Reproduce:
1. Start wpa_supplicant service, making sure -u flag is used
2. Try to start wpa_cli or wpa_gui
  
Actual results:
wpa_cli v0.6.3
Copyright (c) 2004-2008, Jouni Malinen <j@w1.fi> and contributors

...

Could not connect to wpa_supplicant - re-trying

Expected results:
wpa_cli and wpa_gui should have the switch (same -u?) to be able to talk to
wpa_supplicant over dbus interface instead of default socket interface.

Additional info:
Comment 1 Dan Williams 2008-06-02 16:19:09 EDT
Hmm; you may want to ensure that the right bits are in
/etc/wpa_supplicant/wpa_supplicant.conf about ctrl_interface?  They should be
there by default, what does yours have in it, and what does "ps ax | grep wpa"
show when the service is started?

This isn't intentional, you should be able to at least talk to it with the
socket control interface if -u is used.
Comment 2 Pavel Polischouk 2008-06-03 17:32:12 EDT
Debugged it further. It appears that it's not "-u" flag that prevents the socket
control from functioning. The pass/fail condition matrix is as follows:

"-ieth1 -u" works fine
"-ieth1" works fine
"-u" : socket control doesn't work, supplicant works.
"" : supplicant doesn't start at all, either -i or -u option must be present.

So it used to work before because I had "-ieth1" in my
/etc/sysconfig/wpa_supplicant. Switching to NetworkManager I saved my old config
and used the default one provided by rpm package instead, which has no "-i"
flag. Perhaps some glitch in startup code that skips part of initialization when
started without -i?
Comment 3 Pavel Polischouk 2008-06-03 22:45:06 EDT
Analysed the source code. wpa_supplicant considers config files (given by -c
options) per interface. If no -i option is given, no config file is read. Global
control interface file name is taken either from config file, or from -C/-g
command line option, with no built-in default. The global control interface can
ONLY be given through -g option, since there's NO global config file. This also
means that for global config file, no group control is possible
(ctrl_interface_group).

Usually wpa_supplicant refuses to start unless at least one -i is specified.
However, if -u is present, it will start and disregard any config files.

Considering the above, it might not be a real bug, but just a not very intuitive
set of command line options that is also adequately documented. Man page
specifically fails to mention the fact that in certain cases the -c option will
have no action, or the limitations of global control interface. Some of that
information is present in wpa_supplicant/README in source code, but that file is
not %doc'd in RPM build (another generic README with no useful information is
%doc'd instead).

My recommendation: at least update the spec to %doc the proper README, and
update the man page to mark the options which are per-interface and are ignored
in "externally controlled" mode.
Comment 4 Pavel Polischouk 2008-06-03 22:57:29 EDT
Created attachment 308313 [details]
Add a proper README file to docdir

Replace README with %{name}/README in %doc, so wpa_supplicant README is
included instead of hostap top-level stub.
Comment 5 Pavel Polischouk 2008-06-03 23:31:25 EDT
Created attachment 308314 [details]
Man page update highlighting per-interface options.
Comment 6 Dan Williams 2008-07-02 18:52:08 EDT
These patches got pushed upstream, right?  ISTR something like this going past
on the hostap mailing lists.  If that's correct, I'll pull in the git commits
that Jouni did.  Thanks for the debugging!
Comment 7 Bug Zapper 2009-06-09 21:18:54 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Bug Zapper 2009-07-14 13:53:04 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.