The qpopper list archive ending on 17 Sep 1999
Topics covered in this issue include:
1. Re: Unable to get canonical name error (Yes, I read the FAQ)
Randall Gellens <randy at pensive dot org>
Mon, 13 Sep 1999 22:40:42 -0700
2. Re: Unable to get canonical name error (Yes, I read the FAQ)
Randall Gellens <randy at pensive dot org>
Mon, 13 Sep 1999 22:40:42 -0700
3. Polling control
Forrest Aldrich <forrie at forrie dot com>
Tue, 14 Sep 1999 15:23:01 -0400
4. Inetd won't start popper (or ftp)
"Jerry O'Brien" <jobrien at cuttingedge dot net>
Tue, 14 Sep 1999 16:02:50 -0500
5. Re: pop accounts vs shell accounts
"Franco Catena" <catena at surson.com dot br>
Tue, 14 Sep 1999 21:56:58 -0300
6. Re: pop accounts vs shell accounts
Christian Pinheiro <pinheiro at veritel.com dot br>
Tue, 14 Sep 1999 22:10:16 -0300
7. Qpopper 3.0b18 PAM and BullDB?
Jonathan Benson <sysadmin at ocean.com dot au>
Wed, 15 Sep 1999 18:55:14 +1000
8. RE: pop accounts vs shell accounts
Steven Fletcher <stevenf at shellnet.co dot uk>
Wed, 15 Sep 1999 11:09:50 +0100
9. Re: Polling control
"Michael D. Sofka" <sofkam at rpi dot edu>
Wed, 15 Sep 1999 10:35:22 -0400
10. looking for pop3 server that works with virtual hosts
"Jeremy C. Reed" <reed at wcug.wwu dot edu>
Wed, 15 Sep 1999 08:17:32 -0700 (PDT)
11. RE: Polling control
"Pandelis Papanikolaou" <panda at compulink dot gr>
Wed, 15 Sep 1999 18:27:01 +0300
12. RE: Polling control
"Michael D. Sofka" <sofkam at rpi dot edu>
Wed, 15 Sep 1999 12:14:40 -0400
13. RE: Polling control
"Huba Leidenfrost" <huba at uidaho dot edu>
Wed, 15 Sep 1999 09:52:15 -0700
14. Re: Polling control
Vincent Kwan <vinkwan at aicompro dot com>
Wed, 15 Sep 1999 17:22:29 -0700
15. Re: Polling control
Wayne Heming <wheming at hemnet.com dot au>
Thu, 16 Sep 1999 11:15:44 +1000
16. is qpopper 3.0 vulnerable ?
Dariusz Zmokly <globi at graff.com dot pl>
Thu, 16 Sep 1999 13:38:44 +0200
17. Re: is qpopper 3.0 vulnerable ?
pestilence <pestilence at netplan dot gr>
Thu, 16 Sep 1999 16:05:14 +0300
18. RE: is qpopper 3.0 vulnerable ?
Steven Fletcher <stevenf at shellnet.co dot uk>
Thu, 16 Sep 1999 14:04:25 +0100
19. Re: is qpopper 3.0 vulnerable ?
Nicolas Soriano <Nicolas.Soriano at univ-rennes1 dot fr>
Thu, 16 Sep 1999 15:30:28 +0200
20. Re: is qpopper 3.0 vulnerable ?
pestilence <pestilence at netplan dot gr>
Thu, 16 Sep 1999 17:07:09 +0300
21. can receive but cannot send
Feng Qiu <fqiu at biochem.okstate dot edu>
Thu, 16 Sep 1999 12:30:12 -0500
22. Re: can receive but cannot send
"Jeremy C. Reed" <reed at wcug.wwu dot edu>
Thu, 16 Sep 1999 11:16:36 -0700 (PDT)
23. Re: Load averages and large mailfiles
Carrer Yuri <yurj at dns.alfa dot it>
Fri, 17 Sep 1999 12:22:27 +0200 (MET DST)
24. RE: Load averages and large mailfiles
Steven Fletcher <stevenf at shellnet.co dot uk>
Fri, 17 Sep 1999 11:49:00 +0100
25. canonical error...
dandrews at mpiua dot com
Fri, 17 Sep 1999 09:06:43 -0400
26. RE: canonical error...
Steven Fletcher <stevenf at shellnet.co dot uk>
Fri, 17 Sep 1999 14:50:24 +0100
27. .user.pop lock busy! Is another session active?
"Marcelo dos S. Tavares" <mtavares at argo.com dot br>
Fri, 17 Sep 1999 11:08:10 -0400
28. Re: .user.pop lock busy! Is another session active?
Carrer Yuri <yurj at dns.alfa dot it>
Fri, 17 Sep 1999 17:38:50 +0200 (MET DST)
29. RE: .user.pop lock busy! Is another session active?
Steven Fletcher <stevenf at shellnet.co dot uk>
Fri, 17 Sep 1999 17:23:33 +0100
30. RE: .user.pop lock busy! Is another session active?
Carrer Yuri <yurj at dns.alfa dot it>
Fri, 17 Sep 1999 18:26:37 +0200 (MET DST)
31. Stuck pop files
Rick Kunkel <kunkel at w-link dot net>
Fri, 17 Sep 1999 09:43:03 -0700 (PDT)
32. I wrote about this canonical name denial once before and have checked
Rick Kunkel <kunkel at w-link dot net>
Fri, 17 Sep 1999 09:46:35 -0700 (PDT)
33. RE: .user.pop lock busy! Is another session active?
Leonard Hermens <Leonard.Hermens at rcity dot com>
Fri, 17 Sep 1999 09:53:06 -0700
34. RE: .user.pop lock busy! Is another session active?
Steven Fletcher <stevenf at shellnet.co dot uk>
Fri, 17 Sep 1999 18:01:32 +0100
35. Re: Stuck pop files
Carrer Yuri <yurj at dns.alfa dot it>
Fri, 17 Sep 1999 18:58:23 +0200 (MET DST)
36. Re: .user.pop lock busy! Is another session active?
"Marcelo dos S. Tavares" <mtavares at argo.com dot br>
Fri, 17 Sep 1999 13:02:01 -0400
37. RE: .user.pop lock busy! Is another session active?
Steven Fletcher <stevenf at shellnet.co dot uk>
Fri, 17 Sep 1999 18:06:51 +0100
38. RE: .user.pop lock busy! Is another session active?
Carrer Yuri <yurj at dns.alfa dot it>
Fri, 17 Sep 1999 19:04:49 +0200 (MET DST)
39. Re: Stuck pop files
Carrer Yuri <yurj at dns.alfa dot it>
Fri, 17 Sep 1999 19:13:35 +0200 (MET DST)
40. Re: I wrote about this canonical name denial once before and have checked into some things since...
Carrer Yuri <yurj at dns.alfa dot it>
Fri, 17 Sep 1999 19:13:06 +0200 (MET DST)
41. Re: I wrote about this canonical name denial once before and have
Alan Brown <alan at manawatu.gen dot nz>
Sat, 18 Sep 1999 05:25:25 +1200 (NZST)
42. Re: I wrote about this canonical name denial once before and have
Admin Mailing Lists <mlist at intergrafix dot net>
Fri, 17 Sep 1999 13:30:49 -0400 (EDT)
43. Re: .user.pop lock busy! Is another session active?
"Marcelo dos S. Tavares" <mtavares at argo.com dot br>
Fri, 17 Sep 1999 13:49:19 -0400
44. RE: .user.pop lock busy! Is another session active?
Admin Mailing Lists <mlist at intergrafix dot net>
Fri, 17 Sep 1999 13:40:11 -0400 (EDT)
45. RE: .user.pop lock busy! Is another session active?
Admin Mailing Lists <mlist at intergrafix dot net>
Fri, 17 Sep 1999 13:56:10 -0400 (EDT)
46. RE: .user.pop lock busy! Is another session active?
Carrer Yuri <yurj at dns.alfa dot it>
Fri, 17 Sep 1999 19:51:17 +0200 (MET DST)
47. RE: .user.pop lock busy! Is another session active?
Carrer Yuri <yurj at dns.alfa dot it>
Fri, 17 Sep 1999 19:53:50 +0200 (MET DST)
48. RE: .user.pop lock busy! Is another session active?
Leonard Hermens <Leonard.Hermens at rcity dot com>
Fri, 17 Sep 1999 11:40:43 -0700
49. Re: Stuck pop files
"S. Faruque Ahmed" <sfque at texasgroup dot net>
Sat, 18 Sep 1999 01:34:11 +0600
50. RE: .user.pop lock busy! Is another session active?
James Sneeringer <jvs at ocslink dot com>
Fri, 17 Sep 1999 15:52:39 -0500 (CDT)
Date: Mon, 13 Sep 1999 22:40:42 -0700
From: Randall Gellens <randy at pensive dot org>
Subject: Re: Unable to get canonical name error (Yes, I read the FAQ)
At 3:48 PM -0700 9/10/99, Rick Kunkel wrote:
> In my case, there is
>an error message in the logs (the canonical name thing) AND the connection
>is refused by the server, before authentication even kicks in, as can be
>shown by telnetting to port 110 and watching it connect and then pop up a
>box that says connection refused.
My guess is that you have a firewall or TCP wrapper or something else
that prevents the connection.
--
Randall Gellens Randy at Pensive dot Org
---------------------- (randomly-selected tag) ---------------------
Cabbage: A familiar kitchen-garden vegetable about as large and wise
as a man's head.
Date: Mon, 13 Sep 1999 22:40:42 -0700
From: Randall Gellens <randy at pensive dot org>
Subject: Re: Unable to get canonical name error (Yes, I read the FAQ)
At 3:48 PM -0700 9/10/99, Rick Kunkel wrote:
> In my case, there is
>an error message in the logs (the canonical name thing) AND the connection
>is refused by the server, before authentication even kicks in, as can be
>shown by telnetting to port 110 and watching it connect and then pop up a
>box that says connection refused.
My guess is that you have a firewall or TCP wrapper or something else
that prevents the connection.
--
Randall Gellens Randy at Pensive dot Org
---------------------- (randomly-selected tag) ---------------------
Cabbage: A familiar kitchen-garden vegetable about as large and wise
as a man's head.
Date: Tue, 14 Sep 1999 15:23:01 -0400
From: Forrest Aldrich <forrie at forrie dot com>
Subject: Polling control
Is there some mechanism by which we can control the frequency of when
people poll for POP mail? For example: where I work, we have some
dummies that set polling intervals at every 5 seconds, and so forth.
If you can't enforce this through kind means, there must be some kind
of mechanism that can be wrapped around popper (or implemented in it)
to control this.... ?
Thanks.
From: "Jerry O'Brien" <jobrien at cuttingedge dot net>
Subject: Inetd won't start popper (or ftp)
Date: Tue, 14 Sep 1999 16:02:50 -0500
Hi all,
My POP3 server keeps dying and I'm getting these messages in syslog:
popper[11401]: Unable to obtain socket and address of client, err = 107
I know I've seen discussion of this before, but I don't remember what the
solution was, and the FAQ doesn't seem to address it.
Also, I've found that ftp services won't start either, so I restarted inetd
(HUPping it wouldn't do) and then everything runs for a few minutes. I'm not
really sure whether popper or inetd is the cause.
Jerry O'Brien
From: "Franco Catena" <catena at surson.com dot br>
Subject: Re: pop accounts vs shell accounts
Date: Tue, 14 Sep 1999 21:56:58 -0300
How can I create pop accounts without creatin UNIX accounts???? I need this
kind of tool for POP and Postfix.
-----Mensagem Original-----
De: Webmaster <webmaster-pa at elogica.com dot br>
Para: Subscribers of Qpopper <qpopper at lists.pensive dot org>
Enviada em: Sexta-feira, 30 de Julho de 1999 15:34
Assunto: pop accounts vs shell accounts
> Hello again,
>
> Is there a way in qpopper to create pop accounts without creatin
> shell accounts?
>
> Thanks
>
>
Date: Tue, 14 Sep 1999 22:10:16 -0300
From: Christian Pinheiro <pinheiro at veritel.com dot br>
Subject: Re: pop accounts vs shell accounts
Don't think it's possible.
Using Qmail with LDAP patch, it's possible.
Franco Catena wrote:
>
> How can I create pop accounts without creatin UNIX accounts???? I need this
> kind of tool for POP and Postfix.
> -----Mensagem Original-----
> De: Webmaster <webmaster-pa at elogica.com dot br>
> Para: Subscribers of Qpopper <qpopper at lists.pensive dot org>
> Enviada em: Sexta-feira, 30 de Julho de 1999 15:34
> Assunto: pop accounts vs shell accounts
>
> > Hello again,
> >
> > Is there a way in qpopper to create pop accounts without creatin
> > shell accounts?
> >
> > Thanks
> >
> >
Date: Wed, 15 Sep 1999 18:55:14 +1000
From: Jonathan Benson <sysadmin at ocean.com dot au>
Subject: Qpopper 3.0b18 PAM and BullDB?
I obtained the source with PAM patch from:
http://www.ubiobio.cl/~gpoo/linux/
My system is a fully patched RedHat 6.0 box.
After also patching as per a previous post of mine to get BULLDB support
I ended up with a qpopper binary compiled by using:
./configure --prefix=/usr --enable-servermode
--enable-bulletins=/var/spool/bulls --with-pam
It also had DBM support enabled by adding -DBULLDB to the Makefile.
My problems started once I upgraded our mail server to the new system
(and hence had some 4000 users start using it).
I noticed (and some of ours users have complained about) messages
stating that the Bulletin Database could not be opened (only every now
and then, not a regular thing). Once you say OK and possibly re-enter
your password (depends on mail client) everything continues as normal.
As I haven't started using the feature yet I just recompiled qpopper
without the bulletin support and AFAIK things are now fine. I still see
a number of PAM authentication errors in the logs but these could simply
be users mistyping their password or something so I'm not (yet)
concerned about that.
Any suggestions, feedback, etc welcome as this is a feature I'd like to
use.
Thanks
Jon
--
Jonathan Benson
Systems Administrator
Ocean Internet
http://www.ocean.com.au/
From: Steven Fletcher <stevenf at shellnet.co dot uk>
Subject: RE: pop accounts vs shell accounts
Date: Wed, 15 Sep 1999 11:09:50 +0100
mysql_mail used to exist at http://www.netd.co.za/mysql_mail/, but dosen't
seem to anymore. (Does anyone know where it went?) That would have let you
authorise people via a SQL database and let them send mail via Exim....
however that dosen't seem to exlist anymore. I do have the patches to hand
so if anyone wants them just contact me.
Thanks;
Steven Fletcher
stevenf at shellnet.co dot uk
> -----Original Message-----
> From: Franco Catena [mailto:catena at surson.com dot br]
> Sent: 15 September 1999 01:57
> To: Subscribers of Qpopper
> Subject: Re: pop accounts vs shell accounts
>
>
> How can I create pop accounts without creatin UNIX
> accounts???? I need this
> kind of tool for POP and Postfix.
> -----Mensagem Original-----
> De: Webmaster <webmaster-pa at elogica.com dot br>
> Para: Subscribers of Qpopper <qpopper at lists.pensive dot org>
> Enviada em: Sexta-feira, 30 de Julho de 1999 15:34
> Assunto: pop accounts vs shell accounts
>
>
> > Hello again,
> >
> > Is there a way in qpopper to create pop accounts without creatin
> > shell accounts?
> >
> > Thanks
> >
> >
>
>
>
>
Date: Wed, 15 Sep 1999 10:35:22 -0400
From: "Michael D. Sofka" <sofkam at rpi dot edu>
Subject: Re: Polling control
At 03:23 PM 9/14/99 -0400, Forrest Aldrich wrote:
>Is there some mechanism by which we can control the frequency of when
>people poll for POP mail? For example: where I work, we have some
>dummies that set polling intervals at every 5 seconds, and so forth.
>
>If you can't enforce this through kind means, there must be some kind
>of mechanism that can be wrapped around popper (or implemented in it)
>to control this.... ?
We have about 14,000 accounts, 6,500 of which are active. There
are 350,000 popper connections per day, the majority coming from
a relatively small number of users who poll every 5 seconds, or
every minute. Generally, this isn't a big problem. Most of the heavy
pollers end up hurting themselves with ``poplock'' errors, but the
every 5 seconds turned out to be from a specialized winbiff program,
which just polls for new mail (like picking up the phone every 5 seconds
to see if anybody is calling you).
Here are the various things we have done or have considered:
1. Wrote our own xbiff that opened a separate tcp connection,
and stated the mailbox looking for any change in size. If the
mailbox size changed, it popped up a little window saying ``you
have mail.'' One problem is that reading mail via popper changed
the size, so you would get a new window saying you had new
mail after reading mail. This was fixed by having the program
extract message headers and tell you who the mail was from.
It then only reported new headers even after the false hits generated
by a popper run. This code is very alpha, but if you are interested
I can direct you to the programmer who worked on that project.
2. During a mail crisis, when a resolver library problem caused
the mail servers to slow down. We wrap popper in tcp-wrappers,
so I wrote a script which looked at the popper logs and denied
access to anybody checking mail more than once very 5 minutes.
The way the script worked, it looked at the average access over
a half hour, and blocked if the average exceeded a threshold. I
can send the perl script to anybody interested, but it is very
idiosyncratic to our setup, which includes a modified popper
logging facility.
3. You can use inetd to limit the number of popper connections
per minute, and then leave it to the users to allocate a fair distribution.
So, if somebody polls every 5 seconds, and doesn't mind the
angry messages from users who can't read their mail, then so
be it. Posting the top pollers to a web page would be necessary,
and this is likely to require a policy decision. We have not tried
this, but I am, personally, a firm believer in the power of peer
pressure.
4. What I would like to see---and what I'm too busy to do---is to
have a popper modified to run in daemon mode and maintain
state information. That is, run a daemon that forks off children
to handle popper request. The children communicate back to
the parent the uid of the person who just read mail. Then, the
parent can simply not process more than, say, one request
per minute for any giver person, or no more than 1000 requests
per day, or some other metric. What is nice about this
approach is it is efficient, it increases the efficiency of
popper (by running in daemon mode), and popper can just
silently lie about the results of excessive polls. That is,
if can just say ``you have zero new messages''' if the polling
is excessive. :-)
Mike
--
Michael D. Sofka sofkam at rpi dot edu
CIS/SSS Sr. Systems Programmer AFS/DFS, email, listproc, TeX, epistemology.
Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
Date: Wed, 15 Sep 1999 08:17:32 -0700 (PDT)
From: "Jeremy C. Reed" <reed at wcug.wwu dot edu>
Subject: looking for pop3 server that works with virtual hosts
I am looking for a pop3 server that can work with virtual domains
where multiple users could have the same name, such as:
jeremy at reedmedia dot net
jeremy at whatcomnews dot com
The pop server maybe check for an '@' in the USER name and if it exists
then use a password file such as
/etc/domains/w/whatcomnews.com/passwd
for authentication.
The mailbox could be located like
/var/spool/mail/w/whatcomnews.com/jeremy
Does anyone know of something simple like this?
(I do not want to use qmail because it has two much extra stuff.)
Thanks for any suggestions or advice.
(Also: can anyone point me to some easy-to-follow pop3 source
code?)
Jeremy C. Reed
------------------------------------------------------------
http://www.toprecruits.com
From: "Pandelis Papanikolaou" <panda at compulink dot gr>
Subject: RE: Polling control
Date: Wed, 15 Sep 1999 18:27:01 +0300
This in not quite to the point but I think is relevant.
How can you make the popper deny connections that exceed a specified
frequency from a single IP? I am mostly worried about denial of service
attacks where someone with an 'octopus' like exploit can launch a great deal
of connections on any given port.
Of course that is more of a problem fro tcpd to solve.
Any suggestions ?
-----Original Message-----
From: Michael D. Sofka [mailto:sofkam at rpi dot edu]
Sent: Wednesday, September 15, 1999 5:35 PM
To: Subscribers of Qpopper
Subject: Re: Polling control
At 03:23 PM 9/14/99 -0400, Forrest Aldrich wrote:
>Is there some mechanism by which we can control the frequency of when
>people poll for POP mail? For example: where I work, we have some
>dummies that set polling intervals at every 5 seconds, and so forth.
>
>If you can't enforce this through kind means, there must be some kind
>of mechanism that can be wrapped around popper (or implemented in it)
>to control this.... ?
We have about 14,000 accounts, 6,500 of which are active. There
are 350,000 popper connections per day, the majority coming from
a relatively small number of users who poll every 5 seconds, or
every minute. Generally, this isn't a big problem. Most of the heavy
pollers end up hurting themselves with ``poplock'' errors, but the
every 5 seconds turned out to be from a specialized winbiff program,
which just polls for new mail (like picking up the phone every 5 seconds
to see if anybody is calling you).
Here are the various things we have done or have considered:
1. Wrote our own xbiff that opened a separate tcp connection,
and stated the mailbox looking for any change in size. If the
mailbox size changed, it popped up a little window saying ``you
have mail.'' One problem is that reading mail via popper changed
the size, so you would get a new window saying you had new
mail after reading mail. This was fixed by having the program
extract message headers and tell you who the mail was from.
It then only reported new headers even after the false hits generated
by a popper run. This code is very alpha, but if you are interested
I can direct you to the programmer who worked on that project.
2. During a mail crisis, when a resolver library problem caused
the mail servers to slow down. We wrap popper in tcp-wrappers,
so I wrote a script which looked at the popper logs and denied
access to anybody checking mail more than once very 5 minutes.
The way the script worked, it looked at the average access over
a half hour, and blocked if the average exceeded a threshold. I
can send the perl script to anybody interested, but it is very
idiosyncratic to our setup, which includes a modified popper
logging facility.
3. You can use inetd to limit the number of popper connections
per minute, and then leave it to the users to allocate a fair distribution.
So, if somebody polls every 5 seconds, and doesn't mind the
angry messages from users who can't read their mail, then so
be it. Posting the top pollers to a web page would be necessary,
and this is likely to require a policy decision. We have not tried
this, but I am, personally, a firm believer in the power of peer
pressure.
4. What I would like to see---and what I'm too busy to do---is to
have a popper modified to run in daemon mode and maintain
state information. That is, run a daemon that forks off children
to handle popper request. The children communicate back to
the parent the uid of the person who just read mail. Then, the
parent can simply not process more than, say, one request
per minute for any giver person, or no more than 1000 requests
per day, or some other metric. What is nice about this
approach is it is efficient, it increases the efficiency of
popper (by running in daemon mode), and popper can just
silently lie about the results of excessive polls. That is,
if can just say ``you have zero new messages''' if the polling
is excessive. :-)
Mike
--
Michael D. Sofka sofkam at rpi dot edu
CIS/SSS Sr. Systems Programmer AFS/DFS, email, listproc, TeX, epistemology.
Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
Date: Wed, 15 Sep 1999 12:14:40 -0400
From: "Michael D. Sofka" <sofkam at rpi dot edu>
Subject: RE: Polling control
At 06:27 PM 9/15/99 +0300, Pandelis Papanikolaou wrote:
>This in not quite to the point but I think is relevant.
>How can you make the popper deny connections that exceed a specified
>frequency from a single IP? I am mostly worried about denial of service
>attacks where someone with an 'octopus' like exploit can launch a great deal
>of connections on any given port.
>Of course that is more of a problem fro tcpd to solve.
>
>Any suggestions ?
Tricky problem. If the IP is running idnetd, you can use tcp-wrappers
to deny connections from only that user at the IP. Or, if you know
what kind of machines different IP's represent, you can not block
multi-user machines, even if the poling is excessive. (Depending
on the circumstances, you may then be able to throw the abuser off the
multi-user machine under an ``excessive use'' policy.) This is another
reason I prefer a ``state-full'' popper solution, based on the UID that
has read email.
Most of the time this is not a problem for us, but there have been
times were the system was slow, and stopping excessive poling
was a quick way to restore good performance for everybody.
Mike
--
Michael D. Sofka sofkam at rpi dot edu
CIS/SSS Sr. Systems Programmer AFS/DFS, email, listproc, TeX, epistemology.
Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
From: "Huba Leidenfrost" <huba at uidaho dot edu>
Subject: RE: Polling control
Date: Wed, 15 Sep 1999 09:52:15 -0700
This is not trivial but can be done. Something like:
1) Filter your pop log traffic to popper.log
2) Run swatch or some other log watching utility to look for abusers (anyone
popping their mail at greater than your policy
2b) Create that policy so you can refer to it when the user comes screaming
at you with hands swinging
3) When swatch finds your abuser, have it launch a script to put a warning
message in the user's mailbox
4) Continued abuse means you disable their account after x warnings where x
is in that policy you created in 2b)
Hmm, just re-read your message and see that this isn't really what you were
asking. Well you can still use swatch and have swatch put in a hosts.deny
rule for that annoying IP that's flooding you with connections.
Regards,
H u b a
--
--- O HUBA LEIDENFROST Network Systems Analyst
-- <^- huba at uidaho dot edu University of Idaho I.T.S
-- -\/\ http://www.uidaho.edu/~huba
--- \ TEL: 208.885.6721 FAX: 208.885.7539
> This in not quite to the point but I think is relevant.
> How can you make the popper deny connections that exceed a specified
> frequency from a single IP? I am mostly worried about denial of service
> attacks where someone with an 'octopus' like exploit can launch a
> great deal
> of connections on any given port.
> Of course that is more of a problem fro tcpd to solve.
>
> Any suggestions ?
Date: Wed, 15 Sep 1999 17:22:29 -0700
From: Vincent Kwan <vinkwan at aicompro dot com>
Subject: Re: Polling control
Hi all,
I am trying to setup a subdomain mail. If I have a domain, xvy.com, a
user vincent, and a subdomain rst, I want to be able to send a mail to
vincent at rst.xvy dot com without setting a virtual domain for rst. I try
doing an aliases of rst with the MX for xvy, but it can't receive mail sent from
non-local mail server. Any help would be greatly appreciated. Thanks in advance.
--- Vincent
Date: Thu, 16 Sep 1999 11:15:44 +1000
From: Wayne Heming <wheming at hemnet.com dot au>
Subject: Re: Polling control
try
/etc/sendmail.cw
xvy.com
rst.xvy.com
and restart sendmail
It works for me.
wayne
At 10:22 16-09-99 , you wrote:
>Hi all,
>
>I am trying to setup a subdomain mail. If I have a domain, xvy.com, a
>user vincent, and a subdomain rst, I want to be able to send a mail to
>vincent at rst.xvy dot com without setting a virtual domain for rst. I try
>doing an aliases of rst with the MX for xvy, but it can't receive mail
>sent from
>non-local mail server. Any help would be greatly appreciated. Thanks in
>advance.
>
>
>--- Vincent
>
>
>
Date: Thu, 16 Sep 1999 13:38:44 +0200
From: Dariusz Zmokly <globi at graff.com dot pl>
Subject: is qpopper 3.0 vulnerable ?
hi !
sscan shows that qpopper is vulnerable to buffer overflow. Is it true ?
I read qpopper FAQ and there is stated that qpopper 2.5 and later versions
aren't vulnerable. Which information is correct ?
regards,
Dariusz Zmokly
Date: Thu, 16 Sep 1999 16:05:14 +0300
From: pestilence <pestilence at netplan dot gr>
Subject: Re: is qpopper 3.0 vulnerable ?
$version > 2.5 are not vulnerable to the overflow.
--
Kostas Petrakis aka Pestilence
Head admin of Netplan LTD.
http://www.netplan.gr
pestilence at netplan dot gr
=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rewted Network Security Labs
http://www.rewted.org
pestilen at rewted dot org
From: Steven Fletcher <stevenf at shellnet.co dot uk>
Subject: RE: is qpopper 3.0 vulnerable ?
Date: Thu, 16 Sep 1999 14:04:25 +0100
For the definitive guide (from the CERT advisories, CA-98.08.qpopper_vul):
QUALCOMM Incorporated
- ---------------------
Versions of QUALCOMM qpopper prior to 2.5 are vulnerable.
QUALCOMM recommends upgrading to the most recent version
(currently Version 2.52). Patches are available from
ftp://ftp.qualcomm.com/Eudora/servers/unix/popper
Further details, questions and comments should be sent to
<mailto:qpopper at qualcomm dot com>.
Steven Fletcher
stevenf at shellnet.co dot uk
> -----Original Message-----
> From: Dariusz Zmokly [mailto:globi at graff.com dot pl]
> Sent: 16 September 1999 12:39
> To: Subscribers of Qpopper
> Subject: is qpopper 3.0 vulnerable ?
>
>
> hi !
>
> sscan shows that qpopper is vulnerable to buffer overflow. Is
> it true ?
> I read qpopper FAQ and there is stated that qpopper 2.5 and
> later versions
> aren't vulnerable. Which information is correct ?
>
> regards,
> Dariusz Zmokly
>
Date: Thu, 16 Sep 1999 15:30:28 +0200
From: Nicolas Soriano <Nicolas.Soriano at univ-rennes1 dot fr>
Subject: Re: is qpopper 3.0 vulnerable ?
Dariusz Zmokly wrote:
> sscan shows that qpopper is vulnerable to buffer overflow. Is it true ?
> I read qpopper FAQ and there is stated that qpopper 2.5 and later versions
> aren't vulnerable. Which information is correct ?
According to my own experience (about ten attacks each night against my
pop server) qpopper 3 is not vulnerable to bufferoverflow
extract from pop.log :
[17618] @Nicty58.microlink.com.br: -ERR Unknown command: " (I cut a string of 1111 chars) "
But I think they will find something else... ;-(?
--
_____________________________________________________________________
http://www-recomgen.univ-rennes1.fr/Dico
Slackware is Linux on a motorcycle, all wheels and attitude!
Date: Thu, 16 Sep 1999 17:07:09 +0300
From: pestilence <pestilence at netplan dot gr>
Subject: Re: is qpopper 3.0 vulnerable ?
Security is always something that isn't stable, meaning one night you
sleep next day there is a newly bug discovered.
At least up to now there aren't any publickly known buffer overflows of
qpopper 2.5 < $versions, if you look at the code, you will see that
qpoppper handles strings passed to it very nice, and doesn't allow
strings bigger than a certain length to get passed (it cuts the string
down).
--
Kostas Petrakis aka Pestilence
Head admin of Netplan LTD.
http://www.netplan.gr
pestilence at netplan dot gr
=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rewted Network Security Labs
http://www.rewted.org
pestilen at rewted dot org
Date: Thu, 16 Sep 1999 12:30:12 -0500
From: Feng Qiu <fqiu at biochem.okstate dot edu>
Subject: can receive but cannot send
Hello, all,
I have sendmail setup in Sun solaris7. The qpopper let me read messages
from my pc but when I try to send from pc, it said:
Can't send to 'xxxxxe-mail addressxxxx'. The server gives this reason:
'550 <xxxxxe-mail addressxxxx>... Relaying denied'.
Anyone know what is the reason?
Feng Qiu
Date: Thu, 16 Sep 1999 11:16:36 -0700 (PDT)
From: "Jeremy C. Reed" <reed at wcug.wwu dot edu>
Subject: Re: can receive but cannot send
On Thu, 16 Sep 1999, Feng Qiu wrote:
> Can't send to 'xxxxxe-mail addressxxxx'. The server gives this reason:
> '550 <xxxxxe-mail addressxxxx>... Relaying denied'.
In my /etc/sendmail.cf I have the lines:
# IP addresses of local clients allowed to relay through us
F{LocalIP}/etc/mail/localip
Then my /etc/mail/localip has the addresses for the local networks
that can sendmail will relay for, like:
192.168.1
Hope this helps.
Jeremy C. Reed
------------------------------------------------------------
http://www.toprecruits.com
Date: Fri, 17 Sep 1999 12:22:27 +0200 (MET DST)
From: Carrer Yuri <yurj at dns.alfa dot it>
Subject: Re: Load averages and large mailfiles
What does it mean this?
Sep 15 09:07:08 dns popper[14892]: xxxxxx@xxxxxxxxxx: -ERR SIGHUP or
SIGPIPE
Thanxs
From: Steven Fletcher <stevenf at shellnet.co dot uk>
Subject: RE: Load averages and large mailfiles
Date: Fri, 17 Sep 1999 11:49:00 +0100
The POP3 client got disconnected, could be due to a network congestion or
the client disconnecting their modem, for example, without closing their
email client.
Steven Fletcher
stevenf at shellnet.co dot uk
> -----Original Message-----
> From: Carrer Yuri [mailto:yurj at dns.alfa dot it]
> Sent: 17 September 1999 11:22
> Cc: Subscribers of Qpopper
> Subject: Re: Load averages and large mailfiles
>
>
> What does it mean this?
>
> Sep 15 09:07:08 dns popper[14892]: xxxxxx@xxxxxxxxxx: -ERR SIGHUP or
> SIGPIPE
>
> Thanxs
>
>
>
>
From: dandrews at mpiua dot com
Subject: canonical error...
Date: Fri, 17 Sep 1999 09:06:43 -0400
Does anyone know the cause of this error being reported in my maillog, it
seems to happen each time a client connects, although mail pickup is still
successful...
in.qpopper [1831]: (v2.53) unable to get canonical name of client, err = 0
Any help appreciated! =)
David Andrews
PC LAN Administrator
MPIUA
dandrews at mpiua dot com
From: Steven Fletcher <stevenf at shellnet.co dot uk>
Subject: RE: canonical error...
Date: Fri, 17 Sep 1999 14:50:24 +0100
Sounds like a dodgy DNS setup; do your connecting clients have both forward
& reverse DNS entries?
Steven Fletcher
stevenf at shellnet.co dot uk
> -----Original Message-----
> From: David Andrews [mailto:dandrews at mpiua dot com]
> Sent: 17 September 1999 14:07
> To: Subscribers of Qpopper
> Subject: canonical error...
>
>
> Does anyone know the cause of this error being reported in my
> maillog, it
> seems to happen each time a client connects, although mail
> pickup is still
> successful...
>
> in.qpopper [1831]: (v2.53) unable to get canonical name of
> client, err = 0
>
> Any help appreciated! =)
>
>
> David Andrews
> PC LAN Administrator
> MPIUA
> dandrews at mpiua dot com
>
>
>
Date: Fri, 17 Sep 1999 11:08:10 -0400
From: "Marcelo dos S. Tavares" <mtavares at argo.com dot br>
Subject: .user.pop lock busy! Is another session active?
Hi all,
I´m using Qpopper 3.0 BETA 18 -- servermode configured in my Linux
system. Some users, mainly
those with mailbox with above of 2MB, have problems to download e-mails
and receive the message:
-ERR [IN-USE] /car/spool/mail/.user.pop lock busy! Is another session
active? (11)
And normally I have that to remove the lock user.pop manually of the
mail spool.
so.. anyone got any ideas how to resolve this problem ?
Very Thanks !
Date: Fri, 17 Sep 1999 17:38:50 +0200 (MET DST)
From: Carrer Yuri <yurj at dns.alfa dot it>
Subject: Re: .user.pop lock busy! Is another session active?
>
> -ERR [IN-USE] /car/spool/mail/.user.pop lock busy! Is another session
> active? (11)
>
> And normally I have that to remove the lock user.pop manually of the
> mail spool.
>
> so.. anyone got any ideas how to resolve this problem ?
Yes, dump qpopper and use another pop server.
Baing seriously, there's a bad interaction somewhere between Outlook
Express and qpopper.
Yuri
From: Steven Fletcher <stevenf at shellnet.co dot uk>
Subject: RE: .user.pop lock busy! Is another session active?
Date: Fri, 17 Sep 1999 17:23:33 +0100
> Baing seriously, there's a bad interaction somewhere between Outlook
> Express and qpopper.
uuuh....Why would it matter if the POP3 client was Outlook, Agent,
fetchmail, or anything for that matter? POP3 is POP3, nothing will change
that.
More than likely people are simply timing out and trying to connect again
before your server times out. I would look at Qpopper's -T option.
Steven Fletcher
stevenf at shellnet.co dot uk
Date: Fri, 17 Sep 1999 18:26:37 +0200 (MET DST)
From: Carrer Yuri <yurj at dns.alfa dot it>
Subject: RE: .user.pop lock busy! Is another session active?
On Fri, 17 Sep 1999, Steven Fletcher wrote:
>
> > Baing seriously, there's a bad interaction somewhere between Outlook
> > Express and qpopper.
>
> uuuh....Why would it matter if the POP3 client was Outlook, Agent,
> fetchmail, or anything for that matter? POP3 is POP3, nothing will change
> that.
>
> More than likely people are simply timing out and trying to connect again
> before your server times out. I would look at Qpopper's -T option.
If the TCP connection die, why qpopper insists on keeping the damn
.<user>.pop around? Is there a patch out there to see which message
qpopper is sending to the user and how much % of the message it has
sent? A lot of time some users (at the telephone with me) tell me that he
is tryng to download, I see the qpopper process starting and then the
connection from his side stop, but I still see the qpopper and the lock
file.
Yuri
Date: Fri, 17 Sep 1999 09:43:03 -0700 (PDT)
From: Rick Kunkel <kunkel at w-link dot net>
Subject: Stuck pop files
Anyone have any idea why pop files would get stuck stuck stuck for a long
time? I have customers that call occasionally saying that they can't get
their mail, so they disconnect, call me, and I look, and there's still a
.username.pop file from like 5 minutes before. I can sit there and wait
and it doesn't go away. Eventually, later in the day I check and it's
gone.
My line from inetd.conf is as follow:
pop stream tcp nowait root /usr/libexec/tcpd popper -T 60 -b /var/mail/bulldir
I'd be cool to know why they're sticking, but it'd also be cool to know
how to kill the pop process so that it doesn't generate the poplock busy
when they're not even checking (like 30 minutes later!) Any help would be
appreciated...
Thanks,
Rick Kunkel
Date: Fri, 17 Sep 1999 09:46:35 -0700 (PDT)
From: Rick Kunkel <kunkel at w-link dot net>
Subject: I wrote about this canonical name denial once before and have checked
I get the canonical name error occasionally, which is no big deal.
However, my users are actually KEPT from checking mail. It denies them
when name and address don't jibe. From what I hear, it's not Qpopper
causing the refusal, but maybe something else. I've looked everywhere I
can think of. Any ideas of good places where some setting like that might
hide out? We have a file in /usr/local/etc called netperm-table which
will deny connections over various ports to people not in a list of
addresses, but the pop port is open to everyone. I thought that would be
the culprit, but it wasn't...Any other ideas?
Rick Kunkel
Date: Fri, 17 Sep 1999 09:53:06 -0700
From: Leonard Hermens <Leonard.Hermens at rcity dot com>
Subject: RE: .user.pop lock busy! Is another session active?
> > Baing seriously, there's a bad interaction somewhere between Outlook
> > Express and qpopper.
>
>uuuh....Why would it matter if the POP3 client was Outlook, Agent,
>fetchmail, or anything for that matter? POP3 is POP3, nothing will change
>that.
>
>More than likely people are simply timing out and trying to connect again
>before your server times out. I would look at Qpopper's -T option.
>
>Steven Fletcher
>stevenf at shellnet.co dot uk
I can confirm that Outlook clients in the past (don't know about
version 5) have caused a hang that Eudora (for example) did not
exhibit when downloading a large attachment or when certain header
lines were blank. This would lead to a SIGHUP on the qpopper because
the Outlook client did/could not exit gracefully.
-- Leonard
From: Steven Fletcher <stevenf at shellnet.co dot uk>
Subject: RE: .user.pop lock busy! Is another session active?
Date: Fri, 17 Sep 1999 18:01:32 +0100
> If the TCP connection die, why qpopper insists on keeping the damn
> .<user>.pop around?
It's a socket application - your clients probably have not just killed the
connection, but simply stopped receiving data and timed out at their end. It
would stay running untill either the OS's IP stack realises that it isn't
happening any more (I'm guessing you're using Linux here, try a *BSD
implementation instead, they have much nicer IP layers), then the connection
will die (or, if Qpopper has finished sending the data to the IP stack, then
it will go and wait for its idle timer to kick in before it kills itself.
So more than likley, you're relying on 3 things:
1) Dodgy/slow/unreliable dial-up lines
2) IP stack keeping schtum to its daemons
3) A third idle timer, qpopper's.
>Is there a patch out there to see which message
> qpopper is sending to the user and how much % of the message it has
> sent?
Not for percentage, but use a trace file and you'll be able to see what the
last RETR command that was sent was.
Steven Fletcher
stevenf at shellnet.co dot uk
Date: Fri, 17 Sep 1999 18:58:23 +0200 (MET DST)
From: Carrer Yuri <yurj at dns.alfa dot it>
Subject: Re: Stuck pop files
> Anyone have any idea why pop files would get stuck stuck stuck for a long
> time? I have customers that call occasionally saying that they can't get
> their mail, so they disconnect, call me, and I look, and there's still a
> .username.pop file from like 5 minutes before. I can sit there and wait
> and it doesn't go away. Eventually, later in the day I check and it's
> gone.
>
> My line from inetd.conf is as follow:
>
> pop stream tcp nowait root /usr/libexec/tcpd popper -T 60 -b /var/mail/bulldir
>
> I'd be cool to know why they're sticking, but it'd also be cool to know
> how to kill the pop process so that it doesn't generate the poplock busy
> when they're not even checking (like 30 minutes later!) Any help would be
> appreciated...
Heh, I'm not alone :-) I'm planning to switch to cucipop. Qpopper is too
"corporate". :)
Yuri
Date: Fri, 17 Sep 1999 13:02:01 -0400
From: "Marcelo dos S. Tavares" <mtavares at argo.com dot br>
Subject: Re: .user.pop lock busy! Is another session active?
OK!
Do you know another POP3 server with support hash spool, i.e., the mail
spool of
the user is located in /var/spool/mail/u/s/user.
Example: User peter -- /var/spool/mail/p/e/peter
Old, we used CUCIPOP. But it seems does not have has supported hash spool
mail.
Very Thanks!
Carrer Yuri wrote:
> >
> > -ERR [IN-USE] /car/spool/mail/.user.pop lock busy! Is another session
> > active? (11)
> >
> > And normally I have that to remove the lock user.pop manually of the
> > mail spool.
> >
> > so.. anyone got any ideas how to resolve this problem ?
>
> Yes, dump qpopper and use another pop server.
>
> Baing seriously, there's a bad interaction somewhere between Outlook
> Express and qpopper.
>
> Yuri
From: Steven Fletcher <stevenf at shellnet.co dot uk>
Subject: RE: .user.pop lock busy! Is another session active?
Date: Fri, 17 Sep 1999 18:06:51 +0100
> I can confirm that Outlook clients in the past (don't know about
> version 5) have caused a hang that Eudora (for example) did not
> exhibit
Yep; my point to Yuri exactly: If Outlook crashes and Eudora does not, with
the same POP3 server, then what is to fault? Qpopper or Outlook?
Outlook, not Qpopper :-)
Steven Fletcher
stevenf at shellnet.co dot uk
Date: Fri, 17 Sep 1999 19:04:49 +0200 (MET DST)
From: Carrer Yuri <yurj at dns.alfa dot it>
Subject: RE: .user.pop lock busy! Is another session active?
On Fri, 17 Sep 1999, Steven Fletcher wrote:
>
> > If the TCP connection die, why qpopper insists on keeping the damn
> > .<user>.pop around?
>
> It's a socket application - your clients probably have not just killed the
> connection, but simply stopped receiving data and timed out at their end. It
> would stay running untill either the OS's IP stack realises that it isn't
> happening any more (I'm guessing you're using Linux here, try a *BSD
> implementation instead, they have much nicer IP layers), then the connection
This is real bullshit.
> will die (or, if Qpopper has finished sending the data to the IP stack, then
> it will go and wait for its idle timer to kick in before it kills itself.
>
> So more than likley, you're relying on 3 things:
> 1) Dodgy/slow/unreliable dial-up lines
False
> 2) IP stack keeping schtum to its daemons
False
> 3) A third idle timer, qpopper's.
False
Add:
4) There's a problem somewhere.
> >Is there a patch out there to see which message
> > qpopper is sending to the user and how much % of the message it has
> > sent?
>
> Not for percentage, but use a trace file and you'll be able to see what the
> last RETR command that was sent was.
Is a compile option?
Date: Fri, 17 Sep 1999 19:13:35 +0200 (MET DST)
From: Carrer Yuri <yurj at dns.alfa dot it>
Subject: Re: Stuck pop files
> Anyone have any idea why pop files would get stuck stuck stuck for a long
> time? I have customers that call occasionally saying that they can't get
> their mail, so they disconnect, call me, and I look, and there's still a
> .username.pop file from like 5 minutes before. I can sit there and wait
> and it doesn't go away. Eventually, later in the day I check and it's
> gone.
>
http://typhaon.ucs.uwa.edu.au/switch.html
Yuri
Date: Fri, 17 Sep 1999 19:13:06 +0200 (MET DST)
From: Carrer Yuri <yurj at dns.alfa dot it>
Subject: Re: I wrote about this canonical name denial once before and have checked into some things since...
Maybe tcpwrappers?
On Fri, 17 Sep 1999, Rick Kunkel wrote:
> I get the canonical name error occasionally, which is no big deal.
> However, my users are actually KEPT from checking mail. It denies them
> when name and address don't jibe. From what I hear, it's not Qpopper
> causing the refusal, but maybe something else. I've looked everywhere I
> can think of. Any ideas of good places where some setting like that might
> hide out? We have a file in /usr/local/etc called netperm-table which
> will deny connections over various ports to people not in a list of
> addresses, but the pop port is open to everyone. I thought that would be
> the culprit, but it wasn't...Any other ideas?
>
> Rick Kunkel
>
>
Date: Sat, 18 Sep 1999 05:25:25 +1200 (NZST)
From: Alan Brown <alan at manawatu.gen dot nz>
Subject: Re: I wrote about this canonical name denial once before and have
On Fri, 17 Sep 1999, Rick Kunkel wrote:
> I get the canonical name error occasionally, which is no big deal.
> However, my users are actually KEPT from checking mail. It denies them
> when name and address don't jibe. From what I hear, it's not Qpopper
> causing the refusal, but maybe something else. I've looked everywhere I
> can think of. Any ideas of good places where some setting like that might
> hide out?
Check your tcpd hosts.allow/.deny settings for a "paranoid" entry.
AB
Date: Fri, 17 Sep 1999 13:30:49 -0400 (EDT)
From: Admin Mailing Lists <mlist at intergrafix dot net>
Subject: Re: I wrote about this canonical name denial once before and have
if you're the authority for your IP block, make sure IP->hostname and
hostname->IP resolves match. I know a lot of places that don't even
reverse resolve IPs back to hostname, what the heck, are they just lazy,
it's not that hard..speaking about the general community of course, not
you specifically.
-Cygnus
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
On Fri, 17 Sep 1999, Rick Kunkel wrote:
> I get the canonical name error occasionally, which is no big deal.
> However, my users are actually KEPT from checking mail. It denies them
> when name and address don't jibe. From what I hear, it's not Qpopper
> causing the refusal, but maybe something else. I've looked everywhere I
> can think of. Any ideas of good places where some setting like that might
> hide out? We have a file in /usr/local/etc called netperm-table which
> will deny connections over various ports to people not in a list of
> addresses, but the pop port is open to everyone. I thought that would be
> the culprit, but it wasn't...Any other ideas?
>
> Rick Kunkel
>
>
Date: Fri, 17 Sep 1999 13:49:19 -0400
From: "Marcelo dos S. Tavares" <mtavares at argo.com dot br>
Subject: Re: .user.pop lock busy! Is another session active?
> >
> > -ERR [IN-USE] /car/spool/mail/.user.pop lock busy! Is another session
> > active? (11)
> >
> > And normally I have that to remove the lock user.pop manually of the
> > mail spool.
> >
> > so.. anyone got any ideas how to resolve this problem ?
>
> Yes, dump qpopper and use another pop server.
>
> Baing seriously, there's a bad interaction somewhere between Outlook
> Express and qpopper.
OK!
Do you know another POP3 server with support hash spool ?? The mail
spool of the user is located in /var/spool/mail/u/s/user.
Example: User peter -- /var/spool/mail/p/e/peter
Old, we used CUCIPOP. But it seems does not have has supported hash spool
mail.
Very Thanks!
Date: Fri, 17 Sep 1999 13:40:11 -0400 (EDT)
From: Admin Mailing Lists <mlist at intergrafix dot net>
Subject: RE: .user.pop lock busy! Is another session active?
I posted a patch a while back for the popper.
When you connect it checks if your username has a popper process open, if
you do, popper kills the former cleanly, then automatically opens a new
one for you in the current session. Saves admins having to clean any
stale pop files.
Is there a mailing list archive around?
If not, I might still have it in my sent-mail box somewhere.
-Cygnus
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
On Fri, 17 Sep 1999, Leonard Hermens wrote:
> > > Baing seriously, there's a bad interaction somewhere between Outlook
> > > Express and qpopper.
> >
> >uuuh....Why would it matter if the POP3 client was Outlook, Agent,
> >fetchmail, or anything for that matter? POP3 is POP3, nothing will change
> >that.
> >
> >More than likely people are simply timing out and trying to connect again
> >before your server times out. I would look at Qpopper's -T option.
> >
> >Steven Fletcher
> >stevenf at shellnet.co dot uk
>
> I can confirm that Outlook clients in the past (don't know about
> version 5) have caused a hang that Eudora (for example) did not
> exhibit when downloading a large attachment or when certain header
> lines were blank. This would lead to a SIGHUP on the qpopper because
> the Outlook client did/could not exit gracefully.
>
> -- Leonard
>
Date: Fri, 17 Sep 1999 13:56:10 -0400 (EDT)
From: Admin Mailing Lists <mlist at intergrafix dot net>
Subject: RE: .user.pop lock busy! Is another session active?
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime at docserver.cac.washington dot edu for more info.
---171031142-37121570-919954547=:21504
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.9909171346362.1890 at athena.intergrafix dot net>
i found it! it's against 3.0b12, which is what I currently use here.
see below for instructions and see attached file.
-Cygnus
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
Anthony J. Biacco Network Administrator/Engineer
admin at intergrafix dot net Intergrafix Internet Services
"Dream as if you'll live forever, live as if you'll die today"
http://cygnus.ncohafmuta.com http://www.intergrafix.net
.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-.
---------- Forwarded message ----------
Date: Thu, 25 Feb 1999 09:55:47 -0500 (EST)
From: System Administrator <admin at athena.intergrafix dot net>
To: Byron Jones <byron at vianet.net dot au>
Cc: Subscribers of Qpopper <qpopper at lists.pensive dot org>
Subject: Re: qpopper not releasing lock
well, first I suggest upgrading to a 3.0 beta of qpopper, then replacing
your pop_dropcopy.c with the attached text file. and recompiling.
i've changed this source file to:
A) check for the glitch of the missing 'F' in the "From" line of the
headers
B) check for an already existing popper process and/or lock file for the
user. If a popper process exists for the user trying to retrieve their
mail, the old process will be killed, and the current process will
continue the mail retrieval. If a lock file is found, it will be unlocked
and removed, and the current process will continue the mail retrieval.
This does NOT check for GOOD retrievals..(i.e. if you start retrieving
mail from one machine, then try to retrieve on another while the first
retrieval is sitll happening, the first will be cancelled and the 2nd
started) just an FYI.
the file contains 2 extra #defines. PS_COMMAND which sets the command to
use to find the old processes. and PS_SEARCH that defines the name of the
popper process we'll search for. I use linux and the default executable
name, so mine are set to "ps ux" and "popper"
i dont make any guarantees about this hack. it should work on your system,
it works on mine in server mode, but it may not for some reason. if you
lose any mail over it, I'm not responsible. :-)
Hope it works for you.
-Cygnus
---171031142-37121570-919954547=:21504
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="pop_dropcopy.send"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9902250955470.21504 at athena.intergrafix dot net>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="pop_dropcopy.send"
LyoNCiAqIENvcHlyaWdodCAoYykgMTk4OSBSZWdlbnRzIG9mIHRoZSBVbml2
ZXJzaXR5IG9mIENhbGlmb3JuaWEuDQogKiBBbGwgcmlnaHRzIHJlc2VydmVk
LiAgVGhlIEJlcmtlbGV5IHNvZnR3YXJlIExpY2Vuc2UgQWdyZWVtZW50DQog
KiBzcGVjaWZpZXMgdGhlIHRlcm1zIGFuZCBjb25kaXRpb25zIGZvciByZWRp
c3RyaWJ1dGlvbi4NCiAqLw0KDQovKg0KICogQ29weXJpZ2h0IChjKSAxOTk4
IFF1YWxjb21tIEluY29ycG9yYXRlZC4gQWxsIHJpZ2h0cyByZXNlcnZlZC4N
CiAqDQogKiBSZXZpc2lvbnMgOiANCiAqICA2LzIyLzk4ICBbcHldDQogKiAg
ICAgICAgIC0gQWRkZWQga2x1ZGdlIGZvciBOVUxMcyBpbiBtZXNzYWdlIGNv
bnRlbnQoc3VnZ2VzdGVkIGJ5IA0KICogICAgICAgICAgIE1vcmRlY2hhaSBU
LkFienVnKS4NCiAqICAgICAgICAgICBVaWRsIHRvIGNvbnRhaW4gRnJvbSBF
bnZlbG9wZSBpbiBub24tbW1kZiwgYW5kIGxlbmd0aCBjaGVjay4NCiAqICAz
LzE4Lzk4ICBbcHldDQogKiAgICAgICAgIC0gUmV2aWV3ZWQgdGhlIGNvZGUs
IGFkZGVkIERFQlVHIG1hY3JvcywgY29ycmVjdGVkIHRoZSANCiAqICAgICAg
ICAgICAgcmVzb3VyY2VzIHRoYXQgYXJlIG5vdCBjbG9zZWQuDQogKi8NCg0K
LyoNCiAqIFdoZW4gYWRkaW5nIGVhY2ggbGluZSBsZW5ndGggaW50byB0aGUg
c2l6ZSBvZiB0aGUgbWVzc2FnZSBhbmQgdGhlIG1haWxkcm9wLA0KICogaW5j
cmVhc2UgdGhlIGNoYXJhY3RlciBjb3VudCBieSBvbmUgZm9yIHRoZSA8Y3I+
IGFkZGVkIHdoZW4gc2VuZGluZyB0aGUNCiAqIG1lc3NhZ2UgdG8gdGhlIG1h
aWwgY2xpZW50LiAgQWxsIGxpbmVzIHNlbnQgdG8gdGhlIGNsaWVudCBhcmUg
dGVybWluYXRlZA0KICogd2l0aCBhIDxjcj48bGY+Lg0KICovDQoNCiNpbmNs
dWRlIDxjb25maWcuaD4NCg0KI2luY2x1ZGUgPGVycm5vLmg+DQojaW5jbHVk
ZSA8c3RkaW8uaD4NCiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiNpbmNsdWRl
IDxjdHlwZS5oPg0KI2luY2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUgPGZs
b2NrLmg+DQoNCiNpZiBIQVZFX1VOSVNURF9IDQojIGluY2x1ZGUgPHVuaXN0
ZC5oPg0KI2VuZGlmDQoNCiNpZiBIQVZFX1NZU19VTklTVERfSA0KIyBpbmNs
dWRlIDxzeXMvdW5pc3RkLmg+DQojZW5kaWYNCg0KI2lmbmRlZiBIQVZFX0lO
REVYDQojICBkZWZpbmUJaW5kZXgocyxjKQkJc3RyY2hyKHMsYykNCiMgIGRl
ZmluZQlyaW5kZXgocyxjKQkJc3RycmNocihzLGMpDQojIGVuZGlmDQojaWYg
SEFWRV9TVFJJTkdTX0gNCiMgaW5jbHVkZSA8c3RyaW5ncy5oPg0KI2VuZGlm
DQojaW5jbHVkZSA8c3lzL3N0YXQuaD4NCiNpbmNsdWRlIDxzeXMvZmlsZS5o
Pg0KI2luY2x1ZGUgPHB3ZC5oPg0KI2luY2x1ZGUgPHBvcHBlci5oPg0KDQoj
aWZkZWYgTUFJTE9DSw0KIyBpZmRlZiBIQVZFX01BSUxMT0NLDQojICBpbmNs
dWRlIDxtYWlsbG9jay5oPg0KIyBlbmRpZg0KIyBkZWZpbmUgTUFJTFVOTE9D
SygpIG1haWx1bmxvY2soKQ0KI2Vsc2UgDQojIGRlZmluZSBNQUlMVU5MT0NL
KCkNCiNlbmRpZg0KDQojZGVmaW5lIE1JTl9VSURMX0xFTkdUSCA1ICAgICAv
KiBUaGVyZSBpcyBubyBwYXJ0aWN1bGFyIHJlYXNvbiB0byBoYXZlIHRoaXMg
Ki8NCiNkZWZpbmUgTUFYX1VJRExfTEVOR1RIIDcwDQoNCi8qIFRoaXMgbWFj
cm8gY29tZXMgZnJvbSBNYXJrIENyaXNwaW4ncyBjLWNsaWVudCBjb2RlICov
DQoNCi8qIFZhbGlkYXRlIGxpbmUNCiAqIEFjY2VwdHM6IHBvaW50ZXIgdG8g
Y2FuZGlkYXRlIHN0cmluZyB0byB2YWxpZGF0ZSBhcyBhIEZyb20gaGVhZGVy
DQogKgkgICAgcmV0dXJuIHBvaW50ZXIgdG8gZW5kIG9mIGRhdGUvdGltZSBm
aWVsZA0KICoJICAgIHJldHVybiBwb2ludGVyIHRvIG9mZnNldCBmcm9tIHQg
b2YgdGltZSAoaG91cnMgb2YgYGBtbW0gZGQgaGg6bW0nJykNCiAqCSAgICBy
ZXR1cm4gcG9pbnRlciB0byBvZmZzZXQgZnJvbSB0IG9mIHRpbWUgem9uZSAo
aWYgbm9uLXplcm8pDQogKiBSZXR1cm5zOiB0LHRpLHpuIHNldCBpZiB2YWxp
ZCBGcm9tIHN0cmluZywgZWxzZSB0aSBpcyBOSUwNCiAqLw0KDQojZGVmaW5l
IFBTX0NPTU1BTkQJInBzIHV4IgkvKiB0aGlzIGNvbW1hbmQgaXMgcnVuIGFz
IHRoZSB1c2VybmFtZSAqLw0KCQkJCS8qIGFuZCBzaG91bGQgc2hvdyBwcm9j
ZXNzIG5hbWVzLHBpZHMsICovDQoJCQkJLyogYW5kIHRoZSBwcm9jZXNzIG93
bmVyCSAgICAgICAqLw0KCQkJCS8qIHBzIHV4IHdvcmtzIGZvciBsaW51eCBm
b3Igc3VyZSAgICAgICovDQojZGVmaW5lIFBTX1NFQVJDSAkicG9wcGVyIiAv
KiBuYW1lIHRoZSBwb3BwZXIgcHJvY2VzcyBydW5zIGFzICAgICovDQoJCQkJ
IC8qIGFzIHNob3duIGluIHRoZSBwcm9jZXNzIGxpc3QgICAgICAgKi8NCnZv
aWQgY2xlYXJfb2xkKFBPUCAqcCk7DQoNCiNkZWZpbmUgVkFMSUQocyx4LHRp
LHpuKSB7CQkJCQkJXA0KICB0aSA9IDA7CQkJCQkJCQlcDQogIGlmICgoKnMg
PT0gJ0YnKSAmJiAoc1sxXSA9PSAncicpICYmIChzWzJdID09ICdvJykgJiYg
KHNbM10gPT0gJ20nKSAmJglcDQogICAgICAoc1s0XSA9PSAnICcpKSB7CQkJ
CQkJCVwNCiAgICBmb3IgKHggPSBzICsgNTsgKnggJiYgKnggIT0gJ1xuJzsg
eCsrKTsJCQkJXA0KICAgIGlmICh4KSB7CQkJCQkJCQlcDQogICAgICBpZiAo
eCAtIHMgPj0gNDEpIHsJCQkJCQlcDQoJZm9yICh6biA9IC0xOyB4W3puXSAh
PSAnICc7IHpuLS0pOwkJCQlcDQoJaWYgKCh4W3puLTFdID09ICdtJykgJiYg
KHhbem4tMl0gPT0gJ28nKSAmJiAoeFt6bi0zXSA9PSAncicpICYmCVwNCgkg
ICAgKHhbem4tNF0gPT0gJ2YnKSAmJiAoeFt6bi01XSA9PSAnICcpICYmICh4
W3puLTZdID09ICdlJykgJiYJXA0KCSAgICAoeFt6bi03XSA9PSAndCcpICYm
ICh4W3puLThdID09ICdvJykgJiYgKHhbem4tOV0gPT0gJ20nKSAmJglcDQoJ
ICAgICh4W3puLTEwXSA9PSAnZScpICYmICh4W3puLTExXSA9PSAncicpICYm
ICh4W3puLTEyXSA9PSAnICcpKVwNCgkgIHggKz0gem4gLSAxMjsJCQkJCQkJ
XA0KICAgICAgfQkJCQkJCQkJCVwNCiAgICAgIGlmICh4IC0gcyA+PSAyNykg
ewkJCQkJCVwNCglpZiAoeFstNV0gPT0gJyAnKSB7CQkJCQkJXA0KCSAgaWYg
KHhbLThdID09ICc6Jykgem4gPSAwLHRpID0gLTU7CQkJCVwNCgkgIGVsc2Ug
aWYgKHhbLTldID09ICcgJykgdGkgPSB6biA9IC05OwkJCQlcDQoJICBlbHNl
IGlmICgoeFstMTFdID09ICcgJykgJiYgKCh4Wy0xMF09PScrJykgfHwgKHhb
LTEwXT09Jy0nKSkpCVwNCgkgICAgdGkgPSB6biA9IC0xMTsJCQkJCQlcDQoJ
fQkJCQkJCQkJXA0KCWVsc2UgaWYgKHhbLTRdID09ICcgJykgewkJCQkJXA0K
CSAgaWYgKHhbLTldID09ICcgJykgem4gPSAtNCx0aSA9IC05OwkJCQlcDQoJ
fQkJCQkJCQkJXA0KCWVsc2UgaWYgKHhbLTZdID09ICcgJykgewkJCQkJXA0K
CSAgaWYgKCh4Wy0xMV0gPT0gJyAnKSAmJiAoKHhbLTVdID09ICcrJykgfHwg
KHhbLTVdID09ICctJykpKQlcDQoJICAgIHpuID0gLTYsdGkgPSAtMTE7CQkJ
CQkJXA0KCX0JCQkJCQkJCVwNCglpZiAodGkgJiYgISgoeFt0aSAtIDNdID09
ICc6JykgJiYJCQkJXA0KCQkgICAgKHhbdGkgLT0gKCh4W3RpIC0gNl0gPT0g
JzonKSA/IDkgOiA2KV0gPT0gJyAnKSAmJglcDQoJCSAgICAoeFt0aSAtIDNd
ID09ICcgJykgJiYgKHhbdGkgLSA3XSA9PSAnICcpICYmCQlcDQoJCSAgICAo
eFt0aSAtIDExXSA9PSAnICcpKSkgdGkgPSAwOwkJCVwNCiAgICAgIH0JCQkJ
CQkJCQlcDQogICAgfQkJCQkJCQkJCVwNCiAgfQkJCQkJCQkJCVwNCiAgZWxz
ZSBpZiAoKCpzID09ICdyJykgJiYgKHNbMV0gPT0gJ28nKSAmJiAoc1syXSA9
PSAnbScpICYmIChzWzNdID09ICcgJykpIHsJXA0KICAgIGZvciAoeCA9IHMg
KyA0OyAqeCAmJiAqeCAhPSAnXG4nOyB4KyspOwkJCQlcDQogICAgaWYgKHgp
IHsJCQkJCQkJCVwNCiAgICAgIGlmICh4IC0gcyA+PSA0MSkgewkJCQkJCVwN
Cglmb3IgKHpuID0gLTE7IHhbem5dICE9ICcgJzsgem4tLSk7CQkJCVwNCglp
ZiAoKHhbem4tMV0gPT0gJ20nKSAmJiAoeFt6bi0yXSA9PSAnbycpICYmICh4
W3puLTNdID09ICdyJykgJiYJXA0KCSAgICAoeFt6bi00XSA9PSAnZicpICYm
ICh4W3puLTVdID09ICcgJykgJiYgKHhbem4tNl0gPT0gJ2UnKSAmJglcDQoJ
ICAgICh4W3puLTddID09ICd0JykgJiYgKHhbem4tOF0gPT0gJ28nKSAmJiAo
eFt6bi05XSA9PSAnbScpICYmCVwNCgkgICAgKHhbem4tMTBdID09ICdlJykg
JiYgKHhbem4tMTFdID09ICdyJykgJiYgKHhbem4tMTJdID09ICcgJykpXA0K
CSAgeCArPSB6biAtIDEyOwkJCQkJCQlcDQogICAgICB9CQkJCQkJCQkJXA0K
ICAgICAgaWYgKHggLSBzID49IDI3KSB7CQkJCQkJXA0KCWlmICh4Wy01XSA9
PSAnICcpIHsJCQkJCQlcDQoJICBpZiAoeFstOF0gPT0gJzonKSB6biA9IDAs
dGkgPSAtNTsJCQkJXA0KCSAgZWxzZSBpZiAoeFstOV0gPT0gJyAnKSB0aSA9
IHpuID0gLTk7CQkJCVwNCgkgIGVsc2UgaWYgKCh4Wy0xMV0gPT0gJyAnKSAm
JiAoKHhbLTEwXT09JysnKSB8fCAoeFstMTBdPT0nLScpKSkJXA0KCSAgICB0
aSA9IHpuID0gLTExOwkJCQkJCVwNCgl9CQkJCQkJCQlcDQoJZWxzZSBpZiAo
eFstNF0gPT0gJyAnKSB7CQkJCQlcDQoJICBpZiAoeFstOV0gPT0gJyAnKSB6
biA9IC00LHRpID0gLTk7CQkJCVwNCgl9CQkJCQkJCQlcDQoJZWxzZSBpZiAo
eFstNl0gPT0gJyAnKSB7CQkJCQlcDQoJICBpZiAoKHhbLTExXSA9PSAnICcp
ICYmICgoeFstNV0gPT0gJysnKSB8fCAoeFstNV0gPT0gJy0nKSkpCVwNCgkg
ICAgem4gPSAtNix0aSA9IC0xMTsJCQkJCQlcDQoJfQkJCQkJCQkJXA0KCWlm
ICh0aSAmJiAhKCh4W3RpIC0gM10gPT0gJzonKSAmJgkJCQlcDQoJCSAgICAo
eFt0aSAtPSAoKHhbdGkgLSA2XSA9PSAnOicpID8gOSA6IDYpXSA9PSAnICcp
ICYmCVwNCgkJICAgICh4W3RpIC0gM10gPT0gJyAnKSAmJiAoeFt0aSAtIDdd
ID09ICcgJykgJiYJCVwNCgkJICAgICh4W3RpIC0gMTFdID09ICcgJykpKSB0
aSA9IDA7CQkJXA0KICAgICAgfQkJCQkJCQkJCVwNCiAgICB9CQkJCQkJCQkJ
XA0KICB9CQkJCQkJCQkJXA0KfQ0KDQovKiBZb3UgYXJlIG5vdCBleHBlY3Rl
ZCB0byB1bmRlcnN0YW5kIHRoaXMgbWFjcm8sIGJ1dCByZWFkIHRoZSBuZXh0
IHBhZ2UgaWYNCiAqIHlvdSBhcmUgbm90IGZhaW50IG9mIGhlYXJ0Lg0KICoN
CiAqIEtub3duIGZvcm1hdHMgdG8gdGhlIFZBTElEIG1hY3JvIGFyZToNCiAq
IAkJRnJvbSB1c2VyIFdlZCBEZWMgIDIgMDU6NTMgMTk5Mg0KICogQlNECQlG
cm9tIHVzZXIgV2VkIERlYyAgMiAwNTo1MzoyMiAxOTkyDQogKiBTeXNWCQlG
cm9tIHVzZXIgV2VkIERlYyAgMiAwNTo1MyBQU1QgMTk5Mg0KICogcm4JCUZy
b20gdXNlciBXZWQgRGVjICAyIDA1OjUzOjIyIFBTVCAxOTkyDQogKgkJRnJv
bSB1c2VyIFdlZCBEZWMgIDIgMDU6NTMgLTA3MDAgMTk5Mg0KICoJCUZyb20g
dXNlciBXZWQgRGVjICAyIDA1OjUzOjIyIC0wNzAwIDE5OTINCiAqCQlGcm9t
IHVzZXIgV2VkIERlYyAgMiAwNTo1MyAxOTkyIFBTVA0KICoJCUZyb20gdXNl
ciBXZWQgRGVjICAyIDA1OjUzOjIyIDE5OTIgUFNUDQogKgkJRnJvbSB1c2Vy
IFdlZCBEZWMgIDIgMDU6NTMgMTk5MiAtMDcwMA0KICogU29sYXJpcwlGcm9t
IHVzZXIgV2VkIERlYyAgMiAwNTo1MzoyMiAxOTkyIC0wNzAwDQogKg0KICog
UGx1cyBhbGwgb2YgdGhlIGFib3ZlIHdpdGggYGAgcmVtb3RlIGZyb20geHh4
JycgYWZ0ZXIgaXQuIFRoYW5rIHlvdSB2ZXJ5DQogKiBtdWNoLCBzbWFpbCBh
bmQgU29sYXJpcywgZm9yIG1ha2luZyBteSBsaWZlIGNvbnNpZGVyYWJseSBt
b3JlIGNvbXBsaWNhdGVkLg0KICovDQoNCg0KaW50IG5ld2xpbmUgPSAxOw0K
DQovKg0KICogIDAgZm9yIG5vdCBhIGZyb20gbGluZQ0KICogIDEgZm9yIGlz
IGEgZnJvbSBsaW5lDQogKi8NCg0KLyogVmFsaWQgVVVDUCBGcm9tIGxpbmVz
Og0KICoNCiAqCUZyb20gQWRkcmVzcyBbdHR5XSBkYXRlDQogKglGcm9tIFt0
dHldIGRhdGUNCiAqDQogKgkiRnJvbSBbdHR5XSBkYXRlIiBpcyBwcm9iYWJs
eSB2YWxpZCBidXQgSSdtIHRvbyBsYXp5IGF0IHRoaXMNCiAqCXRpbWUgdG8g
YWRkIHRoZSBjb2RlLg0KICoNCiAqLw0KaW50DQppc2Zyb21saW5lKGNwKQ0K
Y2hhcgkqY3A7DQp7DQogICAgaW50IHRpLCB6bjsNCiAgICBjaGFyICp4Ow0K
DQogICAgLyogSWYgdGhlIHByZXZpb3VzIGxpbmUgd2FzIG5vdCBhIG5ld2xp
bmUgdGhlbiBqdXN0IHJldHVybiAqLw0KICAgIC8qIEZyb20gbWVzc2FnZSBz
ZXBhcmF0b3JzIGFyZSBwcmVjZWVkZWQgYnkgYSBuZXdsaW5lICovIA0KICAg
IGlmICgqY3AgPT0gJ1xuJykgew0KCW5ld2xpbmUgPSAxOw0KCXJldHVybigw
KTsNCiAgICB9IGVsc2UgaWYgKCFuZXdsaW5lKSB7DQoJcmV0dXJuKDApOw0K
ICAgIH0gZWxzZQ0KCW5ld2xpbmUgPSAwOw0KDQogICAgVkFMSUQoY3AsIHgs
IHRpLCB6bik7DQogICAgcmV0dXJuKHRpICE9IDApOw0KfQ0KDQoNCi8qDQog
KiBCYXNlIDgwIGVuY29kaW5nIG9mIDE2Ynl0ZSBNRDUgaGFzaC4gVGhpcyBp
cyBhYm91dCB0aGUgc21hbGxlcyBlbmNvZGluZw0KICogcG9zc2libGUgZm9y
IHRoZSBNRDUgaGFzaCB1c2luZyB0aGUgY2hhcnMgYWxsb3dlZCBmb3IgVUlE
THMuIA0KICogKDkzIEFTQ0lJIHZhbHVlcyBhcmUgYXZhaWxhYmxlIGFuZCAx
OV45MyA8IDJeMTI4IDwgMjBeOTMpDQogKiBUaGlzIGltcGxlbWVudGF0aW9u
IGlzbid0IGV4YWN0IGFib3V0IE1TQnMgYW5kIExTQiwgYnV0IGl0IGlzIHVu
aXF1ZS4uDQogKi8NCg0KY2hhciAqYmFzZTgwKGNoYXIgKm91dHB1dCwgY2hh
ciAqZGlnZXN0KQ0Kew0KICB1bnNpZ25lZCBsb25nIHYsIG4sIGo7DQogIGlu
dCBpLCBrOw0KDQogIGZvcihpID0gMCA7IGkgPCAxNjsgKSB7DQogICAgdiA9
IDBMOw0KICAgIGRvIHsNCiAgICAgIHYgPSAodiA8PCA0KSArIGRpZ2VzdFtp
KytdOw0KICAgIH0gd2hpbGUoaSU0KTsNCiAgICBmb3IoayA9IDA7IGsgPCA1
OyBrKyspIHsNCiAgICAgIGogPSB2ICUgODA7DQogICAgICB2ID0gKHYgLSBq
KS84MDsNCiAgICAgICpvdXRwdXQgPSAweDIxICsgajsNCiAgICAgIC8qIEF2
b2lkIC4gYWx0Z290aGVyIHRvIGF2b2lkIGhhdmluZyB0byBzdHVmZiBpdCAq
Lw0KICAgICAgaWYoKm91dHB1dCA9PSAnLicpDQogICAgICAgICpvdXRwdXQg
PSAnfic7DQogICAgICBvdXRwdXQrKzsNCiAgICB9DQogIH0NCiAgKm91dHB1
dCA9ICdcMCc7DQogIHJldHVybihvdXRwdXQpOw0KfQ0KDQoNCg0KLyogSGFz
aGluZyB0byBhIHNwb29sIGRpcmVjdG9yeSBoZWxwcyByZWR1Y2UgdGhlIGxv
b2t1cCB0aW1lIGZvciBzaXRlcw0KICogd2l0aCB0aG91c2FuZHMgb2YgbWFp
bCBzcG9vbCBmaWxlcy4gIFVuaXggdXNlcyBhIGxpbmVhciBsaXN0IHRvDQog
KiBzYXZlIGRpcmVjdG9yeSBpbmZvcm1hdGlvbiBhbmQgdGhlIGZvbGxvd2lu
ZyBtZXRob2RzIGF0dGVtcHQgdG8NCiAqIGltcHJvdmUgdGhlIHBlcmZvcm1h
bmNlLg0KICoNCiAqIE1ldGhvZCAxIC0gYWRkIHRoZSB2YWx1ZSBvZiB0aGUg
Zmlyc3QgNCBjaGFycyBtb2QgMjYgYW5kIG9wZW4gdGhlDQogKgkgICAgICBz
cG9vbCBmaWxlIGluIHRoZSBkaXJlY3RvcnkgJ2EnIC0gJ3onL3VzZXIuDQog
KgkgICAgICBCcmlhbiBCdWhyb3cgPGJ1aHJvd0BjYXRzLnVjc2MuZWR1Pg0K
ICoNCiAqIE1ldGhvZCAyIC0gVXNlIHRoZSBmaXJzdCAyIGNoYXJhY3RlcnMg
dG8gZGV0ZXJtaW5lIHdoaWNoIG1haWwgc3Bvb2wNCiAqCSAgICAgIHRvIG9w
ZW4uICBFZzogL3Vzci9zcG9vbC91L3MvdXNlci4NCiAqCSAgICAgIExhcnJ5
IFNjaHdpbW1lciA8cm9zZWJ1ZEBjeWNsb25lLnN0YW5mb3JkLmVkdT4NCiAq
DQogKiBBbGwgdGhlc2UgbWV0aG9kcyByZXF1aXJlIHRoYXQgbG9jYWwgbWFp
bCBkZWxpdmVyeSBhbmQgY2xpZW50IHByb2dyYW1zDQogKiB1c2UgdGhlIHNh
bWUgYWxnb3JpdGhtLiAgT25seSBvbmUgbWV0aG9kIHRvIGEgY3VzdG9tZXIg
Oi0pDQogKi8NCg0KI2lmIChIQVNIX1NQT09MID09IDEpDQoNCmludA0KZ2Vu
cGF0aChwKQ0KUE9QICpwOw0Kew0KICAgIGludCBzZWVkID0gMDsNCiAgICBj
aGFyIGRpcmNoYXJbNF07DQoNCiAgICBpZiAoIXAtPnVzZXIgfHwgKnAtPnVz
ZXIgPT0gJ1wwJykNCglyZXR1cm4oTlVMTCk7IC8qYm9ndXMgbG9naW4gbmFt
ZSovDQoNCiAgICAvKk5vdywgcGVyZm9ybSB0aGUgaGFzaCovDQoNCiAgICBz
d2l0Y2goc3RybGVuKHAtPnVzZXIpKSB7DQoJICAgY2FzZSAxOg0KCSAgIHNl
ZWQgPSAocC0+dXNlclswXSk7DQoJICAgYnJlYWs7DQoJICAgY2FzZSAyOg0K
CSAgIHNlZWQgPSAocC0+dXNlclswXSArIHAtPnVzZXJbMV0pOw0KCSAgIGJy
ZWFrOw0KCSAgIGNhc2UgMzoNCgkgICBzZWVkID0gKHAtPnVzZXJbMF0gKyBw
LT51c2VyWzFdICsgcC0+dXNlclsyXSk7DQoJICAgYnJlYWs7DQoJICAgY2Fz
ZSA0Og0KCSAgIHNlZWQgPSAocC0+dXNlclswXSArIHAtPnVzZXJbMV0gKyBw
LT51c2VyWzJdK3AtPnVzZXJbM10pOw0KCSAgIGJyZWFrOw0KCSAgIGRlZmF1
bHQ6DQoJICAgc2VlZCA9IChwLT51c2VyWzBdICsgcC0+dXNlclsxXSArIHAt
PnVzZXJbMl0rcC0+dXNlclszXStwLT51c2VyWzRdKTsNCgkgICBicmVhazsN
CiAgICB9DQogICAgZGlyY2hhclswXSA9ICcvJzsNCiAgICBkaXJjaGFyWzFd
ID0gKGNoYXIpKChzZWVkICUgMjYpICsgJ2EnKTsNCiAgICBkaXJjaGFyWzJd
ID0gJy8nOw0KICAgIGRpcmNoYXJbM10gPSAnXDAnOw0KICAgIHN0cm5jcHko
cC0+ZHJvcF9uYW1lLCBQT1BfTUFJTERJUiwgc2l6ZW9mKHAtPmRyb3BfbmFt
ZSkpOw0KICAgIHN0cm5jYXQocC0+ZHJvcF9uYW1lLCBkaXJjaGFyLCBzaXpl
b2YocC0+ZHJvcF9uYW1lKSAtIHN0cmxlbihwLT5kcm9wX25hbWUpKTsNCiAg
ICBzdHJuY2F0KHAtPmRyb3BfbmFtZSwgcC0+dXNlciwgc2l6ZW9mKHAtPmRy
b3BfbmFtZSkgLSBzdHJsZW4ocC0+ZHJvcF9uYW1lKSk7DQoNCiAgICByZXR1
cm4oMSk7DQp9DQoNCiNlbmRpZg0KI2lmIChIQVNIX1NQT09MID09IDIpDQoN
CmludA0KZ2VucGF0aChwKQ0KUE9QICpwOw0Kew0KICAgIHN0YXRpYyBjaGFy
IHBhdGhzdHJbMjU2XTsNCg0KICAgIGlmICghcC0+dXNlciB8fCAqcC0+dXNl
ciA9PSAnXDAnKQ0KCXJldHVybihOVUxMKTsNCiAgICANCiAgICBzcHJpbnRm
KHBhdGhzdHIsICIvJWMvJWMvJXMiLA0KCQkgICAgKnAtPnVzZXIsICoocC0+
dXNlcisxKSA/ICoocC0+dXNlcisxKSA6ICpwLT51c2VyLCBwLT51c2VyKTsN
Cg0KICAgIHN0cm5jcHkocC0+ZHJvcF9uYW1lLCBQT1BfTUFJTERJUiwgc2l6
ZW9mKHAtPmRyb3BfbmFtZSkpOw0KICAgIHN0cm5jYXQocC0+ZHJvcF9uYW1l
LCBwYXRoc3RyLCBzaXplb2YocC0+ZHJvcF9uYW1lKSAtIHN0cmxlbihwLT5k
cm9wX25hbWUpKTsNCg0KICAgIHJldHVybigxKTsNCn0NCg0KI2VuZGlmDQoj
aWYgKEhBU0hfU1BPT0wgIT0gMSAmJiBIQVNIX1NQT09MICE9IDIpDQoNCmlu
dA0KZ2VucGF0aChwKQ0KUE9QICpwOw0Kew0KICAgIHN0cnVjdCBwYXNzd2Qg
KnB3cDsNCg0KI2lmZGVmIEhPTUVESVJNQUlMDQogICAgaWYgKChwd3AgPSBn
ZXRwd25hbShwLT51c2VyKSkgPT0gTlVMTCkgew0KCXBvcF9sb2cocCwgUE9Q
X0ZBSUxVUkUsICJ1bmFibGUgdG8gcmV0cmlldmUgdXNlcnMgcGFzc3dvcmQg
ZW50cnkiKTsNCglyZXR1cm4oLTEpOw0KICAgIH0NCiAgICBzdHJuY3B5KHAt
PmRyb3BfbmFtZSwgcHdwLT5wd19kaXIsIHNpemVvZihwLT5kcm9wX25hbWUp
KTsNCiAgICBzdHJuY2F0KHAtPmRyb3BfbmFtZSwgIi8ubWFpbCIsc2l6ZW9m
KHAtPmRyb3BfbmFtZSkgLSBzdHJsZW4ocC0+ZHJvcF9uYW1lKSk7DQojZWxz
ZQ0KICAgIHN0cm5jcHkocC0+ZHJvcF9uYW1lLCBQT1BfTUFJTERJUiwgc2l6
ZW9mKHAtPmRyb3BfbmFtZSkpOw0KICAgIHN0cm5jYXQocC0+ZHJvcF9uYW1l
LCAiLyIsIHNpemVvZihwLT5kcm9wX25hbWUpIC0gc3RybGVuKHAtPmRyb3Bf
bmFtZSkpOw0KICAgIHN0cm5jYXQocC0+ZHJvcF9uYW1lLCBwLT51c2VyLCBz
aXplb2YocC0+ZHJvcF9uYW1lKSAtIHN0cmxlbihwLT5kcm9wX25hbWUpKTsN
CiNlbmRpZg0KDQogICAgcmV0dXJuKDEpOw0KfQ0KDQojZW5kaWYgLyogSEFT
SF9TUE9PTCAqLw0KDQogIA0KDQovKiANCiAqIEJ1aWxkIHRoZSBNc2dfaW5m
b19saXN0IGZyb20gdGhlIHRlbXBfZHJvcCBpbiBjYXNlIHRoZSBwcmV2aW91
cyBzZXNzaW9uDQogKiBmYWlsZWQgdG8gdHJ1bmNhdGUuIGluaXRfZHJvcGlu
Zm8gYW5kIGRvX2Ryb3BfY29weSBkaWZmZXIgaW4gdGhhdA0KICogZG9fZHJv
cF9jb3B5IHdvdWxkIGNvcHkgYWxsIHRoZSBtZXNzYWdlcyBmcm9tIHNvdXJj
ZSBmaWxlIHRvIGRlc3RpbmF0aW9uDQogKiBmaWxlIHdoaWxlIGl0IGdlbmVy
YXRlcyB0aGUgTXNnX2luZm9fbGlzdC4NCiAqLw0KaW50IGluaXRfZHJvcGlu
Zm8ocCkNClBPUCAqcDsNCnsNCiAgICBNc2dJbmZvTGlzdCAgICAgICAgICog
ICBtcDsgICAgICAgICAvKiBQb2ludGVyIHRvIG1lc3NhZ2UgaW5mbyBsaXN0
ICovDQogICAgaW50CQkJICAgIG1zZ19udW07CS8qIEN1cnJlbnQgbWVzc2Fn
ZSBudW1iZXIgKi8NCiAgICBpbnQJCQkgICAgbmNoYXI7DQogICAgaW50CQkJ
ICAgIGluaGVhZGVyOw0KICAgIGludAkJCSAgICB1aWRsX2ZvdW5kOw0KICAg
IGludAkJCSAgICBleHBlY3RpbmdfdHJhaWxlcjsNCiAgICBpbnQJCQkgICAg
Y29udGVudF9sZW5ndGgsIGNvbnRlbnRfbmNoYXIsIGNvbnRfbGVuOw0KICAg
IGNoYXIgICAgICAgICAgICAgICAgICAgIGJ1ZmZlcltNQVhMSU5FTEVOXTsJ
CS8qICBSZWFkIGJ1ZmZlciAqLw0KICAgIGNoYXIgICAgICAgICAgICAgICAg
ICAgIGZyb21idWZbTUFYTElORUxFTl07ICAgICAgICAvKiBGcm9tIEVudmVs
b3BlIG9mIGVhY2gNCgkJCQkJCQkgKiBtZXNzYWdlIGlzIHNhdmVkLCBmb3IN
CgkJCQkJCQkgKiBhZGRpbmcgaXQgdG8gVUlETA0KCQkJCQkJCSAqIGNvbXB1
dGF0aW9uICovDQogICAgTUQ1X0NUWAkJICAgIG1kQ29udGV4dDsNCiAgICB1
bnNpZ25lZCBjaGFyCSAgICBkaWdlc3RbMTZdOw0KICAgIGxvbmcgdW5pcXVl
X251bSA9IHRpbWUoMCk7DQoNCiAgICBERUJVR19MT0cxKHAsIkRST1BJTkZP
IENoZWNraW5nIGZvciBvbGQgLiVzLnBvcCBmaWxlIiwgcC0+dXNlcik7DQoN
Cg0KI2lmZGVmIE5VTExLTFVER0UNCiAgICB7DQoJLyogRWF0IE5VTExzIGF0
IHRoZSBiZWdpbm5pbmcgb2YgdGhlIG1haWxzcG9vbCAqLw0KCWNoYXIgdGVt
cGNoYXI7DQoJd2hpbGUgKCh0ZW1wY2hhciA9IGdldGMocC0+ZHJvcCkpID09
IDApOw0KCXVuZ2V0Yyh0ZW1wY2hhciwgcC0+ZHJvcCk7DQogICAgfQ0KI2Vu
ZGlmDQoNCiAgICBpZiAobWZnZXRzKGJ1ZmZlciwgTUFYTVNHTElORUxFTiwg
cC0+ZHJvcCkgPT0gTlVMTCkgew0KCURFQlVHX0xPRzEocCwgIkRyb3AgZmls
ZSBlbXB0eSBpbnRpYWxseSA6ICVzIiwgcC0+dGVtcF9kcm9wKTsNCglyZXR1
cm4oUE9QX1NVQ0NFU1MpOyAgICANCiAgICB9DQoNCiAgICAvKiBJcyB0aGlz
IGFuIE1NREYgZmlsZT8gKi8NCiAgICBpZiAoKmJ1ZmZlciA9PSBNTURGX1NF
UF9DSEFSKSB7DQoJcC0+bW1kZl9zZXBhcmF0b3IgPSAoY2hhciAqKXN0cmR1
cChidWZmZXIpOw0KICAgIH0gZWxzZSBpZiAoIWlzZnJvbWxpbmUoYnVmZmVy
KSkgew0KCXJldHVybiBwb3BfbXNnIChwLFBPUF9GQUlMVVJFLA0KCSAgIlVu
YWJsZSB0byBwcm9jZXNzIEZyb20gbGluZXMgKGVudmVsb3BlcykgaW4gJXMu
IixwLT50ZW1wX2Ryb3ApOw0KICAgIH0NCg0KICAgIG5ld2xpbmUgPSAxOw0K
ICAgIHJld2luZChwLT5kcm9wKTsNCg0KICAgIGluaGVhZGVyID0gMDsNCiAg
ICBtc2dfbnVtID0gMDsNCiAgICB1aWRsX2ZvdW5kID0gMDsNCiAgICBleHBl
Y3RpbmdfdHJhaWxlciA9IDA7DQogICAgY29udGVudF9sZW5ndGggPSAwOw0K
ICAgIGNvbnRlbnRfbmNoYXIgPSAwOw0KICAgIGNvbnRfbGVuID0gMDsNCiAg
ICBwLT5tc2dfY291bnQgPSBBTExPQ19NU0dTOw0KDQoNCiNpZmRlZiBOVUxM
S0xVREdFDQogICAgew0KCS8qIEVhdCBOVUxMcyBhdCB0aGUgYmVnaW5uaW5n
IG9mIHRoZSBtYWlsc3Bvb2wgKi8NCgljaGFyIHRlbXBjaGFyOw0KCXdoaWxl
ICgodGVtcGNoYXIgPSBnZXRjKHAtPmRyb3ApKSA9PSAwKTsNCgl1bmdldGMo
dGVtcGNoYXIsIHAtPmRyb3ApOw0KICAgIH0NCiNlbmRpZg0KDQogICAgREVC
VUdfTE9HMShwLCJCdWlsZGluZyB0aGUgTWVzc2FnZSBJbmZvcm1hdGlvbiBs
aXN0IGZyb20gJXMiLHAtPnRlbXBfZHJvcCk7DQoNCiAgICBmb3IgKG1wPXAt
Pm1scCAtIDE7IG1mZ2V0cyhidWZmZXIsIE1BWE1TR0xJTkVMRU4sIHAtPmRy
b3ApOykgew0KCW5jaGFyID0gc3RybGVuKGJ1ZmZlcik7DQoNCglpZiAoKGNv
bnRlbnRfbmNoYXIgPj0gY29udGVudF9sZW5ndGgpICYmDQoJICAgIChwLT5t
bWRmX3NlcGFyYXRvciA/ICFzdHJjbXAocC0+bW1kZl9zZXBhcmF0b3IsIGJ1
ZmZlcikgOg0KCSAgICBpc2Zyb21saW5lKGJ1ZmZlcikpKSB7DQogICAgICAg
ICAgICAvKiAtLS0tIEEgbWVzc2FnZSBib3VuZGFyeSAtLS0tLSAqLw0KICAg
ICAgICAgICAgLyogLS0tLSBUaWR5IHVwIHByZXZpb3VzIG1lc3NhZ2UgKGlm
IHRoZXJlIHdhcyBvbmUpIC0tLS0gKi8NCgkgICAgaWYgKGV4cGVjdGluZ190
cmFpbGVyKSB7DQoJCS8qIHNraXAgb3ZlciB0aGUgTU1ERiB0cmFpbGVyICov
DQoJCWV4cGVjdGluZ190cmFpbGVyID0gMDsNCgkJY29udGludWU7DQoJICAg
IH0NCg0KCSAgICBpZighcC0+bW1kZl9zZXBhcmF0b3IpIHsNCgkJc3RyY3B5
KGZyb21idWYsYnVmZmVyKTsgLyogUHJlc2VydmVkIEZyb20gZW52ZWxvcGUg
Ki8NCgkgICAgfQ0KICAgICAgICAgICAgLyogLS0tLS0tIEdldCByZWFkeSBm
b3IgdGhlIG5leHQgbWVzc2FnZSAtLS0tLSAqLw0KCSAgICBNRDVJbml0ICgm
bWRDb250ZXh0KTsNCgkgICAgTUQ1VXBkYXRlKCZtZENvbnRleHQsKHVuc2ln
bmVkIGNoYXIgKilidWZmZXIsc3RybGVuKGJ1ZmZlcikpOw0KICAgICAgICAg
ICAgLyogSW5jbHVkZSBhIHVuaXF1ZSBudW1iZXIgaW4gY2FzZSBldmVyeXRo
aW5nIGVsc2UgaXMgbm90ICovDQogICAgICAgICAgICB1bmlxdWVfbnVtKys7
DQogICAgICAgICAgICBNRDVVcGRhdGUoJm1kQ29udGV4dCwodW5zaWduZWQg
Y2hhciAqKSZ1bmlxdWVfbnVtLCBzaXplb2YobG9uZykpOw0KDQoJICAgIGlm
ICghaW5oZWFkZXIpIHsNCgkJaWYgKCsrbXNnX251bSA+IHAtPm1zZ19jb3Vu
dCkgew0KCQkgICAgcC0+bWxwID0gKE1zZ0luZm9MaXN0ICopIHJlYWxsb2Mo
cC0+bWxwLA0KCQkJKHAtPm1zZ19jb3VudCArPSBBTExPQ19NU0dTKSAqIHNp
emVvZihNc2dJbmZvTGlzdCkpOw0KCQkgICAgaWYgKHAtPm1scCA9PSBOVUxM
KXsNCgkJCXAtPm1zZ19jb3VudCA9IDA7DQoJCQlyZXR1cm4gcG9wX21zZyAo
cCwgUE9QX0ZBSUxVUkUsDQoJCQkgICAgIkNhbid0IGJ1aWxkIG1lc3NhZ2Ug
bGlzdCBmb3IgJyVzJzogT3V0IG9mIG1lbW9yeSIsDQoJCQkJICAgIHAtPnVz
ZXIpOw0KCQkgICAgfQ0KCQkgICAgbXAgPSBwLT5tbHAgKyBtc2dfbnVtIC0g
MjsNCgkJfQ0KCQlpZihtc2dfbnVtICE9IDEpew0KCQkgICAgREVCVUdfTE9H
NShwLCJNc2cgJWQgdWlkbCAlcyBhdCBvZmZzZXQgJWQgaXMgJWQgb2N0ZXRz
IGxvbmcgYW5kIGhhcyAldSBsaW5lcy4iLA0KCQkJICAgICAgIG1wLT5udW1i
ZXIsIG1wLT51aWRsX3N0ciwgbXAtPm9mZnNldCwgDQoJCQkgICAgICAgbXAt
Pmxlbmd0aCwgbXAtPmxpbmVzKTsNCgkJfQ0KCQllbHNlDQoJCSAgICBwb3Bf
bG9nKHAsUE9QX0RFQlVHLCAiRm91bmQgdG9wIG9mIGZpcnN0IG1lc3NhZ2Ui
KTsNCgkJKyttcDsNCg0KCSAgICB9IA0KCSAgICBlbHNlIHsgDQoJCXBvcF9s
b2cocCxQT1BfREVCVUcsDQoJCSAgICAiTXNnICVkIGNvcnJ1cHRlZCwgaWdu
b3JpbmcgcHJldmlvdXMgaGVhZGVyIGluZm9ybWF0aW9uLiIsDQoJCSAgICAg
bXAtPm51bWJlcik7DQoJICAgIH0NCgkgICAgbXAtPm51bWJlciA9IG1zZ19u
dW07DQoJICAgIG1wLT5sZW5ndGggPSAwOw0KCSAgICBtcC0+bGluZXMgPSAw
Ow0KCSAgICBtcC0+Ym9keV9saW5lcyA9IDA7DQoJICAgIG1wLT5vZmZzZXQg
PSBmdGVsbChwLT5kcm9wKSAtIG5jaGFyOw0KCSAgICBtcC0+ZGVsX2ZsYWcg
PSBGQUxTRTsNCgkgICAgbXAtPnJldHJfZmxhZyA9IEZBTFNFOw0KCSAgICBt
cC0+b3JpZ19yZXRyX3N0YXRlID0gRkFMU0U7DQoJICAgIG1wLT51aWRsX3N0
ciA9ICJcbiI7DQoJICAgIERFQlVHX0xPRzEocCwiTXNnICVkIGJlaW5nIGFk
ZGVkIHRvIGxpc3QgJXgiLCBtcC0+bnVtYmVyKTsNCgkgICAgaW5oZWFkZXIg
PSAxOw0KCSAgICB1aWRsX2ZvdW5kID0gMDsNCgkgICAgY29udGVudF9uY2hh
ciA9IDA7DQoJICAgIGNvbnRlbnRfbGVuZ3RoID0gMDsNCgkgICAgY29udF9s
ZW4gPSAwOw0KCSAgICBpZiAocC0+bW1kZl9zZXBhcmF0b3IpDQoJCWV4cGVj
dGluZ190cmFpbGVyID0gMTsNCg0KCSAgICBjb250aW51ZTsJLyogRG9uJ3Qg
Y291bnQgbWVzc2FnZSBzZXBhcmF0b3IgaW4gdG90YWwgc2l6ZSAqLw0KCX0N
CgkNCglpZiAoaW5oZWFkZXIpIHsNCgkgICAgaWYgKCpidWZmZXIgPT0gJ1xu
Jykgew0KCQlpbmhlYWRlciA9IDA7DQoJCWNvbnRlbnRfbGVuZ3RoID0gY29u
dF9sZW47DQoJCW1wLT5ib2R5X2xpbmVzID0gMTsgIC8qIENvdW50IG5ld2xp
bmUgYXMgdGhlIGZpcnN0IGJvZHkgbGluZSAqLw0KCQlpZiAoIXVpZGxfZm91
bmQpIHsNCgkJICAgIGNoYXIJKmNwOw0KCQkgICAgaW50CQlpOw0KDQoJCSAg
ICBNRDVVcGRhdGUoJm1kQ29udGV4dCwgKHVuc2lnbmVkIGNoYXIgKilmcm9t
YnVmLCANCgkJCSAgICAgIHN0cmxlbihmcm9tYnVmKSk7DQoJCSAgICBNRDVG
aW5hbCAoZGlnZXN0LCAmbWRDb250ZXh0KTsNCgkJICAgIGNwID0gbXAtPnVp
ZGxfc3RyID0gKGNoYXIgKiltYWxsb2MoKERJR19TSVpFICogMikgKyAyKTsN
CgkJICAgIGNwID0gYmFzZTgwKGNwLCBkaWdlc3QpOw0KCQkgICAgKmNwKysg
PSAnXG4nOw0KCQkgICAgKmNwICAgPSAnXDAnOw0KDQoJCSAgICBtcC0+bGVu
Z3RoICs9IHN0cmxlbigiWC1VSURMOiAiKSArIHN0cmxlbihtcC0+dWlkbF9z
dHIpICsgMTsNCgkJICAgIHAtPmRyb3Bfc2l6ZSArPSBzdHJsZW4oIlgtVUlE
TDogIikgKyBzdHJsZW4obXAtPnVpZGxfc3RyKSsxOw0KDQoJLyogTmV3IFVJ
RHMgZG8gbm90IGRpcnR5IHRoZSBtYWlsc3Bvb2wgaWYgTk9fU1RBVFVTIGlz
IHNldC4gIFRoZXkNCgkgICBhcmUganVzdCByZWNhbGN1bGF0ZWQgZWFjaCB0
aW1lIHRoZSBwb3BwZXIgaXMgcnVuIG9yIExNT1MgaXMNCgkgICBzZXQgYW5k
IHRoZSBtYWlsIHNwb29sIGlzIHVwZGF0ZWQuDQoJICovDQojaWZuZGVmIE5P
X1NUQVRVUw0KCQkgICAgcC0+ZGlydHkgPSAxOw0KI2VuZGlmDQoJCX0NCg0K
CSAgICB9IGVsc2UgaWYgKENPTlRFTlRfTEVOR1RIICYmICFzdHJuY21wKGJ1
ZmZlciwgIkNvbnRlbnQtTGVuZ3RoOiIsIDE1KSkgew0KCQljb250X2xlbiA9
IGF0b2koYnVmZmVyICsgMTUpOw0KCQlNRDVVcGRhdGUoJm1kQ29udGV4dCwo
dW5zaWduZWQgY2hhciAqKWJ1ZmZlcixzdHJsZW4oYnVmZmVyKSk7DQoJCW1w
LT5saW5lcysrOw0KCQljb250aW51ZTsJLyogbm90IHBhcnQgb2YgdGhlIG1l
c3NhZ2Ugc2l6ZSAqLw0KCSAgICB9IGVsc2UgaWYgKCF1aWRsX2ZvdW5kICYm
ICghc3RybmNhc2VjbXAoIlJlY2VpdmVkOiIsIGJ1ZmZlciwgOSkgfHwNCgkJ
CQkgICAgICAgIXN0cm5jYXNlY21wKCJEYXRlOiIsIGJ1ZmZlciwgNSkgfHwN
CgkJCQkgICAgICAgIXN0cm5jYXNlY21wKCJNZXNzYWdlLUlkOiIsYnVmZmVy
LCAxMSkgfHwNCgkJCQkgICAgICAgIXN0cm5jYXNlY21wKCJTdWJqZWN0OiIs
YnVmZmVyLCA4KQ0KCQkJCSAgICAgICApKSB7DQoJCU1ENVVwZGF0ZSgmbWRD
b250ZXh0LCh1bnNpZ25lZCBjaGFyICopYnVmZmVyLHN0cmxlbihidWZmZXIp
KTsNCgkgICAgfSBlbHNlIGlmICghc3RybmNhc2VjbXAoIlgtVUlETDoiLCBi
dWZmZXIsIDcpKSB7DQoJCWlmICghdWlkbF9mb3VuZCkgew0KCQkgICAgY2hh
ciAqY3A7DQoJCSAgICBpbnQgbGVuOw0KDQoJCSAgICAvKiBTa2lwIG92ZXIg
aGVhZGVyIHN0cmluZyAqLw0KCQkgICAgY3AgPSBidWZmZXI7DQoJCSAgICBp
ZiAoY3AgPSBpbmRleChidWZmZXIsICc6JykpIHsNCgkJCWNwKys7DQoJCQl3
aGlsZSAoKmNwICYmICgqY3AgPT0gJyAnIHx8ICpjcCA9PSAnXHQnKSkgY3Ar
KzsNCgkJICAgIH0gZWxzZQ0KCQkJY3AgPSAiIjsNCg0KCQkgICAgaWYoIChs
ZW4gPSBzdHJsZW4oY3ApKSA+IE1JTl9VSURMX0xFTkdUSCAmJiBsZW4gPCBN
QVhfVUlETF9MRU5HVEggKSB7DQoJCQl1aWRsX2ZvdW5kKys7DQoJCQltcC0+
dWlkbF9zdHIgPSAoY2hhciAqKXN0cmR1cChjcCk7DQoJCQltcC0+bGVuZ3Ro
ICs9IG5jaGFyICsgMTsNCgkJCXAtPmRyb3Bfc2l6ZSArPSBuY2hhciArIDE7
DQoJCSAgICB9DQoJCX0NCgkJbXAtPmxpbmVzKys7DQoJCWNvbnRpbnVlOyAg
LyogRG8gbm90IGluY2x1ZGUgdGhpcyB2YWx1ZSBpbiB0aGUgbWVzc2FnZSBz
aXplICovDQoJICAgIH0gZWxzZSBpZiAoKHN0cm5jYXNlY21wKGJ1ZmZlciwi
U3RhdHVzOiIsNykgPT0gMCkpIHsNCgkJaWYgKGluZGV4KGJ1ZmZlciwgJ1In
KSAhPSBOVUxMKSB7DQoJCSAgICBtcC0+cmV0cl9mbGFnID0gVFJVRTsNCgkJ
ICAgIG1wLT5vcmlnX3JldHJfc3RhdGUgPSBUUlVFOw0KCQl9DQoJICAgIH0N
Cgl9IGVsc2Ugew0KCSAgICBjb250ZW50X25jaGFyICs9IG5jaGFyOw0KCSAg
ICBtcC0+Ym9keV9saW5lcysrOw0KCX0NCiAgICAgICANCgltcC0+bGVuZ3Ro
ICs9IG5jaGFyICsgMTsNCglwLT5kcm9wX3NpemUgKz0gbmNoYXIgKyAxOw0K
CW1wLT5saW5lcysrOw0KICAgIH0NCg0KICAgIHAtPm1zZ19jb3VudCA9IG1z
Z19udW07DQoNCiAgICByZXR1cm4oUE9QX1NVQ0NFU1MpOw0KfQ0KDQoNCi8q
IA0KICogIHVzZSB0byBiZSBkcm9waW5mbzogICBFeHRyYWN0IGluZm9ybWF0
aW9uIGFib3V0IHRoZSBQT1AgbWFpbGRyb3AgYW5kIHN0b3JlIA0KICogIGl0
IGZvciB1c2UgYnkgdGhlIG90aGVyIFBPUCByb3V0aW5lcy4NCiAqDQogKiAg
Tm93LCB0aGUgY29weSBhbmQgaW5mbyBjb2xsZWN0aW9uIGFyZSBkb25lIGF0
IHRoZSBzYW1lIHRpbWUuDQogKi8NCg0KZG9fZHJvcF9jb3B5KHAsIG1mZCwg
ZGZkKQ0KaW50CW1mZCwgZGZkOw0KUE9QCSpwOw0Kew0KICAgIGNoYXIgICAg
ICAgICAgICAgICAgICAgIGJ1ZmZlcltNQVhMSU5FTEVOXTsgICAgIC8qICBS
ZWFkIGJ1ZmZlciAqLw0KICAgIGNoYXIgICAgICAgICAgICAgICAgICAgIGZy
b21idWZbTUFYTElORUxFTl07ICAgIC8qICBUbyBzYXZlIEZyb20gRW52ZWxv
cGUgKi8NCiAgICBNc2dJbmZvTGlzdCAgICAgICAgICogICBtcDsgICAgICAg
ICAgICAgICAgICAgICAvKiAgUG9pbnRlciB0byBtZXNzYWdlIA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBpbmZvIGxpc3QgKi8NCiAgICBpbnQgICAgICAgICAgICAgICAgICAg
ICBuY2hhcjsgICAgICAgICAgICAgICAgICAvKiAgQnl0ZXMgd3JpdHRlbi9y
ZWFkICovDQogICAgaW50CQkJICAgIGluaGVhZGVyOwkJICAgIC8qICBIZWFk
ZXIgc2VjdGlvbiBmbGFnICovDQogICAgaW50CQkJICAgIHVpZGxfZm91bmQ7
CQkgICAgLyogIFVJREwgaGVhZGVyIGZsYWcgKi8NCiAgICBpbnQJCQkgICAg
bXNnX251bTsNCiAgICBpbnQJCQkgICAgZXhwZWN0aW5nX3RyYWlsZXI7DQog
ICAgaW50CQkJICAgIGNvbnRlbnRfbGVuZ3RoLCBjb250ZW50X25jaGFyLCBj
b250X2xlbjsNCiAgICBNRDVfQ1RYCQkgICAgbWRDb250ZXh0Ow0KICAgIHVu
c2lnbmVkIGNoYXIJICAgIGRpZ2VzdFsxNl07DQogICAgaW50ICAgICAgICAg
ICAgICAgICAgICAgbWFuZ2xlZF9vbmU7DQogICAgRklMRQkJICAgICptYWls
X2Ryb3A7CQkgICAgLyogIFN0cmVhbXMgZm9yIGZpZHMgKi8NCiAgICBsb25n
IHVuaXF1ZV9udW0gPSB0aW1lKDApOw0KDQogICAgREVCVUdfTE9HMChwLCJE
Uk9QQ09QWTogUmVhZGluZyB0aGUgTWFpbCBEcm9wIGJveC4iKTsNCiAgICAv
KiAgQWNxdWlyZSBhIHN0cmVhbSBwb2ludGVyIGZvciB0aGUgbWFpbGRyb3Ag
Ki8NCiAgICBpZiAoIChtYWlsX2Ryb3AgPSBmZG9wZW4obWZkLCJyIikpID09
IE5VTEwgKSB7DQogICAgICAgIHJldHVybiBwb3BfbXNnKHAsUE9QX0ZBSUxV
UkUsIkNhbm5vdCBhc3NpZ24gc3RyZWFtIGZvciAlcyAoJWQpIiwNCgkJICAg
ICAgIHAtPmRyb3BfbmFtZSwgZXJybm8pOw0KICAgIH0NCg0KICAgIHJld2lu
ZCAobWFpbF9kcm9wKTsNCiNpZmRlZiBOVUxMS0xVREdFDQogICAgey8qIEVh
dCBOVUxMcyBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBtYWlsc3Bvb2wgKi8N
CiAgICAgICAgY2hhciB0ZW1wY2hhciA7DQoJd2hpbGUgKCh0ZW1wY2hhciA9
IGdldGMocC0+ZHJvcCkpID09IDApOw0KCXVuZ2V0Yyh0ZW1wY2hhciwgcC0+
ZHJvcCk7DQogICAgfQ0KI2VuZGlmDQogICAgaWYgKG1mZ2V0cyhidWZmZXIs
IE1BWE1TR0xJTkVMRU4sIG1haWxfZHJvcCkgPT0gTlVMTCkgew0KCXJldHVy
bihQT1BfU1VDQ0VTUyk7DQogICAgfQ0KDQogICAgLyogSXMgdGhpcyBhbiBN
TURGIGZpbGU/ICovDQogICAgaWYgKCpidWZmZXIgPT0gTU1ERl9TRVBfQ0hB
Uikgew0KCWlmICghcC0+bW1kZl9zZXBhcmF0b3IpDQoJICAgIHAtPm1tZGZf
c2VwYXJhdG9yID0gKGNoYXIgKilzdHJkdXAoYnVmZmVyKTsNCiAgICB9IGVs
c2UgaWYgKCFpc2Zyb21saW5lKGJ1ZmZlcikpIHsNCglERUJVR19MT0cxKHAs
ImJ1ZmZlciBjaGVja2VkICVzIiwgYnVmZmVyKTsNCglyZXR1cm4gcG9wX21z
ZyAocCxQT1BfRkFJTFVSRSwNCgkgIlVuYWJsZSB0byBwcm9jZXNzIEZyb20g
bGluZXMgKGVudmVsb3BlcyksIGNoYW5nZSByZWNvZ25pdGlvbiBtb2Rlcy4i
KTsNCiAgICB9DQoNCiAgICBuZXdsaW5lID0gMTsNCiAgICByZXdpbmQgKG1h
aWxfZHJvcCk7DQoNCiAgICAvKiAgU2NhbiB0aGUgZmlsZSwgbG9hZGluZyB0
aGUgbWVzc2FnZSBpbmZvcm1hdGlvbiBsaXN0IHdpdGggDQogICAgICAgIGlu
Zm9ybWF0aW9uIGFib3V0IGVhY2ggbWVzc2FnZSAqLw0KDQogICAgaW5oZWFk
ZXIgPSAwOw0KICAgIHVpZGxfZm91bmQgPSAwOw0KICAgIGV4cGVjdGluZ190
cmFpbGVyID0gMDsNCiAgICBtc2dfbnVtID0gcC0+bXNnX2NvdW50Ow0KICAg
IGNvbnRlbnRfbGVuZ3RoID0gMDsNCiAgICBjb250ZW50X25jaGFyID0gMDsN
CiAgICBjb250X2xlbiA9IDA7DQogICAgbWFuZ2xlZF9vbmUgPSAwOw0KICAg
IHAtPm1zZ19jb3VudCA9ICgoKHAtPm1zZ19jb3VudCAtIDEpIC8gQUxMT0Nf
TVNHUykgKyAxKSAqIEFMTE9DX01TR1M7DQojaWZkZWYgTlVMTEtMVURHRQ0K
ICAgIHsvKiBFYXQgTlVMTHMgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgbWFp
bHNwb29sIGlmIGFueS4qLw0KCWNoYXIgdGVtcGNoYXI7DQoJd2hpbGUgKCh0
ZW1wY2hhciA9IGdldGMocC0+ZHJvcCkpID09IDApOw0KCXVuZ2V0Yyh0ZW1w
Y2hhciwgcC0+ZHJvcCk7DQogICAgfQ0KI2VuZGlmDQogICAgZm9yIChtcCA9
IHAtPm1scCArIG1zZ19udW0gLSAxOyBtZmdldHMoYnVmZmVyLE1BWE1TR0xJ
TkVMRU4sbWFpbF9kcm9wKTspIHsNCg0KCW5jaGFyID0gc3RybGVuKGJ1ZmZl
cik7DQoNCglpZiAoZnB1dHMoYnVmZmVyLCBwLT5kcm9wKSA9PSBFT0YpIHsN
CgkgICAgaWYgKGVycm5vID09IEVEUVVPVCkNCgkJcmV0dXJuIHBvcF9tc2cg
KHAsUE9QX0ZBSUxVUkUsDQoJCSAgICAiVW5hYmxlIHRvIGNvcHkgbWFpbCBz
cG9vbCBmaWxlLCBxdW90YSBleGNlZWRlZCAoJWQpIiwNCgkJCWVycm5vKTsN
CgkgICAgcmV0dXJuIHBvcF9tc2cgKHAsUE9QX0ZBSUxVUkUsDQoJCSJVbmFi
bGUgdG8gY29weSBtYWlsIHNwb29sIGZpbGUgdG8gdGVtcCBwb3AgZHJvcGJv
eCAlcyAoJWQpIiwNCgkJICAgIHAtPnRlbXBfZHJvcCwgZXJybm8pOw0KCX0N
CgkvKiBFbmQgb2YgcHJldmlvdXMgbWVzc2FnZSAqLw0KCWlmICgoY29udGVu
dF9uY2hhciA+PSBjb250ZW50X2xlbmd0aCkgJiYNCgkgICAgKHAtPm1tZGZf
c2VwYXJhdG9yID8gIXN0cmNtcChwLT5tbWRmX3NlcGFyYXRvciwgYnVmZmVy
KSA6DQoJICAgIGlzZnJvbWxpbmUoYnVmZmVyKSkpIHsNCiAgICAgICAgICAg
IC8qPT09IE1hdGNoZWQgc2VwYXJhdG9yLCB0aWUgb2YgbGFzdCBtZXNzYWdl
LCBzdGFydCBuZXcgb25lID09PSovDQoNCg0KCSAgICBpZiAoZXhwZWN0aW5n
X3RyYWlsZXIpIHsNCgkJZXhwZWN0aW5nX3RyYWlsZXIgPSAwOw0KCQljb250
aW51ZTsNCgkgICAgfQ0KDQoJICAgIGlmKCAhcC0+bW1kZl9zZXBhcmF0b3Ig
KSB7DQoJCXN0cmNweShmcm9tYnVmLCBidWZmZXIpOw0KCSAgICB9DQoNCiAg
ICAgICAgICAgIC8qPT09IFN0YXJ0aW5nIG5ldyBtZXNzYWdlID09PSovDQoJ
ICAgIE1ENUluaXQgKCZtZENvbnRleHQpOw0KCSAgICBNRDVVcGRhdGUoJm1k
Q29udGV4dCwodW5zaWduZWQgY2hhciAqKWJ1ZmZlcixzdHJsZW4oYnVmZmVy
KSk7DQogICAgICAgICAgICAvKiBJbmNsdWRlIGEgdW5pcXVlIG51bWJlciBp
biBjYXNlIGV2ZXJ5dGhpbmcgZWxzZSBpcyBub3QgKi8NCiAgICAgICAgICAg
IHVuaXF1ZV9udW0rKzsNCiAgICAgICAgICAgIE1ENVVwZGF0ZSgmbWRDb250
ZXh0LCh1bnNpZ25lZCBjaGFyICopJnVuaXF1ZV9udW0sIHNpemVvZihsb25n
KSk7DQoNCgkgICAgaWYgKCFpbmhlYWRlcikgew0KCQlpZiAoKyttc2dfbnVt
ID4gcC0+bXNnX2NvdW50KSB7DQoJCSAgICBwLT5tbHA9KE1zZ0luZm9MaXN0
ICopIHJlYWxsb2MocC0+bWxwLA0KCQkJKHAtPm1zZ19jb3VudCs9QUxMT0Nf
TVNHUykqc2l6ZW9mKE1zZ0luZm9MaXN0KSk7DQoJCSAgICBpZiAocC0+bWxw
ID09IE5VTEwpIHsNCgkJCXAtPm1zZ19jb3VudCA9IDA7DQoJCQlyZXR1cm4g
cG9wX21zZyAocCxQT1BfRkFJTFVSRSwNCgkJCSAgICAiQ2FuJ3QgYnVpbGQg
bWVzc2FnZSBsaXN0IGZvciAnJXMnOiBPdXQgb2YgbWVtb3J5IiwNCgkJCQlw
LT51c2VyKTsNCgkJICAgIH0NCgkJICAgIG1wID0gcC0+bWxwICsgbXNnX251
bSAtIDI7DQoJCX0NCgkJaWYoIG1zZ19udW0gIT0gMSkNCgkJICAgIERFQlVH
X0xPRzUocCwiTXNnICVkIHVpZGwgJXMgYXQgb2Zmc2V0ICVkIGlzICVkIG9j
dGV0cyBsb25nIGFuZCBoYXMgJXUgbGluZXMuIiwNCgkJCSAgICAgIG1wLT5u
dW1iZXIsbXAtPnVpZGxfc3RyLG1wLT5vZmZzZXQsbXAtPmxlbmd0aCwNCgkJ
CSAgICAgIG1wLT5saW5lcyk7DQoJCSsrbXA7DQoNCgkgICAgfSBlbHNlIHsN
CgkJcG9wX2xvZyhwLFBPUF9ERUJVRywiTXNnICVkIGNvcnJ1cHRlZCwgaWdu
b3JpbmcgcHJldmlvdXMgaGVhZGVyIGluZm9ybWF0aW9uLiIsDQoJCSAgICAg
bXAtPm51bWJlcik7DQoJICAgIH0NCg0KICAgICAgICAgICAgbXAtPm51bWJl
ciA9IG1zZ19udW07DQogICAgICAgICAgICBtcC0+bGVuZ3RoID0gMDsNCiAg
ICAgICAgICAgIG1wLT5saW5lcyA9IDA7DQogICAgICAgICAgICBtcC0+Ym9k
eV9saW5lcyA9IDA7DQogICAgICAgICAgICBtcC0+b2Zmc2V0ID0gZnRlbGwo
cC0+ZHJvcCkgLSBuY2hhcjsNCiAgICAgICAgICAgIG1wLT5kZWxfZmxhZyA9
IEZBTFNFOw0KICAgICAgICAgICAgbXAtPnJldHJfZmxhZyA9IEZBTFNFOw0K
ICAgICAgICAgICAgbXAtPm9yaWdfcmV0cl9zdGF0ZSA9IEZBTFNFOw0KCSAg
ICBtcC0+dWlkbF9zdHIgPSAiXG4iOw0KDQoJICAgIERFQlVHX0xPRzEocCwi
TXNnICVkIGJlaW5nIGFkZGVkIHRvIGxpc3QuIiwgbXAtPm51bWJlcik7DQoJ
ICAgIGluaGVhZGVyID0gMTsNCgkgICAgY29udGVudF9sZW5ndGggPSAwOw0K
CSAgICBjb250ZW50X25jaGFyID0gMDsNCgkgICAgY29udF9sZW4gPSAwOw0K
CSAgICB1aWRsX2ZvdW5kID0gMDsNCgkgICAgaWYgKHAtPm1tZGZfc2VwYXJh
dG9yKQ0KCQlleHBlY3RpbmdfdHJhaWxlciA9IDE7DQoNCg0KCSAgICBjb250
aW51ZTsJLyogRG8gbm90IGluY2x1ZGUgRnJvbSBzZXBhcmF0b3IgaW4gbWVz
c2FnZSBzaXplICovDQogICAgICAgIH0NCg0KICAgICAgICAvKiA9PT09PT0g
SGFuZGxlIGhlYWRlciBhbmQgYm9keSBvZiBtZXNzYWdlIGhlcmUgPT09PSAq
Lw0KCWlmIChpbmhlYWRlcikgew0KICAgICAgICAgICAgLyogPT09PT0gSGFu
ZGxlIHRoZSBoZWFkZXIgb2YgYSBtZXNzYWdlID09PT0gKi8NCgkgICAgaWYg
KCpidWZmZXIgPT0gJ1xuJykgew0KICAgICAgICAgICAgICAgIC8qID09PSBF
bmNvdW50ZXJlZCB0cmFuc2l0aW9uIHRvIGJvZHkgPT09PSovDQoJCWluaGVh
ZGVyID0gMDsNCgkJbXAtPmJvZHlfbGluZXMgPSAxOw0KCQljb250ZW50X2xl
bmd0aCA9IGNvbnRfbGVuOw0KDQoJCWlmICghdWlkbF9mb3VuZCkgew0KCQkg
ICAgY2hhciAqY3A7DQoJCSAgICBpbnQgIGk7DQoNCgkJICAgIE1ENVVwZGF0
ZSgmbWRDb250ZXh0LCAodW5zaWduZWQgY2hhciAqKWZyb21idWYsDQoJCQkg
ICAgICBzdHJsZW4oZnJvbWJ1ZikpOw0KCQkgICAgTUQ1RmluYWwgKGRpZ2Vz
dCwgJm1kQ29udGV4dCk7DQoJCSAgICBjcCA9IG1wLT51aWRsX3N0ciA9IChj
aGFyICopbWFsbG9jKChESUdfU0laRSAqIDIpICsgMik7DQogICAgICAgICAg
ICAgICAgICAgIGNwID0gYmFzZTgwKGNwLCBkaWdlc3QpOw0KCQkgICAgKmNw
KysgPSAnXG4nOw0KCQkgICAgKmNwICAgPSAnXDAnOw0KICAgICAgICAgICAg
ICAgICAgICBERUJVR19MT0cxKHAsICJVSURMIC0lcy0iLCBtcC0+dWlkbF9z
dHIpOw0KDQoJCSAgICBtcC0+bGVuZ3RoICs9IHN0cmxlbigiWC1VSURMOiAi
KSArIHN0cmxlbihtcC0+dWlkbF9zdHIpICsgMTsNCgkJICAgIHAtPmRyb3Bf
c2l6ZSArPSBzdHJsZW4oIlgtVUlETDogIikgKyBzdHJsZW4obXAtPnVpZGxf
c3RyKSsxOw0KDQogICAgICAgICAgICAgICAgICAgIC8qIE5ldyBVSURzIGRv
IG5vdCBkaXJ0eSB0aGUgbWFpbHNwb29sIGlmIE5PX1NUQVRVUyBpcw0KICAg
ICAgICAgICAgICAgICAgICAgICBzZXQuICBUaGV5IGFyZSBqdXN0IHJlY2Fs
Y3VsYXRlZCBlYWNoIHRpbWUgdGhlDQogICAgICAgICAgICAgICAgICAgICAg
IHBvcHBlciBpcyBydW4gb3IgTE1PUyBpcyBzZXQgYW5kIHRoZSBtYWlsIHNw
b29sDQogICAgICAgICAgICAgICAgICAgICAgIGlzIHVwZGF0ZWQuICovDQoj
aWZuZGVmIE5PX1NUQVRVUw0KCQkgICAgcC0+ZGlydHkgPSAxOw0KI2VuZGlm
DQoJCX0NCg0KCSAgICB9IGVsc2UgaWYoQ09OVEVOVF9MRU5HVEggJiYgIXN0
cm5jbXAoYnVmZmVyLCJDb250ZW50LUxlbmd0aDoiLDE1KSl7DQogICAgICAg
ICAgICAgICAgLyo9PT0gSGFuZGxlIGNvbnRlbnRfbGVuZ3RoIGlmIHdlIGRv
IHRoYXQgc29ydCBvZiB0aGluZyA9PT0qLw0KCQljb250X2xlbiA9IGF0b2ko
YnVmZmVyICsgMTUpOw0KCQlNRDVVcGRhdGUoJm1kQ29udGV4dCwodW5zaWdu
ZWQgY2hhciAqKWJ1ZmZlcixzdHJsZW4oYnVmZmVyKSk7DQoJCW1wLT5saW5l
cysrOw0KCQljb250aW51ZTsgIC8qIE5vdCBpbmNsdWRlZCBpbiBtZXNzYWdl
IHNpemUgKi8NCg0KCSAgICB9IGVsc2UgaWYgKCF1aWRsX2ZvdW5kICYmICgh
c3RybmNhc2VjbXAoIlJlY2VpdmVkOiIsIGJ1ZmZlciwgOSkgfHwNCgkJCQkg
ICAgICAgIXN0cm5jYXNlY21wKCJEYXRlOiIsIGJ1ZmZlciwgNSkgfHwNCgkJ
CQkgICAgICAgIXN0cm5jYXNlY21wKCJNZXNzYWdlLUlkOiIsYnVmZmVyLCAx
MSkgfHwNCgkJCQkgICAgICAgIXN0cm5jYXNlY21wKCJTdWJqZWN0OiIsYnVm
ZmVyLCA4KQ0KCQkJCSAgICAgICApKSB7DQogICAgICAgICAgICAgICAgLyog
PT09IEFjY3VtdWF0ZSBjZXJ0YWluIGhlYWRlciB3ZSBtaWdodCBzZWUgZm9y
IFVJREwgPT09Ki8NCgkJTUQ1VXBkYXRlKCZtZENvbnRleHQsKHVuc2lnbmVk
IGNoYXIgKilidWZmZXIsc3RybGVuKGJ1ZmZlcikpOw0KCSAgICB9IGVsc2Ug
aWYgKCFzdHJuY2FzZWNtcCgiWC1VSURMOiIsIGJ1ZmZlciwgNykpIHsNCiAg
ICAgICAgICAgICAgLyogPT09PSBEbyB0aGUgVUlETCBoZWFkZXIgPT09PSAq
Lw0KCQlpZiAoIXVpZGxfZm91bmQpIHsNCgkJICAgIGNoYXIgKmNwOw0KCQkg
ICAgaW50IGxlbjsNCg0KCQkgICAgLyogU2tpcCBvdmVyIGhlYWRlciAqLw0K
CQkgICAgY3AgPSBidWZmZXI7DQoJCSAgICBpZiAoY3AgPSBpbmRleChidWZm
ZXIsICc6JykpIHsNCgkJCWNwKys7DQoJCQl3aGlsZSAoKmNwICYmICgqY3Ag
PT0gJyAnIHx8ICpjcCA9PSAnXHQnKSkgY3ArKzsNCgkJICAgIH0gZWxzZQ0K
CQkJY3AgPSAiIjsNCg0KCQkgICAgaWYoIChsZW4gPSBzdHJsZW4oY3ApKSA+
IE1JTl9VSURMX0xFTkdUSCAmJiBsZW4gPCBNQVhfVUlETF9MRU5HVEggKSB7
DQoJCQl1aWRsX2ZvdW5kKys7DQoJCQltcC0+dWlkbF9zdHIgPSAoY2hhciAq
KXN0cmR1cChjcCk7DQoJCQltcC0+bGVuZ3RoICs9IG5jaGFyICsgMTsNCgkJ
CXAtPmRyb3Bfc2l6ZSArPSBuY2hhciArIDE7DQoJCSAgICB9DQoJCX0NCgkJ
bXAtPmxpbmVzKys7DQoJCWNvbnRpbnVlOyAgLyogRG8gbm90IGluY2x1ZGUg
dGhpcyB2YWx1ZSBpbiB0aGUgbWVzc2FnZSBzaXplICovDQoJICAgIH0gZWxz
ZSBpZiAoIXN0cm5jYXNlY21wKGJ1ZmZlciwiU3RhdHVzOiIsNykpIHsNCiAg
ICAgICAgICAgICAgICAvKiA9PT0gRG8gdGhlIHN0YXR1cyBoZWFkZXIgPT09
ICovDQoJCWlmIChpbmRleChidWZmZXIsICdSJykgIT0gTlVMTCkgew0KCQkg
ICAgbXAtPnJldHJfZmxhZyA9IFRSVUU7DQoJCSAgICBtcC0+b3JpZ19yZXRy
X3N0YXRlID0gVFJVRTsNCgkJfQ0KCSAgICB9DQoJfSBlbHNlIHsNCiAgICAg
ICAgICAgIC8qID09PT0gSGFuZGxlIHRoZSBib2R5IG9mIGEgbWVzc2FnZSAo
bm90IG11Y2ggdG8gZG8pID09PSAqLw0KCSAgICBjb250ZW50X25jaGFyICs9
IG5jaGFyOw0KCSAgICBtcC0+Ym9keV9saW5lcysrOw0KCX0NCg0KICAgICAg
ICBtcC0+bGVuZ3RoICs9IG5jaGFyICsgMTsNCiAgICAgICAgcC0+ZHJvcF9z
aXplICs9IG5jaGFyICsgMTsNCiAgICAgICAgbXAtPmxpbmVzKys7DQogICAg
fQ0KDQogICAgcC0+bXNnX2NvdW50ID0gbXNnX251bTsNCg0KI2lmZGVmIERF
QlVHDQogICAgaWYocC0+ZGVidWcgJiYgbXNnX251bSA+IDApIHsNCiAgICAg
ICAgcmVnaXN0ZXIgICAgaTsNCiAgICAgICAgZm9yIChpID0gMCwgbXAgPSBw
LT5tbHA7IGkgPCBwLT5tc2dfY291bnQ7IGkrKywgbXArKykNCiAgICAgICAg
ICAgIHBvcF9sb2cocCxQT1BfREVCVUcsDQoJICAgICJNc2cgJWQgdWlkbCAl
cyBhdCBvZmZzZXQgJWQgaXMgJWQgb2N0ZXRzIGxvbmcgYW5kIGhhcyAldSBs
aW5lcy4iLA0KCSAgICBtcC0+bnVtYmVyLG1wLT51aWRsX3N0cixtcC0+b2Zm
c2V0LG1wLT5sZW5ndGgsbXAtPmxpbmVzKTsNCiAgICB9DQojZW5kaWYNCg0K
ICAgIGlmIChmZmx1c2gocC0+ZHJvcCkgPT0gRU9GKQ0KICAgICAgICByZXR1
cm4gcG9wX21zZyhwLFBPUF9GQUlMVVJFLCJGbHVzaCBvZiB0ZW1wIHBvcCBk
cm9wYm94ICVzIGZhaWxlZCAoJWQpIiwNCgkgICAgcC0+dGVtcF9kcm9wLCBl
cnJubyk7DQoNCiAgICByZXR1cm4oUE9QX1NVQ0NFU1MpOw0KfQ0KDQovKiAN
CiAqICBkcm9wY29weTogICBNYWtlIGEgdGVtcG9yYXJ5IGNvcHkgb2YgdGhl
IHVzZXIncyBtYWlsIGRyb3AgYW5kIA0KICogIHNhdmUgYSBzdHJlYW0gcG9p
bnRlciBmb3IgaXQuDQogKi8NCg0KcG9wX2Ryb3Bjb3B5KHAsIHB3cCkNClBP
UCAgICAgKiAgIHA7DQpzdHJ1Y3QgcGFzc3dkCSoJcHdwOw0Kew0KICAgIGlu
dCAgICAgICAgICAgICAgICAgICAgIG1mZDsgICAgICAgICAgICAgICAgICAg
IC8qICBGaWxlIGRlc2NyaXB0b3IgZm9yIA0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgdXNl
cidzIG1haWxkcm9wICovDQogICAgaW50ICAgICAgICAgICAgICAgICAgICAg
ZGZkOyAgICAgICAgICAgICAgICAgICAgLyogIEZpbGUgZGVzY3JpcHRvciBm
b3IgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHRoZSBTRVJWRVIgbWFpbGRyb3AgKi8NCiAgICBG
SUxFCQkgICAgKnRmOwkJICAgIC8qICBUaGUgdGVtcCBmaWxlICovDQogICAg
aW50CQkJICAgIHRmbjsJCSAgICANCiAgICBjaGFyICAgICAgICAgICAgICAg
ICAgICBidWZmZXJbTUFYTElORUxFTl07ICAgICAvKiAgUmVhZCBidWZmZXIg
Ki8NCiAgICBjaGFyCQkgICAgbWVzc1syNTZdOwkJLyogQ1lHTlVTICovDQog
ICAgbG9uZyAgICAgICAgICAgICAgICAgICAgb2Zmc2V0OyAgICAgICAgICAg
ICAgICAgLyogIE9sZC9OZXcgYm91bmRhcnkgKi8NCiAgICBpbnQgICAgICAg
ICAgICAgICAgICAgICBuY2hhcjsgICAgICAgICAgICAgICAgICAvKiAgQnl0
ZXMgd3JpdHRlbi9yZWFkICovDQogICAgc3RydWN0IHN0YXQgICAgICAgICAg
ICAgbXlidWY7ICAgICAgICAgICAgICAgICAgLyogIEZvciBmc3RhdCgpICov
DQoNCiAgICBpZiAoZ2VucGF0aChwKSA8IDApDQoJcmV0dXJuKHBvcF9tc2co
cCwgUE9QX0ZBSUxVUkUsICJVbmFibGUgdG8gY3JlYXRlIHRlbXBvcmFyeSBk
cm9wIG5hbWUiKSk7DQoNCiAgICAvKiAgQ3JlYXRlIGEgdGVtcG9yYXJ5IG1h
aWxkcm9wIGludG8gd2hpY2ggdG8gY29weSB0aGUgdXBkYXRlZCBtYWlsZHJv
cCAqLw0KICAgICh2b2lkKXNwcmludGYocC0+dGVtcF9kcm9wLCBQT1BfRFJP
UCwgcC0+dXNlcik7DQoNCiAgICBERUJVR19MT0cxKHAsIkNyZWF0aW5nIHRl
bXBvcmFyeSBtYWlsZHJvcCAnJXMnIixwLT50ZW1wX2Ryb3ApOw0KDQojaWZk
ZWYgQlVMTERCDQogICAgaWYgKHAtPmJ1bGxkaXIpIHsNCgljaGFyIGJ1bGxf
ZGJbTUFYTElORUxFTl07DQoNCiNpZmRlZiBCVUxMREJESVINCglzcHJpbnRm
KGJ1bGxfZGIsICIlcy9idWxsZGIiLCBCVUxMREJESVIpOw0KI2Vsc2UNCglz
cHJpbnRmKGJ1bGxfZGIsICIlcy9idWxsZGIiLCBwLT5idWxsZGlyKTsNCiNl
bmRpZg0KI2lmZGVmIEdEQk0NCglpZiAoKHAtPmJ1bGxfZGIgPSBnZGJtX29w
ZW4gKGJ1bGxfZGIsIDUxMiwgR0RCTV9XUkNSRUFULCAwNjAwLCAwKSkgPT0g
TlVMTCkNCiNlbHNlDQogICAgICAgIGlmICgocC0+YnVsbF9kYiA9IGRibV9v
cGVuIChidWxsX2RiLCBPX1JEV1IgfCBPX0NSRUFULCAwNjAwKSkgPT0gTlVM
TCkgDQojZW5kaWYNCgkJew0KCQkgICAgcG9wX2xvZyhwLFBPUF9QUklPUklU
WSwiZ2RibV9vcGVuIGZhaWxlZCA6ICVzICglZCkiLA0KCQkJICAgIHN5c19l
cnJsaXN0W2Vycm5vXSxlcnJubyk7DQoJCSAgICByZXR1cm4ocG9wX21zZyhw
LCBQT1BfRkFJTFVSRSwNCgkJCQkgICAiVW5hYmxlIHRvIG9wZW4gQnVsbGV0
aW4gZGF0YWJhc2UsIGNvbnRhY3QgeW91ciBhZG1pbmlzdHJhdG9yIikpOw0K
CQl9DQogICAgfQ0KI2VuZGlmDQoNCiAgICAvKiBIZXJlIHdlIHdvcmsgdG8g
bWFrZSBzdXJlIHRoZSB1c2VyIGRvZXNuJ3QgY2F1c2UgdXMgdG8gcmVtb3Zl
IG9yDQogICAgICogd3JpdGUgb3ZlciBleGlzdGluZyBmaWxlcyBieSBsaW1p
dGluZyBob3cgbXVjaCB3b3JrIHdlIGRvIHdoaWxlDQogICAgICogcnVubmlu
ZyBhcyByb290Lg0KICAgICAqLw0KDQojaWZkZWYgQklOTUFJTF9JU19TRVRH
SUQNCiMgaWYgQklOTUFJTF9JU19TRVRHSUQgPiAxDQogICAgcHdwLT5wd19n
aWQgPSAoZ2lkX3QpQklOTUFJTF9JU19TRVRHSUQ7DQojIGVsc2UNCiAgICBp
ZiAoIXN0YXQoUE9QX01BSUxESVIsICZteWJ1ZikpDQoJcHdwLT5wd19naWQg
PSBteWJ1Zi5zdF9naWQ7DQojIGVuZGlmDQojZW5kaWYNCg0KICAgIC8qIE5v
dyB3ZSBydW4gYXMgdGhlIHVzZXIuICovDQogICAgKHZvaWQpIHNldGdpZCgo
R0lEX1QpcHdwLT5wd19naWQpOw0KICAgIC8qIFNldCB0aGUgc3VwcGxlbWVu
dGFyeSBncm91cHMgbGlzdCAqLw0KICAgICh2b2lkKSBzZXRncm91cHMoMSwo
R0lEX1QgKikmcHdwLT5wd19naWQpOyANCiAgICAodm9pZCkgc2V0dWlkKChV
SURfVClwd3AtPnB3X3VpZCk7DQoNCiAgICBERUJVR19MT0cyKHAsInVpZCA9
ICVkLCBnaWQgPSAlZCIsZ2V0dWlkKCksZ2V0Z2lkKCkpOw0KDQovKiBTVEFS
VCBDWUdOVVMgKi8NClNUQVJUT1BFTjoNCm1lc3NbMF09MDsNCi8qIEVORCBD
WUdOVVMgKi8NCiAgICBpZiAoKGRmZCA9IG9wZW4ocC0+dGVtcF9kcm9wLCBP
X1JEV1IgfCBPX0NSRUFULCAwNjAwKSkgPT0gLTEpIHsNCiAgICAgICAgcG9w
X2xvZyhwLCBQT1BfUFJJT1JJVFksDQogICAgICAgICAgICAiVW5hYmxlIHRv
IG9wZW4gdGVtcG9yYXJ5IG1haWxkcm9wICclcyc6ICVzICglZCkiLHAtPnRl
bXBfZHJvcCwNCiAgICAgICAgICAgICAgICAoZXJybm8gPCBzeXNfbmVycikg
PyBzeXNfZXJybGlzdFtlcnJub10gOiAiIiwgZXJybm8pIDsNCiAgICAgICAg
cmV0dXJuIHBvcF9tc2cocCxQT1BfRkFJTFVSRSwNCiAgIAkgICAiRmFpbGVk
IHRvIGNyZWF0ZSAlcyB3aXRoIHVpZCAlZCwgZ2lkICVkLiBDaGFuZ2UgcGVy
bWlzc2lvbnMuIiwNCgkJICAgICAgIHAtPnRlbXBfZHJvcCxwd3AtPnB3X3Vp
ZCwgcHdwLT5wd19naWQpOw0KICAgIH0NCg0KICAgIGZzdGF0KGRmZCwgJm15
YnVmKTsNCiAgICBpZiAobXlidWYuc3RfdWlkICE9IHB3cC0+cHdfdWlkKSB7
DQoJY2xvc2UoZGZkKTsNCglyZXR1cm4ocG9wX21zZyhwLCBQT1BfRkFJTFVS
RSwiVGVtcG9yYXJ5IGRyb3AgZmlsZSBub3Qgb3duZWQgYnkgJXMuIiwNCgkJ
ICAgICAgIHAtPnVzZXIpKTsNCiAgICB9DQojaWZkZWYgTkVYVA0KICAgIGlm
IChteWJ1Zi5zdF9tb2RlICYgKDB4NykpDQojZWxzZQ0KICAgIGlmIChteWJ1
Zi5zdF9tb2RlICYgKFNfSVdPVEggfCBTX0lST1RIKSkNCiNlbmRpZg0KICAg
IHsNCgljbG9zZShkZmQpOw0KCXJldHVybihwb3BfbXNnKHAsIFBPUF9GQUlM
VVJFLA0KCSAgIllvdXIgdGVtcG9yYXJ5IGZpbGUgJXMgaXMgYWNjZXNzaWJs
ZSBieSBvdGhlcnMuICBUaGlzIG11c3QgYmUgZml4ZWQiLA0KCSAgICBwLT50
ZW1wX2Ryb3ApKTsNCiAgICB9DQogICAgLyogTWFrZSBzdXJlIHRoZSBtYWls
c3Bvb2wgaXMgbm90IGEgaGFyZCBsaW5rICovDQogICAgaWYgKG15YnVmLnN0
X25saW5rICE9IDEpIHsNCgljbG9zZShkZmQpOw0KCXJldHVybihwb3BfbXNn
KHAsIFBPUF9GQUlMVVJFLA0KCSAgICAiWW91ciB0ZW1wb3JhcnkgZmlsZSBh
cHBlYXJzIHRvIGhhdmUgbW9yZSB0aGFuIG9uZSBsaW5rLiIpKTsNCiAgICB9
DQoNCiAgICAvKiBJZiB0aGUgdGVtcG9yYXJ5IHBvcGRyb3AgaXMgbm90IGVt
cHR5LCByZXZlcnQgdG8gcmVndWxhciBtb2RlLiAqLw0KICAgIGlmIChteWJ1
Zi5zdF9zaXplICE9IDApDQoJcC0+c2VydmVyX21vZGUgPSAwOw0KDQogICAg
LyogIExvY2sgdGhlIHRlbXBvcmFyeSBtYWlsZHJvcC4gTG9ja2luZyBpcyBq
dXN0IHRvIGNoZWNrIGZvciBzaW5nbGUNCiAgICAgKiAgcG9wIHNlc3Npb24g
cGVyIHVzZXIuDQogICAgICovDQogICAgaWYgKCBmbG9jayAoZGZkLCBMT0NL
X0VYfExPQ0tfTkIpID09IC0xICkgew0KCXN3aXRjaChlcnJubykgew0KCSAg
ICBjYXNlIEVXT1VMREJMT0NLOg0KCQkvKiBTVEFSVCBDWUdOVVMgKi8NCgkJ
cG9wX2xvZyhwLFBPUF9QUklPUklUWSwiRm91bmQgbG9ja2VkIHNwb29sIGZv
ciAlcyEiLHAtPnVzZXIpOw0KCQljbGVhcl9vbGQocCk7IC8qIGtpbGwgdXNl
ciBwcm9jZXNzIGlmIHRoZXJlIGlzIG9uZSAqLw0KCQkvKiBwcmludF9sb2Nr
X2RpcihwKTsgKi8NCgkJcG9wX2xvZyhwLFBPUF9QUklPUklUWSwiVW5sb2Nr
aW5nIGxvY2sgZmlsZSBmb3IgJXMiLHAtPnVzZXIpOw0KCQkvKiB1bmxvY2sg
dGhlIGRyb3AgZmlsZSAqLw0KCSAgICAJaWYgKGZsb2NrKGRmZCwgTE9DS19V
Tik9PS0xKSB7DQoJCXBvcF9sb2cocCxQT1BfUFJJT1JJVFksIkNhbnQgdW5s
b2NrIGxvY2sgZmlsZSBmb3IgJXMhICglcykiLHAtPnVzZXIsc3RyZXJyb3Io
ZXJybm8pKTsNCgkJcG9wX2xvZyhwLFBPUF9QUklPUklUWSwiQ2xvc2luZyBk
cm9wIGZpbGUgZm9yICVzISIscC0+dXNlcik7DQoJCWNsb3NlKGRmZCk7IC8q
IGNsb3NlIHRoZSBkcm9wIGZpbGUgKi8NCgkJcG9wX2xvZyhwLFBPUF9QUklP
UklUWSwiQ0xPU0VEIGRyb3AgZmlsZSBmb3IgJXMhIixwLT51c2VyKTsNCgkJ
Z290byBTVEFSVEVORDsNCgkJfQ0KCQlwb3BfbG9nKHAsUE9QX1BSSU9SSVRZ
LCJVTkxPQ0tFRCBsb2NrIGZpbGUgZm9yICVzIixwLT51c2VyKTsNCgkJcG9w
X2xvZyhwLFBPUF9QUklPUklUWSwiQ2xvc2luZyBkcm9wIGZpbGUgZm9yICVz
ISIscC0+dXNlcik7DQoJCWNsb3NlKGRmZCk7IC8qIGNsb3NlIHRoZSBkcm9w
IGZpbGUgKi8NCgkJcG9wX2xvZyhwLFBPUF9QUklPUklUWSwiQ0xPU0VEIGRy
b3AgZmlsZSBmb3IgJXMhIixwLT51c2VyKTsNCgkJcG9wX2xvZyhwLFBPUF9Q
UklPUklUWSwiUmVtb3ZpbmcgZHJvcCBmaWxlIGZvciAlcyEiLHAtPnVzZXIp
Ow0KCQkodm9pZCl1bmxpbmsocC0+dGVtcF9kcm9wKTsgLyogcmVtb3ZlIHRo
ZSBkcm9wIGZpbGUgKi8NCgkJcG9wX2xvZyhwLFBPUF9QUklPUklUWSwiUkVN
T1ZFRCBkcm9wIGZpbGUgZm9yICVzISIscC0+dXNlcik7DQoJCWdvdG8gU1RB
UlRPUEVOOw0KCQlTVEFSVEVORDoNCgkJLyogRU5EIENZR05VUyAqLw0KCQly
ZXR1cm4gcG9wX21zZyhwLFBPUF9GQUlMVVJFLA0KCQkgICAgICJbSU4tVVNF
XSAlcyBsb2NrIGJ1c3khICBJcyBhbm90aGVyIHNlc3Npb24gYWN0aXZlPyAo
JWQpIiwNCgkJCQkJCQlwLT50ZW1wX2Ryb3AsIGVycm5vKTsNCgkgICAgZGVm
YXVsdDoNCgkJY2xvc2UoZGZkKTsNCgkJcmV0dXJuIHBvcF9tc2cocCxQT1Bf
RkFJTFVSRSwiZmxvY2s6ICclcyc6ICVzICglZCkiLA0KCQkJICAgICAgIHAt
PnRlbXBfZHJvcCwgKGVycm5vIDwgc3lzX25lcnIpID8gDQoJCQkgICAgICAg
c3lzX2Vycmxpc3RbZXJybm9dIDogIiIsIGVycm5vKTsNCgl9DQogICAgfQ0K
ICAgIA0KI2lmbmRlZiBLRUVQX1RFTVBfRFJPUA0KICAgIC8qIGNoZWNrIGZv
ciByYWNlIGNvbmRpdGlvbnMgaW52b2x2aW5nIHVubGluay4gIFNlZSBwb3Bf
dXBkdC5jICovDQogICAgLyogcy1kb3JuZXJAdWl1Yy5lZHUsIDEyLzkxICov
DQogICAgew0KICAgICAgc3RydWN0IHN0YXQgYnlOYW1lLCBieUZkOw0KICAg
ICAgaWYgKHN0YXQocC0+dGVtcF9kcm9wLCAmYnlOYW1lKSB8fCBmc3RhdChk
ZmQsICZieUZkKSB8fA0KCSAgYnlOYW1lLnN0X2lubyAhPSBteWJ1Zi5zdF9p
bm8pDQogICAgICB7DQogICAgICAgIHJldHVybiBwb3BfbXNnKHAsUE9QX0ZB
SUxVUkUsDQoJCSJNYWlsZHJvcCBiZWluZyB1bmxvY2tlZDsgdHJ5IGFnYWlu
LiIpOw0KICAgICAgfQ0KICAgIH0NCiNlbmRpZg0KICAgIA0KICAgIC8qICBB
Y3F1aXJlIGEgc3RyZWFtIHBvaW50ZXIgZm9yIHRoZSB0ZW1wb3JhcnkgbWFp
bGRyb3AgKi8NCiAgICBpZiAoIChwLT5kcm9wID0gZmRvcGVuKGRmZCwicisi
KSkgPT0gTlVMTCApIHsNCiAgICAgICAgKHZvaWQpY2xvc2UoZGZkKSA7DQog
ICAgICAgIHJldHVybiBwb3BfbXNnKHAsUE9QX0ZBSUxVUkUsIkNhbm5vdCBh
c3NpZ24gc3RyZWFtIGZvciAlcyAoJWQpIiwNCgkJICAgICAgIHAtPnRlbXBf
ZHJvcCwgZXJybm8pOw0KICAgIH0NCiAgICAvKiAgQWxsb2NhdGUgbWVtb3J5
IGZvciBtZXNzYWdlIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMgYW5kIHRoaXMg
aXMNCiAgICAgKiAgaXMgbm90IGRlbGV0ZWQgc2luY2UgYSBmYWlsdXJlLCBm
b3Igc29tZSByZWFzb24gaW4gdGhpcyBmdW5jdGlvbg0KICAgICAqICB3b3Vs
ZCByZXN1bHQgaW4gcHJvY2VzcyBkZWF0aC4gKi8NCiAgICBwLT5tbHAgPSAo
TXNnSW5mb0xpc3QgKiljYWxsb2MoKHVuc2lnbmVkKUFMTE9DX01TR1Msc2l6
ZW9mKE1zZ0luZm9MaXN0KSk7DQogICAgaWYgKHAtPm1scCA9PSBOVUxMKXsN
CiAgICAgICAgcmV0dXJuIHBvcF9tc2cgKHAsUE9QX0ZBSUxVUkUsDQogICAg
ICAgICAgICAiQ2FuJ3QgYWxsb2NhdGUgbWVtb3J5IGZvciBtZXNzYWdlIGxp
c3QuIik7DQogICAgfQ0KICAgIHAtPm1zZ19jb3VudCA9IDA7DQogICAgcC0+
ZHJvcF9zaXplID0gMDsNCg0KICAgIGlmIChteWJ1Zi5zdF9zaXplICE9IDAp
IHsgLyogTW9zdGx5IHRoaXMgaXMgZm9yIHJlZ3VsYXIgbW9kZS4gKi8NCglp
ZiAoaW5pdF9kcm9waW5mbyhwKSAhPSBQT1BfU1VDQ0VTUykgew0KCSAgICAv
KiBPY2N1cnMgb24gdGVtcF9kcm9wIGNvcnJ1cHRpb24gKi8NCgkgICAgZmxv
Y2soZGZkLCBMT0NLX1VOKTsNCgkgICAgY2xvc2UoZGZkKTsNCgkgICAgcmV0
dXJuKFBPUF9GQUlMVVJFKTsNCgl9DQoJLyogU3luYyB3aXRoIHN0ZGlvOyBz
aG91bGQgYmUgYXQgZW5kIGFueXdheSAqLw0KCSh2b2lkKWZzZWVrKHAtPmRy
b3AsIDBMLCBTRUVLX0VORCk7DQoJb2Zmc2V0ID0gZnRlbGwocC0+ZHJvcCk7
DQogICAgfQ0KDQojaWZkZWYgTUFJTE9DSw0KICAgIC8qIFNZU1YgbG9ja2lu
ZyBmb3IgdXNlcnMgbWFpbGJveC4qLw0KICAgIGlmIChtYWlsbG9jayhwLT51
c2VyLDEpICE9IDApDQogICAgICAgICAgICByZXR1cm4gcG9wX21zZyhwLFBP
UF9GQUlMVVJFLCAibWFpbGxvY2s6ICclcyciLCBwLT50ZW1wX2Ryb3ApOw0K
I2VuZGlmDQoNCiAgICAvKiAgT3BlbiB0aGUgdXNlcidzIG1haWxkcm9wLCBJ
ZiB0aGlzIGZhaWxzLCAgbm8gaGFybSBpbiBhc3N1bWluZyBlbXB0eSAqLw0K
ICAgIC8qIDx0b2RvPiBNYWlsIGRyb3AgaGFzIHRvIGJlIGNyZWF0ZWQgaWYg
b25lIGRvZXNuJ3QgZXhpc3QgZm9yIHNlcnZlcl9tb2RlLg0KICAgICAqIEJl
Y2F1c2UgcC0+ZHJvcCBpcyB1c2VkIGZvciBidWxsZXRpbnMuIFJpZ2h0IG5v
dyBpdCByZXZlcnRzIGJhY2sgdG8gDQogICAgICogcmVndWxhciBtb2RlIGlm
IGRyb3AgYm94IG9wZW4gZmFpbHMuIDwvdG9kbz4NCiAgICAgKi8NCiAgICBp
ZiAoKG1mZCA9IG9wZW4ocC0+ZHJvcF9uYW1lLCBPX1JEV1IpKSA+IDApIHsN
CiAgICAgICAgLyogTG9jayB0aGUgbWFpbGRyb3AgKi8NCiAgICAgICAgaWYg
KGZsb2NrIChtZmQsTE9DS19FWCkgPT0gLTEpIHsNCiAgICAgICAgICAgICh2
b2lkKWNsb3NlKG1mZCkgOw0KCSAgICBNQUlMVU5MT0NLKCk7DQogICAgICAg
ICAgICByZXR1cm4gcG9wX21zZyhwLFBPUF9GQUlMVVJFLCAiZmxvY2s6ICcl
cyc6ICVzICglZCkiLCBwLT5kcm9wX25hbWUsDQoJCQkgICAoZXJybm8gPCBz
eXNfbmVycikgPyBzeXNfZXJybGlzdFtlcnJub10gOiAiIiwgZXJybm8pOw0K
ICAgICAgICB9DQoNCglpZiAoIXAtPnNlcnZlcl9tb2RlKSB7DQoJICAgIC8q
IE5ldyByb3V0aW5lIHRvIGNvcHkgYW5kIGdldCBkcm9wYm94IGluZm8gYWxs
IGF0IHRoZSBzYW1lIHRpbWUgKi8NCgkgICAgbmNoYXIgPSBkb19kcm9wX2Nv
cHkocCwgbWZkLCBkZmQpOw0KDQoJICAgIGlmICggbmNoYXIgIT0gUE9QX1NV
Q0NFU1MgKSB7DQoJCS8qIHBvcF9kcm9wY29weSBoYXMgaW50ZWdyYXRlZCB0
aGUgaW5mbyBnYXRoZXJpbmcgcGFzcyBpbnRvDQoJCSAgIHRoZSBjb3B5IHBh
c3Mgc28gbm93IHRoZSBpbmZvcm1hdGlvbiBvZiB0aGUgZHJvcGZpbGUgaXMN
CgkJICAgaW5jb25zaXN0ZW50IGlmIHRoZXJlIGlzIGFuIGVycm9yLiAgTm93
IHdlIGV4aXQgaW5zdGVhZA0KCQkgICBvZiB0cnlpbmcgdG8gY29udGludWUg
d2l0aCB3aGF0IGlzIGF2YWlsYWJsZS4NCgkJKi8NCgkJKHZvaWQpZnRydW5j
YXRlKGRmZCwgKE9GRl9UKW9mZnNldCkgOw0KCQlnb3RvIGJhaWxvdXQ7DQoJ
ICAgIH0gDQoJICAgIGVsc2Ugew0KCQkvKiBNYWlsIHRyYW5zZmVycmVkISAg
WmVybyB0aGUgbWFpbCBkcm9wIE5PVywgIHRoYXQgd2UNCgkJICAgZG8gbm90
IGhhdmUgdG8gZG8gZ3ltbmFzdGljcyB0byBmaWd1cmUgb3V0IHdoYXQncyBu
ZXcNCgkJICAgYW5kIHdoYXQgaXMgb2xkIGxhdGVyICovDQoJCSh2b2lkKWZ0
cnVuY2F0ZShtZmQsIChPRkZfVCkwKSA7DQoJICAgIH0NCg0KCSAgICAvKiBV
bmxvY2sgYW5kIGNsb3NlIHRoZSBhY3R1YWwgbWFpbCBkcm9wICovDQoJICAg
IGZsb2NrKG1mZCwgTE9DS19VTik7DQoJICAgICh2b2lkKWNsb3NlIChtZmQp
Ow0KCX0gDQoJZWxzZSB7IC8qIFNFUlZFUl9NT0RFICovDQoJICAgIC8qIFNh
dmUgdGhlIHRlbXBvcmFyeSBkcm9wIEZJTEUgYW5kIGZpZCB2YWx1ZXMgKi8N
CgkgICAgcC0+aG9sZCA9IHAtPmRyb3A7DQoJICAgIGlmICgocC0+ZHJvcCA9
IGZkb3BlbihtZmQsInIrIikpID09IE5VTEwpIHsNCgkJcG9wX21zZyhwLFBP
UF9GQUlMVVJFLCJDYW5ub3QgYXNzaWduIHN0cmVhbSBmb3IgJXMgKCVkKSIs
DQoJCQlwLT5kcm9wX25hbWUsIGVycm5vKTsNCgkJZ290byBiYWlsb3V0Ow0K
CSAgICB9DQoJICAgIGlmIChpbml0X2Ryb3BpbmZvKHApICE9IFBPUF9TVUND
RVNTKQ0KCQlnb3RvIGJhaWxvdXQ7DQoJfQ0KICAgIH0NCiAgICBlbHNlIHsN
CgkvKiBSZXZlcnQgdG8gcmVndWxhciBvcGVyYXRpb24gd2hlbiB0aGVyZSBh
cmUgbm8gbWFpbHMgaW4NCgkgKiB1c2VycyBtYWlsIGJveC4gVGhpcyBpcyBm
b3IgdGhlIHNha2Ugb2YgYW55IGJ1bGxldGlucywgDQoJICogd2hpY2ggdXNl
cyBwLT5kcm9wICh0ZW1wX2Ryb3ApIGFuZCB0byBhbGxvdyBwb3BfdXBkdCB0
bw0KCSAqIGNvcHkgYmFjayB0byBvcmlnaW5hbCBtYWlsIGJveC4qLw0KCWlm
KHAtPnNlcnZlcl9tb2RlKSB7DQoJICAgIHAtPnNlcnZlcl9tb2RlID0gMDsg
DQoJfQ0KICAgIH0NCg0KICAgIGlmIChwLT5idWxsZGlyKSB7DQoJLyogUmVj
YWxjdWxhdGUgb2Zmc2V0ICovDQoJKHZvaWQpZnNlZWsocC0+ZHJvcCwgMEws
IFNFRUtfRU5EKTsNCglvZmZzZXQgPSBmdGVsbChwLT5kcm9wKTsNCgkvKiBJ
biBTZXJ2ZXJfbW9kZSwgcC0+ZHJvcCBjYW4gYmUgDQoJICogbnVsbChubyBt
YWlscyksIHBvcF9idWxsIHJlcXVpcmVzIGEgZHJvcCBoYW5kbGUuIDwvYnVn
PiAqLw0KCWlmKHBvcF9idWxsKHAsIHB3cCkgIT0gUE9QX1NVQ0NFU1Mpew0K
CSAgICAvKiBSZXR1cm4gcG9wIGRyb3AgYmFjayB0byB3aGF0IGl0IHdhcyBi
ZWZvcmUgdGhlIGJ1bGxldGlucyAqLw0KCSAgICAodm9pZClmdHJ1bmNhdGUo
cC0+c2VydmVyX21vZGUgPyANCgkJCSAgICAoKG1mZCA9PSAtMSk/ZGZkOm1m
ZCk6ZGZkLCAoT0ZGX1Qpb2Zmc2V0KTsNCgl9DQogICAgfQ0KI2lmZGVmIEJV
TExEQg0KI2lmZGVmIEdEQk0NCiAgICBnZGJtX2Nsb3NlKHAtPmJ1bGxfZGIp
Ow0KI2Vsc2UNCiAgICBkYm1fY2xvc2UocC0+YnVsbF9kYik7DQojZW5kaWYN
CiNlbmRpZg0KDQogICAgKHZvaWQpZnNlZWsocC0+ZHJvcCwgMEwsIFNFRUtf
RU5EKTsNCiAgICBwLT5zcG9vbF9lbmQgPSBmdGVsbChwLT5kcm9wKTsNCg0K
I2lmZGVmIERFQlVHDQogICAgaWYocC0+ZGVidWcgJiYgcC0+bXNnX2NvdW50
ID4gMCkgew0KICAgICAgICByZWdpc3RlciAgICBpOw0KCU1zZ0luZm9MaXN0
ICptcDsgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICBmb3IgKGkgPSAw
LCBtcCA9IHAtPm1scDsgaSA8IHAtPm1zZ19jb3VudDsgaSsrLCBtcCsrKQ0K
ICAgICAgICAgICAgcG9wX2xvZyhwLFBPUF9ERUJVRywNCgkgICAgIk1zZyAl
ZCB1aWRsICVzIGF0IG9mZnNldCAlZCBpcyAlZCBvY3RldHMgbG9uZyBhbmQg
aGFzICV1IGxpbmVzLiIsDQoJCSAgICBtcC0+bnVtYmVyLG1wLT51aWRsX3N0
cixtcC0+b2Zmc2V0LG1wLT5sZW5ndGgsbXAtPmxpbmVzKTsNCiAgICB9DQoj
ZW5kaWYNCiAgICBNQUlMVU5MT0NLKCk7DQoNCiAgICBpZiAocC0+c2VydmVy
X21vZGUpDQogICAgICAgIGZsb2NrKG1mZCwgTE9DS19VTik7DQoNCiAgICBy
ZXR1cm4oUE9QX1NVQ0NFU1MpOw0KDQogYmFpbG91dDoNCiAgICBNQUlMVU5M
T0NLKCk7DQogICAgZmxvY2sobWZkLCBMT0NLX1VOKTsNCiAgICBmbG9jayhk
ZmQsIExPQ0tfVU4pOw0KICAgIGNsb3NlKG1mZCk7DQogICAgY2xvc2UoZGZk
KTsNCiAgICByZXR1cm4oUE9QX0ZBSUxVUkUpOw0KfQ0KDQovKg0KICogVGhp
cyBmdW5jdGlvbiBlbXVsYXRlcyBmZ2V0cygpIGV4Y2VwdCB0aGF0IGl0IHJl
cGxhY2VzIHRoZSBOVUxMcyB3aXRoDQogKiBTUEFDRXMNCiAqLw0KDQpjaGFy
ICoNCm1mZ2V0cyggcywgc2l6ZSwgc3RyZWFtICkNCmNoYXIgKnM7DQppbnQg
c2l6ZTsNCkZJTEUgKnN0cmVhbTsNCnsNCiAgICBpbnQgYzsNCiAgICBjaGFy
ICpwID0gczsNCiAgICBpZiggc2l6ZSA8PSAwICkgew0KCXJldHVybiBOVUxM
Ow0KICAgIH0NCiAgICB3aGlsZSggLS1zaXplICYmICgoYyA9IGdldGMoc3Ry
ZWFtKSkgIT0gRU9GKSApIHsNCglpZiggKCpwID0gKGNoYXIpYykgPT0gJ1ww
JyApICpwID0gJyAnOw0KCWlmKCAqcCsrID09ICdcbicgKSBicmVhazsNCiAg
ICB9DQogICAgaWYoIHAgPT0gcyApIHJldHVybiBOVUxMOw0KICAgICpwID0g
J1wwJzsNCiAgICByZXR1cm4gczsNCn0NCg0KLyogU1RBUlQgQ1lHTlVTICov
DQoNCnZvaWQgY2xlYXJfb2xkKFBPUCAqcCkNCnsNCmludCBwc2ZvdW5kPTA7
DQpjaGFyIHBzbGluZVsyNTddOw0KY2hhciBwc3BpZF9zdHJbMTBdOw0KcGlk
X3QgcHNwaWQ9LTE7DQpGSUxFICpwcDsNCg0KcHNsaW5lWzBdPTA7DQpwc3Bp
ZF9zdHJbMF09MDsNCnBwPXBvcGVuKFBTX0NPTU1BTkQsInIiKTsNCndoaWxl
IChmZ2V0cyhwc2xpbmUsMjU2LHBwKSAhPSBOVUxMKSB7DQoJaWYgKHN0cnN0
cihwc2xpbmUsUFNfU0VBUkNIKSkgew0KCQlyZW1vdmVfZmlyc3QocHNsaW5l
KTsNCgkJc3NjYW5mKHBzbGluZSwiJXMgIixwc3BpZF9zdHIpOw0KCQlwc3Bp
ZD0ocGlkX3QpYXRvaShwc3BpZF9zdHIpOyANCgkJaWYgKGdldHBpZCgpPT1w
c3BpZCkgew0KCQkJcHNsaW5lWzBdPTA7DQoJCQlwc3BpZF9zdHJbMF09MDsN
CgkJCWNvbnRpbnVlOw0KCQkgIH0NCgkJcHNmb3VuZD0xOw0KCQlicmVhazsN
Cgl9DQogfSAvKiBlbmQgb2Ygd2hpbGUgKi8NCnBjbG9zZShwcCk7DQppZiAo
cHNmb3VuZD09MSkgew0KIC8qIHNlbmQgU0lHVEVSTSAqLw0KIHBvcF9sb2co
cCxQT1BfUFJJT1JJVFksIkdvdCBwaWQgJXMgZm9yIHVzZXIgJXMiLHBzcGlk
X3N0cixwLT51c2VyKTsNCiBpZiAoa2lsbChwc3BpZCwxNSkgPCAwKSB7DQog
IHBvcF9sb2cocCxQT1BfUFJJT1JJVFksIkZBSUxFRCBzZW5kaW5nIFRFUk0g
c2lnbmFsIHRvIHBvcHBlciBwcm9jZXNzICV1IGZvciAlcyAoJXMpIiwodW5z
aWduZWQgaW50KXBzcGlkLHAtPnVzZXIsc3RyZXJyb3IoZXJybm8pKTsNCiB9
DQogZWxzZSB7DQogIHBvcF9sb2cocCxQT1BfUFJJT1JJVFksIlNlbnQgVEVS
TSBzaWduYWwgdG8gcG9wcGVyIHByb2Nlc3MgJXUgZm9yICVzIiwodW5zaWdu
ZWQgaW50KXBzcGlkLHAtPnVzZXIpOw0KICBzbGVlcCgyKTsNCiAgfQ0KIH0g
LyogZW5kIG9mIGlmIHBzZm91bmQgKi8NCmVsc2Ugew0KIHBvcF9sb2cocCxQ
T1BfUFJJT1JJVFksIk5vIG9wZW4gcG9wcGVyIHByb2Nlc3MgZm91bmQgZm9y
ICVzIixwLT51c2VyKTsNCiB9DQoNCn0NCg0KDQovKioqIHJlbW92ZXMgZmly
c3Qgd29yZCBhdCBmcm9udCBvZiBzdHJpbmcgYW5kIG1vdmVzIHJlc3QgZG93
biAqKiovDQpyZW1vdmVfZmlyc3QoaW5wc3RyKQ0KY2hhciAqaW5wc3RyOw0K
ew0KaW50IG5ld3BvcyxvbGRwb3M7DQoNCm5ld3Bvcz0wOyAgb2xkcG9zPTA7
DQovKiBmaW5kIGZpcnN0IHdvcmQgKi8NCndoaWxlKGlucHN0cltvbGRwb3Nd
PT0nICcpIHsNCiAgICAgICAgaWYgKCFpbnBzdHJbb2xkcG9zXSkgeyBpbnBz
dHJbMF09MDsgIHJldHVybjsgfQ0KICAgICAgICBvbGRwb3MrKzsNCiAgICAg
ICAgfQ0KLyogZmluZCBlbmQgb2YgZmlyc3Qgd29yZCAqLw0Kd2hpbGUoaW5w
c3RyW29sZHBvc10hPScgJykgew0KICAgICAgICBpZiAoIWlucHN0cltvbGRw
b3NdKSB7IGlucHN0clswXT0wOyAgcmV0dXJuOyB9DQogICAgICAgIG9sZHBv
cysrOw0KICAgICAgICB9DQovKiBmaW5kIHNlY29uZCB3b3JkICovDQp3aGls
ZShpbnBzdHJbb2xkcG9zXT09JyAnKSB7DQogICAgICAgIGlmICghaW5wc3Ry
W29sZHBvc10pIHsgaW5wc3RyWzBdPTA7ICByZXR1cm47IH0NCiAgICAgICAg
b2xkcG9zKys7DQogICAgICAgIH0NCndoaWxlKGlucHN0cltvbGRwb3NdIT0w
KQ0KICAgICAgICBpbnBzdHJbbmV3cG9zKytdPWlucHN0cltvbGRwb3MrK107
DQppbnBzdHJbbmV3cG9zXT0nXDAnOw0KfQ0KDQovKiBFTkQgQ1lHTlVTICov
DQoNCg==
---171031142-37121570-919954547=:21504--
Date: Fri, 17 Sep 1999 19:51:17 +0200 (MET DST)
From: Carrer Yuri <yurj at dns.alfa dot it>
Subject: RE: .user.pop lock busy! Is another session active?
On Fri, 17 Sep 1999, Leonard Hermens wrote:
> > > Baing seriously, there's a bad interaction somewhere between Outlook
> > > Express and qpopper.
> >
> >uuuh....Why would it matter if the POP3 client was Outlook, Agent,
> >fetchmail, or anything for that matter? POP3 is POP3, nothing will change
> >that.
> >
> >More than likely people are simply timing out and trying to connect again
> >before your server times out. I would look at Qpopper's -T option.
> >
> >Steven Fletcher
> >stevenf at shellnet.co dot uk
>
> I can confirm that Outlook clients in the past (don't know about
> version 5) have caused a hang that Eudora (for example) did not
> exhibit when downloading a large attachment or when certain header
> lines were blank. This would lead to a SIGHUP on the qpopper because
> the Outlook client did/could not exit gracefully.
SIGHUP means a server crash?
Date: Fri, 17 Sep 1999 19:53:50 +0200 (MET DST)
From: Carrer Yuri <yurj at dns.alfa dot it>
Subject: RE: .user.pop lock busy! Is another session active?
On Fri, 17 Sep 1999, Steven Fletcher wrote:
> > I can confirm that Outlook clients in the past (don't know about
> > version 5) have caused a hang that Eudora (for example) did not
> > exhibit
>
> Yep; my point to Yuri exactly: If Outlook crashes and Eudora does not, with
> the same POP3 server, then what is to fault? Qpopper or Outlook?
Is not Outlook crashing, is qpopper not acting well sometimes. Is has to
delete the .user.pop lock file if the tcp/ip connection drop. Instead I
suspect it crashes and leaves the lock. Ant way to check if qpopper
crash?
Yuri
Date: Fri, 17 Sep 1999 11:40:43 -0700
From: Leonard Hermens <Leonard.Hermens at rcity dot com>
Subject: RE: .user.pop lock busy! Is another session active?
> SIGHUP means a server crash?
No, the qpopper has never "crashed" in 3 years of use at my former
employer's site. The SIGHUP is a "hangup" signal that terminates the
connection.
> Is not Outlook crashing, is qpopper not acting well sometimes. Is has to
> delete the .user.pop lock file if the tcp/ip connection drop. Instead I
>suspect it crashes and leaves the lock. Ant way to check if qpopper
>crash?
>
>> Yuri
In each instance we observed at our site, Outlook didn't crash, it
just didn't behave correctly under the conditions.
-- Leonard
Date: Sat, 18 Sep 1999 01:34:11 +0600
From: "S. Faruque Ahmed" <sfque at texasgroup dot net>
Subject: Re: Stuck pop files
Gentlemen,
Here's a thought, and a possible solution ...I quote from Qualcomm's site
for the new Qpopper 3.0 Public Beta at
http://www.eudora.com/freeware/qpop.html#BETA
"New features and bug fixes include: ...
A failure at some point in a transaction now releases all locks
explicitly...."
Although it is beta, you might want to give it a shot?
SFQ
At 18:58 17/09/99 +0200, you wrote:
>
>> Anyone have any idea why pop files would get stuck stuck stuck for a long
>> time? I have customers that call occasionally saying that they can't get
>> their mail, so they disconnect, call me, and I look, and there's still a
>> .username.pop file from like 5 minutes before. I can sit there and wait
>> and it doesn't go away. Eventually, later in the day I check and it's
>> gone.
>>
>> My line from inetd.conf is as follow:
>>
>> pop stream tcp nowait root /usr/libexec/tcpd popper
-T 60 -b /var/mail/bulldir
>>
>> I'd be cool to know why they're sticking, but it'd also be cool to know
>> how to kill the pop process so that it doesn't generate the poplock busy
>> when they're not even checking (like 30 minutes later!) Any help would be
>> appreciated...
>
> Heh, I'm not alone :-) I'm planning to switch to cucipop. Qpopper is too
> "corporate". :)
>
> Yuri
>
>
Date: Fri, 17 Sep 1999 15:52:39 -0500 (CDT)
From: James Sneeringer <jvs at ocslink dot com>
Subject: RE: .user.pop lock busy! Is another session active?
On Fri, 17 Sep 1999, Admin Mailing Lists wrote:
| I posted a patch a while back for the popper. When you connect it
| checks if your username has a popper process open, if you do, popper
| kills the former cleanly, then automatically opens a new one for you in
| the current session. Saves admins having to clean any stale pop files.
List archives are kept at:
http://www.pensive.org/mailing_lists/Archives/qpopper/
I found your fix at item #111 of:
http://www.pensive.org/mailing_lists/Archives/qpopper/Archive-1999-02-27.html
Note that it's MIME-encoded, so you'll need to extract the attachment and
run it through metamail or some other MIME decoder to get the file. It
appears to be from version 3.0b12, based on a later posting you made.
-James