Getting the MAC address of the WiFi interface on Symbian

You can get the MAC address of the WiFi interface on a Symbian phone by typing *#622099526# (which is the same as typing *#mac0wlan#).

¿Qué tarjeta Wi-Fi me compro?

Interesante artículo que describe las diferentes variantes de 802.11 y qué factores son interesantes considerar a la hora de adquirir una tarjeta inalámbrica.

En mi caso, me gustaría comentar que uno de los chipsets con mejor soporte para GNU/Linux es el Atheros. Los nuevos MacBook Pro de Apple incorporan este un chipset Atheros con soporte de banda dual 802.11a/g que funciona de serie, sin tener que instalar ningún controlador de dispositivo ni firmware.

Particularmente, me decanto por las tarjetas con soporte de banda dual 802.11a/g porque, aunque el estándar 802.11g tiene mayor penetración el mercado, el estándar 802.11a suele ofrecer mayor velocidad, aunque también menor alcance, y, normalmente, la banda de los 5GHz suele presentar menos interferencias que la banda de 2.4GHz.

Configuring WPA2 Enterprise with EAP-TLS in Mac OS X and Linux

Setting up the CA

Follow the steps on setting up a Certificate Authority (CA) using OpenSSL.

Issuing the client certificate and private key

Once the CA has been configured, we will generate a private key and an unsigned public key digital certificate.

# openssl req -new -days 365 -newkey rsa:1024
-keyout sslkey.pem -out unsigned.pem

The unsigned public key digital certificate, stored in a PEM-encoded file named unsigned.pem will be sent to the CA for signing:

# openssl ca -in unsigned.pem -out cert.pem

Installing the client certificate and private key

The next step consists in installing the private key, public key digital certificate and CA public key certificate.


The private key, public key digital certificate and CA certificate files should get installed into a location where only root and wpa_supplicant can access them, for example, /etc/wpa:

# mkdir /etc/wpa
# chown root.root /etc/wpa
# chmod 700 /etc/wpa

Mac OS X

Mac OS X can only import private keys in PKCS#12 so we need to export all the previous items to a suitable format:

# openssl pkcs12 -export -in cert.pem -inkey key.pem
-out client.p12 -name "host.domain"

Where "host.domain" denotes the FQDN of the host which this digital certificate and private key are intended for.

The output file client.p12 contains the private key and public key digital certificate. This bundle should get moved to the host using a secure distribution channel, like an SSH/SCP/SFTP session or a USB key. Also, the CA digital certificate, usually named cacert.pem, should also get copied to the host.

On Mac OS X, using the GUI, double click the cacert.pem file, and install the CA certificate into the X509Anchors keychain. This a system-wide keychain intended to store X.509 CA root digital certificates.

Next, using the GUI, double click on client.p12 file, supply the password that protects the private key stored in this file, and choose to install both the private key and public key into the login keychain. Next, make sure the private key has been installed:

Configuring the AirPort Express Wireless Access Point

Launch AirPort Admin Utility, select the desired base station and click the Configure icon from the toolbar:

Click the Change Wireless Security… button:

In this new window, fill in the information about the RADIUS server, like its IP address, shared secret and so on.

Configuring the Supplicant for WPA2 Enterprise


Create /etc/wpa_supplicant.conf using the following data:


The identity directive is required, or else the EAP-TLS negotiation will fail.

ap_scan=2 and scan_ssid=1 are needed when the Wireless Acccess Point is configured to not broadcast the ESSID.

Mac OS X

Launch Internet Connect from the Wireless menu:

If no 802.1X icon appears on the toolbar, choose File -> New 802.1X Conection…. Click the 802.1X icon. The window will look like this:

From the Configuration drop-down, select Edit Configurations…:

A window like this will open:

Fill in both the “Description” and “Wireless Network” fields with the ESSID of the Wireless network. Leave “User Name” and “Password” blanked, since we are not using password-based authentication.

From the “Authentication” listbox, clear the checkbox for all the protocols except for TLS. Select the TLS protocol and click the Configure button. A new window will open for you to select the private key that will be used for the EAP-TLS authentication mechanism:

From the drop-down listbox, select the name of the private key that matches the name of the private key installed in the previous section.

Click the Connect button. The Supplicant will authenticate against the Wireless Access Point. At this point, it is possible that Mac OS X asks confirmation for accessing the private key stored in your keychain. It is recommended to “Always Allow” the Supplicant access to the private key.

Launch System Preferences -> Network and Configure… the AirPort interface:

Click the “+” button to add a Preferred network:

Just enter the ESSID of the Wireless network and choose WPA2 Enterprise from the Wireless Security drop-down listbox. Also, make sure the Configuration field shows the name of the 802.1X configuration we created previously using Internet Connect.

Leave the rest of the fields blank, since we are not using password-based authentication.

WPA Enterprise

This document explains how to set up WPA/WPA2 Enterprise using EAP-TTLS (with PAP) as the authentication mechanism.


The original IEEE 802.11 standard defined two basic security mechanisms:

  1. Open System Authentication, which offers no security at all since any Wireless client can associate with a Wireless Access Point configured in such a way.

    Open System Authentication can be useful in public Wireless networks, like those found in airports or public areas. However, this security mechanisms offers no authentication and no confidentiality: data is sent into the air in the clear at the data-link layer, so no encryption and authentication is provided by the upper layers, the transmission can be eavesdropped, hijacked or manipulated.

  2. Wired Equivalent Privacy, which uses up to four shared-secret keys to “secure” the data transmission at the data-link layer.

    One of these four shared-secret keys must be supplied to a Wireless client wanting to associate with the Wireless Access Point. Since there are only four keys available for WEP, some of them will have to be shared among the Wireless clients when the number of Wireless clients exceeds four.

    This shared-secret scheme is not scalable, and does not cope well with revocation: trying to revoke access to a Wireless client usually means changing all the WEP keys and redistributing them to the appropriate Wireless clients (since the revoked client is usually a person who still knows some WEP keys and his brain can’t be easily modified to make him forget those WEP keys). Redistributing one or more keys to a large population is infeasible with current key distribution mechanisms, so here is where WPA Enterprise comes into play.

To enhance the security in IEEE 802.11, the IEEE 802.11i has been proposed. In addition to introducing protocols for key management and establishment, it also defines encryption and authentication improvements. In order to manage security keys automatically, the IEEE 802.11i has defined algorithms and protocols for key management and establishment. As conventional WEP is known to be vulnerable, the IEEE 802.11i has specified enhanced encryption algorithms to provide stronger privacy. The IEEE 802.11i also incorporates IEEE 802.1x as its authentication enhancement. The IEEE 802.1x standard is a port-based network access control to authenticate and authorize devices interconnected by various IEEE 802 LANs. The IEEE 802.11i is expected to play a critical role in improving the overall security of current and
future WLANs.

The new security standard, 802.11i, which was ratified in June 2004, fixes all WEP weaknesses. It is divided into three main categories:

  1. Temporary Key Integrity Protocol (TKIP) is a short-term solution that fixes all WEP weaknesses. TKIP can be used with old 802.11 equipment (after a driver/firmware upgrade) and provides integrity and confidentiality.
  2. Counter Mode with CBC-MAC Protocol (CCMP) [RFC2610] is a new protocol, designed from ground up. It uses AES [FIPS 197] as its cryptographic algorithm, and, since this is more CPU intensive than RC4 (used in WEP and TKIP), new 802.11 hardware may be required. Some drivers can implement CCMP in software. CCMP provides integrity and confidentiality.
  3. 802.1X Port-Based Network Access Control, either when using TKIP or CCMP, 802.1X is used for authentication.

In addition, an optional encryption method called “Wireless Robust Authentication Protocol” (WRAP) may be used instead of CCMP. WRAP was the original AES-based proposal for 802.11i, but was replaced by CCMP since it became plagued by property encumbrances. Support for WRAP is optional, but CCMP support is mandatory in 802.11i.

The 802.1X-2001 standard states:

“Port-based network access control makes use of the physical access characteristics of IEEE 802 LAN infrastructures in order to provide a means of authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics, and of preventing access to that port in cases which the authentication and authorization fails. A port in this context is a single point of attachment to the LAN infrastructure.” — 802.1X-2001, page 1.

In order to fix the WEP vulnerabilities, the Wi-Fi Alliance took a “snapshot” of the standard (based on draft 3), and called it Wi-Fi Protected Access (WPA). One requirement was that existing 802.11 equipment could be used with WPA, so WPA is basically TKIP + 802.1X.

WPA is not the long term solution. To get a Robust Secure Network (RSN), the hardware must support and use CCMP. RSN is basically CCMP + 802.1X. RSN may also be called WPA2.

If TKIP is used instead of CCMP, it is called Transition Security Network (TSN). TSN is basically TKIP + 802.1X. TSN is also know as WPA.

  • TSN = TKIP + 802.1X = WPA
  • RSN = CCMP + 802.1X = WPA2

Extensible Authentication Protocol

Extensible Authentication Protocol (EAP) [RFC 3748] is just the transport protocol optimized for authentication, not the authentication method itself:

“[EAP is] an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this.” — RFC 3748, page 3

In 802.1X terminology:

  • Supplicant, is a network client asking for authentication in order to access a resource, usually associating with a Wireless Access Point, or requesting access to a wired Ethernet switch.

    The Supplicant must supply some form of credentials to an Authentication Server in order to access the requested resource. This credentials can be in the form of user/password combination, a Kerberos ticket, an X.509 client certificate, and so on.

  • Authenticator, usually acts as a proxy between the Supplicant and the Authentication Server, although in Wireless networks it is itself the resource being requested by the Supplicant: the Wireless Access Point.
  • Authentication Server, is the network component in charge of validating the credentials supplied by the Supplicant.

802.1X uses the Extensible Authentication Protocol (EAP). EAP supports several different authentication mechanisms. Some of them are:

  • EAP-MD5: MD5-Challenge requires username/password, and is equivalent to the PPP CHAP protocol [RFC1994].

    Requests contain a challenge to the end user. CHAP requires the challenge to be encrypted with a shared secret between the Supplicant and the Authentication Server.

    This method does not provide dictionary attack resistance, mutual authentication, or key derivation, and has therefore little use in a wireless authentication enviroment.

    EAP-MD5 should not be used alone, but encapsulated inside some other EAP mechanisms, like EAP-TTLS or PEAP.

  • Generic Token Card (EAP-GTC): This EAP mechanism allows the exchange of cleartext authentication credentials across the network.

    EAP-GTC is usually used as an EAP method to exchange a username and a password, like in PAP (Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol). Since credentials are sent in the clear, it is usually tunneled inside EAP-TTLS or PEAP.

  • Lightweight EAP (LEAP): A username/password combination is sent to a Authentication Server (RADIUS) for authentication. LEAP consists of two MS-CHAP version 1 exchanges. One authenticates the network to the user, and the second authenticates the user to the network. Dynamic keys are derived from the two MS-CHAP exchanges.

    Many of the security problems of LEAP stem from the use of MS-CHAP version 1, which has numerous security problems (like being subject to dictionary attacks).

    LEAP is a proprietary protocol developed by Cisco, and is not considered secure. Cisco is phasing out LEAP in favor of PEAP.

  • EAP-TLS: Creates a TLS session within EAP, between the Supplicant and the Authentication Server. Both the server and the client(s) need a valid X.509 certificate, and therefore a PKI.

    This method provides mutual authentication through certificate exchanges. The user is required to submit a digital certificate to the Authentication Server for validation, but the Authentication Server must also supply a certificate for the user to validate it. The client can check the certificate validity against a list of trusted CA, thus preventing the Wireless client from associating with a rogue Wireless Access Point.

    EAP-TLS provides:

    • Strong cryptographic protection, by providing cryptographic protection of the session.
    • Athentication of both the Supplicant and the Authentication Server, by means of using mutual authentication via X.509 digital certificates.
    • Key derivation, which allows for dynamic keying and alleviates the problems derived from the fact of using static keys.

    The problem with EAP-TLS is that it requires a Public Key Infraestructure, generating and signing digital certificates for both the Authentication Server and any possible Supplicant, which can make it unfeasible for small organizations which lack expertise and knowledge.

    EAP-TLS is described in [RFC2716].

  • EAP-TTLS: Sets up a encrypted TLS-tunnel for safe transport of authentication data. Within the TLS tunnel, (any) other authentication methods may be used.

    EAP-TTLS encapsulates another authentication mechanisms. Thus, EAP-TTLS is usually called the outer authentication, while the tunneled mechanism is usually called the inner authentication.

    EAP-TTLS consists of two phases:

    • Phase 1: A TLS tunnel is established between the Supplicant and the Authentication Server. The X.509 digital certificate of the Authentication Server is used by the Supplicant to verify its identity and thus to validate the network authenticity.

      It is very common for this phase to use an anonymous user to avoid sending any user identity in the clear, supplying the real user identity during the inner authentication.

      This phase is usually called the outer authentication.

    • Phase 2: The TLS tunnel is used to encrypt an older authentication protocol, like an EAP (EAP-MD5, EAP-MSCHAPv2) or non-EAP (PAP, CHAP) authentication protocol that authenticates the Supplicant to the Authentication Server and the network.

      This phase is usually called the inner authentication.

    The difference with respect to EAP-TLS is that only the Authentication Server is required to own a digital certificate (Supplicant certificates are optional). The Authentication Server digital certificate is used in the outer authentication, that is, in order to establish the TLS tunnel from the Supplicant to the Authentication Server.

    EAP-TTLS can tunnel another inner EAP mechanism or an inner non-EAP mechanism. Some non-EAP mechanisms are:

    • PAP (Password Authentication Protocol)
    • PAP (Challenge Handshake Authentication Protocol)

    EAP-TTLS was developed by Funk Software and Meetinghouse, and is currently an IETF draft.

  • Protected EAP (PEAP): Uses, as EAP-TTLS, an encrypted TLS-tunnel. Supplicant certificates are optional, but Authentication Server certificates are required.

    PEAP is very similar to EAP-TTLS, but requires the inner authentication to be another EAP exchange, that is, PEAP can only use EAP-compatible authentication methods. PEAP starts the TLS tunnel, then triggers EAP one more time, encapsulated inside the tunnel, in order to perform the authentication.

    Was developed by Microsoft, Cisco, and RSA Security, and is currently an IETF draft.

  • EAP-MSCHAPv2: Requires username/password, and is basically an EAP encapsulation of MS-CHAP-v2 [RFC2759]. Usually used inside of a PEAP-encrypted tunnel.

    Was developed by Microsoft, and is currently an IETF draft.


I’m going to describe how to configure a Wireless Access Point for WPA/WPA2 Enterprise.

Many modern Wireless Access Points support at least WPA Enterprise. Some do also support WPA2 Enterprise, like Apple’s AirPort Extreme Base Station and AirPort Express Base Station. I will use a D-Link DWL-AP2000+ 802.11g 2.4Ghz Wireless Access Point since it’s cheap, works well and supports WPA Enterprise.

The Supplicant (Wireless client) must also support WPA Enterprise. Mac OS X has a built-in supplicant which is WPA/WPA2 Enterprise compatible. Linux and FreeBSD have wpa_supplicant, which supports many of the EAP authentication mechanisms listed above. I will use Mac OS X built-in Supplicant.

The Authentication Server must run a RADIUS-compatible network daemon. I will use FreeRADIUS 1.0.4 as it is open source, free, works well and supports 802.1X. I will run FreeRADIUS inside an VMware Virtual Machine running Fedora Linux Core Development.

EAP-TTLS requires the use of a X.509 certificate for the RADIUS service. I will use OpenSSL to set up a Certificate Authority and generate a X.509 certificate for the RADIUS service.

I have opted to use EAP-TTLS (outer authentication) with inner PAP since it is natively supported by Mac OS X and wpa_supplicant, and it is easy to configure. The inner PAP is provided via EPA-GTC (Generic Token Card). Since PAP sends user names and passwords in the clear, it must be encapsulated inside an EAP mechanisms that provides protection against replaying, eavesdropping, etc.

Generating the X.509 certificates

For more information on setting up a Certificate Authority (CA), creating the private keys, generating the certificate requests and signing those certificates, read Setting up Certificate Authority (CA) using OpenSSL.

Creating the RADIUS X.509 certificate

Generate a new unsigned certificate and its corresponding private key:

openssl req -new -days 365 -newkey rsa:1024 
  -keyout /etc/pki/CA/sslkey.pem
  -out /etc/pki/CA/sslcert.pem

The -nodes option can be used to avoid using a pass-phrase to protect the private key. This is optional, since FreeRADIUS can use a pass-phrase protected private key with no problems at all.

Signing the RADIUS X.509 certificate

To sign this certificate:

openssl ca -in /etc/pki/CA/sslcert.pem -out /etc/pki/CA/cert.pem

Installing the RADIUS X.509 certificate

The certificate and its corresponding private key, plus the CA certificate, must be installed into /etc/raddb/certs in order to use EAP-TLS or EAP-TTLS:

Install the RADIUS private key:

mv /etc/pki/CA/sslkey.pem /etc/raddb/certs/RADIUS-key.pem

Install the RADIUS signed X.509 certificate:

mv /etc/pki/CA/cert.pem /etc/raddb/certs/RADIUS-cert.pem

Install the CA certificate:

cp /etc/pki/CA/cacert.pem /etc/raddb/certs/cacert.pem

/etc/pki/CA/sslcert.pem holds the unsigned X.509 RADIUS certificate, so it can be safely removed:

rm /etc/pki/CA/sslcert.pem

Configuring FreeRADIUS


The Authenticator will proxy the Supplicant authentication request to the Authentication Server. The Authenticator shares a secret, a pass-phrase, with the RADIUS server. This shared-secret is stored in the /etc/raddb/clients.conf file.

Edit /etc/raddb/clients.conf:

client {
	secret	  = TheSharedSecretBetweenRADIUSAndTheWAP
	shortname = MyNetwork

The client directive specifies the IP subnet from which Supplicants can request authentication via 802.1X. The secret directive specifies the secret shared between the Authenticator (the Wireless Access Point) and the RADIUS server. The shortname directive is a descriptive mnemonic.

The Wireless Access Point must be configured to use WPA Enterprise. The following parameters must be configured:

  • RADIUS Server IP: The IP address of the FreeRADIUS server (
  • RADIUS Port: The port of the FreeRADIUS server (usually 1812/UDP).
  • RADIUS Shared Secret: TheSharedSecretBetweenRADIUSAndTheWAP.


FreeRADIUS stores 1024 bytes of entropy (randomness) in file /etc/raddb/certs/random, but since this is a configuration file, it is usually pre-established. Thus, it is a good idea to reseed it:

dd if=/dev/random of=/etc/raddb/certs/random bs=1 count=1024


  1. Change the default EAP module from EAP-MD5 to EAP-TTLS:

    This can be useful if the Supplicant does not force the EAP method to be an specific one. Since Mac OS X built-in supplicant prefers EAP-TTLS with inner PAP, it is a good idea to change the default EAP method:

            eap {
                    #  Invoke the default supported EAP type when
                    #  EAP-Identity response is received.
                    #  The incoming EAP messages DO NOT specify which EAP
                    #  type they will be using, so it MUST be set here.
                    #  For now, only one default EAP type may be used at a time.
                    #  If the EAP-Type attribute is set by another module,
                    #  then that EAP type takes precedence over the
                    #  default type configured here.
                    default_eap_type = ttls
  2. Make sure the EAP-GTC module is enabled:

    PAP is tunneled inside EAP-TTLS through EAP-GTC:

                    gtc {
                            #  The default challenge, which many clients
                            #  ignore..
                            #challenge = "Password: "
                            #  The plain-text response which comes back
                            #  is put into a User-Password attribute,
                            #  and passed to another module for
                            #  authentication.  This allows the EAP-GTC
                            #  response to be checked against plain-text,
                            #  or crypt'd passwords.
                            #  If you say "Local" instead of "PAP", then
                            #  the module will look for a User-Password
                            #  configured for the request, and do the
                            #  authentication itself.
                            auth_type = PAP
  3. Enable the EAP-TLS module:

    The EAP-TTLS module depends on EAP-TLS, so EAP-TLS, which is disabled by default, must be enabled:

                    tls {
                            # Use private_key_password if the RADIUS private key,
                            # stored in RADIUS-key.pem, was protected by a
                            # pass-phrase when it was generated.
                    #       private_key_password = whatever
                            private_key_file = ${raddbdir}/certs/RADIUS-key.pem
                            #  If Private key & Certificate are located in
                            #  the same file, then private_key_file &
                            #  certificate_file must contain the same file
                            #  name.
                            certificate_file = ${raddbdir}/certs/RADIUS-cert.pem
                            #  Trusted Root CA list
                            CA_file = ${raddbdir}/certs/cacert.pem
                            dh_file = ${raddbdir}/certs/dh
                            random_file = ${raddbdir}/certs/random
                            #  This can never exceed the size of a RADIUS
                            #  packet (4096 bytes), and is preferably half
                            #  that, to accomodate other attributes in
                            #  RADIUS packet.  On most APs the MAX packet
                            #  length is configured between 1500 - 1600
                            #  In these cases, fragment size should be
                            #  1024 or less.
                    #       fragment_size = 1024
                            #  include_length is a flag which is
                            #  by default set to yes If set to
                            #  yes, Total Length of the message is
                            #  included in EVERY packet we send.
                            #  If set to no, Total Length of the
                            #  message is included ONLY in the
                            #  First packet of a fragment series.
                    #       include_length = yes
                            #  Check the Certificate Revocation List
                            #  1) Copy CA certificates and CRLs to same directory.
                            #  2) Execute 'c_rehash '.
                            #    'c_rehash' is OpenSSL's command.
                            #  3) Add 'CA_path='
                            #      to radiusd.conf's tls section.
                            #  4) uncomment the line below.
                            #  5) Restart radiusd
                    #       check_crl = yes
                           #  If check_cert_cn is set, the value will
                           #  be xlat'ed and checked against the CN
                           #  in the client certificate.  If the values
                           #  do not match, the certificate verification
                           #  will fail rejecting the user.
                   #       check_cert_cn = %{User-Name}
  4. Enable the EAP-TTLS module, which depends on EAP-TLS:
                    ttls {
                            #  The tunneled EAP session needs a default
                            #  EAP type which is separate from the one for
                            #  the non-tunneled EAP module.  Inside of the
                            #  TTLS tunnel, we recommend using EAP-MD5.
                            #  If the request does not contain an EAP
                            #  conversation, then this configuration entry
                            #  is ignored.
                            default_eap_type = gtc
                            #  The tunneled authentication request does
                            #  not usually contain useful attributes
                            #  like 'Calling-Station-Id', etc.  These
                            #  attributes are outside of the tunnel,
                            #  and normally unavailable to the tunneled
                            #  authentication request.
                            #  By setting this configuration entry to
                            #  'yes', any attribute which NOT in the
                            #  tunneled authentication request, but
                            #  which IS available outside of the tunnel,
                            #  is copied to the tunneled request.
                            # allowed values: {no, yes}
                    #       copy_request_to_tunnel = no
                            #  The reply attributes sent to the NAS are
                            #  usually based on the name of the user
                            #  'outside' of the tunnel (usually
                            #  'anonymous').  If you want to send the
                            #  reply attributes based on the user name
                            #  inside of the tunnel, then set this
                            #  configuration entry to 'yes', and the reply
                            #  to the NAS will be taken from the reply to
                            #  the tunneled request.
                            # allowed values: {no, yes}
                    #       use_tunneled_reply = no

    The default_eap_type directive is configured so, by default, EAP-GTC (configured for PAP) is tunneled inside EAP-TTLS. This is EAP-TTLS with inner PAP.


This file holds the credentials for the RADIUS users. In this scenario, every Supplicant must supply valid credentials in order to be able to associate with the Wireless Access Point. Those credentials are stored in this file.

For every user, the file stores its user name and its corresponding password, via the User-Password RADIUS attribute.

A sample /etc/raddb/users file:

"testuser"      User-Password == "secret"
"otheruser"     User-Password == "othersecret"

Testing FreeRADIUS

Once FreeRADIUS has been configured to support EAP-TTLS with inner PAP, we need to check if it starts up properly:

/usr/sin/radiusd -X

If FreeRADIUS is working properly, it should spit out something like this:

Listening on authentication *:1812
Ready to process requests.

If so, press Ctrl+C to stop FreeRADIUS and configure it to start up automatically at next reboot, then start it as a network daemon:

chkconfig radiusd on
service radiusd start

Opening the firewall

Next, punch a hole in the firewall to allow RADIUS traffic to pass in. RADIUS authentication service uses port 1812/UDP and 1812/TCP.

Edit /etc/sysconfig/iptables and add the following to lines at the end of the file, before the -j REJECT rule:

-A RH-Firewall-1-INPUT -p udp -m udp --dport 1812 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 1812 -j ACCEPT

NOTE: This assumes the default firewall configuration used by Fedora, where the INPUT and FORWARD chains are blended together into the RH-Firewall-1-INPUT chain.

Then, restart the firewall:

service iptables restart

Configuring the Supplicant

The Mac OS X Supplicant is very straightforward to set up:

  1. Open the Wireless preferences popup.
  2. Choose Other…
  3. Select “WPA Enterprise” from the Wireless Security dropdown.
  4. Choose “TTLS – PAP” from the 802.1X Configuration dropdown.

    This is not needed if the EAP default module was changed from MD5 to TTLS in the /etc/raddb/eap.conf file.

  5. Enter the Network Name
  6. Enter the credentials into the User Name and Password fields.
  7. Click OK.

The Mac OS X Supplicant will complain that the CA certificate used to sign the RADIUS X.509 certificate is not knowm, that is, the CA certificate is not stored in the Key Ring. This is only a warning, so we can click on Continue to proceed.

The Supplicant should start the EAP-TTLS with inner PAP authentication and, after a few seconds, the Wireless network port should have associated with the Wireless Access Point.

The FreeRADIUS /var/log/radius/radius.log log file should reveal the following entries:

Info: Using deprecated naslist file.  Support for this will go away soon.
Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none?
Info: Ready to process requests.
Info: rlm_eap_md5: Issuing Challenge
Info: rlm_eap_tls:  Length Included
Error:     TLS_accept:error in SSLv3 read client certificate A
Info: rlm_eap_tls:  Length Included
Info:     (other): SSL negotiation finished successfully
Info: rlm_eap_tls:  Length Included

The “Error: TLS_accept:error in SSLv3 read client certificate A” means the Supplicant didn’t supply an X.509 client certificate. This is not exactly an error, since EAP-TTLS does not mandate Supplicants to supply an X.509 client certificate (only EAP-TLS mandates this).

WPA-PSK with WPA2 and SUSE Linux

SUSE Linux 10.0 Beta3 has native support for Wireless network interfaces using open authentication mode, shared-keys (like WEP), pre-shared keys (PSK) and extensible authentication (EAP).

Each network interface is configured using a plain-text file located in /etc/sysconfig/network. The configuration file usually matchs the following patterns:

  1. ifcfg-wlan-bus–
  2. ifcfg-wlan-

The first naming convention is used when SUSE Linux is unable to guess the device’s hardware MAC address, which is very common for Wireless network cards not natively supported by the Linux kernel. For example, the SMC 2835W V3 CardBus NIC only works, at the moment, using ndiswrapper, and it’s usually impossible to guess the card’s MAC address until ndiswrapper is properly configured. Also, this naming convention ties the Wireless card to an specific CardBus slot, since every slot has a different bus address.

The second naming convention is usually used for cards whose MAC address is guessable without assistance from third-party drivers or software. That is the case of my NetGear WG511U which uses an Atheros chip.

It seems SUSE 10.0 Beta3 only supports WPA (TKIP) pre-shared keys and I have bee unable to find a way to tell Yast2 to use WPA2 (AES-CCMP) authentcatio isntead. I have had to do some tweaking to SUSE’s ifup-wireless script in order to make it understand WPA-PSK with WPA2 (AES-CCMP):

--- ifup-wireless.old 2005-08-28 00:03:05.000000000 +0200
+++ ifup-wireless 2005-08-28 00:02:51.000000000 +0200
@@ -498,6 +498,16 @@
echo " psk="$L""
+ *psk2|*PSK2)
+ echo " key_mgmt=WPA-PSK"
+ if [ ${#L} = 64 ]; then
+ echo " psk=$L"
+ else
+ echo " psk="$L""
+ fi
+ echo " proto=WPA2"
+ ;;
# writing a config that tries to match everything
# FIXME: may be not optimal

This patch adds support for WPA2 authentication to /etc/sysconfig/network/scripts/ifup-wireless. In the network interface configuration file, WIRELESS_AUTH_MODE=’psk2′ must be specified in order to use WPA2 authentication protocol (instead of WIRELESS_AUTH_MODE=’psk’ which is the default value assigned by Yast2 when creating the configuration file).

A sample network configuration file:

# File /etc/sysconfig/network/ifcfg-wlan-00:11:22:33:44:55
NAME='Accton Intersil ISL3890 [Prism GT/Prism Duette]'

Note the two highlighted lines:

  1. WIRELESS_AP_SCANMODE=’2′ is used to tell wpa_supplicant not to look for ESSID beacon frames used to advertise Wireless networks, and is usually used when the ESSID, for the Wireless network the interface is about to join, is hidden. Being the ESSID of the Wireless network kept hidden and this option not specified, will render wpa_supplicant unable to join the Wireless network while waiting in an infinite loop for the ESSID being broadcasted in the air.

    ifup-wireless will parse the network interface configuration file and will create a file called /var/run/wpa_supplicant- (where iface is the Linux interface name, like ath0 or wlan1) that will be feeded to wpa_supplicant itself.

  2. WIRELESS_AUTH_MODE=’psk2′ is used with the patched ifup-wireless script in otder to specifiy that WPA-PSK for WPA2 should be used (AES-CCMP) instead of plain WPA (TKIP).

    This will only work after applying the patch at the top to /etc/sysconfig/network/scrips/ifup-wireless.

SMC 2835W V3 and SMC 2802W V2

Yesterday I bought a SMC EzConnect 54g Wireless CardBus adapter for my Linux laptop. There are, at least, two different and incompatible versions of this card. The SMC 2835W V2 uses the Intersil 3890 Prism54 chipset, which is supported natively by Linux Prism54 driver. The SMC 2835W V3, which is the one I bought, isn’t. Fortunately, ndiswrapper fully supports this card by wrapping native Windows NDIS drivers around a linux kernel driver. Also, the same happens with the EzConnect 54g Wireless PCI adapter I bought for my Pentium IV machine, which sports the SMC 2802W V2 chipset. The Prism54 Linux driver doesn’t support this card yet.

The SMC 2802W card I bought looks like this:

SMC2802W V2

The SMC 2835W V3 CardBus NIC I bought looks like this:

SMC2835W V3

In order to use these cards, I downloaded the latest tarball for ndiswrapper from the ndiswrapper site which, at this time, was version 1.1. The tarball comes with a Red Hat .spec file that requires no tweaking, except updating the version tag to 1.1.

rpmbuild -ba ndiswrapper.spec

This will compile the ndiswrapper userspace tools and kernel module against the current kernel source tree which must be available under “/lib/modules/`uname -r`/kernel” (for Fedora Core 4 and later, there exists a kernel-devel package which contains all kernel source files needed to compile out-of-tree kernel modules).

Once compiled, I installed the resulting ndiswrapper and kernel-module-ndiswrapper RPM packages. Next, I copied the Windows XP NDIS driver directly from the CD-ROM supplied with the card itself to the hard disk. The driver is fully contained within the Utility folder inside the CD-ROM:

cd /tmp
mount /media/cdrom
cp -Rdp /media/cdrom/Utility .
cd Utility
ndiswrapper -i SMC2835W.INF

These steps are required to pick the Windows NDIS driver and firmware and make them available to the ndiswrapper kernel module. In fact, the driver files will get copied into “/etc/ndiswrapper/” where equals “2802w” for the SMC 2802W PCI NIC or “2835w” for the SMC 2835W CardBus NIC.

NOTE: The SMC 2835W V3 Windows driver can also be obtained from this link if desired. The SMC 2802W V2 Windows driver can be obtained from this link.

The last step consists in removing the prism54 module that gets autoloaded by udev/hotplug when the card is plugged into any CardBus slot, then modprobing the ndiswrapper kernel module:

modprobe -r prism54
modprobe ndiswrapper

If everything is ok, something like this should get logged to the kernel dmesg ring:

ndiswrapper version 1.1 loaded (preempt=no, smp=no)
ndiswrapper: driver smc2835w (SMC,04/29/2004, loaded
ndiswrapper: using irq 10
wlan0: ndiswrapper ethernet device 00:04:xx:xx:xx:xx using driver smc2835w, configuration file 1260:3890.5.conf
wlan0: encryption modes supported: WEP, WPA with TKIP, WPA with AES/CCMP

Also, it’s possible to use the following command to check the driver loaded:

ndiswrapper -l

Once everything is working, the last steps try to find a wireless network, associate with it and configure the network stack:

iwlist wlan0 scan | grep ESSID

We should choose among the listed ESSIDs or, if the ESSID broadcasting is disabled, an specific, known ESSID.

iwconfig wlan0 essid 
ifconfig wlan0 up

To make the changes permanent, the following command should be used:

ndiswrapper -m

This last command usually appends the following line to “/etc/modprobe.conf”:

alias wlan0 ndiswrapper

This tells the initscripts to modprobe for the ndiswrapper module when trying to bring the wlan0 interface up. Usually, the initscripts do a modprobe during boot, where equals the kernel’s interface name, like eth0, eth1 or wlan0. The previous alias line makes “modprobe wlan0” to become “modprobe ndiswrapper”.

It’s also recommended to add prism54 to udev/hotplug’s blacklist to prevent it from loading on systems where both ndiswrapper and prism54 kernel modules are present:

echo prism54 >> /etc/hotplug/blacklist