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