Re: bsd sockets + selecting network interface
Re: bsd sockets + selecting network interface
- Subject: Re: bsd sockets + selecting network interface
- From: james woodyatt <email@hidden>
- Date: Tue, 16 Dec 2008 12:13:04 -0800
On Dec 16, 2008, at 11:36, Joe Lake wrote:
[I wrote:]
This might be an error with your client handling IPv6 socket
addresses, i.e. you didn't set the sin6_scope_id field properly, or
it might be an error caused by the server not being attached to the
network where the client host's primary active interface is
attached, while the server is advertising an IPv4 address in mDNS
outside the client's configured subnet.
I'm not sure I understand. At this point, I'm only using IPv4. Is
what I'm trying to do only possible with IPv6?
It depends on the scope of what you're trying to do. In general, it's
not possible to do what you want with IPv4 in all the possible
variations of network topology that may exist in the field. On the
other hand, if you aren't concerned with IPv4 corner cases, then you
may be able to get what you want in the most common cases by just
avoiding address realm conflicts and making sure that DHCP
configurations are correct everywhere.
If you can use IPv6_LINK_LOCAL, then everything is just brain-stoopid
simple to do. (Unless you have the problem that ethernet NIC hardware
generally doesn't support TCP/UDP checksum offloading for IPv6.)
Let's suppose the server is advertising the service on a network
that is not attached to the client's primariy interface, but instead
to the client's secondary interface. The client still discovers
this service, but when it tries to communicate with it, the datagram
goes out the wrong (primary) interface. How do I make the client
send out the secondary interface?
Is the packet that your client transmits on the "wrong" interface
addressed to the correct destination address? Is that destination not
in a subnet assigned to the secondary interface of the client host?
If the answers to both those questions are Yes, then your problem is
that the server isn't advertising its addresses correctly. If the
answer to the first question is No, then the error must be in setting
the destination address for the packet. Otherwise, if the answer to
the second question is No, then the error is probably that the primary
and secondary interfaces are attached in conflicting address realms.
--
james woodyatt <email@hidden>
member of technical staff, communications engineering
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden