Ты че дохуя умный? За тебя уже все давно придумали, умные люди. Придурок
>>18402
Малаца, бро.
L0kin3t поддерживает работу поверх голого Ethernet, пили свой протокол поверх вафли, если чо - правда, для PLCP (Physical Layer Convergence Protocol) сложнее делать быстрые кастомные протоколы, почему так мало народу сейчас их пищет(Netsukuku ещё дёргается, B.A.T.M.A.N. в OpenWRT пихнули - и всё).
Резюмируя - IP - г-но мамонта, переводите домашку под л0ки или OpenWRT с каштомной конфой.
----
1.По поводу твоего дизайна - CGA в первом пункте(ключи надобно распространять по проту типа HIP, а адресацию делать по подсети размером с длину хэша/координат точки на эллипт кривой, есть в IPv6 и будет в варианте с кривыми в л0ки).
2. При адресации по хэшам, ключи могут быть разной длины, ды.
3. .bit неплохо справляется с проблемой двойной регистрации доменных имён, но можно юзать IBE вместо DNS - позволяет, зная мастер-ключ сервера доменных имён сгенерировать boot ключ для разрешаемого доменного имени.
4. Маршрутизация бывает статической и динамической(https://ru.wikipedia.org/wiki/Статическая_маршрутизация - как в ОйПи, в каждом роутере забивается маска подсети, его адрес и адрес гейтвея - алгоритм, который разбирается с этим зовётся "prefix routing" телекомщиками, описан без названия в https://en.wikipedia.org/wiki/IP_routing#Routing_algorithm), (https://en.wikipedia.org/wiki/Dynamic_routing - проще, + используется в беспроводных сетях).
5. То, что ты описываешь - это multipath, его поддерживает только SCTP, работающий поверх сам знаешь чего, и стэк телекомовских протоколов.
// Но, как хакараунд, можно юзать ZeroNet или IETF QUIC (http/3.0, "монолитные" 4-7 уровни OSI, хотя его обычно на уровни не раскладывают - брат жив, разрабы довольны).
Малаца, бро.
L0kin3t поддерживает работу поверх голого Ethernet, пили свой протокол поверх вафли, если чо - правда, для PLCP (Physical Layer Convergence Protocol) сложнее делать быстрые кастомные протоколы, почему так мало народу сейчас их пищет(Netsukuku ещё дёргается, B.A.T.M.A.N. в OpenWRT пихнули - и всё).
Резюмируя - IP - г-но мамонта, переводите домашку под л0ки или OpenWRT с каштомной конфой.
----
1.По поводу твоего дизайна - CGA в первом пункте(ключи надобно распространять по проту типа HIP, а адресацию делать по подсети размером с длину хэша/координат точки на эллипт кривой, есть в IPv6 и будет в варианте с кривыми в л0ки).
2. При адресации по хэшам, ключи могут быть разной длины, ды.
3. .bit неплохо справляется с проблемой двойной регистрации доменных имён, но можно юзать IBE вместо DNS - позволяет, зная мастер-ключ сервера доменных имён сгенерировать boot ключ для разрешаемого доменного имени.
4. Маршрутизация бывает статической и динамической(https://ru.wikipedia.org/wiki/Статическая_маршрутизация - как в ОйПи, в каждом роутере забивается маска подсети, его адрес и адрес гейтвея - алгоритм, который разбирается с этим зовётся "prefix routing" телекомщиками, описан без названия в https://en.wikipedia.org/wiki/IP_routing#Routing_algorithm), (https://en.wikipedia.org/wiki/Dynamic_routing - проще, + используется в беспроводных сетях).
5. То, что ты описываешь - это multipath, его поддерживает только SCTP, работающий поверх сам знаешь чего, и стэк телекомовских протоколов.
// Но, как хакараунд, можно юзать ZeroNet или IETF QUIC (http/3.0, "монолитные" 4-7 уровни OSI, хотя его обычно на уровни не раскладывают - брат жив, разрабы довольны).
>>18402
Уровни OSI это как сферический конь в вакууме, да и обычно эту модель противопоставляют (а не сопоставляют) с моделью TCP/IP.
Чего ты пытаешься добиться, поясни. Ну сделал адреса подлиннее, ну используешь их для криптографии, по сути просто предлагаешь любому брать себе такой адрес какой он сам хочет. Конечно, при этом возникает проблема маршрутизации (а также мультикаста), потому что организация адресного пространства и механизмы распределения (назначения) адресов именно для маршрутизации и запилены, а ты их предлагаешь нахуй послать.
Возникающая проблема полностью аналогична той, которую решают, скажем, в i2p или tor hidden services, включая концепцию "адрес = открытый ключ". Так ты поясни теперь, какие причины заворачивать это в физический уровень, а не в транспортный, как в указанных сетях? Уровни для того и задумывались, чтоб тебе было строго похуй на то, что снизу, покуда оно предоставляет необходимый интерфейс. Почему тебе не похуй?
Уровни OSI это как сферический конь в вакууме, да и обычно эту модель противопоставляют (а не сопоставляют) с моделью TCP/IP.
Чего ты пытаешься добиться, поясни. Ну сделал адреса подлиннее, ну используешь их для криптографии, по сути просто предлагаешь любому брать себе такой адрес какой он сам хочет. Конечно, при этом возникает проблема маршрутизации (а также мультикаста), потому что организация адресного пространства и механизмы распределения (назначения) адресов именно для маршрутизации и запилены, а ты их предлагаешь нахуй послать.
Возникающая проблема полностью аналогична той, которую решают, скажем, в i2p или tor hidden services, включая концепцию "адрес = открытый ключ". Так ты поясни теперь, какие причины заворачивать это в физический уровень, а не в транспортный, как в указанных сетях? Уровни для того и задумывались, чтоб тебе было строго похуй на то, что снизу, покуда оно предоставляет необходимый интерфейс. Почему тебе не похуй?
>>18405
Мне просто не нравится IP и я хочу для своих сетей использовать другую адерсацию. Как минимум для своих сетей.
Да, мне понадобится также пускать свои протоколы и поверх IP в некоторых случаях, для очень удалённых машин.
А вот про мультикаст я не знал, что есть такая штука. Спасибо, теперь я понял, что нужно чтобы получателей могло быть много. Это сэкономит вычислительные и передающие мощности.
Даже более того, надо, чтоб была широковещательная связь, то есть есть отправитель, а получателей нет, любой может получить. Конечно провайдерам надо почти всегда блокировать данное вещание или лицензировать, а то сеть просто упадёт. Или я написал фигню и широковещательная связь это для протоколов нижнего уровня.
Мне просто не нравится IP и я хочу для своих сетей использовать другую адерсацию. Как минимум для своих сетей.
Да, мне понадобится также пускать свои протоколы и поверх IP в некоторых случаях, для очень удалённых машин.
А вот про мультикаст я не знал, что есть такая штука. Спасибо, теперь я понял, что нужно чтобы получателей могло быть много. Это сэкономит вычислительные и передающие мощности.
Даже более того, надо, чтоб была широковещательная связь, то есть есть отправитель, а получателей нет, любой может получить. Конечно провайдерам надо почти всегда блокировать данное вещание или лицензировать, а то сеть просто упадёт. Или я написал фигню и широковещательная связь это для протоколов нижнего уровня.
>Думаю, никому не нужно объяснять, почему IP уёбищен.
>Поэтому надо создать свою систему, протокол для уровня Network
>Мне просто не нравится IP и я хочу для своих сетей использовать другую адерсацию.
Это уже не криптошиза, тут диагноз посерьезнее будет.
>Поэтому надо создать свою систему, протокол для уровня Network
>Мне просто не нравится IP и я хочу для своих сетей использовать другую адерсацию.
Это уже не криптошиза, тут диагноз посерьезнее будет.
>>18411
Что плохого в том, что человек хочет повелосипедить?
Я, например, хочу создавать свои процессоры. Уже почти разработал логическую схему оного. Надо лишь реализовать исполнение парочки команд.
Только вот как я на кремниевую пластину буду всё это наносить, не представляю.
Наверное, первую модель сделаю из обычных транзисторов, но их понадобится очень много. На одни только регистры нужно больше 300, а для АЛУ это будет вообще офигеть сколько.
Что плохого в том, что человек хочет повелосипедить?
Я, например, хочу создавать свои процессоры. Уже почти разработал логическую схему оного. Надо лишь реализовать исполнение парочки команд.
Только вот как я на кремниевую пластину буду всё это наносить, не представляю.
Наверное, первую модель сделаю из обычных транзисторов, но их понадобится очень много. На одни только регистры нужно больше 300, а для АЛУ это будет вообще офигеть сколько.
А как реализовать свой протокол третьего уровня (как IP) в линукс?
>>18433
Поверх netmap(есть коляска - pnet-datalink на Расте спец. для новых протоколов, как бонус - работает на галимой фряхе), PF_RING(сам не пробовал, времени не было), DPDK(только для счастливых обладателей дорогого интеловского железа, иначе работает, как хакараунд вокруг сокетов), AF_PACKET(пакеты вроде как должны быть ОйПишные, но если тебе нужен роутер на OpenWrt с ядром 4й версии только с генерацией вспомогательных пакетов (без приёма), то сойдёт).
Вариантов с коляской два, их и рекомендую.
Поверх DPDK есть стэк - mTCP, лучше модить его - в папке mtcp/src лежит дохера файлов.
1. Править нужно два - 1й = eth_in.c - на 35й строке (файл не меняли с 15го года, можно и строку укозать) есть else... else if ... else конструкция с переменой ip_proto в главной роли.
Добавляешь (обзовём пример BetterIp, ибо креативно) else if (ip_proto == ETH_P_BETTERIP) {ProcessBeterIpPacket(mtcp, cur_ts, ifidx, pkt_data, len);}.
2. Сразу после этого изменеия твой форк стэка перестанет собираться, ибо ему понадобится некая функция.
Заинклудим в eth_in.c <include/betterip_in.h>, являющийся копией include/ip_in.h.
3. Меняешь ProcessIPv4Packet как угодно, лишь бы объявление функции осталось на месте - проверяешь чек-сумму своего протокола. Можно оставить switch-case, (он вызывает TCP/... за тебя))), но возможно тебе не понравится iph (=ip_header)).
Меняем
struct "iphdr* betteriph = (struct iphdr *)(pkt_data + sizeof(struct ethhdr));"
на "struct iphdr* iph = (struct iphdr *)(pkt_data + sizeof(struct ethhdr));".
Обзываем iph в switch... case, как betteriph.
Фух.
4.Заинклудим в tcp_out.c <include/betterip_out.h>, являющийся копией include/ip_out.h.
В функции SendTCPPacketStandalone меняем IPOutputStandalone на BetterIPOutputStandalone. Для SendTCPPacket делаешь то же самое с IPOutput.
5. Препарируем корень зла - ip_out.c
В IPOutputStandalone меняешь часть кода @72 (тот, что с iph) на генератор betteriph (заголовка твоего протокола).
---
Ща буде продолжение.
Поверх netmap(есть коляска - pnet-datalink на Расте спец. для новых протоколов, как бонус - работает на галимой фряхе), PF_RING(сам не пробовал, времени не было), DPDK(только для счастливых обладателей дорогого интеловского железа, иначе работает, как хакараунд вокруг сокетов), AF_PACKET(пакеты вроде как должны быть ОйПишные, но если тебе нужен роутер на OpenWrt с ядром 4й версии только с генерацией вспомогательных пакетов (без приёма), то сойдёт).
Вариантов с коляской два, их и рекомендую.
Поверх DPDK есть стэк - mTCP, лучше модить его - в папке mtcp/src лежит дохера файлов.
1. Править нужно два - 1й = eth_in.c - на 35й строке (файл не меняли с 15го года, можно и строку укозать) есть else... else if ... else конструкция с переменой ip_proto в главной роли.
Добавляешь (обзовём пример BetterIp, ибо креативно) else if (ip_proto == ETH_P_BETTERIP) {ProcessBeterIpPacket(mtcp, cur_ts, ifidx, pkt_data, len);}.
2. Сразу после этого изменеия твой форк стэка перестанет собираться, ибо ему понадобится некая функция.
Заинклудим в eth_in.c <include/betterip_in.h>, являющийся копией include/ip_in.h.
3. Меняешь ProcessIPv4Packet как угодно, лишь бы объявление функции осталось на месте - проверяешь чек-сумму своего протокола. Можно оставить switch-case, (он вызывает TCP/... за тебя))), но возможно тебе не понравится iph (=ip_header)).
Меняем
struct "iphdr* betteriph = (struct iphdr *)(pkt_data + sizeof(struct ethhdr));"
на "struct iphdr* iph = (struct iphdr *)(pkt_data + sizeof(struct ethhdr));".
Обзываем iph в switch... case, как betteriph.
Фух.
4.Заинклудим в tcp_out.c <include/betterip_out.h>, являющийся копией include/ip_out.h.
В функции SendTCPPacketStandalone меняем IPOutputStandalone на BetterIPOutputStandalone. Для SendTCPPacket делаешь то же самое с IPOutput.
5. Препарируем корень зла - ip_out.c
В IPOutputStandalone меняешь часть кода @72 (тот, что с iph) на генератор betteriph (заголовка твоего протокола).
---
Ща буде продолжение.
>>18434
5. (продолжение).
Затем проверяем чексам. Возможно, вставляем свою логику(шифрованные Ethernet-пакеты, интеграцию с HIP-подобными протоколами, ...).
Повторяем 5й пункт до сего момента с IPOutput.
6. Определяешь в файлах структуру заголовка своего пакета (betteriph, см. как ты написал генератор в IPOutputStandalone и IPOutput - те же имена полей и определяй) и ETH_P_BETTERIP, как числецо.
Всё, дальше исправление типографских ошибок и пердолинг с gcc.
-----
Для pnet_datalink свободы больше. Собственно, у тебя есть целых два метода - pnet_datalink::DataLinkReceiver::next() & pnet_datalink::DataLinkSender::build_and_send(...) (вообще есть send_to(...), но он годен только для мультистрима (Подобную фичу печально известный Netsukuku ниасилил до сих пор - не без причины) по нескольким интерфейсам.).
Собственно, там ты пищешь собственный finite state machine для своего протокола (self-consuming style, когда каждый метод возвращает Self - бо не позволяет перейти в некорректное состояние). Пишешь генератор пакета, как раньше, с чексамом и процессингами; делаешь функции для обычной("одиночной") и буферизованной отправки пакетов, как в Сишных функциях.
Но на Расте есть такая маза - можно пустить поверх линка QUIC (=HTTP/3). Но там сложнее, его удовлетворить mio::net::UdpSocket::from_socket"ом надобно, а внём методов дофига. Man(8) terminated.
5. (продолжение).
Затем проверяем чексам. Возможно, вставляем свою логику(шифрованные Ethernet-пакеты, интеграцию с HIP-подобными протоколами, ...).
Повторяем 5й пункт до сего момента с IPOutput.
6. Определяешь в файлах структуру заголовка своего пакета (betteriph, см. как ты написал генератор в IPOutputStandalone и IPOutput - те же имена полей и определяй) и ETH_P_BETTERIP, как числецо.
Всё, дальше исправление типографских ошибок и пердолинг с gcc.
-----
Для pnet_datalink свободы больше. Собственно, у тебя есть целых два метода - pnet_datalink::DataLinkReceiver::next() & pnet_datalink::DataLinkSender::build_and_send(...) (вообще есть send_to(...), но он годен только для мультистрима (Подобную фичу печально известный Netsukuku ниасилил до сих пор - не без причины) по нескольким интерфейсам.).
Собственно, там ты пищешь собственный finite state machine для своего протокола (self-consuming style, когда каждый метод возвращает Self - бо не позволяет перейти в некорректное состояние). Пишешь генератор пакета, как раньше, с чексамом и процессингами; делаешь функции для обычной("одиночной") и буферизованной отправки пакетов, как в Сишных функциях.
Но на Расте есть такая маза - можно пустить поверх линка QUIC (=HTTP/3). Но там сложнее, его удовлетворить mio::net::UdpSocket::from_socket"ом надобно, а внём методов дофига. Man(8) terminated.
>>18402
На одной доске спрашивают следят ли за ними через телеграм и объясняют как реализовать свой протокол третьего уровня в линукс, ну охуеть
На одной доске спрашивают следят ли за ними через телеграм и объясняют как реализовать свой протокол третьего уровня в линукс, ну охуеть
Я проинсталлировал PF_RING и могу через экземпл-программы получать и отправлять пакеты, вроде бы.
Только я не понимаю, как работает адресация на уровне datalink. Есть протоколы MAC, PPP, SLIP, но в случае с вайфаем, определяет ли NIC, что пакет именно ему? По макадресу, может быть. Мне кажется что да, ведь количество пакетов увеличивалось, когда мой интернет трафиик был задействован.
Щас освободится второй компьютер и буду эксперементировать с пересылкой пакетов, хехехе.
Кстати, если я правильно понимаю, то даталинком управлять можно даже на проприетарных смартзондах от дядюшки Ляо, там и инсмод можно установить, и ifconfig, и линукс-хедеры для 3.16-armX. Так что, в случае с моей сетью, провайдером может стать даже телефон со свалки, который имеет доступ к питанию.
Только я не понимаю, как работает адресация на уровне datalink. Есть протоколы MAC, PPP, SLIP, но в случае с вайфаем, определяет ли NIC, что пакет именно ему? По макадресу, может быть. Мне кажется что да, ведь количество пакетов увеличивалось, когда мой интернет трафиик был задействован.
Щас освободится второй компьютер и буду эксперементировать с пересылкой пакетов, хехехе.
Кстати, если я правильно понимаю, то даталинком управлять можно даже на проприетарных смартзондах от дядюшки Ляо, там и инсмод можно установить, и ifconfig, и линукс-хедеры для 3.16-armX. Так что, в случае с моей сетью, провайдером может стать даже телефон со свалки, который имеет доступ к питанию.
Я кстати, получше подумал над протоколом. Если можете предложить что-то, говорите, не стесняйтесь и не бойтесь.
Прежде всего, скажу, что у меня на первом месте стоит быстродействите и сохранение секрета данных, а анонимность на последнем месте.
Я подумал над тем, на каком уровне нужно реализовывать маршрутизатор и понял, что на уровне Network, а не на верхних уровнях, иначе может потеряться смысл UDP и вообще это будет медленно.
Протокол:
флаги — содержат данные о том, надо ли шифровать контент, надо ли шифровать отправителя, получателя и маршрут.
адрес отправителя — адрес отправителя, может быть зашифрован адресом провайдера, а может адресом последнего провайдера в маршруте, а то и вообще адресом получателя.
адреса получателей — почти аналогично.
адрес провайдера — адрес провайдера, не должен быть зашифрован.
маршрут — список адресов к нужным провайдерам.
длина зашифрованных данных — длина зашифрованных данных
зашифрованные данные — данные протокола четвёртого уровня, могут быть зашифрованы адресом получателя. Шифр должен быть таким, чтобы данные могли быть сколько угодно сжаты, но с добавлением мусорных байтов, причём в количестве, не зависящем от размера самих данных, то есть, чтобы размер данных рос в арифметической прогрессии, а не геометрической.
Возможно, стоит сделать так, чтобы в адресе стоял идентификатор шифра, на случай если найдётся способ для взлома уже существующего шифра.
Таким образом, данные могут быть зашифрованы, а могут быть нет. В случае, если несколько юзеров смотрят какой-нибудь TV или другой общедоступный ресурс, то для большинства данные можно не шифровать. А ещё если злые дяденьки сумеют использовать данное свойство как уязвимость, поставляя определённый софт для быдла, то им будет профит и мне будет профит — им профит, а мне распространение моей идеи, стандарта протокола третьего уровня.
В случае если мультивещательный трафик нужно шифровать, то придётся шифровать для каждого свои данные.
Если включить возможность шифрования адресов получателя и отправителя, то можно быть уверенным, что плохие дядьки не узнают, что ты отправляешь какие-то данные на такой-то сервер.
С другой стороны, сервер может попросить мощных мускулистых провайдеров с большими планками РАМ и мультиклеточными процессорами не присылать им запросы от зашифрованных адресов отправителей, так как это может привести к DDOS-атакам., а создать новый адрес требует некоторого времени, наверное. Хотя с другой стороны, можно просто попросить не присылать им запросы от некоторого зашифрованного адреса.
Вообще я немного так запутался, а ещё я только что вбухнул сахара и мне сложно мыслить. Почему такое не происходит, когда я ем обычные сладости?
Прежде всего, скажу, что у меня на первом месте стоит быстродействите и сохранение секрета данных, а анонимность на последнем месте.
Я подумал над тем, на каком уровне нужно реализовывать маршрутизатор и понял, что на уровне Network, а не на верхних уровнях, иначе может потеряться смысл UDP и вообще это будет медленно.
Протокол:
флаги
адрес отправителя
адреса получателей
адрес провайдера
маршрут
длина зашифрованных данных
зашифрованные данные
флаги — содержат данные о том, надо ли шифровать контент, надо ли шифровать отправителя, получателя и маршрут.
адрес отправителя — адрес отправителя, может быть зашифрован адресом провайдера, а может адресом последнего провайдера в маршруте, а то и вообще адресом получателя.
адреса получателей — почти аналогично.
адрес провайдера — адрес провайдера, не должен быть зашифрован.
маршрут — список адресов к нужным провайдерам.
длина зашифрованных данных — длина зашифрованных данных
зашифрованные данные — данные протокола четвёртого уровня, могут быть зашифрованы адресом получателя. Шифр должен быть таким, чтобы данные могли быть сколько угодно сжаты, но с добавлением мусорных байтов, причём в количестве, не зависящем от размера самих данных, то есть, чтобы размер данных рос в арифметической прогрессии, а не геометрической.
Возможно, стоит сделать так, чтобы в адресе стоял идентификатор шифра, на случай если найдётся способ для взлома уже существующего шифра.
Таким образом, данные могут быть зашифрованы, а могут быть нет. В случае, если несколько юзеров смотрят какой-нибудь TV или другой общедоступный ресурс, то для большинства данные можно не шифровать. А ещё если злые дяденьки сумеют использовать данное свойство как уязвимость, поставляя определённый софт для быдла, то им будет профит и мне будет профит — им профит, а мне распространение моей идеи, стандарта протокола третьего уровня.
В случае если мультивещательный трафик нужно шифровать, то придётся шифровать для каждого свои данные.
Если включить возможность шифрования адресов получателя и отправителя, то можно быть уверенным, что плохие дядьки не узнают, что ты отправляешь какие-то данные на такой-то сервер.
С другой стороны, сервер может попросить мощных мускулистых провайдеров с большими планками РАМ и мультиклеточными процессорами не присылать им запросы от зашифрованных адресов отправителей, так как это может привести к DDOS-атакам., а создать новый адрес требует некоторого времени, наверное. Хотя с другой стороны, можно просто попросить не присылать им запросы от некоторого зашифрованного адреса.
Вообще я немного так запутался, а ещё я только что вбухнул сахара и мне сложно мыслить. Почему такое не происходит, когда я ем обычные сладости?
>Адреса — открытые ключи,
делаю как раз подобную шнягу но как замену телеге, очередную.
Тут есть парочка проблем.
Ключи генерируются долго. 8192 РСА около трех секунд например. если делать ключи маленькими например 512 тогда будут коллизии да и ломать их дело пары часов.
В общем остановился на 4096 для клиента и 8192 для сервера. Серверный ключ публичный и посылается клиенту. А клиент шифрует им уже свой ключ и отправляет обратно.
делаю как раз подобную шнягу но как замену телеге, очередную.
Тут есть парочка проблем.
Ключи генерируются долго. 8192 РСА около трех секунд например. если делать ключи маленькими например 512 тогда будут коллизии да и ломать их дело пары часов.
В общем остановился на 4096 для клиента и 8192 для сервера. Серверный ключ публичный и посылается клиенту. А клиент шифрует им уже свой ключ и отправляет обратно.
>>18455
Вот. Коммент по поводу этого. Я бы не сам ключадресом использовал а его кеш. кеш 256 бит а ключ от рса 4096 примерно 1044 если правильно помню. в 4 раза больше. DHT сервера заменяют днс ну и так далее.
Вот. Коммент по поводу этого. Я бы не сам ключадресом использовал а его кеш. кеш 256 бит а ключ от рса 4096 примерно 1044 если правильно помню. в 4 раза больше. DHT сервера заменяют днс ну и так далее.
>>18458
Или еще аргумент.
Если использовать хеш ключа вместо самого ключа то получится прикрутить не только DHT но и бокчейн. Конечно придется синхронизироваться откудато перед коннектом но 40 гигов они теперь даже на флешку помещаются.
Или еще аргумент.
Если использовать хеш ключа вместо самого ключа то получится прикрутить не только DHT но и бокчейн. Конечно придется синхронизироваться откудато перед коннектом но 40 гигов они теперь даже на флешку помещаются.
>>18457
Алсо вот так я представляю гипотетическую авторизацию. Думаю и для целей твоего интернета подобное сгодится.
Алсо вот так я представляю гипотетическую авторизацию. Думаю и для целей твоего интернета подобное сгодится.
Я тут узнал, что, похоже, никакой ни DPDK, ни PF_RING, ни netmap или ещё что-то совершенно не нужны, вместо этого есть libpcap. Либкап позволяет открывать NIC, такой как wlanX или ethX и читать оттуда и писать туда. И я действительно смог получить датаграммы и даже текст HTML-страницы в виде кусков внутри датаграмм, когда обращался к сайту по HTTP.
Вот приблизительный си-код моей программы:
Однако есть непонятки. Я так и не смог передать данные с машины на машину, а моё желаение заниматься этим на сегодня иссякло, так что продолжу заниматься этим потом.
Я долго искал протокол датаграмм для вайфая и кажется https://en.wikipedia.org/wiki/IEEE_802.11#Layer_2_–_Datagrams это он.
Но когда я принтил данные, видел сначала мак-адрес моего интерфейса как получателя данных, а затем мак-адрес моего роутера, причём последний октет был инкрементирован на единицу. С последующими данными я не разобрался, но в любом случае полченные данные не соответствуют протоколу как в википедии.
Вот приблизительный си-код моей программы:
#include <stdio.h>
#include <stdlib.h>
#include <pcap/pcap.h>
u8* device = "wlxXXXXXX";
u8 reciever[6] = {XXXXXX};//first
u8 sender[6] = {XXXXXX};//second
int main(s32 argc,s8** argv) {
if (argc == 1) {
printf("usage: %s r/s\n",argv[0]);
}
u8 err[256] = {0};
pcap_t* d = pcap_open_live(device,65536,0,1000,err);
//printf("%p\n%s\n",d,err);
struct pcap_pkthdr* packet;
const u8* data;
if (argv[1][0] == 'r') {
for (u32 it = 0; it < 20; it++) {
s32 res = pcap_next_ex(d,&packet,&data);
printf("%i\n",packet->caplen);
for (u32 i = 0; i < packet->caplen; i++) {
printf("%0X",data[i]);
}
printf("\n");
}
}
else if (argv[1][0] == 's') {
u8 data[256] = {0xAA};
for (u32 rs = 0; rs < 6; rs++) {
data[rs] = reciever[rs];
}
for (u32 rs = 0; rs < 6; rs++) {
data[6 + rs] = sender[rs];
}
for (u32 it = 0; it < 20; it++) {
s32 num = pcap_inject(d,data,256);
printf("%i\n",num);
}
}
pcap_close(d);
}
Однако есть непонятки. Я так и не смог передать данные с машины на машину, а моё желаение заниматься этим на сегодня иссякло, так что продолжу заниматься этим потом.
Я долго искал протокол датаграмм для вайфая и кажется https://en.wikipedia.org/wiki/IEEE_802.11#Layer_2_–_Datagrams это он.
Но когда я принтил данные, видел сначала мак-адрес моего интерфейса как получателя данных, а затем мак-адрес моего роутера, причём последний октет был инкрементирован на единицу. С последующими данными я не разобрался, но в любом случае полченные данные не соответствуют протоколу как в википедии.
Блин, аноны, ничего не понимаю.Во-первых>>18468>printf("%02X",data[i]);ошибочка.Во-вторых, не имею понятия, как устроена передача вайфая с макадресами и нужно ли может ещё что-то сделать, прежде чем передавать данные? Может быть надо как-то авторизировать мак-адрес?Может лучше пока поучиться по эзернет.Тем не менее, я не понимаю как передавать данные между вайфай-интерфейсами.
>>18474
вайфай же мудрит с телеметрией и сессиоными ключами. тоесть когда радио начинает передачу там идет толи роуминг до ближайшей ап толи что то такое. короче просто писать байты и слать их не получится. там дополнительная инфа есть.
вайфай же мудрит с телеметрией и сессиоными ключами. тоесть когда радио начинает передачу там идет толи роуминг до ближайшей ап толи что то такое. короче просто писать байты и слать их не получится. там дополнительная инфа есть.
>Думаю, никому не нужно объяснять, почему IP уёбищен.
Ты себе сначала объясни почему IP уёбищен, клоун
Ты себе сначала объясни почему IP уёбищен, клоун
>>18507
Потому что я его не понимаю, там маски какие-то, некоторые адреса зарезервированы типа 192.168... и всё такое. И нельзя присвоить определённый IP-адрес машине в глобальной сети.
Однако я тут подумал, что все эти ваши вайфаи и эзернеты сложны и стоит пока попробовать сделать протокол 4-го уровня, но на самом деле 3-го уровня, просто поверх IP.
Потому что я его не понимаю, там маски какие-то, некоторые адреса зарезервированы типа 192.168... и всё такое. И нельзя присвоить определённый IP-адрес машине в глобальной сети.
Однако я тут подумал, что все эти ваши вайфаи и эзернеты сложны и стоит пока попробовать сделать протокол 4-го уровня, но на самом деле 3-го уровня, просто поверх IP.
>>18510
Только вот не надо впутывать сюда создателей IP, они не в чём не виноваты.
Только вот не надо впутывать сюда создателей IP, они не в чём не виноваты.
Поэтому надо создать свою систему, протокол для уровня Network в модели https://en.wikipedia.org/wiki/OSI_model OSI.
Я предлагаю сделать так:
Адреса — открытые ключи, шифрование данных происходит с помощью закрытых ключей.
Каждая "машина" это и клиент, и сервер. При передаче данных с одного пользователя другому, по аналогии с IP, создаётся псевдозаголовок с ключём отправителя и ключём получателя. Также, возможно, стоит сделать так, чтобы ключи были переменного размера, а то вдруг появятся какие-нибудь мощные технологии и их всех можно будет взламывать за 10 секунд? Добавим пару десятков бит и всё будет ок. Почти.
Кроме того, можно запилить протокол Application уровня, который позволяет получить доменное имя некоторого сервиса, так как это будет удобно. Однако, любой может поставить себе уже занятое доменное имя, так что надо быть осторожным и лучше прописать в аналоге hosts ключ настоящего сайта.
И тут у меня возникают парочка вопросов.
Как будет происходить маршрутизация?
Можно сделать так, чтобы некоторые машины становились провайдерами и использовать для этого протокол верхнего уровня. Или нет.
Допустим одна машина стала провайдером. Она пошла сканить все машины, которые к ней подключены, а если отсканенная машина является провайдером, то та запрашивает список клиентов, которые к ней подключены и в итоге, по цепочке, можно собрать все маршруты и когда клиент делает запрос какому-то удалённому сервису, то он посылает этот запрос провайдеру, а тот ищет данный адрес/ключ в своей системе маршрутизации, если находит, то по ещё каким-то данные определяет, какой маршрут лучше, если их несколько. И посылает данный запрос + продуманный путь маршрутизации чтобы зря не нагружать другого провайдера по сети провайдеров.
Есть ещё проблема. Будет ли такая система устойчива ко всяким ддос-атакам и подобному?
Может сюда стоит ещё блокчейн куда-то припихнуть?
Вот пример прикладного примера использования данной сети:
Дядя Василий написал свой сайт со статьями по палеоботанике и позвонил своему другу, анону Сергею, что он может их прочитать, ведь сам хотел. Продиктовал 512-битный ключ и Сергей вбил его в браузер.
Браузер вызывает функцию аналога курла для установки соединения. Wifi-передатчик связывается с ближайшим провайдером и просит его посмотреть, есть ли у него путь к такому-то адресу. Провайдер говорит "Нет", потому что он сломался. Передатчик связывается со следующим провайдером, тот отвечает "Да" и передаёт в клиентскую программу, что ошибки нет, а связь установлена с провайдером. Браузер Сергея шлёт GET-запрос по TCP, к которому прикрепляется псевдозаголовок. Однако, данные шифруются открытым ключём получателя. Wifi-передатчик связывается с провайдером и даёт ему псевдозаголовок, содержащий адрес отправителя и получателя и TCP-данные. Провайдер уже успел подготовить маршрут к адресу получателя, ищет его среди всех готовых маршрутов, срезает с него свой адрес и передаёт следующему провайдеру маршрут + данные. Этот провайдер срезает себя с маршрута и передаёт следующему. Оказалось, что следующего провайдера только что взорвали террористы. Ну ничего, раз таймаут в N секунд прошёл, значит какие-то проблемы, подумал провайдер. И перестроил маршрут через другого провайдера. Ну и в конце конечный провайдер посылает данные серверу и тот в ответ на расшифрованный своим закрытым ключём GET-запрос меняет местами адрес отправителя и получателя в псевдозаголовке и шлёт HTTP/1.1 200 OK и HTML-страницу получателю. И там уже клиент получает нужные данные.
Вообще мне очень нравится, что с сетями всё так хорошо получилось. 7 уровней абстракции. Представьте, каково было бы и разработчикам, и клиентам, да и самому интернету, если бы всё оказалось монолитным? Думаю, вряд ли такое могло случиться.