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}
Related
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 a python script which assembles and sends AVB (IEEE) packets into a network.
The packets will be captured by wireshark.
With an other python script I iterate through the capture file.
But I can't access a few parameters in a few layers because scapy doesn't know them.
So I have to add those layers to scapy.
Here's the packet in wireshark:
I added the following code to the file "python2.7/dist-packages/scapy/layers/l2.py"
class ieee(Packet):
name = "IEEE 1722 Packet"
fields_desc=[ XByteField("subtype", 0x00),
XByteField("svfield", 0x81),
XByteField("verfield", 0x81)]
bind_layers(Dot1Q, ieee1722, type=0x22f0)
When I execute the python script which should grab the parameters in the new layer (IEEE 1722 Protocol), the following error occurs:
"IndexError: Layer [ieee1722] not found"
What's wrong?
Ok, found the solution by editing the type value:
bind_layers(Dot1Q, ieee1722, type=0x88f7) ---> works
Dot1Q is the layer above the created ieee1722 layer (see wireshark).
You can see the type value by clicking at the layer of a packet in wireshark.
This is old, maybe they didn't have the doc page but they have it now:
"Adding new protocols"
https://scapy.readthedocs.io/en/latest/build_dissect.html
I'm currently working with gloox in order to send XMPP messages from my C++ program. I work in local network with my private prosody XMPP server.
Sending text messages between two client works but not files. I tried the gloox examples (ft_rcv & ft_send) but it did not worked neither (obviously I modified the examples to match my configuration), I always have the same error :
<error type='cancel'><service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
At the beginning I thought it was due to my prosody server but I added the following lines in the conf files :
Component "proxy.jabberserver.local" "proxy65"
proxy65_address = "proxy.jabberserver.local"
proxy65_ports = { 7777 }
I tried different server and different port but I'm currently in a dead end. If someone have an idea it would be great.
Thank you
f->addStreamHost( JID("proxy.jabberserver.local"), "proxy.jabberserver.local", 7777 ); should do the trick. If no - show full XML log.
So for our first assignment we made a basic ftp program using TCP, now we have to modify it to use UDP, also sending it to a router program (that we cannot modify, but have the code to look at) that will randomly drop and delay packets and handle it with a simple stop and wait protocol. But that's not the problem.
I modified the Client and Server to use UDP using the notes from my lab teacher (http://www.cs.concordia.ca/~ste_mors/comp445/Assign2tutorial.ppt) and all I'm doing is sending a packet and when I receive it on the other end print a line of text. I followed the instructions in the slides, running it on localhost (have no other machines to test with) and it sends, and the router confirms it receives and forwards the packet, but the server never prints the line of text. Knowing that UDP drops packets a lot I made a while(true) loop that sends packets forever, the server still does nothing.
Here's the code so far:
Client: http://pastebin.com/XdbxuJ9R
Server: http://pastebin.com/iN5j2Ku3
Unmodifiable Router given to us: http://pastebin.com/QwMAc0MW
For the client i left in everything after the connection starts from the old one, the send line is 175, in server I commented out everything in the run loop except the receive part which is at line 181
I'm going absolutely crazy trying to fix this. I had to cancel plans and ruin my entire day because I can't get this one thing working. :(
From what i can tell you're using the wrong ports. Here's what the router.h defines:
// router.h
#define ROUTER_PORT1 7000 //router port number 1
#define ROUTER_PORT2 7001 //router port number 2
#define PEER_PORT1 5000 //port number of peer host 1
#define PEER_PORT2 5001 //port number of peer host 2
And here's what you're defining:
// client.cpp
#define REQUEST_PORT 0x5000 // hexadecimal, that's port 20480
and
// server.cpp
#define REQUEST_PORT 0x5001 // hexadecimal, that's port 20481
I didn't check the rest of the code, but the server appeared to receive something after correcting the port numbers (as in removing the 0x prefix)
Maybe this will help illustrate how the router works:
// the router does (pseudocode):
recvfrom(7000), sendto(PEER2:5001)
recvfrom(7001), sendto(PEER1:5000)
I'm trying to learn boost::asio by writing a simple client which sends strings to an echo server. I have tested the echo server with telnet and it works great, but my boost::asio client is acting weird. async_read_until doesn't seem to read/call handler until four messages have been sent (and returned by the echo server). The output of the client maybe explain this better (I removed the newline after each value):
gurka#x:~/private/code/test$ ./test localhost 2001
Hostname resolved.
Connected to server.
Starting write
Starting read_until
Writting[1]
Writting[2]
Writting[3]
Writting[4]
Read[1]
Writting[5]
Read[2]
Writting[6]
When the connection have been made I have two calls:
boost::asio::async_write(mSocket, mOutgoingBuffer, boost::bind(&Connection::writeToServer, this, boost::asio::placeholders::error));
boost::asio::async_read_until(mSocket, mIncomingBuffer, "\n", boost::bind(&Connection::readFromServer, this, boost::asio::placeholders::error));
writeToServer and readFromServer just prints Writting/Read and the value it's writting/read and then does the async_write/async_read_until call again, with exacly same parameters. The writeToServer takes it messages to send from a queue which I have filled with "1\n".."6\n".
I don't think the error is in the echo server since I can see that it read and writes back all 6 values, in order. And it as I said before, it works perfect using telnet. So, why is async_read_until "delayed" by 4 messages? I've tried sending longer strings and it's the same thing.