[C++/Drivers]Packets uit de driver een laag hoger!

[superboer]

Ik ben nou net weer bezig met een projectje van mijzelf en nu loop ik tegen een paar probleempjes aan !

Inleiding

Ik heb dus een standaard ne2000 driver gemodificeerd en alle hardware aanroepen eruit gehaald. Ook heb ik mijn eigen protocol driver geschreven en die samen met het TCP/IP protocol gebind aan die ne2000 driver. (tot zover geen problemen).

Hiernaast heb ik ook nog een applicatie geschreven die m.b.v mijn protocoldriver alle pakketjes die de ne2000 driver ontvangt onderschept en nou is die applicatie bedoeld om op die pakketjes te reageren (en in dit geval bedoel ik met die packetjes vooral ARP-requests) met een response. (hier kom ik een paar problemen tegen )

Problemen
Als ik vanuit de applicatie een response terugstuur naar mijn protocoldriver zal die dat doorsturen naar de ne2000 driver en daarvandaan zal het packetje omhoog moeten naar de TCP-laag. Dat probeer ik te doen via NdisMEthIndicateRecieve waardoor het pakketje dus naar de gebinde protocollen word doorgestuurd. (zoals in MSDN staat)
Mij protocol driver krijgt dat ook netjes binnen en ook commview laat netjes de ARP-response zien. Alleen krijgt het programma die de ARP-requests stuurt (ping.exe ) nix binnen ! (hij geeft steeds een time-out).

Ik denk zelf eerst dat het misschien aan de manier ligt waarop ik het pakketje verstuur naar de bovenliggende protocollen en dat ik iets vergeet m.b.t. bepaalde Ndis calls maar tot dusver heb ik nog nix gevonden.

Ik sta voor een raadsel en weet zo gauw nix meer te verzinnen dus enkele ideeen van jullie zou welkom zijn.

Meer info schiet me zo niet te binnen !

[Verwijderd]

Moet je niet NdisMFddiIndicateReceiveComplete hierna gebruiken?

NdisMFddiIndicateReceiveComplete notifies NDIS that an FDDI receive packet, identified in a preceding call to NdisMFddiIndicateReceive, has been fully transferred by the NIC so that NDIS can notify the appropriate bound protocol drivers.

[superboer]

Op donderdag 20 juni 2002 14:19 schreef jw.oosting het volgende:
Moet je niet NdisMFddiIndicateReceiveComplete hierna gebruiken?

NdisMFddiIndicateReceiveComplete notifies NDIS that an FDDI receive packet, identified in a preceding call to NdisMFddiIndicateReceive, has been fully transferred by the NIC so that NDIS can notify the appropriate bound protocol drivers.

Bedoel je niet NdisMEthIndicateReceiveComplete ? Want die gebruik ik ook wel, om aan te geven dat het pakketje is getransfereerd (goed nederlands?)

NdisMEthIndicateRecieve is bedoeld voor Ethernet pakketjes ! logischerwijs maak ik dus ook gebruik van NdisMEthIndicateRecieveComplete

[Verwijderd]

Dan zou het toch meoten werken

[Verwijderd]

code:

C:\Documents and Settings\Emiel>ping 88.88.88.88
Pinging 88.88.88.88 with 32 bytes of data:
Request timed out.

Als je iets als dit krijgt wil dat niet zeggen dat je ARP mislukt is, maar dat de host aan de andere kant gewoon niet reageert. Je kan met het tooltje 'arp' kijken wat windows zelf denkt hierover.

[superboer]

Op vrijdag 21 juni 2002 14:02 schreef Qlone het volgende:

...ARP mislukt is, maar dat de host aan de andere kant gewoon niet reageert. Je kan met het tooltje 'arp' kijken wat windows zelf denkt hierover.

Ik weet dus 1000% zeker (heel zeker dus ) dat ik een ARP response terug krijg(creer ik zelf), het lukt me alleen niet om die response te laten zien op het scherm !
en ik zal wel iets vergeten om te doen in die driver maar ik weet niet wat, ik ga ervan uit dat het iets is met NDIS.

Dus mochten meer mensen hier nog gedachten over hebben, spui ze zou ik zo zeggen !

[Verwijderd]

het lukt me alleen niet om die response te laten zien op het scherm !

Als je wilt weten of het systeem je arp response heeft 'gepakt' kun je met 'arp -a' kijken of ie in de arp cache terecht is gekomen. Staat ie daar (kan ik niet opmaken uit je verhaal) dan werkt dat en is 't probleem iets anders, staat ie daar niet, dan ben je in je driver wat fout aan 't doen

[superboer]

Hij komt inderdaad niet in de ARP cache !
Aangezien ik het nu echt niet meer weet zal ik de code
posten van het stuk waar ik alle binnegekomen pakketjes
opvang en probeer omhoog te sturen !

code:

NDIS_STATUS
Ne2000Send(
    IN NDIS_HANDLE MiniportAdapterContext,
    IN PNDIS_PACKET Packet,
    IN UINT Flags
    )
{
    PNE2000_ADAPTER Adapter = (PNE2000_ADAPTER)(MiniportAdapterContext);
    PNDIS_BUFFER    pCurrentBuffer;
    UINT            nBufferCount,TotalPacketLength,CurrentLength;
    PUCHAR          VirtualAddres;
    PUCHAR          LookaheadTemp;
    PNDIS_PACKET    MyPacket;
    NDIS_HANDLE     PacketPool;
    NDIS_STATUS     Status;
    PRSVD           Resvd;
    //
      // Put the packet on the send queue.
      //
    Status=NDIS_STATUS_SUCCESS;
    if (Adapter->FirstPacket == NULL) {
      Adapter->FirstPacket = Packet;
    } else {
      RESERVED(Adapter->LastPacket)->Next = Packet;
    }

    RESERVED(Packet)->Next = NULL;

    Adapter->LastPacket = Packet;

    //
    // Process the next send
    //
    NdisQueryPacket(Packet,NULL,&nBufferCount,&pCurrentBuffer,&TotalPacketLength);
    NdisQueryBuffer(pCurrentBuffer,&VirtualAddres,&CurrentLength);
    //LookaheadTemp=Adapter->Lookahead;

    if(VirtualAddres[0]==0x01&&VirtualAddres[1]==0x02&&VirtualAddres[2]==0x03)
    {
        NdisAllocatePacketPoolEx(&Status,&PacketPool,0x000000FF,
            0x0000FFFF-0x000000FF,4*sizeof(PVOID));
        NdisDprAllocatePacket(&Status,
                           &MyPacket,
                           PacketPool);

        if(Status == NDIS_STATUS_SUCCESS)
        {
            Resvd =(PRSVD)(MyPacket->MiniportReserved);
            Resvd->OriginalPkt = Packet;

            MyPacket->Private.Head = Packet->Private.Head;
            MyPacket->Private.Tail = Packet->Private.Tail;

            //
            // Get the original packet(it could be the same packet as one received or a different one
            // based on # of layered MPs) and set it on the indicated packet so the OOB stuff is visible
            // correctly at the top.
            //
            NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(Packet));
            NDIS_SET_PACKET_HEADER_SIZE(MyPacket,NE2000_HEADER_SIZE);   
            //
            // Set Packet Flags
            //
            NdisGetPacketFlags(MyPacket) = NdisGetPacketFlags(Packet);

            Status = NDIS_GET_PACKET_STATUS(Packet);

            NDIS_SET_PACKET_STATUS(MyPacket, NDIS_STATUS_RESOURCES);
            
            NdisMIndicateReceivePacket(Adapter->MiniportAdapterHandle, &MyPacket, 1);

            if(Status == NDIS_STATUS_RESOURCES)
            {
                NdisDprFreePacket(MyPacket);
            }
            NdisFreePacketPool(PacketPool);
        
        }
    }
    DbgPrint("Send Packet\n");
    Ne2000DoNextSend(Adapter);
    return(NDIS_STATUS_PENDING);
}

Sorry voor de verneukte layout!

[Biedzjee]

Goh, sinds wanneer zitter er driver developers op GoT ?

Ik heb een lijst samengesteld van driver developers in Nederland en Belgie, als je d'r op wilt moet je me maar even ICQ'en.

[superboer]

Geweldig he !

Maar op dit moment kan ik wel janken

[superboer]

Effe een update !

Ik ben erachter gekomen dat er waarschijnlijk iets moet gebeuren met de verschillende IRQL's ?

Omdat als ik de pc opstart met de driver geladen, hij wel de ARP-response pikt die ik vanuit de driver omhoog stuur. (heb ik effe erin gebouwd).
Maar probeer ik hetzelfde, gewoon met mijn applicatie te doen, via dezelfde weg, dan accepteerd ie het gewoon niet !

Dus ik zal daar es even in gaan spitten ! Ik hou jullie op de hoogte !

Mocht iemand anders hier een andere mening over hebben, let me know ! (ik ben geen driver-guru zoals jullie ongetwijfeld wel door hebben )

[Verwijderd]

Ik ben erachter gekomen dat er waarschijnlijk iets moet gebeuren met de verschillende IRQL's ?

Een IRQL geeft toch alleen maar aan hoe 'diep' in het systeem je zit op dat moment? (In sommige IRQL's is bijv paging wel toegestaan, in andere weer niet. Code in een spinlocked section mag bijv geen geheugen reserveren en niet pagen)...

Oh, zomaar even uit nieuwsgierigheid; wat probeer je te maken eigenlijk? Als 't je alleen om ARP requests gaat, waarom zou je dan moeilijk doen met een namaak ne2000 driver enzo? De packet driver die als sample bij de DDK zit voldoet met wat aanpassingen heel aardig .

[superboer]

Op maandag 24 juni 2002 14:20 schreef Qlone het volgende:

Een IRQL geeft toch alleen maar aan hoe 'diep' in het systeem je zit op dat moment? (In sommige IRQL's is bijv paging wel toegestaan, in andere weer niet. Code in een spinlocked section mag bijv geen geheugen reserveren en niet pagen)...

Daar ben ik nu ook achter ! Ik dacht eerst dat het met de IRQL's te maken had(omdat ie het bij het opstarten wel in de ARP cache zat), maar na veel onderzoek en gedebug ben ik er nu achter dat ie gewoon in wel steeds dezelfde IRQL zit en dat het daar dus niet aan ligt.

Op maandag 24 juni 2002 14:20 schreef Qlone het volgende:

Oh, zomaar even uit nieuwsgierigheid; wat probeer je te maken eigenlijk?

Ik probeer een driver te maken voor een Wireless LAN(ik ben gewoon nieuwsgierig en misschien een beetje een nerd ) en aangezien die als netwerk kaart dient te functioneren, dacht ik : "Goh pak eens de ne2000 driver driver source en pas die aan".
Nou heb ik dus alle Hardware aanroepen eruit gehaald en ervoor gezorgd dat die driver gewoon denkt dat er wel een ne2000 kaart inzit !
Hij verstuurt data nu goed, maar ontvangen is een heel ander verhaal!

Op maandag 24 juni 2002 14:20 schreef Qlone het volgende:

Als 't je alleen om ARP requests gaat, waarom zou je dan moeilijk doen met een namaak ne2000 driver enzo? De packet driver die als sample bij de DDK zit voldoet met wat aanpassingen heel aardig .

Het gaat dus niet alleen om ARP-requests maar ook, later, om gewoon IP-pakketjes. Ik dacht zo als ik ping kan laten werken dan lukt dat ook met andere TCP/IP programma's (toch niet verkeerd gedacht? )
Die packet driver heb ik idd ook goed bekeken voordat ik hiermee bezig ging ! En zo'n simpele aanpassing is het toch niet, dacht ik !
Ik maak trouwens wel voor een deel gebruik van die packet-driver, namelijk voor het ontvangen, maar om pakketjes weer terug te zenden mbv die packetdriver lukt niet omdat deze pakketjes dan naar beneden willen (naar de netwerkkaart(die er niet is ))
en ze moeten dus omhoog naar de applicatie die de pakketjes verstuurd! (of heb ik nu iets heel doms gezegd????????)

[Verwijderd]

Ik snap je aanpak nog niet helemaal, maargoed... Je wilt uiteindelijk wel een stuk hardware aan gaan spreken?

Het gaat dus niet alleen om ARP-requests maar ook, later, om gewoon IP-pakketjes. Ik dacht zo als ik ping kan laten werken dan lukt dat ook met andere TCP/IP programma's (toch niet verkeerd gedacht? )
Die packet driver heb ik idd ook goed bekeken voordat ik hiermee bezig ging ! En zo'n simpele aanpassing is het toch niet, dacht ik !
Ik maak trouwens wel voor een deel gebruik van die packet-driver, namelijk voor het ontvangen, maar om pakketjes weer terug te zenden mbv die packetdriver lukt niet omdat deze pakketjes dan naar beneden willen (naar de netwerkkaart(die er niet is ))
en ze moeten dus omhoog naar de applicatie die de pakketjes verstuurd! (of heb ik nu iets heel doms gezegd????????)

Begrijp ik het goed als ik op 't volgende uit kom:

code:

Userspace:  -----------         -----------
         |       |          |        |
         | Jouw app  |          |Andere apps|
         |       |          |   (ping)  |
        -----------         -----------
           |                         |
Kernel: -------|-----------------------------------|--------
           |    -----------     -----------    |
           |   |         |   |       |   |
            -->| Jouw   |<->| TCP/IP    |<--
             |  driver   |   |       |
              -----------     -----------

If so... hoe communiceert jouw app met je driver?

[superboer]

Ik snap je aanpak nog niet helemaal, maargoed... Je wilt uiteindelijk wel een stuk hardware aan gaan spreken?

aanpak is misschien een beetje vreemd, maar ja.
uiteindelijk wel hardware, ja !

Begrijp ik het goed als ik op 't volgende uit kom.

Ja dat klopt !

Mijn applicatie communiceert dmv symbolic links ! Net zoals in die packet driver van DDK.

[superboer]

*Schop em ff weer omhoog !

[Verwijderd]

De sample app van de packet driver gebruikt IOCTL's om data uit die driver te peuteren en er data naartoe te sturen. Hoe doe jij dat? Je zit met 2 'paden' voor je data; aan de ene kant heb je jouw app en aan de andere kant het systeem.

Als jouw app 't 'verkeer' voor je driver afhandelt, hoe test je dat? Gewoonlijk stuurt een netwerkkaart packets 't netwerk op. De jouwe stuurt ze naar je app (die er vervolgens niets mee doet? Ga je nu een heel netwerk simuleren in die applicatie?)

[superboer]

Nou het is in principe heel simpel ! (volgens mijn eigen gedachtengang )

Ik gebruik die app dus om op de pakketjes die ik binnen krijg te antwoorden (dit zijn dus eerst alleen ARP-pakketjes(ARP-response))

Die app stuurt de ARP-response naar mijn driver en die behoort dat weer door te sturen naar de TCP/IP laag !(wat ie dus niet doet )

UPDATE : Het is mij vanavond gelukt om ze erin te krijgen (in de ARP-cache) ! Ik heb geloof ik niet bar veel veranderd, het gebeurde ineens na een BSOD-tje en toen ik na het opstarten het nog een keer probeerde stond ie ineens in de ARP-cache, waar ik hem vantevoren nog uitgehaald had !!!!!! Alleen is het gebleven bij deze ene keer
het lukt me niet om het te reproduceren !!

Ik begin langzaam aan krankzinnig te worden hiero !

[Verwijderd]

Werkt het nu nog niet?

[superboer]

UPDATE!

Op vrijdag 28 juni 2002 17:01 schreef jw.oosting het volgende:
Werkt het nu nog niet?

Goh leuk dat je het vraagt !

Ik heb het eindelijk voor elkaar ! Ik had blijkbaar gewoon teveel van de harde waren weg gecommentarieerd en na veel gezoek en gehack heb ik het nu eindelijk voor elkaar !

In de aanroepen naar de hardware stonden bepaalde functies die ik blijkbaar wel nodig had om succesvol iets naar de TCP/IP laag te sturen !

Mijn missie is voltooid !

_{Ik kan wel janken van geluk !}

[Verwijderd]

Congrats