You can do the capture on the CUCM side via CLI but that doesn't help you prove you lost a packet since you'll also need from the phone side via Span To PC:
utils network capture eth0 size all count 100000 file 7970testreg Press Ctr+c to end the capture after the reject. You can get the capture from RTMT via Trace&Log Central->Collect Files->Packet Capture Logs (on 2nd page). You can also use SFTP: file get activelog platform/cli/7970testreg.cap On Tue, Jun 3, 2014 at 1:29 PM, Mike King <[email protected]> wrote: > Hmm.. > > Before I bust out my span sessions, is there a way to packet capture from > the CUCM / Phone? > > > On Tue, Jun 3, 2014 at 1:22 PM, Brian Meade <[email protected]> wrote: > >> Sounds like an MTU issue to me based on those logs. Get captures from >> the phone side and CUCM. >> >> >> On Tue, Jun 3, 2014 at 1:04 PM, Mike King <[email protected]> wrote: >> >>> Now I'm more confused. >>> Did I pull the right Traces? >>> >>> <ServiceName name="Cisco CallManager"> >>> <ServiceName name="Cisco Tftp"> >>> >>> This is from the Callmanager trace: (attached is the whole log, device >>> MAC is 0019AAAA3EB6) >>> >>> 00268821.002 |12:51:14.196 |AppInfo |EndPointTransientConnection - An >>> endpoint attempted to register but did not complete registration Connecting >>> Port:2000 Device name:SEP0019AAAA3EB6 Device IP address:10.103.5.133 Device >>> type:119 Reason Code:27 Protocol:SCCP Device MAC address:0019AAAA3EB6 >>> IPAddressAttributes:3 LastSignalReceived:StationResponseTimerType >>> StationState:wait_capabilities App ID:Cisco CallManager Cluster >>> ID:StandAloneCluster Node ID:BE6K-CUCM >>> 00268821.003 |12:51:14.197 |AlarmErr |AlarmClass: CallManager, >>> AlarmName: EndPointTransientConnection, AlarmSeverity: Error, AlarmMessage: >>> , AlarmDescription: An endpoint attempted to register but did not complete >>> registration, AlarmParameters: ConnectingPort:2000, >>> DeviceName:SEP0019AAAA3EB6, IPAddress:10.103.5.133, DeviceType:119, >>> Reason:27, Protocol:SCCP, MACAddress:0019AAAA3EB6, IPAddrAttributes:3, >>> LastSignalReceived:StationResponseTimerType, >>> StationState:wait_capabilities, AppID:Cisco CallManager, >>> ClusterID:StandAloneCluster, NodeID:BE6K-CUCM, >>> 00268821.004 |12:51:14.197 |AppInfo |StationD: (0001646) >>> RegisterReject text=''. >>> 00268822.000 |12:51:14.198 |AppInfo >>> |-->RISCMAccess::DeviceTransientConnection(...) >>> 00268823.000 |12:51:14.198 |AppInfo |Device Transient deviceName : >>> SEP0019AAAA3EB6, IPAddress : 10.103.5.133, IPv6Address : not shown, >>> IPv4Attribute :3, IPv6Attribute :0, Protocol : 1 >>> 00268824.000 |12:51:14.198 |AppInfo |DebugMsg deviceName : >>> SEP0019AAAA3EB6, DeviceType : 119, risClass: 1 >>> 00268825.000 |12:51:14.198 |AppInfo >>> |<--RISCMAccess::DeviceTransientConnection(...) >>> >>> >>> On Tue, Jun 3, 2014 at 11:57 AM, Ryan Ratliff (rratliff) < >>> [email protected]> wrote: >>> >>>> > Any Idea's why the phones are being rejected? >>>> >>>> Not from that log that I can tell. Look at the CCM traces. Obvious >>>> reasons are wrong device model in the database, not in the database at all >>>> and auto-registration is disabled, phone configured with a secure profile >>>> requiring an LSC and none is present. >>>> >>>> -Ryan >>>> >>>> On Jun 3, 2014, at 11:08 AM, Mike King <[email protected]> wrote: >>>> >>>> We just purchased a BE6K to setup a lab. >>>> >>>> I've run through the setup, and have that all sorted, or so I think. >>>> (So the environment may or may not be the issue) >>>> >>>> We have a couple of very phones we were going to recycle. >>>> >>>> Right now we have two, a 7970, and a 7971. >>>> >>>> The started life phone firmware at 6.0(2). Utilizing factory >>>> defaulting off my laptop, I got them to 8.3.3. (I couldn't get them to >>>> associated with 6.0(2)) >>>> >>>> Running 8.3.3, they were able to register, and function. >>>> >>>> I pushed the firmware up to 9.3(1SR3.1S) >>>> >>>> Now none of the phones are registering. I've read the release notes, >>>> and I should be able to goto 9.3.1 from 8.3.3 directly on these phones, >>>> with no further intermediate releases. >>>> >>>> Attached is one of the phone logs. Both phone's are showing the same >>>> behavior. >>>> >>>> The phone is just sitting there with the wrong date and time in the >>>> corner, and every once and awhile will print out "Registration Rejected: " >>>> >>>> Any Idea's why the phones are being rejected? >>>> <log199.log>_______________________________________________ >>>> cisco-voip mailing list >>>> [email protected] >>>> https://puck.nether.net/mailman/listinfo/cisco-voip >>>> >>>> >>> >>> _______________________________________________ >>> cisco-voip mailing list >>> [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> >>> >> >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
