Всем привет...  

Написано что если в ARP таблице нет нужного MAC адреса, то рассылается широковещательный ARP запрос (Типа ау, у кого IP такой-то скажите свой MAC).
Широковещательный MAC это FF:FF:FF:FF:FF:FF

Вопрос такой- ведь ARP запрос вложен в Ethernet Кадр... А в заголовке Ethernet кадра надо указывать MAC отправителя и MAC получателя... 
Так вот как же быть, ведь MAC адреса получателя то мы как раз и не знаем... Или в заголовке Ethernet кадра тоже указывается MAC FF:FF:FF:FF:FF:FF?

PS Дело в том, что я тут делаю девайс который работает в сети.. И вот разбираюсь почему спустя примерно сутки работы он перестает отвечать на запросы, хотя
как показала отладка - данные он успешно принимает (не висит) и даже что-то отправляет... А отправляет почему-то постоянно ARP ответы (в состоянии когда не отвечает на пинги).
Вот пытаюсь понять откуда берутся эти ответы... Наткнулся на то, что в одном месте девайс отсылает ARP запрос, но судя по всему какой-то битый.. так как там явно все на перекосяк...
Но работать перестает не сразу а очень даже не сразу... 

Вобщем проверил- действительно в ethernet кадре указывается MAC получателя FF:FF:FF:FF:FF:FF


А кто ни будь может посоветовать программу, которая позволяла бы конструировать различные пакеты и отсылать их по сети?

iperf.

и еще вам для понимания

для эмитации нагрузки юзали scapy - создаёт пакеты под любые нужды

Добавлено через 3 минуты и 48 секунд
по поводу арпов тут нужно чётко представлять модель оси:

арп запрос вида "кто есть 1.1.1.1 ?" идёт по L3 по протоколу ARP, дажее он помещается в широковещательный фрейм с адресом назначения FFF...

при отправке широковещательного пакета, пусть будет udp , отправляется на ip 255.255.255.255, затем он инкапсулируется так же в фрейм с адресом назначения FFF...

Ясненько, спасибо.. буду дальше глюки вылавливать в своем девайсе... Иногда швыряется битыми пакетами... Никак не могу выловить причину... TCP/IP стек взял готовый- uIP.. Весь уже его перешерстил... теперь думаю что свой стек написать было бы проще  

Вообще довольно подозрительно выглядит тот факт, что в довольно популярном стеке у меня происходят сбои, о которых никто другой нигде не пишет... 

Может дело и не в нем вовсе, не понимаю.... 

Может во время обработки одного пакета приходит прерывание о получении другого, они как-то накладываются и получается глюк... 

Вот расставил кучу меток по всей программе, смотрю что пришло, что ушло и т.д. Сейчас тестируется... Может чего и выловлю....

Добавлено @ 15:19
UDP, IPv6 у меня не используется... Используется ARP, TCP, ICMP (реализовано в uIP) и сапомисный сервер Telnet. Но сейчас о нем речи не идет. Девайс перестает отвечать на пинги через некоторое время.. От суток до трех это примерно... Пингуется непрерывно. Если в несколько потоков- быстрее сглючивает.... 

Причем когда перестает отвечать- на самом деле не висит... а плюется ARP пакетами... причем валидными, не косячными. Почему он ими плюется не понятно... вроде бы ARP запросов ему никто не шлет... А может и шлет... Но нафига постоянно то их слать? Тем более что верные ответы приходят- 1 раз узнал, в таблицу записал и можно пользоваться некоторое время, до истечения времени жизни ARP записи.

Это сообщение отредактировал(а) rcdimon - 22.11.2010, 15:19

А у таких самопальных устройств часто бывают проблемы.
Стояло такое чудо за dlink-3326, поставили за dlink-3828 и начало оно дохнуть каждые 2-3 недели.
Аналогично подобные девайсы виснут после небольшого широковещательного шторма или большого кол-ва арп запросов...
Замечено на многих интерфейсах управления недорогих железок...

Ну а что делать... надо делать )

Я всё это к тому, что вполне возможно баг есть в этом бесплатном стеке, птосто на него все кладут...

Я за 1 день накатал свой TCP/IP стек... правда TCP он пока не поддерживает ) Ethernet, ARP, IP, ICMP... твое суток пингуется в 10 потоков непрерывно на микроконтроллере ATmega16... ни одного потерянного пакета... В ближайшие дни реализую TCP и выложу куда ни будь на http://sourceforge.net/

Тока интересно.... Кому ни будь тут это интересно? ))) Я впринципе достаточно кроссплатформенно старался реализовывать... всяике там BIG_ENDIAN, LITE_ENDIAN учитывать )