Echolink Wine Fedora Serial Ports - Fedora Support Forums and Community
Results 1 to 1 of 1
  1. #1
    Join Date
    Jun 2005
    0 Post(s)
    0 Thread(s)

    Talking Echolink Wine Fedora Serial Ports

    Echolink On Fedora Core

    Running Echolink under Fedora Core 8 is a joy. After messing with sound card issues on our repeater for 3 years Fedora came to the rescue. Blazing the path was not easy, but once there looking back it was simple.

    1. Install Wine
    2. Download the Echolink install program and run it. Wine will install Echolink and place a link on the desktop to start the program.
    3. Start Echolink and RUN THE WIZARD THAT POPS UP.

    At this point, most of Echolink will actually be working with one exception. The "Serial Ports".

    Although the documentation from tells you how to set up the serial ports they leave out the information that you need to make it work. Why I do not know, but it seems to be typical of Linux documentation. Here is what you need to do and why:

    1. You will make a symbolic link that points to the hardware DEVICES folder in Fedora called /DEV
    2. You will edit win.ini to include a serial ports section [I think it will work without this step, but it
    is a good thing to do]
    3. You will fix permissions. Fedora defaults to permissions that are somewhat unusable out of the
    box and apparently this is not so for many other distributions, hence the dearth of information
    on getting Echolink to run. On some disti's it works out of the box.

    Setting up the symbolic links (Step 1) - well documented at

    in your home folder, after running Wine the first time, you will find a folder that is hidden, and called .wine - that's dot wine in case you can't see it. In that folder you will find a folder called dosdevices.

    cd .wine

    In dosdevices you will see some links to the virtual drives that wine sets up the first time it runs.

    cd dosdevices

    make a link in this folder to the device you want to be COM1 or COM2. This is simply done this way:

    ln -s /dev/ttyS0 com1

    This means, "make a symbolic link to the serial port on my motherboard" and call it com1.

    If you have two serial ports on your motherboard they will usually be ttyS0 and ttyS1 and you can see their logical references in /dev.

    if you execute:

    ls /dev/ttyS*

    You will see several links, some of which may not actually be there, but they enumerate from 0, so make com1 ttyS0 and com2 ttyS1 if you want to stay sane.

    if you are using a USB Serial Port, they enumerate from 0 as well, and are /dev/ttyUSB0 etc

    after you make your logical links in ~/.wine/dosdevices you can type the ll command (L L but lower case) and you will see the links and where they point. Check the permissions on them by doing:

    ls -l

    You should then see the rwx permissions which are probably rwxrwxrwx . Learn about permissions if you do not know about them.


    If you got this far you deserve the payoff. In your terminal window change to the root user:

    su -

    and then do

    cd /

    to get to the root of the drive. now run:

    ls -l

    you will notice that /dev has permissions rwxr-xr-x

    This is a problem for wine! You need to change these permissions to something that will let wine write to the serial port. In my mind you don't execute hardware, but you read or write to it, so I consider these permissions a design problem.

    Obviously you can fix them this way to make them writeable by everyone:

    chmod 777 /dev

    (remember you must be root to do this). The catch is that every time you reboot Fedora will change the permissions back. Also you may want to consider 775 for security reasons and making the group of /dev be uucp. (It defaults to root:root).

    This can be done this way if you want to (but read to the end first):

    chown root:uucp /dev

    The reason for making the group uucp is because uucp is the default group of the serial ports, so you can write to the directory with group rights (after you make your userid a group member) and after you give the group serial port write capability (which is not the default). IF YOU DO chmod 777 /dev it will work just fine and is probably more secure than you car.

    Once inside /dev you will notice the permissions and owner for the serial ports are not correct for general usage:

    ls -l ttyS* will show you the owner of the serial port is root:uucp. Unless you are operating as root, which has write privileges by default you will have a problem. If you give your userid uucp group privileges you still have a problem because the default group privs for the serial port do not include write capability. Once again, anything you change will go back on reboot.

    I did chmod 775 /dev/ttyS0 and joined the uucp group, but ultimately wound up just setting things up like this for a quick and dirty solution:

    chmod 777 /dev
    chmod 777 /dev/ttyS0
    chmod 777 /dev/ttyUSB0


    The other solution is:

    Make your userid a member of the uucp group.
    chmod 775 /dev
    chmod 775 /dev/ttyS0
    chmod 775 /dev/ttyUSB0
    chown root:uucp /dev

    Either one will make Echolink work. The first one because it gives everyone access to /dev and to the serial ports ttyS0 and ttyUSB0.

    The second one works because you join the uucp group (which is the default for ttyS0 and ttyUSB0) and you give the group write privileges to /dev, ttyS0, and ttyUSB0.

    OK, now you need to make sure the /dev and ttyS0 and/or ttyUSB0 privs are updated with each reboot.

    You can do this by editing /etc/rc.d/rc.local and putting the sequence of commands you prefer into the file. Now Echolink will run like a Linux app.

    If you are wondering what the issues are with Windows and Echolink, my biggest one involved security updates that kill my sound card(s) [I tried several with similar results]. If Windows rebooted without a power down the sound cards would frequently die and nothing brings them back (including the on board sound car) except a real power down, which is difficult from a repeater site. I discussed the problem with Microsoft and HP, but got the typical reaction.

    Of course running remote desktop can cause similar problems.

    Rather than hike the mountain I shut Echolink down.

    Now Echolink is back up, Windows is gone, and everything works just fine - from my warm shack, even with updates!

    Len Umina
    Last edited by wt6g; 22nd July 2008 at 02:51 AM. Reason: clarification of text

Similar Threads

  1. echolink ports
    By kc2dws in forum Servers & Networking
    Replies: 2
    Last Post: 30th April 2011, 04:01 AM
  2. Serial Ports
    By jamillikan in forum Hardware
    Replies: 13
    Last Post: 2nd February 2008, 09:13 AM
  3. Serial Ports Under Fedora Core 5
    By josephcarri in forum Using Fedora
    Replies: 10
    Last Post: 17th January 2007, 03:32 AM
  4. Serial Ports Issue
    By windblows in forum Hardware
    Replies: 3
    Last Post: 19th December 2006, 08:33 AM
  5. Replies: 0
    Last Post: 11th October 2006, 05:00 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts