RE: Incorrect IPv6 link local address assigned to adapter

NDIS 5 or 6, just to be clear?

You only have control over the MAC address via your response to
OID_802_3_PERMANENT_ADDRESS and OID_802_3_CURRENT_ADDRESS. The problem
will be somewhere higher in the stack.

Bryan S. Burgin


This posting is provided "AS IS" with no warranties, and confers no rights.

The driver is NDIS 5.1.

Is it possible that the OUI of the MAC address is not recognized by the
stack and this is why a proper link local address is not created? I suppose
an easy way to test this out is just to change the OUI to something more
common to make sure it's not the OUI itself...

""Bryan S. Burgin [MSFT]"" wrote:

> NDIS 5 or 6, just to be clear?
>
> You only have control over the MAC address via your response to
> OID_802_3_PERMANENT_ADDRESS and OID_802_3_CURRENT_ADDRESS. The problem
> will be somewhere higher in the stack.
>
> Bryan S. Burgin
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights

I found the issue, by chance. A query for an OID (0xff54554e to be exact)
returned success instead of not supported. After fixing this, the link local
address was correct.

Do you know what this OID is used for?

""Bryan S. Burgin [MSFT]"" wrote:

> NDIS 5 or 6, just to be clear?
>
> You only have control over the MAC address via your response to
> OID_802_3_PERMANENT_ADDRESS and OID_802_3_CURRENT_ADDRESS. The problem
> will be somewhere higher in the stack.
>
> Bryan S. Burgin
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights

I looked through the WDK (build 6000/Vista RTM) for that value and anything
that started with OID_ and didn't find it, either. It strikes me odd that
it can also be viewed in ASCII as 'NUT\ff'. Returning NOT_SUPPORTED is the
right thing to do in this case. Perhaps setting a breakpoint when you
receive this and then dump the stack trace will lend some insight on who is
issuing this.

Bryan S. Burgin


This posting is provided "AS IS" with no warranties, and confers no rights.

""Bryan S. Burgin [MSFT]"" <> wrote in message news:...
> It strikes me odd that
> it can also be viewed in ASCII as 'NUT\ff'.

May be, "TUN" ?

--PA

Maybe it's wishful thinking, but TUN makes some sense in the context that
when the driver returned success for this OID, the adapter had the same link
local address as the Toredo tunneling adapter.

"Pavel A." wrote:

> ""Bryan S. Burgin [MSFT]"" <> wrote in message news:...
> > It strikes me odd that
> > it can also be viewed in ASCII as 'NUT\ff'.
>
> May be, "TUN" ?
>
> --PA
>
>
>

Aren't OIDs that begin with "0xFF" vendor-proprietary OIDs?

Thomas

"DW" <> wrote in message
news:7660FEAE-E874-4C8D-A497-...
>I found the issue, by chance. A query for an OID (0xff54554e to be exact)
> returned success instead of not supported. After fixing this, the link
> local
> address was correct.
>
> Do you know what this OID is used for?
>
> ""Bryan S. Burgin [MSFT]"" wrote:
>
>> NDIS 5 or 6, just to be clear?
>>
>> You only have control over the MAC address via your response to
>> OID_802_3_PERMANENT_ADDRESS and OID_802_3_CURRENT_ADDRESS. The problem
>> will be somewhere higher in the stack.
>>
>> Bryan S. Burgin
>>
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights

Thomas F. Divine [MVP] wrote:
> Aren't OIDs that begin with "0xFF" vendor-proprietary OIDs?

Absolutely. And they are all optional by nature.

Stephan