Начитавшись инфы принялся разбирать пакет на части и повялось пара вопросов

Начну из далека, как я понял от сюда

Автор:
Дата: 12.03.07

наш буффер(буфферы)
идут по порядку(цепочкой или куском или и тем и тем), и так почитав спецификацию по протоколам имею:

struct ether_frame
{
    UCHAR dst[6];
    UCHAR src[6];
    USHORT type;
}; // 14 байт

struct ip_frame
{
    ULONG dummy[3];
    ULONG src;    
    ULONG dst;
    ULONG padding;
    ULONG data;
}; // 28 байт

делаю пинг на существующий адрес и в логе вижу:

[Sys CALL] NewNdisSend
virtual_buffer length: 14 of 14
MAC-> src: 0 c 29 3f e6 ca -> dst: 0 50 56 c0 0 8
virtual_buffer length: 20 of 28
IP-> src: 192.168.79.2 -> dst: 192.168.79.1

И вот вопрос 1-ый вопрос, 1 размер буффера(ethernet) все в норме, стыкуется 1 к 1, а вот второй буффер на 8 байт меньше, хотя иногда размер буффера совпадает со структурой и занимает все 28 байт

Дальше...
делаю пинг на НЕ существующий адрес, тут буффер не разбивается на цепочку буфферов, а висит сразу большим куском
Но вот в чем вопрос, чтобы получить IP, offset от начала буфера для структуры ip_frame будет не 14 байт(конец структуры ether_frame), а 16 байт, т.е появляются какие-то 2 байта между структурами ether_frame и ip_frame
И вот вопрос номер 2, что за загадочные 2 байта
Лог:

[Sys CALL] NewNdisSend
PhysicalBufferCount: 1
BufferCount: 1
TotalPacketLength: 42
virtual_buffer length: 42 of 14
MAC-> src: 0 c 29 3f e6 ca -> dst: ff ff ff ff ff ff
// и вот тут для корректных ip нужно к оффсету прибавить 2 байта, хотя при существующем пинге этого делать не надо
IP-> src: 192.168.79.2 -> dst: 0.0.0.0

D>И вот вопрос 1-ый вопрос, 1 размер буффера(ethernet) все в норме, стыкуется 1 к 1, а вот второй буффер на 8 байт меньше, хотя иногда размер буффера совпадает со структурой и занимает все 28 байт

у Вас какой то фантастичный ip_frame. Вы его что ли методом реверса получили??? Я думаю не найти в интернете описание ip пакета просто невозможно. Если в кратко, то пакет состоит из заголовка ( обычно 20 байт, может быть больше в специальных случаях ) и самих данных. Кроме того, не забудьте описания заголовков сетевых пакетов объявить с выравниванием 1 байт

D>Дальше...
D>делаю пинг на НЕ существующий адрес, тут буффер не разбивается на цепочку буфферов, а висит сразу большим куском
D>Но вот в чем вопрос, чтобы получить IP, offset от начала буфера для структуры ip_frame будет не 14 байт(конец структуры ether_frame), а 16 байт, т.е появляются какие-то 2 байта между структурами ether_frame и ip_frame
D>И вот вопрос номер 2, что за загадочные 2 байта

У меня есть подозрение, что вы за ip пакет приняли ARP — смотрите на тип эзернет фрейма ( 0x800 — ip, 0x806 — arp )

Здравствуйте, TarasCo, Вы писали:

TC>у Вас какой то фантастичный ip_frame. Вы его что ли методом реверса получили??? Я думаю не найти в интернете описание ip пакета просто невозможно. Если в кратко, то пакет состоит из заголовка ( обычно 20 байт, может быть больше в специальных случаях ) и самих данных. Кроме того, не забудьте описания заголовков сетевых пакетов объявить с выравниванием 1 байт

ip заголовок взят здесь, первые 12 байт я не использую поэтому
просто пропускаю их массивом ULONG dummy...
Выравнивание стоит #pragma pack(1)

TC>У меня есть подозрение, что вы за ip пакет приняли ARP — смотрите на тип эзернет фрейма ( 0x800 — ip, 0x806 — arp )

Хм, вывел в лог типы и получил интересный результат
Если пинг есть, тип кадра соответствет ip — 0x800, а вот когда пинга нет тип имеет загадочное число 0x1544

[Sys CALL] NewNdisSend
PhysicalBufferCount: 1
BufferCount: 1
TotalPacketLength: 42
virtual_buffer length: 42 of 14
type: 0x1544
MAC-> src: 0 30 18 a7 c 49 -> dst: ff ff ff ff ff ff
IP-> src: 192.168.124.199 -> dst: 0.0.0.0

D>ip заголовок взят здесь, первые 12 байт я не использую поэтому

Вы заголовок взяли, а читать не стали . Если бы прочли, то узнали, что поле, обозначенное в этой доке как Option + Padding, необязательно должно присуствовать в ip пакете. По факту, его очень редко используют и в весьма специфичных случаях.

TC>>У меня есть подозрение, что вы за ip пакет приняли ARP — смотрите на тип эзернет фрейма ( 0x800 — ip, 0x806 — arp )
D>Если пинг есть, тип кадра соответствет ip — 0x800, а вот когда пинга нет тип имеет загадочное число 0x1544

1544 — это ведь наверное десятичное число? Которое в hex выглядит как 0x608. Если вспомнить, что сетевые протоколы имеют отличный от платформы i386 порядок байт, то это число будет 0x806, что соответствует ARP протоколу.

Хорош нам ребусы загадывать. Нужно доки читать. На крайняк, поставить сниффер вроде wireshark и посмотреть на живой сетевой трафик.

TC>Хорош нам ребусы загадывать. Нужно доки читать. На крайняк, поставить сниффер вроде wireshark и посмотреть на живой сетевой трафик.

Благодарю за помощь, wireshark было самым удачным советом )