Thursday, August 21, 2008

Backup data with bcp

What I wanted was not to have more of two months of data online in my table. In order to do accomplish this task I decided to use Ms SQL Server's Bulk Copy Program (bcp).

Here's the MSDN page on bcp usage :
http://msdn.microsoft.com/en-us/library/ms162802.aspx

Then, using osql (MSDN) I'll clean up the table of the rows backupped.

In my table there's a field named dtRow which contains the timestamp as UTC.

I wrote this little batch :

@echo off

:CHECK_ARGUMENTS
if "%1"=="" goto PRINT_USAGE
if "%1"=="-?" goto PRINT_USAGE

:CHECK_ARG_DIRECTION
if "%1"=="in" goto RESTORE_AREA
if "%1"=="out" goto BACKUP_AREA

goto PRINT_USAGE

:BACKUP_AREA

:CHECK_ARG_DAYS
if %2==-d goto CHECK_ARG_DAYS_2
if not %1==-d goto PRINT_USAGE
:CHECK_ARG_DAYS_2
if not "%3"=="" goto CHECK_ARG_PATH
goto PRINT_USAGE

:CHECK_ARG_PATH
if not "%4"=="" goto CHECK_BCP
goto PRINT_USAGE


:CHECK_BCP
echo Looking for BCP....
IF EXIST %PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\bcp.exe GOTO CHECK_BCP_OK ELSE GOTO CHECK_BCP_KO

:CHECK_BCP_OK
echo BCP exists.
goto CHECK_OSQL

:CHECK_BCP_KO
echo BCP does not exist!!.
goto EXITPROGRAM


:CHECK_OSQL
echo Looking for OSQL....
IF EXIST %PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\osql.exe goto CHECK_OSQL_OK ELSE GOTO CHECK_OSQL_KO

:CHECK_OSQL_OK
echo OSQL exists.
goto BACKUP_DATA


:CHECK_OSQL_KO
echo OSQL does not exist!!.
goto EXITPROGRAM


:BACKUP_DATA
ECHO BACKUP DATA....
SET query="SELECT * FROM MyDB.dbo.MyTable WHERE dtRow > ((SELECT TOP 1 dtRow FROM MyDB.dbo.MyTable ORDER BY dtRow DESC) - 86400*%3)"

"%PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\bcp.exe" %query% queryout %4 -N -U sa -P sa -S.\SQL2000

IF not %ERRORLEVEL%==0 goto ERROR_BACKUP

:DELETE_DATA
ECHO.
ECHO DELETING SAVED ROWS
SET query="DELETE FROM MyDB.dbo.MyTable WHERE dtRow > ((SELECT TOP 1 dtRow FROM MyDB.dbo.MyTable ORDER BY dtRow DESC) - 86400*%3)"

"%PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\osql.exe" -S.\SQL2000 -U sa -P sa -d MyDB -Q %query%

ECHO Done.

goto EXITPROGRAM


:RESTORE_AREA
echo RESTORING DATA....
"%PROGRAMFILES%\Microsoft SQL Server\80\Tools\Binn\bcp.exe" MyDB.dbo.MyTable in %4 -N -U sa -P sa -S.\SQL2000
ECHO Done.

goto EXITPROGRAM

:PRINT_USAGE
ECHO Simple Backup Utility
ECHO Usage : obu {in | out} -d days path
ECHO days : Number of days to backup
ECHO starting from the last record.
ECHO path : Path of the backup file.

:ERROR_BACKUP
echo Error during backup phase. Aborting...
goto EXITPROGRAM

:EXITPROGRAM

Cisco and Nokia Dual Mode Part IV : SIP

Now time's to try the embedded SIP client on the Nokia devices.

As for reference I started with the Cisco manual (quite clear) :
http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/admin/6_0_1/ccmcfg/b09sip3p.html

then I continued sniffing with wireshark the SIP registration (which failed), and at last I found the last useful clues on the Cisco NetPro Forum (thanks Ron!)

I decided to try with the Third Party Basic SIP device, however procedure for the Advanced  SIP device is almost the same.

So at last here's  the working configuration :

First configure the CUCM :

Get to System->Security Profile->Phone Security Profile and copy the Third-party SIP Device Basic - Standard SIP Non-Secure Profile and rename it (I used Third-party SIP Device Basic - LAB SIP Non-Secure Profile) and check the Enable Digest Authentication option. Leave unchanged the other settings.



Add the device as a Third-party SIP Device (Basic), set the phone's mac address (here's how to get it) and be sure to set this settings :
Device Security Profile to the security profile yuo've created previously
Digest User to your End User

 
 


Define the DN for your device.

In the End User configuration set the digest credentials (an alphanumeric password) and make the device association with the SIP phone.

Then it's time to configure the Nokia phone :

First get to Tools->Settings->SIP settings and create a new SIP profile :
Profile name :SIP
Service profile : IETF
Default access-point :<your access point>
Public username : sip:<dn>@><cucm ip>
Use compression : No
Registration : Always on
Use security : No

Proxy server
Proxy server address : sip:<cucm ip>
Realm : ccmsipline
Username : <End user userid>
Password : <Digest credentials>
Allow Loose routing : Yes
Transport type : UDP
Port : 5060

Registrar server
Registrar serv. addr. : sip:<cucm ip>
Realm : ccmsipline
Username : <End user userid>
Password : <Digest credentials>
Transport type : UDP
Port : 5060


Then get to Tools->Settings->Internet tel. settings and create a new SIP profile :
Name : Cisco SIP
SIP profile : SIP

Et voilĂ , if WLAN configuration is correct, you should see the phone register immediately.

Tuesday, August 19, 2008

Cisco and Nokia Dual Mode Part III : Mobility my way

After having configured the networking part of the problem here and then refined roaming here, time's to expose the Communications Manager side.

Targets were simple :
  • People who have a dual-mode phone should always be reachable via IP if in WLAN coverage, regardless the caller dialed the office number or the mobile number.
  • People who have a dual-mode phone should not be always reachable regardless the number dialed, but only if called on the cellular number, no automatic call diverting from the office number to the mobile number.
  • The configuration should be as simple as possible and possibly cheap in terms of DLU

We decided not to implement the entire Cisco Mobility suite, but a subset of functions so saving DLUs and having the funtionality we needed.

Extension Mobility is enabled on all the IP Phones and users. Each desk phone has a dummy (not valid on the PSTN) line in a partition called Logout, from which can call only other desk phones, logged in users and emergency (there's a transformation pattern to make it exit on the PSTN).

Each user has a device profile with his personal line in a partition called Login (where all the logged in lines are).

Each dual-mode nokia mobile has two lines : the first shared with the device profile, the second belonging to a partition called Dual-Mode, unreacheable by anyone except from a particular CSS used by translation patterns.

This way behavior is :
People dialing the user's line while he is logged off from the desk phone and not under WLAN coverage (away) get fast busy or is redirected to VoiceMail.


People dialing the user's line while he is logged off from the desk phone but he is under WLAN coverage succeed in connecting since the line is active on the mobile through the Nokia IntelliSync Call Connect for Cisco.

People dialing the user's line while he is logged in and under WLAN coverage makes both the phones ring (shared line). Two notes on this : while in conversation on the mobile you can put the call on hold and then resume it from the desk phone (useful if you answer while away and the you reach your office), if you answer from the desk phone while both ringing, on the mobile you'll find a fake missed call.

People dialing the user's mobile number while he is under WLAN coverage will have their call translated to the "hidden" line on the mobile so using VoIP.

People dialing the user's mobile number while he is not under WLAN coverage will have their call translated to the "hidden" line on the mobile which have a call forward unregistered entry to the real mobile number.

Here's how this is configurated :

Partitions :
Logout : All the devices with no device profile logged in.
Login : All the lines of the device profiles
DualMode : All the "hidden" second lines on the nokia mobiles.

Desk Phone :
1000 in Logout partition.

Device Profile :
2000 in Login partition.


Mobile Phone :
2000 in Login partition.

7000 in DualMode partition.
Call Forward Unregistered on #3331234567 (mobile number)

Translation Pattern :
03331234567 becomes 7000
This one makes people looking for you on the mobile being translated on VoIP.

Route Pattern :
#.[3]! -> PreDot discard and prepend 0.
If you are not under WLAN coverage, the CFU to #3331234567 is routed to your real mobile. This is necessary because redirecting on the real number (03331234567) would meake the call enter a loop (the above mentioned translation pattern...)

Here's some self-explaining slides :

Monday, August 18, 2008

Cisco and Nokia Dual-Mode Part II : CCKM


After having made everything work with EAP-MSCHAPv2 (check out chapter one) I started the fine tuning session, thus finding some roaming issues.

In the Nokia IntelliSync Call Connect Datasheet (here) it is clear that the E-series are CCXv3 compatible.

On the Cisco side, this document says that CCKM with EAP-PEAP (MSCHAP) authentication is supported only with CCXv4 compatible devices.

Finally, the authentication provided by MS IAS on our infrastructure do not support LEAP (alternative to PEAP) so we need to move to a Cisco RADIUS authenticator i.e. ACS (at least in this phase, later we'll use the Cisco ACS 4 as a proxy vs. domain authentication).



Ok, we have to move from EAP-PEAP (MSCHAPv2) to EAP-LEAP protocol authenticating on Cisco ACS.

Here's the cisco doc on configuring the Cisco ACS for LEAP.

Once configured, we'll have to change both WLC and Phone's configuration.

The Wireless LAN Controller (from WCS):





Note on the last tab that DHCP Addr. Assignment Required should UNchecked otherwise you could ask for a new IP at each roaming session.

The Nokia Phone :

-Connection name : VoWLAN
-Databearer : Wireless WAN
-WLAN netw. name: TEST-ACS
-Network status: Hidden
-WLAN netw. mode: Infrastructure
-WLAN security mode: 802.1x (NOT WPA/WPA2)
-WLAN security settings :
--WPA mode: EAP
--EAP plug-in settings:
---EAP-LEAP (select only this, put in the higher position and disable all the others) :

---EAP-LEAP Configuration :
----User name: [Your radius user name]
----Prompt password: No
----Password: [Your radius password]


Now set this connection in the SCCP Profile and the registration to Always On (in chapter one you can find more info and links on this).

How can I see if CCKM is active ? Obviously user experience is useful, i.e., fast roaming is easily noticeable when speaking and walking togheter. However sometimes you could experience some holes in conversation without knowing if you have misconfigured CCKM or the WLAN coverage is not excellent, or both.

Debugging a client on the WLC will give you immediate evidence on this.

This Cisco doc is very useful to understand the entire process, however simply checking for a simple word in the debug output is simpler :

On the WLC issue the command "debug client [mac address of the Nokia device]" (here's how to see the nokia device's WLAN mac address).

Now start a conversation (ip obviously) with the nokia device and start walking so forcing a roaming. Each roaming makes the debug session display a huge amount of information about authentication, dot1x, etc (debugging...).
If CCKM is well configured, you should see in the roaming session output

CCKM: Mobile is using CCKM

and NOT see

Received EAPOL-key in REKEYNEGOTIATING state


If you normally experience correct fast roaming (CCKM) sessions and only sometimes you find key renegotiation (together with worse user experience) then you should check WLAN coverage in that areas, however CCKM should be well configured.

Hope this helps.

Wednesday, August 13, 2008

Cisco ACE and Private VLANs in Switch Mode

This one comes from the esigence to create a housing zone with a shared load balancer. The idea is to keep things as simple as possible providing isolation and all advanced load balancing feature.
So there will be only one vlan for one-armed servers and isolation will be provided by Private VLANs. However, being the ACE shared across the pvlans I had to add access lists to control traffic from one pvlan through another's vip.
Another element of simplicity in this design is the ACE module in switch-mode, this way providing a unique default gateway for all the servers (loadbalanced and not).

The network diagram :

The ACE configuration :

switch-mode

rserver host SERVER-10.1
ip address 10.0.10.1
inservice
rserver host SERVER-10.2
ip address 10.0.10.2
inservice

serverfarm host LAB-A_20.1:80
rserver SERVER-10.1 80
inservice
rserver SERVER-10.2 80
inservice

serverfarm host LAB-B_21.1:80
rserver SERVER-10.3 80
inservice
rserver SERVER-10.4 80
inservice


class-map match-any L4-SNAT
2 match source-address 1.0.10.0 255.255.255.0


class-map match-all L4-LAB-A_20.1:80
2 match virtual-address 10.0.20.1 tcp eq www

class-map match-all L4-LAB-B_21.1:80
2 match virtual-address 10.0.21.1 tcp eq www


policy-map type loadbalance first-match L7-LAB-A_20.1:80
class class-default
serverfarm LAB-A_20.1:80


policy-map type loadbalance first-match L7-LAB-B_21.1:80
class class-default
serverfarm LAB-B_21.1:80


policy-map multi-match L4-POLICYMAPMULTI
class L4-SNAT
nat dynamic 10 vlan 100
class L4-LAB-A_20.1:80
loadbalance vip inservice
loadbalance policy L7-LAB-A_20.1:80
loadbalance vip icmp-reply active
class L4-LAB-B_21.1:80
loadbalance vip inservice
loadbalance policy L7-LAB-B_21.1:80
loadbalance vip icmp-reply active

service-policy input L4-POLICYMAPMULTI


interface vlan 100
description SERVERSIDE
ip address 1.1.1.200 255.255.255.0
no normalization
no icmp-guard
nat-pool 10 10.0.100.1 10.0.100.15 netmask 255.255.255.224 pat
no shutdown
interface vlan 150
description FIREWALLSIDE
ip address 1.0.0.2 255.255.255.0
no normalization
no icmp-guard
no shutdown

ip route 0.0.0.0 0.0.0.0 1.0.0.1

The router's configuration :



svclc module 11 vlan-group 100
svclc vlan-group 100  10,20,100,150

vlan 10
  private-vlan community

vlan 20
  private-vlan community

vlan 100
  name SERVERSIDE
  private-vlan primary
  private-vlan association 10,20

vlan 150
 name P2P-C65-ACE

interface Vlan100
 ip vrf forwarding LAB
  private-vlan mapping 10,20
 
interface Vlan150
 ip vrf forwarding LAB
 ip address 10.0.0.1 255.255.255.240

As usual, on the ACE there's a nat pool to permit server to server load balancing, further information here and here.
"Horizontal" connections across the VLAN's broadcast are prevented by the private vlans' mechanism. However, a server belonging to the PVLAN A can connect to a VIP belonging (logically, as VIPs on the ACE are not PVLAN aware) to PVLAN B.
Being the ACE the default gateway, default behavior must be permit ip any any. Using access-lists and object-groups I created a matrix of negations between real servers on each pvlan versus all the VIPs of the other PVLANs :

object-group network GROUPA
host 10.0.10.1
host 10.0.10.2
object-group network GROUPB
host 10.0.10.3
host 10.0.10.4
object-group network VIPSGROUPA
host 10.0.20.1
object-group network VIPSGROUPB
host 10.0.20.2

access-list ACL01 line 7 extended deny ip object-group GROUPA object-group VIPSGROUPB
access-list ACL01 line 11 extended deny ip object-group GROUPA object-group VIPSGROUPB
access-list ACL01 line 15 extended permit ip any any
access-group input ACL01


Again, many thanks to Daniele and Marco   for support on the lab.

Tuesday, August 12, 2008

Asymmetric Server Normalization on Cisco ACE

Summertime, I've some time to spend in the lab to try some new scenarios, optimization or try something read on the release notes.
This scenario is mostly a proof of concept as in our DataCenter many applications use server to server load balancing and it requires a too messy configuration to make it work with ASN.
From the Cisco doc :
Asymmetric Server Normalization (ASN) allows the ACE to load balance an initial request from the client to a real server; however, the server directly responds to the client bypassing the ACE. This behavior allows the acceleration of server to client communications and is transparent to the client. When the ACE operates in ASN, it does not perform any network translation when receiving packets destined to the VIP address. Traffic from the client hits the VIP address and the ACE uses the address as the destination address but rewrites the destination MAC address to the address of the real server.
So the match is speed vs. capabilities.
Since the ACE do not control the entire flow (it sees only the packets vs. the VIP) most of the advanced load balancing features aren't usable.
However, in some cases, where speed is the most important thing and the application flow is quite simple it could be a good choice.
Here's my implementation :





On the ACE :

access-list ACL01 line 8 extended permit ip any any

! The probe should check for the health status of the loopback interface
! on the real server.
probe icmp ICMP
ip address 10.0.20.1
interval 5

rserver host SERVER-10.1
ip address 10.0.10.1
inservice
rserver host SERVER-10.2
ip address 10.0.10.2
inservice

! The transparent command prevents the ACE to make a destination NAT,
! sending the packet as is to the real server.
serverfarm host LAB_20.1:80
transparent
probe ICMP
rserver SERVER-10.1 80
inservice
rserver SERVER-10.2 80
inservice

class-map match-all L4-LAB_20.1:80
2 match virtual-address 10.0.20.1 tcp eq www

policy-map type loadbalance first-match L7-LAB_20.1:80
class class-default
serverfarm LAB_20.1:80
policy-map multi-match L4-POLICYMAPMULTI
class L4-LAB_20.1:80
loadbalance vip inservice
loadbalance policy L7-LAB_20.1:80
loadbalance vip icmp-reply active


service-policy input L4-POLICYMAPMULTI
access-group input ACL01

!The ACE is used as a bare load balancer, diasbling normalization (to make ASN work),
! and icmp-guard.
interface vlan 100
description SERVERSIDE
ip address 1.1.1.199 255.255.255.0
no normalization
no icmp-guard
no shutdown
interface vlan 150
description FIREWALLSIDE
ip address 1.0.0.2 255.255.255.0
no normalization
no icmp-guard
no shutdown

ip route 0.0.0.0 0.0.0.0 1.0.0.1


On the router :

ip route vrf LAB 10.0.20.0 255.255.255.0 10.0.0.2



This way everything works fine. Now it's time to make server to server load balancing work in this scenario.
What I wanted to work is a load balanced server that calls for its VIP being load balanced on itself or on another real server in the same area. Note that this scenario is different since here real server's are one-armed.

The choice to have a point-to-point vlan between the router and the ACE comes with the esigence to control traffic for some feature I needed described further. For simple ASN scenarios the ACE could easily have only one arm on the real servers' vlan (100).


Here's some observations I made :
1) Without any further configuration, server to server loadbalancing doesn't work as there's a loopback interface on the server with the VIP configured on it, you'll never get out of it.
2) You will need both source NAT and destination NAT to make it work.
3) You will have to make the ACE see all of the flow to make the NAT work.
4) You can't use ASN for server to server load balancing

I will not enumerate all of the tries I made to make it work (from which come the observations), here's my solution : double NAT (source and destination) on the router (6513 in this case) so that the ACE treats the connection as a normal external client request.




Here's the router's configuration :

interface Vlan100
ip vrf forwarding LAB
ip address 10.0.10.200 255.255.255.0
ip nat outside
!
interface Vlan150
ip vrf forwarding LAB
ip address 10.0.0.1 255.255.255.0
ip nat inside

ip nat inside source static 10.0.20.1 4.4.4.1
ip nat outside source static 10.0.10.1 6.6.6.1

ip route vrf LAB 10.0.20.0 255.255.255.0 10.0.0.2
ip route vrf LAB 4.4.4.0 255.255.255.0 10.0.0.2
ip route vrf LAB 6.6.6.1 255.255.255.255 10.0.10.199


The last route is a little tricky : as returning packets come from an outside zone to an inside one, packets need to be first routed and the natted. So you'll have to put a "fake" route versus an inside endpoint to make the packet then match the nat rule.

On the real servers you have a route to make all NATted request return by the ACE and not by the default gateway (router). These requests are easily identified by the source address (6.6.6.1).

Note that ASN and server to server load balancing with double NAT (source and destination) can be implemented both on the same box.

Thanks to Daniele and Marco for helping me in the lab.

Friday, April 18, 2008

Nokia E series codes'n'tricks

Here's some codes and tricks I've found useful while deploying a Cisco WLC - Nokia Dual Mode architecture.

These apply to th e series phones.

To see the phone's WLAN mac-address :
Check behind the battery, or
*#62209526# (mnemonic trick : it is like writing "*#mac wlan#" with T9) will display it.

To reset to factory defaults, get to Tools->Settings->Phone->General->Orig. phone settings
The default unlock code is 12345.

There is also a code to reset the ROM and the factory defaults, without deleting data files : *#7780#

Then there's the Deep Reset code : *#7370#
This one resets factory settings, deletes every data file and uninstall everything. This reset asks for the unlock code too.

To read the phone's IMEI : *#06#

To check the phone's firmware version the code is *#0000#

Then determine if firmware version is up to date : http://europe.nokia.com/A4577224

Tuesday, April 8, 2008

Push XML to my Cisco IP Phone in .NET

Or "the Expect-100 story", or the "CiscoIPPhoneError 6 quest"...

I was trying to do a simple thing, i.e., push XML to my Cisco IP Phone, in order to make it display a message and/or display a sound.
Theory is simple : POST an XML message to the IP Phone's /CGI/Execute by means of a simple HTTP connection.
I decided to use the C# HttpWebRequest object, thinking it's exactly what I needed.

Note : this is a story of a good workaround, not of the solution, I'm still workin' on it, stay tuned.

What I wanted was to post this to my IP Phone :
"XML=<ciscoipphoneexecute><executeitem priority="0" url="Play:chime.raw"><executeitem priority="0" url="http://10.10.10.10:8080/textmessage.xml"></executeitem>"

that means : play chime.raw and display the xml returned by a GET from the phone on http://10.10.10.10:8080/textmessage.xml

Here's my simple HttpWebRequest code (NOT working...)

string sXML = "XML=<ciscoipphoneexecute><executeitem priority="0" url="Play:chime.raw"><executeitem priority="0" url="http://10.10.10.10:8080/textmessage.xml"></executeitem>"
HttpWebRequest webRequest = (HttpWebRequest)HttpWebRequest.Create("http://10.1.1.1/CGI/Execute");
webRequest.Method = "POST";
webRequest.Credentials =
new NetworkCredential("test", "test");
byte[] bArr = Encoding.UTF8.GetBytes(sXML);
webRequest.ContentType = "
application/x-www-form-urlencoded";
webRequest.ContentLength = bArr.Length;
Stream dataStream = webRequest.GetRequestStream();
dataStream.Write(byteArray, 0, byteArray.Length);
dataStream.Close();
HttpWebResponse response = (HttpWebResponse)webRequest.GetResponse();

All I obtained was always a very annoying
<CiscoIPPhoneError Number="6" />

I found nothing on this error, as Cisco docs say :

CiscoIPPhoneError

The following list gives possible CiscoIPPhoneError codes:

  • Error 1 = Error parsing CiscoIPPhoneExecute object

  • Error 2 = Error framing CiscoIPPhoneResponse object

  • Error 3 = Internal file error

  • Error 4 = Authentication error


    So I started sniffing the POST from my dev box to the phone observing some strange traffic before sending the POST message.
    The reason is .NET implementation of the HTTP request, that add an Expect 100-Continue header on the very first packet, and then send the real POST after receiving the 100-Continue from the server (the IP Phone in this case).

    You can find a more exhaustive explanation on this here.
    Note that implementing the solution indicated (set the System.Net.ServicePointManager.Expect100Continue to false) worked not on my code, I'm still workin' on it.

    My solution, or workaround if you wish, was to use a simpler object, the MSXML2.XMLHTTPClass class.

    Here's the working code :

    string sXML = "XML=<ciscoipphoneexecute><executeitem priority="0" url="Play:chime.raw"><executeitem priority="0" url="http://10.10.10.10:8080/textmessage.xml"></executeitem>"
    byte[] bb = System.Text.ASCIIEncoding.UTF8.GetBytes("test" + ":" + "test");
    MSXML2.
    XMLHTTPClass xmlhttp = new MSXML2.XMLHTTPClass();

    xmlhttp.open("
    POST", "http://10.1.1.1/CGI/Execute", true, "", "");
    xmlhttp.setRequestHeader("
    Authorization", "Basic " + Convert.ToBase64String(bb));
    xmlhttp.setRequestHeader("
    Connection", "close");
    xmlhttp.setRequestHeader("
    Content-type", "application/x-www-form-urlencoded");
    xmlhttp.send(sXML);

    Thursday, February 7, 2008

    Cisco Unified Presence Server on my IBM server

    Time to install my Presence Server to test interaction with Microsoft...

    No Cisco MCS this time, so I obtained from Cisco the list of compatible servers :

    click me



    Unified Presence Server 6.0(2) has the same requisites of the CUCM 6.0.

    However I tried to use a different processor (more powerful), having the install script to state the the hardware is incompatible.

    No workaround till now, however, I found the hardware check log, useful to see what went wrong :

    Once the install srcript fails, DO NOT press the "Cancel install" button.
    Press ALT+CTRL+F2 to switch console.
    At the prompt :
    "cd /var/state/xkb/"
    then
    "cat hw_validation_err"
    Here's what I found :

    The hardware you are using is not supported for this software

    Hardware-check results:













    HW type [Vendor/Product]OK
    Number of CPUs (1)OK
    Clock Speed (3600 MHz)NOT SUPPORTED
    Memory size (2048 Mb)OK

    Wednesday, January 30, 2008

    Cisco and Nokia Dual-Mode for Dummies



    Finally I succeeded in configuring my dual-mode Nokia e65 as a SCCP client for our Cisco Unified Communication Manager 6.

    As it wasn't simple at all to set up the Nokia to use the Cisco's recommended WLAN security configuration I publish here the result of two days of tweaking on both Cisco WLC and my Nokia e65.

    Cisco says (link here) :
    The optimal configuration for the controller configuration for the WLAN supporting Cisco Unified Wireless IP Phone 7921s is for the WPA security protocol with TKIP encryption and IEEE 802.1X with CCKM key management.
    So, here's how my WLC looks like (seen from WCS) :







    Note : I've seen on some document from Nokia that broadcasted SSIDs work better on e-series devices than hidden ones.

    Now the Nokia side of the problem. Just remember two things :

    1) Not everything it's in the e65 menu means exactly what you think it should mean.
    2) Disable every protocol, setting or cipher algorithm you do not use!

    First of all you should have your corporate root Certificate installed in your phone. I got it from my Outlook Web Access, navigating from the phone, using my GPRS access obviously.

    Remind to have an Internet access (via GPRS or via another WLAN access), you'll need it to activate your free license for Intellisync unless you have the definitive license at your very first activation (not my case).

    Now get in the Tools->Connection->Access points->Options->New access point.
    Here's my working configuration

    -Connection name : VoWLAN
    -Databearer : Wireless WAN
    -WLAN netw. name: [Your SSID here]
    -Network status: Public
    -WLAN netw. mode: Infrastructure
    -WLAN security mode: 802.1x (NOT WPA/WPA2)
    -WLAN security settings :
    --WPA mode: EAP
    --EAP plug-in settings:
    ---EAP-PEAP (select only this, put in the higher position and disable all the others) :

    ---General:
    ----User certificate: not defined
    ----CA certificate: [Your Corporate Certificate here]
    ----User name in use: User-configured
    ----User name: [Your user name]
    ----Realm in use: User-configured
    ----Realm: [balnk]
    ----Allow PEAPv0 : Yes
    ----Allow PEAPv1 : Yes
    ----Allow PEAPv2 : No

    ---EAP:
    ----EAP-MSCHAPv2 (select only this, put in the higher position and disable all the others) :
    -----User name: [Realm]\[Your user name]
    -----Prompt password: No
    -----Password: [Your password]

    ---Cipher:
    ----RSA,3DES,SHA [enabled]
    ----DHE-RSA,3DES,SHA [enabled]
    ----DHE-DDS,3DES,SHA [enabled]
    ----[disable alle the others]

    et voilĂ , now your WLAN connection is ok.

    Next steps are simpler, and all illustrated on the Nokia businness website i.e. :

    Install the Cisco option package (COP) file for Nokia Intellisync Call Connect for Cisco clients in your Communications Manager.

    Install the Nokia Intellisync Call Connect for Cisco clients in your Nokia e65.

    Activate (via Internet) or install your license.

    Configure the SCCP Profile for using your brand new WLAN connection. (instructions here)

    Configure the Internet Telephony Profile to use the SCCP profile. (instructions here)

    The End.

    08-20-2008 Update :

    Here's a follow up to implement CCKM support.