Vadim Smirnov

Forum Replies Created

Viewing 15 posts - 1,156 through 1,170 (of 1,318 total)
  • Author
    Posts
  • in reply to: Modified packets sent from LAN to WAN across NAT (chcksm ok) #5827
    Vadim Smirnov
    Keymaster

      I would start analyses of this problem with the simplest packet which expected to be replied by MSTCP – ICMP ping. It has simple structure, so it must be easy to verify that the packet which you indicate from the name of the WAN interface after decapsulation is OK.

      I have one idea regarding problems with WAN you have, what MAC addresses do you have in the Ethernet header? If when operation over LAN it does not matter much, then over WAN you must use pair of MAC’s associated with particular WAN connection. In your case you must use MAC’s from the original (UDP?) packet received over WAN, but not the MAC’s that packet had before encapsulation or any other MAC’s. Otherwise NDISWAN fails to associate packet with the particular WAN connection and silently drops it.

      May be this is not your case, but this is one of the common problems with WAN. If it does not help then please provide more details and I hope we will be able to figure out the exact reason.

      in reply to: trial to full version… How upgrade ? #5825
      Vadim Smirnov
      Keymaster

        You can install the full version over (into the same folder) the trial one and reboot (both trial and full use the same registry keys to keep you rules and settings). Don’t forget to shutdown the trial version before installing the full one (otherwise some files may fail to be replaced).

        You can also export your rules to the file, uninstall trial, install full version, reboot and import rules from the file.

        in reply to: log disappear ? #5824
        Vadim Smirnov
        Keymaster

          One note, log size is limited and after the maximum size reached MMC applet removes the oldest entries from the log to release place for the new entries. Also, in order to update log screen press “Refresh” button in the toolbar. hope it helps.

          in reply to: Handle VLAN? #5818
          Vadim Smirnov
          Keymaster

            I had looked through the realization of VLAN in Linux and yes it can be implemented even on low cost adapters because all drivers are available in source code and you can easily increase the ethernet frame size in the NIC driver. But in Windows you can’t modify the source code of the driver for your network card and all packets will be truncated to 1514 bytes. You still can create VLAN for the cost of MTU (packets on the network will be still 1514 bytes but MTU will be decreased from 1500 to 1496 bytes). MUX sample driver from the DDK implements VLAN by this way. However, this implemetation won’t be compatible with Linux VLAN (which uses larger MTU), without additional tricks like decreasing MTU because any incoming packet over 1514 bytes will be truncated. So complete realization of VLAN in Windows is hardly possible without special NIC/drivers…

            in reply to: Handle VLAN? #5816
            Vadim Smirnov
            Keymaster

              Just found here http://support.intel.com/support/network/sb/cs-005897.htm that

              By default, Intel adapters strip the VLAN tag before passing it up the stack.

              In this case WinpkFilter receives 802.3 frame without VLAN tag and there is no way to access it without additional efforts. Even if you do the modifications mentioned on that page to turn off stripping tag then I’m not sure that TCP/IP stack will be able to process these packets with extended header normally.

              in reply to: Handle VLAN? #5815
              Vadim Smirnov
              Keymaster

                I assume you mean VLAN tagging (inserting 4 additional bytes into the ethernet header). Well, current version of WinpkFilter limits the size of Ethernet frame to 1514 bytes but there is no problem to extend it to 1518 (or even to 1522) bytes if network card supports such a frame size (does it?).

                However, does Windows TCP/IP stack supports VLAN? I just suspect that even if VLAN used the tags are stripped before packet reaches the TCP/IP stack…

                in reply to: Internet connection sharing help needed #5814
                Vadim Smirnov
                Keymaster

                  First of all I don’t think that there is any documented way to access ICS table.

                  However, if you filter on the internal interface(LAN) you can differentiate packets destined to the external network (Internet) from the packets destined to the ICS server by their destination IP address. It is hardly possible possible on the external interface (after NAT applied), however you still can use information gathered (build your own copy of NAT table) on the internal network card.

                  in reply to: NAT with XP firewall openned #5813
                  Vadim Smirnov
                  Keymaster

                    Windows XP firewall can be configured to do drop/pass the packets you want. On the other hand WinpkFilter driver processes packets before TCP/IP stack and built-in firewall so basically you can make routing yourself.

                    in reply to: Help needed ! #5812
                    Vadim Smirnov
                    Keymaster

                      It’s the length of ethernet (802.3) packet header which is 14 bytes.

                      #define ETHER_HEADER_LENGTH 14

                      in reply to: WinpkFilter to drop packets. LocalHost to resolve ProcessID. #5810
                      Vadim Smirnov
                      Keymaster

                        Нет готового нет, шаблон для 9x TDI фильтра есть например в VToolsD, так что в принципе сделать аналог можно. Шаблон для LSP есть в MSDN. Так что в принципе задача не слишком сложно решается.

                        in reply to: WinpkFilter to drop packets. LocalHost to resolve ProcessID. #5808
                        Vadim Smirnov
                        Keymaster

                          Для поддержки 98 нужно делать отдельный драйвер (там совсем по другому выстроен сетевой стек), или использовать LSP.

                          in reply to: WinpkFilter to drop packets. LocalHost to resolve ProcessID. #5806
                          Vadim Smirnov
                          Keymaster

                            Можно ли получить (купить) такую модификацию драйвера (LHMON я так понимаю), которая сообщает только про создание/удаление соединений и не логирует сами пакеты (это будет делать WinpkFilter)?

                            Можно при условии приобретения Developer или Source Code лицензии.

                            in reply to: WinpkFilter to drop packets. LocalHost to resolve ProcessID. #5804
                            Vadim Smirnov
                            Keymaster

                              Идея вроде ясна. Но, данное сопоставление оказывается ненадежным вовсе не из-за портов (типа, надо просто локальные сравнивать), а из-за того, что пакет от “LocalHost” приходит позже, чем пакет от “WinpkFilter”. Т.е. возможно заблокировать только последующие пакеты, с опозданием, упустив их некоторое количество. Вроде и ничего, но возможна путаница, когда неблокируемое приложение займет локальный порт сразу за тем, как там пыталось работать то приложение, пакеты которого должны дропаться.

                              Да правильно, я рекомендовал использовать TDI-фильтр (аналогичный LHMON) или LSP для сбора информации процесс<->адрес.порт. Но перехватывать именно пакет данных для построения таблицы соотвествий не нужно. До того момента как любой пакет достигнет NDIS а затем и TDI для него уже существуют ассоциированные структуры представляющие собой соединение (сокет) по которым можно сопоставить пакет процессу(с оговоркой если для пакета существует ассоциированный процесс). LHMON как сниффер не логирует (для user-mode клиента) создаваемые/уничтожаемые соединения но сами эти события отслеживает, чем меньше событий логируется тем меньше нагрузка на процессор (чтение каждой записи лога это переключение контекста). Кстати для одного заказчика делалась модификация драйвера который так же логировал возникновение соединений, для подобных фаервольных целей насколько я понимаю…

                              in reply to: WinPKFilter: MTU decrement broken ? #5803
                              Vadim Smirnov
                              Keymaster

                                I assume you have expirienced problem with the recently generated custom build. The update was sent to you, there was a registry configuration problem skipped by standard custom build tests. I’m really sorry that it has happened
                                with your build.

                                If you meet any problems with the custom build please contact support@ntkernel.com directly, so we can faster check the issue. Thanks for your patience.

                                in reply to: Urgent need of info #5802
                                Vadim Smirnov
                                Keymaster

                                  There are no know compatibility problems with XP built-in firewall.

                                  the firewall “eats” all the processing power

                                  Which process takes the most of processor time?

                                Viewing 15 posts - 1,156 through 1,170 (of 1,318 total)