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. BR, Flavius On Fri, Jul 29, 2016 at 9:11 AM, Siwon Kang <kkangshawn@xxxxxxxxx> wrote: > Hi, > > 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'. > > BR, > Shawn. > > > 2016. 7. 29. 오후 1:59에 "Flavius Lazar" <lazarflavius88@xxxxxxxxx>님이 작성: >> >> 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, >> Flavius >> >> _______________________________________________ >> Hostap mailing list >> Hostap@xxxxxxxxxxxxxxxxxxx >> http://lists.infradead.org/mailman/listinfo/hostap _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
