Troubleshooting

[simon]

I have connected the console cable to iPhone but do not get a router or switch prompt - what is wrong?
------------------------------------------------------------------------------------------------------------------
If no router or switch prompt appears after a few seconds of connecting the Redpark cable then try one or some of the following:
- Does the connection icon show a green outline with a grey world? If not, the cable has not been detected. Please disconnect the cable and reconnect it to the Apple iOS device. Also check it is connected to the console (as opposed to AUX or Ethernet) port on the Cisco or other Network device. If you continue to have problems, please contact us at support@get-console.com - you cable is possibly faulty.
- Connect the cable to the Cisco / Juniper console port PRIOR to connecting the other end to the Apple iOS device. If you did not do this, disconnect both ends and try again with the Cisco / Network Device end connected first. If the connection icon is green, but there is still no screen output, try the following:
- Change the flow control setting from the default (none), to either RTS/CTS (hardware) or Xon/Xoff (software). This in particular solves issues with Cisco 2900XL/3500XL switches.
- Change the stopbits in settings from 1 to 2 stopbits and hit the "enter" button a few times to reset the Cisco console port
- Only use Redpark RJ45-Iphone adapter cable - other "homebrew" cables will not work.
If you receive an error saying "This device is not optomized for iPhone or similar", then disconnect and reconnect the cable (you will not lose your Cisco session). We are aware of this occasional bug and expect to fix it in the v1.4 release.
- Ensure the Cisco console port is configured to use a baud speed of between 9600 and 57600 - other speeds will not work. You can test this by rebooting the Cisco / Network device - if a lot of garbled characters appear on the screen then there is a mismatch between the console port speeds.
- Possibly your Network device is booting where there is actually no console output - just wait for few minutes

I am trying to start the Session Sharing service to allow remote access to my session but it times out - help!
------------------------------------------------------------------------------------------------------------------
If you have a local connection that is working, but when you attempt to initiate a remote session you get a timeout from the Get Console backend server, then try one or some of the following:
- First, test internet access via 3G / Wifi in your i-device"s safari browser by browsing to google.com or other public internet web sites. If browsing in Safari does not work then Get Console app will not work for remote access
- If browsing is working, but remote access still times out, try blocking automatic proxy use/detection in the iPhone/iPad/iPod general / network settings - while the Get Console application uses standard HTTP and should survive inspection and corporate proxies, some corporate proxy servers may still break the application
- If using wifi, switch to 3G and try again as some of the newer application aware firewalls or IPS devices may prevent access
- Try changing the Get Console backend server from Asia Pacific to either UK or USA (or if already using UK or USA, then change to Asia Pacific). The 3 backend servers offer the same service, and the selection is a user preference depending on where they are geographically located.

I can connect to the remote console (Session Sharing), it works ok for a few minutes and then seems to hang for a long period
------------------------------------------------------------------------------------------------------------------
Sometimes this can occur when the iOS device goes into power-saving mode. When session sharing is enabled, the iOS device should be prevented from going into "deep" sleep, and also the Get Console app should remain the fore-ground application. The apple power management and multitasking sub routines along with wireless carrier radio management can also make 3G performance "lumpy" when your session has been idle for a little while. Also, do not try to multitask on your iOS device while running the remote console session, as while the Get Console app for local use will run in background, certain remote access (session sharing) functions do not work in multitasking background mode.

The session sharing performance is very slow
------------------------------------------------------------------------------------------------------------------
Generally, the session sharing speed is usable, but not instant in response. The speed of the session sharing connection is dependent on the Wifi/3G latency from the iOS-device to the Get Console website, and then the latency of the Get Console website back to the remote users browser. We currently have backend servers in US, Asia Pacific and Europe, along with Geo load balanced web front end server in US and Asia Pacific. The user of the iOS device needs to select the closest Get Console backend server to their geographical location via the applications settings. We plan to implement automated backend selection in a later version of the app.

No output from console on very old Cisco switches
------------------------------------------------------------------------------------------------------------------
We have received a couple of reports of users not able to get any response from the console when connecting to Cisco 2900XL and 3500XL switch console ports. This is despite the connected icon showing green, and the baud/stopbit settings being correct. This is due to hardware flow control needing to be enabled on these console sessions - this setting is available in version 1.41 and above of the Get Console app. Please set the flow control setting to RTS/CTS (hardware). The cable should be disconnected and reconnected to the Apple iOS device after changing the flow control settings.

[simon]

Review the settings on you line con0 on the 6500 - if flowcontrol hardware is enabled then you'll need to turn that on in the app (use RTS/CTS) and then disconnect/reconnect cable from the iPad/iPhone end. We have tested it with our sup720 in our lab 6500 and it works fine, but the 6500 console port is configured as default (no flow control).

Flowcontrol settings were enabled in v1.41, so please update your app if you havent already.

Thanks
Simon

[sweetcaroline]

Hi Im trying to send hex values to a terminal. I can do this on a PC, Im trying to do it with your app and cable. I can connect and type commands, I just cant enter hex commands. Is there a format that I should follow? I read the user manual and typed in values in the hex script as 16010100 but it didnt work. I then tried 0x16 0x01 0x01 0x00 and that too didnt work. Do I need to add a terminate script at the then of the hex values? Please let me know so that we can use your program at our company.

Thanks

[simon]

To send hex values in a script use the "Send Hex Bytes" function rather than "Send String" - this is a v1.80 feature so please use most recent release.

The "Send Hex Bytes" format does not require a leading 0x?? - but send only 2 bytes - i.e. for your application you would have 4 script entries
16
01
01
00

Also the Send Hex Bytes will not send a carriage return / new line, so if this is needed by your receiving device then add a fifth entry with 0D to send an ASCII C0 control code for Carriage Return.

You can then run your script via the script button once your terminal is connected to your device.

Please let us know if this works for you.
Thanks
Simon Hope

[sweetcaroline]

This does not work either. I can connect and see a response when I am in terminal mode but it is not accepting the script with Send Hex Values. Any other ideas?

[sweetcaroline]

Also, it looks like the send hex data is not being sent. I connected the cable to my computer and can see keystrokes but when I press the script, nothing happens. Do I have to do something else to send the script?

[simon]

can you please email me a copy of your .script file and i will test it - if your script has a sendX action you should see it come to the terminal when you run the script.

Thanks
Simon

[sweetcaroline]

Simon,

Below is the code that works. It appears that the script is only sending the data if the terminal sends any key to the ipad right after the script button is pressed. This is odd because I dont have a wait statement in the code. Is there a way to get around this?

Thanks




Here is the code that works, but only if the user presses any key at the terminal.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<string>sendbytes</string>
<dict>
<key>bytes</key>
<string>16076375010100f822</string>
</dict>
</array>
</plist>

[simon]

Hi Sweet Caroline.
Weve had a look at this - you are hitting a bug (scripts needing to have waitforstring as first action item). Its fixed in v1.82 that is going to Apple at the end of the week. Sorry for this problem.
Thanks
Simon

[daniel]

Hi Michael,

The TERM variable in the advanced page is a string sent as part of Telnet and SSH connection setups to allow remote shells to configure themselves appropriately; it's not used for serial connections. Importantly for your situation, it doesn't control the client side / GetConsole terminal emulation.

The issue you are facing I suspect is with what is sent when you press the function key F2. Function keys vary quite a bit amongst different terminals and currently GetConsole uses the SCO syntax, e.g. <ESC>[N for F2.

We are hoping to make the function key selection configurable in the next version of GetConsole with a few of the more common terminal types, but in the meantime as a workaround you could try manually entering what F2 would send on a few different types of terminals, e.g. <ESC>[OQ or <ESC>[12~

Hope that helps!