Regexp oddity: DHCP

dennismtaylor · August 11, 2012, 4:08am

This isn’t causing me any real problems, but it’s a head-scratcher.

RouterOS V5.14 and later (perhaps others): Of the following two layer 7 regexes, the first matches DHCP packets, while the second does not:

^[1][\01-\20]\06.c\82sc. (match)
^[2][\01-\20]\06.c\82Sc. (no match)

The difference is in the “magic cookie” at the end–specifically, as shown, lowercase s vs. uppercase S. When implemented as a Layer 7 Protocol regexp, the second expression should match DHCP packets, with the proper magic cookie value of 99.130.83.99, but it does not. However, the first expression does match, when it should not.

Here’s a sample DHCP packet:

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 … …E.
0010 01 48 00 00 00 00 10 11 ce 16 c0 a8 2d 01 c0 a8 .H… …-…
0020 2d 3d 00 43 00 44 01 34 3d a6 02 01 06 00 d1 7e -=.C.D.4 =…~
0030 2f 21 00 00 00 00 00 00 00 00 c0 a8 2d 3d c0 a8 /!.. …-=..
0040 2d 01 00 00 00 00 60 fa cd 8a 04 0f 00 00 00 00 -…`. …
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0110 00 00 00 00 00 00 63 82 53 63 35 01 05 36 04 c0 …c. Sc5..6..
0120 a8 2d 01 33 04 00 03 f4 80 01 04 ff ff ff 00 03 .-.3… …
0130 04 c0 a8 2d 01 06 08 45 36 b1 3e 45 36 a1 3e ff …-…E 6.>E6.>.
0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 … …
0150 00 00 00 00 00 00 …

So, why does the “incorrect” regexp match, while the “correct” one does not?

What am I missing, here?

\01\02 ↩︎
\01\02 ↩︎

greencomputing · August 12, 2012, 4:37pm

Hi there
I repeated your test using the hex representation of the literals S,s,c and I confirm what you had.

In my opinion there is a swap in the code between ‘S’ (upper case ) and ‘s’ (lower case).

ASCII encoding says that :

hex_value('s')=0x73

hex_value('S')=0x53

while on RouterOS , if you write expression like ^[1][\x01-\x20]\x06.*c\x82\x73\x63

it will match 0x63 0x82 0x53 0x63 (as you said the magic cookie used for dhcp )

while using the ^[2][\x01-\x20]\x06.*c\x82\x53\x63 will not match that cookie.

On the other end is interesting to see that the “official” netfilter definiton pattern used for dhcp is :

^[\x01\x02][\x01- ]\x06.*c\x82sc

as defined in http://l7-filter.sourceforge.net/layer7-protocols/protocols/dhcp.pat

where they use the sequence “sc” and NOT “Sc” as we expect according to rfc 2132
http://www.ietf.org/rfc/rfc2132.txt where the magic cookie is defined exactlya as you reported :

This field identifies the mode in which the succeeding data is
to be interpreted. The value of the magic cookie is the 4 octet
dotted decimal 99.130.83.99 (or hexadecimal number 63.82.53.63) in
network byte order.

Now if we are right and no other kind of encoding are in use, that we do not know, this means that the RoS behaviour is not correct on this pattern and others containing the literal ‘s’ (0x73) . In this case I think a bug could be raised .

On the other hand if the behaviour will be fixed , we will have a lot of mikoritk board using l7-filters for dhcp that will need to fix configurations. but this is another story.

Hoping the issue will be clairfied by mikrotik experts.

Have a nice day

\x01\x02 ↩︎
\x01\x02 ↩︎