I am attempting to use RawCap to sniff Windows localhost. However, contrary to its billed ability to do so, it is not working. I am starting it as follows:
rawcap 127.0.0.1 echo.pcap
I then run a little echo TCP client / server test app I wrote. I use the client to send some data over 127.0.0.1, and it indeed gets printed on the server and sent back to the client, where it is also printed. Howver, the packet capture file is empty.
I am running under Windows XP, SP3.
Is anybody aware of any other steps I need to take to get this to work?
Additional information added on 7/20/2011: I contacted the company that produces RawCap, and they suggested making sure that I have administrator privilege, that I try sniffing ping 127.0.0.1, and that I try enabling telnet and sniffing telnet 127.0.0.1. I do indeed have administrator privilege, RawCap sees ping packets, but it did not see telnet packets. I also tried sniffing 127.0.0.1 on another machine, and I failed there also.
Best,
Dave
I've been in contact with the author of RawCap, and he indicated that I found a bug where Windows XP SP 3 can't sniff TCP on localhost. He does not seem hopeful that he can fix it. If any more useful information comes along, I will, in an attempt to help the community, comment on this answer.
Related
I dont think this is a very hard to solve problem, never the less I didnt find anything about it online. I am pretty new to irc/weechat and obviously dont want to leak my ip whenever i join a room. So I want to use a proxy, specifically tor. The thing is, everything I've tried didnt work out.
For clarity, I now my proxy does work, I tested it on firefox.
The things I did to connect an irc server to my proxy where the following:
add tor proxy (no username or password):
/proxy add torproxy socks5 <ip-address> 9050
set proxy on server:
/set irc.server.<server_name>.proxy torproxy
then just connect:
/connect <server_name>
and its always the same output:
irc: disconnecting from server
irc: reconnecting to server in 10 seconds
and after 10 seconds, the exact same output, but with 20 seconds, and the number just goes up
some parameters you might want to consider is that I dont run the proxy at localhost. Its a server in my lan, but i tested it on other computers and the proxy does work, so thats not the problem. Also I want to configure the proxy directly in weechat, and not use some system wide setting or something.
Thanks for your help!
You may need to disable SSL verification.
/set irc.server.<server_name>.ssl_verify off
Another factor to consider is that the server might not accept connections from tor. If the network has multiple servers, try connecting to a different one.
Sorry for asking such a mundane question, but I'm suddenly curious. If I open the network connections dialog on my Windows machine, it shows me a cute little picture of my computer connecting to a router and then to a globe (labeled Internet). What is Windows trying to connect to in order for it to decide that the computer has Internet connectivity? I assume there is no IP4 address for 'The Internet', so where is it going? Is it just sending a ping to an address back at the Microsoft home office? If that address were to disappear, would my window's machine suddenly decide that it no longer has a route to the Internet? Would Windows boxes that were 'close' to that address incorrectly report that they could get to the Internet when they couldn't.
I'll stop now before this gets too silly. But seriously, what criteria does a Windows box use to determine that it has Internet connectivity? I'm assuming that Linux and iOS systems have an equivalent feature. Do they use the same criteria?
The general IP address that is used for 'the internet' is 8.8.8.8 - or Google.com.
If you can ping it, and get a web page from it, then there's a pretty good chance you can get to at least some of the internet.
But for specifically Windows - Network Connectivity Status Indicator - it uses a different domain: dns.msftncsi.com
It will (unless disabled by GPO):
resolve the name, and verify it has the 'right' IP (131.107.255.255
fd3e:4f5a:5b81::1 )
Perform a HTTP get to this address and check it gets a result. NCSI
Presumably if different responses are retrieved, then it can tell if it has a wi-fi login or similar.
Your intuitions seem correct. I am not on a Windows machine but you could find out by firing netstat and then connecting.
If I was programming this I'd make Ping, TCP and HTTP requests. Some devices are connected through proxies such as firewalls, captive portals and others. the only way to be sure is to send something and receive a reply.
My Android device for example can detect captive portals. It probably does that by trying to HTTP connect somewhere.
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 have a project based on windows Phone 7.5, which contains a module to ping remote devices (in the same subnet or internet). I tried to perform an echo request and reply on port 7. but reply does not comes back, rather, an NullReferenceException occurs when I try to access SocketAsyncEventArgs.Buffer. I also tried creating ICMP type packets in app, but no luck.
As far as my understanding goes, icmp packets are not allowed to perform ping. however, from desktop, the phone can be pinged if ip address of phone is known.
I have checked many applications on marketplace (like Console WP7 Lite, TestMyNet), those can perform ping by sending icmp packets and can also access Round trip time of ping operation.
I am wondering how those applications can ping to remote (accessible) devices, when windows phone sockets does not allow icmp packets.
Can anyone help me.
Thanx for help in advance
Are you sure these apps can ping local network? For example can they ping WP Wifi interface's gateway or the WP Wifi interface itself? Or can the only ping hosts on Internet? I tried both apps mentioned by you, and even more and they ping everything except local network. That is why i was convincend that they use external server to perform pings and roound-trip is only calculated or estimated somehow.
Piotr Wojtowicz
I'm trying to see the results of an incoming ping on a target windows machine. This is needed to verify that the ping, which is running in a background thread, is being sent from the originator.
I have tried netstat to no avail. Are there any other approaches I could try?
Thanks.
Ping is an ICMP packet and doesn't create a TCP connection (hence you won't see it in netstat). On Linux, I'd add a rule to the firewall.
The most simple solution for your case might be to open a connection and close it. That will add it to the output of netstat with WAIT_CLOSE.
As Aaron Digulla already noted, ping is ICMP. This also means the originator even less trustable then with TCP; there's no SYN/ACK handshake. You just get an IP packet on your host, and you have to trust the header fields. Anyone can spoof those header fields, with almost no restrictions (It might be a bit challenging to get an IP claiming to come from 127.0.0.1 past a router)
Therefore, ICMP is not suitabel for verification tasks. You need a challenge/response protocol. TCP works reasoanbly well as long as you can trust the network but not necessarily all hosts on it (a reasonable assumption for the Internet. Not strong enough for financial transactions, which is why they use SSL)