NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/wizards/3835

Internet Message Format | 1992-09-08 | 26.3 KB

Path: sparky!uunet!haven.umd.edu!mimsy!afterlife!adm!news
From: [e-mail] (SMTP MAILER)
Newsgroups: comp.unix.wizards
Subject: Mail Delivery Problem
Message-ID: <[e-mail]>
Date: 7 Sep 92 21:31:02 GMT
Sender: [e-mail]
Lines: 705


 ----Reason for mail failure follows----
Sending mail to recipient(s) woodfordm :
  Couldn't make final delivery.

 ----Transcript of message follows----
Received: from gw1.hanscom.af.mil by vd1.hanscom.af.mil with SMTP ;
          Mon,  7 Sep 92 14:18:22 EST
Date: 6 Sep 92 16:22:00 EST
From: [e-mail]
Subject: UNIX-WIZARDS Digest  V16#001
To: "woodfordm" <[e-mail]>

Return-Path: <[e-mail]>
Received: from SEM.BRL.MIL by gw1.hanscom.af.mil with SMTP ;
          Sun,  6 Sep 92 16:22:19 EST
Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa22412; 6 Sep 92 15:30 EDT
Received: from sem.brl.mil by SEM.BRL.MIL id aa22353; 6 Sep 92 15:15 EDT
Date:       Sun, 06 Sep 92 15:15:17 EST
From:       The Moderator (Mike Muuss) <[e-mail]>
To:         [e-mail]
Reply-To:   [e-mail]
Subject:    UNIX-WIZARDS Digest  V16#001
Message-ID:  <[e-mail]>

UNIX-WIZARDS Digest          Sun, 06 Sep 1992              V16#001

Today's Topics:
                ASYNCHRONOUS FILE PRESENCE NOTIFICATION
            Re: How do I remove a directory with no parent?
           Re: Implementation of Sys V. based message queues
                           Re: Disk bad block
                  Re: STREAMS M_ERROR Message problem
                      Question on COFF file format
                    Re: Question on COFF file format
                        random passwd generator
                      Re: random passwd generator
                            Re: Passing FIDs
                          Superblock question
                             UUCP-question

-----------------------------------------------------------------

From: Kunal Singh <[e-mail]>
Subject: ASYNCHRONOUS FILE PRESENCE NOTIFICATION
Keywords: UNIX FILE
Date: 1 Sep 92 14:26:47 GMT
Sender: Kunal Singh <ksingh@passion>
Nntp-Posting-Host: passion
To:       [e-mail]

I'm trying to write a program which will check a certain directory for incoming files.  I want this program to be interrupt-driven such that as soon as a file is put into this directory, my program is signaled and can process the file.

I realize that my program can wake up at fixed intervals and check the directory itself for new files.  But I'm hoping for a more elegant solution.

Is there any way for my program to have the UNIX operating system notify me of the creation of a file in my subdirectory ?

Any help would be greatly appreciated.  Thanks.

Kunal Singh

-----------------------------

From: "Patrick D. Buick" <buick@belay>
Subject: Re: How do I remove a directory with no parent?
Date: 3 Sep 92 01:25:07 GMT
To:       [e-mail]

In article <[e-mail]> [e-mail] (William A Jones) writes:
>I just recently installed smail v3.1.25 on my system (i486 running linux 0.97)
>and during the installation process, the directory /usr/local/lib/smail/methods
>was created.  However, there is absolutely nothing in the directory -- no
>., no .., no nothing.  fsck kindly points this out but hasn't done anything
>to fix it.  rmdir, rm -rf, rm -d all don't work.  I tried removing the entire
>directory tree doing an "rm -rf /usr/local/lib/smail" but that doesn't work.
>
>Other than backing up everything else but this file and running mkfs to make
>a clean disk is there any other way to fix this?
>
>Thanks,
>
>Bill

Of course, my question is: If there is no parent, how did you determine
there was nothing in it?  Don't you have to traverse the inodes containing
directory entries above it to get there?  Hmm... baffles me...  it wouldn't
be a link, would it?  (Does linux support these kinds of links?)
Patrick
--
==========================================================
Patrick D. Buick EMT, EET  | Internet: [e-mail]
Belay Enterprises Inc.     | Internet: [e-mail]
Calgary, Alberta, Canada   | UUCP:...!calgary!pixel!belay!buick

-----------------------------

From: "Antony A. Courtney" <[e-mail]>
Subject: Re: Implementation of Sys V. based message queues
Date: 3 Sep 92 22:10:46 GMT
Sender: "NN required at ashe.cs.tcd.ie" <[e-mail]>
Nntp-Posting-Host: unix1.tcd.ie
To:       [e-mail]

In <[e-mail]> [e-mail] (ASU Student) writes:
>Hello,
>  Does anyone have any insight in to the implementation of Sys V
>based message queues (on SunOS)?

All the system V IPC mechanisms are completely inconsistent with the rest of
the i/o facilities provided by Unix.  The "key"s they use are their own name
space, they are persistent after process death, they don't use descriptors so
you can't use normal read()/write()/select() semantics, and they add about a
dozen system calls to the kernel just for handling them in their own arcane way.

>The reason I ask is because I would
>like to be able to use select(2) to multiplex descriptor based objects
>(sockets) as well as the message queue.

I could be mistaken, but my experience with using Sys V IPC with select()
is:
    'aint no way...

I had the wonderful experience when integrating the DCE threads package with
a control process we had developed in a multi-process environment.  The
system ran beautifully first time, creating all the threads, sharing all the
data properly, simulating blocking i/o, etc.  And then the process had to
read some data from a Sys. V message queue and the process STOPPED STONE
DEAD.

Loads of fun. :-)

(don't even get me started on Sys V semaphores....and to think Unix was once
appreciated for "simplicity" and "clarity".  *sigh*....)

    -antony

--
********************************************************************************
* Antony A. Courtney                              Email: [e-mail] *
* Computer Science Department                            [e-mail] *
* Trinity College, Dublin, Ireland                Phone: 01+353+1-607389       *

-----------------------------

From: "Alan Rollow - Alan's Home for Wayward Tumbleweeds." <[e-mail]>
Subject: Re: Disk bad block
Date: 3 Sep 92 23:06:16 GMT
Sender: "Alan Rollow - Alan's Home for Wayward Tumbleweeds." <alan@nabeth>
To:       [e-mail]


In article <[e-mail]>, [e-mail] (P S Narayan) writes:
>
>Hello,
>Could any one tell me how does the file manager in the Unix File System
>detect a bad block and keep a track of it so that it is never allocated
>to any file. What is badness in a block ?
>I imagine the bad block list  is kept in the zeroth block of the  filesystem.
>
As Dave Olson mentioned, it depends.

Some possible answers:

1.  Some UNIX systems will expect perfect media and not cope with
    bad blocks at all.  If you happen to have an underlying I/O
    that does cope well with them this might be alright.  Unless
    the subsystem expect help from the operating system.

2.  Others acknowledge that bad blocks occur, but know they have
    I/O subsystems that will take care of them.  They are willing
    to help the I/O subsystem perform this task.

3.  Other make no assumption that the subsystem is going to do
    anything interest and take care of themselves.  The methods
    probably vary from a "bad block file" that has the bad
    blocks allocated to it, to systems that hide real disk
    under a layer that maps out the bad blocks.  All you ever
    see is the perfect surface presented by this layer.

On the nature "badness" in a block.

To various degrees the disks you're using have error detection
(and correction) codes stored with the data on the disk.  When
it reads a block it compares runs the data through whatever
firmware or hardware that calculates the error detection code
to see if they match.  If not the block is consider bad.

If the disk or controller supports error correction it will
try to fix the error.  Way down in the operating system it may
present this state as "Data corrected, but it was X badly broken".
The host may then be responsible for telling the controller what
do with the block; replace it and write the still good data back
to the new block.  The controller may decide to do this itself.
and will just tell the host "here's a good copy.  I fixed it."

Sometimes it won't be able to correct the data and still reports
a bad block.  The controller may still go off and replace the bad
block, writting the bad data to a now good block.  Unfortunately
it may not have any way to differentiate between a bad block
and a good block with known corrupt data.  What the host does
in these cases depends on how paranoid they are about data
reliability.

>Regards
>Narayan
>[e-mail]
>Texas A&M University
>
>
--
Alan Rollow                [e-mail]

-----------------------------

From: Graham Wheeler <[e-mail]>
Subject: Re: STREAMS M_ERROR Message problem
Date: 4 Sep 92 09:51:31 GMT
To:       [e-mail]

[e-mail] (Joel Peter Anderson) writes:

>succeed.  If a byte is set to 0, the error state is cleared for the
>corresponding side of theStream.  The values NOERROR and 0 are not
>valid for the one-byte form of the M_ERROR message."

Have you tried using 0 instead on NOERROR? Maybe an error condition has
occurred anyway, and using NOERROR does not change anything.

--
Graham Wheeler                     | "That which is weak conquers the strong,
Software Systems Engineer/Student  | that which is soft conquers the hard."
Aztec Information Management/UCT   |         Lao Tzu - Tao Te Ching Ch. 78
[e-mail] / [e-mail]

-----------------------------

From: Joel Peter Anderson <[e-mail]>
Subject: Re: STREAMS M_ERROR Message problem
Date: 4 Sep 92 17:38:28 GMT
NNTP-Posting-Host: slc5.ins.cwru.edu
To:       [e-mail]


In a previous article, [e-mail] (Graham Wheeler) says:

>[e-mail] (Joel Peter Anderson) writes:
>
>>succeed.  If a byte is set to 0, the error state is cleared for the
>>corresponding side of theStream.  The values NOERROR and 0 are not
>>valid for the one-byte form of the M_ERROR message."
>
>Have you tried using 0 instead on NOERROR? Maybe an error condition has
>occurred anyway, and using NOERROR does not change anything.
>

Good idea, but, sorry, no dice.  After we experienced this problem I wrote
a dumb little device driver that allows you to send any two bytes up the
stream as an M_ERROR message.  I have tried all permutations and 1)can get
errors registered on either or both sides 2) get errors on the read side
only.  As soon as I send any M_ERROR skyward all reads fail.  If NOERROR or
zero is sent, errno reads as EAGAIN.(?) Otherwise, if I send an error
value, that value is put in errno.

Any other thoughts?


--
 -------------------------------------------------------------------------
  [e-mail]           |Freenet: [e-mail]
    Joel Peter Anderson          |PNET: [e-mail]
    Apertus Technologies         |GEnie:J.ANDERSON71

-----------------------------

From: David B Stewart <[e-mail]>
Subject: Question on COFF file format
Date: 4 Sep 92 16:16:30 GMT
Sender: Usenet News System <[e-mail]>
Nntp-Posting-Host: ius4.ius.cs.cmu.edu
Cc: [e-mail]
To:       [e-mail]


I am writing a program which must read in an i860 COFF file.

Is there any way of knowing the size of the string table before
the table is read in?

The header information gives the sizes of everything else, but not
for the string table.  However, to be able to allocate memory to
store the string table, I have to know its size, but that doesn't
seem to be available.

If the size isn't available, is there a customary way of reading
the string table, as used by loaders which must read the COFF file?

Please respond via email.

Thanks a whole bunch!

~dave

 -------------------------------------------------------------------------------
David B. Stewart  - email: <[e-mail]>            The Robotics Institute
snail mail:       - ECE Dept., Carnegie Mellon University, Pittsburgh, PA 15213
Current Projects: - Chimera 3.0 Real-Time Operating System
          - Reconfigurable Sensor-Based Control Systems

-----------------------------

From: Terry Lambert <[e-mail]>
Subject: Re: Question on COFF file format
Date: 4 Sep 92 21:35:46 GMT
Sender: Terry Lambert <terry@thisbe>
Nntp-Posting-Host: thisbe.eng.sandy.novell.com
To:       [e-mail]

In article <[e-mail]>, [e-mail] (David B Stewart) writes:
|>
|> The header information gives the sizes of everything else, but not
                                             ^^^^^^^^^^^^^^^
|> for the string table.  However, to be able to allocate memory to
|> store the string table, I have to know its size, but that doesn't
|> seem to be available.

String table size = size of file from fstat() - total of everything else


                    Terry Lambert
                    [e-mail]
                    [e-mail]

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.

-----------------------------

From: Ken Brown <[e-mail]>
Subject: random passwd generator
Date: 4 Sep 92 17:01:48 GMT
Sender: USENET News System <[e-mail]>
To:       [e-mail]

I'm looking for a program which will generate 'n' number of passwords.  This
would be used by a faculty member who wishes to have a series of
pre-determined passwords to hand to students.

Thanks in advance...
--
====================================================================
Ken Brown                                       voice: [phone]
Trent University Computer Services                fax: [phone]
Peterborough, Ontario, Canada K9J 7B      internet: [e-mail]

-----------------------------

From: Eiji Hirai <[e-mail]>
Subject: Re: random passwd generator
Date: 4 Sep 92 18:52:00 GMT
Sender: USENET News System <[e-mail]>
Nntp-Posting-Host: gingko
To:       [e-mail]

[e-mail] (Ken Brown) writes:
> I'm looking for a program which will generate 'n' number of passwords.

How about this minimalist program below.  You give a number as an argument
and it'll give you that many passwords, both in the original form and
encrypted form.  It tries to make the passwords be a pronounce-able word.

Hack and enjoy.

--
Eiji Hirai <[e-mail]>    :     :    :   :  : :: ::: :::: :::::
Unix Hacker for Swarthmore College      :     :    :   :  : :: ::: :::: :::::
Information Services, Swarthmore, PA, USA.      Copyright 1992 by Eiji Hirai.
I don't speak for Swarthmore College.                    All Rights Reserved.

/* generate.c - generates encrypted strings for random passwords.  -eiji */

#include <stdio.h>
#include <time.h>

extern char    *crypt();

#define SALT    ".."
#define LETTERS    26    /* number of letters in the English alphabet */

void    main(int argc, char *argv[])
{
    int    howmany, numConsonant, numVowel, count, count2;
    char    password[16], consonant[LETTERS], vowel[LETTERS];

    if (argc != 2) {
        fprintf (stderr, "usage: %s howmany\n", argv[0]);
        exit (1);
    }

    howmany = atoi (argv[1]);
    srandom((int)(time((time_t *)0)));

    strcpy (consonant, "bcdfghjklmnpqrstvwxyz");
    strcpy (vowel, "aeiou");
    numConsonant = strlen(consonant);
    numVowel = strlen(vowel);

    for (count = 0; count < howmany; count++)
    {
        strcpy (password, "");
        for (count2 = 0; count2 < 8; count2 += 2)
            password[count2] = consonant[random()%numConsonant];
        for (count2 = 1; count2 < 8; count2 += 2)
            password[count2] = vowel[random()%numVowel];
        for (count2 = 0; count2 < 8; count2 ++)
            if (!(random() % 3))
                password[count2] = password[count2] - 'a' + 'A';
        printf ("%s\t%s\n", password, crypt(password, SALT));
    }
}

-----------------------------

From: Ron Feigen <[e-mail]>
Subject: Re: Passing FIDs
Date: 4 Sep 92 18:37:31 GMT
Sender: [e-mail]
Nntp-Posting-Host: panther3.panther.mot.com
To:       [e-mail]


Hello,

  Does anyone know of bugs/problems with SunOS 4.1.2 passing of file
descriptors.  I faithfully RTFM (as well as R. Stevens UNIX Net. Prog)
to learn about how to do this.  Here's the desciption:
  I have 1 process open a socket, start a non-blocking connect().  Then
at an arbitrary time later pass the access rights to another process.
The other process would request a socket (through a little ack/nack deal)
and then receive the access rights.

    Using sendmsg() -> recvmsg()  with msghdr like the following:

        struct iovec iov;
        iov.iov_base = (char *)0; iov.iov_len = 0;
    msg.msg_name = (caddr_t)0; msg.msg_namelen = 0; msg.msg_iov = iov;
        msg.msg_iovlen = 0;
        msg.msg_accrights = (caddr_t)&fd; /* where this is the created socket fd */
        msg.msg_accrightslen = sizeof(int);

The problems start when I send the desciptor.  For some reason the access
rights fields in the msghdr struct get zeroed out, and garbage ends up
getting sent to the receiver...hence a garbled access rights...but NO error
reported by either sendmsg() or recvmsg() (no return of -1 and errno set)

Anybody had problems like this?

P.S. The code does seem to work occasionally, or when using dbx.

Any help would be greatly appreciated

--

>
Ron Feigen
[e-mail]

-----------------------------

From: P S Narayan <[e-mail]>
Subject: Superblock question
Date: 4 Sep 92 21:05:11 GMT
Sender: Read News <[e-mail]>
To:       [e-mail]

The literature on file systems (4.2 BSD) says that the cylinder block in
every cylinder group contains a bit map of the available data blocks in that
cylinder group. Every cylinder group also contains superblock information
for reliability.The superblock already contains the list of all free data
blocks for that file system. Is it not redundant to have free data blocks bit
map in the cylinder blocks when it is already there in the superblocks ?
Kindly correct me.

Thanks
Narayan
[e-mail]

-----------------------------

From: Mikka Putaala <putaala@zombie>
Subject: UUCP-question
Date: 4 Sep 92 21:54:52 GMT
Sender: [e-mail]
To:       [e-mail]


This newsgroup seemed to be the most appropriate for this posting.

I have installed Taylor-uucp-1.03 succesfully.
I am running uucico with flags -r1 -smuikku -x all. The transformation
seemes to run correctly until it crashes while waiting the third packet.
The remote system I am trying to connect uses HDB UUCP and must be
configured correctly because it transmits data (mail and news) every
night with several other systems.

Here is the transcript of the session:

 ...We have logged in...
uucico muikku - (1992-09-04 23:07:56.09 13535) DEBUG: zget_uucp_cmd:
Got " nuucp\r\n\020Shere=muikku\000"
uucico muikku - (1992-09-04 23:07:59.01 13535) DEBUG: fport_write:
Writing 13 "\020Scecilia -N\000"
uucico muikku - (1992-09-04 23:07:59.01 13535) DEBUG: zget_uucp_cmd:
Got "\020ROK\000"
uucico muikku - (1992-09-04 23:08:00.47 13535) DEBUG: zget_uucp_cmd:
Got "\020Pg\000"
uucico muikku - (1992-09-04 23:08:00.92 13535) DEBUG: fport_write:
Writing 4 "\020Ug\000"
uucico muikku - (1992-09-04 23:08:00.92 13535) DEBUG: fport_set:
Changing setting to 0
uucico muikku - (1992-09-04 23:08:00.95 13535) DEBUG: fgsend_control:
Sending control INITA 7
uucico muikku - (1992-09-04 23:08:00.95 13535) DEBUG: fport_io:
Writing 6 "\020\011k\252?\367"
uucico muikku - (1992-09-04 23:08:00.97 13535) DEBUG: fport_io: Wrote
6 of 6, read 0 of 16251
uucico muikku - (1992-09-04 23:08:00.97 13535) DEBUG:
fgwait_for_packet: Need 6 bytes
uucico muikku - (1992-09-04 23:08:01.49 13535) DEBUG: fport_read: Read
6 "\020\011o\252;\367"
uucico muikku - (1992-09-04 23:08:01.49 13535) DEBUG: fgprocess_data:
Got control INITA 3
uucico muikku - (1992-09-04 23:08:01.49 13535) DEBUG: fgsend_control:

 ...OK. We got INIT A...

Sending control INITB 1
uucico muikku - (1992-09-04 23:08:01.49 13535) DEBUG: fport_io:
Writing 6 "\020\011y\2521\353"
uucico muikku - (1992-09-04 23:08:01.49 13535) DEBUG: fport_io: Wrote
6 of 6, read 0 of 16245
uucico muikku - (1992-09-04 23:08:01.50 13535) DEBUG:
fgwait_for_packet: Need 6 bytes
uucico muikku - (1992-09-04 23:08:01.55 13535) DEBUG: fport_read: Read
6 "\020\011y\2521\353"
uucico muikku - (1992-09-04 23:08:01.55 13535) DEBUG: fgprocess_data:
Got control INITB 1

 ...Here is INIT B...

uucico muikku - (1992-09-04 23:08:01.55 13535) DEBUG: fgsend_control:
Sending control INITC 7

 ...And finally INIT C...

uucico muikku - (1992-09-04 23:08:01.58 13535) DEBUG: fport_io:
Writing 6 "\020\011{\252/\367"
uucico muikku - (1992-09-04 23:08:01.58 13535) DEBUG: fport_io: Wrote
6 of 6, read 0 of 16239
uucico muikku - (1992-09-04 23:08:01.58 13535) DEBUG:
fgwait_for_packet: Need 6 bytes
uucico muikku - (1992-09-04 23:08:02.05 13535) DEBUG: fport_read: Read
6 "\020\011\177\252+\367"
uucico muikku - (1992-09-04 23:08:02.05 13535) DEBUG: fgprocess_data:
Got control INITC 3
uucico muikku - (1992-09-04 23:08:02.05 13535) DEBUG: fgstart:
Protocol started; packsize 64, winsize 3
uucico muikku - (1992-09-04 23:08:02.09 13535) Handshake successful

 ...OK. Handshake is successful...

uucico muikku - (1992-09-04 23:08:02.18 13535) DEBUG:
fsysdep_get_work_init: Found C.N0002
uucico muikku root (1992-09-04 23:08:02.25 13535) Sending /usr/src/gnu/taylor-uucp/uucp-1.03/uux.1
uucico muikku root (1992-09-04 23:08:02.25 13535) DEBUG: fgsendcmd:
Sending command "S /usr/src/gnu/taylor-uucp/uucp-1.03/uux.1 ~/uux.1
root -Cd D.0001 0444 "
uucico muikku root (1992-09-04 23:08:02.26 13535) DEBUG: fgsenddata:
Sending packet 1 (64 bytes)
uucico muikku root (1992-09-04 23:08:02.26 13535) DEBUG: fport_io:
Writing 70 "\020\002\032\311\210YS
/usr/src/gnu/taylor-uucp/uucp-1.03/uux.1 ~/uux.1 root -Cd D.00"
uucico muikku root (1992-09-04 23:08:02.26 13535) DEBUG: fport_io:
Wrote 70 of 70, read 0 of 16233
uucico muikku root (1992-09-04 23:08:02.26 13535) DEBUG: fgsenddata:
Sending packet 2 (64 bytes)
uucico muikku root (1992-09-04 23:08:02.27 13535) DEBUG: fport_io:
Writing 70 "\020\002\023\242\220#01 0444 \000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\


00\000\000"
uucico muikku root (1992-09-04 23:08:02.27 13535) DEBUG: fport_io:
Wrote 70 of 70, read 0 of 16233
uucico muikku root (1992-09-04 23:08:02.27 13535) DEBUG: zgetcmd:
Waiting for packet
uucico muikku root (1992-09-04 23:08:02.27 13535) DEBUG:
fgwait_for_packet: Need 6 bytes
uucico muikku root (1992-09-04 23:08:12.00 13535) DEBUG: fport_read:
Read 0 ""
uucico muikku root (1992-09-04 23:08:12.00 13535) DEBUG:
fgsend_control: Sending control RJ 0
uucico muikku root (1992-09-04 23:08:12.01 13535) DEBUG: fport_io:
Writing 6 "\020\011\232\252\020)"
uucico muikku root (1992-09-04 23:08:12.01 13535) DEBUG: fport_io:
Wrote 6 of 6, read 0 of 16233
uucico muikku root (1992-09-04 23:08:12.01 13535) DEBUG:
fgwait_for_packet: Need 6 bytes
uucico muikku root (1992-09-04 23:08:22.00 13535) DEBUG: fport_read:
Read 0 ""

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! Here seems to be the 'bottleneck'.          !!
!! we need something but don't get it? What do !!
!! we exactly need? This is the point that     !!
!! bothers me most. Could anyone help?         !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

uucico muikku root (1992-09-04 23:08:22.00 13535) DEBUG:
fgsend_control: Sending control RJ 0
uucico muikku root (1992-09-04 23:08:22.02 13535) DEBUG: fport_io:
Writing 6 "\020\011\232\252\020)"
uucico muikku root (1992-09-04 23:08:22.02 13535) DEBUG: fport_io:
Wrote 6 of 6, read 0 of 16233
uucico muikku root (1992-09-04 23:08:22.02 13535) DEBUG:
fgwait_for_packet: Need 6 bytes
uucico muikku root (1992-09-04 23:08:32.00 13535) DEBUG: fport_read:
Read 0 ""
uucico muikku root (1992-09-04 23:08:32.00 13535) DEBUG:
fgsend_control: Sending control RJ 0

 ...RJ 0 is obviously a request to resend the packet (am I right?)...
 ...After this uucico try's to resend the packet ten times without...
 ...success and finally times out and executes CLOSE              ...

uucico muikku root (1992-09-04 23:09:12.01 13535) ERROR: Timed out
waiting for packet
uucico muikku - (1992-09-04 23:09:12.02 13535) DEBUG: fgsend_control:
Sending control CLOSE 0
uucico muikku - (1992-09-04 23:09:12.02 13535) DEBUG: fport_io:
Writing 6 "\020\011\242\252\010\011"
uucico muikku - (1992-09-04 23:09:12.02 13535) DEBUG: fport_io: Wrote
6 of 6, read 0 of 16233
uucico muikku - (1992-09-04 23:09:12.02 13535) DEBUG: fgsend_control:
Sending control CLOSE 0
uucico muikku - (1992-09-04 23:09:12.02 13535) DEBUG: fport_io:
Writing 6 "\020\011\242\252\010\011"
uucico muikku - (1992-09-04 23:09:12.04 13535) DEBUG: fport_io: Wrote
6 of 6, read 0 of 16233
uucico muikku - (1992-09-04 23:09:12.04 13535) Protocol 'g' packets:
sent 2, resent 0, received 0

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!Here it is said: We sent 2 packets but why is it just 2 !!
!!everytime I try it? Are those two the control packets   !!
!!or what? The rest of the transcript was just closing the!!
!!connection, so I deleted it.                            !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

The sys file is here:

#
# The following information is for muikku
#
system muikku
# The login name and password are kept in the callout passwd file
call-login nuucp

# We can send only during night. (2200-0700)
# time Wk2200-0700,Sa2200-0700,Su2200-0700
time Any

# The phone number.
phone 419290

# Muikku is very slow
chat-timeout 120

# We are using Hayes modem
port type modem
port device /dev/tty00
port baud 2400
port carrier true
port dialer chat "" ATZ\r\d\c OK ATDT\D CONNECT
port dialer chat-fail BUSY
port dialer chat-fail NO\sCARRIER
port dialer complete \d\d+++\d\dATH\r\c
port dialer abort \d\d+++\d\dATH\r\c

# This is made to make this work with muikku
# There is no password for user 'nuucp'
chat ogin: \L

This is the story of mine. ANY help appreciated!

Thanks for listening (reading).
--
  // Miikka     [e-mail]           Tatunkuja 6 90540 Oulu
     Putaala    [e-mail]              FINLAND
                                                  Phone: [phone]

-----------------------------


End of UNIX-WIZARDS Digest
**************************