Hi, On Tue, Mar 27, 2012 at 06:08:21PM +0200, hapr...@serverphorums.com wrote: > I think Stud is working on IPV4, but reporting the PROXY line as TCP6 > > PROXY TCP6 ::ffff:127. 0.0.1 :: 52460 7302\r\n > > When Haproxy goes to hash it: > /* backend.c */ > case BE_LB_HASH_SRC: > if (s->req->prod->addr.from.ss_family == > AF_INET) > len = 4; > else if (s->req->prod->addr.from.ss_family == > AF_INET6) > len = 16; > > > It detects the protocol as IPv4, and only hashes the first 4 characters of > the source ip, even though the PROXY line says TCP6 > > I would guess then that the problem lies with stud?
It's kind of a difficult question. I don't know who's right or who's wrong here, it's even possible that both are right abd that both are wrong. In theory the protocol should be reported as it initially was. This is especially important for transparent proxying since you can only transparent proxy from/to a same address family. But what I'm suspecting is that Stud listens to IPv6 and not to IPv4, so clients connecting from IPv4 get an IPv6 address family which stud advertises as such. In a way this is embarrassing because it means that transparent proxying to IPv4-only servers would not work for IPv4 clients when passing through an IPv6-enabled stud. On the other hand, haproxy has no reason to consider this is IPv4. TCP6 is written so it is IPv6. And I have rechecked the code, I see no way it could fail. So hashing has to be performed on the whole address here. Our of curiosity, what version are you observing this on ? Willy
