[zorp] Stacking programs doesn’t work and how to modify POST parameters?

thomas.wenz at gmx-topmail.de thomas.wenz at gmx-topmail.de
Mon Jul 7 15:57:27 CEST 2008


Hi,

Thanks for taking you so much time to help me!

Your idea with self.rerequest_attempts setting to 1 is fantastic! I tried it and it moves 
the stacking so much up like I want it! Now I can do exactly what I described with POST!

The problem left is that stacking is still not done on GET-requests. Somehow, your 
suggested change didn't do anything because it's an OR-clause and if any of these 
checks fails it enters the section and ends. 
If I put a comment around this whole if-section, it's a little bit better: the program gets 
executed but
a) it's then not executed at the same time like with POST and self.rerequest_attempts=1
    so it seems like the alternative path with blobs can only be used with POST. I tried
    changing the has_data value in the http_fetch_request function but it didn't help 
    (probably there's more needed).
b) it's then executed but still no data (= no headers) is passed so it's quite useless. There
    must be another check somewhere later in the program which prevents sending the 
    headers when there's no data part.


I just noticed another minor problem:
A connection takes quite long if I set forge_port to Z_PORT_EXACT or 
Z_PORT_GROUP. Between the "Initiating connection" and "Established 
connection" it takes more than 3 seconds. If I set 
"self.transparent_mode = TRUE" this gets really slow because then the 
connection seems to be not reused, if it's set to false it goes really fast 
(only the first request and if there was no request for some time take 
the 3 seconds). Why is this so? Does it wait for the other connection 
to somehow time out before it can use the same port? With 
Z_PORT_ANY it works flawlessly...


And a more cosmetical issue I found during the investigation of the 
connection problem:
When I attach an strace to a process with a stacked program I get 
a huge filte (18MB) with thousands of 
"close(229284) = -1 EBADF (Bad file descriptor)"
At one point this process then calls the stacked proxy and seems
to normally continue. Is this normal? I've attached the log of this 
process below.

Thomas Wenz


7415  clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb6de3bf8) = 7416
7416  dup2(19, 0 <unfinished ...>
7416  <... dup2 resumed> )              = 0
7416  dup2(21, 1 <unfinished ...>
7416  <... dup2 resumed> )              = 1
7416  dup2(23, 3 <unfinished ...>
7416  <... dup2 resumed> )              = 3
7416  getrlimit(RLIMIT_NOFILE,  <unfinished ...>
7416  <... getrlimit resumed> {rlim_cur=250*1024, rlim_max=250*1024}) = 0
7416  close(4 <unfinished ...>
7416  <... close resumed> )             = 0
7416  close(5 <unfinished ...>
7416  <... close resumed> )             = 0

...

7416  <... close resumed> )             = 0
7416  close(24 <unfinished ...>
7416  <... close resumed> )             = -1 EBADF (Bad file descriptor)
7416  close(25 <unfinished ...>
7416  <... close resumed> )             = -1 EBADF (Bad file descriptor)
7416  close(26 <unfinished ...>
7416  <... close resumed> )             = -1 EBADF (Bad file descriptor)

....

7416  close(255999)                     = -1 EBADF (Bad file descriptor)
7416  execve("/bin/sh", ["/bin/sh", "-c", "/usr/bin/cat"], [/* 15 vars */]) = 0
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx


More information about the zorp mailing list