Bug 23486

Summary: curl: IPv6 на ядре без IPv6
Product: Sisyphus Reporter: Kirill A. Shutemov <kas>
Component: curlAssignee: Anton Farygin <rider>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: normal    
Priority: P3 CC: glebfm, ldv, led, rider, wrar
Version: unstable   
Hardware: all   
OS: Linux   

Description Kirill A. Shutemov 2010-05-16 04:01:14 MSD
Есть машина на которой запущено ядро без поддержки IPv6. Если попытаться получить что-либо с хоста для которого на ряду с обычной IPv4, есть IPv6 запись в DNS, то всё плохо.

Для примера:

$ host ftp.arm.linux.org.uk 
ftp.arm.linux.org.uk is an alias for zeniv.linux.org.uk.
zeniv.linux.org.uk has address 195.92.253.2
zeniv.linux.org.uk has IPv6 address 2002:c35c:fd02::1
$ curl http://ftp.arm.linux.org.uk/                     
curl: (7) couldn't connect to host

В strace:

socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol)

Если собрать curl без поддержки IPv6, то всё работает.
Comment 1 led 2010-05-16 04:50:03 MSD
(В ответ на комментарий №0)
> $ curl http://ftp.arm.linux.org.uk/                     
> curl: (7) couldn't connect to host

а так:
curl --ip4 http://ftp.arm.linux.org.uk/
?
Comment 2 Kirill A. Shutemov 2010-05-16 14:44:12 MSD
так:
curl --ipv4 http://ftp.arm.linux.org.uk/

работает.
Comment 3 Andrey Rahmatullin 2010-05-16 15:50:35 MSD
Слегка в тему, из недавно прочитанного:

IPv6 is not enabled by default for any network activity in ejabberd.
This is because with the current state of ejabberd code it's impossible
to fall back to IPv4 if IPv6 is unavailable, and hence enabling IPv6
by default would immediately break things for users with IPv6 disabled
(see http://bugs.debian.org/503313 for more details).

Так и тут, видимо. Но решение, связанное с полным отключением v6, немедленно получит #23202 blocker.
Comment 4 Kirill A. Shutemov 2010-05-16 16:34:30 MSD
Проверка на работоспособность IPv6 тривиальна. Не вижу проблемы.
Comment 5 Anton Farygin 2010-05-16 22:46:32 MSD
Предложите его апстриму.
Comment 6 Kirill A. Shutemov 2010-05-17 01:57:33 MSD
Поковырялся немного в curl. Похоже проблема, уходит корнями в c-ares. Он некорректно обрабатывает AF_UNSPEC. Он останавливается, если нашёл хотя бы одну AAAA запись, хотя, по идее, должен продолжать смотреть и на A записи.

Если собрать curl без поддержки c-ares, то всё работает как следует.
Comment 7 Victor Forsyuk 2010-08-19 19:42:14 MSD
(В ответ на комментарий №6)
> Поковырялся немного в curl. Похоже проблема, уходит корнями в c-ares. Он
> некорректно обрабатывает AF_UNSPEC. Он останавливается, если нашёл хотя бы одну
> AAAA запись, хотя, по идее, должен продолжать смотреть и на A записи.

Да, совершенно верно: ошибка в c-ares. Однако, к сожалению, это не вопрос написания небольшого патча, который малой кровью пофиксит баг в c-ares. Вот ссылка на анализ кода c-ares:
https://bugzilla.redhat.com/show_bug.cgi?id=548396#c1
Вывод: "I believe the API would have to change to support mixed protocols."

> Если собрать curl без поддержки c-ares, то всё работает как следует.

Нужно собрать curl с опцией --enable-threaded-resolver. Это решит данную проблему. Так уже сделано в сборке Федоры.

В связи с этим перевешваю на curl.
Comment 8 Anton Farygin 2010-08-20 08:55:29 MSD
fixed (curl-7.21.1-alt2)
Comment 9 Dmitry V. Levin 2010-08-20 14:23:31 MSD
(In reply to comment #8)
> fixed (curl-7.21.1-alt2)

$ rpmquery -R libcurl-7.21.1-alt2 |grep cares
libcares >= 1.7.3-alt1
Comment 10 Anton Farygin 2010-08-20 14:42:14 MSD
зависимость поставлена ручками, уберётся при следующей сборке.
Comment 11 Dmitry V. Levin 2010-08-20 14:51:59 MSD
(In reply to comment #10)
> зависимость поставлена ручками, уберётся при следующей сборке.

Не забудешь?
Comment 12 Anton Farygin 2010-08-20 14:53:18 MSD
уже запушил, так что не забуду.