AXL version: 11.5
Looks like WLANProfile's schema doesn't include the necessary options for EAP-TLS, and there's server-side breakage as well. The User Certificate attribute is not supported.
Steps to reproduce
- Add WLAN Profile with EAP-TLS option - any user cert option will break
- Do a get on name
- Hey presto, explosions
Firstly, it's not defined in the all schemas:
ns0:XWLANProfile(name: xsd:string, description: xsd:string, ssid: xsd:string, frequencyBand: , userModifiable: , authMethod: , userName: xsd:string, password: xsd:string, pskPassphrase: xsd:string, wepKey: xsd:string, passwordDescription: xsd:string, networkAccessProfile: ns0:XFkType)
ns0:RWLANProfile(name: xsd:string, description: xsd:string, ssid: xsd:string, frequencyBand: , userModifiable: , authMethod: , userName: xsd:string, password: xsd:string, pskPassphrase: xsd:string, wepKey: xsd:string, passwordDescription: xsd:string, networkAccessProfile: ns0:XFkType, uuid: ns0:XUUID)
ns0:LWLANProfile(name: xsd:string, description: xsd:string, ssid: xsd:string, frequencyBand: , userModifiable: , authMethod: , userName: xsd:string, password: xsd:string, pskPassphrase: xsd:string, wepKey: xsd:string, passwordDescription: xsd:string, networkAccessProfile: ns0:XFkType, uuid: ns0:XUUID)
Secondly, if I do a GUI add, then try to a get on this, I get a server-side failure:
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Body>
<ns0:getWLANProfile xmlns:ns0="http://www.cisco.com/AXL/API/11.5">
<name>axl_get</name>
</ns0:getWLANProfile>
</soap-env:Body>
</soap-env:Envelope>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring/>
<detail>
<axlError>
<axlcode>-1</axlcode>
<axlmessage/>
<request>getWLANProfile</request>
</axlError>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
If I try again with a profile option that contains a password, it works just fine.
Clearly cannot handle the userCertificate attr (deducing name from UI page source). Seems to start with the server-side demand for userid/password to be specified... Not really used for EAP-TLS. There are other bugs here for cases where you're forced to send blank passwords even when they're not in use...
So, presumably bug?
