[PATCH 2/3] P2P: always re-select oper channel if not hard coded

[Jouni Malinen]

On Tue, Dec 25, 2012 at 09:49:52PM +0200, Arik Nemtsov wrote:
> Note this change is essential to make patch 3/3 regarding HT40 (which
> you applied) work correctly.

Does the HT40 patch do any harm on its own, i.e., do I need to revert
it?

> We would never call p2p_reselect_channel() normally, since
> p2p_channels_includes(p2p->op_channel) always returns true. This is
> because p2p->op_channel = 1/6/11 from the p2p init code..

I see.. This may need changes, but this patch 2/3 is not enough to
address this.

> I'm attaching a new version of this patch, which includes the fix to
> p2p_process_go_neg_resp() I mentioned. It is rebased on the (close to)
> latest code.

This seems to break frequency specification as a p2p_connect parameter.
That case must not allow the p2p_reselect_channel() mechanisms to change
the forced channel. In addition, the debug log entry in the beginning of
p2p_reselect_channel() is quite confusing if the function gets called
with the new reason since the peer did not really reject the selected
channel in that case.

-- 
Jouni Malinen                                            PGP id EFC895FA