Amazingly, there *are* apparently protocols with IPv4 addresses in

byte-swapped form - i.e., not network byte order, but the reverse of
network byte order - as, a long time ago, somebody asked to have the
"little_endian" flag affect the way proto_tree_add_item() fetched IPv4
addresses from the packet.

Use ENC_BIG_ENDIAN for IPv4 addresses (ENC_NA and ENC_BIG_ENDIAN have
the same value, but this makes it clearer that we, sadly, need to care).

git-svn-id: http://anonsvn.wireshark.org/wireshark/trunk@39708 f5534014-38df-0310-8fa8-9805f1628bb7

diff --git a/epan/dissectors/packet-diameter.c b/epan/dissectors/packet-diameter.c
index d25892780f3e30f185aab7f003908cc028a45c7e..3dbf765fa6db86f92f185a6847252ea8e069314a 100644 (file)
--- a/epan/dissectors/packet-diameter.c
+++ b/epan/dissectors/packet-diameter.c
@@ -515,7 +515,7 @@ address_rfc_avp(diam_ctx_t* c, diam_avp_t* a, tvbuff_t* tvb)
                                expert_add_info_format(c->pinfo, pi, PI_MALFORMED, PI_WARN, "Wrong length for IPv4 Address");
                                return "[Malformed]";
                        }
-                       pi = proto_tree_add_item(pt,t->hf_ipv4,tvb,2,4,ENC_NA);
+                       pi = proto_tree_add_item(pt,t->hf_ipv4,tvb,2,4,ENC_BIG_ENDIAN);
                        break;
                case 2:
                        if (len != 16) {
@@ -583,7 +583,7 @@ address_v16_avp(diam_ctx_t* c, diam_avp_t* a, tvbuff_t* tvb)
 
        switch (len) {
                case 4:
-                       pi = proto_tree_add_item(pt,t->hf_ipv4,tvb,0,4,ENC_NA);
+                       pi = proto_tree_add_item(pt,t->hf_ipv4,tvb,0,4,ENC_BIG_ENDIAN);
                        break;
                case 16:
                        pi = proto_tree_add_item(pt,t->hf_ipv6,tvb,0,16,ENC_NA);