aboutsummaryrefslogtreecommitdiffstats
path: root/wiretap/erf.c
diff options
context:
space:
mode:
authorPeter Wu <peter@lekensteyn.nl>2016-02-23 01:56:45 +0100
committerMichael Mann <mmann78@netscape.net>2016-04-03 16:22:46 +0000
commitc5b2c1e8f40cee913bd70fcc00284483b3c92fcd (patch)
tree34a87e10fa43477cb69a5443132db5fc2462f800 /wiretap/erf.c
parentc8665c114a3f32237986a89c1fbec2d7f6438826 (diff)
reassemble: remove special treatment for truncated data
Do not try to recover from truncated tvbs for fragment_add_seq-like functions: - If it is the first block and the dissector requested frag_data_len number of bytes, we should not lie and pretend that we are fully reassembled. - For other blocks, returning NULL as no reassembly was possible makes sense. But other fragments in the list should not be cleared as there may be partial fragments which were returned before. It seems that this special behavior was introduced in b2c11b5e13248b1c98ee5104eab411e842911e19 (freeing fragments and returning NULL as an optimization when fragments are deemed not needed anymore) and faeb2c2ee16e61e54c880163e98d6528dd0c5619 (for returning fd_head for the first fragment, "so the first fragment gets dissected as fragmented packet"). Now in theory unused fragments could stick around, but that also possible with the normal fragment_add functions. Bug: 11799 Change-Id: I20829c54e1b2eee25a91fe4de51b19b1458c7789 Reviewed-on: https://code.wireshark.org/review/14082 Petri-Dish: Peter Wu <peter@lekensteyn.nl> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Peter Wu <peter@lekensteyn.nl> Reviewed-by: Michael Mann <mmann78@netscape.net>
Diffstat (limited to 'wiretap/erf.c')
0 files changed, 0 insertions, 0 deletions