1 |
On Tuesday 27 January 2009 11:59:46 Tobias Klausmann wrote: |
2 |
> On Tue, 27 Jan 2009, Peter Alfredsen wrote: |
3 |
> > On Tue, 27 Jan 2009 16:47:50 +0100 Tobias Klausmann wrote: |
4 |
> > > glibc 2.9 uses a different way to implement getaddrinfo() which |
5 |
> > > triggers a race condition in most (if not all) Netfilter |
6 |
> > > firewalls that use connection tracking. glibc does nothing wrong |
7 |
> > > per se, it just triggers the condition. (technical details here: |
8 |
> > > http://marc.info/?l=linux-netdev&m=123304473331445) |
9 |
> > |
10 |
> > [...] |
11 |
> > |
12 |
> > > I don't have any experience with glibc upstream but pestering |
13 |
> > > them about this out of the blue might only cause a flame war |
14 |
> > > between kernel and glibc folks. Thus, I'm asking you, my fellow |
15 |
> > > devs (and the glibc and kernel teams specifically), what you |
16 |
> > > think is the best idea/course of action. |
17 |
> > |
18 |
> > The connection with IPv6 leads me to believe that this is |
19 |
> > http://bugs.gentoo.org/250468 |
20 |
> > http://sourceware.org/bugzilla/show_bug.cgi?id=7060 |
21 |
> |
22 |
> I doubt it: sometimes the lookups work, as this race is very |
23 |
> timing-critical. When experimenting, I had to go below 50 |
24 |
> microseconds between the two packets to actually trigger it plus |
25 |
> the forwarding machines always were multicore. Also, the content |
26 |
> is irrelevant. I implemented this myself sending the payloads |
27 |
> with sendto() and it didn't matter if I sent the A or AAAA query |
28 |
> first. |
29 |
> |
30 |
> That said, without seeing a tcpdump from those people with the |
31 |
> error described in those two bugs, I can not rule it out. |
32 |
|
33 |
the referenced bug generally deals with broken nameservers that cant handle |
34 |
the type of requests that glibc sends out (the requests are correct according |
35 |
to the relevant standards/RFCs, but apparently many DNS servers out there |
36 |
screw up with it due to the ipv4/ipv6 combo). |
37 |
|
38 |
the referenced thread seems to indicate even more the issue is in the |
39 |
netfilter code. |
40 |
|
41 |
> On the wire between the client and the firewall, this happens: |
42 |
> |
43 |
> a packet 1 is sent |
44 |
> b packet 2 is sent |
45 |
> c answer 1 is received |
46 |
> d answer 2 is received |
47 |
> |
48 |
> Sometimes d doesn't happen because b is lost in the firewall |
49 |
> along the way (where the race condition happens). |
50 |
|
51 |
does this affect actual userspace behavior ? in other words, does this lead |
52 |
to lost lookups and errors from the resolver ? |
53 |
-mike |