[RomanCh]

Уж на что я сам поклонник С, но в данном случае, трудно придумать аргументы однозначно опускающие перл для этой задачи.

Вас ни кто не заставляет это делать. Не нравится - делайте как хотите, хоть ядро ОС на паскале и яве, ничего против не имею. Только пожалуйста не надо в этой теме оффтопа.

 

- менее удобен для меня

- не я его писал - не я получил знания об тонкостях дхцп

Это я к тому, что перл отредактировал и запустил, а си компилять ещё нужно, ну и само собой ручное управление памятью, хоть и не в тягость но время отнимает.

Какие-то странные аргументы.

Без комментариев.

 

Опция 116 - хардкодится :)

И?.. Там в принципе много что хардкодится из того что _пока_ не захардкожено.

 

если клиент промолчал про макс размер то больше 576 слать нельзя, зато можно писать в sname и filename опции, меньше 300 тоже лучше не слать

Да, спасибо, я в курсе - RFC читал. Если бы вы были внимательны, то заметили бы что в списке планируемых доработок значится "Доведение внутренней логики работы сервера до полного соответствия RFC."

 

есть два способа кодирования опций чья длинна больше 255: один с рфк второй от МС

Вы видите проблему в реализации этого на С? Я не вижу.

 

И пока не поздно:

Var = OPT82-PORT        o:82:7:1
Var = OPT82-REMOTE-ID    o:82:12

Никто не гарантировал что субопции в опции 82 будут идти по порядку.

Хотя бы добавьте тип: субопции и чтобы после его применения можно было указывать код субопции, смещение и длину.

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

2. Ни кто не гарантировал, да. Но каждый провайдер знает что за оборудование у него работает и знает как правильно разобрать эту опцию. Не вижу проблемы. Будет проблема - будет решение.

 

PS: при работе на клиентах ХР в в логах нет сообщений о таймауте симафора?

Мною не отмечено. И вообще пока что жалоб не поступало.

 

 

Ivan_83, я что-то не пойму, вы какую цель сейчас себе ставите? Пытаетесь доказать что продукт сырой и недоработанный местами? Спасибо, мне кажется это никому не нужно. Хотя бы потому что об этом было честное предупреждение в самом первом посте этого топика и на сайте.

То что я выбрал не верный язык разработки? Это мне кажется вообще глупо.

То что сервер не умеет высчитывать объём сферического коня в вакууме? Ну так вроде бы ни кто этого и не просит потому что никому не нужно. Если будет кому-то нужно - можно будет сделать. Не вижу проблемы и повода для споров и упрёков.

 

Прекращайте пожалуйста бессмысленные посты, предлагаю посвятить это время доработке _вашего_ кода, если уж так хочется показать пример "как нужно делать". Либо доработкам моего кода, если действительно хочется помочь проекту.

[Ivan_83]

я что-то не пойму, вы какую цель сейчас себе ставите?

Сказывается нехватка невербалики при переписке. :(

Я описал проблемы и трудности с которыми сам столкнулся, а также предложил добавить разборку субопций, и варианты для организации кеша.

[RomanCh]

Обновление: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.4.tar.bz2

 

1. Исправлены мелкие баги: 1) кэш пытался пытался зачиститься чаще в число раз равное числу потоков-обработчиков запросов. Не влияло на работу в целом и явно не являлось причиной падений; 2) была бага в отладочном выводе при обновлении DHCP запросов сложенных в очередь и ещё не обработанных потоками отправляющими запросы в БД (беззнаковое показывалось как знаковое с минусом).
2. Исправлена логика зачистки кэша от устаревших значений. Вероятно причина падений крылась в этом. Если это так - теперь падать не должен (ну или должен реже если есть ошибки в другом месте :) ).
3. Таймаут перед запуском следующего DHCP потока (если прослушиваемых интерфейсов больше одного) сокращён до 200 мс. Проблему с падением в FreeBSD при запуске на нескольких интерфейсах это вроде бы решает так же хорошо как и таймаут в 1с, но меньше тормозит запуск сервера.
4. Удалил проверку на несовпадение MAC адреса источника и MAC адреса клиента указанного в DHCP заголовке.

Изменено 11 марта, 2011 пользователем RomanCh

[[-Alt-]]

Так отвечает этот сервер:

2011-03-12 02:21:34.265925 00:1b:21:86:d5:12 > 00:11:95:ff:b0:3a, ethertype IPv4 (0x0800), length 358: (tos 0x10, ttl 64, id 59721, offset 0, flags [none], proto UDP (17), length 344)

10.254.0.2.67 > 10.254.0.13.67: [no cksum] BOOTP/DHCP, Reply, length 316, xid 0xa8ea6704, Flags [none] (0x0000)

Your-IP 46.44.19.70

Server-IP 10.254.0.2

Gateway-IP 10.254.0.13

Client-Ethernet-Address 00:00:1c:d5:67:04 [|bootp]

Так отвечает isc

02:27:46.117610 00:1b:21:86:a5:66 > 00:11:95:ff:b0:3a, ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 49064, offset 0, flags [none], proto UDP (17), length 330)

10.254.0.1.67 > 10.254.0.13.67: BOOTP/DHCP, Reply, length 302, hops 1, xid 0x24b46704, Flags [none] (0x0000)

Your-IP 46.44.19.70

Gateway-IP 10.254.0.13

Client-Ethernet-Address 00:00:1c:d5:67:04 [|bootp]

 

Похоже что Server-IP сноит крышу шлюзикам dlink, и они упорно продолжают перезапрашивать адрес, игнорируя ответ.

[RomanCh]

[-Alt-], не не, так не пойдёт. Надо полный лог DHCP транзакции.

tcpdump -i ... -nvvves0 port 67

Что бы обязательно был полный запрос и полный ответ. Ну и для сравнения ответ ISC DHCP что бы было понятно в чём разница. Сейчас мы видим обрезки по которым ничего сказать нельзя. Поле Server-IP не должно ничего портить т.к. существующая версия патча для dhcrelay работающая через RADIUS тоже его проставляет, и она гарантированно работала со всякими мелкими железками.

 

Вот что про это поле в RFC написано:

DHCP определяет поле 'siaddr' как адрес сервера для использования во время следующего шага процесса начальной загрузки клиента. DHCP-сервер может прислать свой собственный адрес в поле 'siaddr', если сервер готов обеспечить последующую загрузку (например, доставку образа операционной системы). DHCP-сервер всегда присылает свой адрес в опции 'server identifier'.

Нет ничего проще чем удалить дефолтное заполнение этого поля. Но думаю делу это не поможет.

[NiTr0]

Какие-то странные аргументы.

Без комментариев.

Агрументы для прототипа/модели (который может множество раз правиться) - вполне себе не странные. А как будет адекватно отлаженный код (пускай и на 1-2 порядка медленнее чем сишный) - на си при необходимости его переписать труда не составит. Ведь собссно написание кода составляет 10-15% всего времени разработки.

Думаю, вы же не будете спорить, что отладка скрипта все же несколько приятнее, чем отладка сишной программы?

[[-Alt-]]

10.254.0.13.68 > 10.254.0.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:00:1c:d5:67:04, length 548, hops 1, xid 0x8f2a6704, Flags [none] (0x0000)

Gateway-IP 10.254.0.13

Client-Ethernet-Address 00:00:1c:d5:67:04

Vendor-rfc1048 Extensions

Magic Cookie 0x63825363

DHCP-Message Option 53, length 1: Discover

Client-ID Option 61, length 7: ether 00:00:1c:d5:67:04

Hostname Option 12, length 7: "DIR-100"

Parameter-Request Option 55, length 4:

Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name

Agent-Information Option 82, length 18:

Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^R

Remote-ID SubOption 2, length 8: ^@^F^@^QM-^UM-^?M-0:

END Option 255, length 0

PAD Option 0, length 0, occurs 260

15:23:29.451310 00:1b:21:86:d5:12 > 00:11:95:ff:b0:3a, ethertype IPv4 (0x0800), length 358: (tos 0x10, ttl 64, id 51418, offset 0, flags [none], proto UDP (17), length 344)

10.254.0.2.67 > 10.254.0.13.67: [no cksum] BOOTP/DHCP, Reply, length 316, xid 0x8f2a6704, Flags [none] (0x0000)

Your-IP 46.44.19.70

Server-IP 10.254.0.2

Gateway-IP 10.254.0.13

Client-Ethernet-Address 00:00:1c:d5:67:04

Vendor-rfc1048 Extensions

Magic Cookie 0x63825363

Subnet-Mask Option 1, length 4: 255.255.248.0

Default-Gateway Option 3, length 4: 46.44.16.1

Domain-Name-Server Option 6, length 12: 192.168.10.1,192.168.10.2,62.140.229.3

Lease-Time Option 51, length 4: 14400

NTP Option 42, length 8: 192.168.10.1,192.168.10.2

RN Option 58, length 4: 7200

RB Option 59, length 4: 13800

TFTP Option 66, length 10: "10.254.0.1"

Server-ID Option 54, length 4: 10.254.0.2

DHCP-Message Option 53, length 1: Offer

END Option 255, length 0

15:23:29.456967 00:11:95:ff:b0:3a > 00:00:1c:d5:67:04, ethertype IPv4 (0x0800), length 358: (tos 0xfc, ttl 64, id 17576, offset 0, flags [none], proto UDP (17), length 344)

10.254.0.13.67 > 46.44.19.70.68: [udp sum ok] BOOTP/DHCP, Reply, length 316, hops 1, xid 0x8f2a6704, Flags [none] (0x0000)

Your-IP 46.44.19.70

Server-IP 10.254.0.2

Gateway-IP 10.254.0.13

Client-Ethernet-Address 00:00:1c:d5:67:04

Vendor-rfc1048 Extensions

Magic Cookie 0x63825363

Subnet-Mask Option 1, length 4: 255.255.248.0

Default-Gateway Option 3, length 4: 46.44.16.1

Domain-Name-Server Option 6, length 12: 192.168.10.1,192.168.10.2,62.140.229.3

Lease-Time Option 51, length 4: 14400

NTP Option 42, length 8: 192.168.10.1,192.168.10.2

RN Option 58, length 4: 7200

RB Option 59, length 4: 13800

TFTP Option 66, length 10: "10.254.0.1"

Server-ID Option 54, length 4: 10.254.0.2

DHCP-Message Option 53, length 1: Offer

END Option 255, length 0

 

 

И так по кругу discover -> offer

 

Теперь смотрим isc:

 

15:08:32.047962 00:11:95:ff:b0:3a > 00:1b:21:86:a5:66, ethertype IPv4 (0x0800), length 590: (tos 0xfc, ttl 64, id 17000, offset 0, flags [none], proto UDP (17), length 576)

10.254.0.13.68 > 10.254.0.1.67: [udp sum ok] BOOTP/DHCP, Request from 00:00:1c:d5:67:04, length 548, hops 1, xid 0xafba6704, Flags [none] (0x0000)

Gateway-IP 10.254.0.13

Client-Ethernet-Address 00:00:1c:d5:67:04

Vendor-rfc1048 Extensions

Magic Cookie 0x63825363

DHCP-Message Option 53, length 1: Discover

Client-ID Option 61, length 7: ether 00:00:1c:d5:67:04

Hostname Option 12, length 7: "DIR-100"

Parameter-Request Option 55, length 4:

Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name

Agent-Information Option 82, length 18:

Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^R

Remote-ID SubOption 2, length 8: ^@^F^@^QM-^UM-^?M-0:

END Option 255, length 0

PAD Option 0, length 0, occurs 260

15:08:32.052975 00:1b:21:86:a5:66 > 00:11:95:ff:b0:3a, ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 58684, offset 0, flags [none], proto UDP (17), length 330)

10.254.0.1.67 > 10.254.0.13.67: [udp sum ok] BOOTP/DHCP, Reply, length 302, hops 1, xid 0xafba6704, Flags [none] (0x0000)

Your-IP 46.44.19.70

Gateway-IP 10.254.0.13

Client-Ethernet-Address 00:00:1c:d5:67:04

Vendor-rfc1048 Extensions

Magic Cookie 0x63825363

DHCP-Message Option 53, length 1: Offer

Server-ID Option 54, length 4: 10.254.0.1

Lease-Time Option 51, length 4: 3600

Subnet-Mask Option 1, length 4: 255.255.248.0

Default-Gateway Option 3, length 4: 46.44.16.1

Domain-Name-Server Option 6, length 12: 192.168.10.1,192.168.10.2,62.140.229.3

Agent-Information Option 82, length 18:

Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^R

Remote-ID SubOption 2, length 8: ^@^F^@^QM-^UM-^?M-0:

END Option 255, length 0

15:08:32.065436 00:11:95:ff:b0:3a > 00:1b:21:86:a5:66, ethertype IPv4 (0x0800), length 590: (tos 0xfc, ttl 64, id 17004, offset 0, flags [none], proto UDP (17), length 576)

10.254.0.13.68 > 10.254.0.1.67: [udp sum ok] BOOTP/DHCP, Request from 00:00:1c:d5:67:04, length 548, hops 1, xid 0xafba6704, Flags [none] (0x0000)

Gateway-IP 10.254.0.13

Client-Ethernet-Address 00:00:1c:d5:67:04

Vendor-rfc1048 Extensions

Magic Cookie 0x63825363

DHCP-Message Option 53, length 1: Request

Requested-IP Option 50, length 4: 46.44.19.70

Server-ID Option 54, length 4: 10.254.0.1

Client-ID Option 61, length 7: ether 00:00:1c:d5:67:04

Hostname Option 12, length 7: "DIR-100"

Parameter-Request Option 55, length 4:

Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name

Agent-Information Option 82, length 18:

Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^R

Remote-ID SubOption 2, length 8: ^@^F^@^QM-^UM-^?M-0:

END Option 255, length 0

PAD Option 0, length 0, occurs 248

15:08:32.069954 00:1b:21:86:a5:66 > 00:11:95:ff:b0:3a, ethertype IPv4 (0x0800), length 344: (tos 0x0, ttl 64, id 58687, offset 0, flags [none], proto UDP (17), length 330)

10.254.0.1.67 > 10.254.0.13.67: [udp sum ok] BOOTP/DHCP, Reply, length 302, hops 1, xid 0xafba6704, Flags [none] (0x0000)

Your-IP 46.44.19.70

Gateway-IP 10.254.0.13

Client-Ethernet-Address 00:00:1c:d5:67:04

Vendor-rfc1048 Extensions

Magic Cookie 0x63825363

DHCP-Message Option 53, length 1: ACK

Server-ID Option 54, length 4: 10.254.0.1

Lease-Time Option 51, length 4: 3600

Subnet-Mask Option 1, length 4: 255.255.248.0

Default-Gateway Option 3, length 4: 46.44.16.1

Domain-Name-Server Option 6, length 12: 192.168.10.1,192.168.10.2,62.140.229.3

Agent-Information Option 82, length 18:

Circuit-ID SubOption 1, length 6: ^@^D^@^J^@^R

Remote-ID SubOption 2, length 8: ^@^F^@^QM-^UM-^?M-0:

END Option 255, length 0

 

Теперь мне тоже не понятно что конкретно влияет...

[max1976]

Теперь мне тоже не понятно что конкретно влияет...

Наверное релей неправильно реагирует на отсутствие option 82 в offer от сервера, поэтому пакет не долетает до dir 100.

[s.lobanov]

Теперь мне тоже не понятно что конкретно влияет...

Наверное релей неправильно реагирует на отсутствие option 82 в offer от сервера, поэтому пакет не долетает до dir 100.

Особенно если релеить циской. Решается так с помощью добавления команды "ip dhcp relay information check-reply none" на интерфейс. В этом случае, циска не особо проверяет что там вернул сервер, а просто возвращает ответ получателю.

[max1976]

Особенно если релеить циской. Решается так с помощью добавления команды "ip dhcp relay information check-reply none" на интерфейс. В этом случае, циска не особо проверяет что там вернул сервер, а просто возвращает ответ получателю.

Сервер должен возвращать option82, если эта опция была в запросе. Здесь же в запросе опция есть, а в ответе нет. Поэтому и не работает через relay.

[RomanCh]

[-Alt-], что-то какой-то странный первый дамп (да, кстати - было бы хорошо использовать тег [ code ] для дампов).

Мы видим там DHCPDISCOVER (кстати строчка с Ethernet адресами видимо съелась при копировании) в котором всё нормально, и видим почему-то два DHCPOFFER: один - то что было непосредственно послано сервером, а второй - тот что через relay пошёл клиенту. В случае с ISC DHCP такого нет. Как это так получилось, они фактически в одном ethernet сегменте?

 

А так - у меня есть два предположения которые нужно проверить:

1. Если клиент и сервер действительно в одном сегменте и клиент может увидеть первый пакет - он может "расстроиться" видя что там не рассчитана udp checksum. Потому возможно игнорирует второй.
2. Есть ещё более серьёзное подозрение что всё дело вовсе не в п.1 а в том что ISC DHCP _всегда_ в опциях на первое место ставит опцию "тип сообщения" (DHCPOFFER/DHCPAK), а мой сервер добавляет опции в том порядке в котором они получены из БД. Более серьёзное подозрение потому что в написанном мною патче к dhcrelay который работал с RADIUS изначально "бронируется" место для опции типа ответа в поле опций в самом начале, припоминаю что как раз ради таких ущербных клиентов это и сделано.

Итого:

1. Добавлю расчёт udp checksum - в общем-то в исходниках всегда значилось в TODO, вот и пришло время для DO :)

2. Сделаю что бы тип ответа всегда был на первом месте опций.

 

С большой вероятностью после этого всё заведётся.

 

max1976, s.lobanov нет, крайне маловероятно что дело в этом.

max1976 дайте пожалуйста пруфлинк на надёжный источник где написано что сервер обязательно должен это делать. Я не спорю что такого не может быть. Просто хочется ознакомиться с первоисточником.

 

А вообще - на 3526м dlink'е всё работает. И потом - почему работают другие клиенты, но не работает ущербный DIR? Уж точно думаю дело не в отсутствии 82й опции в ответе.

 

 

Агрументы для прототипа/модели (который может множество раз правиться) - вполне себе не странные. А как будет адекватно отлаженный код (пускай и на 1-2 порядка медленнее чем сишный) - на си при необходимости его переписать труда не составит.

Вы пробовали перлокод объёмом более 100 строчек полностью переписать на Си с сохранением стабильности и функционала, быстро получилось? Риторический вопрос. Напомню что огромное множество сложно воспроизводимых и потому сложно поправимых ошибок в программах на С/С++ возникает обычно из-за проблем при работе с указателями и памятью. Которой напрочь нету в интерпретируемых языках и потому ваш "прототип" будет не более чем отдалённой концептуальной моделью. А уж про различие в базовых возможностях языка я вообще молчу.

Ведь собссно написание кода составляет 10-15% всего времени разработки.

Эх, все бы так писали :) К слову - работаю не в самой захудалой компании рунета. И у нас есть несколько отделов программистов (я кстати не программист). Ни в одном отделе не пользуются подобной моделью разработки, хотя логика реализуемых демонов там не слабее чем в DHCP сервере. И вообще ни разу не видел что бы кто-то так делал что-либо серьёзное или даже рекомендовал делать. Мне кажется ваши утверждения порождены недостаточным опытом.

Думаю, вы же не будете спорить, что отладка скрипта все же несколько приятнее, чем отладка сишной программы?

Спорить не буду потому что это заведомо бессмысленное утверждение. Потому что:

1. Изначально с ним не согласен. Если вы считаете иначе - вы просто не достаточно хорошо умеете писать на С и использовать средства разработки.

2. Как бы удобно не было вам отлаживать перлокод - переписав всё это на Си вам придётся отлаживать сишную программу. Любите делать всю работу дважды?

 

И дабы вы не думали что я пишу на С потому что не знаю Perl - скажу что последний год писал на Perl'е много больше чем на С, и решал далеко не самые тривиальные задачи. Только вот - для каждой задачи хорош свой инструмент.

 

Потому попрошу ещё и вас отдельно - не надо захламлять топик бессмысленными постами холиварного содержания. Есть желание узнать что на чём писать лучше? Добро пожаловать на форум программистов. Можете в "курилках" обсуждать эти вопросы сколько угодно. Не захламляйте пожалуйста строго тематический топик посвящённый строго одной задаче.

[[-Alt-]]

Это просто 2 разных сервера, вот и дамп отличается, на один похоже прилетают пакеты ему не предназначенные(но проблема явно не в этом я и на другом сервере пробовал, все аналогично), клиенты находятся в другом влане, и они никогда напрямую не видят ответ от сервера(если только сами юникачтом не прислали запрос), все идёт через релей.

 

[-Alt-], что-то какой-то странный первый дамп (да, кстати - было бы хорошо использовать тег [ code ] для дампов).

Мы видим там DHCPDISCOVER (кстати строчка с Ethernet адресами видимо съелась при копировании) в котором всё нормально, и видим почему-то два DHCPOFFER: один - то что было непосредственно послано сервером, а второй - тот что через relay пошёл клиенту. В случае с ISC DHCP такого нет. Как это так получилось, они фактически в одном ethernet сегменте?

 

А так - у меня есть два предположения которые нужно проверить:

 

1. Если клиент и сервер действительно в одном сегменте и клиент может увидеть первый пакет - он может "расстроиться" видя что там не рассчитана udp checksum. Потому возможно игнорирует второй.

2. Есть ещё более серьёзное подозрение что всё дело вовсе не в п.1 а в том что ISC DHCP _всегда_ в опциях на первое место ставит опцию "тип сообщения" (DHCPOFFER/DHCPAK), а мой сервер добавляет опции в том порядке в котором они получены из БД. Более серьёзное подозрение потому что в написанном мною патче к dhcrelay который работал с RADIUS изначально "бронируется" место для опции типа ответа в поле опций в самом начале, припоминаю что как раз ради таких ущербных клиентов это и сделано.

[vitalyb]

дайте пожалуйста пруфлинк на надёжный источник где написано что сервер обязательно должен это делать. Я не спорю что такого не может быть. Просто хочется ознакомиться с первоисточником.

http://www.faqs.org/rfcs/rfc3046.html раздел 2.2

 

кроме этого, option82 должна передаваться последней в списке опций - некоторое оборудование желает ее видеть именно последней.

 

опцию надо возвращать - по ее содержимому релей/снупинг определяет куда именно надо передавать ответ (какой порт коммутатора, какой модем в DOCSIS и т.д.).

 

[[-Alt-]]

Кстати я похоже понял откуда взялся пакет, так как отсутствует option 82(или релей не понимает что ему ответили), пакет идет сперва на релей, а потом релей на свитче отправляет пакет не в порт, а на ip клиента, а так-как dhсp сервер является шлюзом по умолчанию во влане где работает релей, то пакет от релея к клиенту мы видим tcpdump.

[RomanCh]

http://www.faqs.org/rfcs/rfc3046.html раздел 2.2

кроме этого, option82 должна передаваться последней в списке опций - некоторое оборудование желает ее видеть именно последней.

Спасибо, вижу:

DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies. Servers SHOULD copy the Relay Agent Information option as the last DHCP option in the response. Servers SHALL NOT place the echoed Relay Agent Information option in the overloaded sname or file fields. If a server is unable to copy a full Relay Agent Information field into a response, it SHALL send the response without the Relay Information Field, and SHOULD increment an error counter for the situation.

Дофичим. Но вышеописанная проблема навряд связана с этим.

[Ivan_83]

' timestamp='1299949513' post='596506']

Кстати я похоже понял откуда взялся пакет, так как отсутствует option 82(или релей не понимает что ему ответили), пакет идет сперва на релей, а потом релей на свитче отправляет пакет не в порт, а на ip клиента, а так-как dhсp сервер является шлюзом по умолчанию во влане где работает релей, то пакет от релея к клиенту мы видим tcpdump.

В доке к dhcpcd клиенту написано что обычно клиенты шлют 2 дисковер запроса подряд, потому некоторые дхцп сервера тупо не отвечают на первый и ждут второго. В клиенте для этого опция предусмотрена.

Ещё релей агент не перехватывает пакеты, те броадкастный дискавер/регвест/информ расходится по всем портам (которые в влане, если настроено), а копия пакета с опцией улетает уже куда нужно.

 

 

Возможно имеет смысл в сервере предусмотреть опцию при которой он использует обыкновенный юдп сокет для приёма и отправки, чтобы не обязательно было BPF или аналогичное в ядро вкомпиливать, тем более, что для работы только с релей агентами этого вполне хватает, тк нет необходимости слать на 0.0.0.0 и нужный мак.

 

Для расчёта контрольной суммы UDP можно дёрнуть код отсюда: http://www.netlab.linkpc.net/download/software...rol-1.05.tar.gz

[RomanCh]

Возможно имеет смысл в сервере предусмотреть опцию при которой он использует обыкновенный юдп сокет для приёма и отправки, чтобы не обязательно было BPF или аналогичное в ядро вкомпиливать

Не вижу смысла делать два разных интерфейса для реализации одного и того же в одной и той же программе.

Хотя бы потому что сетевая часть работает на libpcap, который априори платформонезависим (ну, почти :) ) и я пока что не встречал системы (конечно если специально не извратиться над ней) в которой он не будет работать. Ведь тогда не будет работать и tcpdump, и nmap и много чего ещё без чего нормальный провайдинг лично мне не представляется возможным.

[Voronok]

6 часов, полет нормальный

[RomanCh]

6 часов, полет нормальный

Засеки пожалуйста потребление памяти сервером. Какое сейчас и какое через несколько часов (если не упадёт).

[Voronok]

Ок. Имеется ввиду это?

Mem: 97M Active, 366M Inact, 144M Wired, 160K Cache, 112M Buf, 1391M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
29221 dhcpd       7 -58    0  9868K  4540K bpf    1   0:14  0.00% db2dhcp

Или это?

USER    PID %CPU %MEM   VSZ   RSS  TT  STAT STARTED      TIME COMMAND
dhcpd 29221  0.0  0.2  9868  4528  ??  S     8:14PM   0:14.13 /usr/sbin/db2dhcp -c /usr/local/etc/db2dhcp.cong em1

Сейчас посмотрел лог есть ошибки:

2011-03-13 02:32:32 [29221:1211109888] Ignore this message.
2011-03-13 02:32:32 [29221:1211111168] WARN: Found old request for 00:26:2D:AE:74:1B on 172.16.0.151 in DHCP queue. Updating old request.
2011-03-13 02:32:50 [29221:1211111168] Got DHCPINFORM (8) message from client 00:1A:80:B7:25:2F on em1/172.16.0.151
2011-03-13 02:32:50 [29221:1211111168] Got DHCPINFORM (8) message from client 00:1A:80:B7:25:2F on em1/172.16.0.151
2011-03-13 02:32:50 [29221:1211110656] ERROR: Can't delete node from cache: 00:24:1D:82:0F:65/172.16.12.175
2011-03-13 02:32:50 [29221:1211111168] WARN: Found old request for 00:1A:80:B7:25:2F on 172.16.0.151 in DHCP queue. Updating old request.
2011-03-13 02:32:50 [29221:1211110656] ERROR: Can't delete node from cache: 00:24:54:E6:75:56/172.16.23.142
2011-03-13 02:32:50 [29221:1211110656] ERROR: Can't delete node from cache: 1C:6F:65:86:0C:BA/172.16.24.198
2011-03-13 02:32:50 [29221:1211110656] ERROR: Can't delete node from cache: 6C:F0:49:0B:43:8D/172.16.6.170
2011-03-13 02:32:50 [29221:1211110656] Ignore this message.
2011-03-13 02:32:53 [29221:1211111168] Got DHCPINFORM (8) message from client 00:1A:80:B7:25:2F on em1/172.16.0.151
2011-03-13 02:32:53 [29221:1211111168] Got DHCPINFORM (8) message from client 00:1A:80:B7:25:2F on em1/172.16.0.151
2011-03-13 02:32:53 [29221:1211110144] Ignore this message.
2011-03-13 02:32:53 [29221:1211111168] WARN: Found old request for 00:1A:80:B7:25:2F on 172.16.0.151 in DHCP queue. Updating old request.
2011-03-13 02:34:01 [29221:1211111168] Got DHCPINFORM (8) message from client 00:19:D1:8F:D7:52 on em1/172.16.0.151
2011-03-13 02:34:01 [29221:1211111168] Got DHCPINFORM (8) message from client 00:19:D1:8F:D7:52 on em1/172.16.0.151
2011-03-13 02:34:01 [29221:1211111168] WARN: Found old request for 00:19:D1:8F:D7:52 on 172.16.0.151 in DHCP queue. Updating old request.
2011-03-13 02:34:01 [29221:1211110400] ERROR: Can't delete node from cache: 00:24:1D:82:0F:65/172.16.12.175
2011-03-13 02:34:01 [29221:1211110400] ERROR: Can't delete node from cache: 00:24:54:E6:75:56/172.16.23.142
2011-03-13 02:34:01 [29221:1211110400] ERROR: Can't delete node from cache: 1C:6F:65:86:0C:BA/172.16.24.198
2011-03-13 02:34:01 [29221:1211110400] ERROR: Can't delete node from cache: 6C:F0:49:0B:43:8D/172.16.6.170
2011-03-13 02:34:01 [29221:1211110400] Ignore this message.

Изменено 13 марта, 2011 пользователем Voronok

[RomanCh]

USER    PID %CPU %MEM   VSZ   RSS  TT  STAT STARTED      TIME COMMAND
dhcpd 29221  0.0  0.2  9868  4528  ??  S     8:14PM   0:14.13 /usr/sbin/db2dhcp -c /usr/local/etc/db2dhcp.cong em1

Вот это.

2011-03-13 02:32:32 [29221:1211111168] WARN: Found old request for 00:26:2D:AE:74:1B on 172.16.0.151 in DHCP queue. Updating old request.

Это не страшно, но мелкая бага :) По идее раз мы игнорим DHCPINFORM то и вносить в очередь мы ничего не должны. Не очень понятно почему так происходит. Буду смотреть.

 

2011-03-13 02:32:50 [29221:1211110656] ERROR: Can't delete node from cache: 00:24:1D:82:0F:65/172.16.12.175
2011-03-13 02:32:50 [29221:1211110656] ERROR: Can't delete node from cache: 00:24:54:E6:75:56/172.16.23.142
2011-03-13 02:32:50 [29221:1211110656] ERROR: Can't delete node from cache: 1C:6F:65:86:0C:BA/172.16.24.198
2011-03-13 02:32:50 [29221:1211110656] ERROR: Can't delete node from cache: 6C:F0:49:0B:43:8D/172.16.6.170

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

 

[Voronok]

Перезапустил. Пока без ошибок. Буду наблюдать.

USER    PID %CPU %MEM   VSZ   RSS  TT  STAT STARTED      TIME COMMAND
root  30617  0.0  0.1  8588  2200  ??  S     3:29AM   0:00.01 /usr/sbin/db2dhcp -dc /usr/local/etc/db2dhcp.cong em1

Изменено 13 марта, 2011 пользователем Voronok

[RomanCh]

Следующая версия: http://netpatch.ru/projects/db2dhcp/db2dhcp-0.1.a.5.tar.bz2

 

Изменения:

1. Сделан расчёт контрольной суммы UDP.
2. Опция DHCP message type теперь всегда идёт первой в списке опций.
3. Опция 82 возвращается сервером в ответах.
4. Удалено автоматическое заполнение поля 'Server IP' в заголовке DHCP пакета. Если необходимо - можно выдать эту информацию из БД.

[Voronok]

Упал через 6 часов с лишкой после перезапуска. Версия 0.1.а.4

2011-03-13 09:41:16 [30617:1211111168] DEBUG: Got ARP as-it from 172.16.0.151/00:15:17:2C:0F:C8. Check offers queue.
2011-03-13 09:41:27 [30617:1211111168] Got DHCPINFORM (8) message from client 00:1A:80:B7:25:2F on em1/172.16.0.151
2011-03-13 09:41:27 [30617:1211111168] DEBUG: Adding DHCP message to empty queue 'DHCP requests'
2011-03-13 09:41:27 [30617:1211111168] DEBUG: Queue (DHCP requests) length now is: 1, new requests: 1
2011-03-13 09:41:27 [30617:1211111168] Got DHCPINFORM (8) message from client 00:1A:80:B7:25:2F on em1/172.16.0.151
2011-03-13 09:41:27 [30617:1211110144] DEBUG: Trying to get DHCP request from queue 'DHCP requests'.
2011-03-13 09:41:27 [30617:1211111168] DEBUG: Updating node with xid 788221755 to xid 788221755
2011-03-13 09:41:27 [30617:1211110144] Ignore this message.
2011-03-13 09:41:27 [30617:1211111168] WARN: Found old request for 00:1A:80:B7:25:2F on 172.16.0.151 in DHCP queue. Updating old request.
2011-03-13 09:41:27 [30617:1211110144] DEBUG: DHCP request removed from queue 'DHCP requests'. Queue len now is: 0, new requests: 0
2011-03-13 09:41:27 [30617:1211111168] DEBUG: Got ARP as-it from 172.16.0.151/00:15:17:2C:0F:C8. Check offers queue.
2011-03-13 09:41:29 [30617:1211111168] DEBUG: Got ARP as-it from 172.16.0.151/00:15:17:2C:0F:C8. Check offers queue.
2011-03-13 09:41:30 [30617:1211111168] Got DHCPINFORM (8) message from client 00:1A:80:B7:25:2F on em1/172.16.0.151
2011-03-13 09:41:30 [30617:1211111168] DEBUG: Adding DHCP message to empty queue 'DHCP requests'
2011-03-13 09:41:30 [30617:1211111168] DEBUG: Queue (DHCP requests) length now is: 1, new requests: 1
2011-03-13 09:41:30 [30617:1211110656] DEBUG: Trying to get DHCP request from queue 'DHCP requests'.
2011-03-13 09:41:30 [30617:1211111168] Got DHCPINFORM (8) message from client 00:1A:80:B7:25:2F on em1/172.16.0.151
2011-03-13 09:41:30 [30617:1211110656] DEBUG: Flushing cache: last flush ts - 1299998406, flush period - 60, now is 1299998490.
2011-03-13 09:41:30 [30617:1211111168] DEBUG: Updating node with xid 788221755 to xid 788221755
2011-03-13 09:41:30 [30617:1211110656] DEBUG: Adding DHCP cache node 00:01:29:A6:3F:7A/172.16.11.13 to deleting queue - TTL exceeded.
2011-03-13 09:41:30 [30617:1211111168] WARN: Found old request for 00:1A:80:B7:25:2F on 172.16.0.151 in DHCP queue. Updating old request.
2011-03-13 09:41:30 [30617:1211110656] DEBUG: Adding DHCP cache node E0:CB:4E:D9:8C:7B/172.16.0.91 to deleting queue - TTL exceeded.
2011-03-13 09:41:30 [30617:1211110656] DEBUG: Adding DHCP cache node 00:1F:C6:A7:9F:07/172.16.24.41 to deleting queue - TTL exceeded.

Изменено 13 марта, 2011 пользователем Voronok

[Voronok]

Изменения:

1. Удалено автоматическое заполнение поля 'Server IP' в заголовке DHCP пакета. Если необходимо - можно выдать эту информацию из БД.

Это опция №54?