Нужно ли вводить src и dst mac-адрес в поддельном пакете? - PullRequest
1 голос
/ 14 июля 2010

Я начал кодировать пакетный инжектор и немного прочитал о том, что нужно делать. Однако мне интересно, что при создании заголовка IP поля h_source и h_dest должны содержать mac-адрес отправителя и получателя. Нужно ли это делать, и есть ли быстрый способ узнать mac-адрес получателя? Допустим, я создаю ping-пакет ICMP или какой-то произвольный TCP-пакет. Было бы неплохо просто сказать «отправить его на 192.168.0.10 из 192.168.0.1» и не заботиться о mac-адресах. Я предполагаю, что ядро ​​обычно это заполняет, но если оно будет мешать, это не позволит мне полностью контролировать пакет.

Ответы [ 2 ]

4 голосов
/ 14 июля 2010

Боюсь, вы ошиблись, IP не знает адреса MAC, это знает только уровень Ethernet. Вот почему вам нужен протокол ARP, чтобы определить, на какой MAC-адрес отправлять IP-пакет. Обычно вы знаете, к какой подсети вы принадлежите, если IP-адрес назначения локальный, вы ARP для MAC и отправляете его напрямую (хотя обычно это делается на более низком уровне). Если это не в вашей локальной подсети, вы ARP для IP-адреса шлюза и вместо этого отправьте его туда, который будет как-то переадресовать.

Единственным источником и назначением, присутствующим в заголовке IP, являются IP-адреса источника и назначения.

НТН.

EDIT:
В целях разъяснения. При отправке через шлюз IP-пакет обычно не затрагивается (за исключением TTL и, следовательно, контрольной суммы). Есть ситуации, когда IP-пакет должен быть фрагментирован, но это другая проблема. Дело в том, что адреса источника и назначения остаются неизменными, это только на уровне ниже, где мы на самом деле говорим, что его следует отправить через какой-то шлюз или маршрутизатор.

0 голосов
/ 14 июля 2010

Да, вам нужно будет это заполнить. Вы можете использовать ARP для определения MAC-адреса данного IP-адреса: http://en.wikipedia.org/wiki/Address_Resolution_Protocol

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...