1 |
Hi! |
2 |
|
3 |
On Thu, 29 Jan 2009, Mike Frysinger wrote: |
4 |
> > The most visible effect (and the way we found out about it |
5 |
> > first) is a 5s hang on ssh connects. |
6 |
> |
7 |
> this is why i turn off dns lookup in all my sshd_config's |
8 |
> (well, not because of this bug, but because DNS lookup on ssh |
9 |
> can cause annoying delays). plus, that info is largely |
10 |
> useless: for the logged attempts from "bad" people, the dns is |
11 |
> usually screwed up / wrong / unavailable anyways. |
12 |
|
13 |
It's not on the daemon side but the client side. If you don't |
14 |
want to remember the IPs of all the hosts you might want to ssh |
15 |
into (at close to 3000, I don't), the client will have to make |
16 |
DNS lookups. Those are what delays the connection. |
17 |
|
18 |
> > Thing is: how long that timeout is is program dependant |
19 |
> > (whatever they use in select()). A recvfrom() simply hangs. I |
20 |
> > wrote a simple C program to do what glibc does (simplified |
21 |
> > for brevity): ... |
22 |
> |
23 |
> so glibc will not trigger hangs, just delays in some cases. |
24 |
|
25 |
Yup. Still: write a wrapper around ssh that will delay connects |
26 |
by five seconds on 50% of the cases. Use it for two or more weeks |
27 |
at work. That's how annoying it really is. |
28 |
|
29 |
> > A "quickfix" would indeed be using two different ports for the |
30 |
> > queries - but the bug in Netfilter would still be there. |
31 |
> |
32 |
> sure, the bug still exists in netfilter (kernel). but if we |
33 |
> can easily mitigate the effects seen by applications using |
34 |
> glibc's resolver code, that seems sane to me. i havent perused |
35 |
> the glibc resolver code in a while ... do you know if it can |
36 |
> easily be tweaked to use different ports, or would such a |
37 |
> change be invasive ? if the latter, well i guess we'll have to |
38 |
> suck it up. |
39 |
|
40 |
I tried understanding what glibc 2.9 does regarding dns lookups, |
41 |
but since it involves a rather complex (and probably quite |
42 |
clever) queueing mechanism, I'm not quite sure I wouldn't break |
43 |
more than I fix in doing so. |
44 |
|
45 |
Regards, |
46 |
Tobias |