[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

Peter Wu  changed:

   What|Removed |Added

 Status|IN_PROGRESS |RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Peter Wu  ---
Fixed the reassembly issue in:
v2.9.0rc0-702-g06d6fbfdc1
v2.6.2rc0-10-g305f63f021

For the issue in comment 18, consider opening a new bug report if it is
important.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #22 from Gerrit Code Review  ---
Change 2 merged by Peter Wu:
6lowpan: fix reassembly for forwarded packets

https://code.wireshark.org/review/2

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #21 from Gerrit Code Review  ---
Change 2 had a related patch set uploaded by Peter Wu:
6lowpan: fix reassembly for forwarded packets

https://code.wireshark.org/review/2

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #20 from Gerrit Code Review  ---
Change 27761 merged by Anders Broman:
6lowpan: fix reassembly for forwarded packets

https://code.wireshark.org/review/27761

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #19 from sau...@locoslab.com ---
Ah, I've missed that. But I don't think that is an issue of 'wrong'
re-assembly. It seems for all frames that are fragments but have not been
re-assembled, e.g., retransmissions, the context for stateful compression is
not applied to the column addresses. However, the addresses in the detail
window are correct (e.g., Source: fd00:db8::ff:fe00:401).
Looking at the code, I think the reason is in lines 2059ff:

/*
 * Do not set the address columns until after defragmentation, since we
have
 * to do decompression before reassembly, and changing the address will
cause
 * wireshark to think that the middle fragments came from another device.
 */

I assume in the case of re-assembled packets, the column addresses are actually
set by the IPv6 dissector from the reconstructed packet.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #18 from Eduardo Montoya Marín  ---
Well, I can't agree that the re-assembly is not incorrect. Those
00:00:00:ff:fe:00:04:01 and 00:00:00:ff:fe:00:00:00 don't look like something
very right to be shown as source and destination to me. Anyway, I agree that
the Peter's approach is good.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

sau...@locoslab.com changed:

   What|Removed |Added

 CC||sau...@locoslab.com

--- Comment #17 from sau...@locoslab.com ---
As far as I can see, there is no 'incorrect' re-assembly happening here: in
frame 102, the reassembled packet consists of 2 fragments. The fragments are in
the right order and belong to the packet in the sense of matching datagram tag,
etc. The addresses are also correct fd00:db8::ff:fe00:401 ->
fd00:db8::ff:fe00:0. As has been noted, as an external observer in contrast to
the recipient, it is hard to define 'correct' re-assembly, especially in the
multi-hop case. 

I think taking the link-layer destination address into account would make the
re-assembly less surprising and is a good idea, but I would not consider it
'more correct'. I think Peter's patch is a nice implementation.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #16 from Gerrit Code Review  ---
Change 27761 had a related patch set uploaded by Peter Wu:
6lowpan: fix reassembly for forwarded packets

https://code.wireshark.org/review/27761

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #15 from Peter Wu  ---
(In reply to Peter Wu from comment #14)
> To fix reassembly here, I guess it could incorporate the Mesh Destination
> address in the 32-bit reassembly ID (e.g. "(mesh_dest_id << 16) |
> datagram_tag"). Could that work?

Too bad, in this case the 6LoWPAN addresses are the same (not surprising since
these are just being forwarded)... Unconditionally using the link layer address
instead might work though.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #14 from Peter Wu  ---
This problem is also present when capturing from multiple interfaces on an
Ethernet bridge with TCP/IP packets. In that case, packets are wrongly
identified as TCP Out-of-Order/Retransmission/Dup ACK/..., but data is
reassembled correctly due to availability of a sequence number.

To fix reassembly here, I guess it could incorporate the Mesh Destination
address in the 32-bit reassembly ID (e.g. "(mesh_dest_id << 16) |
datagram_tag"). Could that work?

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #13 from Eduardo Montoya Marín  ---
(In reply to Peter Wu from comment #12)
> The datagram tag is already used as ID to group fragments for reassembly,
> see "fragment_add_check" in packet-6lowpan.c. The datagram size should be
> the same for a given tag (unless it is reused), so it might not be more
> useful than the datagram tag.
> 
> Using mesh originator/destination addresses (when available) seems like a
> good idea. Whether to use it in addition or to replace the 802.15.4
> addresses remains an open question (which you can probably answer better
> than I do).
> 
> What I am not sure about, though, is why changing pinfo->dst/src would help
> fixing your original issue. It is not used in the reassembly API
> (epan/reassembly.c), so somehow it is indirectly having some influence
> (perhaps through a "conversation" in the IP dissector?).

Well, maybe my proposed patch is not valid since it might affect other
non-Thread protocols. What I wanted to point out in my previous comment is the
fact that the 6LoWPAN dissector is not taking forwarding into account. My
proposal to solve the wrong reassemblies consists of taking into account the
802.15.4 destination address before assuming several fragments with matching
datagram tag and mesh addresses belong to the same 1-hop datagram.

Maybe a new variable should be added instead of overwriting pinfo->dst, but I
guess I'll leave the coding for someone who is more familiar with the project.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #12 from Peter Wu  ---
The datagram tag is already used as ID to group fragments for reassembly, see
"fragment_add_check" in packet-6lowpan.c. The datagram size should be the same
for a given tag (unless it is reused), so it might not be more useful than the
datagram tag.

Using mesh originator/destination addresses (when available) seems like a good
idea. Whether to use it in addition or to replace the 802.15.4 addresses
remains an open question (which you can probably answer better than I do).

What I am not sure about, though, is why changing pinfo->dst/src would help
fixing your original issue. It is not used in the reassembly API
(epan/reassembly.c), so somehow it is indirectly having some influence (perhaps
through a "conversation" in the IP dissector?).

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #11 from Eduardo Montoya Marín  ---
The only problem I see when matching the 802.15.4 src/dst addresses is the case
when  fragments from the same datagram take different routes, which is a rare
situation but I guess it could happen.

In that case I think fragments could be assembled by the dissector ONLY when
the following parameters match:

- Mesh source address.
- Mesh destination address.
- Datagram size.
- Datagram tag.
- Link destination address.

That would solve the current issue.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #10 from Eduardo Montoya Marín  ---
Probably this issue hasn't arisen before because most implementations do cache
the fragments until the datagram has fully arrived before forwarding them to
the next hop. But there is nothing wrong in forwarding fragments as they
arrive, and currently the dissector gets confused with the forwarded fragments
seen in between the original fragments.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #9 from Eduardo Montoya Marín  ---
That guidance is perfect for the *recipient* of the fragments, the problem
comes for the analyzer of the fragments when multiple hops exist. In that case
the 802.15.4 src/dst addresses should be taken into account as well, in my
opinion.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #8 from Peter Wu  ---
Some guidance from https://tools.ietf.org/html/rfc4944#page-12

> The recipient of link fragments SHALL use (1) the sender's 802.15.4
> source address (or the Originator Address if a Mesh Addressing field
> is present), (2) the destination's 802.15.4 address (or the Final
> Destination address if a Mesh Addressing field is present), (3)
> datagram_size, and (4) datagram_tag to identify all the link
> fragments that belong to a given datagram.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #7 from Peter Wu  ---
Ah, that was some crucial information that I missed. In that case, shouldn't
the mesh src/dst addresses be ignored? Then:
- the 802.15.4 src/dst addresses are the link layer addresses
- the 6LoWPAN src/dst addresses are the network addresses

Search for "hf_6lowpan_source", there are two places where this field is added.
Wouldn't this be a more appropriate "network address"? (And if this is missing,
perhaps then it could fallback to the mesh address.)

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #6 from Eduardo Montoya Marín  ---
The problem here is that the 802.15.4 source and destination are being
overwritten with the mesh header source and destination, which are not the same
when multiple hops are needed.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #5 from Gerrit Code Review  ---
Change 27637 had a related patch set uploaded by Eduardo Montoya Marín:
Remove duplicated spaces

https://code.wireshark.org/review/27637

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #4 from Peter Wu  ---
"pinfo->dst" is documented as being either "pinfo->net_dst" (or if that is
missing, "pinfo->dl_dst"). This works well for IP ("net_dst") over Ethernet
("dl_dst") where the lower layer address (Ethernet address) can be different
when IP packets are routed over different links.

Is this different for 6LoWPAN over IEEE 802.11.5? Are 6LoWPAN packets always
bound to the same 802.15.4 address?

With this proposed change, higher-level protocols that expect "src" to be the
network address might break.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #3 from Eduardo Montoya Marín  ---
Without patch:

   99  81.476524 fd00:db8::ff:fe00:401 → fd00:db8::ff:fe00:0   0x0401 →
0x0400   CoAP0x01 ACK, MID:47368, 2.04 Changed, TKN:5a, /d/dg
  100  81.479714 00:00:00:ff:fe:00:04:01 → 00:00:00:ff:fe:00:00:00   0x0400
→ 0x   6LoWPAN0x01 Data, Dst: 0x, Src: 0x0400
  101  81.483688  →   →  IEEE
802.15.4 Ack
  102  81.485454 fd00:db8::ff:fe00:401 → fd00:db8::ff:fe00:0   0x0401 →
0x0400   CoAP0x01 ACK, MID:47368, 2.04 Changed, TKN:5a, /d/dg
  103  81.487860  →   →  IEEE
802.15.4 Ack
  104  81.491914 00:00:00:ff:fe:00:04:01 → 00:00:00:ff:fe:00:00:00   0x0400
→ 0x   6LoWPAN0x01 Data, Dst: 0x, Src: 0x0400
  105  81.494320  →   →  IEEE
802.15.4 Ack


With patch:

   99  81.476524 fd00:db8::ff:fe00:401 → fd00:db8::ff:fe00:0   0x0401 →
0x0400   CoAP0x01 ACK, MID:47368, 2.04 Changed, TKN:5a, /d/dg
  100  81.479714   0x0400 → 0x 0x0400 → 0x  
6LoWPAN0x01 Data, Dst: 0x, Src: 0x0400
  101  81.483688  →   →  IEEE
802.15.4 Ack
  102  81.485454   0x0401 → 0x0400 0x0401 → 0x0400  
6LoWPAN0x01 Data, Dst: 0x0400, Src: 0x0401
  103  81.487860  →   →  IEEE
802.15.4 Ack
  104  81.491914 fd00:db8::ff:fe00:401 → fd00:db8::ff:fe00:0   0x0400 →
0x   CoAP0x01 ACK, MID:47368, 2.04 Changed, TKN:5a, /d/dg
  105  81.494320  →   →  IEEE
802.15.4 Ack

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

Peter Wu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |IN_PROGRESS
 CC||pe...@lekensteyn.nl
 Ever confirmed|0   |1

--- Comment #2 from Peter Wu  ---
Testing with (without -2V, with -2 and with -V):

tshark -r 6lowpan-dissector-problem.pcap \
  -o6lowpan.context0:fd00:db8::/64 -dudp.port==61631,coap \
  -ouat:ieee802154_keys:'"00112233445566778899aabbccddeeff","1","Thread hash"'

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 14700] 6LoWPAN dissector merges fragments from different sources

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14700

--- Comment #1 from Gerrit Code Review  ---
Change 27630 had a related patch set uploaded by Eduardo Montoya Marín:
dissect_6lowpan_mesh: avoid overwriting src and dst IIDs

https://code.wireshark.org/review/27630

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe