Cisco Active Advisor Upgrade Wednesday Morning, April 23rd, at 6:30am CDT

Hello Cisco Active Advisor Users,
Cisco Active Advisor will be upgraded Wednesday morning, April 23rd, at 6:30am CDT.
During this process, a downtime of up to 5-10 minutes may be experienced in which the service may not be available. Please try to log in a few minutes later, should this happen.
We apologize for any inconvenience this may cause.
As always, please send your thoughts and comments about the service to [email protected] 
Thank you,
The CAA Team
www.ciscoactiveadvisor.com

Yet another "victim" of BT's incompetent Indian call centre,
I think more a victim of BT's totally incompetent internal systems; and probably initially of Openreach's outsourcing to installation to companies that often provide untrained and lazy installers.
The mods should get things sorted. at: http://bt.custhelp.com/app/contact_email/c/4951 . But be aware they take 3 working days to reply: sometimes more if busy.  That is pretty poor in your situation.  They have a good record of getting things solved once they are on the case.
Good luck.

Similar Messages

  • Cisco Active Advisor Upgrade on Thursday June 5th, at 6:30am CDT

    Hello Cisco Active Advisor Users,
    Cisco Active Advisor will be upgraded on Thursday June 5th, at 6:30am CDT.
    During this process, a downtime of up to 5-10 minutes may be experienced in which the service may not be available. Please try to log in a few minutes later, should this happen.
    We apologize for any inconvenience this may cause.
    As always, please send your thoughts and comments about the service to [email protected] 
    Thank you,
    The Cisco Active Advisor Team
    www.ciscoactiveadvisor.com

    Yet another "victim" of BT's incompetent Indian call centre,
    I think more a victim of BT's totally incompetent internal systems; and probably initially of Openreach's outsourcing to installation to companies that often provide untrained and lazy installers.
    The mods should get things sorted. at: http://bt.custhelp.com/app/contact_email/c/4951 . But be aware they take 3 working days to reply: sometimes more if busy.  That is pretty poor in your situation.  They have a good record of getting things solved once they are on the case.
    Good luck.

  • Cisco Active Advisor Upgrade on Tuesday July 8th, at 8:00pm CDT

    Hello Cisco Active Advisor Users,
    Cisco Active Advisor will be upgraded on Tuesday July 8th, at 8:00pm CDT.
    During this process, a downtime of up to 5-10 minutes may be experienced in which the service may not be available. Please try to log in a few minutes later, should this happen.
    We apologize for any inconvenience this may cause.
    As always, please send your thoughts and comments about the service to [email protected] 
    Thank you,
    The Cisco Active Advisor Team
    www.ciscoactiveadvisor.com

    Thanks very much... I can't even say its a pain... 8.0(1a) at least sort of works... 8.5(1) absolutely does not... I would be hard pressed to even believe they tried an outbound call or even any call with it before they tossed it out for release... As you mentioned in base 8.0(1) variable passing didnt even work...  does Calabrio have like one utopian demo system they use it on with like a single dialer port for testing?
    I think Cisco needs to do a better job of holding ther OEM partner to some continuing standards rather then certifying version 4.x and saying the rest are good.  At least Cisco could test it at a minimum!
    I know there are plenty of VAR's that would happily do regression testing on behalf of the CCBU if asked
    Chad

  • Upgrade of Cisco Active Advisor on Wednesday, Dec 18th at 8pm CST

    Hello CAA users,
    The Cisco Active Advisor Portal will be upgrades this Wednesday, December 16th at 8pm CST.
    We are expecting a downtime of up to 10 minutes, and apologize for the inconvenience this may cause.
    We would also like to take this opportunity to wish you and yours a very Happy Holiday!
    Thank you,
    The CAA Team

    Hello CAA users,
    The Cisco Active Advisor Portal will be upgrades this Wednesday, December 16th at 8pm CST.
    We are expecting a downtime of up to 10 minutes, and apologize for the inconvenience this may cause.
    We would also like to take this opportunity to wish you and yours a very Happy Holiday!
    Thank you,
    The CAA Team

  • Upgrade of Cisco Active Advisor on Wednesday, Jan 8th at 8pm CST

    Hello Cisco Active Advisor users,
    Cisco Active Advisor will be upgraded tonight, January 8th, at 8pm CST.
    During this process, a downtime of up to 5-10 minutes may be experienced in which the service may not be available. Please try to log in a few minutes later, should this happen.
    We apologize for any inconvenience this may cause.
    As always, please send us your thoughts and comments about the service. We'd love to hear your thoughts!
    Thank you,
    The CAA Team

    Hello Cisco Active Advisor users,
    Cisco Active Advisor will be upgraded tonight, January 8th, at 8pm CST.
    During this process, a downtime of up to 5-10 minutes may be experienced in which the service may not be available. Please try to log in a few minutes later, should this happen.
    We apologize for any inconvenience this may cause.
    As always, please send us your thoughts and comments about the service. We'd love to hear your thoughts!
    Thank you,
    The CAA Team

  • Upgrade to Cisco Active Advisor tonight at 9pm CDT

    Hello CAA users,
    Cisco Active Advisor will be upgraded tonight at 9:00PM CDT.
    During this time, we expect a brief downtime, of up to 5 minutes, so please excuse the interruption and try us again a few minutes following.
    Thank you,
    The CAA Team

    If you want to maniuplate the update process you need to use the manual process over the automated. If you use the automated process we attempt to do the following. One host in each Cluster managed by the Nexus 1000V will be chosen for upgrade. This host will be put in maintenance mode, upgraded, removed from maintenance mode, and then move to the next host. I'm not sure how we choose the host in the cluster but in my setup where I use IP addresses as host names it uses the lowest number IP address first.
    I can talk to engineering and see if it's possible, but we are constrained with what can be done based off the APIs that VMware makes available. Again if you want to control which ESX hosts are updated and when I would highly recommend using the manual method.
    louis

  • Cisco Active Advisor to be upgraded on Monday, January 5th at 11:00pm CT

    Dear Cisco Active Advisor Users,
    Cisco Active Advisor will be upgraded to a new version on Monday, January 5th, at 11:00pm CT.
    During this time, the site will be unavailable for about 30 minutes.
    We apologize for any inconvenience this may cause.
    Thanks,
    The Active Advisor Team

    The PC does support 4Gb of ram, although it's the max it supports, it does support it.  I have read quite a bit about other people having this issue with other systems and I've gone all through my bios looking for SOME sort of option that I can at least play around with, but there's nothing there.  I've also upgraded the bios thinking that "maybe" it could be something with that.  The video card I'm using is a Nvidia Quadro NVS 420 512 Mb.  I've tried disabling IndirectMemoryAccess in my xorg.conf thinking that might be messing with it somehow, but it did nothing.  I just tried removing the video card altogether and running w/ the onboard video and alas! I recovered 512Mb, which I would be pleased with, but when I add the card back, the available ram disappears again.  So now my question is this...  Why would the kernel be reserving 512Mb of system ram for a card that has 512Mb of ram built in (at the same time not visibly acknowledging the fact that it exists)?  Is this maybe a kernel option that I can pass at boot to disable it from reserving the system ram?
    I'm sorry about the lack of the bbcode tags btw, I'm a first timer to the forums (however an arch user for some time now). 
    Thanks again for any input, it's much appreciated!

  • What's New in Cisco Active Advisor?

    Hello folks,
    A new version of CAA is up, with a bunch of new features and bug fixes. Here’s a glimpse of the new features added recently.
    1) Delete devices
    Devices on your inventory list can now be deleted.
    Simply select the devices to delete and click the Trash icon at the top of the list.
    You will be asked to confirm your delete request.
    2) Enabled Features
    Quickly discover your devices’ enabled features using CAA! All IOS devices that enter your inventory list are now scanned for their enabled features.
    In the device’s window, you’ll find a new tab named ‘Enabled Features’
    Clicking this tab will show all the features that are enabled on your IOS device, ordered by Technology and Features.
    Clicking on the various Technology names will open up a new window that shows all available features under that category.
    3) Line cards and modules
    Good news! Now line cards and modules on your switches and routers will be discovered and displayed in CAA.
    In the inventory list, some devices will have the line card and modules icon
    This indicates that CAA has discovered line cards or modules on your chassis.
    Clicking this icon will lead you to the list of discovered modules. There you will see its status information, as well as relevant lifecycle data.
    When you go into the device overview window, click the same icon to see the line cards and modules list.
    Please note that there is a color code to the line cards and modules icon.
    Red indicates that CAA has found lifecycle alerts on one or more of your modules
    Blue indicates that no lifecycle alerts have been found.
    Please let us know what you think of these feature additions and of Cisco Active Advisor in general!
    We'd love to hear your thoughts and feedback!
    Thanks,
    The CAA Team

    Bug fixes.
    Type "ios 6.0.2" into the search bar at the top of this page by Support and read for yourself.

  • I purchased LR 5 upgrade (from Amazon) April 1 2015-How do I get free LR 6 upgrade?

    I purchased LR 5 upgrade (from Amazon) April 1 2015-How do I get free LR 6 upgrade?

    Hi Martin. See here:  Do I qualify for a free upgrade?

  • Hi, my iphone could not be activated after upgrade it from IOS4 to IOS6, it shows that is due to activation server is unavailable and no sim card in the iphone. Anyone can help me please?

    Hi, my iphone could not be activated after upgrade it from IOS4 to IOS6, it shows that is due to activation server is unavailable and no sim card in the iphone. Anyone can help me please?

    It is 99% hacked/jailbroken iPhone to use a different carrier than intended. You have to put the sim from the original carrier or ask them to unlock the iPhone. We as well as Apple cannot help you with this.

  • HT5642 Upgraded this morning. All worked fine for about 30min then "no service". Still the same problem and a reset of the device only fixes the problem for 15min. then we are back to no service?? When will apple fix this???

    Upgraded this morning. All worked fine for about 30min then "no service". Still the same problem and a reset of the device only fixes the problem for 15min. then we are back to no service?? When will apple fix this???

    Tried to reset network settings ...only fixes it for 15min. Did a firmware restore and a clean new phone setup. no settings restore. still have network service after around 60min. still running 6.1. i do get a prompt that i have to update settings to LTE. Have not excepted the settings as yet. Cellular data is still set to 3G....

  • ? I downloaded the upgrade this morning -- 6/6/12 -- and noew I cannot get into the Develop module.

    ? I downloaded the upgrade this morning -- 6/6/12 -- and noew I cannot get into the Develop module. I get an error message.

    The problem seems to have been corrected. When I checked to make sure that all other modules were accessible, Lightroom 4 quit, restarted and then checked something - "power point curves", went through some kind of internal procedure, after whiuch the problem no longer existed. The error message had been : "An error occurred when attempting to change modules." I decided to respond in this way in case someone else stumbles into this.
    Thank You for responding.

  • Workstation Notebooks FAQs - updated April 23rd 2015

    [Killer LAN adapter] Memory occupied issue.(August 8th 2014)
    [Intel WLAN adapter] Intel AC 7260/3160 WLAN adapter WiFi connectivity issue. (Jun 17th 2014)
    [Wireless Encryption Protocol support] WiFi connectivity issue with WPA encryption. (Sep 12th 2014)
    [Guide]
    How to install Killer’s LAN driver only (without the network manager)? (May 7th 2014)
    How to do a fresh install of Windows 7? (August 8th 2014)
    How to efficiently install all needed drivers on the notebook? (October 23rd 2014)
    How to install SSD and recover the pre-installed system to SSD on MSI Notebooks? (December 4th 2014)
    [Information]
    Information of MSI Workstation Notebook’s storage device information (April 23rd 2015)
    Introduction of MSI pre-installed programs. (August 26th 2014)
    [Tool]
    MSI System Information Export tool (February 4th 2015)
    Find more FAQs HERE.
    More guide from MSI technicians, visit the link: Ask A Question
    Visit our MSI service center for RMA service world wide.

    It never comes to my mind that MSI tech support can do things like this.
    Though these problems have not been mine yet, but I do appreciate it.
    Quote from: msiTech;102814
    GS70 2PC
    Game, Benchmark software crashes
    GE60 2PC
    Build in MIC issue
    All Models
    (Intel WLAN)Wifi constantly lost connection
    Install Killer LAN driver only(No management application)

  • Cisco 4500X IOS upgrade through ISSU

    Hi,
    I am having 2 number of cisco 4500x switch and configured with VSS
    so one switch is active and another switch is standby.
    I am panning to upgrade IOS through ISSU
    i read in document that it required auto boot enable in switch.
    My switch current Configuration register = 0x2101
    do i need to change config register or this will ok. If need to change then what will be auto boot and after IOS upgrade do i need to change it again.
    Please help....

    Hello Tarun,
    Please find below the steps to perform the ISSU:
    ISSU Prerequisites
    Before one can perform an ISSU, there are a few prerequisites one must verify for a successful ISSU. The following list explains what is initially required.
    • Must be using a redundant Cisco Catalyst 4500 switch with symmetric hardware (that is, supervisors, memory, rommon, NFL daughter card, and so on).
    • Both new and old Cisco IOS Software images must be preloaded to the file system on both supervisors.
    • SSO must be configured and working properly.
    • Config register must be configured to autoboot (that is, the value should have a "2" in the lowest byte).
    45010R-203# sh bootvar | i register
    Configuration register is 0x2102
    Standby Configuration register is 0x2102
    Several commands are available to verify if SSO is enabled:
    4510R-203# sh module | b Redundancy
    Mod  Redundancy role     Operating mode      Redundancy status
    ----+-------------------+-------------------+-------------------
     1   Standby Supervisor   SSO                  Standby hot        
     2   Active Supervisor    SSO                 Active
    45010R-203# sh redundancy states 
           my state = 13 -ACTIVE 
         peer state = 8   -STANDBY HOT 
               Mode = Duplex
               Unit = Secondary
            Unit ID = 2
    Redundancy Mode (Operational) =  Stateful Switchover
    Redundancy Mode (Configured)  =  Stateful Switchover
    Redundancy State              =  Stateful Switchover
                 <snip>
    4507R-ISSU# sh run | b redundancy
    redundancy
     mode  sso
    As a step prior to the beginning of the ISSU process, the new version of the Cisco IOS Software image needs to be loaded into both the active and standby supervisors' file systems. Both active and standby supervisor need to contain both the new and old images in the file system. In order to store both new and old images, the supervisors should be upgraded to contain sufficient amounts of flash memory prior to the ISSU process.
    The new images can be downloaded into both supervisors using commands such as:
    copy tftp: bootflash:
    copy tftp: slavebootflash: 
    The example below illustrates this verification:
    4510R-203#dir
    Directory of bootflash:/
    1  -rwx 13636500 Sep 6 2006 03:18:58 -08:00 cat4500-entservices-mz.122-31.SGA
    2  -rwx 13747611 Sep 9 2006 03:19:58 -08:00 cat4500-entservices-mz.122-31.SGA1
    4510R-203#dir slavebootflash:
    Directory of slavebootflash:/
    1  -rwx 13636500 Sep 6 2006 03:18:58 -08:00 cat4500-entservices-mz.122-31.SGA
    2  -rwx 13747611 Sep 9 2006 03:19:58 -08:00 cat4500-entservices-mz.122-31.SGA1 
    Once this check is verified, one can now proceed with the ISSU process.
    The ISSU process is started by typing the "issu loadversion" command on the active supervisor. This command directs the active supervisor to begin the ISSU process. The active supervisor, through intersupervisor communications, checks that the requested image has been downloaded into both the active and standby supervisors' file systems. If the required images are not present, the command is rejected, and an appropriate warning is generated.
    If the "issu loadversion" command is successful, the switch transitions into the "Load Version" ISSU state. The standby supervisor will reset and boot with the new version of the Cisco IOS Software image loaded into the file system.
    The following actions take place when the command is implemented:
    1. The standby supervisor (B) is reset.
    2. The standby supervisor (B) is booted with the new Cisco IOS Software image: Release 12.2(31)SGA1.
    3. If both Cisco IOS Software images are declared as compatible, the standby supervisor moves into SSO mode and is fully stateful for all compatible clients and applications. Compatibility allows for in-service software upgrade or downgrade between two versions to succeed with minimal service effect.
    4. If both Cisco IOS Software images are incompatible, the system moves into RPR mode, and the ISSU process is terminated with an appropriate message to the user. Images are declared incompatible when "required" clients or applications are not interoperable between two Cisco IOS Software releases.
    5. Standby "B" reaches the standby HOT state.
    6. The user has an option to abort the ISSU process by issuing the "issu abortversion" command.
    7. The "issu loadversion" command also supports a "forced" option that allows the operator to force the system into entering RPR mode when incompatibility is detected.
    Note: When performing an ISSU, disable manual switchovers. Performing manual switchovers during the issu process is strongly discouraged. The current implementation does not prevent it, but it does display a warning to the user.
    An example of the CLI for implementing the issu loadversion command is displayed below.
    On the active supervisor, one would issue the following command:
    4510R-203#issu loadversion 1 bootflash:cat4500-entservices-mz.122-31.SGA1 2 slavebootflash: cat4500-entservices-mz.122-31.SGA1
    Syntax - issu loadversion active-slot active-image-new standby-slot standby-image-new
    The second step of the ISSU process is to perform the issu runversion CLI.
    The user can issue the " issu runversion" command when:
    1. The ISSU state is "Load Version"; this can be verified with the "show issu state detail" CLI.
    2. The standby supervisor is running the new version of the software.
    3. The standby supervisor has moved into the "Standby Hot " state.
    The following actions take place when the " issu runversion" command is executed:
    1. A switchover occurs; that is, the standby (B) becomes the new active, and the old active (A) is rebooted and comes up as a standby.
    2. A timer called "Rollback Timer" is started with a previously configured value.
    3. Move both supervisors to "Run Version" state.
    4. If the command "issu acceptversion" is not issued before the "Rollback timer" fires, then the entire ISSU process is aborted via the automatic rollback.
    5. If the active supervisor console connectivity is established and the "issu acceptversion" command is issued, then the rollback timer is stopped.
    6. The user has an option to abort the ISSU process by issuing the "issu abortversion" command.
    An example of the CLI for implementing the issu runversion command is displayed below:
    On the active supervisor, one would issue the following command:
    4510R-203#issu runversion 2 slavebootflash:cat4500-entservices-mz.122-31.SGA1
    Syntax - issu runversion standby-slot [standby-image-new]
    Prior to issuing the `issu acceptversion' command the system will be counting down the rollback timer. If `issu acceptversion' is not completed before rollback timer expires an automatic abort will occur. This command stops the "Rollback Timer." This command serves as a feedback mechanism. This is an optional command and can be skipped in the ISSU process with the "issu commitversion" CLI.
    If this command is not issued within 45 minutes (default) from the time the standby supervisor moves into the "Standby Hot" state, it is assumed that the new active supervisor is not reachable and the entire ISSU process is rolled back to the previous version of the software. The acceptversion is not intended for long-term network operation. It is also important to note that none of the features available on the new version will work yet.
    The following actions take place when the command is implemented:
    1. The "Rollback Timer" is terminated. This means that the rollback timer is not looked at anymore. Therefore, the system can run in this state for an extended period.
    2. The user has an option to abort the ISSU process by issuing the command "issu abortversion."
    Aborting the ISSU process now causes the newly active supervisor (B) to fail over to the standby supervisor (A) running the old image and will also cause the rebooting supervisor (B) to load the original image. The issu acceptversion halts the rollback timer and helps ensure the ISSU process is not automatically aborted during the process.
    An example of the CLI for implementing the issu acceptversion command is displayed below:
    On the "New" active supervisor, one would issue the following command:
    4510R-203#issu acceptversion 2
    % Rollback timer stopped. Please issue the commitversion command.
    Syntax - issu acceptversion active-slot-number
    This is the last stage of the ISSU procedure. Once the user is satisfied with the new version of software, this must be committed by issuing the "issu commitversion" command. This command resets the standby supervisor and boots it with a new version of the software (same as the active supervisor). This concludes the ISSU process, and the new version of software is permanently committed on both supervisors. Since this is the conclusion of the ISSU process, the system can not be reverted back to the previous version of the software from this point onward as a part of this upgrade cycle. However, if for any reason users wish to go back to the previous version of the software, they can do so by starting a new upgrade/downgrade process.
    The following actions take place if the command is implemented:
    1. The standby supervisor (A) is reset and booted with the new version of Cisco IOS Software image.
    2. The standby supervisor (A) moves into the "Standby Hot" state in SSO mode and is fully stateful for all clients/applications that are compatible.
    3. Both supervisors are moved into "Final State," which is the same as "Initial State."
    4. Users can initiate switchovers from this point onward.
    An example of the CLI for implementing the issu commitversion command is displayed below:
    4510R-203#issu commitversion 1
    Syntax - issu commitversion standby-slot-number
    ISSU Process: issu abortversion
    One can abort the ISSU process at any stage manually (prior to issuing the issu commitversion command) by issuing the exec-level issu abortversion command. The ISSU process also aborts on its own if the software detects a failure.
    If a user aborts the process after issuing the issu loadversion command, then the standby supervisor engine is reset and reloaded with the original software.
    If the process is aborted after a user enters either the issu runversion or issu acceptversion command, then a second switchover is performed to the new standby supervisor engine that is still running the original software version.
    The supervisor engine that had been running the new software is reset and reloaded with the original software version. The command is accepted only in "Load Version" or "Run Version" states. In "Load Version" state, the active supervisor is running an old image and the standby supervisor is running new image.
    Syntax - issu abortversion active-slot [active-image-new]
    Let me know if you have any questions.

  • Cisco 1142N AP - Upgrade gone really wrong

    Hi everyone,
    I have run into a major issue with an autonomous Cisco 1142AP. We were in the midst of a firmware upgrade when something went wrong and caused the AP to reboot in an error mode. Basically the unit was flashing Blue, amber, red. We unmounted the unit from the wall, connected to the console, and it would now only flash red over and over.
    We pulled out the cisco guides and performed a factory reset on the unit. This still does not work. and the contents of our flash directory is empty. All we get is a ROMMON AP prompt on the unit. If I issue a set command, I can see the default settings for IP, netmask, etc.
    I cannot access the unit via the network, even after setting IP info and matching it up to my laptop. Since I have no network connectivity, I can't TFTP a new IOS file to the unit.
    I am stumped. Any ideas how to get the config as if it was out of the box, or an alternate way to TFTP to the unit?
    Here is a summary of what I get when I factory reset:
    using  eeprom values
    WRDTR,CLKTR: 0x87000800 0x40000000
    RQDC ,RFDC : 0x80000035 0x00000209
    using ÿÿÿÿ ddr static values from serial eeprom
    ddr init done
    IOS Bootloader - Starting system.
    FLASH CHIP:  Numonyx P33
    Checking for Over Erased blocks
    Xmodem file system is available.
    DDR values used from system serial eeprom.
    WRDTR,CLKTR: 0x87000800, 0x40000000
    RQDC, RFDC : 0x80000035, 0x00000209
    PCIE0: link is up.
    PCIE0: VC0 is active
    PCIE1: link is up.
    PCIE1: VC0 is active
    PCIEx: initialization done
    flashfs[0]: 1 files, 1 directories
    flashfs[0]: 0 orphaned files, 0 orphaned directories
    flashfs[0]: Total bytes: 32385024
    flashfs[0]: Bytes used: 1536
    flashfs[0]: Bytes available: 32383488
    flashfs[0]: flashfs fsck took 17 seconds.
    Reading cookie from system serial eeprom...Done
    Base Ethernet MAC address: 70:81:05:ec:21:d7
    Waiting for PHY auto negotiation to complete... TIMEOUT !
    Ethernet link is down.
    The system has encountered an error initializing
    the Ethernet port.
    The system is ignoring the error and continuing to boot.
    If you abort the system boot process, the following
    commands will re-initialize Ethernet, TFTP, and finish
    loading the operating system software:
        ether_init
        tftp_init
        boot
    button is pressed, wait for button to be released...
    button pressed for 69 seconds
    process_config_recovery: set IP address and config to default 10.0.0.1
    process_config_recovery: image recovery
    I then run a set command
    ap: set
    DEFAULT_ROUTER=10.0.0.1
    ENABLE_BREAK=yes
    IP_ADDR=10.0.0.1
    MANUAL_BOOT=no
    NETMASK=255.255.255.224
    PRODUCT_MODEL_NUMBER=AIR-LAP1142N-A-K9
    RELOAD_REASON=58
    ROM_PERSISTENT_UTC=1326908306
    TERMLINES=0
    TFTP_SERVER=10.1.70.250
    ip_ADDR=
    tftp=
    ap:
    Notice the lines in red, I must have typed someting incorrectly. How do I remove this?
    PS: Now once the unit boots after being reset, I cannot even type in the CLI. Someting majorly screwed up here.
    Can the bootstrap be reinitialized?

    Hi,
    Unfortunately I had followed that portion of the procedure but I was unsuccessful. Unfortunately I could not connect to the unit at all.
    What bothers me now is I cannot type anything in the CLI after I boot up, either normally, by interupting the boot, or by performing a reset.
    Edit: I am now able to type in the CLI, but there is also kinds of bizarro information when I run the set command. Is there a way to clean up this set config? Also, is there any other mechanism to transfer the IOS image other than TFTP. Like I said, I can't connect to the unit via network, only console.
    ap: set
    ABLE_BREAK=yes
    ANUAL_BOOT=no
    DEFAULT_ROUTER=10.0.0.1
    ENABLE_BREAK=yes
    ERMINES=ÿÿÿÿÿÿÿûÿÿÿ÷ÿÿÿóÿÿÿïÿÿÿëÿÿÿçÿÿÿãÿÿÿßÿÿÿÛÿÿÿ×ÿÿÿÓÿÿÿÏÿÿÿËÿÿÿÇÿÿÿÃÿÿÿ¿ÿÿÿ»ÿÿÿ·ÿÿÿ³ÿÿÿ¯ÿÿÿ«ÿÿÿ§ÿÿÿ£ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ{ÿÿÿwÿÿÿsÿÿÿoÿÿÿkÿÿÿgÿÿÿcÿÿÿ_ÿÿÿ[ÿÿÿWÿÿÿSÿÿÿOÿÿÿKÿÿÿGÿÿÿCÿÿÿ?ÿÿÿ;ÿÿÿ7ÿÿÿ3ÿÿÿ/ÿÿÿ+ÿÿÿ'ÿÿÿ#ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
                                                                 ÿÿÿÿÿà
    ETMASK=255.255.0830
    IP_ADDR=10.0.0.1
    MANUAL_BOOT=no
    MLIES=0
    NABLE_BREAK=yes
    NETMASK=255.255.255.224
    NUAL_BOOT=no
    PRODUCT_MODEL_NUMBER=AIR-LAP1142N-A-K9
    P_ADDR=10.0.0.1
    RELOAD_REASON=58
    ROM_PERSISTENT_UTC=1326908306
    TERMLINES=0
    TFTP_SERVER=10.1.70.250
    TMASK=255.255._06
    _ADDR=10.0.0.1
    ip_ADDR=
    set=ÿÿÿÿÿÿÿûÿÿÿ÷ÿÿÿóÿÿÿïÿÿÿëÿÿÿçÿÿÿãÿÿÿßÿÿÿÛÿÿÿ×ÿÿÿÓÿÿÿÏÿÿÿËÿÿÿÇÿÿÿÃÿÿÿ¿ÿÿÿ»ÿÿÿ·ÿÿÿ³ÿÿÿ¯ÿÿÿ«ÿÿÿ§ÿÿÿ£ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ{ÿÿÿwÿÿÿsÿÿÿoÿÿÿkÿÿÿgÿÿÿcÿÿÿ_ÿÿÿ[ÿÿÿWÿÿÿSÿÿÿOÿÿÿKÿÿÿGÿÿÿCÿÿÿ?ÿÿÿ;ÿÿÿ7ÿÿÿ3ÿÿÿ/ÿÿÿ+ÿÿÿ'ÿÿÿ#ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
                                                             ÿÿÿÿÿà
    tftp=
    ap:

Maybe you are looking for