(спасибо) Небольшой патч ядра
Цитата: AlexeyS от 28/08/2019, 23:53diff --git a/linux-3.4.x/net/ipv6/fib6_rules.c b/linux-3.4.x/net/ipv6/fib6_rules.c index 216af3591..cf539e195 100644 --- a/linux-3.4.x/net/ipv6/fib6_rules.c +++ b/linux-3.4.x/net/ipv6/fib6_rules.c @@ -15,6 +15,7 @@ . #include <linux/netdevice.h> #include <linux/export.h> +#include <linux/route.h> . #include <net/fib_rules.h> #include <net/ipv6.h> diff --git a/linux-3.4.x/net/xfrm/xfrm_policy.c b/linux-3.4.x/net/xfrm/xfrm_policy.c index 931fab614..a6eef69a3 100644 --- a/linux-3.4.x/net/xfrm/xfrm_policy.c +++ b/linux-3.4.x/net/xfrm/xfrm_policy.c @@ -141,9 +141,6 @@ static inline struct dst_entry *xfrm_dst_lookup(struct xfrm_state *x, int tos, <-----><------><------>memcpy(prev_daddr, daddr, sizeof(*prev_daddr)); <----->} . -<----->if (IS_ERR(dst)) -<-----><------>dst_release(dst_orig); - <----->return dst; } .Наткнулся тут на пару мелких багов, при попытке включить IPsec.
В результате IPsec запустить удалось, только долго искал, почему TCP не маршрутизируется, в итоге виновато оказалось "Ускорение маршрутизации", я как-то совсем его из виду упустил.
diff --git a/linux-3.4.x/net/ipv6/fib6_rules.c b/linux-3.4.x/net/ipv6/fib6_rules.c index 216af3591..cf539e195 100644 --- a/linux-3.4.x/net/ipv6/fib6_rules.c +++ b/linux-3.4.x/net/ipv6/fib6_rules.c @@ -15,6 +15,7 @@ . #include <linux/netdevice.h> #include <linux/export.h> +#include <linux/route.h> . #include <net/fib_rules.h> #include <net/ipv6.h> diff --git a/linux-3.4.x/net/xfrm/xfrm_policy.c b/linux-3.4.x/net/xfrm/xfrm_policy.c index 931fab614..a6eef69a3 100644 --- a/linux-3.4.x/net/xfrm/xfrm_policy.c +++ b/linux-3.4.x/net/xfrm/xfrm_policy.c @@ -141,9 +141,6 @@ static inline struct dst_entry *xfrm_dst_lookup(struct xfrm_state *x, int tos, <-----><------><------>memcpy(prev_daddr, daddr, sizeof(*prev_daddr)); <----->} . -<----->if (IS_ERR(dst)) -<-----><------>dst_release(dst_orig); - <----->return dst; } .
Наткнулся тут на пару мелких багов, при попытке включить IPsec.
В результате IPsec запустить удалось, только долго искал, почему TCP не маршрутизируется, в итоге виновато оказалось "Ускорение маршрутизации", я как-то совсем его из виду упустил.
Цитата: sfstudio от 28/08/2019, 23:59ХМ. В ванильном ядре что на эту тему по патчам есть? Иначе придётся садиться раскручивать цепочку. Без пачта симптоматика какая?
А из ускорялок да, нужно выкусывать ipsec трафик если только не юзается оффлоад этого самого ipsec аппаратный (не поддержан нами в силу нежелания получать в тыкву от органов при ввозе и платить двойную мзду за фичу бесполезную для ЦУ).
ХМ. В ванильном ядре что на эту тему по патчам есть? Иначе придётся садиться раскручивать цепочку. Без пачта симптоматика какая?
А из ускорялок да, нужно выкусывать ipsec трафик если только не юзается оффлоад этого самого ipsec аппаратный (не поддержан нами в силу нежелания получать в тыкву от органов при ввозе и платить двойную мзду за фичу бесполезную для ЦУ).
Цитата: sfstudio от 29/08/2019, 00:09Всё вижу что с этим патчем не так. В 3.4 он не нужен, при переносе из внутренней ветки зарапортовался не туда зафигачил. Пасиб.
Всё вижу что с этим патчем не так. В 3.4 он не нужен, при переносе из внутренней ветки зарапортовался не туда зафигачил. Пасиб.
Цитата: AlexeyS от 29/08/2019, 00:12Без патча - не собирается. Собственно, второе одним из последних патчей безопасности внесено, но в ядре wive оно лишним оказалось.
Без патча - не собирается. Собственно, второе одним из последних патчей безопасности внесено, но в ядре wive оно лишним оказалось.
Цитата: sfstudio от 29/08/2019, 00:16По ускорялкам можно отледно выкусить для HW и SW (мешает скорее всего только HW) собсно связанное с IPSEC см nf_conntrack_core.c по ключевому слову skip_offload. Там на самом деле уже есть костыёк с проверкой skb_sec_path и скипом всего оффлоада, но видимо в вашем случае его оказалось мало.
По ускорялкам можно отледно выкусить для HW и SW (мешает скорее всего только HW) собсно связанное с IPSEC см nf_conntrack_core.c по ключевому слову skip_offload. Там на самом деле уже есть костыёк с проверкой skb_sec_path и скипом всего оффлоада, но видимо в вашем случае его оказалось мало.
Цитата: sfstudio от 29/08/2019, 00:23Цитата: AlexeyS от 29/08/2019, 00:12Без патча - не собирается. Собственно, второе одним из последних патчей безопасности внесено, но в ядре wive оно лишним оказалось.
Не. Оно не в wive лишним. Оно по контексту в 3.4 быть не должно, эт я прошляпил с 4й ветки (которую на тот момент держал под x86) шлёпнул патч на MT. А оно возьми и наложись. Так и осталось висеть. Patch иногда странную сообразительность проявляет зараза. Там даже контекс другой а оно наложилось. Причём чёт я там видимо ещё совсем не проснуля в 13:43 =)))
Ладно разобрались щас откачу эт дело.
Цитата: AlexeyS от 29/08/2019, 00:12Без патча - не собирается. Собственно, второе одним из последних патчей безопасности внесено, но в ядре wive оно лишним оказалось.
Не. Оно не в wive лишним. Оно по контексту в 3.4 быть не должно, эт я прошляпил с 4й ветки (которую на тот момент держал под x86) шлёпнул патч на MT. А оно возьми и наложись. Так и осталось висеть. Patch иногда странную сообразительность проявляет зараза. Там даже контекс другой а оно наложилось. Причём чёт я там видимо ещё совсем не проснуля в 13:43 =)))
Ладно разобрались щас откачу эт дело.
Цитата: AlexeyS от 29/08/2019, 00:35Хорошо, посмотрю. Хотя оно и так вполне приемлемо работает, на одном конце me1, на другом rt-n56u с Padavan. Надо будет скорость протестировать.
Хорошо, посмотрю. Хотя оно и так вполне приемлемо работает, на одном конце me1, на другом rt-n56u с Padavan. Надо будет скорость протестировать.
Цитата: sfstudio от 29/08/2019, 00:41Ну а чего бы и не сделать лучше. =) Проверьте какой из оффлоадов ломает для начала. Если оба то в блок где проверяется skb_sec_path(skb) придётся придумать что ещё доткнуть для идентификации что этот трафик через IPSEC бежит.
Скорее всего достаточно будет из is_local_svc проверять там же где и secpath (т.е. для всех оффлоадов скипать encripted payload а не только из HW, можно даже не распиливать отдельно прям как есть. Щас сделаю на проверку что бы проще было.
Ну а чего бы и не сделать лучше. =) Проверьте какой из оффлоадов ломает для начала. Если оба то в блок где проверяется skb_sec_path(skb) придётся придумать что ещё доткнуть для идентификации что этот трафик через IPSEC бежит.
Скорее всего достаточно будет из is_local_svc проверять там же где и secpath (т.е. для всех оффлоадов скипать encripted payload а не только из HW, можно даже не распиливать отдельно прям как есть. Щас сделаю на проверку что бы проще было.
Цитата: sfstudio от 29/08/2019, 00:57В гит на пробу. Терь выкусывает по protonum и из софт оффлоадов и из hard этого должно быть в теории достаточно.
В гит на пробу. Терь выкусывает по protonum и из софт оффлоадов и из hard этого должно быть в теории достаточно.
Цитата: AlexeyS от 29/08/2019, 01:01Спасибо, завтра попробую, сегодня не до этого.
Спасибо, завтра попробую, сегодня не до этого.
Цитата: sfstudio от 29/08/2019, 01:02Ну как будет время. У меня вот тож с оным совсем напряжометр случился ;(
Ну как будет время. У меня вот тож с оным совсем напряжометр случился ;(
