Как реализовать модем Ethernet
Хорошо, то, что я хочу сделать в качестве учебного упражнения, это реализовать что-то вроде этого
клиент --ethernet -> Модем1 --GPIO -> Модем2 --ethernet -> Мой домашний маршрутизатор
Где клиент соединяется с Модемом 1, используя кабель Ethernet.
Modem1 - это Raberry PI, который преобразует сигнал и передает его через GPIO
Modem2 - это Raberry PI, получает данные от GPIO и отправляет их через кабель Ethernet на мой домашний маршрутизатор.
Я хочу реализовать модемы, но понятия не имею, с чего начать.
Я немного прочитал о программировании Ethernet, но все еще не могу найти ответы на такие "простые вещи", как.
Как реализовать Modem1, чтобы при подключении к клиенту клиент обнаруживал его как интернет-соединение.
На стороне модема 2, как заставить "Мой домашний маршрутизатор" отправлять пакеты, предназначенные для "клиента", на модем 2, чтобы модем 2 мог их пересылать.
и, возможно, вещи, которые у меня нет, хотя....
Итак, как конкретно я могу это реализовать? желательно в ц.
1 ответ
Рискну сказать, что вы могли бы написать какой-то специальный промежуточный слой GPIO.
Чтение Ethernet-> Инкапсуляция-> Запись GPIO->|-> Чтение GPIO-> Декапсуляция-> Запись Ethernet
(и наоборот)
Тогда возникает проблема: как оба модема могут действовать как "прокси Ethernet"?
Модем1 действует как прокси для роутера. Модем2 действует как прокси для клиента. Если ваш Raspberry Pi может подделать MAC-адреса, возможно, вы сможете обмануть одноранговых узлов Ethernet в связи с портом Ethernet ваших модемов. Причина, по которой вам необходимо подделать MAC-адреса, заключается в том, что в сетях TCP/IP существует таблица ARP, которая отображает удаленные IP-адреса на MAC-адреса, которые могут направлять IP-пакеты к ним или из них. Это то, что позволяет вашему клиенту общаться с вашим маршрутизатором по TCP/IP.
Другая потенциальная ловушка - это то, когда ваша модемная связь создает задержки, которые мешают обработке протокола на уровне Ethernet. Например, протокол Ethernet может иметь ограничения в реальном времени, которые могут быть разрушены, если вы введете задержки...
Но давайте предположим, что в идеальном мире все возможно...
Вам нужно будет написать код для чтения / записи сообщений Ethernet (я видел открытый исходный код для чтения / записи пакетов Ethernet через raw-сокеты в Linux)
Вам нужно написать собственный драйвер для ваших GPIO-коммуникаций. Это означает реализацию тщательно продуманного протокола для управления состоянием булавок, началом сообщения, концом сообщения, полезной нагрузкой данных, контрольной суммой, чем угодно...
Наконец, вам нужно написать коммуникационный уровень верхнего уровня, который реализует:
Процесс Ethernet-to-GPIO:
а) чтение из порта Ethernet, инкапсулирует пакет Ethernet в пользовательское сообщение (или фрагменты сообщения)
б) передать это пользовательское сообщение, используя ваш собственный драйвер протокола GPIO, внешнему узлу GPIO
Процесс GPIO-to-Ethernet:
a) Чтение из GPIO, используя ваш собственный код драйвера. b) Декапсуляция пакета Ethernet. c) Запись пакета Ethernet в порт Ethernet.
эти два процесса работают вечно...
Опять же, все зависит от того, могут ли ваши модемы вставлять себя в одноранговое соединение, не нарушая естественный поток протокола Ethernet...
Что касается части 'C'...
Если вы используете библиотеки с открытым исходным кодом (или фрагменты кода) для чтения / записи необработанного Ethernet через необработанные сокеты, это, скорее всего, написано на C.
Ваш код GPIO будет считывать запись с выводов GPIO одним из двух способов: с H/W-адреса, отображенного в памяти, или с использованием вызовов ioport на этом H/W-адресе.
Получите сырые кадры Ethernet в Linux
Отправить необработанный кадр Ethernet в Linux
Удачи