VxWorks Gurus, need help with MUX : MuxBind & M_BLK_ID - VxWorks
This is a discussion on VxWorks Gurus, need help with MUX : MuxBind & M_BLK_ID - VxWorks ; Hello.
I am using the muxbind API to register my protocol handler with the FE
Driver. I am interested in getting the contents of the ethernet frame
including the header & the data.
The handler routine that gets passed to ...
-
VxWorks Gurus, need help with MUX : MuxBind & M_BLK_ID
Hello.
I am using the muxbind API to register my protocol handler with the FE
Driver. I am interested in getting the contents of the ethernet frame
including the header & the data.
The handler routine that gets passed to the MuxBind called say for ex:
MY_PROTO is my own ethernet type (0x8989)
muxBind(device, unit, MyRxPktHandler, NULL,NULL, NULL,
MY_PROTO, "Rx Handler", NULL);
MyRxPktHandler(void *CallbackId, long type, M_BLK_ID pMblk,
LL_HDR_INFO *pLinkHdrInfo, void *pSpareData)
{
}
I need to get the ethernet header offset, I went through the
documentation & understand that the offsets need to be manually
calculated from
pMblk->mBlkHdr->mData
My assumption is that the ethernet (Type II) header starts at offset 0
at mData? Can anyone please confirm?
Also the total length of the ethernet frame would be pMblk-
>mBlkPktHdr.len - 4 (FCS)
Please correct me if this is incorrect.
Thanks
/R
-
Re: VxWorks Gurus, need help with MUX : MuxBind & M_BLK_ID
On Apr 2, 6:17 pm, Ramesh wrote:
> Hello.
>
> I am using the muxbind API to register my protocol handler with the FE
> Driver.
What version of VxWorks? What CPU type? (Yes, these things matter.)
> I am interested in getting the contents of the ethernet frame
> including the header & the data.
>
> The handler routine that gets passed to the MuxBind called say for ex:
>
> MY_PROTO is my own ethernet type (0x8989)
>
> muxBind(device, unit, MyRxPktHandler, NULL,NULL, NULL,
> MY_PROTO, "Rx Handler", NULL);
>
> MyRxPktHandler(void *CallbackId, long type, M_BLK_ID pMblk,
> LL_HDR_INFO *pLinkHdrInfo, void *pSpareData)
> {
>
> }
>
> I need to get the ethernet header offset,
Stop. I think you may be misstating something here. The "ethernet
header offset" is always 0: the ethernet frame header is always the
first thing in the frame.
You might have really meant to ask about the "ethernet header length"
or the "ethernet payload offset," which will tell you where the frame
contents begin (usually the IP header, but in your case something
else). If that's the case, you can figure it out from the LL_HDR_INFO
structure provided to your receive routine, as shown above. The
LL_HDR_INFO structure contains a dataOffset field: this tells you
where the ethernet payload begins (or, if you prefer, where the
ethernet frame header ends). For most Ethernet_II frames, dataOffset
is 14 (sizeof (struct ether_header)) but if you use VLANs or 802.3
frames with SNAP headers, this could be different. (The LL_HDR_INFO
structure is defined in target/h/end.h.)
> I went through the
> documentation & understand that the offsets need to be manually
> calculated from
>
> pMblk->mBlkHdr->mData
>
> My assumption is that the ethernet (Type II) header starts at offset 0
> at mData? Can anyone please confirm?
Yes. For an Ethernet_II or 802.3 frame, pMblk->m_data always points to
the start of the frame header (offset 0).
> Also the total length of the ethernet frame would be pMblk-
>
> >mBlkPktHdr.len - 4 (FCS)
>
> Please correct me if this is incorrect.
This part is not quite correct (I think): if you are implying that you
need to subtract out the ethernet CRC length yourself, then that's
wrong. The driver always returns the frame without the ethernet CRC
(Frame Check Sequence), so the length in pMblk->m_pkthdr.len is the
size of the frame header plus payload only. You don't need to subtract
out the CRC length yourself.
-Bill
> Thanks
> /R
-
Re: VxWorks Gurus, need help with MUX : MuxBind & M_BLK_ID
Thanks, please find my response inline.
On Apr 3, 1:37 pm, noiset...@gmail.com wrote:
> On Apr 2, 6:17 pm, Ramesh wrote:
>
> > Hello.
>
> > I am using the muxbind API to register my protocol handler with the FE
> > Driver.
>
> What version of VxWorks? What CPU type? (Yes, these things matter.)
This is 6.1 & CPU Type is Motorola 8260
>
>
>
> > I am interested in getting the contents of the ethernet frame
> > including the header & the data.
>
> > The handler routine that gets passed to the MuxBind called say for ex:
>
> > MY_PROTO is my own ethernet type (0x8989)
>
> > muxBind(device, unit, MyRxPktHandler, NULL,NULL, NULL,
> > MY_PROTO, "Rx Handler", NULL);
>
> > MyRxPktHandler(void *CallbackId, long type, M_BLK_ID pMblk,
> > LL_HDR_INFO *pLinkHdrInfo, void *pSpareData)
> > {
>
> > }
>
> > I need to get the ethernet header offset,
>
> Stop. I think you may be misstating something here. The "ethernet
> header offset" is always 0: the ethernet frame header is always the
> first thing in the frame.
Yes, I meant the start of the ethernet header.
>
> You might have really meant to ask about the "ethernet header length"
> or the "ethernet payload offset," which will tell you where the frame
> contents begin (usually the IP header, but in your case something
> else). If that's the case, you can figure it out from the LL_HDR_INFO
> structure provided to your receive routine, as shown above. The
> LL_HDR_INFO structure contains a dataOffset field: this tells you
> where the ethernet payload begins (or, if you prefer, where the
> ethernet frame header ends). For most Ethernet_II frames, dataOffset
> is 14 (sizeof (struct ether_header)) but if you use VLANs or 802.3
> frames with SNAP headers, this could be different. (The LL_HDR_INFO
> structure is defined in target/h/end.h.)
I am using ethernet type II and want to copy the ethernet header 14
bytes & the next two bytes
is the length of my own data in the ethernet frame.
>
> > I went through the
> > documentation & understand that the offsets need to be manually
> > calculated from
>
> > pMblk->mBlkHdr->mData
>
> > My assumption is that the ethernet (Type II) header starts at offset 0
> > at mData? Can anyone please confirm?
>
> Yes. For an Ethernet_II or 802.3 frame, pMblk->m_data always points to
> the start of the frame header (offset 0).
>
> > Also the total length of the ethernet frame would be pMblk-
>
> > >mBlkPktHdr.len - 4 (FCS)
>
> > Please correct me if this is incorrect.
>
> This part is not quite correct (I think): if you are implying that you
> need to subtract out the ethernet CRC length yourself, then that's
> wrong. The driver always returns the frame without the ethernet CRC
> (Frame Check Sequence), so the length in pMblk->m_pkthdr.len is the
> size of the frame header plus payload only. You don't need to subtract
> out the CRC length yourself.
Thanks a bunch. Appreciate your detailed response.
Cheers
/Ramesh
>
> -Bill
>
> > Thanks
> > /R