You are not logged in.
Hello,
Since this weekend I have a new connection to the cruel world wide web. With this connection I got a kind of router, called "Experia Box", which routes all my VoIP and internet stuff. It also has a wireless card in it, which works sends out an signal.
My provider gave me the WPA-PSK for this signal, but it's a 26 char long hex string, and if I fill this in my wpa_supplicant.conf, it doesn't work. I guess wpa_supplicant wants to have the ASCII password, which I don't have.
Is there a way to fix this and let wpa_supplicant work with my 26 char hex string?
Thanks in advance
All you got to do, is tell the story right...
Offline
If this key is ok it should work according to wpa_supplicant docs:
# psk: WPA preshared key; 256-bit pre-shared key
# The key used in WPA-PSK mode can be entered either as 64 hex-digits, i.e.,
# 32 bytes or as an ASCII passphrase (in which case, the real PSK will be
# generated using the passphrase and SSID). ASCII passphrase must be between
# 8 and 63 characters (inclusive).
# This field is not needed, if WPA-EAP is used.
# Note: Separate tool, wpa_passphrase, can be used to generate 256-bit keys
# from ASCII passphrase. This process uses lot of CPU and wpa_supplicant
# startup and reconfiguration time can be optimized by generating the PSK only
# only when the passphrase or SSID has actually changed.
Make sure you enterd the key properly like this:
psk=03101c71c6abf8827293f44d7c13883ec83214fab8ab4069eec737508a7c220a
Offline
mine isn't that long..
This is the part of my config:
network={
ssid="otoria"
scan_ssid=1
psk="c068bac76b29333e95b466585e"
priority=1
}
All you got to do, is tell the story right...
Offline
Michiel,
If that's your PSK, I would recommend changing it. If not, then no worries.... always paranoid on my part.
Have you tried running wpa_supplicant from the command line to determine any errors? Try this:
# wpa_supplicant -c /etc/wpa_supplicant.conf -D (device_type) -i (interface) -dddd
-D is your device type. Mine (ipw2200) is wext. wpa_supplicant --help will list the various cards it can support. -i is your interface (wlanX/ethX or whatever variant your wireless card has choosen).
-dddd puts wpa_supplicant in uber-debug mode. Less d's, less debug. See if you can run it to determine your issue. If need be, post the output here, and we'll go on from there.
-James
James Fryman
Offline
Well, I tried, but i have no clue what could be wrong..
Here is the log: http://hell.freecode.nl/~michiel/wpa.log
Thanks for the help so far
All you got to do, is tell the story right...
Offline
Michiel,
It looks like everything is working just fine, at least according to your logs.
This bit:
CTRL-EVENT-CONNECTED - Connection to 00:01:e3:c4:81:83 completed (auth)
shows that the WPA authentication was successful... but shortly thereafter you manually canceled the supplicant
CTRL-EVENT-TERMINATING - signal 2 received
Do you have a manual IP assigned to your wireless, or is it requested through DHCP? If it's requsted through DHCP, did you try to get a lease?
James Fryman
Offline
This bit:
CTRL-EVENT-CONNECTED - Connection to 00:01:e3:c4:81:83 completed (auth)
shows that the WPA authentication was successful... but shortly thereafter you manually canceled the supplicant
CTRL-EVENT-TERMINATING - signal 2 received
Hmm ok...
Do you have a manual IP assigned to your wireless, or is it requested through DHCP? If it's requsted through DHCP, did you try to get a lease?
Not manual, but through DHCP, I assume the netcfg script tries to get a lease? I didn't tried to get a lease manually yesterday, will try it later today.
Thanks so far
[EDIT]
Ok I tried to request an IP with DHCP, which doesn't work
If I manually assign an IP address, the connection works..
dhcpcd -d (debug) doesn't give any usefull information (only which MAC he uses..) so I have no clue why I don't get a lease..
Little cut from the log:
CTRL-EVENT-CONNECTED - Connection to 00:01:e3:c4:81:83 completed (auth)
...
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
EAPOL: startWhen --> 0
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
CTRL-EVENT-TERMINATING - signal 2 received
All you got to do, is tell the story right...
Offline
If you can access the network when manually assigning a network address, that says to me there is something wrong with your DHCP config, and that your supplicant works just fine.
What does your network-profile script look like? Have you tried to get a dhcp release using the following:
dhcpcd -t 60 wlan0
This will increase the timeout of the DHCP daemon... you may have some network issues where your lease isn't being handed out in a proper amount of time. Try that....
James Fryman
Offline
My network config:
DESCRIPTION="Thuis Wifi"
# Network Settings
INTERFACE="wlan0"
HOSTNAME="vanessa"
IFOPTS="dhcp"
# wifi settings
ESSID="otoria"
#KEY="476c69E50E8774B9A9B2BBD947"
#IWOPTS="mode managed essid $ESSID key restricted $KEY"
IWOPTS="mode managed essid $ESSID channel 1"
WIFI_INTERFACE="wlan0"
WIFI_WAIT=0
USEWPA="yes"
WPAOPTS="-Dwext"
I haven't tried with a timeout of 60 yet, only 30.. Will try 60 in about 10 minutes
Stay tuned
[edit]
60 seconds isn't enough too.. even 90 seconds isn't enough.. I just looked at windows, and windows gets an IP in less then 30 seconds, with DHCP too..
All you got to do, is tell the story right...
Offline
Try this:
# Network Settings
INTERFACE="wlan0"
HOSTNAME="vanessa"
IFOPTS="dhcp"
# wifi settings
ESSID="otoria"
WIFI_INTERFACE="wlan0"
WIFI_WAIT=5
USEWPA="yes"
WPAOPTS="-Dwext"
I'm wondering if your iwoptions are fighting with the network scripts. wpa_supplicant can automatically detect the ESSID and channel, and pass the parameters to wireless_tools.
I'm running out of thoughts here though...
James Fryman
Offline
I'm wondering if your iwoptions are fighting with the network scripts. wpa_supplicant can automatically detect the ESSID and channel, and pass the parameters to wireless_tools.
Without ESSID it won't work i guess, my router doesn't advertise his ESSID so you have to set it yourself..
I'll try without the channel this afternoon
I'm running out of thoughts here though...
Me too
Thanks anyway
[edit]
Doesn't work
All you got to do, is tell the story right...
Offline
Hey!
I just read very fast through this... so it might be a stupid suggestion.
Have you tried to enter the password without the quotes?
I think it wpa_supplicant interprets the text inside the quotes as ASCII, if no quotes then it its hex.. (I think)
- Edson
- Edson
Offline
Have you tried to enter the password without the quotes?
I think it wpa_supplicant interprets the text inside the quotes as ASCII, if no quotes then it its hex.. (I think)
I did, it doesn't work. So I guess this hex like string is my PSK.
I just noticed 2 lines in my `dmesg`:
ipw2200: Unknown notification: subtype=40,flags=0xa0,size=40
wlan0: no IPv6 routers present
So maybe there is a bug in the ipw2200 driver which is build in the arch kernel. Will look at it later this week
All you got to do, is tell the story right...
Offline
My modem firmware was upgraded today and it works o/
However, during my pacman -Syu session I lost my connection twice. I just upgraded kernel and ipw firmware, so I keeps working now
All you got to do, is tell the story right...
Offline