Всем доброго времени суток.Появилась такая необходимость в сборке из сорцов пакета iptables для ванильного ядра версии 2.6.27.53.
Собирается всё через самосборный toolchain, состоящий из:
uClibc-0.9.29,
arm-linux-uclibc-{gcc,g++,cpp} - version (GCC) 4.2.4,
arm-linux-uclibc-{ld,ar,strip} - version GNU ld (GNU Binutils) 2.18процессор для которого это собиралось:
Processor : ARM920T rev 0 (v4l)
Микроконтроллер: AT91RM9200 http://www.gaw.ru/html.cgi/txt/ic/Atmel/micros/arm/AT91RM920...в качестве утилит используется busybox 1.18.5
Попытки сборки были со следующими версиями пакета iptables:
1.3.8 (не подошла из-за невозможности поддержки этой версии ядра) ,
1.4.2 - make заканчивался ошибкой:iptables_static-xtables.o: In function `ip6parse_hostnetworkmask':
/home/aidjek/iptables-1.4.2.orig/build/../xtables.c:1191: undefined reference to `in6addr_any'
collect2: ld returned 1 exit status
make[2]: *** [iptables-static] Error 1
также был найден баг по этому поводу http://bugzilla.netfilter.org/show_bug.cgi?id=569, который решили в более поздних версиях.1.4.3 - make заканчивался ошибкой:
./.libs/libxtables.a(xtables.o): In function `host_to_ip6addr':
xtables.c:(.text+0x3174): undefined reference to `ip6addr_to_numeric'
./.libs/libxtables.a(xtables.o): In function `xtables_ip6parse_any':
xtables.c:(.text+0x37a8): undefined reference to `in6addr_any'
collect2: ld returned 1 exit status
make[2]: *** [iptables-xml] Error 1после этого решил собрать 1.4.3.2.
1.4.3.2 - собралось без проблем:
sbin directory:
iptables: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), not stripped
iptables-multi: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), not stripped
iptables-restore: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), not stripped
iptables-save: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), not stripped
iptables-static: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), not stripped
lib directory:
libiptc.a: current ar archive
libiptc.la: libtool library file
libiptc.so: symbolic link to `libiptc.so.0.0.0'
libiptc.so.0: symbolic link to `libiptc.so.0.0.0'
libiptc.so.0.0.0: ELF 32-bit LSB shared object, ARM, version 1, dynamically linked, not stripped
libxtables.a: current ar archive
libxtables.la: libtool library file
libxtables.so: symbolic link to `libxtables.so.2.0.0'
libxtables.so.2: symbolic link to `libxtables.so.2.0.0'
libxtables.so.2.0.0: ELF 32-bit LSB shared object, ARM, version 1, dynamically linked, not strippedпосле попытки запуска на самом устройстве с ARM процессором, получаем следующую ошибку:
[root@Router7:/mnt/db/updates]# /mnt/db/iptables/sbin/iptables -L
iptables v1.4.3.2: can't initialize iptables table `filter': Invalid argument
Perhaps iptables or your kernel needs to be upgraded.ясно, что нужно копать в сторону модулей ядра:
lsmod
nf_conntrack_ftp 7296 0 - Live 0xbf054000
iptable_nat 5576 0 - Live 0xbf051000
nf_nat 17622 1 iptable_nat, Live 0xbf04b000
nf_conntrack_ipv4 14956 3 iptable_nat,nf_nat, Live 0xbf046000
nf_conntrack 67916 4 nf_conntrack_ftp,iptable_nat,nf_nat,nf_conntrack_ipv4, Live 0xbf034000
ipt_LOG 5440 0 - Live 0xbf02f000
iptable_raw 2208 0 - Live 0xbf032000
iptable_filter 2752 0 - Live 0xbf02d000
ip_tables 11472 3 iptable_nat,iptable_raw,iptable_filter, Live 0xbf029000
x_tables 15268 3 iptable_nat,ipt_LOG,ip_tables, Live 0xbf024000но тут видно что модули подгружены и в логах также никаких проблем:
Aug 8 10:16:46 Router7 user.info kernel: [250628.812500] ip_tables: (C) 2000-2006 Netfilter Core Teamпосле этого решил собрать самую последнюю стабильную версию iptables 1.4.12
1.4.12 - сборка прошла успешно, как и предыдуший вариант делалось скриптом вида:
#!/bin/bashexport STRIP=/PATH/projects/buildroot/build_arm/staging_dir/usr/bin/arm-linux-strip
export AR=/PATH/projects/buildroot/build_arm/staging_dir/usr/bin/arm-linux-ar
export CROSS_COMPILE=/PATH/projects/buildroot/build_arm/staging_dir/usr/bin/arm-linux-uclibc-
export CC=/PATH/projects/buildroot/build_arm/staging_dir/usr/bin/arm-linux-gcc
export CXX=/PATH/projects/buildroot/build_arm/staging_dir/usr/bin/arm-linux-g++
export LD=/PATH/projects/buildroot/build_arm/staging_dir/usr/bin/arm-linux-ld
export LDFLAGS="-L/PATH/projects/buildroot/project_build_arm/router_7/root/usr/lib -liconv"
export CPPFLAGS="-DARM_FPU_NONE=1 -DNO_UNALIGNED_ACCESS"
export CFLAGS="-mcpu=arm9 -msoft-float -mtp=soft -DDEBUG -ggdb3 -O0"../configure --prefix=/home/aidjek/iptables-1.4.12/build/bin \
--enable-devel \
--disable-ipv6 \
--enable-static \
--disable-shared \
--disable-libipq \
--build=i686-pc-linux-gnu \
--host=arm-linux \
--with-ksource=/PATH/projects/router_7/linux/linux-2.6.27.53-addно при запуске на самом устройстве, ошибки при запуске абсолютно такие же.
хотя сам бинарник iptables работает без проблем (help и version выдаёт)
/mnt/db/iptables/sbin/iptables -h
iptables v1.4.12Usage: iptables -[ACD] chain rule-specification [options]
iptables -I chain [rulenum] rule-specification [options]
iptables -R chain rulenum rule-specification [options]
iptables -D chain rulenum [options]
iptables -[LS] [chain [rulenum]] [options]
iptables -[FZ] [chain] [options]
iptables -[NX] chain
iptables -E old-chain-name new-chain-name
iptables -P chain target [options]
iptables -h (print this help information)Commands:
Either long or short options are allowed.
--append -A chain Append to chain
--check -C chain Check for the existence of a rule
--delete -D chain Delete matching rule from chain
--delete -D chain rulenum
Delete rule rulenum (1 = first) from chain
--insert -I chain [rulenum]
Insert in chain as rulenum (default 1=first)
--replace -R chain rulenum
Replace rule rulenum (1 = first) in chain
--list -L [chain [rulenum]]
List the rules in a chain or all chains
--list-rules -S [chain [rulenum]]
Print the rules in a chain or all chains
--flush -F [chain] Delete all rules in chain or all chains
--zero -Z [chain [rulenum]]
Zero counters in chain or all chains
--new -N chain Create a new user-defined chain
--delete-chain
-X [chain] Delete a user-defined chain
--policy -P chain target
Change policy on chain to target
--rename-chain
-E old-chain new-chain
Change chain name, (moving any references)
Options:
--ipv4 -4 Nothing (line is ignored by ip6tables-restore)
--ipv6 -6 Error (line is ignored by iptables-restore)
[!] --proto -p proto protocol: by number or name, eg. `tcp'
[!] --source -s address[/mask][...]
source specification
[!] --destination -d address[/mask][...]
destination specification
[!] --in-interface -i input name[+]
network interface name ([+] for wildcard)
--jump -j target
target for rule (may load target extension)
--goto -g chain
jump to chain with no return
--match -m match
extended match (may load extension)
--numeric -n numeric output of addresses and ports
[!] --out-interface -o output name[+]
network interface name ([+] for wildcard)
--table -t table table to manipulate (default: `filter')
--verbose -v verbose mode
--line-numbers print line numbers when listing
--exact -x expand numbers (display exact values)
[!] --fragment -f match second or further fragments only
--modprobe=<command> try to insert modules using this command
--set-counters PKTS BYTES set the counter during insert/append
[!] --version -V print package version.Делая вывод, что скорее всего проблема в модулях ядра: начал их пересборку с включенным дебаггингом, но положительных результатов это не принесло.
первые отличительные ошибки были:
Aug 5 15:59:12 Router7 user.warn kernel: [11974.734375] translate_table: size 632
Aug 5 15:59:12 Router7 user.warn kernel: [11974.750000] Finished chain 1
Aug 5 15:59:12 Router7 user.warn kernel: [11974.757812] Finished chain 2
Aug 5 15:59:12 Router7 user.warn kernel: [11974.765625] Finished chain 3
Aug 5 15:59:12 Router7 user.warn kernel: [11974.781250] get_entries: 668 != 672погуглив, нашёл такое решение http://www.spinics.net/lists/netfilter-devel/msg05839.html - но сильно с исходниками на Си не игрался, только пару значение поменял для XT_ALIGN, а точнее:
#define XT_ALIGN(s) (((s) + (__alignof__(struct _xt_align)-1)) \
& ~(__alignof__(struct _xt_align)-1))поменял интуитивно на
#define XT_ALIGN(s) (((s) + (__alignof__(struct _xt_align))) \
& ~(__alignof__(struct _xt_align)))потому что в исходниках пакета iptables было так:
#define XT_ALIGN(s) __ALIGN_KERNEL((s), __alignof__(struct _xt_align))но ИМХО возможно сделал бред, потому что после этого ошибки в логе ядра приобрели такой вид:
Aug 5 16:45:09 Router7 user.info kernel: [14732.476562] ip_tables: (C) 2000-2006 Netfilter Core Team
Aug 5 16:45:10 Router7 user.warn kernel: [14732.531250] translate_table: size 632
Aug 5 16:45:10 Router7 user.warn kernel: [14732.554687] Finished chain 1
Aug 5 16:45:10 Router7 user.warn kernel: [14732.562500] Finished chain 2
Aug 5 16:45:10 Router7 user.warn kernel: [14732.570312] Finished chain 3
Aug 5 16:45:10 Router7 user.warn kernel: [14732.578125] ip_tables: target: invalid size 4 != 8поигравшись ещё с настройками для XT_ALIGN получилось уже такие ошибки:
Aug 5 17:09:49 Router7 user.warn kernel: [16211.789062] translate_table: size 632
Aug 5 17:09:49 Router7 user.warn kernel: [16211.812500] Finished chain 1
Aug 5 17:09:49 Router7 user.warn kernel: [16211.820312] Finished chain 2
Aug 5 17:09:49 Router7 user.warn kernel: [16211.828125] Finished chain 3
Aug 5 17:09:49 Router7 user.warn kernel: [16211.835937] ip_tables: ERROR target: invalid size 38 != 32как конкретно избавиться от этой проблемы так и не понял.
Дошёл до абсурда, пересобрал busybox c поддержкой dpkg утилиты и попробовал поставить пакет http://packages.debian.org/ru/lenny/arm/iptables, но только потом увидел зависимость от libc6, которого конечно у меня нет.
Начал пересобирать модули с оригинальных исходников для ядра 2.6.27.53, но также не получил должных результатов.
почти во всех случаях сборки, проблем с модулями нет - они корректно подгружаются, в
[root@Router7:/mnt/db/updates]# cat /proc/net/ip_tables_namesвсё в порядке, но iptables упорно игнорирует наличие таблиц.
filterпосле этого решил пересобрать iptables c поддержкой дебаггинга, используя http://www.spinics.net/lists/netfilter-devel/msg00887.html и http://backreference.org/2010/06/11/iptables-debugging/, но также столкнулся с тем, что iptables не хочет писать ничего в kernel log.
Решил открыть тему типа баг http://bugzilla.netfilter.org/show_bug.cgi?id=734, но вряд ли ответ будет раньше, чем через месяц. Также там и представлены strace для этих ошибок и конфиг для ядра, но если нужно могу выложить их и тут
Ну после всего этого не найдя нормального решения, решил обратиться уже к тем, кто возможно сталкивался с подобными проблемами.
Судя по http://backreference.org/2010/06/11/iptables-debugging/, а точнее по последнему абзацу
[quote]Also, this could be generated in case you are trying to use a match that is not available, either because you did not load the proper module, it was not compiled into kernel or iptables failed to automatically load the module[/quote]возникает вопрос: а как вообще проверить то, что Iptables не может подгрузить модули? (хотя на самом деле модули он подгружает, потому что они не стоят в автозагрузке ядра)
В связи с этим следующий вопрос: может кто то включал дебаггинг по максимуму для iptables и модулей ядра для него.
Ну и может кто то собирал Iptables для таких нужд и возможно поделится опытом.
Буду очень признателен за любую помощь в этих вопросах и могу предоставить всё что попросите.
P.S. данный toolchain является рабочим, на нём были собраны другие пакеты, которые успешно работают. Также все вопросы по поводу обновления каких либо пакетов, не рассматриваются, т.к. это довольно трудоёмкая работа и нерентабельна для данного случая.
> 1.4.2 - make заканчивался ошибкой:
> 1.4.3 - make заканчивался ошибкой:
> 1.4.3.2 - собралось без проблем:Нам google://xtables.c undefined reference to in6addr_any
дал стальные руки-крылья:
http://lists.netfilter.org/pipermail/netfilter-buglog/2009-J...
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a... -- где-то там это и починили, видимо.> после попытки запуска на самом устройстве с ARM процессором, получаем следующую ошибку:
>[root@Router7:/mnt/db/updates]# /mnt/db/iptables/sbin/iptables -L
> iptables v1.4.3.2: can't initialize iptables table `filter': Invalid argument
> Perhaps iptables or your kernel needs to be upgraded.G://iptables "can't initialize iptables table `filter': Invalid argument"
http://lists.netfilter.org/pipermail/netfilter-buglog/2009-N...http://bugzilla.netfilter.org/show_bug.cgi?id=622
""On ARM these errors are usually caused by an ABI mismatch between userspace and kernel.""> ясно, что нужно копать в сторону модулей ядра:
Не модулей как таковых, а [несовпадения] интерфейсов между [собравшимися по-разному?] ядром и /sbin/iptrables, кажется.
...
Я как-то на подобные грабли попал: ставлю сборку debian amd64 (даже не "экзотический" arm) -- а на ней, опа!, /sbin/iptables не хочет и не может примерно с такими же непонятными ошибками. ...пошёл обратно на проверенный i386.> после этого решил собрать самую последнюю стабильную версию iptables 1.4.12
> 1.4.12 - сборка прошла успешно, как и предыдуший вариант делалось скриптом вида:
> --disable-ipv6 \
> но при запуске на самом устройстве, ошибки при запуске абсолютно такие же.
> хотя сам бинарник iptables работает без проблем (help и version выдаёт)
> Делая вывод, что скорее всего проблема в модулях ядра: начал их пересборку
> с включенным дебаггингом, но положительных результатов это не принесло.http://www.spinics.net/lists/netfilter-devel/msg00954.html
""This looks like an alignment problem.""
http://www.spinics.net/lists/netfilter-devel/msg01044.html
""search for "EABI iptables" shows a known arm iptables' problem""> первые отличительные ошибки были:
> Aug 5 15:59:12 Router7 user.warn kernel: [11974.781250] get_entries: 668 != 672
Нет, опыта или решения нет, только предположения из чтения гугля и "пальца в небо".
> P.S. данный toolchain является рабочим, на нём были собраны другие пакеты, которые
Такое впечатлние, что таковы исходники самого iptables: на "не очень популярных" комбинациях архитектур-ядер-компилеров-версий всякие выравнивания и размеры структур "плавают", бинарная совместимость "не наступает", а разработчики по факту "видят" только i386, а остальное лечат от симптомов~~~
---2iZEN: вот _это_ шоу :( http://www.opennet.me/openforum/vsluhforumID3/79595.html#201
Спасибо, за такой разжёванный ответ:
> http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a...
> -- где-то там это и починили, видимо.эту штуку ещё не пробовал - первым делом сейчас и проверю
> G://iptables "can't initialize iptables table `filter': Invalid argument"
> http://lists.netfilter.org/pipermail/netfilter-buglog/2009-N...
> http://bugzilla.netfilter.org/show_bug.cgi?id=622
> ""On ARM these errors are usually caused by an ABI
> mismatch between userspace and kernel.""Эти ссылки изучил вдоль и поперек, нарыл ещё вот такую вот штуку.
http://tech.groups.yahoo.com/group/ts-7000/message/19939но так и не смог разобраться что и с чем это едят - главное нашёл что оно у меня как бы есть:
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y>[оверквотинг удален]
> ядром и /sbin/iptrables, кажется.
> ...
> Я как-то на подобные грабли попал: ставлю сборку debian amd64 (даже не
> "экзотический" arm) -- а на ней, опа!, /sbin/iptables не хочет и
> не может примерно с такими же непонятными ошибками. ...пошёл обратно на
> проверенный i386.
> http://www.spinics.net/lists/netfilter-devel/msg00954.html
> ""This looks like an alignment problem.""
> http://www.spinics.net/lists/netfilter-devel/msg01044.html
> ""search for "EABI iptables" shows a known arm iptables' problem""Спасибо за ссылки, ещё раз копну, но в них я тоже уже лазил (
> Нет, опыта или решения нет, только предположения из чтения гугля и "пальца
> в небо".
>> P.S. данный toolchain является рабочим, на нём были собраны другие пакеты, которые
> Такое впечатлние, что таковы исходники самого iptables: на "не очень популярных" комбинациях
> архитектур-ядер-компилеров-версий всякие выравнивания и размеры структур "плавают",
> бинарная совместимость "не наступает", а разработчики по факту "видят" только i386,
> а остальное лечат от симптомов~~~ну у меня тоже стоит нормальная 32 битка, просто копать уже не знаю куда.
Ладно пробегусь ещё раз по ссылкам, может что то интересное для себя открою.
>Спасибо, за такой разжёванный ответ:Да, ответа-то как такового нет, к сожалению.
Только "ощущение", что "всё плохо" и гугль по диагонали (=немного гугль-фу и чтения на нерусском)~~~
>> -- где-то там это и починили, видимо.
> эту штуку ещё не пробовал - первым делом сейчас и проверюПробовал-пробовал... Ж) Я имел в виду, что починили где-то между 1.4.2/1.4.3 и 1.4.3.2, поэтому последний "уже" собрался. И это более другая ошибка, нежели чем та, что ниже.
> Эти ссылки изучил вдоль и поперек, нарыл ещё вот такую вот штуку.
> но так и не смог разобраться что и с чем это едят
> - главное нашёл что оно у меня как бы есть:
> CONFIG_AEABI=y
> CONFIG_OABI_COMPAT=y
>>lists/netfilter-devel/msg00954.html
>> ""This looks like an alignment problem.""
>>lists/netfilter-devel/msg01044.html
>> ""search for "EABI iptables" shows a known arm iptables' problem""Гм, [по ощущениям,] кроме "плавающих" элайнментов и размеров структур у iptables-а (в ядре против юзерспейса -- как, видимо, у меня было с amd64), на ARM-ах и своих проблем хватает, с этими их xxxABI.
> ну у меня тоже стоит нормальная 32 битка, просто копать уже не знаю куда.
> Ладно пробегусь ещё раз по ссылкам, может что то интересное для себя открою.Может, имеет смысл "танцевать" от какой-нибудь из _работающих систем сборки -- начать с их версий ядра+iptables. Посмотреть, как они добиваются, чтоб оно работало.
OpenEmbedded, Debian Crush, cyanogenmod, ...
>>Спасибо, за такой разжёванный ответ:
> Да, ответа-то как такового нет, к сожалению.
> Только "ощущение", что "всё плохо" и гугль по диагонали (=немного гугль-фу и
> чтения на нерусском)~~~Главное что откликнулся помочь, а то у меня уже котелок не варит. (7х8 часов над этим мучаюсь)
> Пробовал-пробовал... Ж) Я имел в виду, что починили где-то между 1.4.2/1.4.3 и
> 1.4.3.2, поэтому последний "уже" собрался. И это более другая ошибка, нежели
> чем та, что ниже.Ну я попробую руками исходники поправить, может и 1.4.2 заработает ))
> Гм, [по ощущениям,] кроме "плавающих" элайнментов и размеров структур у iptables-а (в
> ядре против юзерспейса -- как, видимо, у меня было с amd64),
> на ARM-ах и своих проблем хватает, с этими их xxxABI.я прочитал внимательно, что же там такое может быть интересное: в основном читалось отсюда http://wiki.debian.org/ArmEabiPort
и вот что у меня получилось:
t405VM:/home/aidjek/iptables-1.4.12/build/bin/sbin# readelf -h iptables | grep Flags
Flags: 0x202, has entry point, GNU EABI, software FPreadelf -h /home/aidjek/iptables-1.4.3.2/build/bin/sbin/iptables | grep Flags
Flags: 0x202, has entry point, GNU EABI, software FPreadelf -h net/ipv4/netfilter/ip_tables.ko | grep Flag
Flags: 0x200, GNU EABI, software FPreadelf -h net/ipv4/netfilter/ip_tables.ko | grep Flag
Flags: 0x200, GNU EABI, software FPт.е. всё собрано с поддержкой EABI - а значит ИМХО тут проблем не должно быть.
> Может, имеет смысл "танцевать" от какой-нибудь из _работающих систем сборки -- начать
> с их версий ядра+iptables. Посмотреть, как они добиваются, чтоб оно работало.Возможно ты и прав, но из работающих сборок я только нашёл:
http://www.altlinux.org/Ports/arm/officeserver
ну и кучу вариантов, сам скачай, сам собери, сам проверь )ещё сделал похожую систему на scratchbox'e - но там добрался только до подгрузки модулей ядра, дальше не осилил, пока )
как мне кажется нужно копать в сторону исходников для x_tables, что то типа этого: http://www.spinics.net/lists/netfilter-devel/msg05839.html потому что в логах, которые я приводил выше, видно что фигня скорее всего и виновата
Всем доброго времени суток.После продолжительного разговора с Jan Engelhardt, человеком который в развитии iptables занимает далеко не последнее место, была найдена следующая особенность http://bugzilla.netfilter.org/show_bug.cgi?id=734:
отличие в kernelspace и userspace некоторых типов данных и в особенности:
kernelspace:
TYPE SIZEOF ALIGNOF
uint64_t 8 8
userspace:
TYPE SIZEOF ALIGNOF
uint64_t 8 4По его словам именно эти значения должны повлиять на ход работы iptables в лучшую сторону.
В связи с этим возникли пару непонятных для меня вопросов.
Ясно, что менять лучше значения для userspace, т.к. kernelspace может повлиять на работу остальных приложении, но каким образом данный тип данных можно изменить?
В моём понимании этот тип данных определяется при компиляции gcc и вероятнее всего в некотором файле stdint.h.
К сожалению toolchain в котором это всё собиралось имеет в себе несколько таких файлов - но я смог вытащить из самого бинарника для gcc следующие данные:
/projects/buildroot/toolchain_build_arm/gcc-4.2.4/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c,c++ --with-sysroot=/projects/buildroot/build_arm/staging_dir --with-build-time-tools=/projects/buildroot/build_arm/staging_dir/usr/arm-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/projects/buildroot/toolchain_build_arm/gmp --with-mpfr=/projects/buildroot/toolchain_build_arm/mpfr --enable-threads --disable-multilib --with-float=soft --with-tune=arm920tК сожалению, меня не натолкнуло на мысль, ничего об изменении данного типа.
Может грамотные программисты на С/C++ смогут натолкнуть меня на мысль о том, куда копать по этим вопросам.
Заранее спасибо.
Все проблему решил полной пересборкой toolchain'a, используя этот мануал http://cross-lfs.org/view/clfs-embedded/arm/index.htmlСобрал самую последнею версию iptables 1.4.12.1
Всё работает без проблем.
Тему можно закрывать.