On 2014-11-26 02:02, Willy Tarreau wrote:
Hi Denys,
On Tue, Nov 25, 2014 at 10:06:54PM +0200, Denys Fedoryshchenko wrote:
Hi
It seems after adding rules:
acl youtubedst dst 173.194.40.0/24 173.194.41.0/24
acl youtube req_ssl_sni -m end googlevideos.com googlevideo.com
gvt1.com youtube.com
tcp-request connection reject if youtube
tcp-request connection reject if youtubedst
To frontend, i experienced segfault. gdb details follows:
#0 smp_fetch_ssl_hello_sni (px=0x6eae90, s=0x707c30, l7=0x0,
opt=<optimized out>, args=0x6aae40 <empty_arg_list>,
smp=0x7fffb5515a50,
kw=0x48cef7 "req.ssl_sni") at src/payload.c:279
279 bleft = chn->buf->i;
(gdb) print chn->buf
Cannot access memory at address 0x8
(gdb) print chn
$1 = (struct channel *) 0x0
(gdb)
Adding
chn = ((opt & SMP_OPT_DIR) == SMP_OPT_DIR_RES) ? s->rep : s->req;
+if (!chn)
+ return 0;
Helped for me.
A test is missing in this function to ensure that buffers are
allocated,
I'll take a look at it. In your case the problem is that you're using
a content-based sample fetch at the connection layer, so such
information
are not available. You can use this fetch in "tcp-request content"
rules
however. Didn't you get a warning when it started ?
Yes, i got warning, (and used later content). It might be critical alert
then, to not do one more if :)
Thanks for the report!
Willy
