Vlad Yasevich writes:
> Ok. First, this is a different bug, so I would prefer a separate patch.
> Also, I see the problem and it's ugly, but this solution is not really correct,
> both conceptually and code wise.
>
> Conceptually, the v4 code should never worry about V4-mapped addresses and shouldn't
> muck with them. They are IPv6 addresses and there should be a clean separation.
>
> Code wise, the code in the __sctp_connect() is terrible.
>
> Does the attached patch work for you in this case.
Sorry about the confusion before, your patch to __sctp_connect()
fixes calls to getpeername() after connect() just fine.
I'll post a patch for the accept()/getpeername() case in a bit.
Acked-by: Dave Johnson <[email protected]>
--
Dave Johnson
Starent Networks
Dave Johnson wrote:
> Vlad Yasevich writes:
>> Ok. First, this is a different bug, so I would prefer a separate patch.
>> Also, I see the problem and it's ugly, but this solution is not really correct,
>> both conceptually and code wise.
>>
>> Conceptually, the v4 code should never worry about V4-mapped addresses and shouldn't
>> muck with them. They are IPv6 addresses and there should be a clean separation.
>>
>> Code wise, the code in the __sctp_connect() is terrible.
>>
>> Does the attached patch work for you in this case.
>
> Sorry about the confusion before, your patch to __sctp_connect()
> fixes calls to getpeername() after connect() just fine.
>
> I'll post a patch for the accept()/getpeername() case in a bit.
>
> Acked-by: Dave Johnson <[email protected]>
>
I had time to tinker and pushed both patches already. They were in
the last pull that Dave Miller did. I also tested both patches locally
to make sure that they worked as supposed to.
-vlad