debug dialup login & why don't ISP's show engaged ?

debug dialup login & why don't ISP's show engaged ?

Post by AliBam » Mon, 26 Jan 2009 08:57:17



I've been using pppd in ignorance for too long now.

It's time to understand [not like the clowns who though
everybody else is getting 125% mortgates, so it must be OK]

My startScript is:--------
pppd  lcp-echo-interval 300 lcp-echo-failure 4  connect '
  chat -v "" ATZ OK ATX OK ATM2DT0113407501 CONNECT "" TIMEOUT 99 ' \

-----------  and I've got a similaar one to dial the ISP's , less
congested but more expensive distant town connection.

I analyse/ghost-hunt what's going on, based on statistics, eg.
depending on: time of week, month, day and the weather
[ie. if the kiddies are outside or online], I can make better than
random, choices whether to dial-in locally or to the distant town.

But some points are REALLY frustrating me:-

Q1.  Since the ISP must have signals/information showing
traffic is congested, why the hell can't they just feed-back an
engaged signal to their modem/s, and save their clients failed
log-in telco connect costs ?

Q2.  Login at 4:00 am. seems impossible, and I suspect that the
  ISP does all its CPU/disk intensive daily-backups ...etc. and
  the ISP can't bother to feedback 'engaged' to save the client
  failed connects costs.   Is this an viable explanation ?

Q3. At one stage I had a ppp-down/off    type command.
  But lately, [under Mandrake9] I can't find such a command.
  So I just power-off the modem [which I keep in noise mode
 while I'm connected, to remind me to power-off].
But, I have statistical evidence that a login is more likely
 to fail, to the same TelcoNumber/town than to the alternate.
If this is true, it means that the 'system has memory, and knows
that I was recently online'.   Eg. if it didn't log me out, when
I powered down, and still has me recorded as on-line 5 minutes
later, it would have cause to refuse a new login.
Is this a viable explanation ?

Q4. The following typical trace, seems to indicate that
PAP authentication *TRIED* but failed. This contradicts my
previous assumptions [based on ample statistics] that login-fails,
were due to congestion time-out *BEFORE* PAP authentication
got a chance to be tested. BTW, I seldom have a failure once PAP
passes., so why should PAP fail depending on the congestion-level ?
Or is "PAP authentication failed" it just a simplistic error message ?

TIA.

== Chris Glur.

 
 
 

debug dialup login & why don't ISP's show engaged ?

Post by Moe Tr » Tue, 27 Jan 2009 05:57:52


On Sat, 24 Jan 2009, in the Usenet newsgroup comp.os.linux.networking, in

Yet another posting name?

Quote:>My startScript is:--------
>pppd  lcp-echo-interval 300 lcp-echo-failure 4

lcp-echo is normally used with the link may go down without warning
or exchange of TermReq/TermAck packets.   It _may_ cause problems if
the links are busy.

Quote:>                                                connect '
>  chat -v "" ATZ OK ATX OK

You want to look at the manual for your modem. 'ATZ' generally resets
the modem to some NVRAM condition - that may or may not be desirable.
Most modems reset to "factory defaults" using the command 'AT&F0'
(mainly US Robotics and 3Com) or 'AT&F1' (most other brands). The 'ATX'
command disables a lot of result codes - are you sure you need that,
or would 'ATX3' be more useful (don't wait for dialtone)?

Quote:>                            ATM2DT0113407501 CONNECT "" TIMEOUT 99 ' \

Rather than sending an empty string ("") which may confuse the peer,
it's usually better to command '\d\c' which suppresses the unwanted
'newline' character that would be sent after the empty string.

'man chat'    The 'TIMEOUT' keyword at this location has no effect, as
it's the last thing in the chat strings, and nothing follows.  This
entire line might work better as

  chat -v "" AT&F1 OK ATX3M2DT0113407501 CONNECT \d\c ' \

Do you _really_ want the 'name' option here? Or do you really want the
'user' option.   Look at the man page for pppd, and compare the two
options, and then look at the /etc/ppp/pap-secrets file. Normally that
file looks something like

   ibuprofin  *  p42Sw0rD~

where the first field is the username, the servername (nearly always
a '*' wildcard as here) and the third field is the secret.

Quote:>Q1.  Since the ISP must have signals/information showing
>traffic is congested, why the hell can't they just feed-back an
>engaged signal to their modem/s, and save their clients failed
>log-in telco connect costs ?

You'd have to ask your ISP.

Quote:>Q2.  Login at 4:00 am. seems impossible, and I suspect that the
>  ISP does all its CPU/disk intensive daily-backups ...etc. and
>  the ISP can't bother to feedback 'engaged' to save the client
>  failed connects costs.   Is this an viable explanation ?

You'd have to ask your ISP. Unless they are rather small, that's not
a logical explanation.   Terminal servers tend not to have such tasks.

Quote:>Q3. At one stage I had a ppp-down/off    type command.
>  But lately, [under Mandrake9] I can't find such a command.

The 'ppp-on', 'ppp-on-dialer' and 'ppp-off' sample scripts as well as
'pon' and 'poff' are still part of the ppp tarball, but haven't been
part of the installation in several years.

   2772 2002-11-24 16:30 ppp-2.4.4/scripts/poff
    970 2004-04-12 04:02 ppp-2.4.4/scripts/pon
    397 1995-10-16 12:25 ppp-2.4.4/scripts/ppp-on-dialer
    967 1995-08-08 19:49 ppp-2.4.4/scripts/ppp-off
   1641 1995-10-16 11:17 ppp-2.4.4/scripts/ppp-on

Notice that the ppp-* scripts are rather ancient, and don't reflect the
modern usage of ppp as defined by windoze (no Login: prompt). If you
can't find those scripts, grab the tarball source using any search
engine.

Quote:>  So I just power-off the modem [which I keep in noise mode
> while I'm connected, to remind me to power-off].

Bad idea - as you've discovered.

Quote:>But, I have statistical evidence that a login is more likely
> to fail, to the same TelcoNumber/town than to the alternate.
>If this is true, it means that the 'system has memory, and knows
>that I was recently online'.   Eg. if it didn't log me out, when
>I powered down, and still has me recorded as on-line 5 minutes
>later, it would have cause to refuse a new login.
>Is this a viable explanation ?

Yes - apparently, the ISP isn't monitoring the hook-drop (the 'modem'
option in the 'ppp' man page), probably because there isn't really a
modem at the ISP - but instead a digital trunk needed for v.90 or v.92
(56k modem) connections.  There are several solutions. First, you
_could_ add the 'nodetach' option to pppd, and the terminal that you
use to run the startScript remains busy running pppd. Pressing the left
'Ctrl' and 'c' keys at the same time in this terminal tells pppd to
shut down cleanly.        Second, you could adopt the commands normally
found in the 'ppp-off' script

--------------------------
if [ "$1" = "" ]; then
        DEVICE=ppp0
else
        DEVICE=$1
fi
if [ -r /var/run/$DEVICE.pid ]; then
        kill -INT `cat /var/run/$DEVICE.pid`
        if [ ! "$?" = "0" ]; then
                rm -f /var/run/$DEVICE.pid
                echo "ERROR: Removed stale pid file"
                exit 1
        fi
        echo "PPP link to $DEVICE terminated."
        exit 0
fi
echo "ERROR: PPP link is not active on $DEVICE"
exit 1
--------------------------

or simply send a 'kill' (shell built-in), '/bin/kill' command with the
'-15' or 'SIGTERM' option to the pppd process-ID, or even use the
simpler '/usr/bin/killall' command ('killall -15 pppd').   These
methods allow pppd to tell the ISP that you are shutting down, and
to log you off.

Quote:>Q4. The following typical trace

Error: trace not found:  core dumped

Quote:>                                  seems to indicate that
>PAP authentication *TRIED* but failed. This contradicts my
>previous assumptions [based on ample statistics] that login-fails,
>were due to congestion time-out *BEFORE* PAP authentication
>got a chance to be tested.

Replace the "" following the CONNECT in your script with  \d\c

Quote:>                            BTW, I seldom have a failure once PAP
>passes., so why should PAP fail depending on the congestion-level ?
>Or is "PAP authentication failed" it just a simplistic error message ?

Your script includes the 'debug' option. Do you have /etc/syslog.conf
set to log 'daemon.=debug    /var/log/ppp.debug'  and see that you
are sending the "right" username and password?    See the 'syslog.conf'
man page if necessary, and restart 'sysklogd' if you alter that file.

        Old guy

 
 
 

debug dialup login & why don't ISP's show engaged ?

Post by Bruce Coo » Fri, 30 Jan 2009 21:24:05


[...]

Quote:> Q1.  Since the ISP must have signals/information showing
> traffic is congested, why the hell can't they just feed-back an
> engaged signal to their modem/s, and save their clients failed
> log-in telco connect costs ?

It depends upon how your ISP is terminating your call.  If they are using an
L2TP delivered service from a carrier, quite often the carrier doesn't
recognize that the ISP is congested  and therefore will terminate the call
and attempt to pass it off to the carrier. The carrier then has to drop the
session, or refuse it to avoid being charged for over-usage of ports.

This is becoming very common with port numbers dropping & less ISPs
maintaining the infrastructure to directly terminate calls themselves.

Quote:

> Q2.  Login at 4:00 am. seems impossible, and I suspect that the
>   ISP does all its CPU/disk intensive daily-backups ...etc. and
>   the ISP can't bother to feedback 'engaged' to save the client
>   failed connects costs.   Is this an viable explanation ?

Not really.   Calls won't be terminated on a server, it'll be on an LNS, a
router dedicated to managing PPP sessions.

Quote:> Q3. At one stage I had a ppp-down/off    type command.
>   But lately, [under Mandrake9] I can't find such a command.
>   So I just power-off the modem [which I keep in noise mode
>  while I'm connected, to remind me to power-off].
> But, I have statistical evidence that a login is more likely
>  to fail, to the same TelcoNumber/town than to the alternate.
> If this is true, it means that the 'system has memory, and knows
> that I was recently online'.   Eg. if it didn't log me out, when
> I powered down, and still has me recorded as on-line 5 minutes
> later, it would have cause to refuse a new login.
> Is this a viable explanation ?

Bad disconnects may leave a PPP session on the LNS until the LCP echo
timeout decides the connection is dead and terminates it.  You may also
have the complication of them using Session information to stop multiple
logins from the same username.  This is maintained typically on a RADIUS
server.

try killall -HUP pppd
or kill -HUP  pid_of_your_ppp_process
which will send an LCP hangup to the LNS before disconnecting, which should
clean the session up.

Quote:>> Q4. The following typical trace, seems to indicate that
> PAP authentication *TRIED* but failed. This contradicts my
> previous assumptions [based on ample statistics] that login-fails,
> were due to congestion time-out *BEFORE* PAP authentication
> got a chance to be tested. BTW, I seldom have a failure once PAP
> passes., so why should PAP fail depending on the congestion-level ?
> Or is "PAP authentication failed" it just a simplistic error message ?

The authentication is sometimes used by the carrier to decide which ISP to
hand the L2TP off to.   The session is handed off and then the ISP goes and
requests the authentication again.

It is also fairly much the first thing the ISP's LNS does when a session is
presented to it.  If it had to drop the session to control congestion, then
you would likely see this happen this way.

Once the ISP accepts the authentication then the port is counted as in-use
by the carrier.

Bruce

 
 
 

debug dialup login & why don't ISP's show engaged ?

Post by Bruce Coo » Fri, 30 Jan 2009 21:26:18



> or simply send a 'kill' (shell built-in), '/bin/kill' command with the
> '-15' or 'SIGTERM' option to the pppd process-ID, or even use the
> simpler '/usr/bin/killall' command ('killall -15 pppd'). ? These
> methods allow pppd to tell the ISP that you are shutting down, and
> to log you off.

SIGHUP (HangUP) is what you actually require - that is actually what this
signal was created for.   Term may not exit the PPP daemon properly and send
the LCP hangup to the other end.

Bruce

 
 
 

debug dialup login & why don't ISP's show engaged ?

Post by AliB.. » Sun, 12 Apr 2009 10:50:34



> On Sat, 24 Jan 2009, in the Usenet newsgroup comp.os.linux.networking, in

> Yet another posting name?

Are you a stalker or just a name-dropper ?

Quote:> >Q1.  Since the ISP must have signals/information showing
> >traffic is congested, why the hell can't they just feed-back an
> >engaged signal to their modem/s, and save their clients failed
> >log-in telco connect costs ?

> You'd have to ask your ISP.

They've just got affirmative-employees who can ask/answer
standard M$loth questions.
--snip--

Quote:> Yes - apparently, the ISP isn't monitoring the hook-drop (the 'modem'
> option in the 'ppp' man page), probably because there isn't really a
> modem at the ISP - but instead a digital trunk needed for v.90 or v.92
> (56k modem) connections.  There are several solutions. First, you
> _could_ add the 'nodetach' option to pppd, and the terminal that you
> use to run the startScript remains busy running pppd. Pressing the left
> 'Ctrl' and 'c' keys at the same time in this terminal tells pppd to
> shut down cleanly.        Second, you could adopt the commands normally
> found in the 'ppp-off' script

--  script snipped but filed for reference ---

OK, initially I'll just try:    killall pppd

--- snip --

Quote:> Your script includes the 'debug' option. Do you have /etc/syslog.conf
> set to log 'daemon.=debug    /var/log/ppp.debug'  and see that you
> are sending the "right" username and password?    See the 'syslog.conf'
> man page if necessary, and restart 'sysklogd' if you alter that file.

ID & pswd are 'computerised'. No manual error.

Thanks for info !


> Indeed.  SIGHUP tells pppd that the underlying serial link is
> _gone_, and thus any further negotiation is pointless, which
> is the exact opposite of what the previous poster said.

>                To simplify greatly:

>                  TERM == good

>                  HUP == slightly bad

>                  KILL == very bad

This doesn't help me [linux user].
man killall exists but not man 'hup/HUP ...etc.
=========================
 > If this is true, it means that the 'system has memory, and knows
 > that I was recently online'.   Eg. if it didn't log me out, when
 > I powered down, and still has me recorded as on-line 5 minutes
 > later, it would have cause to refuse a new login.
 > Is this a viable explanation ?


> Bad disconnects may leave a PPP session on the LNS until the LCP
> echo timeout decides the connection is dead and terminates it.
> You may also have the complication of them using Session
> information to stop multiple logins from the same username.

That's exactly what I was thinking.

Quote:> try killall -HUP pppd
> or kill -HUP  pid_of_your_ppp_process

> which will send an LCP hangup to the LNS before disconnecting,
> which should clean the session up.

That's what I'll try, thanks.

-- snip --

Quote:> The authentication is sometimes used by the carrier to decide
> which ISP to hand the L2TP off to.  The session is handed off
> and then the ISP goes and requests the authentication again.

> It is also fairly much the first thing the ISP's LNS does when
> a session is presented to it.  If it had to drop the session
> to control congestion, then you would likely see this happen
> this way.

OK, but congestion isn't a random spike.
It builds up and is predictable 100 seconds ahead.
Why can't the clowns trottle-back by giving some
dial-up-modems the engaged signal ?

Quote:> Once the ISP accepts the authentication then the port is
> counted as in-use by the carrier.

Similarly, once the ISP goes off-hook the client is
billed for a connection which is predicatably dud !
 
 
 

debug dialup login & why don't ISP's show engaged ?

Post by Moe Tr » Mon, 13 Apr 2009 02:28:11


On Fri, 10 Apr 2009, in the Usenet newsgroups comp.os.linux.networking and


>> You'd have to ask your ISP.
>They've just got affirmative-employees who can ask/answer
>standard M$loth questions.

So are you assuming windoze users don't have this problem?  I doubt
many windoze users are yanking power to the modem to disconnect, so
using 'killall pppd' is probably a step in the right direction.

Quote:>> see that you are sending the "right" username and password?

In the logs, do you see

pppd[518]: sent [PAP AuthReq id=0x1 user="REMOVED"  password="REMOVED"]
pppd[518]: rcvd [PAP AuthAck id=0x1 ""]

or

pppd[849]: rcvd [CHAP Challenge id=0x1 <bunch.of.crap>, name = "something"]
pppd[849]: sent [CHAP Response id=0x1 <still.more.crap>, name = "REMOVED"]
pppd[849]: rcvd [CHAP Success id=0x1 "\000"]

depending on the authentication scheme used?

Quote:>ID & pswd are 'computerised'. No manual error.

Some ISPs are using "Point of Presence" providers - other companies that
run dial-in servers for multiple ISPs. Generally, they want the username

ISP will have the same style of username on all of the access points,
but I have seen some dummies.   Using the wrong style username should
result in an immediate disconnect if the terminal server is set up
correctly.


>>                To simplify greatly:

>>                  TERM == good

>>                  HUP == slightly bad

>>                  KILL == very bad
>This doesn't help me [linux user].
>man killall exists but not man 'hup/HUP ...etc.

Depending on who created the man page, there may be a section at the
bottom named

   SEE ALSO

and the kill and killall man pages may reference 'signal(7)'

[compton ~]$ whatis signal
signal               (2)  - ANSI C signal handling
signal               (7)  - list of available signals
[compton ~]$

If 'man 7 signal' doesn't provide you with this man page, point your
browser at 'http://linux.die.net/man/7/signal'

Quote:>OK, but congestion isn't a random spike.
>It builds up and is predictable 100 seconds ahead.
>Why can't the clowns trottle-back by giving some
>dial-up-modems the engaged signal ?

Find your modem manual, and figure out which command is needed to tell
the modem to send the 'engaged' signal.  Simple - there isn't one.

[compton ~]$ zgrep -c ZA [ALR]* | column
AFRINIC.gz:802  APNIC.gz:0      ARIN.gz:0       LACNIC.gz:0     RIPE.gz:0
[compton ~]$

Perhaps you should look for another ISP.  AfriNIC says there are 802
networks in South Africa.

        Old guy

 
 
 

debug dialup login & why don't ISP's show engaged ?

Post by no-topp.. » Tue, 28 Apr 2009 00:30:47



I'm not happy with some of the replies to my query.

I asked:
1. why don't ISPs feedback an engaged signal when they're
  congested, to save their clients, telco connect-costs ?

2. should [and how] I do ppp-down equivalent, to avoid
  the ISP not logging me in again, soon after I've logged out?

killall -HUP pppd seems to have improved matters. Thanks.
And interestingly, since a fraction of a second after
it's executed, I can hear that the remote modem
goes on-hook.

So that confirms that the signal sent by me, gets detected
beyound the remote modem, and causes a signal to be fed
back to put the modem on-hook.

Therefore there would be no problem to get a signal,
to give the client 'engaged', when the ISP's system is
congested.  To not do so is stupid and very annoying.


> Your script includes the 'debug' option. Do you have /etc/syslog.conf
> set to log 'daemon.=debug    /var/log/ppp.debug'  and see that you
> are sending the "right" username and password?    See the 'syslog.conf'
> man page if necessary, and restart 'sysklogd' if you alter that file.

OK, it shows more than:
   tail -f /var/log/messages

But why should my box send the wrong username and password
depending on the time of day, week, month, year, weather, TV prog ?

You too can make an intelligent estimate of your road-traffic,
based on the relevant environmental parameters ?

Thanks for input.

 
 
 

debug dialup login & why don't ISP's show engaged ?

Post by Maxwell Lo » Tue, 28 Apr 2009 05:57:29




> I'm not happy with some of the replies to my query.

> I asked:
> 1. why don't ISPs feedback an engaged signal when they're
>   congested, to save their clients, telco connect-costs ?

Are you looking for a busy signal? And an operator to tell you to dial again?

TCP protocols handle congestion. They adapt when the network is congested.
The congestion might be in the ISP's network, or anywhere else on the network.

And the problem will alwasy be temporary.

So what exactly do you THINK should happen?

Either you get a connection, or you don't.

 
 
 

debug dialup login & why don't ISP's show engaged ?

Post by Moe Tr » Tue, 28 Apr 2009 06:45:36


On Sun, 26 Apr 2009, in the Usenet newsgroup comp.os.linux.networking, in


Quote:>I asked:
>1. why don't ISPs feedback an engaged signal when they're
>  congested, to save their clients, telco connect-costs ?

>2. should [and how] I do ppp-down equivalent, to avoid
>  the ISP not logging me in again, soon after I've logged out?

>killall -HUP pppd seems to have improved matters. Thanks.
>And interestingly, since a fraction of a second after
>it's executed, I can hear that the remote modem
>goes on-hook.

>So that confirms that the signal sent by me, gets detected
>beyound the remote modem, and causes a signal to be fed
>back to put the modem on-hook.

Chris, you've been using Linux long enough that you should know how
to enable debugging in 'ppp'.   Had you done so, you would see the
debug messages that look like this:

Apr 26 12:40:04 compton pppd[26264]: rcvd [IPCP ConfAck id=0x2 <addr
192.0.2.216> <compress VJ 0f 01>]
Apr 26 12:40:04 compton pppd[26264]: local IP address 192.0.2.216
Apr 26 12:40:04 compton pppd[26264]: remote IP address 192.0.2.1
Apr 26 12:52:28 compton pppd[26264]: sent [LCP TermReq id=0x2 "User
 request"]
Apr 26 12:52:28 compton pppd[26264]: rcvd [LCP TermAck id=0x2]

Now please read section 3.7 ("Link Termination Phase") of RFC1661
(http://www.ietf.org/rfc/rfc1661.txt).   That will also give you a
hint why yanking the phone line out of the modem to disconnect is
not the best idea.

Quote:>Therefore there would be no problem to get a signal,
>to give the client 'engaged', when the ISP's system is
>congested.  To not do so is stupid and very annoying.

And how would they do this?  Tell the modem to go off-hook so that
you get a busy signal?  If you did that often enough on your line,
don't you think the telephone company would start charging you extra
for tying up their equipment?   The way the telephone system is
designed is in the expectation that only a small amount of the
telephones will be in use at any given moment - about a tenth in
fact. You've no doubt heard of earthquakes - the phone system will
have problems because every idiot nearby will pick up the telephone
to call some one and say "Did you feel that???" and will instead
not get a dial tone because to many idiots are trying to use the
phone at the same time.  Yes, it really happens that way.

Oh, and if you wonder why the phone company can't handle all the
phones in use at the same time, think how much extra hardware they
would have to have, and why your telephone bill would be ten times
higher to pay for that rarely needed hardware.

Quote:>But why should my box send the wrong username and password
>depending on the time of day, week, month, year, weather, TV prog ?

Are you absolutely positive that every time you dial in, you always
get connected to the exact same computer, with a single /etc/passwd
file that has your authentication tokens?   That certainly is not
the case here - as looking at the 'remote IP address' or even the
string in the 'CHAP Challenge' differs - heck some of the numbers
I dial in to use PAP instead of CHAP. I'm seeing terminal servers
located in cities over 800 kilometers apart, yet I'm using "local"
telephone numbers to the _same_ ISP.

Quote:>You too can make an intelligent estimate of your road-traffic,
>based on the relevant environmental parameters ?

That's nice, but it has nothing to do with ppp.  Your problem seems
to be that your ISP has to many modems for the amount of upstream
bandwidth they have. Maybe you should change ISPs.

        Old guy

 
 
 

1. Does truss hide stuff or why PAM failures don't show up?

Hi all!

I hoped running truss would show why I'm getting
PAM_SESSION_ERR in certain circumstances.

Running truss -f doesn't show anything except debug
messages. (After setting debug options.) The output
consists of a sequence of snippets like the one below.

There is absolutely nothing between one snippet and the
next, no failed system calls, as if PAM's failure was
the result of reading /etc/pam.conf.

Or is truss designed so as not to trace security
related stuff? (Hmmm... steganography would also
explain why PAM is so scarcely documented in Solaris ;-)

Here's the snippet:

21915:  open("/var/run/syslog_door", O_RDONLY)          = 6
21915:  door_info(6, 0xFFBEE540)                        = 0
21915:  getpid()                                        = 21915 [21909]
21915:  door_call(6, 0xFFBEE528)                        = 0
21915:  close(6)                                        = 0
21915:  getpid()                                        = 21915 [21909]
21915:  fstat(4, 0xFFBEEF58)                            = 0
21915:  time()                                          = 1096567257
21915:  getpid()                                        = 21915 [21909]
21915:  putmsg(4, 0xFFBEE610, 0xFFBEE604, 0)            = 0
21915:          ctl:  maxlen=24   len=24   buf=0xFFBEEF40: "\0\0\0\0\0\0\010"..
21915:    \0\0\0\0\0\0\010\0\0\0\0\0\0\0 '01D8\0\0\0\0\0 '
21915:          dat:  maxlen=1280 len=142  buf=0xFFBEEA40: " S e p   3 0   2"..
21915:     S e p   3 0   2 0 : 0 0 : 5 7   a u t h p a m [ 2 1 9 1 5 ] :  
21915:     [ I D   4 8 5 0 8 4   F A C I L I T Y _ A N D _ P R I O R I T Y
21915:     ]   P A M [ 2 1 9 1 5 ] :   p a m _ e n d ( 2 4 8 c 0 ) :   s t
21915:     a t u s   =   C a n   n o t   m a k e / r e m o v e   e n t r y
21915:       f o r   s e s s i o n\n\0

2. StarOffice 4.0

3. installed window managers don't show up in login screen

4. xwave linking problems "undefined reference"

5. 'last' command doesn't show complete login times

6. what does: (2)No such file or directory: select claimed we could write, but in fact we couldn't. This is a bug in Windows mean?

7. 'who' Shows telnet login When There Isn't One

8. 845GE Chipset severe performance problems

9. Why don't 'kill' references appear in pacct/acctcom listings?

10. Ximian Gnome local login doesn't show up in 'who' list

11. Why don't console message appear in my ``console'' window?

12. Why "login='exec login'"?

13. transition from isp 'A' to isp 'B' routing problem