Hi Bryan,

Could you help me out with writing the file please? 

I have already posted a thread about my problem. http://forum.eeeuser.com/viewtopic.php?id=1787

Thank you

Thanks for your reply. I'll try it when I get my Eee PC next week. Does that configuration just work for WPA or can it be used with WPA2?

Last edited by vision-b (2007-11-10 5:53:53 pm)

vision-b wrote:

Hi Bryan,

Could you help me out with writing the file please? 

I have already posted a thread about my problem. http://forum.eeeuser.com/viewtopic.php?id=1787

Thank you

Looking through my other machine's docs... wpa_supplicant comes with a number of example configurations, including one that may match the one you need.
Go here:
http://hostap.epitest.fi/wpa_supplicant/
Near the bottom of the page is a section called "Configuration file".  This should help you out.

AutomaticPixel wrote:

What needs to be put in if we are connecting to a CA server instead of storing the certs locally?

If you don't want to verify the server certificate... try just commenting out (or removing) the ca_cert line.  I'm not entirely sure this will work for you, since I cannot try this myself.

A lot of explanation of this configuration file is found here
http://hostap.epitest.fi/gitweb/gitweb. … icant.conf

I hope I don't seem to "It is in the manual"-ish.  I just don't have a network like yours to test out different configurations.

Good luck.

Bryan wrote:

I hope I don't seem to "It is in the manual"-ish.  I just don't have a network like yours to test out different configurations.

Good luck.

Don't worry. You've been very helpful

I'll have to try it out myself to see if it works.

Bryan wrote:

Here's my steps:

1.  Using the "Network" button in the "Internet" tab, created a new "Local Area Network - Wireless" with the connection wizard.
     When it asked for Network name (SSID)... just put in something stupid that I would recognize latter.  E.g. "Poopoohead"
     Also made it to automatically start on boot... (up to you about this)

The wizard insists on asking for other settings as well, which it then places in the /etc/network/interfaces file.

What should be answered for these settings?  Do any of the lines in the /etc/network/interfaces file end up conflicting with what wpa_supplicant does?  I am guessing that I should just enter no encryption at all in the wizard, and let the manual wpa_supplicant.conf file take care of it.  Is this correct?

Josh

Bryan wrote:

I just put stuff in there that I knew I could remember to remove from the interfaces file, when I went to edit it.  You're right... if you enter no encryption it should probably still work because wpa_supplicant is taking care of that overhead.  Still need to put in and remove the SSID.

Thanks.  I told the wizard to use no encryption at all.  Here's the resulting content from my /etc/network/interfaces file (after being edited to include wpa_supplicant):

iface lan3 inet manual
    down dhclient3 -r -pf /var/run/dhclient.$IFACE.pid -lf /var/run/dhclient.$IFACE.leases $IFACE
    down ifconfig $IFACE down
    up wpa_supplicant -B -iath0 -Dmadwifi -c/etc/wpa_supplicant.conf
    up ifconfig $IFACE up
    up dhclient3 -cf /etc/dhcp3/dhclient.$LOGICAL.conf -pf /var/run/dhclient.$IFACE.pid -lf /var/run/dhclient.$IFACE.leases $IFACE
    wireless-key off
    wireless-keymode open
    wireless-mode auto
    wireless-rate auto

And, here's my /etc/wpa_supplicant.conf file:

ctrl_interface_group=0
eapol_version=1

#Sets AP sellection to be handled by wpa_supplicant or the driver.  
# 0=driver 1=wpa_supplicant
ap_scan=1

fast_reauth=1

#Begin Network Block
#--------------------------------

network={
        ssid="MY_ESSID_HERE"
        scan_ssid=1
        proto=WPA
        key_mgmt=WPA-EAP
        pairwise=TKIP
        eap=PEAP
        ca_cert="/etc/certs/MY_CERTIFICATE_HERE.der"
        identity="MY_USERNAME_HERE"
        password="MY_PASSWORD_HERE"
    phase1="peaplabel=0"
    phase2="auth=MSCHAPV2"
    priority=1
}

I was following other articles here and tried to follow some of their suggestions.  Added fast_reauth, among others.

This is for a WPA network (not WPA-PSK).  I was given 4 things: a username, a password, the ESSID of the access point, and a certificate file in DER format.

I'm to use TKIP data encryption, EAP authentication, PEAP authentication type, MSCHAPv2 authentication method.

The interface seems to come up, and wpa_supplicant is called, but it just loops through and never completes the negotiation.  I ran wpa_supplicant again from the command line with debugging turned on (used -d instead of -B option).

I see that it correctly discovers the access point, begins negotiation, then fails somewhere and goes back to a quiet state for a few seconds, then re-scans and loops around, picking up the access point again.  It never succeeds.

The openssl messages appearing in the text spew from wpa_supplicant claim that the DER certificate was correctly parsed.  Its contents appear good.  I'm not really sure what the certificate is for.

There might be errors around the EAP authentication process.  The text spew is very large, so don't really want to paste it here (yet).  Are there any known problems with the EEEPC's supplied wpa_supplicant program being able to handle EAP?  Maybe I should try to grab another version of wpa_supplicant?

BTW, is there any way to provide the Windows domain (this authentication is done through servers running Windows)?
I will most likely need to provide this to wpa_supplicant somehow, in addition to username and password.  Is there a field for adding this to the wpa_supplicant.conf file?

Thanks for your help here!

Josh

Same issue at my school.  I'm very interested in getting this fixed.

Krellan wrote:

Downloaded madwifi and wpa_supplicant from source, to try and recompile wpa_supplicant and enable all of the various PEAP combinations, since the best guess so far is that Asus forgot to include some of them.  That might explain why it gives errors about an unsupported authentication method.

Right... in my case (for my work network), we require MSCHAPV2 authentication.  Trying to insert this option into the phase2 portion gave me a "Unsupported" warning.  Blah.  Looks like that option wasn't compiled into xandros-wpa-supplicant.

Krellan wrote:

Tried to compile wpa_supplicant, by using the headers in madwifi, but not actually wanting to recompile madwifi (since Asus might have made some customizations).

Unfortunately, there's a version mismatch.  My new wpa_supplicant compiles perfectly, but when running it, I get ioctl() errors about "Argument list too long" and so forth.  So, no luck, it appears to run normally but doesn't see the wireless AP at all, since it can't correctly communicate with the madwifi driver.

I need to figure out what version of madwifi was used by Asus, and try to match that.  I also could try recompiling madwifi, taking the risk of losing any Asus customizations, but would need the kernel headers to do that.  Are the kernel headers available on Asus's Debian repository?  Did Asus make any modifications to madwifi?

I got similar (perhaps exactly the same) results when I tried using the wpasupplicant provided by the xnv4.xandros.com repo.  I figured that whoever put together the xandros-wpa-supplicant package hacked with wpa_supplicant... but you may be right about the hack to the driver itself.  If that's true... maybe those changes will trickle down into the stable version of madwifi.

It'd be nice if there was some sort of changelog that noted some of these hacks.

Anyone attempted to use xsupplicant for WPA-EAP? 

If not... I'll give this a go in the next day or so.  I'm hoping it'll be less dependent on the device driver.

Krellan wrote:

Did you have any luck finding the kernel headers for Asus's build of the EEEPC kernel?  Without them, I can't recompile madwifi.  So, I'm at a dead end here.

I'm unsure if it's a version clash or not.  The versions of madwifi and wpa_supplicant that Asus used seem to be fairly recent.  Still, it's unclear why the ioctl()'s have been shuffled around.  The upstream wpa_supplicant, when compiled with the headers from the latest upstream madwifi, tries to use ioctl()'s that are not understood by Asus's kernel drivers.

I wonder how much Asus's kernel drivers differ from the upstream madwifi kernel drivers?  From looking at version strings and such, I'm pretty sure they have a common ancestor in madwifi.  So, isn't Asus supposed to provide source, under the GPL, for everything in madwifi (except the binary-only Atheros HAL)?

I'm currently downloading the huge zip file containing the "source" from the Asus webpage.  I was hoping that it would contain the source for the wpa_supplicant, so that we might be able to compile in the necessary options for EAP.  I've been downloading since yesterday... the dl rate is SLOW (~20K/s).

Looking through the forum, looks like people have been able to get EAP to work using ndiswrapper.  However, the kernel supplied with the default Xandros Eeepc, does not include the ndiswrapper driver.  Damnation. 

Is madwifi GPL?  I did a quick glance through their website, and I didn't see anything regarding GPL.  Maybe a more detailed look would reveal it.

Ugh.  Maybe I should just switch to (k)Ubuntu.