Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

(спасибо) Небольшой патч ядра

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 не маршрутизируется, в итоге виновато оказалось "Ускорение маршрутизации", я как-то совсем его из виду упустил.

ХМ. В ванильном ядре что на эту тему по патчам есть? Иначе придётся садиться раскручивать цепочку. Без пачта симптоматика какая?

А из ускорялок да, нужно выкусывать ipsec трафик если только не юзается оффлоад этого самого ipsec аппаратный (не поддержан нами в силу нежелания получать в тыкву от органов при ввозе и платить двойную мзду за фичу бесполезную для ЦУ).

 

Всё вижу что с этим патчем не так. В 3.4 он не нужен, при переносе из внутренней ветки зарапортовался не туда зафигачил. Пасиб.

Без патча - не собирается. Собственно, второе одним из последних патчей безопасности внесено, но в ядре wive оно лишним оказалось.

По ускорялкам можно отледно выкусить для HW и SW (мешает скорее всего только HW) собсно связанное с IPSEC см nf_conntrack_core.c по ключевому слову skip_offload. Там на самом деле уже есть костыёк с проверкой skb_sec_path и скипом всего оффлоада, но видимо в вашем случае его оказалось мало.

 

Цитата: AlexeyS от 29/08/2019, 00:12

Без патча - не собирается. Собственно, второе одним из последних патчей безопасности внесено, но в ядре wive оно лишним оказалось.

Не. Оно не в wive лишним. Оно по контексту в 3.4 быть не должно, эт я прошляпил с 4й ветки (которую на тот момент держал под x86) шлёпнул патч на MT. А оно возьми и наложись. Так и осталось висеть. Patch иногда странную сообразительность проявляет зараза. Там даже контекс другой а оно наложилось. Причём чёт я там видимо ещё совсем не проснуля в 13:43 =)))

Ладно разобрались щас откачу эт дело.

Хорошо, посмотрю. Хотя оно и так вполне приемлемо работает, на одном конце me1, на другом rt-n56u с Padavan. Надо будет скорость протестировать.

Ну а чего бы и не сделать лучше. =) Проверьте какой из оффлоадов ломает для начала. Если оба то в блок где проверяется skb_sec_path(skb)    придётся придумать что ещё доткнуть для идентификации что этот трафик через IPSEC бежит.

Скорее всего достаточно будет из is_local_svc проверять там же где и secpath (т.е. для всех оффлоадов скипать encripted payload а не только из HW, можно даже не распиливать отдельно прям как есть. Щас сделаю на проверку что бы проще было.

В гит на пробу. Терь выкусывает по protonum и из софт оффлоадов и из hard этого должно быть в теории достаточно.

Спасибо, завтра попробую, сегодня не до этого.

Ну как будет время. У меня вот тож с оным совсем напряжометр случился ;(

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: