For fun I'm adding an SNMP server to the IP-stack I wrote (MyIP).
This somewhat works: on a local LAN, I can do a 'walk' (using getnext - no bulk as that is not implemented) without any problems.
Over the internet though it often times out after the first exchange (getnext + response), OR completely fails, or works fine - it never fails after e.g. 2 getnext requests. It has been tried on several locations (vps's and isp's).
When I run tcpdump on my firewall, I see packets come in. When I capture them with wireshark, then wireshark says all is fine.
Does anyone have an idea what is wrong with these SNMP packets? example network trace
Related
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")
I have been reading about setting up a ping tunnel to access the internet when you can only send ICMP packets. Ptunnel seems to be a popular program and the instructions to use it can be found here http://www.cs.uit.no/~daniels/PingTunnel/. The instructions to this program say that you must have both a client and proxy computer.
I do not understand the benefit of a ping tunnel if you must have a proxy computer that can send TCP/IP packets. If I had a computer that could do that, I wouldn't need to set up the tunnel in the first place. Can someone please explain this to me, why is a proxy necessary and if it is how is ping tunneling useful then?
NSNolan
Well, let's assume you have a server (PC running linux for example) in your home where it has total internet access and now you are at work/airport/hotel with your laptop where you have no access to tcp without paying.By setting an icmp or dns tunnel you can "encode" your packets to appear as if they were pings/nslookup, those packets destination is always your server. When the server recieves those pings from you, it "decodes" them and totally understand what you are trying to reach (like a website or download a file as an example).
Then your server serves you and get the information you are seeking and "encode" them again into icmp/nslookup like packets. Those packets can reach you without any problem and once they do, your laptop can decode them back into useful information (just like the ones it would recieve with tcp). That encoding & decoding are what the Ptunnel do. Though I'm not professional I think that is the total point.
I'm writing an IPsec implementation for a microcontroller and I want to test it using a standard Linux box running Debian Lenny. Both devices should secure the communication between them using IPsec ESP in tunnel mode. The keys are setup manually using setkey. There's no (or at least should be no) user space program involved in processing an IPsec packet. Now I want to see how my created packets are processed by the Linux kernel. To see the raw packets I capture them using tcpdump and analyze them using wireshark.
What's the best way to obtain debug information about IPsec processing?
How can I figure out whether the packet is accepted by the kernel?
How can I view the reason for a packet to be dropped?
You can instrument the XFRM (or perhaps ipv4/esp.c) kernel code to print out debug messages at the right spots.
For example, in net/ipv4/esp.c there exists a function esp_input() which has some error cases, but you'll see most the interesting stuff is in the xfrm/*.c code.
That said, I didn't have a problem interoperating a custom IPSec with Linux. Following the 43xx specs and verifying the packets came out correctly via wireshark seemed to do well. If you're having issues and don't want to instrument the kernel then you can setup iptables rules and count the number of (various type of) packets at each point.
Finally, be sure you've actually added a security policy (SP) as well as a security association (SA) and setup firewall rules properly.
I'm trying to connect to the VMWare's pipe; what is in fact simulated serial port where I've redirected debug output from the virtual OS. I used this article to redirect debug output from the virtual OS to the named pipe on my client OS through the VMWare. It works perfectly when I use the WinDbg as decribed in that article but I want to create my own application to catch this debug output - only to catch, nothing else. When I'm only listening from the pipe (that simulated serial port) I'm getting meaningless data.
Is it enough to only read from the remote debugger (redirected to a certain debugport) or should I use some protocol for it (to acknowledge reading or something) ? In other words; may I only listen to the pipe (serial port) without any response to it ?
Thanks for any suggestions
Regards
The data coming out is not meaningless but it has to be parsed based on the particular protocol used. If you are not sending commands but just reading output information it should be enough to just listen (though I do not know off hand if the protocol requires acknowledgement of messages).
However, what you receive will have to be parsed based on the messages you are getting. I've never tried to parse the debug information on my own but this page should give you some information on the protocol.
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.