LINUX.ORG.RU
решено ФорумAdmin

Ip зарезервирован по мак-адресу, но при загрузки под другой системой карта получает другой ip по dhcp

 ,


0

1

Есть ноутбук lenovo e540 с двумя ОС на борту(W10 и Arch). По работе для выполнения различных задач требуется переключаться межу ними. У бука в обеих осях одинаковый hostname, к сети бук подключается по wi-fi. Так вот в чем проблема, за буком зарезервирован ip по мак-адресу, но при загрузки под Arch-ем карта получает другой ip по dhcp. В общем все на скриншоте. Что это такое и как с этим бороться? http://itmages.ru/image/view/4375072/d0d57b00 Делал подмену мака получил вот это: http://itmages.ru/image/view/4375076/3c11c5c3

При загрузке с любого livecd\dvd\usb дистрибутива бук получает нужный ip.

★★★

Последнее исправление: Falcon-peregrinus (всего исправлений: 1)

Mac адрес на арче такой же? Последний networkmanager имеет функцию рандомизации мака для wi-fi и может она включена по дефолту.

MLP_Fan ★★
()
Ответ на: комментарий от snaf
~] >> ifconfig -a
[sudo] пароль для ad: 
enp3s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 28:d2:44:b1:80:a1  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 13  bytes 720 (720.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13  bytes 720 (720.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.15  netmask 255.255.255.0  broadcast 10.0.2.255
        inet6 fe80::fa16:54ff:fedd:7980  prefixlen 64  scopeid 0x20<link>
        ether f8:16:54:dd:79:80  txqueuelen 1000  (Ethernet)
        RX packets 7383  bytes 3039087 (2.8 MiB)
        RX errors 0  dropped 32  overruns 0  frame 0
        TX packets 999  bytes 154854 (151.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[~] >>            

Выхлоп tcpdump [url=]https://www.dropbox.com/s/1dnzzx5t5gsa43i/dump?dl=0

julixs ★★★
() автор топика
Ответ на: комментарий от MLP_Fan

То есть, это для безопасности конечного пользователя? Против засранцев вроде меня, которые складывают все в базу nfseen?

DALDON ★★★★★
()
Последнее исправление: DALDON (всего исправлений: 1)

Я вижу два момента:

1. Резервирование на самом деле не по MAC, а по некой совокупности параметров, которые передаёт DHCP клиент.

2. DHCP клиент на Arch в текущем состоянии настроек отличается от обычного состояния большинства других систем.

Скорее всего DHCP запросы с Arch можно привести к любому желаемому виду. Где-нибудь в dhcpcd.conf или ином по теме.

Elyas ★★★★★
()
Ответ на: комментарий от Elyas

1. Резервирование на самом деле не по MAC, а по некой совокупности параметров, которые передаёт DHCP клиент.

Ну хз, при резервировании можно ввести только 3 параметра: hostname, mac и ip, причем потом изменить можно только mac и hostname, так что резервирование все таки по мак.

2. DHCP клиент на Arch в текущем состоянии настроек отличается от обычного состояния большинства других систем.

Скорей всего.

# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid

Находил инфу про duid, 3комы некоторые отдавали их в dhcp, но согласно описаню они длинней символов на 30, чем в моем случае.

Если я правильно понял решение вопроса кроится вот в этом: In this case, comment out duid and enable clientid above.

julixs ★★★
() автор топика
Последнее исправление: julixs (всего исправлений: 1)
Ответ на: комментарий от Elyas

Где-нибудь в dhcpcd.conf или ином по теме.

Да так и оказалось! Закоментировал DUID и раскоментировал clientid, после перезагрузки бук получил нужный ip, а dhcp мак вместо дуид-а.

Всем СПС!

julixs ★★★
() автор топика
Ответ на: комментарий от julixs

МАС в чистом виде в DHCP запросах как таковых не обязан быть. Часто он включён как часть client id.

Elyas ★★★★★
()
Ответ на: комментарий от julixs

Надо было изначально логи dhcpd смотреть, там скорее всего вместо MAC-адреса вот эта халабурда проскакивала.

Radjah ★★★★★
()
Ответ на: комментарий от Radjah

Да я с начало в стороны dhcp сервера копать начал. У меня такая хрень проскакивала на виндовой гостевой машине(hp какой то был, честно таких даже не видел до этого), когда представители заказчика приезжали - французы, но тогда значения не придал, а потом с рабочим буком впаролся.

julixs ★★★
() автор топика
Ответ на: комментарий от julixs

Тут вот что интересно, по идее DUID это строковое значение mac+interface в кодировке ANSII
То есть строка (свич 3com) 343030312e633634332e393037622d566c616e2d696e7465726661636531 вернет 4001.c643.907b-Vlan-interface1 при переводе hex - > txt. А моя:54dd7980000100011c3087dd28d244b180a1 возвращает [url=]http://itmages.ru/image/view/4376501/310c65ac Поэтому тему duid'a развивать сначала не стал, как оказалось зря. Чет хрень какая то с lor-cod((

julixs ★★★
() автор топика
Последнее исправление: julixs (всего исправлений: 1)
Ответ на: комментарий от DALDON

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

MLP_Fan ★★
()
Ответ на: комментарий от DALDON

Чтобы, например, нельзя было в большой сети с кучей точек доступа отслеживать движение человека у которого wi-fi просто ищет точки не подключаясь.

MLP_Fan ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.