Bug 23486

Summary:	curl: IPv6 на ядре без IPv6
Product:	Sisyphus	Reporter:	Kirill A. Shutemov <kas>
Component:	curl	Assignee:	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

уже запушил, так что не забуду.