Tuesday, January 29, 2013

Case Study: Cisco Phone 7942 unexpected auto-call/auto-dial

Problem Description:
This is an actual ticket escalated to our team.

User reported that his Cisco IP Phone automatically dials a number once he picks up the handset of the phone.

HW/SW Versions:
  • Cisco IP Phone 7942
  • SCCP42.9-2-3S
  • CUCM 7.1 (
  • Same behavior is observed when pressing the speaker button;
  • Same behavior is observed when pressing the headset button;
  • Only one number is being called consistently;
  • IP Phone is registered correctly in CUCM;
  • Resetting the phone has stopped the auto-dialling.

Root Cause:
After some research, we found the bug documenting this behavior:

CSCtz29414 - 7942/7962 - Call History is Auto-Dialed When Pressing Speaker Button

When a 7942/62 phone is populated with call history records (e.g. received/placed/missed calls), the endpoint will auto-dial the number contained in its call history when the speaker button is pressed.

IP Phone Call History contains Received/Placed/Missed Phone number record prior to pressing speaker button to go off-hook. Phone will continue to auto-dial the number listed in Call History once error condition is experienced.

Reset IP Phone to clear error condition

1st Found-In:


As per the bug above, reset the phone

Permanent Fix:
Upgrade the phone firmware.

Friday, July 27, 2012

Aptigen .NID File Format

            <Location XPos="94" YPos="79" />
          <Paging Enabled="True" Forward="Next" Previous="Prev" RecordsPerScreen="32" />
        <Title>Speed Dials Site A-Z</Title>
            <Location XPos="243" YPos="42" />
          <Paging Enabled="True" Forward="Next" Previous="Prev" RecordsPerScreen="32" />
          <Name>Alaa AJ</Name>
          <Name>Aline Cara</Name>
            <Location XPos="238" YPos="80" />
          <Paging Enabled="True" Forward="Next" Previous="Prev" RecordsPerScreen="32" />
          <Name>Magd Dan</Name>
          <Name>Magd Darren</Name>
            <Location XPos="240" YPos="120" />
          <Paging Enabled="True" Forward="Next" Previous="Prev" RecordsPerScreen="32" />
          <Name>Pierre John</Name>
          <Name>Raymond Edward</Name>
    <Connectors />
    <Queries />
    <LDAPConnectors />
    <LDAPQueries />
    <AptigenWebFiles />
    <AptigenControls />
    <SessionVars />

Wednesday, June 20, 2012

Wireless clients getting DHCP Server in a different subnet


  • Running "ipconfig /all" on the client shows that the wireless DHCP server is in a different subnet and/or a different DHCP server than expected;
  • Confirmed no network connections observed from wireless client;
  • Wireless network infrastructure consists of Lightweight Access Points controlled by Wireless LAN Controller (WLC);
  • Even if IP address is released and renewed, client is still getting the correct IP address but DHCP Server is still in the different subnet.


Wireless LAN adapter Wireless Network Connection:

   Connection-specific DNS Suffix  . : my.company.com
   Description . . . . . . . . . . . : Intel(R) Centrino(R) Advanced-N 6200 AGN
   Physical Address. . . . . . . . . : 00-27-EE-EE-EE-EE
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::c010:5d39:eeee:eee%11(Preferred)
   IPv4 Address. . . . . . . . . . . :
   Subnet Mask . . . . . . . . . . . :
   Lease Obtained. . . . . . . . . . : Saturday, June 09, 2012 6:56:11 PM
   Lease Expires . . . . . . . . . . : Sunday, June 10, 2012 12:56:11 AM
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 218113808
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-15-9D-76-61-00-EE-EE-EE-EE-EE
   DNS Servers . . . . . . . . . . . :
   Primary WINS Server . . . . . . . :
   Secondary WINS Server . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Enabled



  • First thing to confirm is if there is any actual network issue; i.e., does the client have any network connectivity issues? In this example, it's already confirmed that there are no issues.
  • In this case, there is actually no network/configuration issue; the WLC is configured as a DHCP Relay (as opposed to instead of as a DHCP Server); hence, the client sees a virtual IP address of the WLC, instead of the actual DHCP server.
  • Here's the rough run-through of the process;
    • Wireless Client DHCP request --> AP --> WLC (dhcp relay) ---> DHCP Server
    • DHCP Server reply --> WLC --> AP --> Wireless Client

Wireless LAN Controller (WLC) FAQ

Monday, April 30, 2012

Case Study: Juniper client disconnects randomly with nc.windows.app.23711

Below is an actual issue seen several times in our working environment involving Juniper VPN client (NC Connect)

System Log Message: The Network Connect session terminated. Do you want to reconnect? (nc.windows.app.23711). 

- Juniper Networks > Network Connect 7.1.0
- MS Windows 2000, Windows XP, Windows Vista, Windows 7


This error indicates that some installed software or program in your laptop is trying to modify the network routes within your laptop. The Juniper VPN application see this as a threat and therefore throws this message and disconnects the VPN tunnel.

Historically, this is widely caused by the older version of the Bonjour service (versions earlier than 1.06) used by Apple. Recently though, we have discovered that some device management applications are also causing the same issue.

I have experienced this at home myself. I have a Canon printer management suite that auto-runs on startup of my laptop. It automatically scans my home network for my printer. When I connect to the company network via VPN, I lose connection to my home network, thus losing connection to my home printer. To look for the printer, one of the things that the Canon management suite does is modify the route table of my laptop, which is the "threatening" action detected by Juniper which then causes the VPN to be disconnected. Luckily though, the simple solution here is to turn off the Canon management suite before I connect via VPN.

Troubleshooting with debugs/Logs:

Below steps may help confirm if the above error is indeed generated by "unauthorized" modification of the computer's routing table. We've had multiple issues in which there is nothing indicated on the logs, but later on we determined the cause is the same.
  1. Launch NC troubleshooting (Start > All Programs > Juniper Networks > Network Connect 7.1.0
  2. On the Logs tab, select "Detailed Info"
  3. On the Information tab, select "Show All" from the dropdown, and click "Copy to Log"
  4. On the Diagnostics tab, click "Start Diagnostics, then after completing successfully, click "Copy to Log"
  5. Connect via VPN.
  6. Once the connection breaks and you get the error message, go back to NC Troubleshooting > Logs tab > click Explore Log Files
  7. Search each of the log files for "unauth"


First thing to check is the Bonjour service version installed; versions earlier than 1.06 are known to cause this issue.

Next, check the computer for any device management applications/application suites. These refers to any device managed by this computer remotely over the network (wired or wireless), such as printers, scanners, fax, modems, and cameras. If so, turn them off (via Task Manager) and connect again to test.