Say I've got a file descriptor from socket(2) and I've done a connect(2) on it -- is there any way later to determine (from inside the running program) what network device might be in use for the underlying transport? A call to stat(2) on the fd gives a device number of 0; none of the ioctl(2) or getsockopt(2) options seem applicable.
There's no foolproof way to do so -- certainly not a posix-compliant way.
However, in practice, you can easily determine the interface 99% of the time. After you've done the connect, use getsockname to obtain the IP address, then look through the list of available interfaces on the box for one with a matching IP address.
From the accept call you should be able to get the remote client's ip address (seen here on Beej's). Assuming you do not have any asymmetric routes, you can look up the route to that address in your local routing table. The routing table should tell you what ethernet device is used to send packets to the remote client.
EDIT:
you could use the following command line tool to query your local routing table with the remote client's address:
ip route get <remote-client-ip-addr>
Related
I am new to sipp and network concepts i got a contact header
"Fin Tax" <sip:b2fdfc58-b7f2-a482-572c-8dbc1aae24#10.195.1.41:5060>;+
"ip.instance="urn:uuid:00000000-0000-0000-0000-34db8dc64>";+
u.sip!devicename="ATA34DBFD8DC64"4DBFD18DC64";+u.sip!model.cc.co.com="681"
Can you explain this contact paramerter i know the first part uri but what are next parameters
First parameter is +sip.instance (the double quote after + in the example above is a typo for sure), which is defined by IETF, it can be found in SIP Outbound (RFC5626) and GRUU (RFC5627):
https://www.rfc-editor.org/rfc/rfc5626
https://www.rfc-editor.org/rfc/rfc5627
Its purpose is to identify uniquely a device, independent of contact address (which can change in case of roaming around wifi hotspots or 4G/5G networks) or multiple connections, but contact addresses can also overlap when devices are located in private networks using same IP range.
Usually its value is build using a UUID (universally unique identifier), which should reduce the risk of duplicate values for users with multiple devices. Its uniqueness allows SIP Registrar Server to identify what contact record to update or remove when processing REGISTER requests from the same device.
The next two parameters prefixed with +u.sip! seem to be custom parameters set by the sending SIP UA. They look like specific to some CISCO equipment, probably a gateway. In general, SIP specifications tell that custom parameters can be ignored by receiving UA, if it does not know how to interpret them.
I'm interested to know, how does WSAIoctl() with the SIO_ROUTING_INTERFACE_QUERY control code create the list of IP addresses of my host machine? In particular, what criteria does it use to order the IP addresses?
It only returns one! From MSDN (emphasis mine):
SIO_ROUTING_INTERFACE_QUERY (opcode setting: I, O, T==1)
To obtain the address of the local interface (represented as sockaddr structure) that should be used to send to the remote address specified in the input buffer ...
It's true that multiple routes to the destination address might exist, in which case it will no doubt pick the cheapest (routing table entries each contain a cost, or metric, see here).
Or did you mean SIO_ADDRESS_LIST_QUERY?, in which case Windows knows full well what network interfaces you have installed on your machine and the order in which they are returned is supremely unimportant.
http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.progcomm%2Fdoc%2Fprogcomc%2Fskt_bind.htm
Internet domain:
Produces an association composed of local and foreign addresses and local and foreign ports.
UNIX domain:
Produces an association composed of local and foreign path names.
NDD domain (Network Device Driver of the operating system):
Provides an association composed of local device name (operating system NDD
name) and foreign addresses, the form of which depends on the protocol
being used.
They talk about association composed of local and foreign addresses.
What exactly does that mean.
I can understand the local address, but what's with the foreigh addresses, how does it find them, and which are they, and how does it create their association?
The local and foreign socket addresses are simply the address of your program (the local one) and the address of the other program you are communicating with (the foreign one).
Different programs use different mechanisms to determine that foreign address. For example:
To view a Web page, you type in a desired URL or click on a link; the URL contains a name, and the address associated with the name is looked up and connected to in order to retrieve the resource.
To look up an address from a name, your computer will contact a name server at a different designated address. The address of the name server is itself often obtained from another protocol, DHCP.
To locate a DHCP server, your computer will send a broadcast message to all machines on the local network, then wait for a server to reply.
Associations can also vary depending upon whether a protocol is connection-based or connectionless.
In a connection-based protocol such as TCP, this association is called a connection; messages are exchanged between the network subsystems of the two machines to negotiate the set-up of the connection, and this connection persists until explicitly closed.
In a connectionless protocol such as UDP, a simple facility to send and receive individual messages to or from any addressing-compatible endpoint is provided; any associations are entirely at the convenience of the software using the protocol.
Below is a sample invoking of getaddrinfo()
status = getaddrinfo("www.example.net","1234", &hints, &server_info);
After that, the server_info will point to a linked list with all kinds of address information.
I have the following questions:
Since I have clearly specified the host name and port number, the only address infos I can think of are IPv4 and IPv6 addresses. So, the length of the linked list should be 2. Is there any other kind of address info besides them?
Thanks.
The name could resolve to more than one IPv4 or IPv6 address, there is nothing to say that only one IPv4 address will be returned, for example (try it with "www.google.com" for example, you'll likely get more than one IPv4 address).
But in any case, I think the basic premise of your question is wrong. Even if there was no possibility to return more than one IPv4 and one IPv6 address today, the function is documented to return an arbitrarily-long linked list of addrinfo objects. Therefore, even if your code worked today in every situation, there is no guarantee that it would continue to work tomorrow. If the function is documented to return an arbitrarily-long linked list, then you need to be able to handle that.
You want to disconnect the physical configuration of machines with names in your mind. DNS merely maps a name to a set of addresses. A lot of hosts will only have one interface. Many hosts will have multiple (called multi-homing). DNS doesn't care about what the configuration of the machine or machines that the addresses it maps a name to is. As simple examples often a server will have interfaces on multiple networks with different addresses that will all map to the same name. Sometimes when collapsing services from different machines onto one different names will map to the same address. So don't assume any sort of 1:1 mapping between names and machines much less interfaces.
When browsers look up hostnames, do they do that even when the "host name" is an IP address? For instance http://74.125.39.105/ goes to some Google servers. Will this result in a DNS lookup on common browsers and platforms, such as Safari, IE, Firefox, Chrome, Opera, Windows, Linux, Mac OSX?
Or will the browser (in the common case) just start a connection directly without trying a DNS lookup first?
There is no DNS lookup done if the entire host part is numeric in nature. It could be in dotted quad format, or a single unsigned 32 bit integer. I haven't tested IPv6 yet.
There's no point in performing a lookup as there are no authoritative DNS records for these numeric "names".
Some recursive nameservers (e.g. dnscache) will respond to these kind of queries with the corresponding IP address, as if there was a real record of the form:
74.125.39.105. IN A 74.125.39.105
but this is, I assume, intended to deal with simplistic clients that assume everything is a DNS name. The most common nameserver, BIND, doesn't have this behaviour though - so don't rely on it.