LIBBSD TCPDUMP

[Kirspel, Kevin]

No.  I fixed that after I noticed the data was invalid during testing.  I moved the variable declaration outside of the if statement and now the data is correct.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510-4444 ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-----Original Message-----
From: gedare at gwmail.gwu.edu [mailto:gedare at gwmail.gwu.edu] On Behalf Of Gedare Bloom
Sent: Saturday, July 01, 2017 1:30 PM
To: Kirspel, Kevin <Kevin-Kirspel at idexx.com>
Cc: joel at rtems.org; rtems-devel at rtems.org <devel at rtems.org>
Subject: Re: LIBBSD TCPDUMP

On Sat, Jul 1, 2017 at 11:49 AM, Kirspel, Kevin <Kevin-Kirspel at idexx.com> wrote:
> This is how I fixed it.  I did similar things for EXTRACT_32BITS and 
> EXTRACT_64BITS.
>
>
>
> static inline u_int16_t
>
> EXTRACT_16BITS(const void *p)
>
> {
>
> #if defined(__arm__) && defined(__rtems__)
>
>                 if(((uint32_t)p % 2) != 0) {
>
>                                 u_int16_t value;
>
>                                 u_int8_t *ptr = (u_int8_t *)&value;
>
>                                 ptr[0] = ((const u_int8_t *)p)[0];
>
>                                 ptr[1] = ((const u_int8_t *)p)[1];
>
>                                 p = &value;
>

Is it correct to assign a pointer to a block-scoped variable here? It looks suspect to me. I'd at least put the declaration of 'value'
before the block here.

>                 }
>
> #endif /* __rtems__ */
>
>                 return ((u_int16_t)ntohs(*(const u_int16_t *)(p)));
>
> }
>
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510-4444 ext. 81642
>
> Direct: (770)-688-1642
>
> Fax: (770)-510-4445
>
>
>
> From: Joel Sherrill [mailto:joel at rtems.org]
> Sent: Saturday, July 01, 2017 11:39 AM
> To: Gedare Bloom <gedare at rtems.org>
> Cc: rtems-devel at rtems.org <devel at rtems.org>; Kirspel, Kevin 
> <Kevin-Kirspel at idexx.com>
> Subject: Re: LIBBSD TCPDUMP
>
>
>
>
>
>
>
> On Jul 1, 2017 10:34 AM, "Gedare Bloom" <gedare at rtems.org> wrote:
>
> On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin 
> <Kevin-Kirspel at idexx.com>
> wrote:
>> I get a crash when running the tcpdump command in LIBBSD.  It is due 
>> to the following structure
>>
>>
>>
>> struct stp_bpdu_ {
>>
>>     u_int8_t protocol_id[2];
>>
>>     u_int8_t protocol_version;
>>
>>     u_int8_t bpdu_type;
>>
>>     u_int8_t flags;
>>
>>     u_int8_t root_id[8];
>>
>>     u_int8_t root_path_cost[4];
>>
>>    u_int8_t bridge_id[8];
>>
>>     u_int8_t port_id[2];
>>
>>     u_int8_t message_age[2];
>>
>>     u_int8_t max_age[2];
>>
>>     u_int8_t hello_time[2];
>>
>>     u_int8_t forward_delay[2];
>>
>>     u_int8_t v1_length;
>>
>> };
>>
>>
>>
>> In the code, there is an access to the port_id field as follows:
>> EXTRACT_16BITS(&stp_bpdu->port_id).  EXTRACT_16BITS calls ntohs() .  
>> Since the address of “&stp_bpdu->port_id” is at an odd word (16 bit) 
>> boundary, an exception is generated.  What is the correct way to fix 
>> this?  I was going to update EXTRACT_16BITS to check for an odd 
>> boundary and fix it up before calling ntohs().
>>
>
> That would probably be a more portable fix than allowing unaligned 
> accesses. I think the alignment should be made to the CPU_ALIGNMENT 
> macro.
>
>
>
> Can't you also just pull it out a byte at a time, form the net version 
> and then ntohs()?
>
>
>
> That's what I coded recently in some marahalling code.
>
>
>
>
>
>>
>>
>> Kevin Kirspel
>>
>> Electrical Engineer - Sr. Staff
>>
>> Idexx Roswell
>>
>> 235 Hembree Park Drive
>>
>> Roswell GA 30076
>>
>> Tel: (770)-510-4444 ext. 81642
>>
>> Direct: (770)-688-1642
>>
>> Fax: (770)-510-4445
>>
>>
>>
>>
>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_m
>> ailman_listinfo_devel&d=DwIFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ
>> 32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=ZD1dtkTMUak_NH2kvhh9fcWsBvl09av5rA
>> xPKDDt1ac&s=QxnRQLVQGW81f8ARsKfj1Hd7M4JNXV0oc_WjhT5dOHw&e=
> _______________________________________________
> devel mailing list
> devel at rtems.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_ma
> ilman_listinfo_devel&d=DwIFaQ&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32
> G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=ZD1dtkTMUak_NH2kvhh9fcWsBvl09av5rAxPKDDt1ac&s=QxnRQLVQGW81f8ARsKfj1Hd7M4JNXV0oc_WjhT5dOHw&e=
>
>