error regarding over-range ip address (socket.connect)

[vins]

i was trying to make port scanner using the references  through this link :-   
http://www.cplusplus.com/articles/o2N36Up4/

so, i want to know  how does the function (constructor IpAddress(address) )resolve the IP address, which are over-range (not allowed for ex:- 256.256.256.256 ) !!!!!

I meant, when i tried to input an IP address like 256.256.256.256 (or and string, which is not a valid address like "vins_net" and port 8080) , the function return value.

here's the source code and screen shot :-

#include <iostream>
#include <SFML/Network.hpp>

bool port_open(const std::string& address, int port)
{
        sf::TcpSocket socket;
        bool open = (socket.connect (sf::IpAddress(address), port)==sf::Socket::Done);
        socket.disconnect();
        return open;
}
int main()
{ std::string address;
  int port;

  std::cout<<"Enter the ip address of the client: ";
  std::cin>>address;

  std::cout<<"\nEnter the port to scan: ";
  std::cin>>port;

  if(port_open(address, port))
          std::cout<<"The port "<<port<<" at IP:"<<address<<" is OPEN."<<std::endl;
  else
          std::cout<<"The port "<<port<<" at IP:"<<address<<" is CLOSED.";

  system("pause");
  return 0;
}
 

[Laurent]

An invalid string will produce a sf::IpAddress::None address. The fact that it succeeds to connect... is a bug caused by an internal implementation detail

[binary1248]

Actually, connecting to INADDR_ANY is permitted, but might not lead to what people might expect. Since sf::IpAddress has to have some way of signalling address resolution failure, you either need to set an extra flag or let the user check whether the address that is returned is plausible or not. The POSIX API obviously adheres to the second option since nothing is allowed to resolve to the broadcast address (which technically isn't even an address) and so it leaves it up to the user to perform sanity checks using the provided constants. The connect() call technically succeeds hence it returns sf::Socket::Done, however no connection establishment took place.

This is less of a bug than just a missing warning in the documentation. The user should be expected to always check the sf::IpAddress against the sf::IpAddress constants before using it in anything else.

This is easy enough to do anyway:

sf::IpAddress my_address( address );

if( my_address == sf::IpAddress::None ) {
        // something went wrong
}
else {
        // connect
}

Rule #1 in secure network programming: Never make use of unsanitized user input.

[Laurent]

Actually, connecting to INADDR_ANY is permitted

What is the reason behind this, what does it mean? I can't find any useful source of information regarding this behaviour.

[binary1248]

http://pubs.opengroup.org/onlinepubs/009695399/functions/connect.html

If the initiating socket is not connection-mode, then connect() shall set the socket's peer address, and no connection is made. For SOCK_DGRAM sockets, the peer address identifies where all datagrams are sent on subsequent send() functions, and limits the remote sender for subsequent recv() functions. If address is a null address for the protocol, the socket's peer address shall be reset.

This is a case where connecting to 0 (or the value of INADDR_ANY) has an intended purpose. The same might be true if doing so on a TCP socket as well, but I was too lazy to test . This could also be a leftover from ancient implementations where it still had a special meaning. connect() is just part of the POSIX API and doesn't take into account more advanced networking semantics. The parameters are probably not checked because it is assumed that e.g. all addresses can be valid in different situations. It is probably passed directly to the network subsystem of the kernel and it is up to the kernel what it wants to do. I wouldn't be surprised if it silently ignores parameters that it has no idea what to do with. It would make sense from an efficiency point of view (and we know how much kernel hackers love efficiency ). This isn't even considering all the other protocols available to be used. TCP and UDP are not the only transport protocols in existence, and each has its own quirks that are probably scarcely documented as well.