Hex values in Expect
179 views
Skip to first unread message
Pratik Malhotra
Nov 23, 2015, 7:24:47 AM11/23/15
to Android Send/Expect
I am not sure how to regex hex values in expect. I want all of the expected hex data in a single tasker variable then I will manipulate it further.
I am using the tasker plugin.
Any pointer will be greatly appreciated. :)
Thanks
Pratik
David
Nov 23, 2015, 11:23:12 AM11/23/15
to Android Send/Expect
Hello.
Interesting. I don't recall anyone having asked about matching hex data. Looking at my test cases, I see that this is not covered, which usually means that it has bugs (untested code is broken code).
The regex matching is directly from java.util.regex.Pattern so you should be able to use \u and \x to match hex values.
For returning regex matches as Tasker variables see the Tasker section of the help built into Send/Expect, and also look in this forum for topics about setting variables.
I will try over the next few days to add some test cases to Send/Expect for matching binary/hex data.
David
Isaac Asher
Sep 5, 2016, 1:34:44 PM9/5/16
to Android Send/Expect
Have you (or anyone else) found a solution to this? I'm stuck trying to do the same thing myself. I am using the Send/Expect Tasker plugin, so not sure if this is the right place for this post or not. (My apologies if this is not the right place).
I can see in the logs that the "Received buffer contains" some weird ASCII data like "\uff81D$a! uffff" and then a weird box-like character. Then it says "hex bytes:" (the data I'm after!) and it provides a string of hex bytes. The regex I'm using to match is:
(?<test>[A-Fa-f0-9](\s)?)
and the logs show the matched data as an Asian language character followed by a capital "D". When I flash the Tasker variable %test, it shows "D".
It seems to me like the regex is matching the ASCII characters or perhaps not interpreting the results as hex and therefore not storing the proper values.
I have thoroughly tested my regex statement on regexr.com and it works, so I don't believe it's the regex. I am using the named group convention as this is how the plugin correlates with Tasker variables. I know this part works because the value of Tasker variable %test is getting set, it's just not getting the correct values returned from the regex match.
Any ideas?? Many thanks in advance
David
Sep 5, 2016, 6:41:22 PM9/5/16
to Android Send/Expect
On Monday, September 5, 2016 at 10:34:44 AM UTC-7, Isaac Asher wrote:
Have you (or anyone else) found a solution to this? I'm stuck trying to do the same thing myself. I am using the Send/Expect Tasker plugin, so not sure if this is the right place for this post or not. (My apologies if this is not the right place).
This is the right place for Send/Expect questions. Although this one is mostly a regular expression question.
I can see in the logs that the "Received buffer contains" some weird ASCII data like "\uff81D$a! uffff" and then a weird box-like character.
Sorry, the printf portion of the log for binary data is pretty naive.
Then it says "hex bytes:" (the data I'm after!) and it provides a string of hex bytes.
This part should be the exact bytes received.
The regex I'm using to match is:(?<test>[A-Fa-f0-9](\s)?)and the logs show the matched data as an Asian language character followed by a capital "D". When I flash the Tasker variable %test, it shows "D".It seems to me like the regex is matching the ASCII characters or perhaps not interpreting the results as hex and therefore not storing the proper values.I have thoroughly tested my regex statement on regexr.com and it works, so I don't believe it's the regex.
Did you test your RE with binary data? It is saying match one of the following ASCII characters ABCDEFabcdef0123456789 followed by 0 or more spaces. So this will only match if the binary data is the hex value for one of those ASCII characters (e.g. A == 0x41)
Matching binary with regular expressions is not generally done, but since you are asking how to do this with Send/Expect I would google for things like:
Isaac Asher
Sep 5, 2016, 8:17:18 PM9/5/16
to Android Send/Expect
Glad I'm in the right place and thank you David for your help!
To continue:
The regex I'm using to match is:(?<test>[A-Fa-f0-9](\s)?)
Did you test your RE with binary data?
The exact string I was expecting to receive is this:
81 44 24 61 21 01 00 00 00 FF 05 00 0F 7F (confirmed using another packet sender software)
So that is the exact string I used when testing my RE on regexr.com and I was able to successfully select all the bytes and any trailing space.
The string appearing in the "hex bytes" section of the Expect was this:
EF BE 81 44 24 61 21 01 00 00 00 EF BF BF
I figured the difference in the data was a bug for a later time, but perhaps it is more significant than I realized. Regardless, all I get back from the RE output is "D".
Does this perhaps mean anything to anyone?
David
Sep 5, 2016, 9:32:38 PM9/5/16
to Android Send/Expect
On Monday, September 5, 2016 at 5:17:18 PM UTC-7, Isaac Asher wrote:
Glad I'm in the right place and thank you David for your help!To continue:The regex I'm using to match is:(?<test>[A-Fa-f0-9](\s)?)Did you test your RE with binary data?The exact string I was expecting to receive is this:81 44 24 61 21 01 00 00 00 FF 05 00 0F 7F (confirmed using another packet sender software)So that is the exact string I used when testing my RE on regexr.com and I was able to successfully select all the bytes and any trailing space.
We may have some confusion in terms and data representation here. My point earlier is that your RE is looking for the ASCII characters A, B, C, etc...
But you seem to be talking about a binary (non-ascii characters) data stream. So what do you mean the by "exact string ..." that starts with "81 " ? Does that mean the ASCII character 8, followed by the ACSII character 1, or do you mean a single byte with the value 0x81?
Can you post a Send/Expect log file? Or send one directly to me (via the sharing icon from the log viewer)?
David
Isaac Asher
Sep 5, 2016, 10:42:18 PM9/5/16
to Android Send/Expect
Oh that makes sense! And you are correct. To answer your example question, by "81 " I really mean 0x81. Should this be expressed differently in the RE?
Here is the Send/Expect log file:
[
{
"timestamp": 0,
"recordType": "Start",
"recordData": "Tasker"
},
{
"timestamp": 0,
"recordType": "Version",
"recordData": "2000051"
},
{
"timestamp": 0,
"recordType": "Send/Expect Data",
"recordData": "Timeout seconds: 2\nSend (original): \\x81\\x8A\\x8B\\x96\nSend (variables replaced): \\x81\\x8A\\x8B\\x96\nExpect: (?<test>[A-Fa-f0-9](\\s)?)\n"
},
{
"timestamp": 1,
"recordType": "Connection Started",
"recordData": "10.0.0.9:5577"
},
{
"timestamp": 129,
"recordType": "Connection Completed",
"recordData": "10.0.0.9:5577"
},
{
"timestamp": 129,
"recordType": "Send",
"recordData": "\\x81\\x8A\\x8B\\x96"
},
{
"timestamp": 129,
"recordType": "Data Sent",
"recordData": null
},
{
"timestamp": 129,
"recordType": "Expect",
"recordData": "([A-Fa-f0-9](\\s)?)"
},
{
"timestamp": 129,
"recordType": "Received Buffer Contains",
"recordData": ""
},
{
"timestamp": 152,
"recordType": "Received Bytes",
"recordData": "14"
},
{
"timestamp": 152,
"recordType": "Received Buffer Contains",
"recordData": "ﾁD$a!\u0001\u0000\u0000\u0000�\u0005\u0000\u000f "
},
{
"timestamp": 153,
"recordType": "Expect Matched",
"recordData": "ﾁD"
},
{
"timestamp": 153,
"recordType": "Capture Group",
"recordData": "testmatched D"
},
{
"timestamp": 153,
"recordType": "Capture Group",
"recordData": "unnamedmatched null"
},
{
"timestamp": 153,
"recordType": "Disconnect",
"recordData": null
},
{
"timestamp": 153,
"recordType": "Set Tasker Variable",
"recordData": "%test = D"
},
{
"timestamp": 153,
"recordType": "Succeeded",
"recordData": null
}
]
David
Sep 11, 2016, 9:40:36 PM9/11/16
to Android Send/Expect
On Monday, September 5, 2016 at 7:42:18 PM UTC-7, Isaac Asher wrote:
Oh that makes sense! And you are correct. To answer your example question, by "81 " I really mean 0x81. Should this be expressed differently in the RE?
Yes.
To match 0x81, you would want a regular expression of \x81
To match any byte, you want a regular expression of .
Isaac Asher
Sep 12, 2016, 11:11:18 PM9/12/16
to Android Send/Expect
When I use a dot-plus RE to match any bytes, what I get back in the expect is that same foreign language character I mentioned earlier, then "D#a! ~". However, when I send the exact same hex info by Packet Sender on my PC, the response is a series of hex bytes as it should be. It seems the response isn't being translated correctly or something?
Any ideas?
Isaac Asher
Sep 19, 2016, 11:57:55 PM9/19/16
to Android Send/Expect
I found I can use [[:xdigits:]] to match hex bytes and included that in my Expect and got slightly different results, although it's still not capturing the hex bytes as I would expect.
Here is an updated log after using the different RE as mentioned above:
[
{
"timestamp": 0,
"recordType": "Start",
"recordData": "Tasker"
},
{
"timestamp": 0,
"recordType": "Version",
"recordData": "2000051"
},
{
"timestamp": 1,
"recordType": "Send/Expect Data",
"recordData": "Timeout seconds: 2\nSend (original): \\x81\\x8A\\x8B\\x96\nSend (variables replaced): \\x81\\x8A\\x8B\\x96\nExpect: (?<test>[[:xdigit:]].+)\n"
"timestamp": 69,
"timestamp": 69,
"recordType": "Send",
"recordData": "\\x81\\x8A\\x8B\\x96"
},
{
"timestamp": 69,
"recordType": "Data Sent",
"recordData": null
},
{
"timestamp": 70,
"recordType": "Expect",
"recordData": "([[:xdigit:]].+)"
},
{
"timestamp": 70,
"recordType": "Received Buffer Contains",
"recordData": ""
},
{
"timestamp": 108,
"recordType": "Received Bytes",
"recordData": "14"
},
{
"timestamp": 108,
"recordType": "Received Buffer Contains",
"recordData": "ﾁD#a!\u0001\u0000\u0000\u0000�\u0005\u0000\u000f~"
},
{
"timestamp": 108,
"recordType": "Expect Matched",
"recordData": "ﾁD#a!\u0001\u0000\u0000\u0000�\u0005\u0000\u000f~"
},
{
"timestamp": 109,
"recordType": "Capture Group",
"recordData": "testmatched D#a!\u0001\u0000\u0000\u0000�\u0005\u0000\u000f~"
},
{
"timestamp": 109,
"recordType": "Disconnect",
"recordData": null
},
{
"timestamp": 109,
"recordType": "Set Tasker Variable",
"recordData": "%test = D#a!\u0001\u0000\u0000\u0000�\u0005\u0000\u000f~"
},
{
"timestamp": 109,
Reply all
Reply to author
Forward
0 new messages