I am using Telit modem GL 868 Dual V3. AT command AT#SCFG has 2 parameters- packet size to be used and data sending time-out for TCP. Is there any AT command which specifies that if any delimiter string is found, then that data will be sent on TCP ignoring the packet size and time-out?
There are commands #PADFWD, #PADCMD which serves the purpose of delimiter.
Below is a snapshot from AT commands reference guide for telit modem.
Related
I use the gpsd python library in order to read and parse the NMEA string recieved from the gps device. I would like to send some command to gps in order to fine tune the measurement rate, report rate and so on.
It is possible using the gpsd library or I must send the command with in other way?
According to 'gpsd' manual:
To send a binary control string to a specified device, write to the
control socket a '&', followed by the device name, followed by '=',
followed by the control string in paired hex digits.
So if you have gpsd service running as gpsd -F /var/run/gpsd.sock you can use the following code to send commands to the gps device:
import socket
import sys
# Create a socket
sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
# Connect the socket to the port where the GPSD is listening
gpsd_address = '/var/run/gpsd.sock'
sock.connect(gpsd_address)
# #BSSL 0x01<CR><LF> - Set NMEA Output Sentence (GGA only)
# cmd = '#BSSL 0x01' + '\r\n'
# #RST<CR><LF> - RST - Reset
cmd = '#RST' + '\r\n'
message = '&/dev/ttyUSB1='
cmd_hex = cmd.encode('utf-8').hex()
print ('cmd_hex {}'.format(cmd_hex))
# cmd_hex 405253540d0a
message += cmd_hex
bin_message = message.encode('utf-8')
print ("bin message {}".format(bin_message))
# bin message b'&/dev/ttyUSB1=405253540d0a'
sock.sendall(bin_message)
data = sock.recv(16)
print ('received {}'.format(data))
# received b'OK\n'
sock.close()
In my case I am sending #RST command followed by CR, LF symbols.
When sending the FormatPICC command to a MIFARE DESFire EV1 card, I observe the following behavior:
PCD ---> PICC
--------------
0xFC --->
<--- 0x00 or 0x00 + MAC or ERROR CODE
If authenticated with the command 0x0A (legacy (3)DES authentication), the response to the FormatPICC command is only one byte (0x00).
If authenticated with the command 0xAA (AES authentication), the response to the FormatPICC command is the status byte (0x00) plus the MAC.
When I send another command (e.g. GetVersion (0x60)), the response does not contain the MAC regardless of which authentication was used (0x0A or 0xAA).
Why is that difference? Should I still calculate the MAC for such commands (to update crypto state)? Is there some document that explains that?
Your observation seems to be wrong. Once authenticated using either AuthenticateISO (0x1A) with TDES or AuthenticateAES (0xAA), MIFARE DESFire EV1 will return a MAC in response to all commands (except, of course, the authentication commands and SelectApplication, which both reset authentication).
Consequently, a MAC should be returned in response to the GetVersion command. However, note that the GetVersion command is split across 3 frames. The MAC is only appended to the last frame (the one with the status code 0x00):
PCD ---> PICC
--------------
0x60 --->
<--- 0xAF + DATA
0xAF --->
<--- 0xAF + DATA
0xAF --->
<--- 0x00 + DATA + MAC
In DPKD the ETH_RSS_IPV4 data flow is not activated by default for XL710 Intel NIC. So, when you want to distribute packets among lcores you have to select other IPv4 data flows which are supported by XL710, namely ETH_RSS_FRAG_IPV4, ETH_RSS_NONFRAG_IPV4_TCP, ETH_RSS_NONFRAG_IPV4_UDP, ETH_RSS_NONFRAG_IPV4_SCTP, and ETH_RSS_NONFRAG_IPV4_OTHER. However you will face a silly problem when you are dealing with the fragmented IP packets. If you choose to go with ETH_RSS_FRAG_IPV4 and ETH_RSS_NONFRAG_IPV4_TCP options then some fragmented packets of a connection will fall into another queue, because they don't have L4 port numbers. If you exclude ETH_RSS_NONFRAG_IPV4_TCP function then the ETH_RSS_FRAG_IPV4 hash function will not be applied to non-fragmented packets and those packets will go to queue 0. All other combination of hash functions will not work. So, what should we do?
The behavior of XL710 is not compatible with the conventions in DPDK. So, you must directly work with the API offered by i40e driver in order to set up RSS for ETH_RSS_IPV4. As mentioned in the Intel® Ethernet Controller 710 Series Specification Update, page 18 (release Jan 2017):
Functions that require the Hash (RSS) filters on IPv4 packets should
set all IPv4 PCTYPEs in the PFQF_HENA / VFQF_HENA (PCTYPEs 31, 33…36)
Supported packet types (PCTYPE) are mentioned in Intel® Ethernet Controller 710 Series Datasheet pages 597 and 598 (release Jan 2017). You can see that there is no packet type defined for IPv4.
However there is a solution. The clue is to modify the input set for all required flow types (or packet types). Let's try it with testpmd tool which is provided by DPDK in app folder. After compiling DPDK and the app, run the testpmd application:
./app/test-pmd/testpmd -c ff -n 2 -w 0a:00.0 -w 0a:00.1 -- -i --rxq=4 --txq=4
We have two XL710 in our system. With the following commands you can configure XL710 to behave as you want to support IPv4 data flow.
port config all rss all
set_hash_input_set 0 ipv4-tcp src-ipv4 select
set_hash_input_set 0 ipv4-tcp dst-ipv4 add
set_hash_input_set 0 ipv4-udp src-ipv4 select
set_hash_input_set 0 ipv4-udp dst-ipv4 add
set_hash_input_set 1 ipv4-tcp src-ipv4 select
set_hash_input_set 1 ipv4-tcp dst-ipv4 add
set_hash_input_set 1 ipv4-udp src-ipv4 select
set_hash_input_set 1 ipv4-udp dst-ipv4 add
set_hash_global_config 0 default ipv4-frag enable
set_hash_global_config 0 default ipv4-tcp enable
set_hash_global_config 0 default ipv4-udp enable
set_hash_global_config 1 default ipv4-frag enable
set_hash_global_config 1 default ipv4-tcp enable
set_hash_global_config 1 default ipv4-udp enable
It selects the proper input set for TCP and UDP flow types by removing the L4 port section. The set_hash_global_config command enables the symmetric hash if you need it. By modifying the TCP input set, it behaves just like Frag IPv4 flow type and as a result all packets belonging to the same connection go to the same lcore.
Note that the default input set for Frag IPv4 and NonFIPv4, Other is IP4-S and IP4-D. So it doesn't need to be modified. Remember to modify all other IPv4 flows input set and symmetric quality of them.
You can find the API functions of those commands by looking at the source code of the testpmd application.
I want to send UDP from Node Red to Pure Data. In NR, I have a UDP output node set to 127.0.0.1:3001 and a Pd netreceive object set to 3001 1 (the 1 sets the object to UDP rather than TCP). No message is received in the Pd patch.
To thicken the plot, a Node Red UDP output node set to 127.0.0.1:1881 does successfully send to Node Red UDP input node set to 1881. Also, a TCP object set to 127.0.0.1:3000 does connect with d netreceive object set to 3000, reported by the Pd console as "EOF on socket 12".
As the Node Red UDP output node is sending within the flow and Pd can report a TCP connection, I suspect there's something I have to do to format the message for PD. Any ideas?
netreceive expects messages to be FUDI-formatted. Basically, this means messages are terminated with a semicolon. Until a ';' is received, [netreceive] won't output anything.
Read more here: https://en.wikipedia.org/wiki/FUDI
Please check out my git repo for a solution.
https://github.com/sylatupa/Digital-Culture-Sound-Client/issues/1
Node Red was used to receive MQTT on particular topics.
I route the topics to the appropriate shell command that runs the locally installed pdsend executable.
I take the MQTT payload and pipe '|' two strings to the pdsend executable.
Left 3 is relieved by the execution of pdsend
The puredata patch receives and routes the 'Left 3' message
Node-Red is running on a raspberry pi, along side the mqtt broker.
I am testing with a MQTT client written in python.
See the github for the code and pure data patch, and maybe the node-red flow if that can be exported.
What is lacking is more complex messages, json encoded strings, and larger hierarchy topics, /pi/sensor1.
I'm trying to send a multiline sms from an application I am creating to my phone via telnet to a GSM modem. I would like the message to be output to my phone as shown below but cannot figure out how to add new lines within the message string so that the message is output to my phone as below. I cannot find much documentation on this either and the few character codes (\r\n) I tried either terminated the telnet command were they were displayed in my code or were showing in the SMS received on my phone.
Does anybody know what character code that would give me a new line without terminating the telnet command within the message string?
at*smsm2m= “441234567891
Pinging 192.168.0.31 with 32 bytes of data:
Reply from 192.168.0.31: bytes=32 time=3ms TTL=64<br>
Reply from 192.168.0.31: bytes=32 time=1ms TTL=64<br>
Reply from 192.168.0.31: bytes=32 time=1ms TTL=64<br>
Reply from 192.168.0.31: bytes=32 time=1ms TTL=64
Ping statistics for 192.168.0.31:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
The server side of Telnet is typically just a regular shell so you can do the same things you'd do for embedded newlines as if you were typing at a command line. Try this:
echo -e "this\nhas\nmultiple\nlines" | program
(you may need to look up flags for the echo command on the server if it's not a GNU machine)