I used Wireshark to control communication between PC and ATA when uploading configuration file via local network. PC with Ubuntu and ATA connected to small hub (blue WAN port <-> to hub). Ubuntu run ISC-DHCP Server with subnet configured for ATA, and config file is in TFTP root directory. As I can see, Wireshark does show that the device downloads it's profile successfully, but it never reboot to apply the new profile to the device. I tried few times, what can be the problem? There is also ETHERNET FRAME CHECK SEQUENCE INCORRECT entries, but not sure this can be an issue. asked 21 Jan '17, 15:27  kosmicity edited 21 Jan '17, 15:42 |
One Answer:
The Ethernet Frame Check Sequence is handled by the network adapter - it's unusual to see the actual FCS in a wired capture without certain equipment. Since it is handled by your adapter, you see all 0's for the value, while Wireshark is calculating the actual value, and of course it is failing the check. The preferences pain has the requisite entries to disable the validation:
Also google has a lot of information on this topic, much from previous questions related to FCS: Most likely, you can ignore this error or turn off the check in Wireshark. An actual bad frame with a bad FCS would usually never make it up to Wireshark, so you wouldn't see it - you would need specific hardware configured to pass up bad frames, or see it in the various interface counters as dropped. If you have a managed switch, you likely have counters for this sort of thing. A basic unmanaged switch likely does not. answered 22 Jan '17, 04:33  Bob Jones |
So config file was definitely uploaded into ATA, but ATA not resyncing and not reboots?
It certainly looks that way from the trace. You have the packets inverted, but you can see the request, the response (indicates last frame), then the acknowledgment.
I don't know what an ATA is, or if it should do the things that you expect. One thing to check that was left out of the trace: if the ACK was not accepted, you would expect the data frame to retry for some amount of time / number of retries. I can't see if that occurred or not from the picture you provided. If this is the whole signature, you can rule out network issues as the file is being delivered.
Is the config file valid? Does the device have to be in a certain state to accept a config?
I don't think this is your issue, but it's along the same lines:
https://quickview.cloudapps.cisco.com/quickview/bug/CSCsd44357
Cisco Bug: CSCsd44357 - ATA186 Auto-Registration Fails if XMLDefault file exceeds 4k in Size
I didn't found the retries, so it looks like it's the whole signature. I recorded 108 packets, maybe I should wait more time. If assume that file has been delivered, then I can rule out network issues. The config is valid, file size is only 366 bytes, so its not file size issue.
The device (Cisco SPA Voice adapter with router) should accept default config profile on boot, when powered up it resyncs to this file on the local TFTP server specified by DHCP option 66.
I wasn't sure about my LAN and DHCP server setup, as I used WAN IP addresses for subnet, not common private ip address range, as ATA was not reachable via its default IP address.