8

Update#2, After testing with different console applications, I think the conclusion is GNU screen coming with Mac OS X 10.11.4 has a defect causing this issue. Hope some dev can see this and help diagnose for a fix...

Update#1, Now I upgraded to the 10.11.4 and also upgraded cable driver... Issue still happens...help!!!

I have a USB to Serial Adaptor for connecting to CONSOLE port of switch/router and I use "screen" inside Terminal to connect. Recently I found the "screen /dev/cu.usbserial 9600" works only once for every system reboot. Here are the steps to replicate:

  1. The output of "ls /dev/usb" shows the correct device.
  2. Login to console of the device with "screen /dev/cu.usbserial 9600"
  3. Press "Ctrl+A, Ctrl+K" to exit screen
  4. (optional), disconnect/reconnect the usb to serial adaptor from laptop OR disconnect/reconnect the console cable from target device.
  5. The output of "ls /dev/usb" still shows the correct device.
  6. Try to connect to console again with "screen /dev/cu.usbserial 9600", the screen process will hang. Once that is happening, the screen process can not be killed via "sudo kill -9" and only be solved by complete power cycle. BTW, the laptop will also hang during reboot/shutdown, until I keep pressing on power button...
  7. Once screen hang, The output of "ls /dev/usb" would show nothing.

Once laptop boots up again, I can connect with the same screen command and same scenario for step 2-3 above...

I have Mac OS 10.11.3 and adaptor is Micro Innovations branded (Prolific chip). I downloaded and installed/re-installed driver from Prolific site and no difference...

Any idea?

|improve this question
  • Anyone could help? Or I am the only experiencing the issue? – m1xed0s Feb 24 '16 at 18:29
  • Now I upgraded to the 10.11.4 and also upgraded cable driver... Issue still happens...help!!! – m1xed0s Mar 22 '16 at 22:55
  • First, I would not use screen to connect to serial consoles. minicom is is the tool you want, it can be installed via MacPorts. Second, the Prolific chip is problematic–particularly with Cisco hardware. The only reliable USB-Serial that I have used is the Keyspan USA-19HS. – medbot Apr 6 '16 at 0:00
  • @medbot, the one I have is provided by the company...so cheaper from my perspective. I really did not have issue with connecting to different vendor devices via screen, just recently started causing me issue on Mac. – m1xed0s Apr 7 '16 at 12:58
1

Firstly, does cu -l /dev/cu.usbserial -s 9600 work more than once? If not, how does it fail?

Because the second open blocks and does not die even with kill -9 it probably it is a driver issue with the call to open(2) getting the initial device handle blocking. The device open might block if the device is not in local mode and the CD input is low.

Some versions of those devices have hardware flow control bugs. You could try a hardware fix of looping RTS to CTS and connecting DTR, DSR and CD on the connector and just let the RX, TX and ground pins connect to the console port.

Another possibility is running stty clocal < /dev/cu.usbserial. This should make the device ignore control signals. This is worth trying from a different terminal while the second open is blocking.

Update:

You need to run cu with sudo so that it can write a lock file to /var/spool/uucp. If you have no contention for ports (unlikely on a single user Mac), you can change the lock directory path using a config file. Create an empty directory, then create a config file setting lockdir to that directory path. Something like:

lockdir /User/yourname/lockdir

Then run using a command line like this:

cu -I /path/to/conf/file -l /dev/cu.usbserial -s 9600
|improve this answer
  • cu -l /dev/cu.usbserial -s 9600 works more than once. I think your are right on the open(2)...I also tried stty clocal < /dev/cu.usbserial but after that screen still hang on second connect... – m1xed0s Mar 23 '16 at 17:18
  • To just save hacking effort on the adaptor and money to buy anther adaptor, should I just simply use cu instead of screen when I need to connect to console? – m1xed0s Mar 23 '16 at 17:23
  • @m1xed0s Yes, you should use cu instead of screen. If you need the detach functionality, you can do screen cu -l /dev/cu.usbserial -s 9600. The issue is probably around screen changing the RS-232 signal handling on the port, and cu leaving it alone. – janm Mar 23 '16 at 22:32
  • @m1xed0s With the stty clocal < /dev/cu.usbserial command, did you try it while screen was hanging? Trying it before the second command and during the second command test different things; it's worth trying both. – janm Mar 23 '16 at 22:33
  • I don't need detach feature of the screen but the only downside with cu is i have to run with sudo... I will check the stty again and report back – m1xed0s Mar 24 '16 at 0:58
1

I also had this issue, exactly as described with a PL2303 USB/serial device.

The solution I went with was to use the driver from https://www.mac-usb-serial.com/

Screen worked fine after this for multiple connections.

|improve this answer
0

I would like to mention, not being mentioned anywhere else, that I have the exact same problem on a Raspberry Pi with the same USB to serial connector.

One question that remains unanswered is how to disconnect: I found that out in the cu man page: ~.

Also I found out that sudo cu -l /dev/cu.usbserial -s 9600 works on reconnection to the RPi (RPi 1, Model B); but sudo cu -l /dev/cu.usbserial -s 115200 doesn't; which is at odds with Adafruit's instructions, which say screen /dev/cu.usbserial 115200.

I am happy now to be able to connect and disconnect to the RPi at will. I am also able to cu without sudo. Thank you @janm.

|improve this answer
0

To resolve this, I removed the FTDI extension and reinstalled the most current version of the 'driver' (v2.3) downloaded from FTDI's website.

rm /Library/Extensions/FTDIUSBSerialDriver.kext
Install new version
Restart

Now I can disconnect and reconnect the USB to Serial cable without restarting.

|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .