From c8722d1ed9ac58561dd555b1c5b205e2f5f62432 Mon Sep 17 00:00:00 2001 From: bol-van Date: Wed, 28 Jan 2026 18:41:38 +0300 Subject: [PATCH] update docs --- docs/manual.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/manual.md b/docs/manual.md index 72e6466..237510a 100644 --- a/docs/manual.md +++ b/docs/manual.md @@ -1706,6 +1706,7 @@ conntrack работает только с tcp и udp, он не ведет уч В диссекте выдаются поля ip, ip6, payload. payload включает содержимое пакета после L3 заголовка. desync.track всегда отсутствует. + # С интерфейс nfqws2 Перед выполнением `--lua-init` C код выставляет базовые константы, блобы и C функции. @@ -2125,14 +2126,16 @@ IPPROTO_UDP, IPPROTO_ICMP, IPPROTO_ICMPV6 в зависимости от нал Режим ip6_preserve_next используется, если у вас специальная цель, требующая ручной крафтинг полей next protocol. В этом случае поля next в exthdr и ip6.ip6_nxt оставляются как есть. -Если вы реконструируете отдельно ipv6 header и не используете вариант ip6_preserve_next, невозможно автоматически узнать что вы хотите вписать в последний exthdr. -Туда вписывается ip6_last_proto, либо IPPROTO_NONE, если ip6_last_proto не задан. +Если не задан ip6_preserve_next и задан ip6_last_proto, ip протокол полезной нагрузки замещается на ip6_last_proto. badsum вынесен в реконструкцию, поскольку чексуммы tcp и udp считаются на базе всего IP пакета. В сумме участвуют элементы хедера ip/ip6, весь хедер tcp и сам пейлоад. Поэтому по отдельным частям гарантированно испортить чексумму невозможно. Что бы вы туда не вписали, существует маленькая вероятность (1/65536), что она окажется верной. +Пакет формируется на базе L3 заголовка, далее к нему пристыковывается L4 заголовок - tcp,udp,icmp, если присутствует, в конце идет payload. +В процессе реконструкции это всегда так - поля ip protocol не учитываются. Поэтому можно конструировать tcp,udp,icmp пакеты с измененным ip protocol. + #### standard rawsend Опции отсылки raw пакетов - rawsend_opts