ipv6: RH extension header parsing issue

A logic error in the IPv6 Routing header parsing caused accidental
updating of the original packet buffer. The calculated extension
header lenght was set to the length field of the routing header,
causing it to be wrong.

This has 2 consequences:

1. defrag failure. As the now modified payload was used in defrag,
the decoding of the reassembled packet now contained a broken length
field for the routing header. This would lead to decoding failure.

The potential here is evasion, although it would trigger:
[1:2200014:1] SURICATA IPv6 truncated extension header

2. in IPS mode, especially the AF_PACKET mode, the modified and now
broken packet would be transmitted on the wire. It's likely that
end hosts and/or routers would reject this packet.

NFQ based IPS mode would be less affected, as it 'verdicts' based on
the packet handle. In case of replacing the packet (replace keyword
or stream normalization) it could broadcast the bad packet.

Additionally, the RH Type 0 address parsing was also broken. It too
would modify the original packet. As the result of this code was not
used anywhere else in the engine, this code is now disabled.

Reported-By: Rafael Schaefer <rschaefer@ernw.de>
app-layer-ssh: fix banner parser

Carefully crafted SSH banner could result in parser error.

CVE 2014-6603

Signed-off-by: Eric Leblond <eric@regit.org>
Reported-By: Steffen Bauch
ssh: convert error message to debug statement

Don't print errors based on traffic issues.
Update changelog for 2.0.4