Есть такая замечательная структура _NDIS_PROTOCOL_CHARACTERISTICS, используемая протокольными драйверами. В этой же структуре есть коллбэк функции, которые вызываются Ndis или драйвером адаптера сетевого при разных событиях. http://msdn.microsoft.com/en-us/library/ms919698.aspx Интересует аргументы вот этого коллбэка: ReceiveHandler Вот что пишут о его аргументах в мсдн: Код (Text): pHeader [in] Points to the base virtual address of a range containing the buffered packet header. The address is valid only within the current call to ProtocolReceive. ... LookAheadBuffer [in] Points to the base virtual address of a range that contains LookaheadBufferSize bytes of buffered network packet data. This address is valid only within the current call to ProtocolReceive. Как видим приходит два буфера. Вопрос почему два, а не один и самое главное, что подразумевается под Код (Text): the buffered packet header Есть еще связанный вопрос, но я пожалуй напишу его в другом топике.
Пакет имеет заголовок (например, заголовок ethernet) и немного данных, чтобы понять, его это пакет или нет. Если, посмотрев на данные LookheadBuffer, протокол понимает, что пакет его, он возвращает NDIS_STATUS_SUCCESS, иначе NDIS_STATUS_NOT_ACCECPTED. Это каким-то образом влияет на приоритет протокольного драйвера в получении пакетов.
т.е. Если мы цепляемся к адаптеру ethernet, то имеем хидер пакета ethernet, если адаптер скажем isdn, то хидер пакет будет уже будет другим? Почему в хидер пакета не может оказаться ip header?
Насколько я понимаю, пакеты мы получаем от низлежащего драйвера порта (у него есть соответствующая ф-ия, которую он вызывает, когда на NIC приходит пакет). Разбирать протокол IP (или вообще любой протокол выше второго уровня) он не будет, т.к. это не его задача.
Откуда вы это все узнали? Можете ссылку дать на доку. В мсдн не просто, там этого описания нет. Просто не хочется облажаться. Нужна официальная дока, чтобы драйвер не выглядел кустарщиной, построенной на догадках. Спасибо.
Эээ... А что "это"? У меня довольно скромные познания в этой области. Все, что я прочитал -- это краткое описание примера NdisProt из WDK, сам пример NdisProt из WDK + MSDN. Насчет остального отчасти просто догадался. Про возвращаемое из ProtocolReceiveHandler значение написано в MSDN (правда, несколько туманно) -- там говорится про приоритеты. То, что пакет передается из низлежащего драйвера порта тоже, кажется, там. По крайней мере я где-то видел упоминание ф-ии NdisMIndicateReceive -- ее как раз и вызывает драйвер порта.
я про хидер пакета, где гарантия, что он не будет в себе включать еще, что-то, кроме ethernet пакета? Кстати, что он должен создержать весь ethernet packet или же только хидер etherneta? Я конечно могу посмотреть в дебагере, но если даже я 100 раз увижу только хидер эзернета, еще не значит, что в хидере пакета на 101 не окажется, что-то еще.
Я отнесся проще -- посмотрел пример NdisProt. Там идут проверки на размер полученного заголовка (если он меньше ethernet header, значит что-то не то). Где взять гарантию -- не знаю, у меня вообще ощущения, что все учатся по примерам, личному опыту и MSDN. Можно еще спросить на OSR Online -- там много хороших специалистов по NDIS. Но все общение на английском.
Прошу не путать теплое с мягким. Почитайте об ISDN и Ethernet и напишите в чем их разница. А разница там как между грибом и яблоком. Их даже сравнивать так как вы сравниваете нельзя. И второе - с чего вы взяли что хидер будет другим?) вы подключались и видели это? Может быть дело не в isdn а во вложении протоколов друг в друга (например вы увидели PPP хидер).
Про ISDN это я поторопился. FDDI, он по-моему на протоколе Token Ring, если не ошибаюсь 802.5 Пока вижу хидер эзернетовский нормальный, 14 байт. Вижу и в шарке и в дебаггере. Поправьте если не прав ethernet содержит в себе ppp, поэтому по любому хидер будет эзернетовский.
neutronion Ну в принципе верно. Просто формат кадра Ethernet немного изменяется (например добавляется LLC или что-то еще, в зависимости от стандарта). Именно поэтому вам и рекомендуют проверять длину кадра Ethernet. А логика примерно проста - если вы сели NDIS протокол драйвером на сетевуху которая работает по Ethernet (разъем у нее одноименный) - то таки да. Любой хидер будет Ethernet, но надо естественно проверять каким именно.