Hi Dave,
> > Next trick is to stop it from fucking up the responses...
>
> --- plugins/dnsproxy.c~ 2009-12-09 08:04:13.000000000 +0000
> +++ plugins/dnsproxy.c 2009-12-09 11:24:09.000000000 +0000
> @@ -150,7 +150,7 @@ static gboolean server_event(GIOChannel
> {
> struct server_data *data = user_data;
> struct request_data *req;
> - unsigned char buf[768];
> + unsigned char buf[4096];
> struct domain_hdr *hdr = (void *) &buf;
> int sk, err, len;
>
>
> However, that doesn't seem to be sufficient. When I run pidgin with
> Kerberos authentication, for example, something is sending EDNS0
> requests with the buffer size set to 2KiB, which isn't large enough for
> the SRV response (which in the case of our internal Kerberos setup is
> 2297 bytes).
>
> I found a dirty hack which makes it work -- we artificially bump the
> buffer size up to 4KiB when we see a request which is smaller. You
> wouldn't want to do this in a DNS proxy which serves arbitrary clients
> that might crash when they get a larger response than they asked for.
> But since we're only serving the local host and we know that glibc
> _does_ cope, we can probably get away with it for now.
>
> I think we really will want to do TCP though. Or at least find a way to
> ensure that glibc always sets the EDNS0 buffer size high enough,
> consistently.
my stomach has stopped turning around from this hack, but I think it
does help a lot. And until we see major crashes with it pushed it
upstream.
I had a play run with being verbose in the logs and put out a warning,
but that was spamming it too much to be acceptable.
Since glibc retries with TCP, it could also retry with a bigger buffer
size first. Or just use a bigger buffer to begin with.
Regards
Marcel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
