I was writing about some changes to AAP
I worked on it and I completed all that changes
This is to let everyone know about it
Anyway I sent all the new code to Orange
It is important to know that the biggest and hardest-to-write part of AAP is written by Orange and I couldn't write it starting from 0
I've just added and changed some features
So Orange now will decide what to do with my code: he can add some of my changes to the next Piranha release and he can refuse some changes
Moreover, at the moment, I'm in a mess cause I'm going to move in a week to a new country (to Amsterdam) with a new job
So probably I'll have not so much spare time in the next month
Here is a brief summary of my changes:
1) AAP WORKS ALSO WITH MULTIPLE VAP
AAP works with "a single madwifi-VAP ath0 in STA mode" as Orange wrote here: https://forum.openwrt.org/viewtopic.php?id=21636
I.e. the fonera connects to a wifi net in client mode and uses its internet connection
Fonera's clients has to connect to it via ethernet
I want fonera to create a VAP (virtual access point) in AP mode, i.e. a new wifi net which uses the internet connection from the previous
Now it is working even with multiple VAPs
2) RANDOM MAC ALSO WITHOUT ANY ETH CONNECTION
Before connecting to a net in client mode, AAP changes randomly the MAC address of the fonera's wifi device
But this change is not really random
The command used to randomly change the MAC address is:
macchanger -A wifi0
Macchanger, to get a random number, uses the device /dev/random
But in devices diskless, small and simple like the fonera, the entropy's source has not a high quality
So it happens often (e.g. 2 times on 10) that the new MAC is an old one already used before
This problem becomes more frustrating if the fonera is used without any ethernet connection (like me)
Because the entropy's source for the device /dev/random is right the ethernet connection
So, if there is no ethernet connection, 9 times on 10 the same "random" MAC is choosen
https://secure.wikimedia.org/wikipedia/en/wiki//dev/random
http://www.pinkas.net/PAPERS/gpr06.pdf
Now this problem is solved and the MAC is pseudo-random (every time it is different)
3) REWRITE FUNCTION aap_counter()
The function counter() check the time since the last scan
When the rescandelay (a parameter in the config file) interval is over, a new scan have to be done
By default, rescandelay is 12 hours
I rewrote this function minimizing the writes on disk
4) ANALYZE AND MINIMIZE WRITES ON DISK
Minimized all the writes on disks, cause the router has a solid state memory and it can be ruined if written too often
5) BETTER SCAN
The scan function use a command which updates the values of the signal power too slowly
I.e. if a net become instantly less powerful (e.g. from a power of 80 to a power of 30), that command takes 5 min to updates this value (even if run more times)
Now it is faster
6) CHANGES TO THE CHECK FUNCTION aap_check()
I changed the way to check if the connection is ok or not
Now the watchinet param has a bit different meaning
The check can be done in 2 ways:
- using the ping command: if the param watchinet is 1
- checking that ath0 is associated: otherwise
The first one tests if the network has a working internet connection (using the ping command and the parameter ineturl)
The second one just tests if the ath0 is associated
This second option is useful for me cause in my situation I have a lot of wifi networks available and all of them has always an internet connection
So in this situation, if a ping fails, is just a temporary problem (caused by some delay) and I dont want to skip this network
So it will check just the association status of ath0 using the command iwconfig
98) WEB GUI
Get the web interface at: http://10.0.0.1
99) SMALL BUGS AND CHANGES
Fixed some bugs in the log