When connecting with a uucico to in.uucpd via stunnel, the login / password dialog times out. Straceing in.uucpd shows [pid 24287] write(2, "Password: "..., 10) = 10 [pid 24287] read(0, <unfinished ...> [pid 24287] <... read resumed> "x"..., 1) = 1 [pid 24287] read(0, "x"..., 1) = 1 [pid 24287] read(0, "x"..., 1) = 1 [pid 24287] read(0, "x"..., 1) = 1 [pid 24287] read(0, "x"..., 1) = 1 [pid 24287] read(0, "x"..., 1) = 1 [pid 24287] read(0, "x"..., 1) = 1 [pid 24287] read(0, "x"..., 1) = 1 [pid 24287] read(0, "x"..., 1) = 1 [pid 24287] read(0, "\r"..., 1) = 1 [pid 24287] read(0, 0xbfc2b006, 1) = ? ERESTARTSYS (To be restarted) [pid 24287] --- SIGALRM (Alarm clock) @ 0 (0) --- The password prompt is sent by libpam_misc's conv function. Earlier versions (etch) just slurped in the whole password string and worked as expected. Lenny's misc_conv() function of libpam reads one charachter up to a '\n'. This '\n' is never sent by uucico...
A workaround for clients may be to use chat ogin: \L word: \P\r\n\c or chat ogin: \L word: \P\n\c as chat script instead of chat ogin: \L word: \P Hanno
Hi, After many years of working with V2 and HDB, I want to use Taylor uucp on 2 local debian systems via tcp. I could not get it working and spent days on it because I assumed it was a problem in the (for me unfamiliar) Taylor configuration files. I checked amd rechecked and then thought perhaps it was the old linux releases running on the 2 machines that were causing the problem? So I did the following: I created 2 new virtual box virtual machines on a windows laptop. Both minimal installation debian 13.4 (no graphics). I then installed uucp on both and followed the documentation to the letter but had the same problems as before. There is a timeout after a login attempt. Adding the \r\c or \c workarounds suggested by Hanno did not work for me, but changed the Debug info and I now get a zget_uucp_cmd: Got " Login incorrect ... line in Debug. Has this bug been addressed? For as far as I can see it was reported in 2009 (running version 19) but years later it seems it is not fixed. I am not running in.uucpd (as originally reported) but uucico. Some help would be appreciated. Thanks, Albert
Hi, After spending another week on this problem, I have an easy workaround that fixes the issue. In the past I used uucp for dial-up, dial-in and direct rs-232 connections, but never via networks. Being unfamiliar with the different programs available and involved to setup the "dial-in" side (e.g. inetd, systemd, in.uucpd, tcpd. etc.), as possibly other old uucp users are as well, I took quite a bit of time to find a solution. It turns out to be quite simple. Enclosed in the uucp package is a file to start the uucpd listening daemon. The file is debian/uucp/lib/systemd/system/uucp@.service. After installation the file can be found at /usr/lib/systemd/system/uucp@.service. The file does not exist on a clean debian install before the uucp package is installed. The file contents is: [Unit] Description=UUCP server Wants=network.target Documentation=http://airs.com/ian/uucp.html [Service] User=uucp ExecStart=-/usr/sbin/in.uucpd StandardInput=socket I changed the ExecStart line, replacing "in.uucpd" by "uucico -l" as shown below, and now have a working system. ExecStart=-/usr/sbin/uucico -l This is a workaround, and not a solution. It will probably have security issues, but then again if you are using uucp unencrypted (like I am in a home network) you are (or should be) well aware of those issues anyway. I hope that this may help others running into the same or similar issues. PS To find out what was wrong, I created multiple virtual Debian 13.4 and FreeBSD15 machines. The problem does not occur in FreeBSD, where uucp works fine over tcp straight after installation. The problem seems to be debian related.