I am trying to do a remote tachograph authentication by sending a RemoteCompanyCardReady cantp message to a VDO tachograph on connector C.
The reply message I get is a nack 7f 31 7f which seems to suggest there is no open session. I can't seem to find anywhere how to open the diagnostic session to the tachograph. Also the can id I am using for sending the messages is 18DAEEFB, is that correct? Can anyone give me the byte sequence on the can bus for that?
If you are receiving a response from the device (7F 31 7F in your case), then the CAN ID seems to be correct.
The service which you are trying to send (0x31) seems to be a Routine Control service. Those services usually work in the Diagnostic Session.
According to the ISO, Session Control service is 0x10. So, try to send the request (10 03) to the device. If you receive a positive response (50 01 XX..) then send your required service immediately (within 5 seconds of receiving 50 01).
Related
I have been working on a Twilio project and i have set everything up using this guide: Stream TwiML
i have already resolved a common issue with the help of Alan here Answer
I'm unable to send back the processed bytes I'm using.
ws.send(bytes)
ws.receive()
These two methods i assume are required to send and receive back and forth data using the web socket.
But im receving a constant data stream from twilio.
That's:
b'\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xfe\xf
Which does not makes any sense. The guide officially says you can get bytes from real time call and then send them. So let's say i receive bytes and process them using my custom logic maybe storing it somewhere. My processing outputs the same PCM/16Bit Mono audio data in bytes. Which i think twilio is also send me raw bytes as it says in the documentation that it gives out raw bytes (which i assume are without any kind of encoding). So all i want here is to receive audio data sent from the caller to twilio to receive and send bytes to an endpoint which i have setup ed earlier in flask to handle and then i can process it a little bit and return PCM bytes to it which can be played back at the caller side.
All i want is to caller send his voice and gets processed and receives back maybe our voices added to it as well. It wont matter how the byte is treated here my concept is to add some audio data to it and send back.
But since verb is new so there's no where i can find how to properly handle the bytes and send them back.
It would be nice if someone can point me what twilio expects in the web socket return as a audio data that it can be played on the caller side. And what i should be expecting from twilio. But since in the documentation it says that payload sends out raw bytes so i assume its a plain PCM data in bytes.
Please let me know so i can receive bytes from twilio and send them back which can be played at the caller side and caller's voice can be heard from here.I have players and clients setup ed as well to play the byte data but since the data is plain or recursive i cannot play it.
Thanks in advance.
Twilio developer evangelist here.
As far as I know right now Media Streams only supports streaming the data to your server one way. You cannot stream media back to Twilio via the websocket connection.
If you were able to save the bytes you want to send back as an audio file, you can play it back to the call by redirecting the call to some TwiML that <Play>s the audio to the call.
Let me know if that helps at all.
I am facing an issue with the presence status, following the documentation and XMPPframework example code. I have written a chat application.
Problem : When the user 1 & 2 are online I get the status successfully and they can chat with each other. However when the user 2 goes physically offline via (Wifi OFF / 3G Off) User 1 is not getting the offline status from XMPP and hence what ever messages are sent from that instant of time are lost when the user 2 comes online.
It seems since the user 2 is not notified or stored as offline in XMPP and hence its not storing the offline messages to push back to user 2 when it comes online.
I have tried to resolve this by explicitly writing a [goOffline] call to XMPP, however the call is shown in 'SEND log' for 'user 2' but not received in 'RECV log' in user 1 from XMPP, due to which the message are lost in between.
Also tried with other sources replies.
Set status for presence available and send XMPP
priority changed with values non-negative
XMPPArchiving work but this is not what I wanted.
Server side Mod_zero push enables but get only first message push notification sometimes.
Setting limit on ejabberd.cfg file for users and offline message limit.
request for offline message pull.
Can anyone help me with this?
This is very typical situation where client losses network but server can't detect that it is offline.
To detect status of each client, server need to send PING packets to every client and wait for response.
If client responds then fine otherwise server will mark that client as offline and every other online client will be informed automatically.
Here is PING Module implementation for ejabberd XMPP Server (hope you are using ejabberd server):
mod_ping:
send_pings: true
ping_interval: 10
timeout_action: kill
ping_ack_timeout: 10
This has to be written in ejabberd.yml configuration file.
At client side also we need to enable ping module to respond to server pings as:
private var xmppPing: XMPPPing?
xmppPing = XMPPPing()
xmppPing!.activate(xmppStream!)
This code has to be written while we setupStream() for iOS.
For detailed info, please go through mod_ping documentations.
Sounds like your problem is at server level. The server thinks that the user is online so it sends the message but nobody gets it. This does not really have a simple solution.
1.
The best solution would be delivery receipts. Where basically when the message is sent to your client, your client returns a confirmation of delivery receipt. If the server does not get that receipt it would resend the message every n time. Depending on your XMPP server you might find a already made solution, of not you would have to roll out your own.
2.
A possible hack would be to have your server always store and deliver last 10 messages and then at client side you discard repeated... This also depends on your server implementation. XMPP MUC and PubSub have resources along these lines.
For a long term scalable solution, you'll need to deal with this both at server and client level.
In the technical note, tn2265 apple describes how to handle errors while attempting to send batch push notifications: (direct quote)
Here's how to check for errors when using the enhanced notification
format. Keep writing until a write fails. If the stream is ready for
writing again, resend the notification and keep going. If the stream
isn't ready for writing, see if the stream is available for reading.
If it is, read everything available from the stream. If you get zero
bytes back, the connection was closed because of an error such as an
invalid command byte or other parsing error. If you get six bytes
back, that's an error response that you can check for the response
code and the ID of the notification that caused the error. You'll need
to send every notification following that one again.
My question relates to the text I have highlighted in bold. For the record, I am using the Enhanced Notification Format, and I am passing in my unique ID for each recipient in the my list, so as the APNS service can return this id in case of errors.
In case we receive 0 bytes back, i.e. Apple has closed the connection without sending an error code back, we cannot know after which attempted device token the error occurred. I.e. we cannot resume sending from that or the next token.
In this case, is it acceptable to attempt re-sending to all the devices again? Is this not going to result in devices being "spammed" by the same notification multiple times?
For example: Assume I have a list of 5000 devices to send to. The 0-byte response problem occurs after I have successfully sent to a random part of my list, and I do not know how many devices AND which ones have actually received my notification. Not having an error code returned with the device id of the last successful device, or the device at which the error occurred, does not allow me to resume sending from the next token, which was the whole purpose behind using the Enhanced Notification Format in the first place.
How have others handled this issue? I would appreciate any thoughts or suggestions.
Thanks in advance for your assistance.
i went through this question
Lost messages over XMPP on device disconnected
but there is no answer.
When a connection is lost due to some network issue then the server is not able to recognize it and keeps on sending messages to disconnected receiver which are permanently lost.
I have a workaround in which i ping the client from server and when the client gets disconnected server is able to recognize it after 10 sec and save further messages in queue preventing them from being lost.
my question is can 100% fail save message delivery be achieved by using some other way i know psi and many other xmpp client are doing it.
on ios side i am using xmppframework
One way is to employ the Advanced Message Processing (AMP) on your server; another one is to employ the Message Delivery Receipts on your clients.
The former one requires an AMP-enabled server implementation and the initiating client has to be able to tell the server what kind of delivery status reports it wants (it wants an error to be returned if the delivery is not possible). Note that this is not bullet-proof anyway as there is a window between the moment the target client losts its connectivity with the server and the moment the TCP stack on the server's machine detects this and tells the server about it: during this window, everything sent to the client is considered by the server to be sent okay because there's no concept of message boundaries in the TCP layer and hence if the server process managed to stuff a message stanza's XML into the system buffers of its TCP connection, it considers that stanza to be sent—there's no way for it to know which bits of its stream did not get to the receiver once the TCP stack says the connection is lost.
The latter one is bullet-proof as the clients rely on explicit notifications about message reception. This does increase chattiness though. In return, no server support for this feature is required—it's implemented solely in the clients.
go with XEP-0198 and enjoy...
http://xmpp.org/extensions/xep-0198.html
For a XMPP client I'm working on, the following mechanism is used:
Add Reachability to the project, to detect quickly when the phone is having connectivity problems.
Use a modified version of XEP-0198, adding a confirmation sent by the server. So, the client sends a message, the server confirms with a receipt. Later on, the receiving user will also confirm with a receipt. For each message you send, you get two confirmations, one from the server, one from the client. This requires modifications on the server of course.
When the app is not connected to the XMPP server, messages are queued.
When the app is logged in again to the XMPP server, the app takes all messages which were not confirmed by the server and sends them again.
For this to work, you have to locally store the messages in the app with three possible states: "Not sent", "Confirmed by server", "Confirmed by user"
I am working on a school project to connect the pn532 with a nfc phone. I am using the seeedstudio nfc controller and the library they have, with some code that I am adding. My questions are related to the connection and discovery stage of the protocol.
Question 1: What to respond when the initiator sends a CONNECT command to the DSAP = 1 "discovery service". Bellow I explain the results of the protocol.
Phones used to test were(gs4, note 2):
Situation 1:
the phone sends me 05 20 06 this is a CONNECT command to SAP =1 in the receiver device, then I respond with the CC command 81 84 2 2 0 78.
then they send me an IPDU with the URI of the application in the foreground, I keep sending command as per the llcp-snep protocol in the nfc forum and everything finish cool.
*The problem is that I don't want the URI of the application in the foreground, I want the NDEF message data of that application instead.*
Situation 2:
the phones send to the pn532 11 20 , this is a CONNECT command to SAP =4 in the receiver device, then I respond with the command CC 81 84 2 2 0 78.
After this the phone send me the NDEF data as is suppose to be.
Now my questions are:
Why some times the phone send me the CONNECT command to the SAP =1 and some times to SAP=4?
What command I have to response for the 05 20 06 ?
When a CONNECT command is send to SAP 1 it means that the sender wants to perform service discovery and connection setup in one step. In this situation, a required information in the CONNECT command is the service name. If that service exists and is connectable the response would be a CC (Connection Complete) PDU to the SAP from which CONNECT was received and from
the SAP that the named service is bound to. If a service with the requested name does not exist the answer would have to be a Disconnected Mode (DM) PDU with the appropriate reason code.
Unfortunately you have not provided full information about the CONNECT command received on SAP 1, at lest the service name length byte and the name itself are missing. As written, the CONNECT PDU is just invalid and should not be acknowledged.
As expected the whole problem was solved. After the request for connection of the undesired service I sent the DM with reason 02 command and everything went normal. It took me some time to get the library to work with all phones together but finally I fixed it. Thanks for all the feedback