lazarflavius88 at gmail.com
Fri Jul 29 00:01:18 PDT 2016
I'm not using dbus at all.
Then according to wpa_supplicant dev manual: "Linux version of
wpa_supplicant is using UNIX domain sockets for the control interface"
(with UDP as protocol I would say).
My netstat is from busybox and it doesn't provide the "-p" option.
Anyhow, I know the process which leaks file descriptors, but I don't
know how to identify the spot where it happens.
I ran "netstat -ax" and it shows me some "DGRAM" sockets that could be
the guilty ones, but much less than what "lsof -p <pid>" shows as
"can't identify protocol" sockets.
On Fri, Jul 29, 2016 at 9:11 AM, Siwon Kang <kkangshawn at gmail.com> wrote:
> Unless you are not using dbus for communication, you might be sending your
> command to wpa_supplicant through unix udp socket. You can see your socket
> status by 'netstat -axp'.
> 2016. 7. 29. 오후 1:59에 "Flavius Lazar" <lazarflavius88 at gmail.com>님이 작성:
>> Hello everyone,
>> I have an application that sends commands to wpa_supplicant through
>> the control interface. It provides simple functionality like scan,
>> connect to an AP or disconnect from an AP. This application runs on an
>> embedded Linux device.
>> I have a test that simulates the use case when my device passes out of
>> AP coverage exactly in the moment when it tries to connect to the AP.
>> I'm running this test in a loop and I noticed that I run out of open
>> file descriptors in my application's process. Checking with lsof I can
>> see a lot of sockets with "can't identify protocol". I do not open any
>> sockets in my application. So, I'm wondering if they might be from the
>> control interface part - there it uses unix domain sockets to send the
>> commands to wpa_supplicant?
>> I tried looking into the source code of wpa_supplicant, but it's not
>> so simple to identify what happens to the socket file descriptor if
>> the connection process is interrupted during the 4way handshake.
>> wpa_supplicant version: 2.0 (cannot upgrade - I have some patches from
>> my driver provider)
>> Best Regards,
>> Hostap mailing list
>> Hostap at lists.infradead.org
More information about the Hostap