[Help] How to figure out that the wpa_supplicant has changed the Ssid?
-
Hello Qt users and forum readers,
I'm working on the Qt application which connects to the wifi and uses the wpa_supplicant to set and achieve working connection. At the moment I use "wpa_cli" as a control interface of the wpa_supplicant (I create "wpa_cli" commands and them call them with system.
My problem is that I would like to know whether the wpa_supplicant refreshes it's configuration i.e. it connectes to the access point which has better signal strength or wpa_supplicant wakes up from the power safe mode.
Is there any system (Linux) SIGNAL that is emitted be the wpa_supplicant? Or maybe there is something like this in the supplicant's dbus interface? I was looking in the documentation, but with no success so far...
I'm working on Linux with Qt 4.8.6.
with best regards,
poorBob -
Hello again,
I tried to figure out whether anything was changed in network configuration with QFileSystemWatcher.
So I added the "/proc/net/route" and "/proc/net/" with "QFileSystemWatcher::AddPath":http://qt-project.org/doc/qt-4.8/qfilesystemwatcher.html#addPath method, but it seems that QFileSystemWatcher does not work with Linux's system files and no change signal is emitted :(.
Or it works but I'm unaware of something with it?Does anyone has any idea?
with best regards,
poorBob -
The QFileSystemWatcher uses inotify for linux which is based off the inode. This does not work well with procfs. In their "docs":http://inotify.aiken.cz/?section=inotify&page=faq they say it does work with procfs but every kernel has some issues. I ran the test mysefl with some test code and found it didn't work on procfs at all.
An easy test for this is just use something like:
@
tail -f /proc/net/route
@It should say something like "tail: route: file truncated". It will now no longer get file notification like tail -f normally would.
Just to be sure I wrote a Qt app that tested this as well. It most definitely did not work with proc.
If you would like my test applet me know and I'll send it to you, basically just takes files to watch on the command line and prints a message if they change.
As for a solution, you may want to check out something like stat() or poll(). I would lean towards "poll()":http://linux.die.net/man/2/poll for what you want. Not 100% sure it will work but I didn't have more time to write some test code.
-
Also, I checked sysfs with /sys/class/net/enp4s0/operstate and it didn't respond to changes either. Although tail -f didnt report a problem but it wouldn't detect the change either.
I'm thinking procfs and sysfs don't respond to inotify properly at all. At least not with my kernel so not with any reliability for distribution.
-
And finally, a post from a guy on this "thread":http://stackoverflow.com/questions/3216458/on-linux-how-can-i-programmatically-determine-if-a-nic-interface-is-enabled-and says:
open AF_NETLINK socket
bind it to sockaddr_nl with nl_groups = RTMGRP_LINK
send message RTM_GETLINK to kernel
make poll/epoll on socket to read RTM_NEWLINK and RTM_DELLINK messages
you will receive initial interfaces list and its changes in futureThat sounds exactly like what you want but without procfs/sysfs monitoring.
-
Hello ambershark,
thanks for Your reply and for confirming my worries about QFileSystemWatcher.
Regarding the solution: I've never tried socket programming so could You prepare some simple example how to do it? I would also love to get You test app via private message to see Your solution.
with best regards,
poorBob -
You can download my test app from "here":https://dl.dropboxusercontent.com/u/108525578/proctest.tar.gz, however since it's just the same thing you are doing it's not really going to help.
If I get some time later today I will write some test code for polling to see if that works. It would be an easier solution than the socket. The socket would take a lot more code.
-
Hi,
QFileSystemWatcher works on all platforms, but it won't work on every file on the system, you should normally get a message on the console in such a case.
-
Unfortunately no message on the console in this situation.
But it's not Qt's fault. It is inotify and problems with different kernels. And since Qt uses inotify it just doesn't work but Qt has no idea it failed.
If you have a linux system you can download my test code linked above and give it a shot yourself, just build then:
@
./proctest /proc/net/route
ifconfig <net interface> down
@At that point it will turn your network off thus removing a route and the file would update. However Qt/inotify doesn't see it.
Oh and make sure you know your route info or you will have to restart your networking to fix that ifconfig down line. :)
For me to turn mine back on would be
@
ifconfig <net interface> up
route add default gw 10.0.1.1 <net interface>
@And again that should update /proc/net/route but Qt won't see the change. This happens with the sysfs filesystem too.
It does work with a normal filesystem on linux though. Tested with ext4. You can use proctest on that too:
@
./proctest /proc/net/route ~/somefile
@You will notice that changes to ~/somefile get reported but changes to the /proc do not.