When I tried to use the sr1 command in scapy with packets, it sends the packet but it didn't receive the reply.
For example, I tried to send a ping packet with the sr1 in order to receive the reply. I have seen the request-packet in wireshark but nearby was written "response not found" while the reply packet was just 2 lines down.
Related
I am using Scapy to create an SSDP protocol discovery packet for all devices (ssdp:all) however suddenly I am not getting any response from the devices when I did get them before. I am using a Ubuntu VM. This is the code I am using to create the packet.
ssdpPacket = IP(dst="239.255.255.250")/UDP(sport=6700,dport=1900)/Raw(load='M-SEARCH * HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nST:ssdp:all\r\nMAN:"ssdp:discover"\r\nMX: 2\r\n\r\n')
send(ssdpPacket)
In wireshark, I see that it does send the packet but no response. I am kind of frustrated because it worked before and now its just not working. Help!!
I'm trying to analyse my Sniffer Capture and to get information about the STA, who sends deauth packets. Actually I'm doing it with my laptop and my AP to test my WLAN security
aireplay-ng [wlan inteface] --deauth 1000 -a {BSSID}
But where in this wireshark capture should I look for the MAC Adress from the station who sends deauth packets (my laptop)? All I can see here, it's like my AP sends packets to himself. Maybe it's a silly question, but I do not get it.
You send deauth to broadcast if command is used like this:
aireplay-ng [wlan inteface] --deauth 1000 -a {BSSID}
When this command is running from the laptop, packets will be sent with the AP address of the point specified in the "-a" option:
Source address = Transmitter Address = AP BSSID
Explanation of addresses:
Receiver Address: immediate recipient of the frame
Destination Address: final recipient of the data
Transmitter Address: STA that transmitted the frame
Source Address: source of the data
(edit: solved -- see below)
This is my situation:
TL-MR3020 -----ethernet----- mbed
OpenWRT C/C++ custom networking stack
192.168.2.1 192.168.2.16
TL-MR3020 is a Linux embedded router
mbed is an ARM microcontroller.
On the network I just want them to exchange messages using UDP packets on port 2225. In particular, TL-MR3020 has to periodically send packets every second to 192.168.2.16:2225, while mbed has to periodically send packets every 50ms to 192.168.2.1:2225.
Everything was good untill I removed the network stack library from mbed (lwIP, not so lightweight for me) and written a new minimal stack.
My new stacks sends 5 gratuitous ARP reply just after the ethernet link gets up, then starts sending and receiving udp packets.
Now TL-MR3020 doesn't receive any UDP packet. In particular, with ifconfig I can see packets coming, but my application can't get them.
Also, if I connect my laptop instead of the TL-MR3020, I can see the UDP packets coming, using Wireshark. There's nothing wrong, except done for my application.
I have a node.js script that has to receive the packets, but it doesn't receive nothing, but if I send UDP packets from local to local, the script receives them.
I think that my application is OK also because neither SOCAT can receive the UDP packets using socat - UDP-LISTEN:2225.
I've already checked on TL-MR3020:
arp table has the correct ip-mac assiciation
destination MAC address matches the incoming interface
destination IP address matches the incoming interface
IP checksum: wireshark says good=false, bad=false
UDP checksum: wireshark says good=false, bad=false
So, I'm asking... what are the minimum requirements for a custom networking stack to send UDP packets?
SOLVED:
You need a good checksum in the IP header.
UDP checksum, my case, can be set to zero.
tcpdump is very helpful (thanks to AndrewMcDonnell)
I am learning datalink raw socket programming on Linux, and I found these helpful examples. I compiled the icmp4_ll.c, and used it to send an ICMP packet to anther computer in the same LAN. I can receive the reply from the destination computer. However, when I used it to send an ICMP packet to the local computer, that is, I set the source and destination Ethernet MAC and IP addresses to the MAC and IP address of eth0, I cannot receive the ICMP reply on either eth0 or lo interface (In Wireshark, I only noticed the ICMP request sent over eth0, but no ICMP reply on any interface.)
I think the ICMP request message is composed correctly, (otherwise the remote destination wont reply). But I don't know why the OS just doesn't reply the request. Any help or hints are appreciated.
RFC 792 defined special conditions for the ICMP messages:
No ICMP error messages are sent in response to ICMP error messages to avoid infinite repetition.
For fragmented IP datagrams, ICMP messages are only sent for errors on fragmented zero (the first fragment).
ICMP error messages are never sent in response to a datagram that is destined to a broadcast or a multicast address.
ICMP error messages are never sent in response to a datagram sent as a link layer broadcast.
ICMP error messages are never sent in response to a datagram whose source address does not represents a unique host (the source address
cannot be zero, a loopback address, a broadcast address or a multicast
address).
ICMP error messages are never sent in response to an IGMP message of any kind. When an ICMP message of unknown type is received, it must
be silently discarded.
Routers will almost always generate ICMP messages but when it comes to a destination host, the number of ICMP messages generated is implementation dependent.
Is it possible to configure Scapy to listen for network traffic and send a crafted packet once a packet with certain parameters is received? I mean for example Scapy listens network traffic on eth0 and in case an ICMP "echo request" packet from source IP 10.10.44.3 is received, Scapy sends an TCP SYN packet to port 34 to IP address 192.168.2.1 using 8.8.8.8 as a source. Is such setup possible with Scapy?
Yes.
Using the sniff() function, you can provide a parameter to the stop_filter option.
>>> print sniff.__doc__
Sniff packets
sniff([count=0,] [prn=None,] [store=1,] [offline=None,] [lfilter=None,] +
L2ListenSocket args) -> list of packets
...clipped...
stop_filter: python function applied to each packet to determine
if we have to stop the capture after this packet
ex: stop_filter = lambda x: x.haslayer(TCP)
If the function returns 1, sniff will stop, and you can continue with whatever logic you wish.