Comments 74
И не забываем о малом, но возможном варианте получить коллизию на свитче.
Который берет 2 байта влан, 6 байт от mac и в сумме пакует их в 6 байт.
Поэтому 2 разных mac могут оказаться одним и тем же. Но редко.
Который берет 2 байта влан, 6 байт от mac и в сумме пакует их в 6 байт.
Поэтому 2 разных mac могут оказаться одним и тем же. Но редко.
«Патентованное восстановление реального МАС» — надувательство.
А разве кто-то заявлял о патентах?
Так, только маркетологи для красного словца…
Исторически адреса прошивались в ПЗУ чипсета сетевой карты без возможности их модификации без флеш-программатора, но в настоящее время адрес может быть изменен программно, из операционной системы.
Кхм.
Исторически, где-то во второй половине 90х своими руками и прилагавшейся утилиткой под дос менял мак на еще isa'шной сетевухе, как бы не соврать — еще с двумя, BNC+TP разъемами.
По причине случившейся коллизии мак-адресов в сетке.
Спасибо за статью, интересно было почитать. Для меня стало новостью, что можно купить себе собственный блок MAC-адресов всего за $755)
Только смысла в нем нет никакого, если вы не собираетесь производить свои устройства.
Здесь интереснее другие вопросы, например, насколько «законно» (соответствует разным политикам IEEE) изменять MAC контроллера, который произвел не ты на свой купленный, например в конечном устройстве.
А вообще, вопрос в цене и связях. Вот отменили на CA/B Forum SSL для IP адресов (и доменов .local), но 1.1.1.1 его имеет.
Здесь интереснее другие вопросы, например, насколько «законно» (соответствует разным политикам IEEE) изменять MAC контроллера, который произвел не ты на свой купленный, например в конечном устройстве.
А вообще, вопрос в цене и связях. Вот отменили на CA/B Forum SSL для IP адресов (и доменов .local), но 1.1.1.1 его имеет.
Давным давно я работал в поддержке интернет провайдера. Запомнился пользователь, у которого интернет то работал, то нет. Оказалось, что у него mac адрес был полностью забит нулями, у кого-то другого в сети, судя по всему, тоже. Надиктовал ему от балды новый mac и всё починилось.
Подобное сплошь и рядом творится. Был клиент, который получал IP-адреса от DHCP и потом руками их прописывал как статику (зачем?!). Само собой, когда какой-то компьютер долго не использовался (трое суток), аренда отменялась и IP мог быть выдан кому угодно (в том числе, клиенту другой компании). Потом тот компьютер в первой организации включали и в сети начинались коллизии. Сошлись на том, что сдали в аренду клиенту целую подсеть, ибо уж очень он хотел прописывать статику.
клиент, который получал IP-адреса от DHCP и потом руками их прописывал как статику (зачем?!)
Ну, например, клиент/его сисадмин не умел правильно настраивать nat/firewall/что-то ещё при получении адреса по dhcp.
«Статика по DHCP» — реальный юзкейс. Криворукие админы провайдера настраивают DHCP сервер так, что адрес не всегда отдается или просто сеть хреновая по физике. И у клиента периодически (но регулярно) нет коннекта, винда в панике — клиент психует. Но если прописать статику, то ничего не отваливается, или отваливается, но клиент не замечает. Все спокойны — все хорошо.
Это не всегда отвечает решаемым задачам. В том случае, о котором я говорил, клиенту нужен был прямой выход в интернет на каждом компьютере со своим собственным IP, но платить за аренду подсети по началу клиент был не готов :)
Насколько помню, ещё с Windows 2000 (а то и раньше), в настройках адаптера появилась "альтернативная конфигурация", которая и применялась только в случае невозможности получения аренды DHCP.
Однажды пришла нам партия телефонов Avaya в количестве 150 штук с одинаковыми МАС ( примерно по 5-10 штук совпадали). Ставить мы их начали не сразу, а по мере требования и в разных вланах. Но вот руководство решило собрать все ip телефоны в один влан… То то же мы поразвлекались.
И на корпусе тоже были нанесены одинаковые MAC?
Потому что, если да — то это один разговор (подделка? рефаб?), если нет — другой (кто-то не очень прямыми руками ковырял софт/обновлял).
Потому что, если да — то это один разговор (подделка? рефаб?), если нет — другой (кто-то не очень прямыми руками ковырял софт/обновлял).
Был баг, описан у Avaya, при обновлении определенной модели на определенную прошивку он в сбрасывал MAC адрес на определенный. У нас так полегло порядка 30 телефонов. Причем все были в одном стеке свитчей.
Старые D-Link 620 под старой OpenWRT выдают мак '11:22:33:44:55:66', если не вмешаться руками. Забавно на это смотреть, если подключение PPPoE у провайдера =)))
Вспоминается байка о том как в Microsoft разбили молотком сетевую карточку, чтоб гарантировать уникальность GUID-а.
UFO just landed and posted this here
Это SecureRandom(). Некоторое описание реализации здесь.
C iOS7 уже не получить MAC адрес
Есть неточность утверждение в статье что в сети не должно присутствовать идентичных mac адресов. В современных сетях это встречается очень часто, единственное условие — адреса должны быть уникальными в пределах одного L2 домена АКА vlan. В общем случае mac может и повторяется постоянно
Подменой адреса можно попробовать "представиться" вашим устройством, что может сработать, только если не применяется дополнительных средств защиты (авторизация и/или шифрование). 99.9% людей здесь не о чем волноваться.
В современном мире это далеко уже не так. Многие публичные сервисы привязывают MAC устройства к номеру телефона — этого требует закон об обязательной идентификации абонентов, причём не только в России.
Ну а дальше дело техники: сканируем эфир, подменяем MAC и делаем безобразия от чужого имени. А товарищ майор разбираться потом уже не будет. А самое безобидное, чего можно добиться подменой MAC — это подключение к чужому оплаченному Wi-Fi в метро.
Не пользуйтесь вайфаем в метро, да и вообще в публичных местах, пока повсеместно не внедрят Hotspot 2.0.
Все гостевые сервисы должны привязывать МАС к номеру телефона. Однако тот закон не регулирует механику передачу привязки товарищу майору. На практике интеграция авторизации с СОРМ реализована только у крупных операторов.
Все гостевые сервисы должны привязывать МАС к номеру телефона. Однако тот закон не регулирует механику передачу привязки товарищу майору. На практике интеграция авторизации с СОРМ реализована только у крупных операторов.
Не пользуйтесь публичный Wi-Fi даже после внедрения Hotspot 2.0.
Кстати, в Android 10 есть возможность использования случайного MAC в каждой новой сети:
ibb.co/BnzHfsK
Кстати, в Android 10 есть возможность использования случайного MAC в каждой новой сети:
ibb.co/BnzHfsK
Восьмой (с начала) бит первого байта МАС адреса называется Unicast/Multicast битом и определяет,
Как вы биты считаете?
Википедия говорит о двух младших битах первого байта.
На картинке (с википедии) как-бы тоже b0 и b1.
Little-endian vs big-endian ?
Little-endian vs big-endian — это про то, как два (или более) соседних байта byte0 byte1 формируют целое число: byte0 + byte1*256 или же byte1 + byte0*256.
Когда разговор идет об одном единственном байте, никаких Little-endian vs big-endian нет, так как мы не можем прочитать байт частично, мы всегда читаем его целиком.
Когда разговор идет об одном единственном байте, никаких Little-endian vs big-endian нет, так как мы не можем прочитать байт частично, мы всегда читаем его целиком.
Но в сети физическая передача-то последовательная. Так что тоже возможны два порядка. И в Ethernet первым идет именно младший бит. Поэтому он и выбран под признак Unicast/Multicast, чтобы коммутатору (или получателю) не пришлось весь байт собирать, а прямо по первому биту адреса назначения, который тоже первый в заголовке, можно было определить, в какую таблицу смотреть.
Это все правильно, но в статье речь идет о представлении MAC адреса в памяти PC.
Это представление как-то там соответствует последовательным битикам на канальном уровне,
пикам на осциллографе, whatever.
Но я не знаю, как, и знать не хочу в данный момент, ибо мы все равно в конечном счете обсуждаем представление в памяти PC.
Итого.
В статье на ВИКИ говорится, что младшие биты b0 и b1 зарезервированы под U/M и G/L.
Окей, топикстартер приводит картинки из ВИКИ с битами b0 и b1, но почему-то называет их старшими (7 и 8 с начала).
Мне это не понятно, об этом и вопрос.
Это представление как-то там соответствует последовательным битикам на канальном уровне,
пикам на осциллографе, whatever.
Но я не знаю, как, и знать не хочу в данный момент, ибо мы все равно в конечном счете обсуждаем представление в памяти PC.
Итого.
В статье на ВИКИ говорится, что младшие биты b0 и b1 зарезервированы под U/M и G/L.
Окей, топикстартер приводит картинки из ВИКИ с битами b0 и b1, но почему-то называет их старшими (7 и 8 с начала).
Мне это не понятно, об этом и вопрос.
Вообще-то топикстартер называет их не старшими, а «восьмой (с начала)» и «седьмой (с начала)». Я это воспринял как «последний и предпоследний», что вообще-то неверно, ибо единственное место, где у бит в байте есть порядок — это сеть, и там они первый и второй. О чем и написал. А написал как комментарий к фразе «так как мы не можем прочитать байт частично, мы всегда читаем его целиком», которая тоже неверна (не всегда), т.к. в проводе байт именно передается и читается по битам.
Моя фраза «так как мы не можем прочитать байт частично, мы всегда читаем его целиком»
относилась к проблеме «Little-endian vs big-endian» в памяти PC.
Вопрос последовательности передачи битиков каждого байта на канальном уровне — это уже не «Little-endian vs big-endian» в памяти PC, а какая-то другая проблема.
Уверен, что у нее есть свое имя в среде инженеров, но это совершенно отдельный вопрос от программирования.
Программисты не знают, что там на канальном уровне.
Вообще, если подумать, раз network byte order нужен для того, чтобы сравнивать получаемые по сети числа по первым байтам (первым — значит старшим), то тогда логично предположить, что в каждом байте старшие биты тоже идут первыми на канальном уровне.
Тогда можно сравнивать вообще по первыи битам.
Отсюда, возможно, идет путаница у ТС.
относилась к проблеме «Little-endian vs big-endian» в памяти PC.
Вопрос последовательности передачи битиков каждого байта на канальном уровне — это уже не «Little-endian vs big-endian» в памяти PC, а какая-то другая проблема.
Уверен, что у нее есть свое имя в среде инженеров, но это совершенно отдельный вопрос от программирования.
Программисты не знают, что там на канальном уровне.
Вообще, если подумать, раз network byte order нужен для того, чтобы сравнивать получаемые по сети числа по первым байтам (первым — значит старшим), то тогда логично предположить, что в каждом байте старшие биты тоже идут первыми на канальном уровне.
Тогда можно сравнивать вообще по первыи битам.
Отсюда, возможно, идет путаница у ТС.
Другая, да. Тем не менее это ситуация, когда байт читается не весь сразу, и порядок битов существует.
А в памяти — да, там байт неделим, разумеется.
А в памяти — да, там байт неделим, разумеется.
Сорри, я уже десять раз исправил коммент.
Таки пишут, что в Ethernet byte order — BE, а bit order — LE.
www.linuxjournal.com/article/6788
Таки пишут, что в Ethernet byte order — BE, а bit order — LE.
www.linuxjournal.com/article/6788
Давайте разберемся.
Для начала, Little endian/Big endian имеет отношение только к порядку байт и только при их сетевой передаче, причем тогда, когда передаются числа типа short и long. Не наш случай. МАС адрес-просто последовательность из 6 идущих подряд байт, без всяких трюков по их перестановке.
Биты в байте (в его двоичном представлении) принято именовать справа налево, от младших бит к старшим потому, что младшие биты отвечают за меньшие, в алгебраическом смысле, числа. Считать же биты можно как угодно, и поскольку мы находимся в регионе, где в письме и чтении принят порядок слева направо, я считаю биты в байтах с первого слева. Тем более такой способ разумен, когда в контексте статьи обсуждаем последовательности из 48 бит, идущих подряд с первого по шестой байт слева направо.
Для начала, Little endian/Big endian имеет отношение только к порядку байт и только при их сетевой передаче, причем тогда, когда передаются числа типа short и long. Не наш случай. МАС адрес-просто последовательность из 6 идущих подряд байт, без всяких трюков по их перестановке.
Биты в байте (в его двоичном представлении) принято именовать справа налево, от младших бит к старшим потому, что младшие биты отвечают за меньшие, в алгебраическом смысле, числа. Считать же биты можно как угодно, и поскольку мы находимся в регионе, где в письме и чтении принят порядок слева направо, я считаю биты в байтах с первого слева. Тем более такой способ разумен, когда в контексте статьи обсуждаем последовательности из 48 бит, идущих подряд с первого по шестой байт слева направо.
А когда числа десятичные записываете, младшая цифра с какой стороны?
Я вас понял :)
Право-лево — это все вкусовщина. Я видел как справо-налево, так и слева-направо.
Важно именно то, какая степень двойки будет стоять при данном бите при переводе в число.
Вобщем, лучше бы вы называли биты как на картинке из вики, меньше было бы путаницы.
Ибо никаких оснований у вашей перенумеровки бит, кроме вкусовщины, нет :)
Право-лево — это все вкусовщина. Я видел как справо-налево, так и слева-направо.
Важно именно то, какая степень двойки будет стоять при данном бите при переводе в число.
Вобщем, лучше бы вы называли биты как на картинке из вики, меньше было бы путаницы.
Ибо никаких оснований у вашей перенумеровки бит, кроме вкусовщины, нет :)
Возможно, но тогда бы обе мои таблицы распределения единиц выглядели (сверху вниз) бы как последовательности 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 и так далее, что сорвало бы крышу у большинства читателей.
(почти некрокоммент, но для полноты таки впишусь)
> Для начала, Little endian/Big endian имеет отношение только к порядку байт и только при их сетевой передаче, причем тогда, когда передаются числа типа short и long.
Классика — именно с IEN137 пошли термины big и little endian. В частности, к данному вопросу относится следующий кусок:
B0 — старший бит, B31 — младший.
Вот вам вполне действующий RFC 791 (IPv4):
Тоже 0 — старший бит как байта, так и 32-битного слова.
Точно так же: z/Architecture Principles of Operation от самой живой big-endian архитектуры. Во всей документации бит 0 — старший бит любого регистра. Иногда это даёт тот эффект, что надо уточнять контекст — одни и те же биты называются 0-31, когда идёт речь об отдельно младшей 32-битной части регистра, и 32-63, когда о полном 64-битном регистре.
Нумерация старшего бита нулём имеет очень существенный смысл для big-endian: в этом случае нумерация битов в многобайтной цепочке становится консистентной независимо от того, вы рассматриваете её по байтам, по полусловам, словам, или любой другой единице. Аналогично, для little-endian нумерация 0=LSB точно так же консистентна. Что я имею в виду: возьмём код работы с битовыми строками по типу:
можно заменить unsigned char, 3, 7 на uint16_t, 4, 15; uint32_t, 5, 31; uint64_t, 6, 63; — принцип хранения взаимозаменяем, можно читать/писать разными вариациями той же функции. Но для LE так не получится: надо будет убрать "~" в вычислении shift. И вариант для LE точно так же не будет однородным для BE.
В битовых полях в C это приводит к коду вида:
(из FreeBSD)
> Биты в байте (в его двоичном представлении) принято именовать справа налево, от младших бит к старшим потому, что младшие биты отвечают за меньшие, в алгебраическом смысле, числа.
Да, так сейчас чаще делают (и во многих источниках, даже если в остальном big-endian, нумеруют 0=LSB: стандарты SCSI). Но это не закон, просто предпочтительная манера. Если бы все машины и форматы изначально были little-endian, она была бы единственной.
> Для начала, Little endian/Big endian имеет отношение только к порядку байт и только при их сетевой передаче, причем тогда, когда передаются числа типа short и long.
Классика — именно с IEN137 пошли термины big и little endian. В частности, к данному вопросу относится следующий кусок:
In order to be consistent, B0 should be to the left of B31. If the
bytes in a word are designated as C0 through C3 then C0 is also to the
left of C3. Hence we get:
|---word0---|---word1---|---word2---|....
|C0,C1,C2,C3|C0,C1,C2,C3|C0,C1,C2,C3|.....
|B0......B31|B0......B31|B0......B31|......
B0 — старший бит, B31 — младший.
Вот вам вполне действующий RFC 791 (IPv4):
A summary of the contents of the internet header follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Тоже 0 — старший бит как байта, так и 32-битного слова.
Точно так же: z/Architecture Principles of Operation от самой живой big-endian архитектуры. Во всей документации бит 0 — старший бит любого регистра. Иногда это даёт тот эффект, что надо уточнять контекст — одни и те же биты называются 0-31, когда идёт речь об отдельно младшей 32-битной части регистра, и 32-63, когда о полном 64-битном регистре.
Нумерация старшего бита нулём имеет очень существенный смысл для big-endian: в этом случае нумерация битов в многобайтной цепочке становится консистентной независимо от того, вы рассматриваете её по байтам, по полусловам, словам, или любой другой единице. Аналогично, для little-endian нумерация 0=LSB точно так же консистентна. Что я имею в виду: возьмём код работы с битовыми строками по типу:
_Bool get_bit(void *bitset_area, unsigned index) {
unsigned offset = index >> 3;
unsigned shift = ~index & 7; // ~ - вот тут специфика BE
return 0 != (1 & (((unsigned char*) bitset_area)[offset] >> shift));
}
можно заменить unsigned char, 3, 7 на uint16_t, 4, 15; uint32_t, 5, 31; uint64_t, 6, 63; — принцип хранения взаимозаменяем, можно читать/писать разными вариациями той же функции. Но для LE так не получится: надо будет убрать "~" в вычислении shift. И вариант для LE точно так же не будет однородным для BE.
В битовых полях в C это приводит к коду вида:
struct ip {
#if BYTE_ORDER == LITTLE_ENDIAN
u_char ip_hl:4, /* header length */
ip_v:4; /* version */
#endif
#if BYTE_ORDER == BIG_ENDIAN
u_char ip_v:4, /* version */
ip_hl:4; /* header length */
#endif
...
};
(из FreeBSD)
> Биты в байте (в его двоичном представлении) принято именовать справа налево, от младших бит к старшим потому, что младшие биты отвечают за меньшие, в алгебраическом смысле, числа.
Да, так сейчас чаще делают (и во многих источниках, даже если в остальном big-endian, нумеруют 0=LSB: стандарты SCSI). Но это не закон, просто предпочтительная манера. Если бы все машины и форматы изначально были little-endian, она была бы единственной.
вспомнилась та маленькая радость, когда провайдер прописывал МАС адрес сетевой карты (чтобы покупали на каждый комп отдельное подключение), а у роутера была функция клонирования МАС адреса.
А ещё были ситуации, что некоторые из подобных роутеров при начальном включении слали пакет с оригинальным MAC-адресом, а потом клонированным. Что ловилось провайдером, и если он блокировал не на MAC-адреса, а на количество устройств, то роутер блокировался и пользователь долго чесал репу, что же не так.
Тут, видимо, все знают, но для меня было новостью, что MAC меняется в операционке, но не в самой сетевой карте. Был случай, когда я через некий софт по винду сменил mac на сетевой карте, и он был для меня удобочитаем. После я пытался включить комп по WOL, но не выходило. Потом оказалось, что он включается, но по своему заводскому MAC, а не по тому, который я ему присвоил.
Ну или это как-то по другому работает.
Спасибо, интересно. Подскажите, а если устройство на свалку что с mac адресом?
Были встроенные материнки, которые в сети не работали без прописывания руками мака (был маленький, причину не выяснил)
А вот потом встречалось такое — комп, подключенные через второй порт ip-телефона переставал (непостоянно!) работать с сервером smtp (25порт), остальное работало без сбоев. И вылечилась сменой мака компа. Повторяющихся маков не было при этом.
По поводу одинаковых MAC-адресов: поимели много веселья, когда два виртуалочных хоста решили своим виртуалкам раздавать одинаковые адреса (как я понимаю, префикс там генерируется при установке, а дальше просто счётчик). Так что, тема с виртуалками (особенно с бекапом-рестором и клонированием) может хорошо помочь в понимании проблем работы сети с одинаковыми адресами.
Тоже ожидал, в статье обо всем что я хотел знать, прочитать информацию о MAC и виртуалках.
Здесь все о очень просто. Если у вас две сетевые карты имеют одинаковый МАС адрес в одном сетевом сегменте (влане), то с точки зрения коммутатора, который этот сегмент (VLAN) обслуживает, будет наблюдаться эффект «mac flapping». По сути это «прыгание» адреса между портами. Что с этим будет коммутатор делать-зависит от вендора. В большинстве случаев — просто обновлять свою таблицу коммутации. Можно настроить блокировку, вот например.
UFO just landed and posted this here
Что будет, если в сети будет присутствовать два устройства с одним МАС адресом? Все зависит от логики сетевого оборудования (проводного роутера, контроллера беспроводной сети). Скорее всего, оба устройства или не будут работать, или будут работать с перебоями.
Построили у нас новую проходную. И поставили на ней 2 турникета и 4 терминала для бесконтактных пропусков. И заметили, что 2 терминала что-то барахлят — чсто не срабатывают с первого раза.
Я пять (пять, Карл!) часов пытался найти причину пропажи связи. Два терминала работают относительно стабильно (в пределах разумного, т.к. сетевухи у них какие-то крайне убогие на полудуплексных 10 Mbit/s и дпускают частые потери пинга), а две показывают странную картину — несколько секунд пингуются, потом примерно такое же время не пингуются совсем, потом снова пингуются.
Я проверил все кабели и коннекторы. Я втыкивал их в другой свитч. Я плясал с бубном по жопе.
Апофеозом стала ситуация, когда я подключил 2 терминала к одному свитчу, два к другому, свитчи соединил между собой и к каждому подключил ноут. На ноутах на четырех CLI шли пинги. Вернее, на одном пинговались три терминала из четырех и на втором три из четырех, но не пингуемые при этом не совпадали. А я тупо смотрел на эту картину и охреневал…
В конце-концов я собрал всё, как было, пошел к себе и тупо проарпил сеть (ну надо же хоть что-то делать). И… глаз зацепился за два одинаковых MAC с разными IP. И это были IP этих двух терминалов.
Вообще-то, я человек культурный и по телефону на поставщиков матом не ругаюсь. Но в данном случае решил сделать исключение. Пять часов! Пять!!!
1:1 наша картина — безопасники жаловались на плохо работающий "считыватель", поставщик хлопал глазами, подключал всё к своему ноуту напрямую — работает идеально, возвращал в "общую" сеть — глюки. Отправил к моим сетевикам, те стали валить на "тупые 10-имегабитные интерфейсы", а причина арпилась с первой же попытки. Теперь если кто-то включает что-то новое (особенно "пришедшее с али"), и начинаются чудеса, сразу отправляю искать дублирующиеся/дефектные (00-00-00-00-00-00 и прочие 11-22-33-44-55-66) MAC-адреса.
Считыватель, случайно, не BioLink FingerPass? :D
Нет, это был не BioLink, но "российский" считыватель карточек Mifare, но сути это не меняет — производители массово выпускаемой мелочёвки (управляемые по сети/WiFi релюшки, IP-камеры, датчики движения и т.п.) за уникальностью MAC-адресов следят не особо строго.
Ну так у нас тоже были проблемы со считывателем Mifare. Забавно было бы, если того же бренда :)
И не только производители мелочевки этим грешат.
У нас есть (или были) бездисковый терминал и принтер с одним и тем же MAC, что несколько странно.
Производитель принтера и сетевухи были почти разные. Принтер HP, а сетевуха в терминале — 3COM. Возможно, пул MAC-адресов после слияния перешел от 3COM к HP и они особо не разбирались, что там уже утилизировано.
И не только производители мелочевки этим грешат.
У нас есть (или были) бездисковый терминал и принтер с одним и тем же MAC, что несколько странно.
Производитель принтера и сетевухи были почти разные. Принтер HP, а сетевуха в терминале — 3COM. Возможно, пул MAC-адресов после слияния перешел от 3COM к HP и они особо не разбирались, что там уже утилизировано.
UFO just landed and posted this here
В МАС адресе 48 бит, из которых «полезными» можно считать 46… что даёт 2^46
В не по трём октетом производителя считать нужно?
Если с бюрократией, то адресов не так уж и много…
Бывают EEPROM, в которые на заводе, в read-only область прошивают гарантированно уникальный МАС адрес. Интерфейс I2C или SPI. Например 24AA02E48. Паяем такую на плату и при старте вычитываем и используем MAC. Бонусом получаем немного EEPROM памяти общего назначения.
Интересно, а много ли случаев, когда один вендор использует в MAC-адресе OUI другого вендора? Например, Cisco в некоторых случаях использует MAC-адреса Citrix при отправке STP BPDUs из vPC на коммутаторах Nexus:
www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/211494-Use-of-Source-MAC-Address-Field-in-Spann.html#anc12
www.cisco.com/c/en/us/support/docs/switches/nexus-7000-series-switches/211494-Use-of-Source-MAC-Address-Field-in-Spann.html#anc12
> Что, если поставить себе МАС с выставленным в «1» седьмым или восьмым битом, т.е. local или multicast-адрес? Скорее всего, ваша сеть на это не обратит внимания, но формально такой адрес не будет соответствует стандарту, и лучше так не делать.
«Немного» не так.
Unicast-адреса локального типа совершенно законны и массово используются во многих случаях. Описанное вами случайное назначение Androidʼом — только один случай. Ещё во многих средах, где стартуют виртуальные машины с собственными (виртуальными) сетевыми адаптерами, им назначаются случайно сгенерированные MAC локального типа, 46 бит случайности. (Есть также традиции, где для этого берутся адреса с 24 битами случайности и вроде бы глобальным префиксом 08:00:27. В общем, вариантов много.)
А вот multicast-адрес получает специальную обработку на свичах: на простых — кадр рассылается всем; на управляемых со сложной логикой — может вообще никуда не уходить, пока не получена IGMP подписка на него… в обоих случаях работа будет совсем не такой, как ожидалась.
«Немного» не так.
Unicast-адреса локального типа совершенно законны и массово используются во многих случаях. Описанное вами случайное назначение Androidʼом — только один случай. Ещё во многих средах, где стартуют виртуальные машины с собственными (виртуальными) сетевыми адаптерами, им назначаются случайно сгенерированные MAC локального типа, 46 бит случайности. (Есть также традиции, где для этого берутся адреса с 24 битами случайности и вроде бы глобальным префиксом 08:00:27. В общем, вариантов много.)
А вот multicast-адрес получает специальную обработку на свичах: на простых — кадр рассылается всем; на управляемых со сложной логикой — может вообще никуда не уходить, пока не получена IGMP подписка на него… в обоих случаях работа будет совсем не такой, как ожидалась.
Sign up to leave a comment.
Всё, что вы хотели знать о МАС адресе