Raw Ethernet, issues

*** Updating this post with additional information emailed by customer, in order to help others who may encounter this issue ***

"Hi Steve,

 I posted a problem with send earlier.  It turns out that there are two problems.  We have a work arounds.

 One is a Linux problem, and the other is on the TI side.

 Linux doesn’t accept the ethertype 0x300 on the incoming packet.   But 0x801 seems to work for both sides, TI and Linux.  That’s okay for this application.

 On the TI side, it seems that the send() and the getsendncbuff() do not accept lengths greater than 1500.  Since the raw buffer includes the header, this means there is not room for a header at the de-facto standard 1514.   Mabe the MTU is not set correctly?

 MItch"

*** Updating this post with additional information emailed by customer, in order to help others who may encounter this issue ***

"Steve

 The getsendncbuff(), after the sendnc() has completed, is returning ENOBUFS.

Seems very strange.  Can you give me a clue?

 Thanks

Mitch"

Mitch,

I found an email chain in which someone had encountered this same issue.  Here is where the chain left off.  I have asked everyone involved what the result of this was, to see where they got with this, but I am still awaiting a repsonse.  FYI, this problem was on different hardware (and so different Ethernet drivers), but this code below is from the generic stack code:

Can you set a breakpoint at RawEthSockCreatePacket() in ndk\src\stack\rawethsock\rawethsock.c and check ps->TxBufSize you are setting, ps->TxBufSize is set in RawEthSockSet(), and your application can configure the maximum 1500 bytes TX payload size using setsockopt() after creating a raw Ethernet socket:

PBM_Pkt* RawEthSockCreatePacket( HANDLE hSock, UINT32 Payload, UINT32* pError )

{

    SOCKRAWETH*     ps = (SOCKRAWETH *)hSock;

    PBM_Pkt*        pPkt;

    /* The maximum packet size that can be transmitted is limited

     * by either the MTU of the interface on which the packet will

     * be transmitted or by the TxBufSize configured on this socket,

     * whichever is the smaller value of those.

     * There is no layer to do the fragmentation on the Raw Eth Tx path,

     * hence its important to limit the packet size by the MTU so as to

     * avoid drops at the driver.

     */

    if( ((ps->TxBufSize) && (Payload > ps->TxBufSize)) || ((ps->hIF) && (Payload > IFGetMTU( ps->hIF ))) )

    {

        /* The packet size too big to transmit using the specified

         * settings.

         */

        *pError = EMSGSIZE;   /* Set a breakpoint here */

        return NULL;

    }

Thanks,

Steve

Perhaps therein is the problem.

Our application is doing RAW ethernet.  That means the packet includes the Ethernet header. It seems to me the stack should allow RAW packets that are as large as the MTU + Ethernet Header.

Mitch,

I finally heard back from the people who encountered this issue previously.  It turns out it was never solved, they merely worked around it.  Here's what they said:

"Turns out it [wasn't] a blocking issue – amidst the things in our [project]. So, we still run NDK with 1486 + 14 MTU only. We’ve not applied any correction yet."

I have a suggestion for a workaround.  Since you have the stack code, you could try to update the code to have something like the following in bold type:

#define ETH_HEADER_SIZE 14

    …

if( ((ps->TxBufSize) && (Payload > ps->TxBufSize)) || ((ps->hIF) && (Payload > IFGetMTU( ps->hIF ) + ETH_HEADER_SIZE)) )

{

    /* The packet size too big to transmit using the specified

     * settings.

     */

    *pError = EMSGSIZE;

    return NULL;

}

Steve

Yes, i realize i could patch it like that.  But it probably makes more sense  to just comment it out.  We know the packet is a legitimate size because we contro the interface on both ends and we wrote the software that generates the packet.

This another good example why for a DSP, a general purpose network stack is not a subsitute for a bare bones packet interface.  The general purpose stack limits utility and wastes processor and memory cycles doing things that are irrelevant to the application.