Coverity warns around that test code:
"Overrunning struct type in46_addr of 20 bytes by passing it to a
function which accesses it at byte offset 39."
That's basically because in64a_from_eua expects to be passed a 2 element
array to be filled. The second element, though, is only accessed in the
case where an IPv4v6 EUA is passed, so in the cases where the test
explicitly passes an IPv4 or IPv6 EUA it's not really an issue, hence
coverity throwing a false positive here.
Let's anyway rewrite the code to pass a 2 element array for completeness,
since it doesn't hurt and makes coverity happy.
Related: Coverity CID#249006
Change-Id: Idfc9104f48eeee6e7f11ebc5c17d4b0e4b2fe9e2
Before this commit, when an MS requested an ipv4v6 context osmo-ggsn
returned an error stating the type was unknown, and this text was
printed in the log:
Processing create PDP context request for APN 'ims'
Cannot decode EUA from MS/SGSN: f1 8d
This patch has been tested with an MS running the 3 types of addresses:
- IPv4 and IPv6: no regressions observed, the context is activated and
packets are sent to the ggsn.
- IPv4v6: Wireshark correctly parses request and reponse, and then
ICMPv6 traffic from both sides. Finally I see the MS using the IPv4 and
IPv6 DNS addresses advertised and TCP traffic over IPv4 (because
probably my IPv6 network setup is not correct). I also checked I can
disable/enable data (pdp ctx delete and activate) several times without
any issue.
Change-Id: Ic820759167fd3bdf329cb11d4b942e903fe50af5
Pau Espin
Neels Hofmeyr
Harald Welte