[Oisf-devel] Decoding Problem [ One byte Missing ]

[Prabhakaran Kasinathan]

Hi Anoop Saldanha,

Thanks for your help. I understood the second method and it worked
perfectly. printf prints to console normally :). Now i have the basic
decoding, which gives me the src and dst address + some other data required
for time being.

In-order to write the Detection module. Which files to Look up?


My Idea is to detect an flooding intially. Such that a signature should
match the src and dest address and the rate of incoming packet's.

Could you give me a high level overview of where to start and look after
could be very helpful :)

Thank you!.


On Wed, Jul 25, 2012 at 6:37 PM, Anoop Saldanha <anoopsaldanha at gmail.com>wrote:

> On Wed, Jul 25, 2012 at 4:48 PM, Prabhakaran Kasinathan
> <prabhakaran1989 at gmail.com> wrote:
> > Dear Developer's,
> >
> > I have been working in decoding the IEEE802154 packets and 6LoWPAN
> packets.
> > It took some time to understand the decoding functionality. Pls Help!
> >
> > Now my problem is,
> >
> > One byte is missing when i try to separate the structure like ( uint16_t
> ,
> > uint8_t,here next 8 bit is missing, uint16_t ...) it jumps to the next 16
> > bit and next 16 bit and soo on!  What is the problem here?
> >
> > whereas it works correctly either if i use ( uint16_t , uint8_t
> > ,uint8_t,uint16_t ,uint16_t , and so.... ) or ( uint16_t ,uint16_t
> ,uint16_t
> > ,uint16_t , ... ) . I couldn't understand this.
> >
> > Details :
> >
> > The current Header of IEEE802154 packet.
> >
> > octects 2      1            2            2            2
> > |  FCF     |  Seq no | Dst Pan | Dst Add | Src Add | remaining data
> >
> >
> > Hex :  61 88 d9 22 00 01 00 64 00 e0 ... Data...        [ the byte 22 is
> > missing when i print the hole order ]
> >
> > My Structure Declarations
> >
> > typedef struct Ieee802154Hdr_ {
> >     uint16_t ieee802154_fcf;
> >     uint8_t ieee802154_seq;
> >     uint16_t  ieee802154_dstpan;
> >     uint16_t  ieee802154_dstadd;
> >     uint16_t  ieee802154_srcadd;
> > } Ieee802154Hdr;
> >
> >     SCLogInfo("\n Length  %d ieee FCF: %x | ieee seq %x | DstPan  %04x |
> > Dstadd %04X | SrcAdd
> >
> %04x",len,ntohs(p->ieeeh->ieee802154_fcf),ntohs(p->ieeeh->ieee802154_seq),ntohs(p->ieeeh->ieee802154_dstpan),ntohs(p->ieeeh->ieee802154_dstadd),ntohs(p->ieeeh->ieee802154_srcadd));
> >
> >
> > Output is:
> >
> > Length  26 ieee FCF: 6188 | ieee seq d9 | DstPan  0001 | Dstadd 0064 |
> > SrcAdd 00e0
> >
> >                                                                  it
> should
> > be 0022               0001              0064
> >
> > Note: If I use the (uint16_t) continuously, I get the bytes correctly.
> How
> > to overcome this problem.
> >
>
> This is a gcc alignment issue.  Can't think of any portable solutions as
> such.
>
> One way would be use a uint8_t array to point to the packet byte
> array, and use macros to dereference the various fields from this
> array.
>
> #DEFINE GET_IEEE802145_DSTPAN(array) (*((uint16_t *)((uint8_t *)array + 3))
>
> --
>
> Another solution would be to define the struct as
>
> {
>     uint16_t a;
>     uint8_t b;
>     uint8_t c1;
>     uint8_t c2;
>      ...
> }
>
> So c1 + c2 in your case would be ieee802154_dstpan.  You can hide the
> retrieval of the value from c1 + c2 using some macros.
>
> Let me know if you have a better solution.
>
> > Question 2:
> >
> > How to use the SCLogDebug and Printf lines to get printed in console?
> Since
> > I couldn't find that. I started using SCLogInfo to print and debug the
> > error's.
> >
> > --
> > Best Regards,
> > Prabhakaran Kasinathan
> > +39 3279720502
> >
> >
> > _______________________________________________
> > Oisf-devel mailing list
> > Oisf-devel at openinfosecfoundation.org
> > http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
>
> doesn't printf print to the console?  SCLogDebug needs --enable-debug
> while configuring and requires you to set the log-level  in the conf
> to debug.
>
> --
> Anoop Saldanha
>



-- 
Best Regards,
Prabhakaran Kasinathan
+39 3279720502
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20120726/072f96d3/attachment-0002.html>