dproxy-devel

[Dproxy-devel] dproxy - remotely exploitable buffer overflow vulnerability

[Alexander K. <a....@cy...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

============================================
||| Security Advisory AKLINK-SA-2007-001 |||
||| CVE-2007-1465 (CVE candidate)        |||
============================================

dproxy - remotely exploitable buffer overflow
========================================================================

Date released: 20.03.2007
Date reported: 11.03.2007
$Revision: 1.1 $

by Alexander Klink
   Cynops GmbH
   a....@cy...
   https://www.cynops.de/advisories/CVE-2007-1465.txt
   (S/MIME signed: https://www.cynops.de/advisories/CVE-2007-1465-signed.txt)
   https://www.klink.name/security/aklink-sa-2007-001-dproxy-bufferoverflow.txt
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1465

Vendor: Matthew Pratt (Open Source)
Product: dproxy - a small caching DNS server
Website: http://dproxy.sourceforge.net
Vulnerability: buffer overflow
Class: remote
Status: unpatched (author is unresponsive)
Severity: high (arbitrary command execution as root)
Releases known to be affected: 0.1, 0.2, 0.3, 0.4, 0.5
Releases known NOT to be affected: dproxy-nexgen

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Overview:

dproxy suffers from a typical buffer overflow condition, which allows
an attacker to overwrite the stack.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Technical details:

In dproxy.c, the UDP packet buffer, which can be up to 4096 bytes long
is copied into a variable called query_string, which is at most 2048
bytes. As this is done using strcpy, the stack can be overwritten
which leads to arbitrary command execution.

Note that one can easily find out whether dproxy is running
using the fpdns tool (see http://www.rfc.se/fpdns/). dproxy also
seems to be used in a number of WLAN access points / routers, but
the version used there (at least in the Linksys WRT54AG, the Asus
WL500g and the Netgear DG834G) seems to be dproxy-nexgen, which is not
vulnerable to this attack.

Thanks to Dan Kaminsky, who provided me with the interesting statistics
that apparently only 20 out of about 2.000.000 DNS servers he scanned
are using dproxy. So this does not look like a major attack vector.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Exploit:

A MetaSploit Framework 2.7 exploit module is available from
https://www.cynops.de/downloads/metasploit/dproxy.pm

It has been tested successfully with both a Debian stable and an
Ubuntu system (with randomize_va_space=0).

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Workaround:

Drop packets to the destination UDP port 53 which are larger than
2048 bytes (which is a pretty large DNS query packet anyway).

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Communication:

* 13.03.2007: Author updated on vulnerable versions
* 11.03.2007: First problem report to author

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Solution:

Patch dproxy.c:

- --- dproxy-0.5/dproxy.c 2000-02-03 04:15:35.000000000 +0100
+++ dproxy-0.5.patched/dproxy.c 2007-03-13 13:07:53.000000000 +0100
@@ -105,7 +105,7 @@
   /* child process only here */
   signal(SIGCHLD, SIG_IGN);
 
- -  strcpy( query_string, pkt.buf );
+  strncpy( query_string, pkt.buf, sizeof(query_string) );
   decode_domain_name( query_string );
   debug("query: %s\n", query_string );

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Credits:

Alexander Klink, Cynops GmbH (discovery and exploit development, patch)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFF/7TXAEAIlkRL9AcRAhxmAJoDj8OT6wx+/CjKP3GOPb5+Uae/hQCffcoq
/2D9FAkTfhEJyBuUuTmarew=
=JIGg
-----END PGP SIGNATURE-----

[Dproxy-devel] dproxy: warnings patch

[Peter M. <mi...@ca...>]

Please find attached a patch to fix all of the compiler warnings in
dproxy-nextgen.

-- 
Regards
Peter Miller <mi...@ca...>
/\/\*        http://www.canb.auug.org.au/~millerp/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.

[Dproxy-devel] OS/2 port

[Dunhill S. S. <in...@du...>]

Dproxy NextGen is ported to OS/2, by Paul Smedley

http://smedley.info/dproxy-nexgen.zip

and works fine

(only i cannot get the dproxy.deny to work)
-- 

======================================================
*Dunhill Systems*, USA,
The Satellite Specialists for the Carribean
Nera, Idirect and Direcway Certified Installers
Phone: 352-437-1026

*Brant Systems*, Dominican Republic
Registered at INDOTEL
Phone: 809-437-8005

Visit our website at: http://www.dunhill.ws

[Dproxy-devel] MX Records

[Bryan R. <squ...@sa...>]

Working with dproxy a little bit more I have found out that MX records
are having problems (there was also another email on this list regarding
MX problems).  The ip address of my pop & smtp servers are missing from
the dproxy cache list.  If I manually add the ip addresses for these
servers into this list, dproxy works fine looking up the pop & smtp
servers - otherwise I am unable to send or receive email using Thunderbird.

I really need to start looking into DNS protocols and such, I'm not
really experienced in C/C++ right now either, so this is quite a task to
try and fix.  Any thoughts or direction would be awesome.

[Dproxy-devel] Abnormal Exiting of dproxy

[Bryan R. <squ...@sa...>]

I'm running into various problems with dproxy crashing on OpenBSD.  I
doesn't look like too many people are maintaning this project, the only
message to this list in the year 2005 was in May.  I have been
personally looking to use something on my internal network as a caching
DNS - even possibly using it in an embedded OpenBSD Router project I'm
working on.  Is anybody doing any hacking on the code still?  Anybody
have any ideas where these following problems are coming from.  I did
notice that the function in question (according to /var/log/messages)
the code uses strcpy instead of strncpy - that was just a quick look at
the code, dunno if that is the problem.  If anybody is doing any work,
or can give me advice in how to fix the problem - let me know...  (BTW,
my ISP is road runner and their DNS servers suck monkey balls most of
the time - that might be causing the problem, who knows)...

Debug Output from running dproxy -c /etc/dproxy.conf -d
...
[ 21941 ]: Cache hit
[ 21941 ]: enter cache_purge()
[ 21941 ]: cache_add_hosts_entreies()
[ 21941 ]: cache_add_hosts_entreies(): done
[ 21941 ]: Dumping list:
[ 21941 ]: cache_lookup_name(weather.noaa.gov)
[ 21941 ]: .......... weather.noaa.gov ---- 205.156.51.200
[ 21941 ]: Cache hit
[ 21941 ]: Dumping list:
[ 21941 ]: ..........  ---- 172.16.99.21
[ 21941 ]: Cache hit
Abort trap (core dumped)
...

/var/log/messages
...
Jun 10 22:32:21 chii dproxy: stack overflow in function
dns_decode_reverse_name
...

[Dproxy-devel] "Lotsa answers" appears then dproxy aborts.

[<su...@ib...>]

Dear All,

I have posted a message in the Sourceforge Open Discussion Forum but I go=
t no answers. Then I decide to post the message in this mailing list. See=
 below:
=20
I have a DSL-500T router of Dlink and I notice that when I run the Emule =
software the dproxy process aborts.=20
When dproxy aborts, the last message that appears in debug log is "Lotsa =
answers".=20
Take a look in the tailed file:=20
http://hstein.trix.net/lotsa_answers.txt=20

The problem occurs between 3-6 hours of modem activity. Someone got the s=
ame problem? Any hint?
=20
I guess that the router has the following dproxy packages intalled:=20
dproxy-nexgen_1.0-10_18_02.diff.gz=20
dproxy-nexgen_1.0.orig.tar.gz=20
dproxy-timeout-init.diff.gz=20
=20
Best Regads,=20
=20
Sumo=20

PS. For DSL-500T users: to see the modem debug log is required to kill th=
e original dproxy process (in telnet console), then start it again - all =
DNS requests will then shown in the terminal.=20
The command arguments are in the list of processes (ps command). Mine is:=
 /sbin/dproxy -c /etc/resolv.conf -d=20
("-d" is required).=20


Conhe=E7a o novo iBest Acelerado e aumente a velocidade da sua navega=E7=E3=
o em at=E9 5 vezes. O primeiro m=EAs =E9 gratuito. Basta acessar o endere=
=E7o http://www.ibest.com.br/acelerado para se cadastrar.

[Dproxy-devel] dproxy used in ASUS Wl-500g

[Stefan <mo...@ir...>]

[ This was meant to be a message to Matt, but I can't seem to find a
  valid email address for him. ]

On the dproxy webpage you mention that dproxy is used by the Netgear DG834
and by the wrt54g firmware replacement distributed at www.batbox.org.

First, I must point out that the thing at batbox.org is not a firmware (it
is a bunch of packages that are downloaded at runtime into RAM and thus lost
after reboot).

Second, the ASUS WL-500g claims to use the dproxy package as well (I wish
they made it possible to edit the /etc/hosts file to make better use of your
code), so you could list that one as well ;-)

Thank you for your work,


        Stefan

[Dproxy-devel] Re: dproxy-nexgen question

[Matthew P. <mat...@ya...>]

I did some hacking today. The results are in cvs under
the dproxy-nexgen branch.

--- "Sergio M. Ammirata"  wrote:
> 1) I would like to read the dns servers from the
> /etc/resolv.conf when
> the program starts instead of the config file (you
> mentioned a possible
> patch for this on the email archives but I did not
> find any).

There is now a new config option to enable this.

> 2) I would like to turn off the parallel query
> option. This brings
> unnecessary flooding to the dns servers.

OK what I did is have the next server in the list
queried whenever 2 seconds pass without a response.
Edit dproxy.h to change this value.

> 3) Is there a way to tell it not to take more than a
> specific amount of
> hard drive space? 

New option in dproxy.conf to enable this.

> 4) Would it be possible to just do an in memory
> cache and nothing else,
> with a limit on memory usage or number of cached
> queries?

New option in dproxy.conf. Note when the memory cache
gets full LRU entries are flushed to disk. This also
happens periodically.

It would be great to get some feedback from testers.

Matt


__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2

Re: [Dproxy-devel] 0.5 vs nexgen?

[Mark H. <mar...@ho...>]

On Sat, Aug 31, 2002 at 06:53:39PM -0700, Matthew Pratt wrote:
>Hows this for a solution: a hack to dproxy-nexgen to
>get its upstream DNS servers from /etc/resolv.conf
>instead of its config file?
>
>It could periodically (like every minute) check to see
>if /etc/resolv.conf has changed, and if it has, grab
>the nameservers out of there.

That would work.  I would probably want it to be configurable on the
time, though.  Because really it's only something that needs to be done
at boot time (for me anyway).  I don't often change /etc/resolv.conf
while booted, just in between boots.

Thanks,
- Mark

Re: [Dproxy-devel] 0.5 vs nexgen?

[Matthew P. <mat...@ya...>]

--- Mark Horn
<mar...@ho...> wrote:
> But this is not a problem in Linux.  Linux simply
> gets the DNS servers
> during network config using either DHCP or PPP, and
> it uses those servers
> because they're stored in /etc/resolv.conf.  What I
> was looking for with
> dproxy was a way to extend the use of the DHCP
> assigned DNS servers to
> my statically configured win4lin.

OK, I see what you want now.

Hows this for a solution: a hack to dproxy-nexgen to
get its upstream DNS servers from /etc/resolv.conf
instead of its config file?

It could periodically (like every minute) check to see
if /etc/resolv.conf has changed, and if it has, grab
the nameservers out of there.

How does that sound?

Matt


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

Re: [Dproxy-devel] 0.5 vs nexgen?

[Mark H. <mar...@ho...>]

On Thu, Aug 29, 2002 at 01:27:22AM -0700, Matthew Pratt wrote:
>> The 0.5 behavior did not require you to
>> pre-configure a DNS server in
>> dproxy's config, but nexgen does.  This behavior
>> does not really do
>> what I'm looking for, and I'm much more interested
>> in the 0.5 behavior,
>> which indirectly uses /etc/resolve.conf.
>
>Could you please explain a little more?

I use a program called win4lin on my laptop.  Win4lin is a program
like vmware which creates a virtual machine in linux that can runs
a windows OS.  In order to connect up to the network, I have set up a
"dummy" network w/in linux.  This looks exactly like an ethernet network,
but it's entirely abstracted w/in the linux kernel.  You could think
of it like this: my laptop is two computers (one linux and one windows)
connected together with a "virtual ethernet" (i.e. the dummy network).
When win4lin connects to the dummy network, it routes through my laptop
using iptables and NAT.

The problem is DNS.  Win4lin (on the dummy network) needs to have a
different DNS configuration depending on whether or not I'm at work
at home network, or if I'm on the road dialed up into the internet.
In the third case, I don't know in advance what the DNS servers will be.
In the other two cases, I can't access my work DNS servers from home and
vice versa.  So I end up having to reconfigure DNS in win4lin everytime
I switch networks.

But this is not a problem in Linux.  Linux simply gets the DNS servers
during network config using either DHCP or PPP, and it uses those servers
because they're stored in /etc/resolv.conf.  What I was looking for with
dproxy was a way to extend the use of the DHCP assigned DNS servers to
my statically configured win4lin.

So I can do this by setting up dproxy 0.5 on my linux box.  And then
statically pointing the DNS resolver in win4lin to use my linux box for
all DNS resolution.  Then it doesn't matter where I am connected, as long
as linux's /etc/resolv.conf is correct, win4lin can properly resolve DNS.

Using nexgen requires that I know in advance what all of my DNS servers
will be when I configure dproxy.  And I don't.

I've found lots of different DNS proxies that support the new strategic
direction of dproxy: dnrd, pdnsd, totd, dnscache.  But dproxy was the
only one that I found that supported what I actually wanted to do.
I'd really like to see it available as an option in nexgen to use
blocking gethostbyname().  For what I'm trying to do the speed thing
just is NOT that big of a deal.  However, I can see how it would not be
a good default setting.

>One thing that the nexgen version does that the 0.5
>version doesn't  is parallel queries. It will
>simultaneously query all the DNS servers listed in its
>config file and reply with which ever anwser happens
>to come back first.

You might want to consider doing something that pdnsd does.  It keeps
track of which dns servers are available.  Pdnsd will (by default) ping
test all DNS servers in its configuration, and only send queries to
those servers that are available.  Ping is the default test, but there
are others.

Just something to think about.

Thanks so much for your reply.
- Mark

Re: [Dproxy-devel] 0.5 vs nexgen?

[Matthew P. <mat...@ya...>]

--- Mark Horn
<mar...@ho...> wrote:
> Hello,
> 
> I've been looking for something like dproxy for some
> time now and am
> glad that I found it.  I have a question re:
> dproxy's behavior.
> 
> The behavior that is exhibited in 0.5 is what I was
> looking for.
> Specifically, I wanted a DNS proxy that could listen
> for requests on my
> private network, and then generate queries to one of
> several different
> networks each with different DNS servers.

If I'm understanding what you are saying, then the
nexgen version should be able to do this as well.
 
Just list the multiple servers in the config file. The
OS should take care of routing them over the correct
network.

> The 0.5 behavior did not require you to
> pre-configure a DNS server in
> dproxy's config, but nexgen does.  This behavior
> does not really do
> what I'm looking for, and I'm much more interested
> in the 0.5 behavior,
> which indirectly uses /etc/resolve.conf.

Could you please explain a little more?

> Is this a strategic design change or an experiment? 
> If this is strategic,
> will the 0.5 behavior be available in future
> releases?

It is a strategic design. Basically since
gethostbyname() is blocking we fork a new process for
each query. Unfortunately this leads to syncronisation
issues when writing back to the cache file, and is
quite a heavy weight solution.

I deemed it easier and more efficient to write my own
resolvers than work out these issues.

Having thought about this some more, it may not be so
hard to fix these issues, and if nexgen truly doesn't
suite your needs I could have a go at implementing
these.

One thing that the nexgen version does that the 0.5
version doesn't  is parallel queries. It will
simultaneously query all the DNS servers listed in its
config file and reply with which ever anwser happens
to come back first.

Matt


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

[Dproxy-devel] 0.5 vs nexgen?

[Mark H. <mar...@ho...>]

Hello,

I've been looking for something like dproxy for some time now and am
glad that I found it.  I have a question re: dproxy's behavior.

The behavior that is exhibited in 0.5 is what I was looking for.
Specifically, I wanted a DNS proxy that could listen for requests on my
private network, and then generate queries to one of several different
networks each with different DNS servers.

The 0.5 behavior did not require you to pre-configure a DNS server in
dproxy's config, but nexgen does.  This behavior does not really do
what I'm looking for, and I'm much more interested in the 0.5 behavior,
which indirectly uses /etc/resolve.conf.

Is this a strategic design change or an experiment?  If this is strategic,
will the 0.5 behavior be available in future releases?

Thanks,
- Mark

Also, please cc: me, as I'm not subscribed to the list.

[Dproxy-devel] Problem with dproxy not always caching lookups

[Martin W. <ma...@mw...>]

Hi,

I've just started running dproxy on my Linux router project box and =
there seems to be some problems with it not always caching the name =
lookups. It also seems to take a very long time to lookup the first =
address after that it works fine.

LRP is 2.2.16 kernel with 2.0 libs
dproxy is ver 0.5
pppd version 2.3.5 dial on demand

Thanks in advance

Martin

[Dproxy-devel] subscribe

[Peter N. <ni...@de...>]

					NIDD
--=20
________________________________________________________________________
The Debian Project. Debian booth@Linux Expo Road Show coordinator.
Linux Expo Road Show Timeline: 23.04.01 Prague, 24.04.01 Budapest,=20
25.04.01 Warsaw, 26.04.01-28.04.01 Moscow.=20
Conferences in all cities and exhibition in Moscow.
Visit http://people.debian.org/~nidd/LERS-TODO.html if you're intrested.
Mail contact: ni...@de...             Phone contact: 7-095-4281612
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Dproxy-devel] Patch for setuid

[Vesala T. <tv...@iw...>]

This patch adds 2 new conf options:
user_id and group_id - first one is username which is used to run dproxy
process and second one is same for group. Ownership of cache file is
changed to this pair before program calls setgid and setuid. Compiling
with FreeBSD and Linux (RH 6.1) is working correctly, default values are
root and root (because every system has own id for user/group 'nobody',
and at struct userid and groupid are defined to uid_t and gid_t) I'll put
autoconf scripts automatically to find user and group 'nobody'.

Oh yeah, this patch is to dproxy-nexgen(!)

And as I didn't hear anyone saying anything against autoconf scripts I'll
start to hack them...

Teemu =)

Re: [Dproxy-devel] dproxy-nexgen and userid

[Matthew P. <mat...@ya...>]

Vesala Teemu wrote:
> 
> Maybe I should aswer to myself:
> 
> I was running dproxy with id 'nobody' yesterday and it ran fine. setuid(2)
> was ran after bind, and cache file was set for 'nobody' by hands. I'm
> planning to create much nicer system than the 'dirty' hack I made
> yesterday.
> 
> Teemu =)
> 

Yes my bad. This was in dproxy-0.5 and I forgot to move it over to
nexgen.

And on the security note, I was considering writing a program that
spurted random junk into the dproxy input port so we can see if we can
overflow anything and get it to crash. Not an exhustive test my any
means, but better than nothing.

Lastly, I dont think I put a bound on how man DNS request can be waiting
in the queue, and so an attacker could flood your box with bogus
requests, and use all your RAM up. This will need to be fixed.

Cheers,
Matty

Re: [Dproxy-devel] dproxy-nexgen and userid

[Vesala T. <tv...@iw...>]

Maybe I should aswer to myself:

I was running dproxy with id 'nobody' yesterday and it ran fine. setuid(2)
was ran after bind, and cache file was set for 'nobody' by hands. I'm
planning to create much nicer system than the 'dirty' hack I made
yesterday.

Teemu =)

[Dproxy-devel] dproxy-nexgen and userid

[Vesala T. <tv...@iw...>]

Hi,

Is it necessary to run dproxy-nexgen with root id? I'm more concerned
about possible security risks it might cause. As far as I read the code
thru during weekend, I couldn't found any security problems, but
program grows and later there might be some problems (and I didn't do any
real testing with it, I just read the code) IMO any server shouldn't have
more priviledges than it REALLY needs.

(And btw, I compiled dproxy at FreeBSD 3.3. Only small change I had to do
was to add #include<sys/types.h> to all (or many) source files. (But I can
send patches during next week and if I have enough time, I'll implement
autoconf scripts to dproxy unless somone is against that idea) 

Teemu Vesala =)

[Dproxy-devel] dproxy-nexgen

[Matty <mat...@ya...>]

Hi all,

Sorry for such a long period with nothing happening.

I got an email from a user yesterday that said he was using 0.5
successfully at home but when he took it to work it bogged down quite a
fast machine.

I too have been realising how crappy 0.5 is.

So last nite I decided to rewrite dproxy from scratch ---> dproxy-nexgen
the result today.

This time there is no forking crap, its all event based. It simply listens
on port 53 UDP via a select and when ever a request/answer comes in the
packet is read and decoded.  Each packet is stored in a structure that
includes both the original packet and the decoded version as well as
source address and port.

If the packet is a new query and is not in the cahce then it is added to
linked list of outstanding queries and is passed untouched on to the
upstream nameserver.
All new requests are checked against the list for entries with the same
id. Obviously if a request with the same id is already in the list then
the new request is not added. This prevents duplicates in the list.

When and answer is received the list is checked for the query with the
same transaction ID and the answer is forwarded to the src of the query
untouched. It is also added to the cache.

All this avoids the blocking gethostbyname() function.

The cache subsystem is bascially untouched, but with the locking removed.
Ditto for the config system.
I haven't put in the ISDN or DHCP stuff, yet as I hope to rewrite those
bits too.
Overall the structure should be a bit less hackish than version 0.5,
mainly because I actually followed the RFCs a bit closer this time, and I
guess experience always helps. There is still some documentation of
fuctions to be done, and some of the functions in dproxy.c should probably
be moved into seperate files but it seems to work and is an improvement
over 0.5.

Anyway you can get it out of cvs or get a tar ball from the anonymous ftp
at ftp://dproxy.sourceforge.net

Give it a try and pass on any bugs or fixes,

Matty

[Dproxy-devel] CVS updates

[Andreas H. <hof...@in...>]

Hi all,

I checked in some changes to the CVS

- regular expresions in 'dproxy-deny' by Benjamin Close.
- bugix for cache2.c that cause dproxy to terminate.
- fixed some pedantic warnings for SCO's cc


Ciao
  Andreas

[Dproxy-devel] New version & anonymous ftp

[Andreas H. <hof...@in...>]

Hi all,

I have just checked in some changes to the 1.x development tree

- dproxy now drops root privilegs when it no longer need it
- fixed a bug in the last cvs version that caused an endless loop on
some queries.

I also set up the files for anonymous ftp, you'll find dproxy-0.5 in the
stable directory, 1.1x in the unstable tree.

BTW. if there are no negative reports on dproxy-0.5, we could move to
version 1.0

Ciao
  Andreas

[Dproxy-devel] Memory cache implemented

[Andreas H. <hof...@in...>]

Hi,

I just checked in the first try for memory cache and MX handling. These
features are experimental and need more testing.

MX records. 
-----------
To check that out, run configure with "--enable-mx' and recompile. This
switch will enable some config options in "dproxy.conf" and the mx
handling code. 

memory cache
------------ 
Benjamin sent me the linked list implementation (thanks!) and I
implemented the memory cache as discused in earlier postings. 

The 'purge_time' parameter in dproxy.conf will now control how long
entries are kept in memory.

At the moment, dproxy dumps the memory cache to the debug output on each
call to cache_purge, this will create _huge_ debug logs.


Next
----
We can now start to implement the 'refresh' stuff. Any new Ideas on that
?

What about the wildcard matching in the domain block code? Anybody who
like to implement that?



Ciao.
  Andreas

[Dproxy-devel] new cache stuff

[Andreas H. <hof...@in...>]

Hi all,

I integrated the new cache code into the main module now. Remember, the
file format for the cache has changed !

The new stuff seems to work so far, but it needs more testing.


Andreas

Re: [Dproxy-devel] dproxy 1.x

[Benjamin C. <li...@se...>]

On Thu, 10 Feb 2000, Andreas Hofmeister wrote:
<SNIP>
> combination of refcount and LRU time like this:
> 
> - every time an entry is referenced, we incremt the refcount.
> - every time the LRU time is < now - cache_expiration_time  , we decrement
> the refcount and set the LRU to now.
> - if the refcount drops to 0, rmove the entry.

I like it!

> --- Job #1 --
...disk cache stuff

> --- Job #2 ---
> We need a LL implementation. As we maybe want to re-use  it (refresh list
> ...), it should be in a separate module, i would suggest an api like this:

I'll do this. I enjoy lls. 

> typedef struct {...} list_t;
> tyepdef struct { list_t * list , ll_entry_t *pNext , cache_data_t * data }
> ll_entry;

The cache_data_t will could cause problems if the implementation of the
refresh list requires extra fields (ie a delay to rechech the host later
if it's down). Guess we can cross that hurdle when we get there though.

> We need to remove entries from the middle of the list, so we maybe should
> implement this as a double linked list. Some of the functions are trivial and
> could be implemented as macros.  (or inlines, but some compilers  can not use
> inline)

Macro's are the safer option, most compilers like them.
I think we can get away with a single linked list.
After all we have to go from the front to the end on our search anyway -
why not keep a pointer to the previous entry as we search.

I take it the ll will only be searched by the initial instance of dproxy.
Hence avoiding locks/memory sharing. If not let me know.

Cheers,
--

* Benjamin Close
* Be...@se...
* Web Page: http://users.senet.com.au/~benjsc