[cisco-voip] 8831 registration problems with 9.1.1a

Erick Bergquist erickbee at gmail.com
Fri Dec 12 01:51:02 EST 2014 

Just a update on this, the 8831 went down again due to power issues in
the location and was a bear to get up and working again.
It came up after a couple dozen attempts of shutting down port for
different periods of time, changing vlans, bringing port back up, etc.
Left it shutdown for 10 minutes at times.

I updated it to firmware 10-3-1-16 and am having the same difficulty
to get it to register, it updated fine before it reset fully.

The issue is with the phone getting a initial network connection after
power on, but once it has a good one it seems to be fine until the
connection is lost.

Have tried different cables, different switch ports, different model
switch, etc.

It is a hardware rev 1.0 8831.

When it is up and working fine, it responds to pings fine (!!!!!) but
when it is wonky it doesn't respond to pings or responds to every few
pings maybe.

I'm going to try to get this phone replaced....

I also saw this in the status message web page when it was up, any
ideas where this is coming from?

TFTP Timeout : SK5e5aacd7-9792-465c-873d-162a6f4a53c9.xml.sgn


BTW, for those reading this the 8831 firmware update from 9.3,3 to
10-3-1 is a two step update with a special load.


Device ID: SEPAC44F2100978
Entry address(es):
  IP address: 10.10.10.23
Platform: Cisco IP Phone 8831,  Capabilities: Host Phone
Interface: GigabitEthernet0/13,  Port ID (outgoing port): Port 1
Holdtime : 167 sec

Version :
sip8831.10-3-1-16

advertisement version: 2
Duplex: full
Power drawn: 12.950 Watts
Power request id: 30735, Power management id: 8
Power request levels are:12950 0 0 0 0
Management address(es):

On Sat, Sep 14, 2013 at 2:16 AM, Erick B. <erickbee at gmail.com> wrote:
> Ryan, I'll need to find the bug I saw the other day. I did get around to
> updating the 8831 to the 9.3.3.5 fw and same type of behavior kind of. I had
> to tinker with it more and longer to get it to come back up. While doing
> that I debugged the DHCP Server (2800 router) and noticed the 8831 was
> sending DHCP requests and the 2800 was sending DHCP offers, this kept
> happening over and over. The show cdp neighbor for the 8831 showed no IP
> address.I let it do this for quite some time. After awhile, I shutdown the
> 8831 switchport for a few minutes and brought it back and after a few
> minutes it seemed to take the DHCP address and is up again,
>
> This is not local to me... trying to get my hands on a 8831. I'm asking the
> folks local to the 8831 to set it to use a static IP and see if it works
> fine on resets/shutdowns to narrow it down to DHCP and maybe get a packet
> capture.
>
> Bug Toolkit and Bug Search Tool aren't revealing anything for the 8831 or
> the IOS version DHCP releated. The IOS Version is 12.4(24)T8.
>
>
> On Thu, Sep 5, 2013 at 9:26 AM, Ryan Ratliff (rratliff) <rratliff at cisco.com>
> wrote:
>>
>> Thanks for the good info Erick.
>>
>> I just added those commands to my switch here and will let you know if I
>> hit the same problem.
>>
>> What was the switch bug you found?
>>
>> -Ryan
>>
>> On Sep 5, 2013, at 4:14 AM, Erick B. <erickbee at gmail.com>
>>  wrote:
>>
>> Some updates on this....
>>
>> This is combination of having port-security and spanning-tree guard root
>> enabled on the port it looks like. I did find a switch IOS bug the other day
>> where both could cause a problem. I can get the phone back up and registered
>> again if I tinker with the switchport settings (shutdown port, remove
>> port-security, remove guard root, throw port into another vlan then back
>> into voice vlan, leave port shutdown for 2-3 minutes then bring it back up).
>> The command variation slightly varies and sometimes need to do it 1-2 times.
>>
>> I'm trying to get them to move this 8831 to another switch with newer IOS
>> until we get window to update the IOS on one it is on, plus if it's moved to
>> other switch and this doesn't happen when it is unplugged or port shutdown I
>> can point toward the switch IOS more.
>>
>>
>> On Sat, Aug 31, 2013 at 12:38 AM, Erick B. <erickbee at gmail.com> wrote:
>>>
>>> Yes, a MAC address is learned on the interface and another device on same
>>> VLAN gets the MAC via ARP response fine.
>>> Can't ping however.
>>>
>>> I narrowed it down even further playing with it some more this evening, I
>>> reverted port back to the way all ports are setup.
>>>
>>> interface Gigabit0/3
>>>  switchport mode access
>>>  switchport voice vlan 100
>>>  switchport port-security maximum 3
>>>  switchport port-security
>>>  srr-queue bandwidth share 10 10 60 20
>>>  srr-queue bandwidth shape 10 0 0 0
>>>  priority-queue out
>>>  mls qos trust device cisco-phone
>>>  mls qos trust cos
>>>  auto qos voip cisco-phone
>>>  spanning-tree portfast
>>>  spanning-tree guard root
>>>  service-policy input AutoQoS-Police-CiscoPhone
>>>
>>> If I remove the "spanning-tree guard root" command, the phone comes back
>>> fine. I tested it a half dozen times.
>>> Spanning tree on the port was in forwarding state when it wasn't working.
>>>
>>> Haven't been able to have someone move the phone to another switch yet,
>>> I'll see if they can unplug it a few times to see if it comes back fine that
>>> way. It's at another site.
>>>
>>> Thanks.
>>>
>>>
>>>
>>> On Fri, Aug 30, 2013 at 8:28 AM, Ryan Ratliff (rratliff)
>>> <rratliff at cisco.com> wrote:
>>>>
>>>> When the phone is in this state does the mac address-table on the switch
>>>> get updated?  If so can another device on the vlan get an ARP response?
>>>>
>>>> This could still be a phone problem.  It has to send a packet to build
>>>> the mac address-table on the switch (I'd guess this is happening if it got
>>>> an IP from DHCP).  Then the phone has to respond to ARPs, and then for ICMP
>>>> to work it has to respond to those packets.  There are a few places in this
>>>> process that the endpoint can break things.
>>>>
>>>> For comparison I've got an 8831 on 9-3-3-3 that's been up for a month or
>>>> more registered to 9.1(1) the whole time.  It's been daisy-chained a few
>>>> times but I don't recall messing with the switchport at all.  It's connected
>>>> to a 3750 running 122-55.
>>>>
>>>> -Ryan
>>>>
>>>> On Aug 30, 2013, at 2:31 AM, Erick B. <erickbee at gmail.com> wrote:
>>>>
>>>> Thanks for the pointers, however I tried the new search tool with build
>>>> # and right product and various keywords and nothing comes up.
>>>>
>>>> Anyway...
>>>>
>>>> I tinkered with the phone some more and this looks to be a IOS issue on
>>>> a switch. I broke it a few times and fixed it the same way each time and the
>>>> time port is down doesn't matter. If the phone is unplugged or port is
>>>> shutdown, the phone doesn't come back with a good LAN connection. I see the
>>>> phone via CDP neighbor, it gets a IP address eventually but I can not ping
>>>> it from the same VLAN at all no matter how long I wait.
>>>>
>>>> To fix it I shutdown the switchport, set the switchport vlan to another
>>>> vlan then back to the voice vlan then re-enable the switchport.
>>>>
>>>> Once the phone is registered, I can reset it from CUCM and it comes up
>>>> fine again. It only has the problem if unplugged or loses power/port
>>>> shutdown.
>>>>
>>>> The switch is a 3560 with IOS version c3560-ipbase-mz.122-35.SE5.bin.
>>>> I'm going to have them plug phone into a newer switch and see if things are
>>>> better and look into updating the 3560.
>>>>
>>>> Erick
>>>>
>>>>
>>>> On Thu, Aug 29, 2013 at 10:19 PM, Ryan Ratliff (rratliff)
>>>> <rratliff at cisco.com> wrote:
>>>>>
>>>>> There's a big difference in not registering at all and losing
>>>>> registration intermittently.  The first is almost always a config or
>>>>> devicepack issue. The second mostly network or a bug, though the SIP profile
>>>>> can come into play.
>>>>>
>>>>> For open bugs you'll find BST much more accurate for CUCM bugs than
>>>>> phones.  The phone bugs are there it's just a challenge sometimes to get the
>>>>> fixed-in version to be something that makes sense to anyone other than a
>>>>> developer and this obviously wreaks havoc with searches.
>>>>> Here's the search I whipped up for all bugs fixed with a version of
>>>>> "9.1(2.10000".  I left of the last digits to get bugs fixed in earlier
>>>>> builds than 28.
>>>>>
>>>>> https://tools.cisco.com/bugsearch/search?kw=&pf=prdNm&pfVal=268439621&rls=9.1%282.10000&sb=fr&srtBy=byRel&bt=custV
>>>>>
>>>>>
>>>>> -Ryan
>>>>>
>>>>> On Aug 29, 2013, at 6:51 PM, Erick B. <erickbee at gmail.com> wrote:
>>>>>
>>>>> Ok. Interesting. The time on the 8831 on initial power on is 7pm on
>>>>> 12-31-99 it looks like then it is right once registered so...
>>>>>
>>>>> The phone's been up and fine now for almost 6 hours since I shutdown
>>>>> the switchport for roughly 2 minutes before bringing the port back up.
>>>>>
>>>>> Is there a list of bugs fixed in CUCM 9.1.2 anywhere in a document? The
>>>>> 9.1.2 release notes say to use bug toolkit. I dislike release notes not
>>>>> listing resolved caveats as bug toolkit might not pull up everything that
>>>>> was fixed and it is up to us to find what was fixed. For example, the
>>>>> release notes for the 8831 9.3.3 firmware list a handful of open caveats but
>>>>> resolved section says to use bug toolkit. You go search for bugs on the 8831
>>>>> phone model and only one comes up with 1 hit. I would expect to see the open
>>>>> caveats listed in the release notes and a few others.
>>>>>
>>>>> I'll work on getting a packet capture. This is in a remote location so
>>>>> I'll have to see if I can get my hands on a 8831 one myself hopefully with
>>>>> 9.3.3.3.
>>>>> 9.3.3.5 is the only firmware on the cisco.com page.
>>>>> I can throw new firmware on it but was trying to figure this out also.
>>>>>
>>>>> There are a couple posts on cisco support forums about this, and a few
>>>>> have upgraded to CUCM 9.1.2 to solve this but no details/bugs/etc provided.
>>>>> https://supportforums.cisco.com/message/4019981#4019981
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Aug 29, 2013 at 3:34 PM, Wes Sisk (wsisk) <wsisk at cisco.com>
>>>>> wrote:
>>>>>>
>>>>>> great find Brian. one bit of clarification - "cm_closed_tcp" mesa the
>>>>>> phone received TCP RST or FIN from the _network_ that did not necessarily
>>>>>> originate from CUCM.
>>>>>>
>>>>>> -Wes
>>>>>>
>>>>>> On Aug 29, 2013, at 3:17 PM, Brian Meade (brmeade) <brmeade at cisco.com>
>>>>>> wrote:
>>>>>>
>>>>>> Eric,
>>>>>>
>>>>>> I didn’t find the initial time the phone went into this state but the
>>>>>> phone does print a list of reasons why the phone last unregistered when it
>>>>>> boots up:
>>>>>>
>>>>>> 0918 NOT 00:00:57.357542 CVM-System P7-display
>>>>>> MQThread|cip.sipcc.SipEnhancedAlarmInfo:getLastUnregistrationTimeReason -
>>>>>> TimeStamp=1377753202845946685028372,946684857457,1377753927440,946685018334,946685040399946685046997,946684934872,946684857026;
>>>>>> Reasons =14,14,14
>>>>>>
>>>>>> Here, you can see the last 3 unregister reasons have cause 14 which
>>>>>> corresponds to CM_CLOSED_TCP so CallManager closing the TCP socket.
>>>>>>
>>>>>> We don’t have any engineering specials posted for the 8831 but a quick
>>>>>> bug search didn’t show anything.  Can you get a packet capture of it in the
>>>>>> broken state?
>>>>>>
>>>>>> Thanks,
>>>>>> Brian Meade
>>>>>>
>>>>>>
>>>>>> From: Erick B. [mailto:erickbee at gmail.com]
>>>>>> Sent: Thursday, August 29, 2013 3:42 PM
>>>>>> To: Brian Meade (brmeade)
>>>>>> Cc: voip puck
>>>>>> Subject: Re: [cisco-voip] 8831 registration problems with 9.1.1a
>>>>>>
>>>>>> Brian, I sent you the console logs. Thanks.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 29, 2013 at 1:12 PM, Erick B. <erickbee at gmail.com> wrote:
>>>>>> Yea, let me do that.
>>>>>>
>>>>>> It seems if I shutdown the switchport for 2-3 minutes then bring it
>>>>>> back up it stays up, if a quick shut/no shut is done then it doesn't come up
>>>>>> or may register for a minute then go back unregistered.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 29, 2013 at 1:02 PM, Brian Meade (brmeade)
>>>>>> <brmeade at cisco.com> wrote:
>>>>>> Eric,
>>>>>>
>>>>>> Can you collect console logs covering the time period of it going from
>>>>>> working to nonworking?
>>>>>>
>>>>>> Thanks,
>>>>>> Brian Meade
>>>>>>
>>>>>> From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf
>>>>>> Of Erick B.
>>>>>> Sent: Thursday, August 29, 2013 1:24 PM
>>>>>> To: voip puck
>>>>>> Subject: [cisco-voip] 8831 registration problems with 9.1.1a
>>>>>>
>>>>>> Does anyone know if there are issues with sip8831.9-3-3-3
>>>>>>  firmware on 8831 model phone and network/VLAN connection?
>>>>>>
>>>>>> Had a 8831 working for a month or so fine with 9.1.1a (9.1.1.20000-5)
>>>>>> and now it won't register reliably. If I shutdown the switchport and such a
>>>>>> few times it registers again, sometimes for 1-2 minutes or might stay up and
>>>>>> work fine until it is unplugged or reset again.
>>>>>>
>>>>>> I set the switchport access vlan to be in voice vlan directly to
>>>>>> (removed switchport voice vlan) and that seemed to help but same thing
>>>>>> happened the next day.
>>>>>>
>>>>>> Not finding any release notes for the 9.3.3.5 firmware and there is a
>>>>>> cisco support forum post suggesting a upgrade to 9.1.2 call manager fixes
>>>>>> this issue.
>>>>>>
>>>>>> Device Pack 9.1.1.21017-2 used to add support for this.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-voip mailing list
>>>>>> cisco-voip at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>
>>>>
>>>
>>
>>
>

More information about the cisco-voip mailing list