Я работал над программой, которая использует интерфейс TUNTAP (в режиме TUN) на устройстве маршрутизации, которое работает поверх ядра Linux. Это протокол многоадресного туннелирования, и я пытаюсь отправить MLD-соединения в ядро через мое приложение, чтобы его можно было получить в другом месте. Тем не менее, даже несмотря на то, что я четыре раза проверял свои пакеты, отправляемые на интерфейс, ядро linux отбрасывает пакет, прежде чем он будет передан.
Утомительно я отслеживал путь пакета через linuxkernel пытается выяснить, почему его отбрасывают, и я думаю, что до некоторой степени выяснил, почему он не обрабатывается. Параметры Hop-by-Hop (содержащие параметр Router-Alert, необходимый для MLD) анализируются в net / ipv6 / ip6_input. c в функции ipv6_rcv, но вместо продолжения обработки пакета в ip6_rcv_fini sh пакет отбрасывается, поскольку NF_HOOK в конце функции ipv6_rcv каким-то образом интерпретирует пакет как обрабатываемый чем-то другим. (NF_STOLEN вместо NF_ACCEPT)
Как только функция ipv6_rcv завершает выполнение, что-то еще выполняет ip6_mc_input, (в net / ipv6 / ip6_input. c все еще), но отсюда параметры Hop-by-Hop не обрабатываются Это означает, что когда ядро завершает обработку протокола уровня 4, ему нечего обрабатывать, поскольку параметры Hop-by-Hop должны были обрабатываться заранее. Это означает, что ядро отбрасывает пакет из-за неизвестного протокола.
Я пытаюсь выяснить, что вызывает ip6_mc_input. Я много смотрел на эликсир, чтобы назвать его, но существует так много возможностей, так как он вызывается из указателя в структуре rt6_info, который трудно отследить, так как его используют многие вещи. Кто-нибудь знает что-нибудь, что могло бы помочь мне в моем поиске?
Объединения IGMP работают нормально, но материал IPv4, вероятно, очень похож, поэтому информация из этого контекста, вероятно, также будет полезна.
Для справки используется версия ядра linux v4.4.6