[C++] Verbinden met een MAC-adres

[B-Man]

Ik heb al wat gegoogled, en vond weinig nuttigs, vandaar dat ik het hier aan de C++'ers onder de GoTTers vraag:

Is het in C/C++ mogelijk (of een andere taal), om een netwerkverbinding te openen op een LAN (pc A <--> switch/hub <---> pc , met een pc zonder IP-adres, waar het MAC adres van bekend is?

pc A bijvoorbeeld 192.168.0.1
via hub of switch verbonden met pc B, waarvan alleen het MAC-adres bekend is. Pc B heeft nog geen IP-adres.

Kan dit ?

[.oisyn]

ja, maar dan zul je ethernet frames door moeten gaan sturen, ik neem aan dat je niet IPX bedoelt?
Of dit ook ondersteund wordt hangt overigens volledig van je platform af, en heeft derhalve niets met C(++) te maken

[B-Man]

Bedankt voor je reactie (op dit uur van de dag).

pc B = linux
pc A = windows of linux

Ik probeerde net al onder windows met arp-s IP MAC te koppelen, maar dan kan ik vanuit windows het ip wel pingen, maar krijg geen reactie terug. Ik neem aan dat ik een laag te hoog zit (TCP/IP, en pc B heeft immers nog geen TCP/IP actief).

Wat ik wil is een tooltje draaien, laten we zeggen onder windows, waarmee ik een pc die in een netwerk hangt, waarvan ik het MAC ken, op afstand kort kan "beheren". Dit in de simpele vorm waarin ik pc B een IP toewijs...
Het is mogelijk, zo heb ik hier al eens met Camera's met ingebouwde webserver gewerkt, die je ook op deze manier kon configureren:

netwerkkabel erin, progje op je windows pc starten, MAC invoeren (progje kon trouwens ook zoeken/ broadcast ofzo?), en je kon het ding beheren. Hieruit kon ik afleiden dat er een netwerkverbinding met het ding was, zonder dat de camera een IP had.

[Nibble]

Ik denk dat je je search dan moet verkleinen tot het schrijven van een netwerk driver

Je zit dan namelijk op de 2e datalink-layer sublaag (mac), terwijl (in mijn ervaring) software netjes op de application-layer blijft. Alles wat daar onder valt zijn protocollen.
En idd, pingen gaat niet, want dan ben je met icmp bezig. (wat deel uitmaakt van de tcp/ip suite).

Maar als je alleen een ip aan je mac wilt toewijzen kun je dan niet gewoon dpcp of bootp gebruiken of iets dergelijks

[johnwoo]

B-Man schreef op 27 november 2002 @ 02:33:
[...]

Wat ik wil is een tooltje draaien, laten we zeggen onder windows, waarmee ik een pc die in een netwerk hangt, waarvan ik het MAC ken, op afstand kort kan "beheren". Dit in de simpele vorm waarin ik pc B een IP toewijs...

[...]

Het klinkt alsof je DHCP opnieuw aan het uitvinden bent

[ Voor 2% gewijzigd door johnwoo op 27-11-2002 09:50 . Reden: ik moet toch eens leren de hele draad te lezen voordat ik op een post reageer, Nibble was way ahead of me :P ]

[curry684]

Windows krijg je vanuit de SDK-API's iig niet onder de app-layer geforceerd, dus je bent veroordeeld tot TCP of UDP daar. Voor IP/Ethernet frames sturen zul je idd de networking-DDK's moeten doorspitten ben ik bang (ik zou niet weten hoe je het anders zou moeten doen)

[B-Man]

Nibble/Johnwoo: aangezien ik de machines in omgevingen wegzet die ik niet ken, kan ik er niet vanuitgaan dat er DHCP aanwezig is.

Het moet kunnen onder windows, heb de camera waar ik over sprak even opgezocht. Het is er een van Axis, zie de volgende pagina voor een tooltje om een netwerk af te zoeken naar Axis camera's, en om een Camera zonder IP een IP te geven: http://www.axis.com/techsup/software/ipinstall/ipinstall.htm

[B-Man]

Tevens staat hier een stukje tekst waaruit is af te leiden dat je met een statische (tijdelijke) ARP-verwijzing ook verbinding moet kunnen leggen met een pc/apparaat over een netwerk...

[B-Man]

Heb vandaag behoorlijk wat sites gezien (en usenet posts) over het gebruik van raw sockets. Voorzover ik het begrepen heb, kan ik hiermee ook een machine bereiken, die nog geen IP-adres heeft. Toch is het me nog niet helemaal duidelijk hoe dit er vertaald naar een programma uitziet:
- Er moet aan de kant van pc B een programma draaien dat mijn packets van de lijn vist neem ik aan.... Hoe pak ik dit aan? Het werkt anders als met een normale socket las ik (dus geen accept() )
- Hoe krijg ik mijn data (bijvoorbeeld een string "SET IP xxx.xxx.xxx.xxx" dan van A naar B... Gewoon een string in een packet zetten, verzenden, en aan de andere kant het packet ontleden en de string eruit vissen ?

[Verwijderd]

Indien je een apparaat een ip adres wilt geven, moet dit apparaat hier wel iets voor ingebouwd hebben. Bijvoorbeeld een dhcp client, die een broadcast stuurt (op ethernet niveau) over de lijn en wacht op een antwoord van de eerste beste server die respons geeft.
Er zijn natuurlijk duizenden manieren verzinnen om een apparaat een IP te geven, maar je moet wel weten wat de 'client' (de camera/printer/pc) verwacht op dat gebied.

[Nibble]

B-Man schreef op 27 November 2002 @ 20:15:
Heb vandaag behoorlijk wat sites gezien (en usenet posts) over het gebruik van raw sockets. Voorzover ik het begrepen heb, kan ik hiermee ook een machine bereiken, die nog geen IP-adres heeft. Toch is het me nog niet helemaal duidelijk hoe dit er vertaald naar een programma uitziet:
- Er moet aan de kant van pc B een programma draaien dat mijn packets van de lijn vist neem ik aan.... Hoe pak ik dit aan? Het werkt anders als met een normale socket las ik (dus geen accept() )
- Hoe krijg ik mijn data (bijvoorbeeld een string "SET IP xxx.xxx.xxx.xxx" dan van A naar B... Gewoon een string in een packet zetten, verzenden, en aan de andere kant het packet ontleden en de string eruit vissen ?

kun je die axis code niet disassembleren ?
(weet dat het niet mag, maar dat is een ander verhaal).
Of misschien ergens een open-source aansturing vandaan halen ?

[curry684]

Ik denk dat deze link wel behulpzaam voor je kan zijn. Zoals je daar ziet is er een duidelijke scheiding tussen network layer en transport layer, en een standaard applicatie in een 'beschermde' omgeving staat je zoals gezegd niet toe onder de transport layer te duiken. Daar IP enkel een protocol bovenop standaard Ethernet is is het dus idd mogelijk om data naar een machine te sturen dat nog geen IP-adres heeft: je hebt alleen het MAC-adres nodig theoretisch. Vervolgens moet je wel flink flooden want je bent doordat je geen hogere protocols implementeert iedere vorm van error-checking, sequence checking, en packetloss-retrieval kwijt.

Enjoy

[B-Man]

Unteraarsch: Ik wil er dan ook wat voor bouwen, in de vorm van een simpele C++ server die wacht op een een autorisatie, en vervolgens een "SET IP xx.xx.xx.xx" commando.

Nibble: Bedankt voor het meedenken, maar de Axis software "onderzoeken" lijkt me niet erg gemakkelijk. a) ben hier niet in thuis, b) zal vermoedelijk erg specifiek zijn gebouwd en c) ik wil flexibel zijn met mijn eigen "tool", die overigens best open-source kan worden. Ik heb nog geen open source projecten gezien die hier een (soort van) oplossing voor bieden.

curry684: bedankt voor je link, daar kan ik inderdaad wat mee. Als ik je goed begrijp is IP laag genoeg in het OSI model om verbinding te kunnen leggen met een andere pc zonder IP, met alleen een MAC adres? Moet ik overigens echt denken aan een "verbinding", of aan een UDP broadcast-achtige interactie tussen pc A en pc B?
Wat ik tot nu toe over deze vorm van communicatie gelezen heb gaat over RAW sockets.
Ik heb overigens de libnet library van internet gehaald (http://www.packetfactory.net/libnet), waarmee ik zelf packets kan creeeren.

Ik ben erg blij () dat jullie er wat vanaf weten, aangezien ik er op het internet (na een hoop gegoogle, nu al een paar dagen) geen duidelijke info over kan vinden (het direct met een MAC adres verbinden).

Ik heb in ieder geval weer even wat te lezen. Kunnen jullie me misschien globaal vertellen hoe mijn app er uit moet komen te zien om bovenstaande te realiseren? Ik vraag niet om code of pseudocode, maar om een uitleg in woorden. Ben ik in de goede richting aan het zoeken met RAW sockets, of zit ik dan een laag te laag in het OSI model ?

Alvast bedankt!

[curry684]

B-Man schreef op 28 november 2002 @ 00:10:
curry684: bedankt voor je link, daar kan ik inderdaad wat mee. Als ik je goed begrijp is IP laag genoeg in het OSI model om verbinding te kunnen leggen met een andere pc zonder IP, met alleen een MAC adres?

Mmmm niet helemaal, IP is daarvoor namelijk niet laag genoeg. Je bedoelt Ethernet daar, die is dat wel

Moet ik overigens echt denken aan een "verbinding", of aan een UDP broadcast-achtige interactie tussen pc A en pc B?

Het hangt er vanaf wat je als 'verbinding' definieert. In principe doet Ethernet niets anders dan broadcasts waarvan ze hoopt dat de correcte adapter het oppikt, ergo je wil broadcast-achtige interactie doen. Echter, in een Ethernet-frame zit zowel het MAC van ontvanger als afzender, dus je kunt op en neer praten tussen de 2 adapters: en dat is in zekere zin een 'verbinding'

Wat ik tot nu toe over deze vorm van communicatie gelezen heb gaat over RAW sockets.
Ik heb overigens de libnet library van internet gehaald (http://www.packetfactory.net/libnet), waarmee ik zelf packets kan creeeren.

Klinkt errug interessant, ga ik ook eens naar kijken als ik tijd heb.

Ik ben erg blij () dat jullie er wat vanaf weten, aangezien ik er op het internet (na een hoop gegoogle, nu al een paar dagen) geen duidelijke info over kan vinden (het direct met een MAC adres verbinden).

Ik vind het ook errug interessante materie, maar kwalificeer mezelf niet als expert in het gebied. Alles wat ik gezegd heb moet je dan ook vooral niet blind voor waarheid aannemen, en eventuele correcties zou ik graag in dit topic terugzien.

Ik heb in ieder geval weer even wat te lezen. Kunnen jullie me misschien globaal vertellen hoe mijn app er uit moet komen te zien om bovenstaande te realiseren? Ik vraag niet om code of pseudocode, maar om een uitleg in woorden. Ben ik in de goede richting aan het zoeken met RAW sockets, of zit ik dan een laag te laag in het OSI model ?

Ik weet niet precies wat je met RAW sockets bedoelt (WinSock noch Berkeley sockets ondersteunen het officieel, alhoewel het bij allebei losjes in de docs vermeld staat als optie) maar ik gok dat dat een rauwe IP connectie betreft, oftewel tussen 2 IP-adressen maar zonder TCP of UDP headers. En dat zou een laag te hoog zijn (network layer ipv ethernet layer).

[ Voor 2% gewijzigd door curry684 op 28-11-2002 00:57 . Reden: Tag fixed ]

[B-Man]

curry: ik zal je input niet blind voor waar aannemen, maar ben eerlijk gezegd allang blij dat iemand me in ieder geval wat kan vertellen over deze materie.

FYI: een RAW socket is inderdaad een rauwe connectie (IP weet ik niet). Voorzover ik kon zien hoef ik niet per se een IP adres op te geven.

De libnet bibliotheek gaat me in ieder geval wat tijd schelen m.b.t. de ethernet laag.

Wat me nu nog resteert aan "onderzoek" is de vraag hoe ik kan luisteren op een interface naar mijn eigen ethernet-packets... Ik heb nu een tool om ze te verzenden, nu moet ik ze nog kunnen ontvangen. Op de site van libnet hebben ze het hiervoor over pcap, te vinden op tcpdump.org, alleen kan ik tcpdump.org al twee dagen niet bereiken.

[rollebol]

Niet perse 100% relevant en klinkt als de 'gebruik dan DHCP'-posts aan het begin van het topic, maar misschien kan je iets hebben aan Rendezvous, het stateless autoconfiguratiegedoe dat Apple en diverse hardware-fabrikanten zijn begonnen te gebruiken.

Ik geloof http://developer.apple.com/macosx/rendezvous/ maar ik kan er naastzitten.

B-Man schreef op 28 november 2002 @ 00:53:
Wat me nu nog resteert aan "onderzoek" is de vraag hoe ik kan luisteren op een interface naar mijn eigen ethernet-packets... Ik heb nu een tool om ze te verzenden, nu moet ik ze nog kunnen ontvangen. Op de site van libnet hebben ze het hiervoor over pcap, te vinden op tcpdump.org, alleen kan ik tcpdump.org al twee dagen niet bereiken.

Ethereal. Perfect dingetje. Is een Gtk-programma, maar er is ook een ncurses-variant genaamd tethereal.

[ Voor 54% gewijzigd door rollebol op 28-11-2002 01:03 . Reden: hehe geschiedvervalsing ]

[B-Man]

rollebol: hmmm, daar kan ik mogelijk wel wat mee ja, bedankt. Het lijkt niet over MAC-adres verbindingen te gaan, maar over het automatisch instellen van een IP, en vervolgens kijken of er geen collisions optreden. Niet helemaal wat ik zoek, maar de sourcecode kan mogelijk wat hulp bieden.

Zoals ik overigens al meldde, kom ik niet op tcpdump.org, jullie wel ?

[B-Man]

Zoals ik al aangaf ben ik er nog niet uit hoe ik kan luisteren op een interface naar packets. De interface is namelijk niet "up". Kan ik dan toch zien wat er binnen komt ?

[Reptile209]

Dan denk ik dat je haast een eigen driver voor de interface moet maken die 'm als "up" naar het OS doorgeeft, en ondertussen luistert naar je eigen broadcasts. Is het niet mogelijk dat je, omdat je zegt dat je niet weet of er DHCP zal zijn, een eigen DHCP-server (als componetje??) meeneemt in je programma? Die moet dan wel zo getweaked zijn dat hij alleen aan jouw interface een IP geeft, en de rest met rust laat. Dat om te voorkomen dat je een compleet netwerk zit te beheren vanuit een eigen brouwsel

[djexplo]

Ik dacht zelf gelijk aan "wake on lan" packetjes, die worden ook naar een mac adress verstuurt in plaats van een ip-adress aangezien de computer nog niet aanstaat.

Hier bestaat vrij veel bron code voor, als je dat bekijkt weet je tenminste hoe je een packetje aan een mac adres kan leveren.
http://planetsourcecode.com/ (Zoek op wake on lan c++ voor source code )

Source code van Sniffers , dit kan je gebruiken om ethernet packetjes te ontvangen

http://www.e-secure-db.us/dscgi/ds.py/View/Collection-1520
http://www.ethereal.com/

Als je deze twee soorten source code bij elkaar gooit, heb je een systeem waar mee je via ethernet packetjes kan ontvangen en sturen

[ Voor 31% gewijzigd door djexplo op 28-11-2002 11:47 . Reden: +urls ]

[B-Man]

Reptile: Daar zat ik zelf ook al aan te denken ja: DHCP iets aanpassen (extra header of iets in de payload van de packets zetten), zodat deze alleen door mijn prog gebruikt wordt...

[B-Man]

Ik zit nu de sources van de ISC DHCP client/server te bekijken. De client kan namelijk ook als een netwerkinterface down is hier "aan gaan hangen" en DHCPDISCOVER verzenden.

De client kijkt naar /proc/net/dev onder linux, hierin schrijft de linux-kernel weg welke interfaces er zijn, ook als ze down zijn.
Wat me echter niet duidelijk is, is hoe ze vervolgens luisteren naar packets. Ze roepen interface_allocate aan, alleen kan ik deze functie nergens in de sources terugvinden. Is dit een linux functie ?

De betreffende code ziet er als volgt uit:

code:

tmp = (struct interface_info *)0;
status = interface_allocate (&tmp, MDL);
if (status != ISC_R_SUCCESS)
    log_fatal ("Can't allocate interface %s: %s",
           name, isc_result_totext (status));
tmp -> flags = ir;
strncpy (tmp -> name, name, IFNAMSIZ);
interface_reference (&tmp -> next, interfaces, MDL);
interface_dereference (&interfaces, MDL);
interface_reference (&interfaces, tmp, MDL);
interface_dereference (&tmp, MDL);
tmp = interfaces;

if (dhcp_interface_discovery_hook)
    (*dhcp_interface_discovery_hook) (tmp);

[B-Man]

Ben wederom iets verder: de DHCP client gebruikt een command-line script voor configuratie van de netwerkinterfaces. Het lijkt erop dat ze simpelweg "ifconfig $interface 0 up" uitvoeren, en vervolgens packets gaan verzenden.

[Reptile209]

Ik weet niet of je hier nog wat aan hebt, maar het is een beschrijving van de pakketjes die tijdens de DHCP discover fase worden uitgewisseld tussen client en (DHCP) server. Het vertelt in ieder geval naar wat voor soort pakketjes er geluisterd wordt en wat de inhoud zou moeten zijn. Met dank aan ome Bill

[B-Man]

Reptile: merci, gaat wel van pas komen. Ik had zelf al een visuele representatie gevonden.

[B-Man]

Heb net wat interessants ontdekt: Je kan in linux een netwerkinterface "up" brengen, zonder IP. Dit doe je met "ifconfig <interface> 0 up". Vervolgens kan je er met C gewoon een listener aan hangen, die ethernet packets opvangt... Erg handig.

[Verwijderd]

Ondersteunt je linux bak op dat moment uberhaupt netwerkprotocollen? Via Netbios kan je namelijk ook communiceren. Ik weet niet of een named pipe naar een linux machine werkt (nog nooit geprobeerd) maar voor named pipes heb je iig geen IP adres nodig. Voor Netbios ook niet...

[B-Man]

Akhorahil: daar heb ik nog niet naar gekeken, bedankt voor je tips.