Problem with USB-to-serial adapters?

[stian]

Hi,

I frequently use a Belkin USB to serial adapter to connect to router console ports. I've found that if I unplug the serial adapter while I still have a SecureCRT terminal session open, SecureCRT will hang.

I suspect the reason this happens is that unplugging the USB adapter removes the serial port to which SecureCRT is attached. It's obviously quite rude of me to be ripping the serial port out from underneath SecureCRT, but would it be possible to handle this error a bit more gracefully (for example, display an error message and treat the session as "Disconnected", which still provides the ability to scroll back and copy text out of the window, etc.)?

-Stian

[jfallesen]

You might want to try upgrading the driver to your USB-thingie.

I have had similar problems and even bluescreens with a Sandberg device being unplugged while SecureCRT was connected. Upgrading to a newer version of the driver for the device solved the problem and I can now unplug with SecureCRT connected without any problems.

Interestingly, SecureCRT does not seem to notice and if I plug it back in I can continue working.

[stian]

Originally Posted by jfallesen

You might want to try upgrading the driver to your USB-thingie.

I have had similar problems and even bluescreens with a Sandberg device being unplugged while SecureCRT was connected. Upgrading to a newer version of the driver for the device solved the problem and I can now unplug with SecureCRT connected without any problems.

Interestingly, SecureCRT does not seem to notice and if I plug it back in I can continue working.

I can do the same. I do not get bluescreens and Windows is not affected. If I plug the device back in, I can continue working as if nothing happened.

The problem occurs when I attempt to close the SecureCRT window or disconnect the session while the adapter is unplugged. I am running the latest drivers and they do not correct the problem. I do believe a fix in SecureCRT itself is needed.

[MrC]

This is most likely not SecureCRT/CRT's problem. Serial devices are opened and closed, and by nature, do not just disappear. So unplugging a cable (although not truely supported by hardware) from an active system is no real problem.

But a USB device when connected to a system has to create and map the device. In the USB to serial connection, the mapping is made at the OS driver level to map the USB device to the serial device. Unplugging the USB cable requires sending a device Close call, since the device is no longer in use. And this is where the problem occurs.

The driver should close the instantiation, and this leaves SecureCRT in a pickle - it probably wants to read (or write) more data from the device, but the device is gone. The fact that it works from some USB-to-Serial devices does not make it supported in general.

It is not appopriate to remove hardware when software is still using the device. This is why Windows has the Remove Hardware tasktray item - so that software can be gracefully notified of device closure.

I'd put this in the Don't Do This category.

[stian]

Originally Posted by MrC

This is most likely not SecureCRT/CRT's problem. Serial devices are opened and closed, and by nature, do not just disappear. So unplugging a cable (although not truely supported by hardware) from an active system is no real problem.

But a USB device when connected to a system has to create and map the device. In the USB to serial connection, the mapping is made at the OS driver level to map the USB device to the serial device. Unplugging the USB cable requires sending a device Close call, since the device is no longer in use. And this is where the problem occurs.

The driver should close the instantiation, and this leaves SecureCRT in a pickle - it probably wants to read (or write) more data from the device, but the device is gone. The fact that it works from some USB-to-Serial devices does not make it supported in general.

It is not appopriate to remove hardware when software is still using the device. This is why Windows has the Remove Hardware tasktray item - so that software can be gracefully notified of device closure.

I'd put this in the Don't Do This category.

We already established this much in the first post. My point was just that it is within SecureCRT's abilities to detect that the device is gone and display an appropriate error message, which I'm sure you'll agree is a better response than getting stuck (probably in the windows equivalent of an iowait state) waiting for the device forever.

[MrC]

Hi Stain,

I'm not sure if you fully understand. Certain system calls are "blocking" and CANNOT be interrupted by software. For example, a blocking read call to a device will NOT return until the driver allows it to! The software makes a call to read some data, and that call puts SecureCRT to sleep until the device driver has some data to provide. Then SecureCRT will get woken up by the device driver. If the device goes away, and the driver does not wake SecureCRT, it sleeps forever.

That said, there may be nothing SecureCRT can do to prevent this. The driver MUST wake SecureCRT or any sleeping software for it to have a chance to clean up gracefully.

[galb]

Originally Posted by stian

I frequently use a Belkin USB to serial adapter to connect to router console ports. I've found that if I unplug the serial adapter while I still have a SecureCRT terminal session open, SecureCRT will hang.

When you say 'SecureCRT will hang', can you tell me more
precisely what is happening?

For example, after you unplug the device, do SCRT's menu's
still display?

Does the hang happen immediately after you remove the device,
or after some time?

What OS are you running?

I have been testing a Belkin FSU409, and unfortunately, the belkin
drivers are buggy. In particular, they don't don't handle the
inter-character timeout correctly, and they don't appear to be
able to cancel pending I/O requests.

In my testing under Windows XP, this results in a 10 second hang
on disconnect. (UI will become unresponsive.)

In addition, the serial port is locked until a reboot, and while
the SCRT window dissappears correctly, the SCRT process will
never terminate.

I have sent email to belkin technical support (as of Friday evening)
but haven't yet heard back from them.

Windows does actually provide a way for applications to get notified that device has gone away.

CRT doesn't currently register to receive this notification.

The behavior you should currently see is either the behavior others
have described, that when you reconnect the device you can keep
typing, or you could concievably get errors from SCRT if the driver
choose to complete CRT's pending I/O requests w/ errors during
surprise removal.

If CRT registered for the notification, it could close the COM port
when the device is removed (it could close the COM port before
remove if it was a safe removal, or, if I recall correctly, veto the
safe removal of the device.)

What should CRT do when the user attempts to remove the COM
port that is open?

1. Close the com port and let the operation happen?
2. Veto the operation (assuming we really can and I'm not misremembering
the way all this works)?
3. Do nothing-- let the user either reconnect the com port and keep
going or manually click the disconnect button to terminate the connection
to the (now defunct) com port?

If CRT was notified of a surprise remove, what should it do?

1. Close the com port
2. Same as 3 above-- do nothing?

Thanks,

Joseph

[jfallesen]

Originally Posted by galb

What should CRT do when the user attempts to remove the COM port that is open?

1. Close the com port and let the operation happen?
2. Veto the operation (assuming we really can and I'm not misremembering
the way all this works)?
3. Do nothing-- let the user either reconnect the com port and keep
going or manually click the disconnect button to terminate the connection
to the (now defunct) com port?

I think 2 really does not make a lot of sense. I do not think anybody will ever remember to gracefully shut down a USB device before unplugging it, and for CRT the most likely scenario would be a USB COM device.

The "correct" thing to do would be 1 as this would probably lead to fewer problems with funny drivers.

There is also something attractive in 3 if you need to do a temporary disconnect but I do believe you rarely need to do that and that you can live with the session having to be manually reconnected. If CRT was configured to not close on disconnect, a simple hit on Enter would work quite nicely.

So I vote for option 1 which would also be the case for a surprise remove.

/Jens

[galb]

Originally Posted by stian

I frequently use a Belkin USB to serial adapter to connect to router console ports. I've found that if I unplug the serial adapter while I still have a SecureCRT terminal session open, SecureCRT will hang.

I suspect the reason this happens is that unplugging the USB adapter removes the serial port to which SecureCRT is attached. It's obviously quite rude of me to be ripping the serial port out from underneath SecureCRT, but would it be possible to handle this error a bit more gracefully (for example, display an error message and treat the session as "Disconnected", which still provides the ability to scroll back and copy text out of the window, etc.)?

I believe I found the bug that was causing this and checked in a fix tonight, so it should behave better in the next beta (which is soon I believe... I think we're freezing code tomorrow.)

It should now go to disconnected (at least for the belkin I have it does... I think the behavior might be somewhat driver dependant.)

Let us know if the next beta doesn't work correctly.

Thanks,

Joseph