дамп ETHERNET

[Guest]

Вопрос такой.

Делаю устройство по типу автоматической пинговалки на ПЗУ. (см обзор 77)

Только на более современной элементной базе. Сей час затык в том что переданный пакет карта отбрасвает как ошибочный. Похоже ошибка в поле СRC. Нужен образ пакета ETHERNET вместе СRC.

Может у кого есть такие дампы. А может у когото есть файлы прошивки ПЗУ для пинговалки.

сейчас дамп такой (получен синтезом по описанию стандарта

frame ETHERNET)

 

 

{ preamble } { Start Frame}

0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAB

{ dest mac } { собственно начало пакета

0x00, 0x02, 0x44, 0x25, 0x20, 0x24, 0x00, 0x60

src mac }

0x97, 0x6D, 0xF6, 0x54, 0x08, 0x00, 0x45, 0x00

0x00, 0x2A, 0x04, 0xD2, 0x00, 0x00, 0x40, 0x11

{ src IP } {

0x82, 0xF5, 0x0A, 0x64, 0x6F, 0x05, 0x0A, 0x64

dest IP } {src port 10001} {dest port 10001}

0x6F, 0x2F, 0x27, 0x11, 0x27, 0x11, 0x00, 0x16

0x04, 0x44, 0x74, 0x68, 0x69, 0x73, 0x20, 0x69

0x73, 0x20, 0x61, 0x20, 0x74, 0x65, 0x73, 0x74

0x00, 0x00, 0x00, 0x00, 0x28, 0x54, 0xCF, 0x75 последние 4 байта CRC

 

Проверьте если несложно.

 

Наскочил на инфу что все поля в пакете нужно сдвигать младшими байтами вперед (кроме СRC и преамбулы) Правда ли это. До этого я делал все байты у меня выползали со старшего разряда.

 

Помогите кто чем может.

dizel2000@rambler.ru

[Guest]

Почитать до конца RFC, проверить длинну пакета - больше минимальной длинны, воспользоваться сниффером .

 

Расчет контрольной суммы:

В большинстве описаний сетевых протоколов формула расчета контрольной суммы выглядит так (для ICMP):

 

Контрольная сумма - это 16-битное дополнение до единицы суммы дополнений для ICMP сообщения, начиная с поля типа ICMP. При вычислении контрольной суммы это поле должно быть сперва обнулено. Если общая длина сообщения нечетная, то для вычисления контрольной суммы поле данных дополняется еще одним нулевым октетом.

 

 

На самом деле имеется в виду примерно следующее (здесь 14 - смещение от начала пакета *TxP):

 

unsigned long sum,ChkSum;

unsigned char SrcMAC[6],SrcIP[4],i,temp;

unsigned int csum;

...

...

sum=0;

for (i=0;i<10;i++) { sum=sum+((*(TxP+14+(i<<1)))<<8)+*(TxP+14+(i<<1)+1); }

ChkSum=sum&0xFFFF;

ChkSum=ChkSum+(sum>>16);

csum=(int)ChkSum;

csum=~csum;

 

или по другому

 

u_short checksum(u_short * data,u_short length)

{

register long value;

u_short i;

for(i=0;i<(length>>1);i++) value+=data; // add

if((length&1)==1) value+=(data<<8); // compensate of odd amount of datas

value=(value&65535)+(value>>16); // complements one to one

return(~value); // XOR the result

}

-------------------

www.picping.narod.ru

[Guest]

Как воспользоваться снифером если карта при приеме данного пакета прибавляет только счетчик ошибок.? Именно что в описании стандарта опскаются многие (очивидные для них) мелочи типа порядка выдачи бит в полях и т.д. Очень бы помог запоминающий осцилограф для снятия полной осцилограммы пакета с сетевой карты. А на обычном я только просматриваю свой сигнал синхрясь от своих синхроимпульсов. Преобразование NRZ- МАНЧЕСТЕР правильное (смотрю NRZ на внутренней шине ХАБА СОМПЕХ-1008).

Те остается только неправильный образ пакета. Будем копать вроде виден свет в конце.

Тему не закрываю.

[Guest]

Создано снифером

 

 

Ethernet II

Destination MAC: 00:50:FC:90:E2:2D

Source MAC: 00:01:2E:A0:18:5C

Ethertype: 0x0800 (2048) - IP

IP

IP version: 0x04 (4)

Header length: 0x05 (5) - 20 bytes

Type of service: 0x00 (0)

Precedence: 000 - Routine

Delay: 0 - Normal delay

Throughput: 0 - Normal throughput

Reliability: 0 - Normal reliability

Total length: 0x003C (60)

ID: 0xDCD2 (56530)

Flags

Don't fragment bit: 0 - May fragment

More fragments bit: 0 - Last fragment

Fragment offset: 0x0000 (0)

Time to live: 0x80 (128)

Protocol: 0x01 (1) - ICMP

Checksum: 0x6E86 (28294) - correct

Source IP: 192.168.55.11

Destination IP: 192.168.55.12

IP Options: None

ICMP

Type: 0x08 (8) - Echo

Code: 0x00 (0)

Checksum: 0x475C (18268) - correct

Identifier: 0x0200 (512)

Sequence Number: 0x0400 (1024)

 

0x0000 00 50 FC 90 E2 2D 00 01-2E A0 18 5C 08 00 45 00

0x0010 00 3C DC D2 00 00 80 01-6E 86 C0 A8 37 0B C0

0x0020 37 0C 08 00 47 5C 02 00-04 00 61 62 63 64 65 66

0x0030 67 68 69 6A 6B 6C 6D 6E-6F 70 71 72 73 74 75 76

0x0040 77 61 62 63 64 65 66 67-68 69

[Guest]

Держи более удобоваримую версию дампа пакета :)

http://www.auto-podgorodinka.ru/temp/packet.jpg

[Guest]

Дык, от снифера толку мало, ибо он:

а) отбрасывает все пакеты если CRC в конце пакета не совпадает, и нигде эти пакеты не отображает. Только счетчик ошибок увеличивает

б) Показывает принятый пакет если CRC и длина пакета верна, но само поле CRC (кстати, 32 битное) при этом отбрасывается. Соответственно увидеть принятый пакет полностью вместе с CRC не получается. Соответсвенно не понятно, правильные ли мы пакеты выдаем.

В свете выше сказанного возникает два варианта:

а) Каким-нибудь образом просмотреть содержимое пакетов, которые сетевая карта считает ошибочными. Т.е. что бы сетевая карта выдавала дамп отброшенного ошибочного пакета и, желательно, говорила где ошибка :) Благодаря этому можно было бы убедиться, что хоть физический уровень работает верно и мы принимаем то же что и посылаем. Но как это сделать - не ясно. Сниферы показывают только правильные пакеты... Может чего-нить подскажите?

б) Взять "эталлонный" пакет где все поля заведомо верные и выдавать в сеть его. Если будет приниматься нормально, значит с физ. уровнем все ОК, а проблема с нашими пакетами. Вопрос откуда взять этот "эталлонный" пакет. Повтарюсь, сниферы CRC ethernet кадра не показывают :( Свинство, пользуешься каждую секунду, а содержимое пакета незнаешь :) Мож кто-нить видел где-нибудь в инете полный дамп пакета от начала и до самого конца?

[repa]

Похоже без специального измерительного оборудовния не разобраться.

 

Есть вариант другой.

На обычной машине ставим пинговать какой-то не существующий апишник. В результате имеем генератор повторяющихся ARP запросов.

1. С помощью вашего же устройства слушаем и разбираем структуру "правельного пакета".

2. Повторяем его тютельку в тютельку и убеждаемя что пакет принимается обычной сетевой картой.

3. После этого начинаем эксперимент с изменением содержимого пакета и оттачиваем механизм формирования пакета.

 

Вот, вроде, получится специальный измерительный инструмент... :о)

[Guest]

Наше устройство слушать и разбирать не умеет, оно только говорить умеет :)

Пытались сделать похожую фишку на плате W3100, там вроде есть режим приема ошибочных пакетов, но чей-то не пошло :(

Может у кого-нить все-таки есть пример рабочего пакета с CRC

[ssnet]

а нафига тогда сие чудо надо ели оно глухое и тупое ? :))))

[Guest]

Оно не тупое, ОНО ЗАРАБОТАЛОООО.!!!! УРА

ДЕло было как и думали в CRC.

Всем спасибо за помошь.