Дойдут ли до Winpkfilter’a некорректные пакеты?

Home › Forums › Discussions › Support › Дойдут ли до Winpkfilter’a некорректные пакеты?

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • January 2, 2007 at 7:06 pm #5080
    VK
    Participant

      Дойдут ли до Winpkfilter’a некорректные пакеты, например с неправильной контрольной суммой? Или они будут отброшены ОС еще до прихода на Winpkfilter?

      January 2, 2007 at 11:49 pm #6201
      Vadim Smirnov
      Keymaster

        Придут, если речь конечно не об Ethernet checksum (эти пакеты будут убиты на уровне сетевой карты).

        January 3, 2007 at 7:39 pm #6202
        VK
        Participant

          У меня такая ситуация. Жду первый из трех пакетов создания TCP соединения (SYN), добавляю к нему полезную нагрузку, изменяю размер в IP заголовке и пересчитываю контрольные суммы. Передаю пакет в функцию SendPacketToAdapter . На другом хосте получаю этот пакет (для перехвата использую CommView), но полезной нагрузки нет и контрольные суммы все верные, т.е. ситуация такая, как будто я ничего не менял, хотя буфер передаваемый в SendPacketToAdapter точно измененный. Пакет точно тот же, т.к. IP ID совпадают. То же самое со вторым ACK пакетом. Кто/что могло изменить (убрать добавленную мною полезную нагрузку) пакет? Сетевая карта? В RFC по TCP не написано, что пакеты “рукопожатия” должны обязательно быть без полезной нагрузки.

          И еще, предположим есть Хост 1 и Хост 2 на которых работают приложения, модифицирующее пакеты с помощью Winpkfilter. Кроме сетевых карт Хоста 1 и 2 кто-нибудь еще находится (т.е. может как-то обрабатывать пакеты) между Winpkfilter’ам Хоста 1 и 2?

          Вот нарисовал картинку для наглядности:
          http://img387.imageshack.us/img387/3055/questal3.jpg

          January 4, 2007 at 6:44 pm #6203
          Vadim Smirnov
          Keymaster

            У меня для одного заказного проекта требовалось приписывать хвост пакету из keyed MD5 (HMAC-MD5), на принимающей системе хвост проверялся и отрезался, пакет передавался стеку уже без довеска, то есть насколько я понимаю что-то вроде того что у Вас и требуется.

            Никаких проблем с исчезновением приписанного digest не наблюдалось, видимо у Вас где-то ошибка или стоит какой-то очень специфический софт с подобным же драйвером, сложно сказать что-то конкретное. Если конечно это повторяется на абсолютно чистых системах, значит что-то действительно сделано неправильно…

            January 4, 2007 at 7:27 pm #6204
            VK
            Participant

              да, скорее всего у меня где-то ошибка.

              @SerpentFly wrote:

              У меня для одного заказного проекта требовалось приписывать хвост пакету из keyed MD5 (HMAC-MD5), на принимающей системе хвост проверялся и отрезался, пакет передавался стеку уже без довеска, то есть насколько я понимаю что-то вроде того что у Вас и требуется.

              Если не секрет, как решалась ситуация когда длинна packet + digest > MAX_ETHER_FRAME. Такой пакет отправлялся двумя фрагментами?

              January 5, 2007 at 11:54 am #6205
              Vadim Smirnov
              Keymaster

                Если не секрет, как решалась ситуация когда длинна packet + digest > MAX_ETHER_FRAME. Такой пакет отправлялся двумя фрагментами?

                Не секрет. Длинна digest была 16 байт, соответственно MTU (протокол запрашивает MTU сетевой карты прежде чем посылать на нее пакеты) уменьшался на эти 16 байт и TCP/IP стек не послылал IP пакеты превышающие 1500-16 = 1484 байта.

                В WinpkFilter для этого есть функция SetMTUDecrement, она создает значение в реестре которое драйвер считывает при загрузке (требуется перезагрузка) и уменьшает MTU сетевых адаптеров на указанную величину.

              • Author
                Posts
              Viewing 6 posts - 1 through 6 (of 6 total)
              • You must be logged in to reply to this topic.