receiverbox
Goto Top

Conf-Probleme für WPA beim Cisco AP 1231G

Hallo,

ich habe meinen AP Cisco AP1231G wie folgt konfiguriert. Eine ältere Axis-Kamera kann sich über WPA nicht anmelden am CiscoAP1231G. An einem Consumer-Gerät geht es einwandfrei (WPA-PSK und gleicher Schlüssel). Ich nehme an, dass ich die Einstellungen noch etwas "laxer" macher muss, damit die Kamera reingeht. Laut Config-GUI der Kamera kann diese "nur" WEP oder WPA aber nicht WPA2. Nur wo muss ich drehen??

!
version 12.3
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname AP1231G-St
!
!
ip subnet-zero
!
!
aaa new-model
!
!
aaa authentication login default local
aaa authorization exec default local
aaa session-id common
dot11 syslog
dot11 vlan-name Native vlan 1
!
dot11 ssid st21
vlan 1
authentication open
authentication key-management wpa
mbssid guest-mode
wpa-psk ascii 7 xxxxxx
!
!
!
username admin privilege 15 password 7 xxxxxx
!
bridge irb
!
!
interface Dot11Radio0
no ip address
no ip route-cache
!
encryption mode ciphers aes-ccm tkip
!
encryption vlan 1 mode ciphers aes-ccm tkip
!
ssid st21
!
mbssid
speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 54.0
channel 2447
station-role root
no dot11 extension aironet
!
interface Dot11Radio0.1
encapsulation dot1Q 1 native
no ip route-cache
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
bridge-group 1 spanning-disabled
!
interface Dot11Radio0.2
encapsulation dot1Q 2
no ip route-cache
bridge-group 2
bridge-group 2 subscriber-loop-control
bridge-group 2 block-unknown-source
no bridge-group 2 source-learning
no bridge-group 2 unicast-flooding
bridge-group 2 spanning-disabled
!
interface FastEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
!
interface FastEthernet0.1
encapsulation dot1Q 1 native
no ip route-cache
bridge-group 1
no bridge-group 1 source-learning
bridge-group 1 spanning-disabled
!
interface FastEthernet0.2
encapsulation dot1Q 2
no ip route-cache
bridge-group 2
no bridge-group 2 source-learning
bridge-group 2 spanning-disabled
!
interface BVI1
ip address 10.0.8.202 255.255.0.0
no ip route-cache
!
ip default-gateway 10.0.0.100
ip http server
ip http authentication aaa
no ip http secure-server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
!
bridge 1 route ip
!
!
!
line con 0
line vty 0 4
!
end

Content-ID: 256317

Url: https://administrator.de/contentid/256317

Ausgedruckt am: 05.11.2024 um 23:11 Uhr

aqui
aqui 30.11.2014, aktualisiert am 06.06.2021 um 15:09:58 Uhr
Goto Top
Wenn möglich solltest du immer auf die TKIP Cipher Suite verzichten ! Zu WPA-2 gehört eigentlich nur AES-CCMP.
Testweise also mal weglassen.
Das Passwort und die SSID sollten keine Sonderzeichen enthalten !
Außer no dot11 extension aironet kannst du mit world-mode dot11d country-code DE both noch den EU konformen Betrtieb des Clients erzwingen sofern der 802.11d supportet. Manche Clients möchten das gerne.

Ansonsten steht hier genau beschrieben wie das einzurichten ist:
Cisco WLAN Access Points 1142N, 2702, 3702 für den Heimgebrauch umrüsten
receiverbox
receiverbox 30.11.2014 um 18:37:13 Uhr
Goto Top
Da der WLAN-Client kein WPA2 kann, habe ich TKIP und AES-CCMP gewählt. Die Konfiguration mit nur AES-CCMP hatte auch nicht funktioniert.

Kann ich mit den Logging-Mechanismus den Handshake beobachten und nachvollziehen warum der Client keine Verbindung aufbauen kann?
aqui
aqui 01.12.2014 aktualisiert um 09:13:09 Uhr
Goto Top
kein WPA2 kann, habe ich TKIP und AES-CCMP gewählt.
Das hast du aber oben nicht geschrieben !!
Dann ist AES natürlich Blödsinn, denn dann gibt es das gar nicht, denn WPA kann nur TKIP. Dann definierst du also am besten kein WPA-2 sondern nur WPA und einzig TKIP in der Cipher Suite und lässt den Rest weg, das macht dann keine Negotiation sondern erzwingt dann WPA mit TKIP.
Ist leider immer die Crux bei billige Taiwan Client Hardware die kein vollständiges 802.11 WLAN implementiert hat face-sad
Kann ich mit den Logging-Mechanismus den Handshake beobachten und nachvollziehen
Ja natürlich kannst du das ! Sollte man als Cisco AP User aber eigentlich auch wissen ?! Gib auf dem CLI:
ap#debug dot11 ?
  Dot11Radio         IEEE 802.11 WLAN
  aaa                Authentication, Authorization, and Accounting
  amacdbg            AMAC Debugger Server
  arp-cache          ARP Cache
  beacon             IEEE 802.11 beacon and probe response
  cac                Admission Control
  drv-intf           dot11 driver interface
  events             IEEE 802.11 events
  forwarding         802.11 AP forwarding
  ids                Intrusion Detection System
  ip                 IP Protocols
  l2roam             L2Roam E2E
  lbs                802.11 Location Based Management
  leap-dot1x         802.1X LEAP debugging
  mgmt               802.11 Management
  network-map        Network Map
  packets            IEEE 802.11 packets
  policing           Traffic policing
  rx-filter          802.11 driver rx filter
  station            Debug station connection failures
  supp-sm-dot1x      802.1X supplicant state machine debugging
  tsm                Traffic Stream Metrics
  virtual-interface  802.11 virtual interface
  wpa-cckm-km-dot1x  WPA/WPA-PSK/CCKM supplicant key management debugging 
Das sind die Debuggings die du im WLAN ausführen kannst. Events, packets und ganz besonders station und wpa-cckm... sollten dir helfen !
Ein show logg zeigt dir zudem das AP Log an was du am besten vorher mit clear logg löschen solltest wenn du den Connect Versuch machst.

Wenn du per Telnet Terminal auf dem AP bist vergiss nicht terminal monitor einzugeben sonst kannst du die Debug Message online nicht sehen sondern nur im Log !
Zum Schluss ein undebug all nicht vergessen um das Debugging wieder auszuschalten !
receiverbox
receiverbox 01.12.2014 um 10:17:24 Uhr
Goto Top
Danke für die wertvollen Tipps. Bin zwar Cisco User, aber nur "Consumer Level" bisher face-wink
receiverbox
receiverbox 01.12.2014 um 18:50:30 Uhr
Goto Top
Hallo, offensichtlich war tatsächlich das Passwort zu komplex. Allerdings konnte ich weder über

debug dot11 station, events, wpa-cckm.... oder packets irgendeinen Verbindungsversuch feststellen.

Kann natürlich auch daran liegen, dass die Kamera-Software sich am PW schon verschluckt hat und gar nicht versucht sich mit dem AP zu connecten.

Oder habe ich nur die falschen Debug paramter genommen??
aqui
aqui 01.12.2014 um 19:41:56 Uhr
Goto Top
Vermutlich die falschen Parameter ?!
Konntest du wenigstens sowas wie:
Nov 26 17:22:42: %DOT11-4-MAXRETRIES: Packet to client 1234.f4e6.223a reached max retries, removing the client
Nov 26 17:22:42: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 1234.f4e6.223a Reason: Previous authentication no longer valid
Nov 26 19:48:59: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 1234.f4e6.223a Reassociated KEY_MGMT[WPAv2 PSK]
Nov 26 20:00:36: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 1234.f4e6.223a Reason: Sending station has left the BSS

sehen ?
debug dot11 aaa all sollte auch was zeigen.