I'm using Flash Media Server to stream audio. I used to use it on port 1935 (the default port) but a lot of users were complaining they couldn't hear the stream, I figured it may be a firewall issue and their firewall was blocking that port. So I changed it to port 80 and most of the users who couldn't stream properly, were now able to.
Ever since then, i've still encountered a few users who complain about not hearing the stream. I'm not really sure where to go from here, I would have thought port 80 is open for everyone seeing as HTTP goes through port 80 and if you can browse the web then you should be able to stream right? Clearly not... Does anyone have any suggestions on what I can do my end to enable streaming for these users who can't hear anything port 80?
Thanks for the help, much appreciated.
In some organizations, there is an intelligent firewall or some device that does deep packet inspection. These devices can be configured to analyze the data running over a port, and flag it accordingly.
So, you sent RTMP over port 80, the device recognizes it and will usually do one of two things:
"Hey, that's RTMP being sent over the wrong port! Not on my watch!! [BLAM, packet killed]"
"Hey, that's RTMP being sent over the HTTP port! Let's not apply rules for HTTP and apply the packet shaping rule for RTMP, which says it should be blocked (or throttled down to 0.03kbps)"
Unfortunately, there's not much you can do about this. It is very common for this kind of thing to get blocked or throttled near the client's end.
If you can find someone this happens for, you can analyze the packets with Wireshark, or some other packet sniffing software. Then you can see for sure what is reaching the client, and what isn't.
Related
There are already some questions regarding this, but I want to ask something very specific that does not seem to be covered by the others. So, I'm aware that the same UDP port (server) can be used by different users - the server stills knows where to deliver the appropriated packages. However, since the UDP port on the server is exactly the same for both users, does this mean that some delay can occur? For instance, if at exact same time 5 users want to use the same server socket and the connection is UDP based, then there will be a delay because the socket can't deal with the 5 connections at the same time. Is this correct? I know that, in practice, this would only happen with a great amount of connection, given that processing time of an UDP connection is faster than TCP, but it could potentially happen. Or am I wrong?
Since I'm not happy with the functionality of an iPhone App that operates my Actioncam, I would like to write an app that improves on that functionality.
In order to do that, by lack of proper documentation, I need to reverse engineer the communication between the App and the Device.
What I know, is that the Device only responds on ports 21, 554 and 15740.
I managed to create a setup including an iPhone, the Device and two Macs, and traffic analyzing software called Charles (but likely I could also use Wireshark), that shows me all HTTP(S) traffic.
This is where my knowledge ends. What I hoped to see, was that Charles would report something like
rtsp://[my device ip, which is known to me]:554/[unknown to me path]
Potentially it would even involve a login and password in that URL.
Could any of you give me a hint on how to proceed? Aforementioned software seems to be limited to HTTP traffic.
What excatly do you want to reverse engineer? The video feed or control logic? From what you mentioned it seems that 21 could be used for FTP, 554 for RTSP and 15740 for some custom TCP protocol. If you have no idea about the format of the data that is sent over to the port 15740 it will be quite hard to reverse engineer (except if it is some kind of plain text ascii protocol).
For the video feed - I'd suggest setting up Wireshark to monitor the port 554 and then you should be able to see the url of the video location from the DESCRIBE command.
Since ISPs as well as company networks (eg. when connected via WiFi) tend to block different ports, is there a best practise of choosing a specific portnumber when developing the server part of a mobile app?
I am talking about the choice of a listening port on the sever, that the app connects to (either udp or tcp), with a non-REST/non-HTTP(S) response.
What I found so far
Different people on the net mentioned that using a high port number (like 50k upwards) would be appropriate, since those are not assigned (which makes most sense to me, except they might be altogether blocked)
So others suggest using port 80 or 443, since they rarely get blocked by anyone
Again others suggested using ports like 81 or 8080 (but this seems like the worst of both worlds since 8080 is on the one hand usually used for proxying, on the other hand often blocked for the same reason)
As for me, I am about to implement a simple websockets server on something other than port 80 (if at all feasible), but I am actually even more interested in what to generally pick as a best practice (also UDP).
Thank you all!
Use 80 or 443 not others. For an app I used 8080 but some ISPs blocked that port. To check that I have to add a checking connection when the app starts, if there is no connection a message is sent to a service in port 80, that is why I noticed that it is not good using other ports than 80 or 443.
I'm trying to generate ARP (Address Resolution Protocol) request packets on the iPhone and listen for the associated responses that come back.
Google searches have led me into a dead-end. In order to send logical-layer packets, I'd need something along the lines of a raw socket, but need super-user permissions to create them. I'm trying to avoid jailbreaking my phone.
There's lots of c code out there that can do this, but I can't find anything that can translate to iOS due to the permissions.
I was ready to throw in the towel when I decided to Wireshark a couple network discovery apps I have. Namely "Fing" and "Pinggy" (hats off to Fing and Pinggy btw... awesome apps!)
https://itunes.apple.com/us/app/pinggy/id562201096?mt=8
https://itunes.apple.com/us/app/fing-network-scanner/id430921107?mt=8
Running Wireshark alongside these iPhone apps shows that they do an ARP scan from XXX.XXX.X.0 all the way to XXX.XXX.X.255. I do not see any ICMP packets go out simultaneously with the "ARPs". This leads me to believe that sending and receiving ARP packets are indeed possible on iOS.
I've thought about a ping sweep, assuming that it will generate ARP requests on its own. However, I will still need a raw socket to listen to the responses, correct?
Questions: What's available for sending/receiving packets at the logical layer? Specifically for sending receiving ARP packets? Am I missing anything fundamental?
Thanks in advance!
ARP requests do go out when I attempted to ping the problematic devices. This was seen with a Wireshark session running alongside the ping scanner. I found that I could not reproduce the "missing devices" I was seeing earlier that led me to ask my original question.
So, to answer my own question: ARP requests are sent per IP address when doing a simple ping scan on my subnet. I would see the ARP request go out (using Wireshark) as well as the ping request. If you need to generate an ARP request, simply send out a ping.
Even if the "problematic" device won't respond to ping requests, the ARP table will be notified of its existence.
You can't do what you want to do, and get the app in the AppStore,
since what you are trying to do isn't in the public API.
So one thing you could do, for testing purposes on your own network, or enterprise distributed apps is looking in the private/undocumented APIs.
One such list is maintained at https://github.com/nst/iOS-Runtime-Headers, but I can't vouch for its accuracy.
Good luck!
I am using the Winsock API (not CAsyncSocket) to make a socket that listens for incoming connections.
When somebody tries to connect, how can I get their IP address BEFORE accepting the connection? I am trying to make it only accept connections from certain IP addresses.
Thanks
SO_CONDITIONAL_ACCEPT socket option. Here
Also, pretty sure it's available in XP and Server 2003, not just Vista.
Two reasons why I do not want to accept the connection in order to check the remote IP address:
1). The client would see that there is a listening socket on this port. If i decide to reject the client connection, I would not want them to know that there is a socket listening on this port.
2). This technique is not as efficient and requires more CPU, RAM, and network usage; so it is not good in case of a Denial Of Service attack.
When using ATM, the CONNECT ACK packet will come from the most recent switch, not the end client. So, you would have to call accept() on the socket, then look at the address (based on the passed addr_family), and at that point just close the socket. By the time it reaches the requester, it will probably just get a failure.
And I'm not sure how many resources you think this will take up, but accepting a connection is at a very low level, and will not really be an issue. It's pretty easy to drop them.
If you come under a DoS attack, your code CAN quit listening for a preset amount of time, so the attacker just gets failures, if you are so worried about it.
Does it really matter if the client knows there is a socket listening? Try using telnet to connect to your localhost on port 137 and see how fast the file sharing in windows drops the connection... (If you even have it enabled, and if I remembered the correct port number.. heh..)
But, at the SOCKET level, you are not going to be able to do what you want. You are talking about getting down to the TCP level, and looking at the incoming connection requests, and deal with them there.
This can be done, but you are talking about a Kernel driver to do it. I'm not sure you can do this in user-mode at all.
If you want Kernel help with this, let me know. I may be able to give you some examples, or guidance.
Just my own two cents, and IMVHO...
accept the connection, look at the IP, if it is not allowed, close the connection
Edit:
I'm assuming you're talking about TCP connection. When you listen to the port and a connection comes from a client, the API will perform the TCP 3-way handshake, and the client will know that this port is being listened to.
I am not sure if there is a way to prevent sending any packets (i.e. accepting the connection) so that you can look at the IP address first and then decide.
The only way I can think of is to do packet filtering based on the source IP at the network layer (using firewall, for example).