To Sergey Vasiliev
Спасибо Вам за быструю реакцию на вопрос.
Роутером я как раз очень доволен, спасибо D-Link'у за прекраный продукт, как я говорил - без проблем пользуюсь им достаточно давно.
На счёт снифа - я, именно и воспользовался сниффером Wireshark 1.0, простейшим HUB'ом и вторым LAN-интерфейсом в компьютере.
Код который я приводил в первом посте - это текстовый вариант перехваченных Wireshark'ом пакетов на WAN порту с фильтрацией для 'BOOTP client' (68) and 'BOOTP server' (67).
Заголовки столбцов - стандартные - как в Wireshark:
No. Time Source Destination Protocol Info
Если нужны сами *.pcap файлы могу их выслать на e-mail.
Если нужно будет ещё, что-то "закапчерить" (сниф) - с удовольствием это сделаю, Вы только скажите какие именно пакеты будут интересовать.
На счёт таймаута для запросов в bootp.
Вы имеете в виду проанализировать поле "seconds elapsed" (secs) в BOOTP-пакете?
Я просмотрю его дома вечером.
Код:
Посмотрел:
во всех пакетах поле secs == 0;
в запросах DI-524UP поле Hops == 0;
в ответах сервера поле Hops == 1;
RFC-951 BOOTSTRAP PROTOCOL (BOOTP) предполагает, что до сбрасывания "backoff" должно проходить "about 60 seconds"
Цитата:
'secs' is set to the
number of seconds that have elapsed since the client has started
booting. This will let the servers know how long a client has
been trying.
...
7.2. Client Retransmission Strategy
...
As a possible strategy, you might consider backing off
exponentially, similar to the way ethernet backs off on a
collision. So for example if the first packet is at time 0:00,
the second would be at :04, then :08, then :16, then :32, then :64.
...
On each succeeding backoff, the mask is increased in length by one
bit. This doubles the average delay on each backoff.
After the 'average' backoff reaches about 60 seconds, it should be
increased no further, but still randomized.
Я вижу, что каждые 30 секунд (не 60 секунд) происходит backoff и начинается новый цикл с отправки DHCP-Discovery.
Я не говорю, что виноват роутер и я не люблю искать виноватых.
Роутер прекрасно работает в сетях где ответы приходят с задержками до 10 - 12 секунд, чтоб total delay было < 30 сек.
Я мог бы собрать статистику для поля "seconds elapsed" (secs), проанализировать причины сброса через 30 сек.
Важно, найти и устранить проблему - я думаю, что 60 сек до сброса соответствовало бы RFC, роутер получал бы IP в загруженной сети и у меня работал бы iNet и вечером.
Но кто инициирует сбросс через 30 секунд, на основании каких данных и почему не через 60 секунд?
RFC-2131 по DHCP: раздел 3.1.5 говорит о том, что ответственный за это клиент и ответ сервера ему следует ждать до 1 минуты.
Цитата:
... e.g., a client retransmitting as described in section 4.1 might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds,
before restarting the initialization procedure.
RFC-2131 по DHCP: раздел 4.1Цитата:
... DHCP clients are responsible for all message retransmission. ...
... The retransmission delay SHOULD be doubled with subsequent retransmissions up to a maximum of 64 seconds. ...
RFC допускает сети с большими задержками, такими, чтоб суммарное время поцесса было до 60 секунд, но не более 64-х с с учетом того, что нужно елемент случайности +-1 сек для запросов добавлять, чтоб 100 компьютеров при перезагрузке флуд не устраивали.
У меня в сети total delay = 31 сек (а бывает и больше, но до 60 сек)
Цитата:
0 сек - DHCP Discover
2 сек - DHCP Discover
4 сек - DHCP Discover
17 сек - DHCP Offer
17 сек - DHCP Request
19 сек - DHCP Request
21 сек - DHCP Request
31 сек - DHCP ACK
34 сек - DHCP Discover
Как узнать почему роутер на 34-й секунде снова посылает DHCP Discover когда на 31-й пришёл DHCP ACK?
Какую помощь или содействие могу оказать я, чтоб роутер мог распознать ответ DHCP ACK на 58-й секунде?
Всё сделаю, что в моих силах. Помогите пожалуйста.
Спасибо.
Вход
Регистрация
FAQ
Поиск
