Bug 23486 - curl: IPv6 на ядре без IPv6
: curl: IPv6 на ядре без IPv6
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/curl)
: unstable
: all Linux
: P3 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2010-05-16 04:01 by
Modified: 2010-08-20 14:53 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2010-05-16 04:01:14
Есть машина на которой запущено ядро без поддержки 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 From 2010-05-16 04:50:03 -------
(В ответ на комментарий №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 From 2010-05-16 14:44:12 -------
так:
curl --ipv4 http://ftp.arm.linux.org.uk/

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

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 From 2010-05-16 16:34:30 -------
Проверка на работоспособность IPv6 тривиальна. Не вижу проблемы.
------- Comment #5 From 2010-05-16 22:46:32 -------
Предложите его апстриму.
------- Comment #6 From 2010-05-17 01:57:33 -------
Поковырялся немного в curl. Похоже проблема, уходит корнями в c-ares. Он
некорректно обрабатывает AF_UNSPEC. Он останавливается, если нашёл хотя бы одну
AAAA запись, хотя, по идее, должен продолжать смотреть и на A записи.

Если собрать curl без поддержки c-ares, то всё работает как следует.
------- Comment #7 From 2010-08-19 19:42:14 -------
(В ответ на комментарий №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 From 2010-08-20 08:55:29 -------
fixed (curl-7.21.1-alt2)
------- Comment #9 From 2010-08-20 14:23:31 -------
(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 From 2010-08-20 14:42:14 -------
зависимость поставлена ручками, уберётся при следующей сборке.
------- Comment #11 From 2010-08-20 14:51:59 -------
(In reply to comment #10)
> зависимость поставлена ручками, уберётся при следующей сборке.

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