SPA112 Crashes - No dialtone, restart needed

[danbuchko]

Yesterday morning, we picked up the phone to make a call via the SPA112 and there was no dialtone.  I disconnected/reconnected the power and then we were able to get a dialtone and make a call.  Unfortunately I didn't have the opportunity to see if the web-interface was up.  Am running the latest GA firmware, 1.1.0 (011) Feb 10 2012.  It had probably been running for only about 4 days or so since the last reboot.  Anyone else seeing stability issues?  (I thought I'd seen another older posting about someone having had to reboot their device regularly.  In addition, I saw the report about caller id's longer than 26 chars causing issues, but I haven't publicized my new number yet so it is unlikely that was the cause.)

Cisco, any suggestions on a way to capture additional debug info, other than keeping a logging server running?  Didn't see any unusual activity in the device logs.

Dan

[nseto]

If you see this occur next time, please use the web UI to check the Info page in the Voice section and see if the Line has lost registration with the proxy.  So far, an instance that seems to match what you are describing is if the proxy is an asterisk running older version of software and the Reg Auth gets mismatched.  Newer asterisk versions have fixed this issue.

You can also run the debug log to verify if the registration is lost.

https://supportforums.cisco.com/docs/DOC-9862

[JevgenijUnius]

Hello,

I have the same problem with SPA112 and SPA122 phone adapters. They work correctly for several days, then for a reason unknown for me it hangs. The device is reachable by pinging its IP address, bet the WEB interface is not responding so the manual physical reboot is needed. Moreover, there is no signal in handset, and I dont get a response from IVR menu by entering ****. I have worked with SPA2102 adapters and they worked perfectly in our network of different models of D-Link access switches.This problem only occurs with 112 and 122 models. Any suggestions?

[Motofreak]

We only provisioned handful of these 122's to clients that are willing to "beta test" a Cisco final release retail product and we are getting the same results, Device lockups , GUI timeouts, no repsonce, failure to send syslog & debug info to our server.

But if we disable a lot of  the services & features (REMOTE GUI, Bonjour, onboard logging and a few other things) we can make it to about 10-14 days so far,  without the need to power cycle the unit.

but without actual getting some type of console access, its sure feels likes it's running out of memoery!

[JevgenijUnius]

Is there any way to reboot an adapter remotely with WEB interface turned off? Maybe SNMP OID or smth similar?

So the solution would be to script rebooting of adaper and shedule it.

[nseto]

You can send a SIP Notify with Event: reboot

[danbuchko]

I too am still seeing the issue, have to reboot the device about every 2 weeks or so.

Regards,

Dan

[JevgenijUnius]

technicans in one of our regions have been using these adapters with following setup:

1. completely isolated network (ACL) - so no excess packets can enter the broadcats domains. only pbx ant management vlan is allowed

2. all unwanted features are disabled, except web access

3. web access default port is replaced with 8080

so far working fine (little over a month)

we are currently field-testing that configuration in our live network. I'll keep you up with results in a while

[laharper]

Hello everyone,

We are currently researching this issue with our development team and will provide a resolution to this issue in a engineering firmware pre-release as soon as possible.

We will then incorporate into the next SPA112/SPA122 maintenance release which is schedule for early summer.

Best regards,

-Lance Harper

Cisco Systems, Inc.

[dark_hack]

I have the same probleme.

I can give you log access.

I see the module crash often when the intranet connexion is unstable.

like bad cable connexion, and the interface eth0 down (like is describe by the log)

after module voice can't access from webmin.

Keep me in news about an new firmware.

But for say, We work in medical section.

This product is an really disaster.

can't have one day without crash.

[JevgenijUnius]

Hello, as I have said before, we were testing these adapters with custom setings: http port 8080, acl, so on. So the result is tragic. Nothing seems to be working without crashes. Solution is to order older spa2101 adapters, install them in the field, burn down all 112's and 122's  and sleep well OR, maybe cisco technicans will figure out the bug and release updated software soon. Anyway, these black boxes with cisco written on them are on their way to the farest and darkest angle of our warehose for now ;P

[terryip83]

I'm also having this issue. So far I've managed a week before a reboot. Can't access via the Web interface. We're using this now instead of the PAP2T's that just went EOS. Am eagerly awaiting the new firmware release to test before we start rolling these out.

[laharper]

Hello,

We have addressed this issue in the latest pre-release of the SPA112 and SPA122 firmware.

Please open a case with our support center who can then provide the latest beta firmware to you.

Information to open a case can be found at the following website:

http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

Best Regards,

-Lance Harper

Cisco Systems, Inc

[bweybrecht]

Hello,

One thing I know crashes the SPA 122 on FW 1.1.0(011) is a "484 Address Incomplete".  If the box is running 1.0.1(022), it responds appropriately, and just sends reorder to the phone. Of course, that brings back all the issues that were fixed in 1.1.0.

I opened a case asking about trying the beta to see if it fixes the issues such as the DTMF problem, Caller ID problem, and this issue, but the tech. wanted configs, fresh packet caps, and all kinds of stuff that shouldn't be necessary given that some of the issues I mentioned are supposedly fixed.

He was real helpful with regard to the config migration from SPA 2102 in that the old config to xml migation only works with a specific version of the SPC tool, which isn't mentioned in the "we're killing SPA2102, but it's OK 'cause you can migate" document.

Not sure if the 484 box crash is related to the issue discussed here, as it recovers, but one never knows if it causes some progressive issue with the box that after 10 or 20, it burns up all available memory, or something similar. Packet cap and syslog output of the event that crashes the box below.

23:06:37.954693 IP (tos 0x0, ttl 64, id 22296, offset 0, flags [none], proto UDP (17), length 830)
    10.33.90.60.sip > SPA122.8060: SIP, length: 802
        SIP/2.0 484 Address Incomplete
        Via: SIP/2.0/UDP 10.33.90.111:8060;branch=z9hG4bK-2817ba48
        From: <4331>;tag=1481fc25925927f6o0
        To: <4669>;tag=NNmBD3S5vZSyK
        Call-ID: c07d0711-f4b9b9fa@10.33.90.111
        CSeq: 102 INVITE
        User-Agent: FreeSWITCH-mod_sofia/1.2.0-rc2+git~20120624T003326Z~86df8b338e+unclean~20120624T044059Z
        Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
        Supported: timer, precondition, path, replaces
        Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
        Reason: Q.850;cause=16;text="NORMAL_CLEARING"
        Content-Length: 0
        Remote-Party-ID: "4669" <4669>;party=calling;privacy=off;screen=no

23:06:37.973366 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 635)
    SPA122.8060 > 10.33.90.60.sip: SIP, length: 607
        ACK sip:4669@10.33.90.60 SIP/2.0
        Via: SIP/2.0/UDP 10.33.90.111:8060;branch=z9hG4bK-2817ba48
        From: <4331>;tag=1481fc25925927f6o0
        To: <4669>;tag=NNmBD3S5vZSyK
        Call-ID: c07d0711-f4b9b9fa@10.33.90.111
        CSeq: 102 ACK
        Max-Forwards: 70
        Proxy-Authorization: Digest username="4331",realm="10.33.90.60",nonce="455f6ec0-c0ce-11e1-bdff-c9d1f242411e",uri="sip:4669@10.33.90.60",algorithm=MD5,response="e59568b7cab23ca5081d697b612fef0e",qop=auth,nc=00000001,cnonce="be94babd"
        Contact: <4331>
        User-Agent: Cisco/SPA122-1.1.0(011)
        Content-Length: 0

Clock in ATA is slightly diferent than NTP locked server, but death begins at 23:06:37

<4>Jun 27 23:06:35 SPA122 [17179877.700000]  In cordless Driver Codec 100 and str NSE/8000  chan 0

10.50.50.1 27/06 23:06:29.268

<4>Jun 27 23:06:35 SPA122 [17179877.700000]  In cordless Driver Codec 112 and str encaprtp/8000  chan 0

10.50.50.1 27/06 23:06:29.268

<29>Jun 27 23:06:37 SPA122 msgswitchd[380]:   MSGSWD RTCP Reqt len 12 Data 2,35,7304,0

10.50.50.1 27/06 23:06:31.359

<4>Jun 27 23:06:37 SPA122 [17179879.824000]  RTCP is running so calling rtcp stop

10.50.50.1 27/06 23:06:31.390

<4>Jun 27 23:06:37 SPA122 [17179879.824000]  chan->kmode is present not null

10.50.50.1 27/06 23:06:31.390

<4>Jun 27 23:06:37 SPA122 [17179879.828000]  ###### RTCP sock_sendmsg return 172

10.50.50.1 27/06 23:06:31.390

<4>Jun 27 23:06:37 SPA122 [17179879.836000]  ###### sock_sendmsg return 172

10.50.50.1 27/06 23:06:31.390

<4>Jun 27 23:06:37 SPA122 [17179879.836000] 

10.50.50.1 27/06 23:06:31.452

<4>Jun 27 23:06:37 SPA122 [17179879.836000]  #### RTP STOP Flag set in this channel break ####

10.50.50.1 27/06 23:06:31.452

<6>Jun 27 23:06:37 SPA122 [17179879.888000] cordless: deinit

10.50.50.1 27/06 23:06:31.452

<6>Jun 27 23:06:52 SPA122 [17179894.068000] cordless: loading synergy-2012-01-18

10.50.50.1 27/06 23:06:45.757

<6>Jun 27 23:06:52 SPA122 [17179894.108000] cordless: init successful

10.50.50.1 27/06 23:06:45.757

<13>Jun 27 23:06:54 SPA122 msgswitchd:  MSGSWITCH fd_rtp fifo created 12

10.50.50.1 27/06 23:06:47.817

<13>Jun 27 23:06:54 SPA122 msgswitchd:  MSGSWITCH fd_ch fifo created 14

10.50.50.1 27/06 23:06:47.817

<13>Jun 27 23:06:54 SPA122 msgswitchd:  MSGSWITCH fd_gmep fifo created 15

10.50.50.1 27/06 23:06:47.817

[Patrick Born]

This appears to be related to https://supportforums.cisco.com/message/3779434#3779434

Regards,

Patrick

----------