question about socket with link local addr
Mark Yang <[email protected]>
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Message-ID | <[email protected]> |
Hi,
This looks like a very simple question, but I don't know where do
ask so I post it here.
I start my Mac, my "network" setting shows I have IP "10.1.1.157" since
I am using DHCP,
I created a socket, try to connect to a linklocal addr say
"169.254.80.220". now I find i am using IP "10.1.1.157" to connect
obviously this is not what I want.
Question is how do I create a socket on mac such that the packet i
send out shows my IP LL addr?
Thanks
mark
On Wednesday, July 2, 2003, at 04:47 AM, Philip Nye wrote:
>> From: "Robert Elz" <[email protected]>
>>
>> | The use of "any" implies that two interfaces on the same host and
> connected
>> | to the same link would not recognise each others ARPs as
>> conflicts.
> This is
>> | not independence.
>>
>> No, but nor does anything claim that the interfaces are independent.
>>
>> What it says is to run the algorithm independently on each interface.
>> That is: the order in which the two happen (including in parallel)
>> should be irrelevant, and the results of running the algorithm on the
>> two
>> should in no way depend upon each other. That's all it means.
>
> My issue is this:
>
> If I see a claim for an IP address I already have, then I should
> recognise
> it as a conflict if and only if the claim appears on the interface to
> which
> I have assigned that address.
>
> The fact that the hardware address for a conflicting claim matches one
> of my
> other interfaces is spurious. It does however tell me that that other
> interface is connected to the same link and allows me to resolve the
> conflict internally if I wish (I could also avoid the conflict
> internally
> before it ever occurs) but this is an implementation issue which need
> not
> appear in the document.
>
> On the other hand, if the interfaces happen to be on different links
> then
> seeing a claim for an address I already have on another interface,
> should
> not be seen as a conflict - once again irrespective of hardware
> address.
>