Substract first occurency from char* - arduino

I have this code on esp32 which get the return of command from an obd adapter
if (receive(buffer, sizeof(buffer)) > 0) {
char *p = buffer;
Serial.print("3 - p:");
Serial.println(p);
Serial.print("31 - size of p : ");
Serial.println(strlen(p));
p = strstr(p, "43 ");
Serial.print("32 - p:");
Serial.println(p);
}
My goal is to substract the first 3 chars "43 " from the buffer
And this is what I get in serial
3 - p:43 01 33 03 01 00 00
>
31 - size of p : 23
32 - p:43 01 33 03 01 00 00
>
33 - size of p : 23
How should I proceed to substract the first "43 " from the buffer ?
Thanks

If you just add an offset to the buffer pointer, so you're in effect skipping three characters, you should be fine:
if (receive(buffer, sizeof(buffer)) > 0) {
char *p = buffer+3;
Serial.print("3 - p:");
Serial.println(p);
}
This should print
3 - p:01 33 03 01 00 00
Is this what you want?

You can use strstr to check if buffer really contains (or starts with) "43 "
If it does, the returned pointer is set to the begin of "43 "
p+3 would point to the characters following "43 ", if this is what you call "subtracting".
If there's no "43 " in buffer, p is NULL, and p+3 points anywhere. Have fun.

Related

How could I determine this checksum pattern?

Let's assume that I have 512-byte packets plus a 16-bit CRC at the end. I would like to determine what the CRC parameters are.
It's a Fujitsu chip, where I'm writing the the flash with a programmer, the programmer calculates the CRC for me, and I read out the CRC with an oscilloscope. I have the ability to check every possible combination.
My test messages are 512 zeros except for one byte that I set to the values 0 to 17 in decimal. The one byte is one of the first four or last two in the packet. Here are the resulting CRCs in hexadecimal, where the rows are the value of the byte, and the columns are which byte is set:
00 01 02 03 510 511
00 00 00 00 00 00 00
01 0x8108 0x0100 0x3020 0xC6B0 0xF1F0 0x8108
02 0x8318 0x0200 0x6040 0x0C68 0x62E8 0x8318
03 0x0210 0x0300 0x5060 0xCAD8 0x9318 0x0210
04 0x8738 0x0400 0xC080 0x18D0 0xC5D0 0x8738
05 0x0630 0x0500 0xF0A0 0xDE60 0x3420 0x0630
06 0x0420 0x0600 0xA0C0 0x14B8 0xA738 0x0420
07 0x8528 0x0700 0x90E0 0xD208 0x56C8 0x8528
08 0x8F78 0x0800 0x0008 0x31A0 0x0AA8 0x8F78
09 0x0E70 0x0900 0x3028 0xF710 0xFB58 0x0E70
10 0x0C60 0x0A00 0x6048 0x3DC8 0x6840 0x0C60
11 0x8D68 0x0B00 0x5068 0xFB78 0x99B0 0x8D68
12 0x0840 0x0C00 0xC088 0x2970 0xCF78 0x0840
13 0x8948 0x0D00 0xF0A8 0xEFC0 0x3E88 0x8948
14 0x8B58 0x0E00 0xA0C8 0x2518 0xAD90 0x8B58
15 0x0A50 0x0F00 0x90E8 0xE3A8 0x5C60 0x0A50
16 0x9FF8 0x1000 0x0010 0x6340 0x1550 0x9FF8
17 0x1EF0 0x1100 0x3030 0xA5F0 0xE4A0 0x1EF0
As you can see the first and last bytes give the same value. I tried several variations of CRC-16, but without much luck. The closet one was CRC-16 with polynomial 0x1021 and initial value 0.
The fact that every single CRC ends in 0 or 8 strongly suggests that it is not a 16-bit CRC, but rather a 13-bit CRC. Indeed, all of the sequences check against a 13-bit CRC with polynomial 0x1021 not reflected, initial value zero, and final exclusive-or zero.
We can't be sure about the initial value and final exclusive-or unless you can provide at least one packet with a length other than 512. With only examples of a single length, there are 8,191 other combinations of initial values and final exclusive-ors that would produce the exact same CRCs.

Decode Epson print (ESC-i) command decoding/encoding

I'm trying to understand the algorithm used for compression value = 1 with the Epson ESCP2 print command, "ESC-i". I have a hex dump of a raw print file which looks, in part, like the hexdump below (note little-endian format issues).
000006a 1b ( U 05 00 08 08 08 40 0b
units; (page1=08), (vt1=08), (hz1=08), (base2=40 0b=0xb40=2880)
...
00000c0 691b 0112 6802 0101 de00
esc i 12 01 02 68 01 01 00
print color1, compress1, bits1, bytes2, lines2, data...
color1 = 0x12 = 18 = light cyan
compress1 = 1
bits1 (bits/pixel) = 0x2 = 2
bytes2 is ??? = 0x0168 = 360
lines2 is # lines to print = 0x0001 = 1
00000c9 de 1200 9a05 6959
00000d0 5999 a565 5999 6566 5996 9695 655a fd56
00000e0 1f66 9a59 6656 6566 5996 9665 9659 6666
00000f0 6559 9999 9565 6695 9965 a665 6666 6969
0000100 5566 95fe 9919 6596 5996 5696 9666 665a
0000110 5956 6669 0456 1044 0041 4110 0040 8140
0000120 9000 0d00
1b0c 1b40 5228 0008 5200 4d45
FF esc # esc ( R 00 REMOTE1
The difficulty I'm having is how to decode the data, starting at 00000c9, given 2 bits/pixel and the count of 360. It's my understanding this is some form of tiff or rle encoding, but I can't decode it in a way that makes sense. The output was produced by gutenprint plugin for GIMP.
Any help would be much appreciated.
The byte count is not a count of the bytes in the input stream; it is a count of the bytes in the input stream as expanded to an uncompressed form. So when expanded, there should be a total of 360 bytes. The input bytes are interpreted as either a count of bytes to follow, if positive, in which case the count is the byte value +1; and if negative the count is a count of the number of times the immediately following byte should be expanded, again, +1. The 0D at the end is a terminating carriage return for the line as a whole.
The input stream is only considered as a string of whole bytes, despite the fact that the individual pixel/nozzle controls are only 2 bits each. So it is not really possible to use a repeat count for something like a 3-nozzle sequence; a repeat count must always specify a full byte 4-nozzle combination.
The above example then specifies:
0xde00 => repeat 0x00 35 times
0x12 => use the next 19 bytes as is
0xfd66 => repeat 0x66 4 times
0x1f => use the next 32 bytes as is
etc.

q{} removing spaces in a raku map

This Raku expression converts color codes from RGB to HEX:
raku -e 'my #array = (0, 255, 0), { #^a «+» (25.5, -25.5, 0) } ... ( * ~~ (255, 0, 0 ) );
say #array.map: "#" ~ *.fmt: "%02X"'
(#00 FF 00 #19 E5 00 #33 CC 00 #4C B2 00 #66 99 00 #7F 7F 00 #99 66 00 #B2 4C 00 #CC 33 00 #E5 19 00 #FF 00 00)
Adding q{} to the expression removes spaces:
raku -e 'my #array = (0, 255, 0), { #^a «+» (25.5, -25.5, 0) } ... ( * ~~ (255, 0, 0 ) );
say #array.map: "#" ~ *.fmt: "%02X", q{}'
(#00FF00 #19E500 #33CC00 #4CB200 #669900 #7F7F00 #996600 #B24C00 #CC3300 #E51900 #FF0000)
I have not been able to figure out why adding 'q{}' to the expression removes spaces. I would aprreciate any hint on this issue. Thanks.
Per the doc for .fmt applied to a List, the routine's signature is:
method fmt($format = '%s', $separator = ' ' --> Str:D)
▲▲▲ - default separator
So, by default, each three element List like (0, 255, 0) will turn into three formatted elements separated by a space when you don't specify the separator, but unseparated when you specify a null string as the specifier.
q{} is a string (using the Q lang) that specifies a null string (ie it's the same as '').
Hence the result you're seeing.

Getting an error while trying to send SS command using USAT application

I'm trying to have a USIM perform call forwarding (a.k.a call redirection) using the proactive command SEND SS (TS 31.111 sections: 6.4.11, 8.14, etc.). Unfortunately I keep getting an error from the network which I can't understand.
I'm trying the following sequence:
ME->USIM: 8012000018 (FETCH from the ME toward UICC)
USIM->ME: 12 (procedure byte)
USIM->ME: D01681030411008202818305000909FFAA120A25556777B49000
D0 (proactive command) 16 (length)
81 (command details) 03 (length) 04 (command number) 11 (SEND SS) 00 (RFU)
82 (device identities) 02 (length) 81 (UICC) 83 (network)
05 (alpha identifier) 00 (length)
909FFAA120A25556777B4 (SS String = **21*0525576774#)
9000 (OK)
ME->USIM: 801400000D (Terminal response of size 0x0D)
USIM->ME: 14 (procedure byte)
ME->USIM: 81030411000202828103023424
81 (command details) 03 (length) 04 (command number) 11 (SEND SS) 00 (RFU)
02 (device identities) 02 (length) 82 (ME) 81 (UICC)
03 (Result) 02 (length) 34 (SS Return Error) 24 (???)
I can't figure out what '24' means.
Just to make sure I'm using a correct SS string, I activated CALL CONTROL on the USIM and dialed **21*0525576774# in the keypad. The result was as follows:
ME->UICC: 80C200001C (Envelope of length 0x1C)
UICC->ME: C2 (procedure byte)
ME->UICC: D41A020282810909FFAA120A25556777B4130924F51027D078CF0013
D4 (envelope) 1A (length)
02 (device identities) 02 (length) 82 (ME) 81 (UICC)
09 (send ss) 09 (length) FFAA120A25556777B4 (SS string)
13 (location information) 09 (length) 24F51027D078CF0013 (not relevant)
USIM->ME: 9000 (OK)
As you can see, the SS string is identical. When the ME sends it it seems to work (call forwarding is activated) yet when I try to send it from the UICC to the network I get the error '3424'.
I've searched through the specs (TS 31.111, TS 22.030 and even TS 24.080) but didn't find even the tiniest lead as to what I'm doing wrong.
Any help will be appreciated :)
Cheers,
Nir.
I think the problem occurs due to timer management(Action in contradiction with the current timer state) becouse
0x34-> Means SS Return Error
0x24-> Means Action in contradiction with the current timer state.

UDP packet does not arrive

I'm not sure if this is the right place to ask this question. If not, i will remove it...
Anyway, i have made driver for enc28j60 for LPC1788 and I'm trying to send UDP message to it from iOS. Sending fails.
Communication starts by iOS sending the ARP request. On LPC i make response and send it to iOS MAC address. I have read RFC for ARP and created packet by the specification, but for some reason i dont see the response in network sniffer.
That would for sure indicate that my response routine does not work, if there was not this case when i send udp message from OSX (nc -u xxx.xxx.xxx.xxx port) that comes correctly to LPC.
The difference that i observed is that OSX sends the request which is 42bytes long and gets 60bytes long response with last 18bytes of 0's (padding bytes), and iOS sends the 60byte long request with last 4bytes as 90 eb 58 96.
I tried to respond with all padding zeros, and with copying those 4 bytes, but neither approach worked.
OSX ARP(req, res) and UDP package is visible in sniffer.
iOS ARP req is visible in sniffer and nothing else.
Any idea ?
EDIT:
IOS code:
CFSocketRef sock = CFSocketCreate(kCFAllocatorDefault, PF_INET, SOCK_DGRAM, IPPROTO_UDP, 0, NULL, NULL);
if ( sock == NULL) {
NSLog(#"CfSocketCreate Failed");
}else{
struct sockaddr_in remoteAddress;
memset(&remoteAddress, 0, sizeof(remoteAddress));
remoteAddress.sin_family = AF_INET;
remoteAddress.sin_len = sizeof(remoteAddress);
remoteAddress.sin_port = htons(1200);
remoteAddress.sin_addr.s_addr = inet_addr("192.168.5.8");
char data[] = "test";
NSData *message_data = [NSData dataWithBytes:&data length:4];
NSData* remoteAddressData = [NSData dataWithBytes:&remoteAddress length:sizeof(remoteAddress)];
CFSocketError er = CFSocketSendData(sock, (__bridge CFDataRef)(remoteAddressData), (__bridge CFDataRef)message_data, 0);
}
LPC code:
void make_arp_response (uint8_t *buffer)
{
uint16_t pos = sizeof (ethernet.source)+sizeof (ethernet.dest);
uint8_t type[2];
type[0] = ARP_TYPE>>8;
type[1] = (uint8_t)ARP_TYPE;
memcpy (buffer+pos, &type, sizeof (ethernet.type)); pos = sizeof(ethernet); //set ethernet type
arp.hwType = ((0x01)<<8);
memcpy (buffer+pos, &arp.hwType, sizeof (arp.hwType)); pos += sizeof(arp.hwType);
arp.protocol[0] = 0x08;
arp.protocol[1] = 0x00;
memcpy (buffer+pos, &arp.protocol, sizeof (arp.protocol)); pos += sizeof(arp.protocol);
memcpy (buffer+pos, &arp.macLen, sizeof (arp.macLen)); pos += sizeof(arp.macLen);
memcpy (buffer+pos, &arp.ipLen, sizeof (arp.ipLen)); pos += sizeof(arp.ipLen);
arp.opCode = (0x02) << 8;
memcpy (buffer+pos, &arp.opCode, sizeof (arp.opCode)); pos += sizeof(arp.opCode);
memcpy (buffer+pos, &macaddr, sizeof (arp.sourceMac)); pos += sizeof(arp.sourceMac);
memcpy (buffer+pos, &arp.destIP, sizeof (arp.sourceIp)); pos += sizeof(arp.sourceIp);
memcpy (buffer+pos, &arp.sourceMac, sizeof (arp.destMac)); pos += sizeof(arp.destMac);
memcpy (buffer+pos, &arp.sourceIp, sizeof (arp.destIP));
enc28j60_PacketSend(sizeof (ethernet)+sizeof (arp),buf);
}
UPDATE:
It seems that this is not just an iOS problem, but problem with Wifi clients. I have tried to send UDP from windows laptop over wifi and it also sends the ARP request but response and UDP packet got lost somehow. It seems that my ruter have some problems with my LPC :)
I have also tried to connect Arduino to the same enc28j60 board instead of LPC, and UDP communication works.
Library for arduino is found somewhere on the NET. ARP response in arduino code looks the same to me.
UPDATE 2:
Arp request:
ff ff ff ff ff ff 85 29 fb 0d c2 71 08 06 00 01
08 00 06 04 00 01 85 29 fb 0d c2 71 c0 a8 05 28
00 00 00 00 00 00 c0 a8 05 08 00 00 00 00 00 00
00 00 00 00 00 00 00 00 25 a9 c3
Arp response:
85 29 fb 0d c2 71 7b c3 53 a6 9c 55 08 06 00 01
08 00 06 04 00 02 7b c3 53 a6 9c 55 c0 a8 05 08
85 29 fb 0d c2 71 c0 a8 05 28
This response is dumped from LPC just after sending it on wire. I didnt saw it in sniffer.

Resources