Bug #7891

Could not configure port: (5, 'Input/output error') --- STILL NOT SOLVED !

Added by onsenfout onsenfout about 1 month ago. Updated about 1 month ago.

Status:Feedback Start date:05/18/2020
Priority:Normal Due date:
Assignee:- % Done:


Target version:-
Chirp Version:daily Platform:Linux
Model affected:Baofeng UV-5R+



Model Baofeng UV5R+PLUS

Cable: genuine BAOFENG

OS: Fedora31

Casual user added to dialout group, same failure.

With daily chirpw and root exec to prevent rights issues:

[root@adramalec chirp-daily-20200516]# chirpw
ERROR: --- Exception Dialog: Could not configure port: (5, 'Input/output error') ---
ERROR: Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/chirp/ui/mainapp.py", line 731, in do_download
File "/usr/lib/python2.7/site-packages/serial/serialutil.py", line 240, in init
File "/usr/lib/python2.7/site-packages/serial/serialposix.py", line 272, in open
File "/usr/lib/python2.7/site-packages/serial/serialposix.py", line 326, in _reconfigure_port
raise SerialException("Could not configure port: {}".format(msg))
SerialException: Could not configure port: (5, 'Input/output error')

ERROR: ----------------------------
[root@adramalec chirp-daily-20200516]#

USB chipset/driver:

root@adramalec chirp-daily-20200516]# lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

Chirp is broken, same result with or without radio actually connected, tried on all USB ports of an healthy desktop.


Related issues

related to Bug #2923: Could not configure port: (5, 'Input/output error') Closed 10/15/2015
related to Bug #4061: Get error "Could not configure port: (5, 'Input/output er... Closed 09/24/2016
related to Bug #7563: "Could not configure port" on Baofeng UV-5R+ Feedback 01/14/2020


Updated by Bernhard Hailer about 1 month ago

  • Priority changed from Urgent to Normal
  • Model affected changed from (All models) to Baofeng UV-5R+
  • Platform changed from Windows to Linux

I don't think Chirp is broken. The serial port isn't been created in the first place, which should happen on the operating system level. There are a few things you could research.

1) Some Linux distributions don't use the dialout group for serial ports, they use "serial" instead. I don't know whether Fedora is one of these.
2) You may need to do some research about the USB to Serial adapter you're using. Some input can be found here, for example: [[https://unix.stackexchange.com/questions/189896/testing-qinheng-electronics-hl-340-usb-serial-adapter]].

Your subject line says: "STILL NOT SOLVED !" - well, it's something you need to resolve on your system yourself. Do you have another ticket open about this, or why do you expect a solution?

Finally, you could simply ask on the mailing list.
You might get some more feedback there.

Updated by Bernhard Hailer about 1 month ago

  • Status changed from New to Feedback

Updated by onsenfout onsenfout about 1 month ago


Please don't put on my shoulder the fact that CHRIP IS broken, i.e don't work in normal situation with one of the most standard Linux distro: FEDORA.

For info:

[root@adramalec ~]# ll /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 19 mai 08:24 /dev/ttyUSB0

The group of /dev/ttyUSB0 IS dialout, and the test with root user prevent any access rights issue.

The adapter cable is the GENUINE BAOFENG, i.e any discussion on the nature of the usb-serial converter has no meaning.

This adapter and a pair of UV5R+PLUS are correctely managed with... CHIRP on WineDoze, so the problem is located within CHIRP on LINUX.

For module:

[root@adramalec ~]# lsmod | grep ch
ch341 20480 0

The module is loaded.

Result of dmesg when connecting:

954.168865] usb 1-1: new full-speed USB device number 8 using xhci_hcd
[ 954.297112] usb 1-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64
[ 954.297125] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 954.297132] usb 1-1: Product: USB Serial
[ 954.301928] ch341 1-1:1.0: ch341-uart converter detected
[ 954.303535] usb 1-1: ch341-uart converter now attached to ttyUSB0

So I do confirm: CHRIP on Linux IS BROKEN or so oddly coded that it needs a specific distro to work and don't on standard (RH/Centos/Fedora) distro.

This IS a bug.


Updated by Bernhard Hailer about 1 month ago

Hello, no need to get excited here. We're trying to help after all. Chirp isn't written by a company with a well-staffed tech support department, it's all volunteers - so bear with us, ok? A belligerant tone will not help much, it might simply shut us off.

Please keep in mind that Chirp is built to satisfy three major operating systems in countless flavors. It actually works very well. Thing is, it does rely on the drivers each operating system provides in some or other good shape. It doesn't matter if it works in Windows: if it doesn't in Linux, then there the driver might not be working correctly. If it just doesn't work in Fedora, then Fedora may not have added a good driver for it yet (honestly, I don't know). Linux is generally pretty good with USB to Serial drivers; however there are some chips around which may be not so easy to deal with. The fact that a cable is "genuine Baofeng" doesn't mean much at all - they still use the cheapest chips they get (otherwise their radios and cables would cost much more than they actually do), and that chip might not be fully supported.

I found these tickets, which possibly may have information which could be potentially helpful: #2923, #4061, #7563. Some suggest an issue with a specific kernel version (that was a while ago, though). The last one is going pretty deep, but is stuck at some point. It seems to leave open where the problem is, but suggests a path to proceed on. Perhaps you could chime in there and help to trace where this behavior comes from.

Updated by Jim Unroe about 1 month ago

Run CHIRP as root and report back what happens.


Also available in: Atom PDF