On Fri, Dec 23, 2016 at 05:21:57PM +0100, Willy Tarreau wrote: > Hi Baptiste, > > > On Fri, Dec 23, 2016 at 04:57:36PM +0100, Willy Tarreau wrote: > (...) > > The problem is that in order not > > to lose the port which was already parsed, we temporarily set the family to > > AF_INET and store the port in the sockaddr. The problem is that by doing so > > we lose the initial value of this family and we believe it was forced as if > > you had had "[email protected]", so the error is valid in str2ip2. If we > > think > > about it for a moment, we need to store the port only for : > > > > AF_INET (no change needed) > > AF_INET6 (no change needed) > > AF_UNSPEC > > > > It's the last case which causes trouble in fact. We only need to be able to > > store the information that the family is unknown and that we already have a > > port. We could even hijack an existing family for this but that's not clean. > > We cannot leave AF_UNSPEC here as it's used when we pass an fd. I'll have to > > think about it a bit :-/ > > Regarding this issue, I think that in fact we should decide to split the > server port apart from the address. After all, we're manipulating the port > and the address separately everywhere, we even have some extra settings in > other places (eg the fact that the ports are relative). I have not yet > analysed the impact of all of this but I think that's definitely something > we need to consider for the mid term. It will also remove most of the > "switch (family)" needed to retrieve/manipulate ports. > > What do you think ?
Also, I think that for the stable backport we can cheat. AF_UNSPEC is not used on the server side as we (obviously) don't support connecting to a file descriptor. So we should be able to return AF_UNSPEC with the port arbitrarily set in the IPv4 part. str2ip2() doesn't use the port, it only preserves it. We "just" need to be extra careful never to pass AF_UNSPEC with anything but zero in the port to str2ip2(). That still sounds tricky in the end :-/ Willy
