Ethernet, rozgłoszenia

Można jakoś wysłać i odebrać ramki rozgłoszeniowe najlepiej w c/c++?
TCP/UDP łatwo znaleźć, ale ja potrzebowałbym coś całkiem niskopoziomowego.
Muszę nadać rozgłoszenie w sieci z jakąś ramką (najlepiej niczym niezdefiniowaną z polem EtherType jakimś niestandardowym) i odebrać ją na innym komputerze w tej sieci. Po co tak? Chodzi o pominięcie wszystkich możliwych skomplikowanych spraw takich jak pozyskiwanie IP, sprawdzanie czy drugi komputer jest, jeśli jest to jaki ma mac itd.

Idea jest taka, że po jednej stronie jest komputer, po drugiej stronie jest małe urządzenie, z małymi zasobami. I te zasoby nie dość że małe to mają możliwość odczytania ramek, ale chodzi aby niczego nie kłopotać poprzez dodatkowe adresy. Rozgłoszenie po sieci lokalnej byłoby wręcz idealne.

Szanowny Panie PetRRRrrru, to jest jedyny kanał na którym nie ma Pana 24 godziny na dobę i bardzo bym chciał aby tak pozostało.
A tak na poważnie, na całe szczęście jest to prawie nie możliwe, ponieważ jak tylko zniknie "porządek na drucie" to już nikt nikogo nie zrozumie.

Dlaczego?
http://standards-oui.ieee.org/ethertype/eth.txt
lista mówi, że nie brakuje protokołów ethertype bliżej niezdefiniowanych ale istniejących. Nikt nie powiedział jaki wykorzystam, bo tego nie wiem, może skorzystam z jakiegoś gotowego. Po prostu interesuje mnie niskopoziomowa funkcja pozwalająca na wysłanie ramki ethernet, gdzie podawałoby się np. takie parametry:
adres mac odbiorcy, adres mac nadawcy, ethertype, dane

załóżmy na przykład, że chciałbym z poziomy C/C++ wysłać np. ramkę AoE.

Nadmienię, że to rozgłoszenie jest o tyle tutaj ważne, że ma posłużyć to tak sporadycznej komunikacji lokalnej (statystycznie 2-3 minuty rocznie albo i rzadziej). Stąd właśnie zainteresowanie takim protokołem, który niczego nie wymaga, bo po prostu to skomplikuje tylko sprawę i to straszliwie. Chodzi o maksimum prostoty, żeby nic nie trzeba było ustawiać i tak jak USB podłączyć tak tutaj, tylko podpiąć, zrobić swoje i spokój (nie pytajcie dlaczego nie po prostu USB, bo to zupełnie inna bajka).

Przy tak rzadkim połączeniu radzę zastosować UDP i nie bawić się niskim poziomem. Kiedyś oparłem się o połączenia niskopoziomowe - bokiem wyszło. Więc odradzam.

Tak, ale udp to porty i w ogóle. Tutaj chodzi praktycznie o łącze 1:1, coś jak tryb awaryjny/diagnostyczny z jak najmniejszymi zasobami. Można nawet postawić tutaj tezę, że przychodzi gość, wciska jakiś guziczek, wpina się z laptopem do gniazdka i może zrobić diagnostykę bez dodatkowych problemów. Ewentualnie wpina się nie bezpośrednio tylko do jakiegoś switch'a. Wiesz, chodzi o takie minimum, minimów, jak prosty COM, czy coś, gdzie z założenia w sieci będzie na pewno jeden nadawca i jeden odbiorca. Dobry byłby USB ale on odpada, bo diagnostykę w 99% przypadków wygodniej będzie przeprowadzić wpinając się gdzieś do switch'a z laptopem czy nawet łącząc się przez wi-fi niż krótkim kabelkiem stojąc z laptopem gdzieś przy szafie. Dlatego poszukuje czegoś co będzie najprostsze z możliwych, żeby jak najmniej zasobów zżerało do komunikacji i nie wymagało żadnej wstępnej (nawet automatycznej) konfiguracji.

Jaką warstwę sieciową chcesz wykorzystać do transmisji ? Ogólnie pakiety TCP i UDP są pakietami z warstwy transportowej.

Łącza danych/sieciowa coś jak np. ARP, czyli ramka będzie się składać standardowo z:
MAC odbiorca, MAC nadawca, EtherType, Dane

Możesz skorzystać z biblioteki libnet, tutorial niżej
https://repolinux.wordpress.com/2011/09/18/libnet-1-1-tutorial/

Prostszym rozwiązaniem jest użycie TCP lub UDP, ale to Twój wybór i przypuszczam, że to będzie dla ciebie ciekawe doświadczenie.

Ciekawym doświadczeniem było przeżycie napisania własnej obsługi sieci dla mikrokontrolera, żeby działał tam poczciwie malutki serwerek www. Cel był taki, aby działało normalnie DHCP (i UDP przy okazji) lub adresowanie statyczne, było wykrywanie błędów transmisji, było wykrywanie problemów z układem komunikacyjnym (np. zdarzyło się raz, że zamilkł i bez resetu nie odbierał ramek), prawidłowa obsługa ARP, własne żądania ARP, prawidłowa obsługa pinga no i oczywiście obsługa TCP, żeby chodziło www z możliwością odpowiedzi na kilka żądań jednocześnie (a więc otwieranie/zamykanie połączeń). W samej obsłudze www przeżyłem implementacje POST, GET, wysyłanie dużych plików, prawidłowa implementacja reakcji na zgubienie pakietu, reakcje na kończenie, resetowanie połączeń, samoistne zakończenie połączenia itd. czyli wszystko co było potrzebne, żeby to jako tako estetycznie działało niczego nie blokując ani pracy reszty urządzenia, ani kilka połączeń nie blokują mikrokontrolera. Wymagało to bardzo dużo pracy, ale działa.

Tyle tylko, że tryb testowy ma być zarówno trybem testowym jak i bootloaderem, a więc w grę wchodzi i testowanie i wymiana oprogramowania w ten sposób. Dlatego wszystkie procedury, które teraz potrzebuje muszą być albo kopią albo uproszczeniem. Zejście do poziomu komunikacji przez rozgłoszenia uprości mi sprawę, bo właściwie ważne będzie, żebym tylko odróżnił, że to rozgłoszenie, że to odpowiedni protokół i to wszystko, bez całej masy dodatkowych zabiegów.

Dlatego dzięki, zapoznam się z tematem.