802.1X test and WPA Supplicant tool

[krihal]

We at SUNET in Sweden have a need for a perfSONAR probe monitoring 802.1X availability and created a simple test and tool for this purpose. The test takes a few parameters such as a username, password and network interface and then tries to authenticate with 802.1X using WPA Supplicant. If that is successful, we will try to acquire an IP address through DHCP. Today that is done in the same tool, but can easily be split into two separate tools if that is preferred.

The test will report back if the authentication was successful or not, which IP address we acquired and a few other things we want to know.

I don't know how new features are handled in the perfSONAR project, but are there any chance we can merge this into the pscheduler repository here? If so I will clean up the code and open a pull request or provide more information.

Thanks, /K

[mfeit-internet2]

New plugins are absolutely welcome. You're the first from outside the project to have one that's fully-developed, so this is new territory for us, too. :-)

A pull request would be a good vehicle for this process:

• Submit your code as it stands as a pull request for the 4.4.0 branch.
• I'll review it for quality and architectural fit and suggest changes.
• You make changes in your copy and we review it again.
• Once we're both happy, we'll pull it and ship it with the 4.4.0 release and list SUNET on the project's contributing organizations list.

We would ask that SUNET commit to maintaining the plugin between its first release and at least the next minor or major release. Our experience has been that outside of adding new features, most plugins reach a steady state after a few months of active use. If you're already using it internally, there are likely to be fewer problems out of the gate and therefore less work for you.

I'm on holiday for the rest of the week and will pick this up when I get back.

[epcjr]

Does this allow you to specify the BSSID, or just the SSID?

[krihal]

Does this allow you to specify the BSSID, or just the SSID?

We're currently using it for testing wired connections, but if there is interest I can add optional arguments for specifying BSSID/SSID as well.

One requirement for this to work is that WPA Supplicant is running on the probe with the D-Bus interface enabled since we currently use wpa_cli to configure the supplicant.

[mfeit-internet2]

Now that I've had some time to think about it (and be delayed by other things), I have some thoughts on the test that are being put here instead of the pull request so they don't get lost:

I'll preface this by saying that getting the test design right is the most important and most difficult part of the process. The goal is to come up with something that encompasses as many applications as is reasonable and will be expandable in the future to accommodate new tools. For example, throughput started life with tools for iperf2, iperf3 and nuttcp and had Ethr added later without upheaval.

It's also important to keep tests from being front-ends for specific tools, which can end up becoming a dead end. We can support tool-specific features, but we try to do so in a generic way. For example, rtt has protocol parameter that allows that measurement to be made in different ways, such as with tools that use ICMP or TWAMP.

Having reflected a bit on the test, it does more than just making sure 802.1x works:

• Bring up the interface
• Authenticate to the switch using 802.1x
• Get an address from a DHCP server

Given that, I'd like to suggest a couple of minor structural changes that will also accommodate some of what @epcjr wants to do with wireless:

First is to rename the test to something more descriptive. All I could come up with was ifup, for "interface up," but I'm open to other ideas.

Second is to organize the test to be a little more modular (for lack of a better word).

{
    "interface": "wlan0",

    "isolate": false,

    "wifi": {
        "ssid": "eduroam",
        "bssid": "de:ad:be:ef:00:00",
        "band": 5,
        "channel": 9
    },

    "ieee802.1x": {
        "_user": "foo",
        "_password": "bar"
    },

    "dhcp": false,

    "teardown": false
}

isolate - Take steps to do the test in a way that doesn't interfere with anything else on the interface (i.e., use an unoccupied network namespace and/or subinterface). Most tools would default to true for this, but one of Ed's applications is to bring the interface up into a given configuration and leave it that way.

wifi - Optional parameters for WiFi to be used by tools that support it.

ieee802.1x - Optional parameters for authenticating via iee802.1x to be used by tools that support it.

dhcp - Whether or not to get an IP address via DHCP. It might be worth adding parameters If you wanted to make it really slick, additional parameters for requesting DHCP options and putting what comes back in the result would be neat, although probably overkill for the first cut.

teardown - Undo all changes made to the system at the end of the test. Should normally default to true; Ed's wireless application requires that the interface remain up for subsequent tests.

Let me know what you think.

[krihal]

I think all this seems very reasonable, the more general we can make it the better. Regarding the name, I can't come up with anything better so let's stick with "ifup" for now. I'll try to implement what is missing, but will most likely not be done until after X-mas.

[mfeit-internet2]

Whenever is good. There's plenty of time since this won't be out until the next feature release.