[C] Raw socket programming. Zie geen packets in wireshark?

[chronozphere]

Hey iedereen,

Ben beetje begonnen met raw socket programming in C. Heb nu mijn eerste programmaatje af, maar ik zie geen verkeer in wireshark. Ik ben een beginner op het gebied van C en netwerken.

Toen het niet lukte heb ik het volgende programaatje gecompiled en geprobeerd (die eerste op de pagina):

http://www.tenouk.com/Module43a.html

Na het toevoegen van de string.h en stdlib.h includes compilede het allemaal netjes. Vervolgens startte ik het programma met het volgende commando:

sudo ./traceroute 192.168.1.39 1533 192.168.1.254 3527

Waarbij het eerste IP mijn lokale IP is, en de tweede die van mijn router. De ports zijn random. De output is als volgt:

socket() - Using SOCK_RAW socket and UDP protocol is OK.
setsockopt() is OK.
Trying...
Using raw socket and UDP protocol
Using Source IP: 192.168.1.39 port: 1533, Target IP: 192.168.1.254 port: 3527.
Count #1 - sendto() is OK.
Count #2 - sendto() is OK.
Count #3 - sendto() is OK.
Count #4 - sendto() is OK.
Count #5 - sendto() is OK.
Count #6 - sendto() is OK.
etc....

Het lijkt allemaal goed te gaan, maar toch zie ik niets in wireshark. Ik zie natuurlijk wel al het verkeer dat gegenereerd word door mijn browser en IM client. Wireshark draait onder root rechten om toegang te krijgen tot de network interfaces. Ik draai zelf Ubuntu 9.10. Kernel: 2.6.32-27. Er zit nog een switch tussen mij en de router, maar dat zou AFAIK niet uit moeten make.

Heeft iemand enig idee wat ik fout doe? Wil heel graag kunnen zien wat voor verkeer ik genereer met mijn code.

Thanks a bunch!

[Ventieldopje]

Toevallig WireShark ingesteld dat hij alleen TCP verkeer onderschept?

[chronozphere]

Nee, ik zie ook een hoop DNS verkeer en af en toe wat ARP packets. Daarnaast heb ik niets veranderd, behalve dat ik hem nu als root draai.

[Ventieldopje]

http://www.linuxquestions...-sending-too-fast-752437/

Iemand meld daar dat de pc te druk was en dat daardoor wireshark pakketjes mistte. Wat voor filter gebruik je in Wireshark?

[chronozphere]

Thanks voor de hint, maar ik denk niet dat het probleem daar zit. Hij ontving namelijk wel de eerste paketten, terwijl ik helemaal niets terug zie.

Ik draai ubuntu zonder zware software. Heb even resources gechecked en mijn CPU word gemiddeld 30% belast (door mijn OS + browser). Geheugengebruik is vrij minimaal. Bij de netwerk stats zie ik af en toe wat bursts voorbij komen.

Heb mijn programma nu aangepast zodat hij 50 packets stuurt zonder te wachten, maar als ik hem draai zie ik geen veranderingen in mijn netwerk gebruik. Misschien komt dat pas als ik een grote payload aan elk pakket hang?

Ik blijf het erg vreemd vinden allemaal. :-/

Edit: de network tools van ubuntu laten wel packets zien in wireshark. Heb nog een ander stukje code geprobeerd, maar ik kreeg weer niets te zien.

[ Voor 10% gewijzigd door chronozphere op 26-01-2011 18:18 ]

[Soultaker]

Zie je ook niet op de loopback interface (als je daarmee test) of op de universele pseudo-device packets langskomen?

Verder is de code die je refereert aan alle kanten stuk. Zo is de ipheader struct niet packed, bijvoorbeeld, en is het eerst veld 5 in plaats van 4 bits. Ik kan me niet voorstellen dat de code als zodanig ooit voor iemand gewerkt heeft, want die struct is vrijwel zeker te groot.

Waarom het je een goed idee lijkt om code van het internet te halen, die begint met "Must be run by root lol!" en verder voor de helft niet en voor de andere helft inconsistente indentation heeft, is me een raadsel. Die eerste regel zou voor mij al genoeg aanleiding zijn om de pagina te sluiten en er nooit meer terug te komen.

[ Voor 3% gewijzigd door Soultaker op 26-01-2011 19:01 ]

[StM]

Als ik het me goed herinner zie je de packets die je zelf verstuurt onder linux via een raw socket idd niet voorbij komen. Mogelijk heeft dat iets te maken met de manier waarop ze verzonden worden in de kernel? Ik denk dat de hook die de packets afvangt op een hoger niveau zit.

Dat je root moet zijn is trouwens niet zo bijzonder, als gewone user mag je geen raw socket openen.

[ Voor 31% gewijzigd door StM op 26-01-2011 19:41 ]

[chronozphere]

Hah thanks. Zie nu inderdaad dat die IP header totaal brak was (ip-version van 5 bits en fragmentation flags van 8 bits.. bah).

Heb het nu dus gefixt en zie mijn packets verschijnen op de loopback interface en niet via mijn NIC. Enig idee waarom dat zo is? Worden ze wel verstuurd nu?

Thanks.

[Soultaker]

chronozphere schreef op woensdag 26 januari 2011 @ 19:58:
.. fragmentation flags van 8 bits..

Goed gevonden. Heb je ook het daaropvolgende veld ook ingekort? Dat zou 12 bits moeten zijn, anders is je struct nog steeds te groot.

Heb het nu dus gefixt en zie mijn packets verschijnen op de loopback interface en niet via mijn NIC. Enig idee waarom dat zo is? Worden ze wel verstuurd nu?

Als wat StM zegt klopt, dan zie je ze niet maar worden ze wel verstuurd. In dat geval zou je eens op een andere machine binnen het netwerk moeten testen of je ze ziet verschijnen als je ze daar naartoe stuurt.

[farlane]

Misschien denkt ie dat je naar localhost wilt ofzo?

[StM]

Nu ga ik er wel over twijfelen of het zo is... Het kan ook een ander OS zijn geweest. Het is voor mij al een heel poosje geleden dat ik wat met raw sockets gedaan heb.

En idd gewoon even proberen of ze op een remote machine wel aankomen.

farlane schreef op woensdag 26 januari 2011 @ 20:07:
Misschien denkt ie dat je naar localhost wilt ofzo?

Als het goed is niet.

C:

din.sin_addr.s_addr = inet_addr(argv[3]);

Hiermee geef je aan de sendto de destination aan. Daarmee selecteert hij de juiste interface.

[ Voor 42% gewijzigd door StM op 26-01-2011 20:12 ]

[chronozphere]

Goed gevonden. Heb je ook het daaropvolgende veld ook ingekort? Dat zou 12 bits moeten zijn, anders is je struct nog steeds te groot.

Heb gewoon dat frag. flags veld eruit geknalt. Het veld daarna is 16bits lang en bevat dan dus de flags en de offset samen. Verder niet belangrijk want ik laat die op nul staan.

Misschien denkt ie dat je naar localhost wilt ofzo?

Kan ik me niet voorstellen. Heb zoiets nergens aangegeven. Ookal spoof ik het source address, de packets blijft alleen zichtbaar via de loopback interface.

Hiermee geef je aan de sendto de destination aan. Daarmee selecteert hij de juiste interface.

Ik heb het IP van mijn router gebruikt. Not sure if that should work. Die staat namelijk als gateway aangegeven in mijn routing table en niet als destination.

Lijkt me vrij vervelend als ik die loopback interface moet blijven capturen. Daarop zie ik natuurlijk niet het spul dat terug komt. Hopelijk biedt de universele interface uitkomst.

[Soultaker]

StM schreef op woensdag 26 januari 2011 @ 20:09:
Hiermee geef je aan de sendto de destination aan. Daarmee selecteert hij de juiste interface.

Is dat wel zo? Is het niet zo dat het destination adres dat wordt meegegeven aan de sendto() call bepaalt via welke interface het pakket verzonden wordt? (Dat zou hier ook goed moeten gaan, natuurlijk, als het doeladres zinnig is.)

[ Voor 49% gewijzigd door Soultaker op 26-01-2011 21:05 ]

[StM]

Sendto parsed het pakket niet opnieuw maar gaat als het goed is uit van de meegegeven sockaddr struct. Ik zie alleen dat hij uitgaat van het source adres (sin) en dat het destination adres (din) nergens gebruikt wordt. Waarom dat dan toch in de code staat? Geen idee...

TS: Deze tutorial behandeld naar mijn mening raw sockets veel beter: http://mixter.void.ru/rawip.html

Ik zie alleen dat de includes wegvallen maar die kan je gewoon zien in de html source.

[ Voor 10% gewijzigd door StM op 26-01-2011 21:36 ]

[farlane]

Anders zou je je lokale socket kunnen binden met setsockopt( ..., SO_BINDTODEVICE, ... ) om te kijken of dat wat uitmaakt.

[chronozphere]

Heb mijn socket proberen te binden aan "eth0", maar het maakte geen verschil.

code:

  char *interface = "eth0";
  setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, interface, 4);

Ik denk toch dat er nog een probleem is. Het lijkt erop ofals mijn packets niet verzonden worden. Kan ze immers alleen zien in de loopback interface.

Ik ben bezig met een traceroute implementatie. De packets lijken verzonden te worden, maar ik krijg niets terug. ik heb de uitgaande packets vergeleken met die van de linux traceroute tool en op IP en UDP niveau zijn ze vrijwel identiek. Op datalink niveau lijkt het bij mij fout te gaan. Ter verduidelijking heb ik hier even een pakketje gedumpt:

code:

No.     Time        Source                Destination           Protocol Info
      9 2.703823    192.168.1.39          74.125.77.99          UDP      Source port: 25645  Destination port: 33444

Frame 9 (76 bytes on wire, 76 bytes captured)
    Arrival Time: Jan 27, 2011 01:31:38.469527000
    [Time delta from previous captured frame: 0.000044000 seconds]
    [Time delta from previous displayed frame: 0.000044000 seconds]
    [Time since reference or first frame: 2.703823000 seconds]
    Frame Number: 9
    Frame Length: 76 bytes
    Capture Length: 76 bytes
    [Frame is marked: False]
    [Protocols in frame: sll:ip:udp:data]
    [Coloring Rule Name: TTL low or unexpected]
    [Coloring Rule String: ( ! ip.dst == 224.0.0.0/4 && ip.ttl < 5) || (ip.dst == 224.0.0.0/24 && ip.ttl != 1)]
Linux cooked capture
    Packet type: Unicast to us (0)
    Link-layer address type: 772
    Link-layer address length: 6
    Source: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Protocol: IP (0x0800)
Internet Protocol, Src: 192.168.1.39 (192.168.1.39), Dst: 74.125.77.99 (74.125.77.99)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 60
    Identification: 0xfcec (64748)
    Flags: 0x00
        0.. = Reserved bit: Not Set
        .0. = Don't fragment: Not Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 3
        [Expert Info (Note/Sequence): "Time To Live" only 3]
            [Message: "Time To Live" only 3]
            [Severity level: Note]
            [Group: Sequence]
    Protocol: UDP (0x11)
    Header checksum: 0x6115 [correct]
        [Good: True]
        [Bad : False]
    Source: 192.168.1.39 (192.168.1.39)
    Destination: 74.125.77.99 (74.125.77.99)
User Datagram Protocol, Src Port: 25645 (25645), Dst Port: 33444 (33444)
    Source port: 25645 (25645)
    Destination port: 33444 (33444)
    Length: 40
    Checksum: 0xb0aa [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Data (32 bytes)

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
    Data: 000000000000000000000000000000000000000000000000...
    [Length: 32]

Ik heb echt al een paar uurtjes in documentatie gegraven op zoek naar een verklaring hiervoor, maar ik staar nog volledig in het duister.

Is er ergens een "raw sockets hero" die me hiermee kan helpen?

Heel erg bedankt.

[MLM]

Ik ben geen raw-sockets hero, maar wat me opvalt is dat je met een raw socket udp datagrams gaat verzenden.
Is het niet heel veel simpeler om gewoon een udp socket aan te maken?

[chronozphere]

Als het normale udp datagrams waren was dat inderdaad mogelijk. Maar nu wil ik velden in de IP en UDP header zelf manipuleren. Dat gaat niet als je met normale SOCK_DGRAM sockets werkt.

[farlane]

Zijn er statistics in /proc/net oid die je kunnen helpen bij het analyseren?

[chronozphere]

Na lange tijd debuggen eindelijk de oplossing gevonden:

De packets kwamen niet op de lijn terecht omdat ik per ongeluk de source address structure meegaf aan sendto() i.p.v de destenation address structure. (Overigens een bug in de code in de link die k in mijn eerste post gaf )

Vervolgens had ik nog het probleem dat er geen ICMP packets terug kwamen, maar dat werd waarschijnlijk veroorzaakt doordat ik de UDP checksum verkeerd berekende (op 0 zetten helpt... het OS doet het dan).

Allemaal heel logisch natuurlijk. Het lastige van C is bugs eerrrrug lastig te vinden zijn.

Iedereen bedankt!

[Hillie]

chronozphere schreef op zaterdag 29 januari 2011 @ 19:46:
Het lastige van C is bugs eerrrrug lastig te vinden zijn.

Da's met iedere taal als je geen debugger gebruikt en je debugstrategie onhandig is.

[chronozphere]

True, ik moet me nog ff verdiepen in GDB.

[farlane]

chronozphere schreef op zaterdag 29 januari 2011 @ 19:46:
De packets kwamen niet op de lijn terecht omdat ik per ongeluk de source address structure meegaf aan sendto() i.p.v de destenation address structure.

farlane schreef op woensdag 26 januari 2011 @ 20:07:
Misschien denkt ie dat je naar localhost wilt ofzo?