Предлагаю remote_id считать всегда MAC адресом коммутатора, не надо пихать туда всякую фигню, тем более что по дефолту MAC им и являетсяAvdoshkin писал(а):Проверка работы dhcp!
Как и писал при использовании DES-3526 в режиме dhcp_local_relay к requets unicast опция 82 не добавляется. Если настроить получение IP по имени коммутатора
1) Клиент отправляет descovery(broadcast) опция 82 навешивается
2) Клиент отправляет requets(broadcast) опция 82 навешивается адреса получет
3) Продление адреса requets(RENEWALTIME)(unicast) опция не навешивается, utm5_dhcp смотрим что пакет не правильный и адреса не продляет.
4) Проходит время клиент отправляет(REBINDTIME)(broadcast) опция навешивается и тогда utm5_dhcp продляет адрес.
Я так понимаю что все исправите в update4?
Тестируем 5.3.002
-
Avdoshkin
- Сообщения: 156
- Зарегистрирован: Вт май 10, 2005 19:28
- Откуда: Ачинск
- Контактная информация:
Есть разумное звено в твоих словах!Magnum72 писал(а):Предлагаю remote_id считать всегда MAC адресом коммутатора, не надо пихать туда всякую фигню, тем более что по дефолту MAC им и являетсяAvdoshkin писал(а):Проверка работы dhcp!
Как и писал при использовании DES-3526 в режиме dhcp_local_relay к requets unicast опция 82 не добавляется. Если настроить получение IP по имени коммутатора
1) Клиент отправляет descovery(broadcast) опция 82 навешивается
2) Клиент отправляет requets(broadcast) опция 82 навешивается адреса получет
3) Продление адреса requets(RENEWALTIME)(unicast) опция не навешивается, utm5_dhcp смотрим что пакет не правильный и адреса не продляет.
4) Проходит время клиент отправляет(REBINDTIME)(broadcast) опция навешивается и тогда utm5_dhcp продляет адрес.
Я так понимаю что все исправите в update4?
Да можно, но как то не по стандарту. Здесь все описано в принципе http://www.faqs.org/rfcs/rfc3046.html
А здесь практический пример http://webdev.dlink.ru/technical/faq_hub_switch_72.php
А здесь практический пример http://webdev.dlink.ru/technical/faq_hub_switch_72.php
FreeBSD 10 Может кому пригодится.
UTM5 RFW: Version 5.3-002-update3-bsd10_x64 ругается на
Shared object "libelf.so.0" not found, required by "utm5_rfw"
Лечится установкой libelf-0.8.13_1. Предлагаю разработчикам сделать пакет так, чтобы тянулась нужная зависимость автоматом.
Код: Выделить всё
FreeBSD NAT_2014 10.0-RELEASE-p6 FreeBSD 10.0-RELEASE-p6 #0: Wed Jun 25 19:32:18 MSK 2014 root@NAT_2014:/usr/obj/usr/src/sys/NAT_2014 amd64
Shared object "libelf.so.0" not found, required by "utm5_rfw"
Код: Выделить всё
Кстати управление правами неудачно реализованно,kirush писал(а):
так как постоянно добавляются новые функции то при большом количестве групп сложно контролировать что нужно включить чтобы заработало, при этом вспоминая была ли отключена функция ранее или это новая функция, поэтому предлагаю подумать над следующими доработками:
1) От запретительной политики перейти к разрешительной, т.е. давать доступ ко всем функциям которые явно не запрещены для данной системной группы
2) В свойствах группы добавить список пользователей участников группы, и тут же реализовать возможность добавления и удаления участников.
Не открывает памятку пользователя
Админка пишет "not invoked"
upd: удалил в бд напрямую, помогло.
Код: Выделить всё
Jun 27 12:31:37 ?Debug : 8ad9800 RPCConn[SSL]<amigo_office@192.168.254.132>: URFA ping received, sending reply
Jun 27 12:31:37 ?Debug : 8ad9800 RPCConn[SSL]<amigo_office@192.168.254.132>: Call: 0x7039 (rpcf_generate_doc_for_user_new)
Jun 27 12:31:37 ?Debug : 8ad9800 RPCConn[SSL]<amigo_office@192.168.254.132>: Real Call: 0x7039 (rpcf_generate_doc_for_user_new)
Jun 27 12:31:37 ?Debug : 8ad9800 DBConnectionPool: DBConnectioManager pool [Default]: connection is popped
Jun 27 12:31:37 ?Debug : 8ad9800 DBConnection_mysql: <0x803428b00> SQL SELECT query: SELECT act_id FROM acts_templates WHERE is_old='0' AND def='1' AND doc_type='2'
Jun 27 12:31:37 ?Debug : 8ad9800 DBConnection_mysql: <0x803428b00> SQL SELECT query: 2 rows in 0.000 sec
Jun 27 12:31:37 ?Debug : 8ad9800 DBConnectionPool: DBConnectionManager pool [Default]: connection is pushed back
Jun 27 12:31:37 ?Debug : 8ad9800 RPCConn[SSL]<amigo_office@192.168.254.132>: Call 0x7039 (rpcf_generate_doc_for_user_new) finished in 0.00 sec
Jun 27 12:31:37 ?Debug : 8ad9800 RPCConn[SSL]<amigo_office@192.168.254.132>: Stream cleared
upd: удалил в бд напрямую, помогло.
sejik
В копилку глюков!
1.
Обращаем внимание на expired='1403882421',updated='1403882406'
В качестве клиента выступал маршрутник TP-LINK TL-WR841N с последней FW.
На ISC DHCP маршрутник по opt82 получает все корректно.
Компы получают все вроде корректно и аренда у них истекает через сутки (по дефолту).
Прилагаю скрин где мы вроде получили адрес но нифига не работает)
2.Есть такая особенность или Баг.
Допустим абонент получил на компе ip статичный по opt82 все нормально.
Через 2 минуты ставится маршрутизатор (модель любая) и арендовать тот же самый адрес он не сможет пока не удалишь аренду ранее полученную компом во вкладке - Оборудование - DHCP аренда.
Считаю что по идее если запрос идет снова с того же самого порта надо автоматом билингу грохнуть аренду и выдать снова адрес другому маку (устройству).
Вот что в логах на примере получаем адрес микротиком.
Утм посчитало что адрес как бы заюзан...
После удаления аренды микротик получил адрес и заработал.
Что с этим моментом - дайте рекомендации или это все же баг?
3. Обратите внимание на ???? в id Клиента это когда хосты на RU языке именуются.
4. Имеем ZyXEL NBG334W EE с последней FW. На удивление эти модели utm_dhcp отшибает наглухо уже 3 случай с 1 и тем же симптомом в логах.
Видимо маршрутник отсылает доп параметр который биллинг не знает куда записать в какое поле и отшибает в итоге.
Как результат ip получить нельзя.
Вот еще логи при удалении имени NBG334WEE (пустое поле)
В копилку глюков!
1.
Код: Выделить всё
Jun 27 19:20:06 ?Debug : c9865700 DHCP_Server: request from 172.16.21.115:68:
DHCP packet header
op: 1
htype: 1
hlen: 6
hops: 1
xid: 2a402507
secs: 0
flags: 0
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 172.16.21.115
chaddr: c0:4a:00:5f:7c:6d
sname:
file:
option [dhcp-message-type]: 01
option [dhcp-max-message-size]: 0400
option [dhcp-client-identifier]: 01c04a005f7c6d
option [host-name]: TL-WR841N
option [dhcp-class-identifier]: MSFT 5.0
option [dhcp-parameter-request-list]: 0103060f212b2c2e2f79f9
option [relay-agent-info]: 0106000401a500020208000678542eac1e20
Jun 27 19:20:06 ?Debug : c9865700 DBConnection_mysql: <0x231edd0> SQL SELECT query: SELECT id,ip,expired,client_id,binding_id,flags FROM dhcp_leases WHERE mac='c0:4a:00:5f:7c:6d' ORDER BY id
Jun 27 19:20:06 ?Debug : c9865700 DBConnection_mysql: <0x231edd0> SQL SELECT query: 1 rows in 0.000 sec
Jun 27 19:20:06 ?Debug : c9865700 DHCP_Server: got DHCPDISCOVER packet
Jun 27 19:20:06 ?Debug : c9865700 BindingManager: binding #7906985 OK
Jun 27 19:20:06 ?Debug : c9865700 DBConnection_mysql: <0x231edd0> SQL SELECT query: SELECT mac FROM dhcp_leases WHERE ip='-1407944416' AND (expired>'1403882406' OR flags='1')
Jun 27 19:20:06 ?Debug : c9865700 DBConnection_mysql: <0x231edd0> SQL SELECT query: 0 rows in 0.001 sec
Jun 27 19:20:06 ?Debug : c9865700 LeaseManager: static_offer: IP 172.20.121.32 for MAC c0:4a:00:5f:7c:6d; switch #17; port #2; VLAN #421
Jun 27 19:20:06 ?Debug : c9865700 DBConnection_mysql: <0x231edd0> SQL query: UPDATE dhcp_leases SET ip='-1407944416',client_id='TL-WR841N',binding_id='7906985',expired='1403882421',updated='1403882406',flags='0' WHERE id='128'
Jun 27 19:20:06 ?Debug : c9865700 DBConnection_mysql: <0x231edd0> SQL query takes 0.001 sec
Jun 27 19:20:06 ?Debug : c9865700 DHCP_Server: offered IP 172.20.121.32 from the pool ID 5
Jun 27 19:20:06 ?Debug : c9865700 DHCP_Server: sending OFFER of 172.20.121.32 to c0:4a:00:5f:7c:6d
Jun 27 19:20:06 ?Debug : c9865700 DHCP_Server: sending reply to relay 172.16.21.115:67
DHCP packet header
op: 2
htype: 1
hlen: 6
hops: 0
xid: 2a402507
secs: 0
flags: 0
ciaddr: 0.0.0.0
yiaddr: 172.20.121.32
siaddr: 172.20.121.253
giaddr: 172.16.21.115
chaddr: c0:4a:00:5f:7c:6d
sname:
file:
option [dhcp-message-type]: 02
option [dhcp-server-identifier]: 172.20.121.253
option [dhcp-lease-time]: 86400
option [routers]: 172.20.121.254
option [subnet-mask]: 255.255.255.0
option [domain-name-servers]: 172.28.100.253;172.28.100.254
option [domain-name]: mkc-net.ru
option [relay-agent-info]: 0106000401a500020208000678542eac1e20В качестве клиента выступал маршрутник TP-LINK TL-WR841N с последней FW.
На ISC DHCP маршрутник по opt82 получает все корректно.
Компы получают все вроде корректно и аренда у них истекает через сутки (по дефолту).
Прилагаю скрин где мы вроде получили адрес но нифига не работает)
2.Есть такая особенность или Баг.
Допустим абонент получил на компе ip статичный по opt82 все нормально.
Через 2 минуты ставится маршрутизатор (модель любая) и арендовать тот же самый адрес он не сможет пока не удалишь аренду ранее полученную компом во вкладке - Оборудование - DHCP аренда.
Считаю что по идее если запрос идет снова с того же самого порта надо автоматом билингу грохнуть аренду и выдать снова адрес другому маку (устройству).
Вот что в логах на примере получаем адрес микротиком.
Код: Выделить всё
Jun 06 23:50:11 ?Debug : 7f05c700 DHCP_Server: request from 172.16.20.254:68:
DHCP packet header
op: 1
htype: 1
hlen: 6
hops: 1
xid: 97f50fef
secs: 0
flags: 32768
ciaddr: 0.0.0.0
yiaddr: 0.0.0.0
siaddr: 0.0.0.0
giaddr: 172.16.20.254
chaddr: d4:ca:6d:57:36:6f
sname:
file:
option [dhcp-message-type]: 01
option [dhcp-parameter-request-list]: 01790321062a
option [host-name]: MikroTik
option [dhcp-client-identifier]: 01d4ca6d57366f
option [relay-agent-info]: 0106000401a40010020800061caff76c4e66
Jun 06 23:50:11 ?Debug : 7f05c700 DBConnection_mysql: <0x12f2b30> SQL SELECT query: SELECT id,ip,expired,client_id,binding_id,flags FROM dhcp_leases WHERE mac='d4:ca:6d:57:36:6f' ORDER BY id
Jun 06 23:50:11 ?Debug : 7f05c700 DBConnection_mysql: <0x12f2b30> SQL SELECT query: 0 rows in 0.001 sec
Jun 06 23:50:11 ?Debug : 7f05c700 LeaseManager: no lease for MAC d4:ca:6d:57:36:6f found
Jun 06 23:50:11 ?Debug : 7f05c700 DHCP_Server: got DHCPDISCOVER packet
Jun 06 23:50:11 ?Debug : 7f05c700 BindingManager: binding #7906761 OK
Jun 06 23:50:11 ?Debug : 7f05c700 DBConnection_mysql: <0x12f2b30> SQL SELECT query: SELECT mac FROM dhcp_leases WHERE ip='-1407944688' AND (expired>'1402084211' OR flags='1')
Jun 06 23:50:11 ?Debug : 7f05c700 DBConnection_mysql: <0x12f2b30> SQL SELECT query: 1 rows in 0.000 sec
Jun 06 23:50:11 ?Debug : 7f05c700 LeaseManager: IP 172.20.120.16 is leased by bc:5f:f4:bc:c4:03
Jun 06 23:50:11 ERROR : 7f05c700 LeaseManager: static_offer: IP 172.20.120.16 is already used by another host
Jun 06 23:50:11 ERROR : 7f05c700 DHCP_Server: send_offer: LeaseManagerError: static_offer: IP is already used by another host
После удаления аренды микротик получил адрес и заработал.
Что с этим моментом - дайте рекомендации или это все же баг?
3. Обратите внимание на ???? в id Клиента это когда хосты на RU языке именуются.
4. Имеем ZyXEL NBG334W EE с последней FW. На удивление эти модели utm_dhcp отшибает наглухо уже 3 случай с 1 и тем же симптомом в логах.
Видимо маршрутник отсылает доп параметр который биллинг не знает куда записать в какое поле и отшибает в итоге.
Код: Выделить всё
Jun 24 13:59:36 ?Debug : 2b688700 LeaseManager: static_offer: IP 172.20.119.19 for MAC 40:4a:03:ad:57:75; switch #11; port #19; VLAN #419
Jun 24 13:59:36 ?Debug : 2b688700 DBConnection_mysql: <0x275ae00> SQL query: INSERT INTO dhcp_leases(ip,mac,server_id,client_id,binding_id,expired,updated,flags) VALUES ('-1407944941','40:4a:03:ad:57:75','172.20.119.253','NBG334WEE
Jun 24 13:59:36 ERROR : 2b688700 DBConnection_mysql: <0x275ae00> MySQL query failed:<You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''NBG334WEE' at line 1> Trying to reconnect: 0 Вот еще логи при удалении имени NBG334WEE (пустое поле)
Код: Выделить всё
Jun 24 14:11:03 ?Debug : f991a700 DBConnection_mysql: <0xad7df0> SQL SELECT query: SELECT id,ip,expired,client_id,binding_id,flags FROM dhcp_leases WHERE mac='40:4a:03:ad:57:75' ORDER BY id
Jun 24 14:11:03 ?Debug : f991a700 DBConnection_mysql: <0xad7df0> SQL SELECT query: 0 rows in 0.000 sec
Jun 24 14:11:03 ?Debug : f991a700 LeaseManager: no lease for MAC 40:4a:03:ad:57:75 found
Jun 24 14:11:03 ?Debug : f991a700 DHCP_Server: got DHCPDISCOVER packet
Jun 24 14:11:03 ?Debug : f991a700 BindingManager: binding #7906909 OK
Jun 24 14:11:03 ?Debug : f991a700 DBConnection_mysql: <0xad7df0> SQL SELECT query: SELECT mac FROM dhcp_leases WHERE ip='-1407944941' AND (expired>'1403604663' OR flags='1')
Jun 24 14:11:03 ?Debug : f991a700 DBConnection_mysql: <0xad7df0> SQL SELECT query: 0 rows in 0.000 sec
Jun 24 14:11:03 ?Debug : f991a700 LeaseManager: static_offer: IP 172.20.119.19 for MAC 40:4a:03:ad:57:75; switch #11; port #19; VLAN #419
Jun 24 14:11:03 ?Debug : f991a700 DBConnection_mysql: <0xad7df0> SQL query: INSERT INTO dhcp_leases(ip,mac,server_id,client_id,binding_id,expired,updated,flags) VALUES ('-1407944941','40:4a:03:ad:57:75','172.20.119.253','Zy404A03AD5774
Jun 24 14:11:03 ERROR : f991a700 DBConnection_mysql: <0xad7df0> MySQL query failed:<You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''Zy404A03AD5774' at line 1> Trying to reconnect: 0
Есть баг с откатом платежей:
1) выбираем отчет по платежам за определенный день
2) выбираем сортировку по одному из типов платежей (не важно, главное чтобы их было в день более 1)
3) Откатываем какой нить платеж
Имеем: откат происходит не тому клиенту чей платеж был откачен.
В добавок происходит иногда (зависимость не понял) откат в USD (хотя использую только RUR)
Из за этого бага, потерял вечер
Сейчас всем вернуть у кого не верно списались, и по новой с 01.01.14 искать и вручную все проверять.
1) выбираем отчет по платежам за определенный день
2) выбираем сортировку по одному из типов платежей (не важно, главное чтобы их было в день более 1)
3) Откатываем какой нить платеж
Имеем: откат происходит не тому клиенту чей платеж был откачен.
В добавок происходит иногда (зависимость не понял) откат в USD (хотя использую только RUR)
Из за этого бага, потерял вечер
Сейчас всем вернуть у кого не верно списались, и по новой с 01.01.14 искать и вручную все проверять.
