I have a 56K fax modem that should support voice, and should support full duplex. I need to make phone call, where i can play sound (out) , and also receive sound (in).
Procedures :
-- I
nitializing modem
AtQ0 ' Enables modem to send result codes to the DTE.
AT+GCI=B5 ' set country of installation to XX
AT-STE=7 ' to be able to get busy , line in use messages
AT+FCLASS=8 ' set mode to voice mode
AT+VSM=130 ' set received audio format
-- Dialing phone number
ATD123456; ' to dial number 123456
-- WHAT IS NEXT
??? I do assume that i have to read the data signals using VTR , but it gives me error since the modem is not into connect mode. If I used AT+VLS=1 , it will work well to get the audio data from line, but I can not then dial number (ATD1123456;)
Questions:
- What is the normal logic to start phone call , and record data.
- Shall I then read and write to the same COM Port, as this modem should support full duplex.? , or two different COM Ports are to be used?
Related
I am writing a Qt application for serial communication with a Qorvo MDEK-1001. All built-in serial commands I've had to use work fine except for one: aurs n k, where n and k are integers corresponding to the desired rate of data transmission (e.g. "aurs 1 1\r"). Write function is:
void MainWindow::serialWrite(const QByteArray &command)
{
if(mdek->isOpen())
{
mdek->write(command);
qDebug() << "Command: " << command;
//mdek->flush();
}
}
If I send the command "aurs 1 1\r". It doesn't actually get sent to the device until I send another command for some reason. So if I subsequently send the "quit" command to the device, the returned data from the device is: "aurs 1quit", which registers as an unknown command. Any assistance getting this command to send properly is appreciated.
I've tried a bunch of stuff (setting bytes to write as second parameter in write(), using QDataStream, appending individual hex bytes onto QByteArray and writing that), but nothing has worked. This is the first time I've had to use Qt's serial communication software so I've probably missed something obvious.
On Linux Manjaro (same thing happens on Windows 8.1)
Connection settings: 8 data bits, Baud: 115200, No Flow Control, No Parity, One Stop Bit
I am new to gRPC framework, and I have created a sample client-server on my PC (referring to this).
In my client-server application I have implemented a simple RPC
service NameStudent {
rpc GetRoll(RollNo) returns (Details) {}
}
The client sends a RollNo and receives his/her details which are name, age, gender, parent name, and roll no.
message RollNo{
int32 roll = 1;
}
message Details {
string name = 1;
string gender = 2;
int32 age = 3;
string parent = 4;
RollNo rollid = 5;
}
The actual server and client codes are adaptation of the sample code explained here
Now my server is able to listen to "0.0.0.0:50051(address:port)" and client is able to send the roll no on "localhost:50051" and receive the details.
I want to see the actual binary data that is transferred between client and server. i have tried using Wireshark, but I don't understand what I am seeing here.
Here is the screenshot of wireshark capture
And here are the details of highlighted entry from above screenshot.
Need help in understanding wireshark here, Or any other way that can be used to see the binary data.
Wireshark uses the port to determine how to decode the communication, and it doesn't know any protocol associated with 50051. So you need to configure it to treat this as HTTP.
Right click on a row and select "Decode As..." in the context menu.
Then set "Current" to "HTTP" or "HTTP2" (HTTP will generally auto-detect HTTP2) and hit "OK".
Then the HTTP/2 frames should be decoded. And if using a recent version of Wireshark, you may also see the gRPC frames decoded.
The whole idea of grpc is to HIDE that. Let's say we ignore that and you know what you're doing.
Look at https://en.wikipedia.org/wiki/Protocol_Buffers. gRPC uses Protocol Buffers for it's data representation. You might get a hint at the data you're seeing.
Two good starting points for a reverse engineer exercise are:
Start simple: compile a program that sends an integer. Understand it. Sniff it. Then compile a program that sends a string. Try several values. Once you understand it, pass to tacke the problem of understanding how's google sending your structure.
Use known data and do small variations: knowing what 505249... means is easier if you start knowing the data you're sending (as an example, send "Hello world" string; then change it to "Hella world"; see what changes on the coded sniff; also check that sending several times the same data produces the same sniffed output). Apply prior point: start simple, first empty string, then " ", then "a", then "b", etc. and then pass to complex and larger strings. Don't be affraid to start simple.
I have used scapy to sniff internet packets from my computer knowing that they are not encrypted how can I decode the data being sent so it comes out as clear text , something like wireshark does, I would like a code exemple for it.
I do not want to use wireshark I want to code this myself for learning.
I used the following simple script to capture the packets :
from scapy.all import *
def callback(pkt) :
print pkt.summary()
print pkt.show()
sniff(store=0, prn= callback)
It depends on the application that sends the taffic. If it sends the data unencrypted and in plain text (ascii) you can access and display it using the atribute load of the packet. For example:
def callback(pkt) :
print pkt.load
If the data is not plain text you need to know how the application is encoding the data and decode it. If you're looking for more similar output to that of wireshark you can try with hexdump(pkt).
GDB Client:
NetworkClientConnect 503: Attempting host: 10.23.37.155 (addr: 02CE4B50)
NetworkClientConnect 518: Connected to host: 10.23.37.155
NetworkClientRecv 576: Recv Packet: +
NetworkClientSend 550: Sent Packet: +
GDB Server:
Debug: 243 275 pld.c:207 handle_pld_init_command(): Initializing PLDs...
Info : 244 22937 server.c:83 add_connection(): accepting 'gdb' connection from 3333
Debug: 247 22954 gdb_server.c:260 gdb_get_char_inner(): received '+'
Debug: 248 22954 gdb_server.c:272 gdb_get_char_inner(): returned char '+' (0x2b)
Initially the connections are made then they acknowledge that they got the packet by sending "+". In my case the client says it is receiving a '+' and so does the server as the very first info exchange. That does not make sense. One has to send and the other receive what I see is both receiving and sending in parallel. But it is working. So where is my thinking wrong? Also if you can point me to a URL which shows exactly the GDB Server and Client protocol exchange that would be awesome.
In your GDB client printout, it looks to me, messages are not printed in order (see that Recv packet has number 576, and sent 550).
Use wireshark or similar tool to debug an issue like this.
I tried connecting to gdbserver via loopback and according to wireshark the dialogue looks like this:
client sends "+"
client sends "$qSupported:multiprocess+;xmlRegisters=i386;qRelocInsn+#b5"
server sends "+"
server sends "$PacketSize=3fff;QPassSignals+;..."
and so on.
Gdb does help an option selectable at runtime that can help debug such things. Start it, then issue "set debug remote 1". Same on remote side. Start gdbserver by "gdbserver --remote-debug ...". This will print remote gdb protocol dialogue on both sides.
Another, possibly best if most time consuming options is to check the gdb&gdbserver source.
I got into WireShark Help Forum (http://ask.wireshark.org/) and posed the question there. "How to capture packets between 2 IP's". There a person called Quadratic gave a brilliant answer. You can refer the WireShark site or here it is. It works like a charm!!
Do this:
• When you first start Wireshark, click on the button in the far upper-left that says "List the available capture interfaces" when you scroll over it.
• In the new "Capture Interfaces" window that opens, select the interface you want to capture packets (with the check box on the left-hand side) and click"Options".
• In the Capture Options window, on the lower-left corner there should be a "Stop Capture Automatically After..." seciton. Check the "packets" option and put in a value of 50
• In the same Capture Options window, in the text box to the right of "Capture Filter", type the statement (without quotes) "ip host 10.xx.xx.xx and ip host 10.yy.yy.yy".
• Hit the Start button :)
One small thing to note - if the interface you're capturing is doing vlan tagging, replace the capture filter statement to "vlan and ip host 10.xx.xx.xx and ip host 10.yy.yy.yy" without quotes.
Edit:
An even simpler solution is to just use one command line statement:
C:\Program Files\Wireshark\dumpcap.exe -c 50 -i {interface name or number} -w {wherever you want to save the packet capture file}
I am trying to analyse a file containing packets captured using tcpdump. I first want to categorize the packets into flows using 5-tuple. Then I need to get the size and inter-arrival time of each packet in each flow. I tried Conversation list in wireshark but it gives only the number of packets in the flow not information about each packet in the flow. A suggestion for any code (c++ or shell script) that can do the job? Thank you
UmNyobe,
If you haven't heard of Scapy yet I beleive what you are trying to do would be a near perfect fit. For example I wrote this little snippet to parse a pcap field and give me something like what you are talking about using Scapy.
#!/usr/bin/python -tt
from scapy import *
import sys
from datetime import datetime
'''Parse PCAP files into easy to read NETFLOW like output\n
Usage:\n
python cap2netflow.py <[ pcap filename or -l ]>\n
-l is live capture switch\n
ICMP packets print as source ip, type --> dest ip, code'''
def parse_netflow(pkt):
# grabs 'netflow-esqe' fields from packets in a PCAP file
try:
type = pkt.getlayer(IP).proto
except:
pass
snifftime = datetime.fromtimestamp(pkt.time).strftime('%Y-%m-%d %H:%M:%S').split(' ')[1]
if type == 6:
type = 'TCP'
if type == 17:
type = 'UDP'
if type == 1:
type = 'ICMP'
if type == 'TCP' or type == 'UDP':
print( ' '.join([snifftime, type.rjust(4, ' '), str(pkt.getlayer(IP).src).rjust(15, ' ') , str(pkt.getlayer(type).sport).rjust(5, ' ') , '-->' , str(pkt.getlayer(IP).dst).rjust(15, ' ') , str(pkt.getlayer(type).dport).rjust(5, ' ')]))
elif type == 'ICMP':
print(' '.join([snifftime, 'ICMP'.rjust(4, ' '), str(pkt.getlayer(IP).src).rjust(15, ' ') , ('t: '+ str(pkt.getlayer(ICMP).type)).rjust(5, ' '), '-->' , str(pkt.getlayer(IP).dst).rjust(15, ' '), ('c: ' + str(pkt.getlayer(ICMP).code)).rjust(5, ' ')]))
else:
pass
if '-l' in sys.argv:
sniff(prn=parse_netflow)
else:
pkts = rdpcap(sys.argv[1])
print(' '.join(['Date: ',datetime.fromtimestamp(pkts[0].time).strftime('%Y-%m-%d %H:%M:%S').split(' ')[0]]))
for pkt in pkts:
parse_netflow(pkt)
Install Python and Scapy then use this to get you started. Let me know if you need any assistance figuring it all out, if you know C++ chances are this will already make alot of sense to you.
Get Scapy here
http://www.secdev.org/projects/scapy/
There are tons of links on this page to helpful tutorials, keep in mind Scapy does alot more but hone in on the areas that talk about pcap parsing..
I hope this helps!
dc
I worked on a library to analyze tcp dump but it was for a business so I cannot just give to you. if you don't find what you are looking for then my answer can help. A tcpdump is just nested network data like the Matryoshka dolls, where the pcap layer is added by tcpdump.
If you only want to work on the captures, the format of a dump is specified in Libpcap File Format. To get the size and time of arrival of each packet you need to process the dump using this specification.
If you have to go deeper in the analysis these are the following layers in order
the link layer
the internet layer
Transport layer
The application layer
Each layer has a header definition. So you need to find which protocol stack your pcap data contains and to parse the header to get information.
What are the members of the 5-tuple? If the flows are TCP or UDP, the source and destination IP addresses and port numbers, plus, perhaps, a number to distinguish multiple flows over time between the two endpoints would work; for SCTP, it would be similar, although if a flow is a stream, you might need more.
If the members of the 5-tuple are all "named fields" in Wireshark, you could use TShark with the -T fields option, and use the -e option to specify which fields to print, and select a field with the time stamp (frame.time_epoch would give you the time as seconds and fractions of a second since the UN*X epoch), a field the appropriate size (frame.len gives you the raw number of bytes in the link-layer packet PLUS any meta-data such as a radiotap header for 802.11 radio information), and the other fields, and then feed the output of TShark to a script or program that does the processing you want to do. That lets TShark do the processing of the protocol layers, so that your program only needs to process the resulting data.