-
This is probably due to -s 1500 and jumbo packets. Try using -s 0.
2009-03-19 15:28:57 UTC in ssldump
-
This is probably due to -s 1500 and jumbo packets. Try using -s 0.
2009-03-19 15:28:07 UTC in ssldump
-
When frox accepts a connection from a new client, it forks off a new process, that should immediately close the listening socket (but doesn't do that). This may result in frox continuing to listen on certain port even after having been killed.
A patch is available upon demand.
2008-02-07 16:54:55 UTC in Frox - a transparent ftp proxy and cache
-
Adds a new configuration variable - ActiveLocalPorts - which is a port range to use when choosing a source port for the active mode data connection to the client. Defaults to 20-21 (corresponding to a single port - 20) which is what required by the RFC.
2008-02-04 08:25:44 UTC in Frox - a transparent ftp proxy and cache
-
Some more leaks due to step up (the second handshake overwrites some pointers which are consequently lost).
Patch is attached.
2007-01-04 13:27:28 UTC in ssldump
-
In order to avoid problems with white spaces, I am attaching the patch below.
File Added: patch.
2007-01-04 09:47:19 UTC in ssldump
-
Some web servers (notoriously - IIS) tend to perform a 'double handshake' (aka 'step up protocol'). It causes a key material of the first handshake overwritten by the key material of the second handshake, thus never released. Here's the patch that fixes this:
*** ssldecode.c 2002-08-17 04:33:17.000000000 +0300
--- ssldecode.c.new 2007-01-04 11:44:17.000000000 +0200
***************
***...
2007-01-04 09:46:00 UTC in ssldump
-
Logged In: YES
user_id=1468321
Dear mgarnier,
Yes, you are correct on all counts: I didn't specify the
source file (it is indeed base/network.c), and the line
numbers are skewed due to additional changes I've made to
that file, as compared to the official version.
You are indeed supposed to place the fix in the place you
described: right after FREE(p->base).
2006-11-12 08:51:26 UTC in ssldump
-
packet_destroy is supposed to free all the memory
allocated in packet_copy. In practice, it only frees
the buffer, but not the packet structure. Fix:
203a204
> FREE(p);
(must come AFTER the buffer has been freed).
2006-10-31 12:40:36 UTC in ssldump
-
Whenever a terminating segment (either FIN or RST) is
missed by the SSLDump for some reason, the
corresponding session forever remains in the linked
list of sessions, causing substantial memory leakage
over time.
2006-08-13 08:43:15 UTC in ssldump
