04-24-2012 01:06 AM - last edited on 04-24-2012 09:42 AM by Larry
What were you thinking?!
What on earth can be used to justify using a NON-STANDARD USB connection for the console? Shipping a 1.5m cable that is hardly long enough to reach the ladder let alone the ground? Post drivers on your support site that is down while I'm trying to fix your **bleep** device that went down due to a bug in your software [this is not really relevant to this, but anyway] out in the rain?
At least Cisco is able to do things right. Their USB consoles have a serial console right next to them. And they use a standard connector.
A lot of the time my work involves shipping an IP KVM or serial-to-ethernet dongle to customers to debug stuff hundreds of kilometers away. No more with the AP175. Now I have to juggle with the customer to get the serial drivers working, find your non-standard usb cable and a usb extension, guess which ever COM port the thing is today and then get VNC or some other way to access the laptop, and get the output via pastebin. Now this is convenience.
I really hope you have a good explanation for this.
04-26-2012 01:01 PM
Thanks for reaching out and sharing your concern with Aruba.
Let me start by saying that we consider the use of the console port as an interface of last resort and we consider any situation that requires that interface to be engaged to be a serious issue. I encourage you and your field personnel to make Aruba’s tech support organization aware that such remediation is being initiated. It is our goal to eliminate issues that lead to this result since it is a highly disruptive event when the gear is mounted 20ft in the air.
As to your comment about driver accessibility. I will work with the team to ensure we understand why it might be difficult to get to the appropriate driver.
On the final point. Why did we choose a type A interface on the unit. There are a number of reasons.
1) It is a standard interface and is available globally. It is now not quite as pervasive as the Mini USB that many of us are familiar with due to their proliferation with smart phones but they remain readily available anywhere in the world.
2) In the US type A interface cables and extensions are available in various lengths at places like Fry’s, Bestbuy …
3) The type A interface is more robust that some of the mini usb interfaces.
4) It is generally easier to ensure that you are trying to connect it the right way up. This is particularly important in the dark.
5) There are many mini usb type out there, mini-A, mini-B, Micro-A and Micro-B and they are often difficult to distinguish until you try to insert them into the mating part. Having to come back down from the install location and make another trip to your local electronics store to get the right one is a pain. Full type A is readily identifiable and reduces the chance of getting the wrong one.
6) In the field the USB A interface has the best retention characteristics, so being sensitive to the plight of the person in the air we wanted to maximize the ability of the connector to stay in place.
Again, thanks for your feedback and I hope this addresses your concerns.
Product Line Manager: Outdoor Solutions
08-03-2015 03:51 PM
Please explain the trick into catching the boot cycle percisly timed for the USB "serial port" to come up and interrupting the auto boot cycle. I just spent an unsuccessfulo hour on the roof with this usb serial port. Its an active port meaning when the unit is off the port goes away. After powering up the AP it takes several seconds for the port to come up and the driver for it to load. Then start putty. And if one guesses correctly on the time, there is a second or two when return can be used to interrupt the boot sequence. So much trial and error I found a timing which worked. Only then to be frustrated again when after the inital return to interrupt auto boot, the AP or my Client, can't tell which, stops communicating. Really? Also how about new and signed drivers so they will work in a current Windows operating system operating system. My next trip to the roof top will be to pull the unit down and bring it onto a bench because this design limitation is rediculuous.
08-03-2015 04:08 PM - edited 08-03-2015 04:15 PM
I'm not sure why it would have taken that long unless it's a windows/driver issue (I don't have a PC handy to test with right away, but will try that tomorrow in the lab). I usually fire up putty/serial terminal right after powering up the AP and I can catch the AP boot within a second or so (usually while the AP's console is posting before apboot). Are you Win7, 8, or 10? I can test with 7 and 8 I think.
Also, in case someone monkeyed with the AP environment variables, make sure someone didn't set the apboot timers to zero. When you get in to apboot, run a printenv and send me the output at email@example.com.
Otherwise, once I get into the lab tomorrow, I will try and replicate. Let me know what windows version you have. For putty, if I don't know the COM port, I let the AP power up with the serial driver connected, and then check the system properties to see what COM port it took. From there, it will be the same COM port everytime, I will power off the AP, configure Putty to use that COM port, power up the AP and connect once the power light illuminates, and I will catch the AP posting before the AP boot in most every case.
Again, like Eric mentioned above, getting in the console port is a very last resort. I would be interested to know the reason you need the console port access of the AP (for my own edification). Thanks!
Sr. Techical Marketing Engineer
08-03-2015 04:10 PM
Also, I will bring up the driver signature issue for the AP-175 and our serial console driver. In the interim, driver signing checks can be disabled in Windows temporarily to let you get done what you need to get done, but it should only check that upon install, not upon each and every use.
Sr. Techical Marketing Engineer
08-03-2015 11:06 PM - edited 08-03-2015 11:08 PM
the easy way to avoid the problem of catching the bootprompt - assuming the AP can actually boot ArubaOS - any ArubaOS - and reaches the "#" prompt is as follows.
1. let ap boot/power up etc.
2. connect serial , get it working - ensure you can see bootup messages scrolling away
3. eventually AP should reach "#" prompt. If it hangs around the section where it wants an IP (perhaps there is none, connectivity/dhcp issue etc) then type a "ctrl-c" into the serial, that will break the boot script.
4. you should in most cases (but maybe not every possible scenario) now be at "#" prompt. Enter "esc+ctrl+k" (i.e. hold them down and keep them pressed one by one in that order)
5. ap responds "switching to full access"
6. type reboot.... wait for it to shutdown, now you will see the full apboot countdown and can interrupt without timing lottery.
08-04-2015 02:12 PM
PLZ, please see the attached for a guide. Note that the AP-228 and 27x family are different in that the serial adapter within the AP is powered by the laptop. So you can connect the laptop to the AP-228 or 27x series, see the com port come up, then start the console and power up the AP to capture the apboot.
Hope this helps.
Sr. Techical Marketing Engineer