Port Scanning

No, it's not close to a good idea. What it might do is bring your network administrator down on your head. And it won't be particularly quick anyway as you're supposed to be waiting for a response from the target system. Just let the ports be configurable.

Are those client or server ports?

It's best not to do naughty things, particularly not without the user's permission.

Sending out a lot of requests may cause denial of service problems behind NAT devices, as you may exhaust the available number of NAT rules (or there may be a limit per host, so you only deny yourself service).

You should not be using well-known ports on the client side anyway, it's poor etiquette.

Mark

Pick one port as your "standard" port. Try to use that. If it doesn't work, inform the user of the problem. Let the user pick an override port through a settings dialog.

Common now, I'm not a jackass. The output port is configurable. It is normally set to 0, which allows the OS to determine the port (usually around 1024-1030).

I'm trying to determine an open port to send from on the client's side.

You think it would bring the network admin trouble? I'm just trying to send from a lot of ports.

It wouldn't take a gross amount of time. It's not like I'm going to send 1 packet, then wait. I'm going to send about 1000 packets, then check for a reply from all of them.

Yes, the network admin wouldn't like it, and such things tend to come up on their radar very quickly. It probably would take a 'gross' amount of time - have you tried running a port scanner yourself? The time consumed is nothing to do with the packet you send, it's to do with establishing the connection, and firewalled ports tend to fail silently and slowly.

Quote:

Original post by Kylotan The time consumed is nothing to do with the packet you send, it's to do with establishing the connection, and firewalled ports tend to fail silently and slowly.

It will only have to establish a connection if the packet gets through. So I will only be establishing one connection. Firewalled ports may fail silently, but I don't see how they could fail slowly. Either the packet gets to its destination in ~30ms or it doesn't. Firewalls don't slow down packets.

I don't understand how the time consumed has nothing to do with sending the packets. Nothing else in the equation takes time from the program's point of view. The prog would have to:
a) create 65000 sockets and bind them to a certain port
b) send up to 65000 packets for a total of about 2.1 megs of data
c) listen for a packet on up to 65000 ports with multiple select calls
d) receive one packet (if we get through)

Now obviously I wouldn't do those in that order. I'd probably try to batch around 500 at a time. And those 500 wouldn't be 1024-1524, I would make sure to jump around and intelligently search in the hopes that there was a batch of open ports.

What really concerns me is that professional games work behind the router that initiated this problem. Although most every game uses TCP, even games like Battlefield 2 work fine... and I fail to believe they fall back on a TCP network plan.

Quote:

Original post by Kylotan Yes, the network admin wouldn't like it, and such things tend to come up on their radar very quickly. It probably would take a 'gross' amount of time - have you tried running a port scanner yourself? The time consumed is nothing to do with the packet you send, it's to do with establishing the connection, and firewalled ports tend to fail silently and slowly.

Yep. A thorough port scan takes a "gross" amount of time. A faster approach may be to do the opposite, that is, list all TCP and UDP endpoints on your system, eg: TCPView.

Are you sure your network is filtering SOURCE ports? Most of the time, it's destination ports that are the problem.

Note that UDP, being lossy, is exceptionally hard to do solid port detection for. If you send 1000 messages, each of which is 32 bytes, then the router might only have space for 500, and dump the other 500 on the floor. You don't know if the reason you didn't get an answer was that the port is blocked, or you just exceeded some queue or bandwidth capacity somewhere.

Quote:

Original post by hplus0603 Are you sure your network is filtering SOURCE ports?

Yeah, I was pretty disappointed to find out that not even the initial packet made it to my server.

I never expected it to be easy to port scan all 65000 ports... but it is really my only option. Well, the other option would be to fall back on a TCP system, but that would give me more overhead than I want. I've heard that Battlefield 2 actually falls back to TCP if the UDP is blocked. This would explain why it works from the same place that I can't get to work with my prog. Could this be true?

And its mildly okay if it takes a "gross" amount of time. Although, I'm pretty sure that it won't take any longer than uploading 2 megs of data, I may have to do it 2-3 times to make sure my packet isn't getting dropped. Yes, there are a lot of other factors that will kill performance and reliability, but this is all going to happen when the player is playing single player. And once it works, the port gets saved and it never has to execute again.

None of that really matters though, because I've heard industry routers/switches will blacklist IP's that are "hacking" like this. Can anybody confirm this?

I mentioned that port scanning was my only option in the previous post... well, its just the only one I know will work (pending the router/switch blacklist situation).

Some other ideas I had (and if you didn't like port scanning, you won't like these):

-Construct my own raw packets and fake a TCP or at least don't send an exact UDP header. Basically, try to find out what the switch is filtering out and change it. The problem being, this requires admin privileges on the PC running the prog.

-Take over an OS port. 21, 23, 80... there are a lot of ports that I could tap into in hopes that the switch does not filter UDP on these ports.

-I could try to "massage" the port by starting a TCP connection, and then switching over to UDP. But, I have no idea if the filter works like this.

Yes, many games will try to fall back to TCP if UDP doesn't work.

Yes, there are routeres that will detect port scanning and blacklist the source.

No, you cannot "massage" a connection by switching between TCP and UDP -- they are totally different address spaces. Port 1234 for TCP has nothing to do with port 1234 for UDP.

Quote:

Original post by hplus0603 Port 1234 for TCP has nothing to do with port 1234 for UDP.

What!? Really? How can that be? Are you telling me I can send/recv on port 1234 TCP in one thread, and sendto/recvfrom port 1234 UDP in another thread?

I was under the assumption that the port was physically the same thing, the only differnce in TCP and UDP was the header of the message... and, of course, the way winsock subsystem guarantees the send.

Quote:

Original post by blaze02 Quote: Original post by hplus0603 Port 1234 for TCP has nothing to do with port 1234 for UDP. What!? Really? How can that be? Are you telling me I can send/recv on port 1234 TCP in one thread, and sendto/recvfrom port 1234 UDP in another thread? I was under the assumption that the port was physically the same thing, the only differnce in TCP and UDP was the header of the message... and, of course, the way winsock subsystem guarantees the send.

hplus is correct. The ports are unrelated. The TCP and UDP implementations on the system do not talk. To understand this, think of the network stack. Incoming data on Ethernet has a "port" specifying what protocol to use, here IP. Incoming IP packets have a "port" showing what higher-level protocol to use, which will usually be TCP or UDP. TCP and UDP happen to both use a similar-looking port system out of convenience, but IP itself knows nothing of ports.

well as both above posts say, a port can blocked on TCP and open on UDP.
they are not the same, I used to have the same port for a udp and a tcp packet on my network engine :P
blaze02: i dt think IT dept. will notice anyth if u blow up the bandwidth lol :)
damn dit IT dept :@

Quote:

Original post by blaze02 I was under the assumption that the port was physically the same thing, the only differnce in TCP and UDP was the header of the message

'Physically' the port is only in the header of the message too. It's just a number, nothing more, that allows an operating system to determine which process needs a given bit of data.

Quote:

Original post by blaze02 I mentioned that port scanning was my only option in the previous post... well, its just the only one I know will work (pending the router/switch blacklist situation). Some other ideas I had (and if you didn't like port scanning, you won't like these): -Construct my own raw packets and fake a TCP or at least don't send an exact UDP header. Basically, try to find out what the switch is filtering out and change it. The problem being, this requires admin privileges on the PC running the prog. -Take over an OS port. 21, 23, 80... there are a lot of ports that I could tap into in hopes that the switch does not filter UDP on these ports. -I could try to "massage" the port by starting a TCP connection, and then switching over to UDP. But, I have no idea if the filter works like this.

Consider nmap, which has a Paranoid setting for portscanning. At least you won't (potentially) be detected.

Quote:

Original post by blaze02 Quote: Original post by hplus0603 Port 1234 for TCP has nothing to do with port 1234 for UDP. Are you telling me I can send/recv on port 1234 TCP in one thread, and sendto/recvfrom port 1234 UDP in another thread?

Since nobody answered my question specifically, I'll assume from the above posts that:
Yes, you can safely thread the same port if one is UDP and the other is TCP.

I still don't quite believe the UDP and TCP ports are unrelated. Also, how does that work with raw sockets?

Quote:

Yes, you can safely thread the same port if one is UDP and the other is TCP. I still don't quite believe the UDP and TCP ports are unrelated. Also, how does that work with raw sockets?

We actually answered this explicitly. Yes, you can use both at the same time for different purposes with no risk of interference.

For raw sockets, you don't bind to a specific port; you bind to a protocol number (or maybe even to just a device). It's up to you to decode the protocol and ports in that case.

I suggest you read up on the basic OSI layer model of networking, or maybe even a good TCP book such as TCP/IP Illustrated.

I pretty much wrote off the idea after learning that most good routers will blacklist IPs that do this sort of thing. I can't imagine the IT guy raising too big of a fuss. Every student in our networking class made a port scanner and used it inside the building playing our little hide-and-seek networking games.