diff options
| author | Gerald Combs <gerald@wireshark.org> | 2009-06-15 22:25:05 +0000 |
|---|---|---|
| committer | Gerald Combs <gerald@wireshark.org> | 2009-06-15 22:25:05 +0000 |
| commit | f7d80a113c0be45df2016f439ba478c0505e8f75 (patch) | |
| tree | 1d63cbc61fc1dec954adf1b134a0ea87eff5a183 /wiretap | |
| parent | bfe13d8bbe5682d27fd98e2bb52847adcaa44c52 (diff) | |
From Ben Winslow via bug 3535:
Because Lucent/Ascend equipment will sometimes omit the hex dump for a packet
or send two headers followed by two hex dumps, Wireshark needs to be very
lenient when parsing a Lucent/Ascend trace. On a busy access server, a packet
like this is pretty likely to appear within a few minutes.
svn path=/trunk/; revision=28749
Diffstat (limited to 'wiretap')
| -rw-r--r-- | wiretap/ascend.y | 11 |
1 files changed, 10 insertions, 1 deletions
diff --git a/wiretap/ascend.y b/wiretap/ascend.y index e1ad3dc1df..6b23c504db 100644 --- a/wiretap/ascend.y +++ b/wiretap/ascend.y @@ -482,8 +482,17 @@ parse_ascend(FILE_T fh, guint8 *pd, struct ascend_phdr *phdr, as to where to look for the next packet, if any. If we didn't, maybe this record was broken. Advance so we don't get into an infinite loop reading a broken trace. */ - if (first_hexbyte) + if (first_hexbyte) { *start_of_data = first_hexbyte; + } else { + /* Sometimes, a header will be printed but the data will be omitted, or + worse -- two headers will be printed, followed by the data for each. + Because of this, we need to be fairly tolerant of what we accept + here. If we didn't find any hex bytes, skip over what we've read so + far so we can try reading a new packet. */ + *start_of_data = file_tell(*fh_ptr); + retval = 0; + } /* if we got at least some data, return success even if the parser reported an error. This is because the debug header gives the number |