If the URG flag is set to zero, then the urgent pointer field is disabled. In that case, why is the value of the urgent pointer field not displayed in Wireshark? asked 13 Aug '13, 14:19  HiB edited 13 Aug '13, 14:37  cmaynard ♦♦ |
One Answer:
The urgent pointer field is only meaningful if the URG flag is set; otherwise the two bytes are essentially meaningless. If Wireshark were to display those 2 bytes as if there were an actual urgent pointer even though the URG flag was not set, then potentially packets that should not match a particular display filter would be incorrectly displayed. For example, suppose you are interested in all packets containing an urgent pointer set to some specific value, say 0x1234, then you might use the following display filter to isolate them: If there happened to be TCP packets with the URG flag cleared yet the bytes where the urgent pointer would be represented happened to contain those same values, then the packet would incorrectly match the filter. Interestingly, Wireshark currently does display the tcp.urgent_pointer field, even if the URG Flag isn't set, if the value of the tcp.urgent_pointer is non-zero. An expert info warning is even reported in such cases indicating, "Broken TCP. The urgent pointer field is nonzero while the URG flag is not set". Apparently this was done with the understanding that this field should be zero when the URG flag isn't set, but as Guy Harris noted in the earlier discussion, there actually doesn't appear to be any requirement for the urgent pointer field to be zero when the URG flag is not set. We might consider removing that expert info warning, or at least changing it from a warning to a note with different wording, in particular removing the "Broken TCP" portion of the message. answered 13 Aug '13, 15:09 cmaynard ♦♦ edited 13 Aug '13, 15:12 showing 5 of 11 show 6 more comments |
why would a packet incorrectly match if it has an urgent_pointer 0x1234 and URG flag is zero? for me not displaying urgent pointer value in this case is a bug - since 0x0000 is part of the packet, as 0x1234 would be - so in both case wireshark should display it with a note as you suggested.
The field is only an urgent pointer if the URG flag is set. If the URG flag isn't set, it's just arbitrary data that happens to reside in the location where the urgent pointer would be if the URG flag was set. To treat those 2 bytes as an urgent pointer when the URG flag is not set would be wrong.
But if you're interested in searching for a particular value of those 2 bytes (again, using 0x1234 as an example) regardless of whether the URG flag is set or not, you can use a display filter such as follows:
I agree with rewording the expert info warning to a note, but if a field is present in a packet, I'd like Wireshark to display it, whether the contents are meaningful or not. Same for the ACK field in the first packet of the three-way handshake. Wireshark does not display it because the ACK bit is not set, but it is still present in the packet. As you click on fields in the Packet Details pane, you can see Wireshark skip over a block of bytes in the Packet Bytes pane.
Perhaps a good solution would be for Wireshark to always display the Urgent Pointer field, but with "(Urgent flag not set)" shown next to it when appropriate, and to always display the Ack field, but with "(ACK flag not set)" shown when appropriate.
Maybe playing with semantics, but to me there is a difference between a field and some bytes in the packet.
A field should only be present and dissected if it is deemed present by the dissector as in this case by the flag.
The bytes may still be in the packet and can be seen in the packet bytes, but according to the protocol description the field is to be disregarded.
Regarding the urgent pointer field, to reiterate again from RFC793: This field is only [to] be interpreted in segments with the URG control bit set.
FYI ... I removed the expert info messages relating to both the urgent pointer and acknowledgment number fields in r51356. IMO, the ack field should not be added either when the ACK bit isn't set. I haven't made that change though ... at least not yet.
so now tcp.urgent_pointer filter is valid only if URG bit is set? I havent seen such case earlier when a filter depended on something. then please create another filter name like tcp.urgent_pointer_octets which would work in every case - like the filter tcp[18:2] you suggested. by the way I am working with pdml files - in pdml there are a lot of hidden fields - in this case urgent_pointer field could be a hidden one - without it, there is no any info about those 2 octets - so the packet cannot be reproduced correctly even if these octets have no meanings. what do you think? and thanks for the commit!
"so now tcp.urgent_pointer filter is valid only if URG bit is set?"
Well, the filter is always valid, but the current behavior is that only those packets where the URG bit is set will match the filter. This is currently inconsistent behavior with other fields, for example the Acknowledgment Number field as I alluded to in the commit message. I believe another change should be made for consistency. More on that below ...
"I haven't seen such case earlier when a filter depended on something."
I'm sure there are other examples within the thousands of Wireshark dissectors.
then please create another filter name like tcp.urgent_pointer_octets which would work in every case - like the filter tcp[18:2] you suggested. by the way I am working with pdml files - in pdml there are a lot of hidden fields - in this case urgent_pointer field could be a hidden one - without it, there is no any info about those 2 octets - so the packet cannot be reproduced correctly even if these octets have no meanings. what do you think?
Wireshark does not assign fields to every byte within a packet, so you will never be able to reliably reproduce a packet from purely pdml. You can only do it from the raw bytes themselves.
I'm not in favor of adding a tcp.urgent_pointer_octets field. But as I mentioned above, I do recognize an inconsistency so I think something should change. My thoughts:
The 1st option means both the acknowledgment number and urgent pointer fields will only be present/match filters in TCP packets where the ACK or URG bit is set, respectively. The implication is that a user would not be able to see as easily the values contained within the space reserved for those fields in packets where the respective bit isn't set. Does this matter though?
The 2nd option means that both fields will always be present and it will be the responsibility of the user interested in either of those 2 fields to be aware that those values only really mean something if the respective bit is set, somewhat analogous to a "container" that's present, but whose contents is only valid if another field says it is.
Number 1 (the acknowledgment number field is only added if the ACK bit is set) is current behavior.
In my comment above, I was in favor of #2. As I think about this more, I'm not sure that's the best approach, and I'm beginning to favor #1. I think I'll sit firmly on the fence and leave this to whatever consensus emerges.
"Number 1 (the acknowledgment number field is only added if the ACK bit is set) is current behavior."
I stand corrected. I merely removed the expert info warnings for non-zero acknowledgment numbers or urgent pointers when their respective ACK or URG bit wasn't set. I thought I had made another change too, but I only made it in my head apparently.
So #2 is the current behavior then, as can be seen if you apply the following display filters:
What #1 proposes is to only add the tcp.ack field if the tcp.flags.ack field is 1 and similarly for the urgent pointer filed. I'm inclined to leave things as they are now, especically since that seems to be the desire from OP anyway, and it's probably what everyone is used to.
I think at least some of the confusion comes from the fact that the behavior must have changed since the post that OP references in the original question. So what version of Wireshark is OP running where the urgent pointer isn't displayed when the URG bit isn't set?
Oh good god. Yes, I DID make the change so that the urgent pointer is always displayed just like the ack field is always displayed, irrespective of the flags. So the behavior is as described in #2 and it is currently consistent between them. Whether that's the expected behavior or not is another matter, but I'm still inclined to leave things as they are now. If some other developer disagrees, I don't have a problem with the change.