Ethernet на самом низком уровне

Кто-нибудь, помогите! :
Нужно обмениваться по сети компьютерам, которые работают под самодельной ОС (www.multex.nm.ru)
Ну, нашел я описание REALTEK - адаптера, получил доступ к его регистрам, а как организовывать пакеты и вообще, как сеть то работает с ними ??? Подскажите, где найти какую-нибудь документацию об этом. У меня ведь даже NETBIOS-a нет, значит все протоколы нужно вручную наворачивать.
Буду благодарен за любую информацию.

Цитата klotho, 23.04.03, 15:03:59

Кто-нибудь, помогите! :

Тут никто не поможет, это - к психиатру... :-(

Цитата

Нужно обмениваться по сети компьютерам, которые работают под самодельной ОС (www.multex.nm.ru)
Ну, нашел я описание REALTEK - адаптера, получил доступ к его регистрам, а как организовывать пакеты и вообще, как сеть то работает с ними ??? Подскажите, где найти какую-нибудь документацию об этом. У меня ведь даже NETBIOS-a нет, значит все протоколы нужно вручную наворачивать.

Это уже начинаются настоящие "наступания на грабли" ... когда говорят: "не лепите самопалки OS - не дело это!"... Всё далеко не так просто, и только начинается (вам ещё IPC предстоит!!! :-(). Что предстоит сделать с сетью:

1. Прописать стек TCP/IP в полном соответствии с RFC (в Linux, помнится передача TCP - 8000 стр. кода, а приём - 23000, кажется - это когда уже транспорт IP сделан). Почему TCP/IP (там выше фраза про NETBEUI...)? Потому, сто TCP/IP postfactum стандарт общеупотребимый, а NETBEUI etc. - это частная фирменная херня никому, кроме MS не нужная. Т.е. п.1 - прописать "транспортный уровень" 7-уровневой модели OSI.

2. Для каждого типа сетевой карты - написать драйвер, т.е. реализацию MAC-уровня для каждого типа железа (канальный уровень OSI). Это - вниз...

3. А вверх ... Для минимально полноценной OS:
- ppp и инкапсуляция через сериальные каналы;
- всю технику маршрутизации и разрешения имён: DNS, arp - rarp ....
- весь прикладной уровень: telnet, ssl/ssh, ftp, http ..... даже перечислять скучно.

... и вот только после всего этого ... можно подумать об том, чтоб с этой OS начинать выползать в сетевое окружение...

"Я скорблю вместе с вами" (с).

P.S. В качестве бонуса: для попыток обмена MAC-уровня нужно начинать со стандарта NE-2000 совместимых Ethernet карт - с этого все начинают - он масово реализован и достаточно описан. Кстати, выше сказано - REALTEC карта... это кто? "Имя им легион" (с) - если RTL8029 - это и есть NE-2000, RTL8139 ... всё гораздо хуже ...

Сообщение отредактировано: Olej - 23.04.03, 11:44

Спасибо за ответ! Это, действительно, RTL8139, но все не так уж страшно...
После того, как я написал драйверы для звука чипсетов i815 и VIA, да навернул на них MP3-декодер, это уже меня не пугает.
А где посмотреть структуру MAC-заголовка? Я просто с сетями возился до сих пор только на уровне сокетов в Delphi...

Цитата klotho, 23.04.03, 15:50:08

А где посмотреть структуру MAC-заголовка?

MAC пакет - для вашей платы - это Ethernet кадр.
Смотреть всё нужно в RFC (MAC, IP, ICMP/IGMP, UDP/TCP, ARP/RARP...) - номера я не помню, но это и несложно: поисковиком ищем справочники по RFC, есть хорошие русскоязычные, где-то в Новосибирске... Только RFC! - это основополагающие документы, всё остальное - их перепевки...

Цитата

Я просто с сетями возился до сих пор только на уровне сокетов в Delphi...

А первое с чего нужно начать - уровень абстракции сокетов, особенно Delphi - забыть: это всё уже использование надстроек, которые только предстоит построить.

P.S. А если уже и вправду - невмоготу ... я бы сделал так:
1. поставить небольшую "эталонную" OS, лучше из UNIX, я бы лично взял QNX 6.2.
2. установить в нём BPF + libcap - Берклиевский пакетный фильтр.
3. запустить над ним сетевой снифер tcpdump.

Вот теперь можно с tcpdump:
1. смотреть детально структуру всех пакетов: MAC, ARP, IP-UDP-TCP, .... NETBEUI и др.
2. видеть структуру пакетов "мусора", который отсылается из новой OS в процессе доводки и отладки.

Я написал драйвер RTL8139, мне нужно теперь передавать пакеты из Windows в мои вычислители. А можно ли под Win98 выдавать "сырые" пакеты на уровне MAC-адресов?
Собственно, большего мне и не надо...
Я почитал Windows-SDK, там про RAW-Socket что-то невразумительное написано...

2klotho - могу сказать одно, когда я писал драйвер USB устройства + USB host
controllera под DOS то лучше чем исходники ядра Linux быть не может, там и смотри всё что тебе надо особенно по сетям.

P.S почитал про MULTEX, интересно, а драйвер для USB хоста не думали написать, в принципе могу поучаствовать?

Цитата klotho, 28.04.03, 13:13:34

Я написал драйвер RTL8139, мне нужно теперь передавать пакеты из Windows в мои вычислители. А можно ли под Win98 выдавать "сырые" пакеты на уровне MAC-адресов?
Я почитал Windows-SDK, там про RAW-Socket что-то невразумительное написано...

RAW-сокет - это уже сокет IP, но ... незаполненный. Т.е. для его использования уже нужен (полноценный!) транспортный уровень IP!

Сокет MAC-уровня есть пока реализованный только в Linux - тип SOCK_PACKET (так, кажется). Может там, в кодах смотреть надо.

Если уж совсем не ймётся туда лезть - смотрите книгу У.Стивенса, вот здесь об ней:
http://qnx.org.ru/forum/viewtopic.php?topic=1350&forum=12&10
- книга только что вышла в издательстве "Питер" - 1080 стр. детального текста с кодами по использованию техники сокетов. Ничего другого подобного нет!

Цитата Olej, 30.04.03, 12:18:04

RAW-сокет - это уже сокет IP, но ... незаполненный. Т.е. для его использования уже нужен (полноценный!) транспортный уровень IP!

Сокет MAC-уровня есть пока реализованный только в Linux - тип SOCK_PACKET (так, кажется). Может там, в кодах смотреть надо.

Если уж совсем не ймётся туда лезть - смотрите книгу У.Стивенса, вот здесь об ней:
http://qnx.org.ru/forum/viewtopic.php?topic=1350&forum=12&10
- книга только что вышла в издательстве "Питер" - 1080 стр. детального текста с кодами по использованию техники сокетов. Ничего другого подобного нет!

RAW сокеты есть и в Windows 2000.
Сокет MAC уровня звучит интересно в Linux сокет уровня IP если ты имел ввиду не одно и тоже.

Цитата ViSko, 30.04.03, 14:01:08

RAW сокеты есть и в Windows 2000.
Сокет MAC уровня звучит интересно в Linux сокет уровня IP если ты имел ввиду не одно и тоже.

Нет, я имел в виду именно сокет MAC-уровня, т.е. сокет Ethernet-кадра (или другой среды...), именно AF-PACKET в Linux его и определяет. То-же, с чем оперирует перехват пакетов в BPF (Berkley Packet Filter) & tcpdump.
У Стивенса есть...

У Стивенса есть... <br>

до этого я ещё не дочитал  :)

Цитата ViSko, 05.05.03, 17:02:40

У Стивенса есть... <br>

до этого я ещё не дочитал љ:)

fd = socket( AF_INET, SOCK_PACKET, htons( ETH_P_ALL ) );

- странно мне только (но в Linux многое "по-быстренькому") - почему сокет для MAC-уровня должен определяться в семейсиве адресов IP?

сырцы для Ethernet&TCP/IP  смотреть на
http://www.opentcp.org

Кстати, то, что я писал:

Цитата

fd = socket( AF_INET, SOCK_PACKET, htons( ETH_P_ALL ) );

- это специфика Linux, и никого более. А вот в хэдерах стандартной BSD реализации стека TCP/IP определено ещё такое адресное семейство как AF_LINK - т.е. судя по всему - это MAC-уровень, и они его сами в реализации для этого используют. Нельзя ли этой штукой попользоваться с пользовательского уровня?

И ещё одна штука, общеупотребимая (портированная) - это BPF (Berkley Packet Filter). Обычно, его знают в связи с снифером tcpdump, но это гораздо большее - он имеет описанный пользовательский интерфейс, вполне достаточный для манипулирования с сетью минуя стек TCP/IP (или параллельно - потому он и "фильтр"), в том числе и на MAC-уровне, что мы и видим по tcpdump.

Обычно использую в Linux (2.4.3-20mdk):
packet_socket = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL))

По поводу BPF:
если не ошибаюсь, BPF позволяет только получит данные канального уровня, минуя стек TCP/IP. Отправить пакет нельзя (ИМХО).

Сообщение отредактировано: Andy_user - 21.05.03, 13:02

Цитата Andy_user, 21.05.03, 16:58:21

Обычно использую в Linux (2.4.3-20mdk):
packet_socket = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL))

По поводу BPF:
если не ошибаюсь, BPF позволяет только получит данные канального уровня, минуя стек TCP/IP. Отправить пакет нельзя (ИМХО).

Засомневался ... и специально проверил:
- BPF позволяет как принимать, так и отправлять пакеты канального уровня. Выглядит это как-то примерно так:
open( "/dev/bf0", ... ); // там любопытно: bf0, bf1 ... - первый свободный
ioctl(...); // несколько раз - устанавливабтся параметры, фильтр...
read()/write(); // - всё, поехали читать/писать...

- запись в канальный уровень через BPF используется очень редко: UDP/TCP пишутся через IP-сокет, ICMP/IGMP - через RAW ... почти ничего не остаётся... Поэтому запись в BPF менее известна и освещена. Но - напр. демон RARP-разрешителя во многих OS не сделан в ядре (см. ниже), а как пользовательский процесс пишет в BPF. Запись в BPF - незаменимая штука, когда нужно отправлять "хитрые" UDP/TCP сегменты - если вы помните, там такая штука: UDP/TCP пакеты не доходят (!) до RAW-сокета - они известны ядру, оно их принимает, и не передаёт RAW...

- почему я и засомневался, что есть такая известная библиотека libcap - интерфейс к ... чуть не сказал BPF - это ""обобщённый" интерфейс, который использует "то что есть": BPF, пакетный  сокет Linux, что-то ещё из TLI SVR4....

- BPF - считается много эффективнее, чем пакетный сокет Linux, и тем-более всякая самопальная фича, типа "сниферов":
1. BPF много лет вылизан, стандартный интерфейс, всё время совершенствуется;
2. выполняется в режиме ядра с двойной (обменной) буферизацией и намного реже требует переключения в контекст пользовательского процесса и копирования буферов;
3. в отличие от пакетного сокета - выполняет фильтрацию в режиме ядра, и сыпет на пользовательский уровень только то, что запросили, а не "всё", а это на порядки меньше переключений контекстов!