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: [email protected] [mailto:[email protected]] On Behalf Of Gedare Bloom Sent: Saturday, July 01, 2017 1:30 PM To: Kirspel, Kevin <[email protected]> Cc: [email protected]; [email protected] <[email protected]> Subject: Re: LIBBSD TCPDUMP On Sat, Jul 1, 2017 at 11:49 AM, Kirspel, Kevin <[email protected]> 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:[email protected]] > Sent: Saturday, July 01, 2017 11:39 AM > To: Gedare Bloom <[email protected]> > Cc: [email protected] <[email protected]>; Kirspel, Kevin > <[email protected]> > Subject: Re: LIBBSD TCPDUMP > > > > > > > > On Jul 1, 2017 10:34 AM, "Gedare Bloom" <[email protected]> wrote: > > On Sat, Jul 1, 2017 at 10:01 AM, Kirspel, Kevin > <[email protected]> > 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 >> [email protected] >> 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 > [email protected] > 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= > > _______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
