Hi, I just found a critical bug in f/w v2.00.20.
When upgrading some provisioned units, I suddenly lost provisioning contact with one unit (it stopped checking for new config files).
At the same time, I noticed requests for an unknown config file as well as "Resync failed" errors in my syslog.
As it turnes out, one of the units started requesting a config file named with MAC address of the cloned MAC settings instead of the real MAC.
I use [$MAU.xml] in the profile rule and this will in v2.00.20 pick up the cloned MAC if customer has configured this.
Please verify my findings.
Nick, dev is looking into this issue but are asking the following....
I'm trying to reproduce it, I use configured xml with MAC Clone enabled, and every 60 seconds to resync different xml by http profile rule.
But it seems hard to reproduce it.
so could you ask for more detail info? such as
what's the profile rule, http or https?
each time when it failed, the config file name and mac addr in syslog are all changed?
The typical syslog should have failed reason like this:
WRP400 00:23:69:78:DD:1A -- Resync failed: file not found
It's better if we can get the syslog, and the xml config file.
Please provide and I'll forward to dev. Thanks.
Profile rule is http.
After upgrade, the ATA constantly called for the config file using it's cloned MAC address in the file name (and still is).
In order to regain control, I manually renamed the config file with the cloned MAC address in file name.
Syslog did not report more as I used Debug Level 0.
WRP400 **:**:**:**:**:** -- Resync failed: file not found
If you want my XML file, pls give me your address at cisco.
I am a WRP400 user base in New Zealand who is also experiencing serious issues with this device. We are on a 50Mbps fibre connection and we find we need to reboot the device every 3-5 days because the speed steadily drops over the hours (down as low as 3-5Mpbs or wherever I get fed up with it and reboot). The knock-on effect of the slow speed is the degradation in the VoIP service, which seems to be the centre topic of this forum.
As per your suggestion of trying out the beta version of the latest firmware, I contacted the Small Business Support Centre on 1866 606 1866 but got nowhere. The support guy I spoke to - Ed - was only able to send me the 2.00.20 version of the firmware which I am already running. As it was 6:00pm on Sunday where Ed was (it was lunchtime on Monday here in New Zealand) there was no-one around he could ask.
I'm hoping you or someone can post a link or email the 2.00.21 beta firmware to me at "mike dot walen at keyimagery dot com" as it is proving difficult with the time difference to source it from NZ.
Hi, My name is Eric Moyers. I am a Network Support Engineer in the Cisco Small Business Support Center. I can get you a copy of the firmware that you are looking for. I will contact you by email.
Cisco SBSC Network Engineer
I'm having the same problems as well. Would it be possible to get the beta firmware so I can test it and see if the problem persists?
After some intensive searching i finally found 1.00.04.c fw at some obscure site. please dont post rapidshares anymore. They actually delete files that are inactive after some time. Whats up with that. well enjoy.
I installed it and seems to work fine for now.
Hello ,i just red whole thread.
I'm working for Cisco support partner and just got a few tickets about this problem on WRP400.
to email@example.com > Firware version 1.00.04.c is on some of problematic units too and itself not solving this problem. Now testing Restrict Source IP and Auth Invite options enabled.
3) in a specific case, provisioning resets the configuration to default
In some cases our technicians configure WRP400 with a file loaded from "Administration - Config Management - Restone Configuration" web menu.
This file was generated from a device with firmware version 1.x.x.
After this procedure all work right.
With firmware 2.00.21, if after restoring procedure the WRP gets a new configuration via provisioning, it restarts in default mode.
In regards to item 2, dev comment is
Can you ask customer whether it only failed with Cisco AS5400HPX? Or it only works with cisco 2621XM, I want to know is it a general issue or just a specific case.
The fax problem described in item 2 is present only between WRP400 and cisco AS5400 HPX.
I tested same scenario with different gateways (cisco 2621XM, cisco 1760, etc.) without problems.
AS5400 is a common gateway in a Cisco PGW installation.
If you need more traces or logs, ask me.