Динамический IP на устройстве, Как найти свою железку? Опции

[-= Александр =-]

Добрый день!
В общем делаю я некое устройство с управлением через Ethernet. Подумалось мне, что будет гораздо удобнее сделать ему присвоение адреса по DHCP, чем зашивать его в явном виде и где-то на наклейке писать. Юзеры глупые, бумажку потеряют, программное с другой машины с другими настройками перетащут и будет мне головная боль. Другое дело когда все автоматическое

Так вот вопрос: как машине найти железку, не зная под каким адресом она запустилась? Машина тоже получает адрес от сервера и железка аналогично его не знает.
Есть всякие роутеры, так-же получающие адрес, но есть к ним фирменные программки, которые их каким-то волшебным образом находят. Как же это работает? Там явно не перебор адресов, все гораздо быстрее.

[Kuzmi4]

2 -= Александр =-
просто запускаете стандартный isc-dhcp-server на машине, который раздаёт IP -> на железяке обычный DHCP client. Или вам надо выдавать как то специфически IP для ваших железяк ?

[zltigo]

Там явно не перебор адресов...

Broadcast запросы в локальной сети еще никто не отменял. Вот так все просто.

просто запускаете стандартный isc-dhcp-server на машине, который раздаёт IP -> на железяке обычный DHCP client.

Але гараж! Кто из них скажет любой другой машине на неведомом адресе какой адрес был выдан конкретной железке?

[_3m]

2 -= Александр =-
просто запускаете стандартный isc-dhcp-server на машине, который раздаёт IP -> на железяке обычный DHCP client. Или

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

[-= Александр =-]

Да, действительно, я и забыл что так можно)
Broadcast делается на уровне IP или где-то глубже?

Про роутеры пока не думаем, все в одном сегменте работает.

[zltigo]

Broadcast делается на уровне IP или где-то глубже?

По желанию - есть и IP и MAC broadcast. Судя по этому Вашему вопросу, Вам надо с UDP/IP работать, поскольку явно взяли какой то готовый IP стек и испытываете уверенность что всегда будет существовать DHCP сервер.

[krux]

гуглите в направлении "групповой MAC-адрес".

представьте себе 10 ваших устройств, воткнутых в один коммутатор, и комп.
у каждого вашего устройства два MAC-адреса: есть свой уникальный MAC-адрес и общий для всех ваших устройств одного типа групповой MAC-адрес.
на уникальный MAC устройство реагирует нормальным образом, реализуя всю обычную логику протокола ARP.
при получении пакета на групповой MAC-адрес, ваше устройство формирует специальный UDP пакет вашего формата, протокол вашей разработки.

на компе запускаете UDP-сокет на прием и RAW-сокет на передачу.
при помощи RAW-сокета формируете специальный ARP-запрос с групповым MAC-адресом.
все 10 ваших устройств его получают, но ответ на него формируют с использованием своих индивидуальных MAC-адресов (и полученных по DHCP IP-адресов) и в адрес IP-адреса компа, с которого вы посылали групповой ARP-запрос.
т.е. на ваш комп на открытый UDP-сокет должны прилететь 10 пакетов с их MAC и их IP.

данное решение работает в одном broadcast-домене, т.е. понятное дело через маршрутизаторы это всё не пролезет.

[-= Александр =-]

Пасибо за ответы, пойду учить матчасть. Пока-что считается что DHCP есть и все в одном сегменте. Остальное может будет, но позже.

[Lagman]

Можно попробовать сделать так, пропинговать диапазон адресов, а потом командой "arp -a" посмотреть и найти нужный mac адрес устройства и привязанный к нему ip адрес.

[-= Александр =-]

пропинговать диапазон адресов

Некрасиво. Да и фиг знает на какой диапазон DHCP настроено, может там вся подсеть вообще и сканировать долго будет.

[Lagman]

У вас сеть выше класса 1С?

[-= Александр =-]

У вас сеть выше класса 1С?

Даже если ниже - всяко секунд 10 пинговать придется, а то и больше. И так при каждом запуске.

[jcxz]

Пасибо за ответы, пойду учить матчасть. Пока-что считается что DHCP есть и все в одном сегменте. Остальное может будет, но позже.

Почему-то никто не вспомнил про DynDNS - поможет в случае разных подсетей, да и вообще совсем разных сетей.
А если Вам нужно узнать IP-адрес, а MAC известен, то поможет RARP (это протокол обратный ARP).
А если известно NETBIOS-имя устройства/компа, то поможет преобразовать его в IP протокол WINS.

[zltigo]

Почему-то никто не вспомнил про DynDNS - поможет в случае разных подсетей, да и вообще совсем разных сетей.

Никакого отношения к собственно задаче найти свою железку не имеет.

А если Вам нужно узнать IP-адрес, а MAC известен, то поможет RARP (это протокол обратный ARP).

Ага, и заставить пользователя вбивать и запоминать еще больше цифр. Плюс надо поднять этот протокол.

А если известно NETBIOS-имя устройства/компа, то поможет преобразовать его в IP протокол WINS.

Осталось его поднять на железке, да и на компьютере тоже разрешить, ибо уже в 90x netbios вышел из употребения де факто.

Все ведь просто - посылается broadcast UDP запрос на порт предназначенный для целей идентификации у железки. Железка видит, что запрос именно ее, а не вообще что-то чужое и радостно узнает из него IP адрес компьютера и сообщает на него о своем существовании.
Всего делов на полчаса.

[jcxz]

Никакого отношения к собственно задаче найти свою железку не имеет.

Железке присваиваем уникальное символьное имя. При включении железка по DHCP получает IP и регистрирует его на DynDNS для вышеозначенного символьного имени. Далее - любой клиент может разресольвить это символьное имя в её IP.
Что не так?

Ага, и заставить пользователя вбивать и запоминать еще больше цифр. Плюс надо поднять этот протокол

Вы о чём?? Что вбивать и что запоминать?
У железки однозначно есть какой-то MAC. И естественно пользователь на компе должен его знать. Но в этом же нет проблем?
Он же не меняется. А меняется IP, который и нужно узнать.
Вот RARP - он как раз для этого.
А поднимать всё равно что-то придётся. Но лучше поднимать стандартный протокол, а не самопал, чтобы не получить потом люлей от админа.

Осталось его поднять на железке, да и на компьютере тоже разрешить, ибо уже в 90x netbios вышел из употребения де факто.

Да ладно! И сетевыми папками Вы с 90-х не пользовались и сетевым принтером тоже и т.п.? Я Вам сочувствую

Все ведь просто - посылается broadcast UDP запрос на порт предназначенный для целей идентификации у железки. Железка видит, что запрос именно ее, а не вообще что-то чужое и радостно узнает из него IP адрес компьютера и сообщает на него о своем существовании.

Это "просто" до первого конфликта по портам с другой такой-же железкой, сляпанной таким же умельцем
А чтобы этого избежать, надо будет дать возможность пользователю изменить этот порт - и опять же придётся ему "вбивать и запоминать еще больше цифр"
Да и как быть за пределами подсети?

Имхо - следует максимально возможно использовать стандартные протоколы, а не лепить самопал.
И даже в этом случае - прежде чем его лепить, нужно изучить все возможности стандартных протоколов и если их почему-то не хватает - только в этом случае ваять своё.
Лепить свой велосипед в обход всех стандартов и не зная их - это пионэрский подход, странно слышать от Вас призывы к этому.
Ну если конечно эта железка делается только для себя и не пойдёт ни к кому. Но тогда не проблема и просто в своём роутере прописать фиксированную аренду постоянного IP для этой железки и не маяться. Может ТСу так и сделать? Он в курсе такой возможности?

[zltigo]

Вы о чём?? Что вбивать и что запоминать?
У железки однозначно есть какой-то MAC. И естественно пользователь на компе должен его знать. Но в этом же нет проблем?

Ознакомьтесь с постом Автора, который не хотел назначать даже IP адрес, дабы пользователь его не запоминал, не забывал и не набирал.
Так "Вы о чём??"©

Да ладно! И сетевыми папками Вы с 90-х не пользовались и сетевым принтером тоже и т.п.? Я Вам сочувствую

Да именно так - с 90x ничем на нетбиосе не пользуюсь, как не пользуются им ДЛЯ РАБОТЫ сетевые диски и прочие. Всегда Disabled. Сочувствия не принимаю .

Это "просто" до первого конфликта по портам с другой такой-же железкой, сляпанной таким же умельцем
А чтобы этого избежать, надо будет дать возможность пользователю изменить этот порт - и опять же придётся ему "вбивать и запоминать еще больше цифр"

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

Да и как быть за пределами подсети?

Ни один из прeдложенных и Вами способов эту проблему не решит, поскольку даже знание глобального и локального адресов железки не поможет пробиться к ней через роутер. Такая проблема решается по другому, но автору этого и не требуется.

Имхо - следует максимально возможно использовать стандартные протоколы, а не лепить самопал.

Никакого самопала нет и в помине. Берется совершенно стандартный UDP/IP и любой из портов разрешенный для приложений. Все совершенно стандартно.
Иначе по Вашей логике Автор ничего и для взаимодействия со своей железкой использовать не должен креме telnet и прочих , ибо "нестандартно"

Лепить свой велосипед в обход всех стандартов и не зная их - это пионэрский подход, странно слышать от Вас призывы к этому.

Ответ Выше.

[jcxz]

Ознакомьтесь с постом Автора, который не хотел назначать даже IP адрес, дабы пользователь его не запоминал, не забывал и не набирал.
Так "Вы о чём??"©

У автора ETHERNET. Прочитайте по слогам несколько раз, а потом объясните - каким образом не назначая MAC работать через Ethernet?

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

Видно что искусство чтения Вам недоступно. В "этой" нет, и что? Вы же предлагаете широковещательно отправлять. А широковещательно - значит, что этот пакет попадёт на все прочие железки с открытым таким портом, на что они как-то отреагируют. При том что Вы в принципе не знаете какие такие открытые порты могут быть в сети пользователя. И как это оборудование будет реагировать на Ваши самопальные пакеты.
Второе - эти самые чужие железки тоже могут отправлять широковещательные кадры на ваш порт в железке.

Ни один из прeдложенных и Вами способов эту проблему не решит, поскольку даже знание глобального и локального адресов железки не поможет пробиться к ней через роутер. Такая проблема решается по другому, но автору этого и не требуется.

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

Иначе по Вашей логике Автор ничего и для взаимодействия со своей железкой использовать не должен креме telnet и прочих , ибо "нестандартно"

Я не говорил, что не может. Не передёргивайте. Я писал, что городить свой велосипед нужно тогда и только тогда, когда нет стандартного средства решения или оно по каким-то причинам не подходит. А из сообщений автора видно, что он даже не знает о существующих решениях. Соответственно - не зная их, начиная изобретать что-то своё, запросто нагородит такого, что будет с чем-то конфликтовать.

[zltigo]

У автора ETHERNET. Прочитайте по слогам несколько раз, а потом объясните - каким образом не назначая MAC работать через Ethernet?

Автор спрашивал как ему назначить MAC? Нет? Тогда зачем наводите тень не плетень в ответе на вопрос, как узнать выданный DNS IP?

Видно что искусство чтения Вам недоступно. В "этой" нет, и что? Вы же предлагаете широковещательно отправлять. А широковещательно - значит, что этот пакет попадёт на все прочие железки с открытым таким портом, на что они как-то отреагируют. При том что Вы в принципе не знаете какие такие открытые порты могут быть в сети пользователя. И как это оборудование будет реагировать на Ваши самопальные пакеты.
Второе - эти самые чужие железки тоже могут отправлять широковещательные кадры на ваш порт в железке.

Никаких проблем. В сети могут бегать и БЕГАЮТ самые разные пакеты от и для самых разных устройств. Как широковещательные, так и нет. Любое устройство должно уметь отличать свои и чужие. Это даже не обсуждается, иначе интеренет будет разрушен даже не первым залетевшим дятлом.
Так что не надо проявлять заботу о неких уж действительно махровых самодельщиках, которые вдруг получив на свой порт неведомый пакет на broadcast адрес с неведомого порта выпадут в осадок, или ответят чем то неведомым, но Автор посчитает это достойным ответом и решит, что приславший неведомый ему пакет, а не пакет типа "Здравствуй, сервер, это я товоя железка ERWQYWRT с серийным номером 1421412534", есть его оборудование.

но - как это у меня получается связаться с DNS-сервером находящимся через несколько роутеров от меня, получить от него IP и соединиться потом по этому IP. Считаете это фантастикой?

А у кого проблема саязаться с DNS сервером? У кого проблема получить СВОЙ адрес? Кто жаловался???
Проблема узнать ЧУЖОЙ адрес и потом (это Вы уже решили усложнить) пробится через роутеры, если он не глобальный.

Я не говорил, что не может. Не передёргивайте. Я писал, что городить свой велосипед нужно тогда и только тогда, когда нет стандартного средства решения или оно по каким-то причинам не подходит. А из сообщений автора видно, что он даже не знает о существующих решениях. Соответственно - не зная их, начиная изобретать что-то своё, запросто нагородит такого, что будет с чем-то конфликтовать.

Уродливые "стандартные" предлагаемые Вами к использованию через анус, действительно не подходят. И в случае тогоже нетбиоса обернутого в TCP просто уродливы и живы только благодаря усилиями MS по их поддержке для "совместимости". По этой причине абсолютно все известные мне производители (включая меня ) оборудования делают поиск своих устройств своими утилитами в сегменте локальной сети именно на выделенном для этой цели порте. Например, MOXA использует 4800 UDP порт. По нему идет и поиск, и чтение настроек. Для переконфигурации и перепрошивки используется еще один порт и еще один для мониторинга. И никакой "стандартизации" там, где она ни нафиг никому не нужна в отличие от, например, поисков тех-же сетевых принтеров WIN средстваими и установки какого нибудь драйвера из WIN коллекции. При этом родные установщики этих-же принтеров ни нафиг не пользуются всякими нетбиосами с обертками. Все действия по стандартизации должны быть осмысленными. Любителей пушек и линуксов для стрельбы по воробьям и так хватает.

[_3m]

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

Да, это фантастика.
Аксиома1: настройки и логи роутера, dhcp сервера и прочих сетевых устройств недоступны: заблокировано злыми админами или СБ.
Аксиома2: выхода в интернет нет: заблокирован "товарищами" из п.1 или на объекте интернета нет вообще. Работаем только в локалке.

[jcxz]

Аксиома2: выхода в интернет нет: заблокирован "товарищами" из п.1 или на объекте интернета нет вообще. Работаем только в локалке.

Эта неверна. Так как автору нужна работа именно по IP, значит он должен быть доступен.

Автор спрашивал как ему назначить MAC? Нет? Тогда зачем наводите тень не плетень в ответе на вопрос, как узнать выданный DNS IP?

Опять передёргиваете.
Это вообще-то Ваша сентенция была - "о, ужос! это же надо что-то назначать...".
На что я заметил - раз ETHERNET, то по-любому MAC уже назначен.
А из этого следует - RARP - уже возможен и более ничего не требует. Никаких "назначений".
А "махровый самодельщик" - это похоже Вы так самокритично о себе?
Ибо куда уж махровее, когда есть стандарт, реализующий данный способ (RARP), взамен него лепить что-то своё, делающее то же самое?

А у кого проблема саязаться с DNS сервером? У кого проблема получить СВОЙ адрес? Кто жаловался???
Проблема узнать ЧУЖОЙ адрес и потом (это Вы уже решили усложнить) пробится через роутеры, если он не глобальный.

Вы уверены, что понимаете значение термина "DNS"?
DNS - это средство преобразования символьного имени в IP-адрес. Заметьте - любого имени.
Попробуйте набрать в строке браузера "electronix.ru". Вот этот адрес для вас - чужой. И Ваш браузер, чтобы определить IP-адрес "electronix.ru", обратиться к DNS (если конечно его нет в локальном DNS-кеше). Вот именно чужие адреса и разресольвивает DNS.
Причём тут СВОЙ адрес?
Вот так и серверное ПО автора сможет обратиться к DNS, чтобы узнать IP адрес устройства по заранее заданному фиксированному имени. А уж устройство, когда включится, сообщить DynDNS свой текущий IP. И этот протокол работает через все роутеры и фаерволлы (как правило).

Уродливые "стандартные" предлагаемые Вами к использованию через анус, действительно не подходят. И в случае тогоже нетбиоса обернутого в TCP просто уродливы и живы только

У Вас тут на конфе почти в каждом сообщении то "уродливые", то через "анус". Прямо какая-то обида на жизнь, в самом деле...
А если бы Вы ещё иногда опускались до чтения того, на что отвечаете, то могли бы заметить, что я писал про NETBIOS-имена(!).
Ни про NETBIOS-протокол! Ни про какие-то его TCP-обёртки! - это всё Ваши фантазии. Только NETBIOS-имена. Почувствуйте разницу.
Я говорил про WINS. Как ещё одно средство преобразования некоего почти произвольного символьного имени в IP-адрес. Вот NETBIOS-имя только в контексте WINS.

PS: Да - и не надо про то, что автору "не нужна работа через шлюз в другую подсеть". Сейчас не нужна - завтра понадобится. И придётся весь велосипед переписывать.
Вон автор уже пишет, что там есть какие-то пользователи. Завтра к этим пользователем придёт новый админ и отсадит их за шлюз от железки. И потом автор будет объяснять им почему он не предусмотрел такую вроде само собой разумеющуюся вещь как возможность работы в разных подсетях.

[_3m]

Эта неверна. Так как автору нужна работа именно по IP, значит он должен быть доступен.

IP != доступ в Интернет

[Corvus]

Присоединяюсь к варианту zltigo. Широковещательный запрос по UDP.
Для примера посмотрите, как это сделано на отладках серии Stellaris от TI.

https://github.com/hrshygoodness/Luminary-M...nder/finder.cxx - утилита для Win
https://github.com/hrshygoodness/Luminary-M...utils/locator.c - код для контроллера, под LwIP.

Если хочется совсем по-взрослому, гуглите SSDP и UPnP.

[gosha-z]

Выбирайте:
Link-Local Multicast Name Resolution
Multicast DNS

Из той же оперы:
DNS-Based Service Discovery
Web Services Dynamic Discovery

[zltigo]

Ибо куда уж махровее, когда есть стандарт, реализующий данный способ (RARP), взамен него лепить что-то своё, делающее то же самое?

Может хватит Вам уже дурака валять. Глупо.

У Вас тут на конфе почти в каждом сообщении то "уродливые", то через "анус". Прямо какая-то обида на жизнь, в самом деле...

Не фантазируйте. Я своей жизью не обижен.

А если бы Вы ещё иногда опускались до чтения того, на что отвечаете, то могли бы заметить, что я писал про NETBIOS-имена(!).
Ни про NETBIOS-протокол! Ни про какие-то его TCP-обёртки! - это всё Ваши фантазии. Только NETBIOS-имена. Почувствуйте разницу.
Я говорил про WINS. Как ещё одно средство преобразования некоего почти произвольного символьного имени в IP-адрес. Вот NETBIOS-имя только в контексте WINS.

WINS есть обертка над NETBIOS обернутым в IP. К чему все это Ваше словобудие было?

PS: Да - и не надо про то, что автору "не нужна работа через шлюз в другую подсеть". Сейчас не нужна - завтра понадобится. И придётся весь велосипед переписывать.

Третий и последний раз, ибо надоело поворять элементарные вещи - никакое знание имен или адресов или всего вместе не позволит пробиться через "через шлюз в другую подсеть" от устройства находящегося за другим шлюзом к устойству имеющему локальный адрес без изменения настроек шлюзов или посредников с глобальными адресами. Если говорить только о локальной сети, то для работы локальной достаточны broadcast для подсети или всей сети.

[gosha-z]

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

[zltigo]

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

Если узнаете, что такое локальная IP сеть и глобальная, то поймете что есть локальный и глобальный адреса.
Локальный адрес это уникальный идентификатор в пределах локальной сети. Глобальный это уникальный индентификатор в пределах всей глобальной сети.

[krux]

2 jcxz

а подскажите, какой из сервисов DynDNS,про которые вы говорите, сейчас 1) имеют свободную регистрацию новых пользователей 2) являются бесплатными

[gosha-z]

Локальный адрес это уникальный идентификатор в пределах локальной сети. Глобальный это уникальный индентификатор в пределах всей глобальной сети.

Не путайте народ. Есть четкое определение адресов для "внутреннего пользования" (тут).Есть еще Link Local адреса, но это из другой оперы.

[zltigo]

Не путайте народ. Есть четкое определение адресов для "внутреннего пользования" (тут).Есть еще Link Local адреса, но это из другой оперы.

Не путайте себя тем, что понять не можете. И вобще private это частный а не "внутрений". Не путайте . Вот терминология русского интернета https://ru.wikipedia.org/wiki/Частный_IP-адрес придуманного Вами синонима "внутреннего использования" нет, хотя мне понятно что за адреса Вы так называете - нет проблем. "Локальный адрес" там есть. Если нравится слово "внутри" и не нравится "локальный", то все же лучше использовать распространенный синоим "внутрисетевой".

[jcxz]

Если говорить только о локальной сети, то для работы локальной достаточны broadcast для подсети или всей сети.

Именно о локальной сети и говорилось. Причём тут интернет?
Ваши броадкасты будут ходить ходить до ближайшего шлюза. В более-менее крупной конторе уже несколько подсетей внутри сети.
Другая подсеть, к Вашему сведению, это когда (netmask & ip_addr) != 0.

Присоединяюсь к варианту zltigo. Широковещательный запрос по UDP.
Для примера посмотрите, как это сделано на отладках серии Stellaris от TI.

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

а подскажите, какой из сервисов DynDNS,про которые вы говорите, сейчас 1) имеют свободную регистрацию новых пользователей 2) являются бесплатными

Раньше я несколько лет пользовался http://freedns.afraid.org. Соответствовал и 1 и 2.
Но года 3 как уже не нужно.

[zltigo]

Именно о локальной сети и говорилось. Причём тут интернет?

Да, Вы действительно говорили "именно о локальной" и это не мешало Вам лихо поминать тот же DynDNS Хватит юлить

Ваши броадкасты будут ходить ходить до ближайшего шлюза.

Не знаю, как Ваши , а мои, которые direct broadcast, а не limited broadcast ходят и за шлюз, как им и положено. Добавляется пребор старших адресов, печально, но не смертельно. Фантазии про страшных админов избирательно борющихся только с тем, что не подходит под ваши идеи, но зато безропотно запускающие у себя на всякие "нужные" Вам сервисы и допускающие к каким попало внешним сервисам меня рассторгали до глубины души.
Совершенно очевидно что с ни одной сколь-нибудь серьезной "конторой" Вы не сталкивались.

[KRS]

А если Вам нужно узнать IP-адрес, а MAC известен, то поможет RARP (это протокол обратный ARP).

Только RARP
1. Устаревший протокол
2. Использовался не для определения IP адреса по MAC
3. Т.к. это не IP протокол есть сложности с реализацией под windows

как уже предложил zltigo
надо делать UDP broadcast запрос - это самый простой и надежный вариант.

[Kabdim]

А чего никто не вспоминает про UPnP?

[gosha-z]

Другая подсеть, к Вашему сведению, это когда (netmask & ip_addr) != 0.

Точнее, (src_addr & netmask) != (dst_addr & netmask)