Hi Yves, On Thu, Sep 17, 2015 at 05:09:41PM +0200, Yves Van Wert wrote: > hi Willy, > > hmm maybe, but i have a second case at which i'm sure the client didn't > crash because the jsessionid didn't change before and after the crash. > I'll attach the logfile. > > At line 73 is where the trouble starts. Here the client switches from > backend ias01n to ias02n. But i'm sure the client didn't crash because at > the first lines in the logfile the forms is running with jsessionid > = TFnJV5HLQZphLHqR2Fd5NCwDTHmpyQ0fYMH3pZjJNNwvnJn6fQPt and after the switch > from backend the forms tries to continue with the same jsessionid. After a > few tries with that jsessionid the application comes to a stop and the user > has to relaunch te application resulting in a new jsessionid. > > any idea on how we can debug this ?
Well I agree it's suspicious enough. At this stage I'm afraid you'll have to take a network capture. For this, please use : tcpdump -i eth0 -s0 -w file.cap host <listening_ip> and port <listening_port> This file WILL contain sensitive trafic such as credentials and so on. You will be able to re-split the file to limit it to only the victim once you find its address in the logs : tcpdump -r file.cap -w bug.cap host <victim's ip> You may prefer to send me this file directly instead of sending it to the list (unless it's safe to post, of course). Maybe we'll find that for an unknown reason the server kills the cookie or the client presents a malformed cookie header or that haproxy fails to decode it in some cases. Regards, Willy
