I have a AODV pcap file which shows me some RREP packets with both destination and Originator IP address to be the same.
Is it correct or this could possibly be an error.
My sample pcap file can be found here
RREP with same D and O are hello messages
Related
i have a Ubuntu 16.04.5 server with Vesta CP.
I checked the server on https://dnsflagday.net, and I got this report:
domain.cl. #123.456.78.90 (ns1.domain.cl.): dns=ok edns=ok edns1=ok edns#512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=timeout optlist=ok
domain.cl. #123.456.78.90 (ns2.domain.cl.): dns=ok edns=ok edns1=ok edns#512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=timeout optlist=ok
I do not know what edns512tcp = timeout means and I have not had much luck looking for a solution on internet.
Can someone help me? thanks
For that tool, any kind of "timeout" error is a problem, it means some server did not reply or the message (either query or reply) was eaten by some active element on the path, so it needs to be fixed.
edns512tcp is when the testing software does an EDNS query with a buffer of 512 bytes and over TCP.
If you go to https://ednscomp.isc.org/ednscomp/ for your domain you will have the full test results.
For that specific error it is:
EDNS - over TCP Response (edns#512tcp)
dig +vc +nocookie +norec +noad +edns +dnssec +bufsize=512 dnskey zone #server
expect: NOERROR
expect: OPT record with version set to 0
See RFC5966 and See RFC6891
So you can see which DNS query was done with dig, that you can reproduce it (+vc is an old flag name that is an alias for +tcp). The test expects to get a NOERROR code back and an OPT record. Your servers did not reply at all, so the test failed.
It seems that your servers did not reply to that at all, which is wrong. Maybe they do not reply to TCP queries at all which is even more wrong. In all cases you will need to contact the entity responsible for maintaining those servers and point it to the test results so that they start to fix the problem.
thanks for your help.
I read more about it and I could detect that port 53 was being blocked by the firewall, I added the rule to the firewall to allow TCP connections on port 53.
Everything it's fine now
I'm using STM32 with ESp8266 using latest AT Command Firmware V2
Also i'm including https://github.com/nimaltd/ESP8266
Which helps parse at commands
I can connect to my router access point and my local tcp server but when sending GET requests i receive nothing on my local
const char* host = "192.168.1.9";
while(!Wifi_TcpIp_StartTcpConnection(0,host,3437,10)){
char buffer[] = "Unable to connect to TCP Backend\r\n";
HAL_UART_Transmit(&huart1,buffer,sizeof(buffer),HAL_MAX_DELAY);
};
uint8_t req ="GET /opaaa HTTP/1.1\r\n"; Wifi_TcpIp_SendDataTcp(0,sizeof(req),&req); //success but i receive nothing
Assuming the TCP communication works properly (you can connect to the server, send and receive data) and that the host you connect to serves HTTP on that port, the issue I can see with your request is that you're missing an additional CRLF at the end, like so:
char *req = "GET /opaaa HTTP/1.1\r\n\r\n";
Wifi_TcpIp_SendDataTcp(0, strlen(req), (uint8_t*)req);
This signifies the end of HTTP headers that you're sending. In your original case, the server may still be waiting for more headers and therefore holding with sending the response back to you.
I also suggest to clean up the sending code, one way of which I've pasted above - you were assigning a string to a single byte uint8_t variable.
What TCP dump filter should I use to get an ARP packet with a specific H\W address(src or dst) from a pcap dump file ?
Try this:
"arp and ether host xx:xx:xx:xx:xx:xx"
Refer to the PCAP-FILTER man page for more information.
I am working on a way to find a mapping between the application and the url it accesses at a given timestamp. For this I first got the mapping of tcp port number to url by parsing the packet dump file from time t1 to t2. I wrote this python code for parsing:
import dpkt
f = open('/home/nachiket/Desktop/Research work/my project/s1-pcapFilesParsed/pcap files/2017_04_01_023856.pcap')#2017_03_30_013908.pcap #2017_03_02_010455.pcap
pcap = dpkt.pcap.Reader(f)
g=open('s1final.txt','w')
g.write("\n")
list=set()
for ts, buf in pcap:
eth = dpkt.ethernet.Ethernet(buf)
ip = l2.data
tcp = ip.data
if type(tcp)!=str:
if (tcp.dport == 80 or tcp.dport == 443) and len(tcp.data) > 0:
try:
http1 = dpkt.http.Request(tcp.data)
if http1.uri!='/_ping':
g.write("p "+str((hex(tcp.sport).split('x')[-1])).upper()) #converted to hex
except (dpkt.dpkt.NeedData, dpkt.dpkt.UnpackError):
continue
Now I mapped the tcp port to uid from /proc/net/tcp and from uid I got application name. Thus I merged the two files and got the tcp port to application name mapping at a given timestamp.
The python code:
#! /bin/bash
for i in {1..80}
do
adb shell "date +%s" > dump/netdump$i
adb shell "cat /proc/net/tcp" >> dump/netdump$i
echo finished: $i
sleep 1
done
The problem I faced is the tcp ports from running the first code doesnt match at all with the tcp ports running from second code. If was supposed to merge them on basis on common tcp ports used by application at a given timestamp and hence to find the application to url mapping at a given time. But the ports doesnt match.
I know that the /proc/net/tcp is used for getting details of each socket but it shouldn't affect the tcp ports I guess.
PS: I am a beginner and have done research before submitting question
Thank you
I have created forged destination unreachable ICMP with type 3 and code 4 (fragmentation needed and DF bit is set). My setup has Server, Client, and a switch between them. Ideally this ICMP gets generated by router/gateway but I'm generating this at client. I'm creating this ICMP using Scapy tool. Here is how I'm creating:
ip = IP()
icmp = ICMP()
# IP Packet sent to client
ip.dst = ip_server
ip.src = ip_client
ip.protocol = 1 #shows that ip header contains icmp as data
# icmp type 3 + code 4
icmp.type = 3
icmp.code = 4
mtu =1300
icmp.unused = mtu
#
# build original packet for ICMP ping request
#
ip_orig = IP()
ip_orig.src = ip_server
ip_orig.dst = ip_client
icmp_orig = TCP()
tcp_orig.sport = 50000
tcp_orig.dport = 50000
tcp_orig.seq= original sequence number
#
# send the packet
#
send (ip/icmp/ip_orig/tcp_orig)
Steps I'm following to demonstrate the effect of this ICMP:
1> Server and client are talking to each other using sockets
2> As soon as server accepts the connection, I'm giving a 60 seconds pause in the machine during which I disable all the TCP ACKs going out of client machine (because if server receives ACKs for the message it sent then it wouldn't respond to ICMP).
3> Server sends it first message to client but won't receive any ACKs and server keeps re-transmitting the message, meanwhile I inject an ICMP message as mentioned in the above scapy code: send (ip/icmp/ip_orig/tcp/orig). I'm reporting MTU 1300 in the icmp i'm sending.
4> Ideally Server should reduce it's MTU and sends message back to client with MTU size of 1300.
But Server keeps re-transmitting the message with MTU size 1500. Kindly help me with this.
Why is server not reducing its MTU? Am I doing something wrong in my demonstration? Any help would be greatly appreciated.
There are a few pointers I outlined in this answer and in its comments:
The specification requires that the original IP header that is encapsulated in the ICMP error message (i.e. ip_orig) is exactly identical to the one received. Therefore, setting just its source IP address and destination IP addresses (i.e. ip_orig.src and ip_orig.dst, respectively) is probably not enough.
The sequence number of the original TCP header that is encapsulated in the ICMP error message (i.e. tcp_orig.seq) should be set as well, since the specification requires that at least 8 bytes of the problematic packet's IP layer payload are included in the ICMP error message.
Verify that path MTU discovery is enabled and that the DF bit is set. You can enable path MTU discovery with sysctl -w net.ipv4.ip_no_pmtu_disc=0.
Verify that there isn't any firewall and/or iptables rule that blocks ICMP messages.