From Teaching Open Source

Contents 1 Wireless networking laboratory 2 Wireless testing exercise (some more thoughts) 3 Disconnect packets

[edit] Wireless networking laboratory

Frederick Grose wrote:

I have proposed this laboratory exercise for the next crop of RIT students in the Developing for OLPC Sugar Honor Seminar, RIT/Wireless networking. (The seminar draft syllabus is here, RIT/Honors Seminar.)

I have just learned some of these tools, and would appreciate it if you could look over this proposal and comment.

On Wed, Sep 9, 2009 at 12:53 PM, William Schaub <wschaub at steubentech.com> wrote:

Looks ok to me except for iwlist interfacenamehere scanning should just be iwlist interfacename scan or

even just iwlist scan which will scan on ALL interfaces with wireless extensions and display the results.

I've just submitted it to professor Jacobs and Grace, so they may not accept it immediately, but I wanted to solicit your support if it is accepted. In that case, it might help to have you available online in IRC or a telephone call in case we need more experienced help.

Thanks for your time and consideration! --Fred

I haven't had a lot of time to look over your whole proposal. but I would make sure the students get links to all of the official documentation for the Linux wireless stack and utilities.

I'm pretty sure wpa-supplicant is the way to go for joining a WPA network. I have used it successfully under slackware before and as long as you have a good commented config file to work with it should be trivial to make it both scan for and join open networks as well as remember and supply the credentials for known networks. (I'm sure more modern wireless connection managers provide a GUI to make this happen seamlessly but it is great to be able to use the command line and see how things work under the hood)

The current WPA2 configuration with wpa_supplicant worked! --FGrose 23:25, 9 September 2009 (UTC)

There are a lot of different options and different ways to arrive at a working wireless network. but I think the idea is a good one in that it helps them see how things work under the hood to a certain extent. Perhaps another great exercise would be to have them learn to automate the system with their own shell scripts (or python or whatnot) because once they learn how things are done under the hood and from the command line the next step is to be able to write programs or scripts to customize the behavior of the system.

But I have no idea what the scope of this class is and what the main goal really is so that might not be a useful suggestion for what you want to accomplish. I've never tried to be an educator.

See http://wiki.sugarlabs.org/go/What_is_Sugar%3F#About_the_Sugar_pedagogy. Your ideas in today's notes demonstrate principle #1, "everyone is a teacher and a learner". You have thought about something you know and don't know and guided us for the next cycle of learning. Because you taught yourself so much, perhaps you can remember better the course of your learning that those who might have set more passively through their courses. --FGrose 23:25, 9 September 2009 (UTC)

[edit] Wireless testing exercise (some more thoughts)

On Wed, Sep 9, 2009 at 1:19 PM, William Schaub wrote:

One thing I noticed that is not there but is essential is the iwconfig utility. This utility needs to be understood because it configures all of the wireless specific parts of a wireless capable network interface. (Much like ifconfig does for network specific stuff like ip address, subnet mask etc) things like iwpriv could also be important as well (iwpriv allows you to examine and change driver specific properties of a device)

I think they should understand how to get a wireless network up by hand in a shell without any high level software running (NetworkManager). they should be able to run iwconfig on an interface to setup the wireless mode (Managed, Ad-Hoc etc), the essid, channel (optional but it should be understood, in managed mode the firmware can scan and find the right channel to talk on and really only pays attention to the essid, although you can have multiple essids that are the same and then things get interesting particularly if they are not run by the same people (this can be used for roaming setups for example) and you might need to specify the desired Access point's mac address which is another parameter.)

I considered iwconfig for this laboratory, but I read that iwconfig only supports WEP, so I turned to wpa_supplicant and that seems to work. (I'm in that category of blackbox users, even if I were to use iwconfig--it's just another box with parameters. I would like to see the code and the commentary of an author or instructor--something like you did in getting the first version of the Unix textbook.) --FGrose 23:25, 9 September 2009 (UTC)

Then they should be able to use ifconfig to set the ip address and subnet and to bring the interface up. A small network of two machines connected to an access point should be good enough for them to bring the interfaces up and ping each other. You can of course substitute using the dhclient or dhcpcd commands but they should understand what the DHCP software does which is to simply negotiate an address and set the proper parameters on the interface.

Either way a basic understanding of IP networks and 802.11 networking form a system administrators perspective would probably be useful as background to all of this. otherwise they are just learning commands without background into why everything is the way it is and how it all fits together.

But like I said in the previous email I really have no idea what you are trying to teach and perhaps network technology and systems administration is outside the scope of what you are after.

I agree with your instructive approach wholeheartedly. However, Jacobs and Grace are not sufficiently technical, it seems, to be comfortable with too much lower level detail. So, I included the 'limited edition' of the laboratory to just expose everyone to the command line and the power it offers when the gui doesn't work. It turns out that Ryan Nolette is a Networking, Security, & Systems Administration major in the class and Gary Scarborough, http://www.it.rit.edu/?q=node/163, an systems administrator, is joining our class, so we may proceed with Wesley Dillingham, Ryan, and Gary to work on a School Server installation, http://wiki.laptop.org/go/School_server, for the RIT OLPC Sugar community. --FGrose 23:25, 9 September 2009 (UTC)

(when I say systems administration I am including the person sitting in front of a network capable machine configuring that machine to join a network, not just paid professionals managing a large network or collection of computers, in most cases today the end user of a system is both the user and the administrator of that machine)

I feel this is an important point, and that we need to work hard to build onramps for new system administrators that will be needed for the coming systems we envision. I'd like to keep working on laboratory experiments and exercises that would serve to challenge and build skills needed for coming generations of systems and people. Your participation in this work is really appreciated and would, naturally, be credited as co-author. In fact, it would be best to move this discussion to the wiki discussion page where it will be more easily available for reference. Please sign up for a TOS wiki account, if that is ok with you.

[edit] Disconnect packets

On Wed, Sep 9, 2009 at 1:32 PM William Schaub <wschaub /at/ steubentech.com> wrote:

• RIT reportedly scans their on campus wireless spectrum and floods any rogue ad-hoc cells with disconnect packets. Does this actually interfere with the XO's 802.11s (modified) Mesh interface? Explain why or why not. What are the options to enable Mesh networking on campus?

I didn't catch this before. that is intersting because I didn't run into this when doing demos for TEOTWAWKI Net in the conference room. is this an auotmated system or controlled by humans? my simple ad-hoc network stayed up. unless you are replacing ad-hoc with rogue access points. I'm not sure if ad-hoc networks have disconnect requests because there is rally no association going on in an ad-hoc network. (at least as I understand it anyway, but there are a large number of ways you cna disrupt 802.11 networks with the right tools)

Come to think of it I also demoed a laptop set up as a typical rogue AP running my software and that also worked so I'm guessing this doesn't happen instantly the moment a new network is set up. (particularly at such a low power and short range that my setup had it was probably not even detected and likely didn't really extend much further than the conference room.

This morning Wesley, Gary Scarborough, Ann (Grover) Warren, http://nssa.rit.edu/?q=node/104, & I met with Michael Muttitt, communications specialist with RIT ITServices, where he explained that they have a process running on the access point controller that searches on about a 10-minute cycle. I don't remember the essential details, but the behavior described was that you could connect ok but after about 10 minutes you would be dropped from the connection. He described that some of the access point systems would shut themselves down completely after receiving too many packets from an outside process that normally should be coming from an internal process (or address?). This countermeasure maybe something relatively new. I will try to test again tomorrow with a couple of XOs on Mesh interfaces to see what happens over a longer period. --FGrose 23:25, 9 September 2009 (UTC)

The technology is there to do automated detections and attacks. there are tools that allow you to hook up a ton of different autonomous systems with wireless interfaces in monitor mode called sensors. which then send the packets they scan back to a central host that can process the data and initiate attacks (or other pre-defined actions) to the senor nodes that picked up the un-authorized network. so they could really clamp down if they wanted to be ugly about it.

The person wanting to run an unauthorized network would have to play a game of cat and mouse and try to avoid detection by such a system or at least confuse it somehow. basically it is an arms race on both sides that is constantly changing.

To be good citizens on the RIT networks, we agreed that we should find ways to shut down the mesh interfaces to reduce radio frequency traffic when we don't really need it (as the WPA2 configuration worked), and then other ways to use the mesh, if desired for other experiments.

Thanks for you thoughts! --Fred --FGrose 23:25, 9 September 2009 (UTC)