<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
	<channel>
		<title>Mikrotik.moscow [тема: Регулярное выражение – странность: DHCP]</title>
		<link>http://mikrotik.moscow</link>
		<description>Новое в теме Регулярное выражение – странность: DHCP форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow]</description>
		<language>ru</language>
		<docs>http://backend.userland.com/rss2</docs>
		<pubDate>Fri, 21 Aug 2026 19:30:02 -0400</pubDate>
		<item>
			<title>Регулярное выражение – странность: DHCP</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/59608-regulyarnoe-vyrazhenie-_-strannost_-dhcp/message226551">Регулярное выражение – странность: DHCP</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Привет! Я повторил твой тест, используя шестнадцатеричное представление литералов S, s, c, и подтверждаю то, что у тебя получилось. По-моему, в коде произошла перестановка между ‘S’ (заглавная) и ‘s’ (строчная). ASCII кодировка говорит, что: hex_value('s')=0x73<br /><br />hex_value('S')=0x53, в то время как в RouterOS, если ты пишешь выражение вроде [1] [\x01-\x20]\x06.*c\x82\x73\x63, оно будет соответствовать 0x63 0x82 0x53 0x63 (как ты и сказал, это "magic cookie", используемый для dhcp), а использование [2] [\x01-\x20]\x06.*c\x82\x53\x63 этого cookie не совпадет. С другой стороны, интересно, что “официальное” определение netfilter pattern, используемое для dhcp, выглядит так: ^[\x01\x02][\x01- ]\x06.*c\x82sc, как определено в <noindex><a href="http://l7-filter.sourceforge.net/layer7-protocols/protocols/dhcp.pat" target="_blank" rel="nofollow" >http://l7-filter.sourceforge.net/layer7-protocols/protocols/dhcp.pat</a></noindex>, где используют последовательность “sc”, а не “Sc”, как мы ожидаем, согласно rfc 2132 <noindex><a href="http://www.ietf.org/rfc/rfc2132.txt" target="_blank" rel="nofollow" >http://www.ietf.org/rfc/rfc2132.txt</a></noindex>, где magic cookie определен точно, как ты сообщил: 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. Теперь, если мы правы и никаких других видов кодировки не используются, которые мы не знаем, это означает, что поведение RoS некорректно в этом pattern и в других, содержащих литерал ‘s’ (0x73). В этом случае, я думаю, стоит поднять баг. С другой стороны, если поведение будет исправлено, у нас будет много mikrotik board, использующих l7-фильтры для dhcp, которые потребуют исправить конфигурации. Но это уже другая история. Надеюсь, этот вопрос будет прояснен экспертами Mikrotik. Хорошего дня \x01\x02 ↩︎ \x01\x02 ↩︎ <br />
			<i>12.08.2012 16:37:00, greencomputing.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/59608-regulyarnoe-vyrazhenie-_-strannost_-dhcp/message226551</link>
			<guid>http://mikrotik.moscow/forum/forum57/59608-regulyarnoe-vyrazhenie-_-strannost_-dhcp/message226551</guid>
			<pubDate>Sun, 12 Aug 2012 16:37:00 -0400</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Регулярное выражение – странность: DHCP</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/59608-regulyarnoe-vyrazhenie-_-strannost_-dhcp/message226550">Регулярное выражение – странность: DHCP</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Это не вызывает у меня реальных проблем, но это заставляет задуматься. RouterOS V5.14 и более поздние версии (возможно, и другие): из следующих двух регулярных выражений уровня 7 первое соответствует пакетам DHCP, а второе — нет:<br /><br />[1] [\01-\20]\06. c\82sc. (совпадает)<br />[2] [\01-\20]\06. c\82Sc. (не совпадает)<br /><br />Разница в "magic cookie" в конце — конкретно, как показано, строчная s против заглавной S. Когда реализовано как регулярное выражение протокола уровня 7, второе выражение должно совпадать с пакетами DHCP с правильным значением "magic cookie" 99.130.83.99, но этого не происходит. Однако первое выражение совпадает, хотя и не должно. Вот пример пакета DHCP:<br /><br />0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00<br />… …E.<br />0010 01 48 00 00 00 00 10 11 ce 16 c0 a8 2d 01 c0 a8<br />.H… …-…<br />0020 -d=00 43 00 44 01 34 d= a6 02 01 06 00 d1 7e<br />-=.C.D.4 =…~<br />0030 /!00 00 00 00 00 00 00 00 c0 a8 2d 3d c0 a8<br />/!.. …-=..<br />0040 - 01 00 00 00 00 60 fa cd 8a 04 0f 00 00 00 00<br />-…`. …<br />0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />0110 00 00 00 00 00 00 63 82 53 63 35 01 05 36 04 c0<br />…c. Sc5..6..<br />0120 a8 2d 01 33 04 00 03 f4 80 01 04 ff ff ff 00 03<br />.-.3… …<br />0130 04 c0 a8 2d 01 06 08 45 36 b1 3e 45 36 a1 3e ff<br />…-…E 6.&gt;E6.&gt;.<br />0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />… …<br />0150 00 00 00 00 00 00<br /><br />So, why does the “incorrect” regexp match, while the “correct” one does not? What am I missing, here? \01\02 ↩︎ \01\02 ↩︎ <br />
			<i>11.08.2012 04:08:00, dennismtaylor.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/59608-regulyarnoe-vyrazhenie-_-strannost_-dhcp/message226550</link>
			<guid>http://mikrotik.moscow/forum/forum57/59608-regulyarnoe-vyrazhenie-_-strannost_-dhcp/message226550</guid>
			<pubDate>Sat, 11 Aug 2012 04:08:00 -0400</pubDate>
			<category>RouterOS</category>
		</item>
	</channel>
</rss>
