I'm trying to capture TCP packets related to some type of bug I'm finding when using a Wiznet W5300. It seems to freeze up sometimes when the TCP sequence number is near the rollover point of 0xFFFFFFFF. I'm trying to capture packets near the rollover only, say within 5000 bytes before or after, because the total amount of data that moves before the bug hits is way too much. I have 4 units running with IP addresses of .52 through .55 When I use this filter expression: ((ip[15] >= 52 and ip[15] <= 55) or (ip[19] >= 52 and ip[19] <= 55)) and ((tcp[4:4] < 0x00001388)) it shows the following compilation: (000) ldh [12] (001) jeq #0x800 jt 2 jf 16 (002) ldb [29] (003) jge #0x34 jt 4 jf 5 (004) jgt #0x37 jt 5 jf 8 (005) ldb [33] (006) jge #0x34 jt 7 jf 16 (007) jgt #0x37 jt 16 jf 8 (008) ldb [23] (009) jeq #0x6 jt 10 jf 16 (010) ldh [20] (011) jset #0x1fff jt 16 jf 12 (012) ldxb 4*([14]&0xf) (013) ld [x + 18] (014) jge #0x1388 jt 16 jf 15 (015) ret #65535 (016) ret #0 and it seems to correctly filter out the typical messages that do not have sequence numbers from 0 to 5000. However, when I use the filter I actually want with the additional constraint to get the high end of the sequence numbers as well: ((ip[15] >= 52 and ip[15] <= 55) or (ip[19] >= 52 and ip[19] <= 55)) and ((tcp[4:4] < 0x00001388) or (tcp[4:4] > 0xFFFFEC77)) I get the following compilation: (000) ldh [12] (001) jeq #0x800 jt 2 jf 17 (002) ldb [29] (003) jge #0x34 jt 4 jf 5 (004) jgt #0x37 jt 5 jf 8 (005) ldb [33] (006) jge #0x34 jt 7 jf 17 (007) jgt #0x37 jt 17 jf 8 (008) ldb [23] (009) jeq #0x6 jt 10 jf 17 (010) ldh [20] (011) jset #0x1fff jt 17 jf 12 (012) ldxb 4*([14]&0xf) (013) ld [x + 18] (014) jge #0x1388 jt 15 jf 16 (015) jgt #0xffffec77 jt 16 jf 17 (016) ret #65535 (017) ret #0 which seems reasonable, but it doesn't work. It captures all packets that are not in the sequence number range I want. Does anyone see a logic error or a numeric/sign type error? Wireshark is pretty new for me. Thanks. asked 17 Nov '15, 07:56  eeabe |
One Answer:
I was able to get it working by switching to 16 bit comparisons, and using < and >: ((ip[15] >= 52 and ip[15] <= 55) or (ip[19] >= 52 and ip[19] <= 55)) and ((tcp[4:2] < 0x0001) or (tcp[4:2] > 0xFFFE) or (tcp[8:2] < 0x0001) or (tcp[8:2] > 0xFFFE)) Maybe there is a bug with 32 bit comparisons, or with the >= or <=. I'm up and running for now. Thank you for the great hint sindy. answered 17 Nov '15, 10:03 eeabe |
I don't dare to call it an Answer (yet), but in order to check whether it is a sign issue, please try to split
tcp[4:4] > 0xFFFFEC77intotcp[4:2] = 0xFFFF and tcp[6:2] > 0x7fff(you should get slightly more packets than with your original value of 0xec77 but you'll be sure whether the highest bit is evaluated as sign bit or not).Smart idea. I tried it and it still captures undesired packets. I should have also noted that the high end constraint, (tcp[4:4] > 0xFFFFEC77), seems to work fine by itself. It's only when I try to "or" the low and high end constraints together that everything gets through the filter.
I also just tried: ((ip[15] >= 52 and ip[15] <= 55) or (ip[19] >= 52 and ip[19] <= 55)) and ((tcp[4:4] < 0x00001388) or (tcp[4:2] == 0xFFFF))
Just adding the or (tcp[4:2] == 0xFFFF) term causes all the packets to be let through. Again, the compilation seems logical but doesn't seem to work.