virtual END and ARP processing - VxWorks

This is a discussion on virtual END and ARP processing - VxWorks ; Hi All, I'm developing a virtual END driver to sniff ARP and ICMP data from an ethernet connection and forward it to the vxworks network stack so it can process them and generate the apropriate responses. Is it possible to ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: virtual END and ARP processing

  1. virtual END and ARP processing

    Hi All,

    I'm developing a virtual END driver to sniff ARP and ICMP data from an
    ethernet connection and forward it to the vxworks network stack so it
    can process them and generate the apropriate responses. Is it possible
    to do this with a END driver? I was told that only an NPT driver would
    be able to pass the ARP packets to the MUX is this correct?

    thanks,
    Tiago.


  2. Re: virtual END and ARP processing

    I have done something similar. I added a "snarf protocol". My use was to
    prevent some packets
    to reach the TCP/IP stack (simple firewall), while most packets was to be
    forwarded up to the
    stack. This is also a good way to make a "sniffer". In older versions of
    VxWorks we used the
    etherInputHookAdd I am presently using VxWorks 5.4
    Wind River has some documentation, or try to google "snarf vxworks". Thisone
    looks OK to
    check if this is an OK soulution:
    http://networking.ittoolbox.com/pub/PR100102.htm

    BT


    wrote in message
    news:1144056353.200694.178360@i39g2000cwa.googlegr oups.com...
    > Hi All,
    >
    > I'm developing a virtual END driver to sniff ARP and ICMP data from an
    > ethernet connection and forward it to the vxworks network stack so it
    > can process them and generate the apropriate responses. Is it possible
    > to do this with a END driver? I was told that only an NPT driver would
    > be able to pass the ARP packets to the MUX is this correct?
    >
    > thanks,
    > Tiago.
    >




  3. Re: virtual END and ARP processing

    Hi,
    thanks for your response.

    In my case I belive I have to implement a driver because the ARP and
    ICMP packets come from an ASIC which has an API that enables me to
    capture and send raw ethernet packets. I then have to Inject these
    packets in the VXworks network stack (so a correct response can be
    generated and sent to the device) and I think the only way to do this
    is to develop an END driver.
    My question is if this is possible with an END driver?

    In an somewhat unrelated matter is there a way to hook the ARP table so
    changes can be detected? For example a driver injects a ARP response
    packet in the MUX, the packet is process and results in an update of
    the ARP table, a client that has an update hook on the table receives a
    notification and updates to the new information.

    thanks,
    Tiago.


  4. Re: virtual END and ARP processing


    wrote in message
    news:1144145468.566808.70660@g10g2000cwb.googlegro ups.com...
    > Hi,
    > thanks for your response.
    >
    > In my case I belive I have to implement a driver because the ARP and
    > ICMP packets come from an ASIC which has an API that enables me to
    > capture and send raw ethernet packets. I then have to Inject these
    > packets in the VXworks network stack (so a correct response can be
    > generated and sent to the device) and I think the only way to do this
    > is to develop an END driver.
    > My question is if this is possible with an END driver?
    >
    > In an somewhat unrelated matter is there a way to hook the ARP table so
    > changes can be detected? For example a driver injects a ARP response
    > packet in the MUX, the packet is process and results in an update of
    > the ARP table, a client that has an update hook on the table receives a
    > notification and updates to the new information.
    >
    > thanks,
    > Tiago.
    >


    Something like this:


    Can you do something like this?

    Assume you have a received mblk:
    M_BLK_ID pMblk, /* Received packet on virtual interface.. */


    END_OBJ *pEnd; /* Pntr to an END object. */
    char *devName; /* Name of device which you want TCPIP stack to
    belive the packet came from */
    M_BLK_ID pMblkCopy;

    devName = "fei"; /* Whatever you have. */

    pEnd = endFindByName(devName,0);
    if (pEnd != NULL) {
    pMblkCopy =
    netMblkChainDup(pEnd->pNetPool,pMblk,0,M_COPYALL,M_DONTWAIT);
    if (pMblkCopy != NULL) {
    END_RCV_RTN_CALL(pEnd,pMblkCopy);
    netMblkClChainFree(pMblk); /* Free the original mBlk chain
    */
    }
    }

    BT



  5. Re: virtual END and ARP processing

    Hi,

    I'm not getting the raw packets with an end driver. I obtain these
    packets through a proprietary API. What you describe would work for
    packet injection in the MUX, but where do the response ICMP and ARP
    packets go to (I still have to have an end driver to receive the
    responses and send them to the ASIC)? Is there a way to intercept the
    packets that come from the MUX before they reach the end driver?

    thanks,
    Tiago.


  6. Re: virtual END and ARP processing


    wrote in message
    news:1144184870.423033.126120@v46g2000cwv.googlegr oups.com...
    > Hi,
    >
    > I'm not getting the raw packets with an end driver. I obtain these
    > packets through a proprietary API. What you describe would work for
    > packet injection in the MUX, but where do the response ICMP and ARP
    > packets go to (I still have to have an end driver to receive the
    > responses and send them to the ASIC)? Is there a way to intercept the
    > packets that come from the MUX before they reach the end driver?
    >
    > thanks,
    > Tiago.
    >



    Hi again

    Did I try to explain the opposit problem?
    You can intercept packts from and END driver before they are
    forwared to the TCPIPe stack in the MUX layer with a "snarf"
    protocol (MUX_PROTO_SNARF) You may then discard the packet, modify
    the packet or just forward it....

    In a similar way You can intercept packets from the TCPIP stack before
    they are sent to an END driver with an output protocol (MUX_PROTO_OUTPUT).
    If the ICMP and ARP's are comming from the TCPIP stack this is the
    way. (I belived you ment ICMP and ARP's received from the wire)

    Use muxBind() to add the protocols.

    The MUX layer is a layer above the END driver and below the network layer,
    both
    sent and received packets passes the MUX layer and can be intercepted.

    The WxWorks document "Network Protocol Toolkit" describes how to write
    MUX protocols and the MUX API's ++
    http://www.embed.com.cn/download/fy_...etProGuide.pdf
    Hope you find something there.

    Another way can be to write an "virtual" END driver,
    load the driver (muxDevLoad()). Attach it (ipAttach()) and set IP address
    and a
    propper netmask. Then All packets sent to this IP address will end up in
    your "virtual"
    send routine. Here you may do your stuff and maybe forward it to a "real"
    END driver
    with MuxSend(). This brings the packet up to the MUX layer again and then
    down
    to your "real" END driver.

    BT



+ Reply to Thread