I'm using the Scapy library for Python 2.6 on Windows 7 in order to see if I can spoof my IP address (for non-malicious purposes, I'm curious how it works).
When I use the sr1() function, it sends the packet, but it gets nothing in return. I have to interrupt it manually using CTRL+C in order for it to stop receiving packets that are not an answer.
I've tried to use both Python-Scapy or the like-How can I create an HTTP GET request at the packet level and Scapy: no reply on raw ICMP packet, with no luck.
I have tried tracking it in Wireshark, but nothing showed up.
I know Scapy is not made for Windows, so that could be the issue. If so, I can get a Linux environment instead.
NOTE: Note that I am running this through the console version of Scapy, but I found the exact same results running it through Python scripts.
IP(dst="www.google.com")/TCP(dport=80,flags="S")
This TCP packet's sport will automatically set to be 20 (www-data) in Scapy.
And what is worse, www.google.com does not reply from the sport=20 (www-data)
try
IP(dst="www.google.com")/TCP(sport=65000,dport=80,flags="S")
Related
I'm trying to get my head around SNMP for a project I'm working on. After I failed miserably getting it to work in my company's network, I set up a simple 3-device network to test things on, consisting of two Windows 10 PCs and a manageable switch between them.
I installed the optional feature "SNMP" on both PCs, made sure the service is running correctly and configured both services to accept SNMP queries from each other. I made sure to open up UDP port 161 in both PCs firewalls. Then I got the Net-SNMP binaries in order to use SNMPGET and SNMPWALK. As an alternative, I set up the SNMP extension for PHP through xampp (since I want to use PHP in my project once I get SNMP to work). Finally, I installed wireshark to monitor what exactly is going on and this is what I found:
When I try SNMPGET or SNMPWALK either through cmd or as a PHP command, I always get a timeout message. Wireshark is showing the get-next-request leaving one PC and arriving correctly on the other, so the network connection itself is working fine. But the receiving PC never sends a response. As I said, I'm pretty new to SNMP and I'm at a loss as to why this is happening. As I understand it, the optional feature for Windows 10 comes with its own SNMP agent, correct? If so, what could cause it to simply ignore an incoming request from a valid source IP?
The funny thing is that this even happens when I try to send an SNMP query to 127.0.0.1. I have no idea what I'm doing wrong...
Thanks to the comment of Lex Li, I was able to finally figure out which step I made a mistake with:
When setting up the SNMP service, under the security tab, I had to add 'public' as an accepted community name (with READ-ONLY rights). I figured since 'public' is sort of the standard read-only community, it would be accepted by default, which apparently it is not.
Alternatively, I guess I could have added my own communtiy name, but I didn't try that since I only want to read some values through SNMP anyways and read-only access is all I need for that.
Thank you very much Lex Li, I'm off to continue my project now!
I'm attempting to write a script to connect to a DLNA audio renderer.
There are a few articles on the web giving information on how to do this using UDP and curl, however in my particular scenario I'm having some difficulties.
The first step is to send a UDP multicast announcement over the network to discover DLNA devices on the network.
The message sent to discover devices is:
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MX: 5
Man: "ssdp:discover"
ST: urn:schemas-upnp-org:device:MediaRenderer:1
All lines in this message sent over UDP should have crlf line endings and the last line should have an extra crlf according to this article
That all seems fine. And if the message above is in a file devicediscovery.txt supposedly it's possible to use netcat to send out this message:
cat devicediscovery.txt | nc -u -4 239.255.255.250 1900
239.255.255.250:1900 is the multicast address and port over which DLNA devices communicate.
This all seems fine too, however, as is pointed out in the linked article netcat ignores the response from the dlna media renderer because there is a mismatch in IP addresses the message is sent out over the dlna multicast address, though the response comes from the router. The article suggests using tcpdump to capture the response, however I'm on Windows and using Bash on Windows WSL so tcpdump is not available and such a technique would possibly be complicated when developing a script to automate the dlna connection.
Would it be possible to use two seperate instances of netcat? One instance sending the message over the dlna multicast address and the other listening for the response from the router?
I have tried to get this working, however I'm unsure which port netcat should be listening on to hear the incomming response. Is there a standard port that netcat should listen on?
I've tried commands such as: nc -luv 192.168.0.1, however I get an error Servname not supported for ai_socktype. I've tried to remedy this by playing around with /etc/services but had no luck.
What command can I use and how must I configure the system to listen for the response from the search for dlna devices? I'd like to parse the response in a script so that the dlna connection can be automated.
Although you mention issues with DLNA it looks that you are really asking for how to best troubleshoot this.
Network cards don't allow access to incoming traffic unless set in promiscuous mode. Netcat won't be able to do what you need because of this. But, you can use Wireshark to read the traffic on the interface. TCPdump and Wireshark have close ties and almost interchangeable.
https://www.wireshark.org/
I would recommend to use it to troubleshoot further. Ppost the capture (not just a picture) and show where it failed.
I was trying to find traceroute program implementation for MS Windows that can be used by regular user (with no admin rights) and I could not find any. Those I could find (like tracetcp or nmap) require PCAP library and in order to install winpcap I think administration rights are required.
I don't know much about Windows internals but I'm wondering what is the 'magic' behind. If tracert shipped by MS with Win OS works fine for regular user (but it can use ICMP only) then is there any issue (technical limitation) with setting TTL for TCP/UDP packet by regular user and receiving respective response on the socket such as:
ICMP: TTL expired in transit
UDP: port unreachable
and probably few others (like TCP RST, ICMP host unreachable etc)?
So basically:
if there is no issue why there is no reasonable traceroute implementation
for windows?
if there is a technical limitation for TCP/UDP then why
original MS ICMP traceroute works fine for non admin users?
I know that the most popular linux traceroute with -T option (for using SYN probes) requires root priviliges too but I'm assuming it's just because it does not want to complete full TCP handshake and sending RST after receiving SYN-ACK may be restricted for root. Anyway as longs as TTL can be set by reqular user (for UDP it seems to work fine) then I would imagine TCP traceroute completing full TCP handshake should be possible to implement for non root linux users?
And by the way ICMP traceroute also needs admin rights because of using RAW sockets but surprisingly for Windows it does not seem to be an issue.
Sadly, the simple answer to your question is "no, there is no native way to do that on a Windows box".
I am a bit unsure about your specific usecase, but one route to go is evaluate if Power Shell has more functionality to help you out. Jose Baretto from Microsoft wrote an article about Power Shell equivalents for common networking commands. You can find it here:
https://blogs.technet.microsoft.com/josebda/2015/04/18/windows-powershell-equivalents-for-common-networking-commands-ipconfig-ping-nslookup/
Failing that, your only option is (as you mention yourself) 3rd party tools, and you'll be hard press to find one that doesn't require elevated privileges.
I am looking for UDP debugger tool, for the following requirement
1) netstat -s, shows udpInOverflows=23000 and this counter is increasing continuously.
how can I check udp packets which are thrown because of no buffer space.
2) what are the possible reason for this problem to occur and how to solve it.
3) is there any way to check incoming UDP packet which are received by kernel after all verification like udp socket is open for that port and no check sum error, snoop will not work because it capture direct from network interface.
Regards
Nitin
If you are willing to spend a little time with kernel source you should be able to use dtrace to get at the information you want. For example "dtrace -n 'fbt::udp_input:entry{stack();}' will show you how packets are getting into udp_input (not all that interesting). You should also check the mib::: probes and fbt:ip:ip_drop*:. This is all dependent on the version of Solaris you are using of course.
I am working on a project that involves a usb device, through which we will receive ip packets from a remote pc. We assign the remote pc its IP Address. I have been experimenting with sending raw ip packets via several methods:
1 - raw sockets: ping works fine, problems sending tcp
2 - tun/tap W32: I managed to get this working enough to send pings out and get pings back to the phy ethernet device, but could not read them using ReadFile(...) on the driver guid.
3 - winpcap: ping works, out going tcp shows up on wireshark(so I assume it is leaving the pc), but i never get an ack to my syn. Im also worried that if I did get an ack the windows TCP stack would send a rst.
Our goal is to be a transparent pass through from the client pc to the network.
Client <-wrapped ip packet-> [device] <-wrapped ip packet-> WinPC <- IP -> IpNetwork
Its possible that im going about this wrong, seems like this should be easier.
I realize that windows is prob not the ideal OS for this, however I have no control over the OS.
thanks in advance
Fixed my issue with TCP Syn packets not getting acked, turns out I forgot to include the pseudo-header when calculating the TCP header checksum. Now it looks like the tcp handshake completes, so im calling this problem solved. If anyone feels like recomending a better way to accomplish this, feel free to reply. For now looks like we will use the winpcap method.
Update:
For this to work without windows constantly RST'ing tcp connections, you have to enable internet connection sharing(ICS) on the adapter you are sending packets out of. Other than that this ended up working for us.