I have an application running on heroku, say my-app.herokuapp.com. However, if I type
ping -c 10 my-app.herokuapp.com
in Mac terminal, it says Request timeout, though the app is running, I can open it in my browser.
Why is that?
Ping uses a different protocol vs opening it in a browser. Ping uses ICMP whereas your browser will be using TCP. It would seem Heroku simply block the ICMP protocol which is fairly common as it can be abused (try pinging www.microsoft.com also)
Related
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 tried to run a simple 1-page site with Flask in Python on port 5000 of my computer 192.168.0.113, which is running Windows 10. On the same computer, I can view the site by using localhost:5000 in a web browser.
I tried to use another computer 192.168.0.134 on the same LAN to view the site. However, 192.168.0.113 never replied with a SYN/ACK packet to the SYN packet from 192.168.0.134, even if the firewall of 192.168.0.113 is completely turned off. This image is the captured flow of the packets:
If I did it reversely (i.e. 192.168.0.134 as the server to host the site, and 192.168.0.113 tried to connect as the client), then 192.168.0.113 is able to connect.
I noted from some previous posts (especially this one) that the problem can be solved by disabling TCP window scaling and TCP timestamps. I checked in netsh of 192.168.0.113 and noted that TCP window scaling had already been disabled and TCP timestamps was normal. I tried to disable both of them, and also tried to disable just one of them. However, all combinations failed and 192.168.0.113 still wonn't sent SYN/ACK packets in response to SYN packets from 192.168.0.134.
How can I get this fixed?
More broadly you are only showing traffic going in one direction in the Wireshark capture.
You probably are not listening on an external IP addresses. The Flask application takes an IP address argument to listen on, if it is localhost or 127.0.0.1 it will not respond to external connection. Set this to 0.0.0.0 to listen on all IP addresses. Verify this by running the command netstat -a -b to see which IP address you application is listening on.
The Flask Quick start page goes through this (see Externally Visible Server)
flask run --host=0.0.0.0
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.
I'm trying to access some websites via Telnet on Windows XP and whenever I open a website or my 127.0.0.1 on port 80 it echoes back connecting to 127.0.0.1 ... or whatever other target I have typed.
After a long long time the connection times out and I'm left with nothing.
My browser works fine.
Is there something wrong?
What happens if you type GET / after the connecting... string? It could be that you've connected and your telnet client isn't telling you, and the webserver's waiting for you to do something.
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.