Hi Luis/Johannes/John,
The Wireless mesh networking (802.11s) draft support has been added to
Linux 2.6.26. We at LTP (http://ltp.sourceforge.net/,
https://sourceforge.net/projects/ltp/) are trying to expand the test
coverage of all the untouched areas of kernel. With this drive in mind,
may i know if the testing infrastructure of Wireless mesh networking can
be shared with LTP under GPLv2. It would be a shot-in-the-arm for Linux
testing community, and, we can decide on how this can be best integrated
into LTP.
Regards--
Subrata
On Mon, Aug 25, 2008 at 02:00:31PM -0700, Subrata Modak wrote:
> Hi Luis/Johannes/John,
>
> The Wireless mesh networking (802.11s) draft support has been added to
> Linux 2.6.26. We at LTP (http://ltp.sourceforge.net/,
> https://sourceforge.net/projects/ltp/) are trying to expand the test
> coverage of all the untouched areas of kernel. With this drive in mind,
> may i know if the testing infrastructure of Wireless mesh networking can
> be shared with LTP under GPLv2. It would be a shot-in-the-arm for Linux
> testing community, and, we can decide on how this can be best integrated
> into LTP.
Mesh code is GPLv2 right now. What I'd recommend is to get mesh support
added into mac80211_hwsim driver and then you can test mesh code without
even having any wireless hardware.
At the third Linux wireless summit in Ottawa we briefly spoke about
automating testing for wireless. We should try to automate this first
with mac80211_hwsim and some scripts to do basic tests. Mesh testing can
be added once mac8021_hwsim gets support for Mesh.
Here are two scripts which create an AP and one which creates a STA with
the different encryption setups available.
http://www.winlab.rutgers.edu/~mcgrof/qa/create-ap.sh.txt
http://www.winlab.rutgers.edu/~mcgrof/qa/create-client.sh.txt
Similar type of scripts can be used to create different topologies and
test environments. Later on once this is polished we can test the actual
hardware with different drivers. But this should be a roadmap to start
IMO.
Let me know what you think.
For more information on mac80211_hwsim please see:
Documentation/networking/mac80211_hwsim/README
Luis
Thanks Jouni and Luis,
On Thu, 2008-08-28 at 19:56 +0300, Jouni Malinen wrote:
> On Mon, Aug 25, 2008 at 02:46:25PM -0700, Luis R. Rodriguez wrote:
>
> > Mesh code is GPLv2 right now. What I'd recommend is to get mesh support
> > added into mac80211_hwsim driver and then you can test mesh code without
> > even having any wireless hardware.
>
> That would be quite useful addition for automated tests that anyone can
> run.
Yes, this is what we also aim to achieve - fully automated testing, even
if it requires some initial human intervention. Normally this happens
even in the normal LTP network tests:
http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/network,
Somebody needs to do the following:
1) Setup some network daemons to run on the server. This is done
manually,
2) The LTP source code should be installed at the same directory
location in both the client and the server,
3) From the Client side, the user-id/password/server-ip is exported,
Once this is done, then the network tests begin and then everything in
automated. You just need to analyze the logs after the test is over.
This typical scenario makes this test cases to run separately from other
default LTP tests, yet they reside inside LTP.
>
> > At the third Linux wireless summit in Ottawa we briefly spoke about
> > automating testing for wireless. We should try to automate this first
> > with mac80211_hwsim and some scripts to do basic tests. Mesh testing can
> > be added once mac8021_hwsim gets support for Mesh.
>
> I've started collecting test cases for mac80211_hwsim. It would be
> interesting to see whether these could be integrated into LTP somehow
> and allow people to run a set of tests in fully scripted way. These
Yes, this is the way we should target things. Say we have your wireless
test cases inside a directory:
http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/network/wireless/mesh_networking/
This should have some bare minimum entries, like:
1) Makefile -> which should be able to build any binary required and
also install the binaries (actual test cases and wrapper scripts, etc)
here:
http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/bin/
2) A master wrapper script which does:
2.1) Checks out the existence of the driver(s) in the system,
2.1.1) If does not exist, then the script should also be able to
download it from the required location,
2.2) If driver exists, then load it,
2.2.1) handle driver loading/unloading errors and report
accordingly,
2.3) Then actually run those tests(other binaries/scripts) and record
results,
2.4) Unload the driver once the tests are over ; report unloading
errors if any,
Starting initially, we will prevent your Makefile to get called from the
root LTP Makefile (when make is invoked from LTP root directory). This
allows only selected testers (who will be actually interested in testing
this component) to drill down to this sub-directory and issue make. And
then invoke the master wrapper script to run tests and see results. You
can look in to the following to see how SElinux tests are intergrated
inside LTP. This will help you to understand the scenario:
http://ltp.cvs.sourceforge.net/ltp/ltp/testcases/kernel/security/,
Once this process gets stabilized, we can integrate the make with the
LTP make so that your test cases gets built and installed during the
normal LTP build/install. Now in one of your READMEs, you should mention
the following things very properly:
1) Ways to get/download/install the source(test code),
2) Ways to build/install and run,
3) Any other special requirement/setup the tests need to execute, like
Glibc version ??, Kernel version ?? (which options in kernel should have
been enabled to get this feature running), Architecture Supported, etc.
I hope we can start in bits and pieces. You can create a small patch and
send it across. I am not in a hurry. Please take your time and do things
in bits and pieces. I wanted to stay in touch and make sure that we have
started to do somethings, however small they may be.
Regards--
Subrata
> tests are described in hostap.git tree mac80211_hwsim/tests
> subdirectories:
> http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=mac80211_hwsim/tests
>
> The current instructions for running the commands (*/test.txt) are more
> for a person than a script, but the changes to get test running would be
> trivial (i.e., just run hostapd and wpa_supplicant on background).
> Larger task is in adding some functionality to verify that the test
> passed and then finish with cleaning up (killing daemons from background
> and unload mac80211_hwsim).
>
On Mon, Aug 25, 2008 at 02:46:25PM -0700, Luis R. Rodriguez wrote:
> Mesh code is GPLv2 right now. What I'd recommend is to get mesh support
> added into mac80211_hwsim driver and then you can test mesh code without
> even having any wireless hardware.
That would be quite useful addition for automated tests that anyone can
run.
> At the third Linux wireless summit in Ottawa we briefly spoke about
> automating testing for wireless. We should try to automate this first
> with mac80211_hwsim and some scripts to do basic tests. Mesh testing can
> be added once mac8021_hwsim gets support for Mesh.
I've started collecting test cases for mac80211_hwsim. It would be
interesting to see whether these could be integrated into LTP somehow
and allow people to run a set of tests in fully scripted way. These
tests are described in hostap.git tree mac80211_hwsim/tests
subdirectories:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=mac80211_hwsim/tests
The current instructions for running the commands (*/test.txt) are more
for a person than a script, but the changes to get test running would be
trivial (i.e., just run hostapd and wpa_supplicant on background).
Larger task is in adding some functionality to verify that the test
passed and then finish with cleaning up (killing daemons from background
and unload mac80211_hwsim).
--
Jouni Malinen PGP id EFC895FA