HI Joel, While there isn't an explcit button to cause the WOL packet to be sent, creating a cross-launch of any kind to the target device will cause the WOL packets to be sent to it. When we create one of these cross launch tunnels, we send the WOL packets, just in case the device is sleeping. Once you create the cross-launch instance, you can immediately delete it if you don't need it. Hope that helps, Robert P.S. It does make sense to offer this as a stand alone feature. ... View more

Hi Joe, The ON100 requests an address from the default VLAN on startup. After startup, it goes into discovery mode and watches for any VLAN 'hints' that are broadcast through the LAN port. If it discovers a VLAN, it tries to join that VLAN using DHCP on a specific VLAN interface. Is there any chance that you have the same server handling both the voice and data VLANs? I'm asking as for each DHCP, we end up using the same MAC address. It might be possible that your DHCP server only supports a single device appearing on the network, regardless of which VLAN it is present on. Can you share details about the DHCP configuration for this network? Thanks, Robert ... View more

When NTOP is enabled, all of its content can be accessed via the local port 3000. You can connect to it using http:// :3000 Using our tunneled solution isn't necessary to use NTOP's web GUI. In general, we've been under the impression that most management will be done remotely and that tunnels, of some sort, would always be necessary. Robert ... View more

Can you try doing a DNS resolve of the domain xlx-1-35150-2036-6400f120d732.1-dfw-xlx.cisco-onplus.com Since I'm on Unix like environments, I use tools like nslookup and dig. I'm sure that no matter what tools you have, we'd expect that you gets something like: bear:~ jamwyatt$ nslookup xlx-1-35150-2036-6400f120d732.1-dfw-xlx.cisco-onplus.com Server:                    72.163.47.11 Address:          72.163.47.11#53 Non-authoritative answer: xlx-1-35150-2036-6400f120d732.1-dfw-xlx.cisco-onplus.com          canonical name = www.1-dfw.cisco-onplus.com. Name:          www.1-dfw.cisco-onplus.com Address: 216.227.195.156 The screen shots you posted suggest that there's a DNS resolution issue for the cross-launch services. I've verified that it works for me, but that doesn't help you. What is your DNS setup? Are you going through a local DNS caching server (i.e. Windows Server?). Are you able to remotely connect to other devices at your site? If you were to set you PC's DNS server to use '4.2.2.2' for DNS resolution, do things start working? Robert ... View more

Hi JP, The 'Status 2' led, once the device is activated, indicates the status of the heartbeat. In general, that's your first, best, check on the state of the connection. I can see that it might also be good to present that on the status page too, but as Mike noted, there's not too much there and it gets very little use in practice. As for the IP address for 1-dfw.cisco-onplus.com, while that might be correct, our service has the ability to reconsitute with a different IP address during extreme service situations (never happened yet, but we're prepared). If you were thinking about doing an ACL to permit 11300 and 216.227.195.156, it might be better to target permitting the ON100 to use port 11300 without destination restriction, just for safety? Robert ... View more

Glad to hear it ... We've seen a couple of sites (yours is number two) that had this issue recently. We have timeouts on the donwloads such that it can give this problem if a WAN connection gets really slow. Also, we did see a single case where there was some issues with making https connections (potentially certificate changes), but a simple reboot fo the device cleared that. On reboot, the device also attempts a firmware upgrade. None-the-less, it is good to know that it is cleared, but we'd want to know if it happens again. We might be too aggressive on our timeouts ... or something of that nature. Thanks, Robert ... View more

HI Robert, What are the two Status LEDs showing? Robert ... View more

Hi Kurt, I was unable to get results from a ‘showtech’ request until I rebooted the device. Prior to the reboot, I ended up with a show tech tar file with 2 bytes size. After the reboot, I could get the showtech and see that there was success in the upgrade on boot, and the previous nightly attempts were dying with an odd failure about getting a mix up on http headers. We’ll have to see if this repeats, but it certainly is a new issue. I’ve seen timeouts before where network latency is way too high. That isn’t related to this issue. The post-reboot upgrade went nice and fast too. So, for the moment, wait and see, but all is good now. I’ll do some more checking on my side, but I don’t hold out any hold of recreating this as it was pretty odd. Thanks, Robert ... View more

Hi Kurt, I assume that this device has been installed for a while, right? Has anything on the network changed that might block content? I'd like to take a closer look, and possibly reboot the device. If that's ok with you, please send me a PM with the URL for the topology for this customer? Thanks, Robert jamwyatt@cisco.com ... View more

Hi Steve, Regarding your comment on telnet/ssh. Do you use the 'Generic' connection to connect telnet and ssh today? Using the Generic connection and port 23 (telnet) or port 22 (ssh), you can create a tunnel that handle those protocols. The resulting tunnel has a push pin that can copy the relavent temporary data to your cut-n-paste buffer such that you can paste it into your application or onto your command line. I suspect that the only thing new we can add for this feature going forward is an explicit ssh/telnet tab or button similar to VNC/RDP connections today. Thanks, Robert ... View more