This reorders all frame sending functions to be at the top of the
file. When reading the file, I tend to be looking at either the
frame code or the state machine, and having them mixed in the file
is confusing. When all frame sending is at the top the remainder
of the file is more readable, in my opinion.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Ever since we refactored beaconing to not be controlled by a
fake queue this parameter to ieee80211_sta_def_wmm_params
has been unused.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ieee80211_sta_start_scan() can very well take a non-NULL
ssid pointer with a zero ssid_len.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When a scan is requested for non-STA interfaces, we simply fire
off a scan, but for STA interfaces we shouldn't because they
could be in the middle of an association. This clarifies the
corresponding code.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now that I've created ht.c, I can move the aggregation
code from main.c into it.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some of the HT code in mlme.c is misplaced:
 * constants/definitions belong to the ieee80211.h header
 * code being used in other modes as well shouldn't be there
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This moves all the BSS list handling out of mlme.c to scan.c,
no further changes except fixing kzalloc/atomic_inc/atomic_inc
to kzalloc/atomic_set(2).
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch refactors some code and moves the scan RX function
to scan.c. More importantly, however, it changes it so that the
MLME's beacon/probe_resp functions aren't invoked when scanning
so that we can remove a "if (scanning)" conditions from two
places.

There's a very slight behavioural change in this patch: now,
when scanning, IBSS and mesh aren't updated even on the same
channel.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Here's a first patch to move some code from mlme.c to a
new file called scan.c. The end result will hopefully be
a more manageable mlme.c.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I'm surprised nobody complained about these before. What a waste.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since we now use sdata pointers most of the time, using a netdev
pointer here is somewhat artificial, use an sdata pointer instead.
Replace a netdev-prefix in a few messages by a wiphy-prefix.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reorders the mlme code a bit so we don't need all the forward
function declarations. It also removes the ERP_INFO_USE_PROTECTION
define that is unused, but otherwise contains no real changes.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

During testing of the disassociation fixes, Tomas noticed that it
was possible to run into a situation where you'd suddenly get a
few "wlan0: dropped frame to <AP> (unauthorized port)" messages
and I found this to be due to the AP's sta_info having been
removed but netif_carrier_off not having removed/stopped traffic
yet. To avoid that, stop the queue for the interface (and avoid
bringing them up when another vif scans when they weren't up.)
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch moves disassociation code from ieee80211_set_associated
to ieee80211_set_disassoc. To reduce code duplication, it introduces
the ieee80211_sta_send_apinfo function. Additionally, it fixes a lapse
where BSS_CHANGED_HT wasn't set when notifying the driver of changes
due to disassociation.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch makes the MLME cleanly disassociate from the current BSS
when leaving it for a new one. This is not just nicer to the old AP
(we're leaving it, might as well tell it!) but also required for some
drivers that keep track of the station we're associated with, they'd
get confused because they'd think we are associated with two APs.
Signed-off-by: NRon Rindjunsky <ron.rindjunsky@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch restructure the flow of disassociation and deauthentication
flows to be consistent under all circumstances.
It ensures that BA session is treated down before deauthentication or disassociation,
adds the removal of the obsolete sta form station table and fixes a related bug (sta_info_destroy
without sta_info_unlink) in ieee80211_associated()
and reduce some code duplication
Signed-off-by: NRon Rindjunsky <ron.rindjunsky@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since IE parsing is required for the mlme and mesh code, it's
not a static function anyway, and it's much better to have it
in util rather than the overly large mlme.c
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This says chan_switch.action_code but really means
measurement.action_code, of course the actual offset in
the frame is the same, it's just harder to understand
this way.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The action frame length checks are one too small, there's not just
an action code as the comment makes you believe, there's a category
code too, and the category code is required in each action frame
(hence part of IEEE80211_MIN_ACTION_SIZE).
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When we receive information about a BSS we check at some point
whether or not we think we're allowed to use the channel it is
on, but we do that fairly late. I don't think we should do it
that late, so do it earlier to avoid doing IBSS/mesh stuff on
that channel and then getting confused because it's disabled.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The conf_tx callback currently needs to be atomic, this requirement
is just because it can be called from scanning. This rearranges it
slightly to only update while not scanning (which is fine, we'll be
getting beacons when associated) and thus removes the atomic
requirement.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The if itself doesn't need to be protected, so move in the RCU
locking to avoid doing anything at all when the condition isn't
true.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch follows 11n spec naming more rigorously replacing MIMO_PS
with SM_PS (Spatial Multiplexing Power Save).

(Originally submitted as 4 patches, "mac80211: change MIMO_PS to SM_PS",
"iwlwifi: change MIMO_PS to SM_PS", "ath9k: change MIMO_PS to SM_PS",
and "iwlwifi: remove double definition of SM PS". -- JWL)
Signed-off-by: NRon Rindjunsky <ron.rindjunsky@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Johannes Berg reported that occaisionally, bringing an interface
down or unregistering it would hang for up to 30 seconds.  Using
debugging output he provided it became clear that ICMP6 routes
were the culprit.

The problem is that ICMP6 routes live in their own world totally
separate from normal ipv6 routes.  So there are all kinds of special
cases throughout the ipv6 code to handle this.

While we should really try to unify all of this stuff somehow,
for the time being let's fix this by purging the ICMP6 routes
that match the device in question during rt6_ifdown().
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Otherwise entries stay on the GC todo list forever, even after we free
them.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Now that we save states within a walk we need synchronisation
so that the list the saved state is on doesn't disappear from
under us.

As it stands this is done by keeping the state on the list which
is bad because it gets in the way of the management of the state
life-cycle.

An alternative is to make our own pseudo-RCU system where we use
counters to indicate which state can't be freed immediately as
it may be referenced by an ongoing walk when that resumes.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The previous default behavior is definitely the least user
friendly.  Hanging there forever just because the keying
daemon is wedged or the refreshing of the policy can't move
forward is anti-social to say the least.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fixes kernel bugzilla 11469: "TUN with 1024 neighbours:
ip6_dst_lookup_tail NULL crash"

dst->neighbour is not necessarily hooked up at this point
in the processing path, so blindly dereferencing it is
the wrong thing to do.  This NULL check exists in other
similar paths and this case was just an oversight.

Also fix the completely wrong and confusing indentation
here while we're at it.

Based upon a patch by Evgeniy Polyakov.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The commit commit 4c563f76 ("[XFRM]:
Speed up xfrm_policy and xfrm_state walking") inadvertently removed
larval states and socket policies from netlink dumps.  This patch
restores them.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

as it accentally contained the wrong set of patches. These will be
submitted separately.
Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>

The Security Mode 4 of the Bluetooth 2.1 specification has strict
authentication and encryption requirements. It is the initiators job
to create a secure ACL link. However in case of malicious devices, the
acceptor has to make sure that the ACL is encrypted before allowing
any kind of L2CAP connection. The only exception here is the PSM 1 for
the service discovery protocol, because that is allowed to run on an
insecure ACL link.

Previously it was enough to reject a L2CAP connection during the
connection setup phase, but with Bluetooth 2.1 it is forbidden to
do any L2CAP protocol exchange on an insecure link (except SDP).

The new hci_conn_check_link_mode() function can be used to check the
integrity of an ACL link. This functions also takes care of the cases
where Security Mode 4 is disabled or one of the devices is based on
an older specification.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

With the introduction of Security Mode 4 and Simple Pairing from the
Bluetooth 2.1 specification it became mandatory that the initiator
requires authentication and encryption before any L2CAP channel can
be established. The only exception here is PSM 1 for the service
discovery protocol (SDP). It is meant to be used without any encryption
since it contains only public information. This is how Bluetooth 2.0
and before handle connections on PSM 1.

For Bluetooth 2.1 devices the pairing procedure differentiates between
no bonding, general bonding and dedicated bonding. The L2CAP layer
wrongly uses always general bonding when creating new connections, but it
should not do this for SDP connections. In this case the authentication
requirement should be no bonding and the just-works model should be used,
but in case of non-SDP connection it is required to use general bonding.

If the new connection requires man-in-the-middle (MITM) protection, it
also first wrongly creates an unauthenticated link key and then later on
requests an upgrade to an authenticated link key to provide full MITM
protection. With Simple Pairing the link key generation is an expensive
operation (compared to Bluetooth 2.0 and before) and doing this twice
during a connection setup causes a noticeable delay when establishing
a new connection. This should be avoided to not regress from the expected
Bluetooth 2.0 connection times. The authentication requirements are known
up-front and so enforce them.

To fulfill these requirements the hci_connect() function has been extended
with an authentication requirement parameter that will be stored inside
the connection information and can be retrieved by userspace at any
time. This allows the correct IO capabilities exchange and results in
the expected behavior.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The ACL config stage keeps holding a reference count on incoming
connections when requesting the extended features. This results in
keeping an ACL link up without any users. The problem here is that
the Bluetooth specification doesn't define an ownership of the ACL
link and thus it can happen that the implementation on the initiator
side doesn't care about disconnecting unused links. In this case the
acceptor needs to take care of this.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Instead of duplicating the fields, integrate a user stats structure into
the kernel stats structure. This is more robust when the members are
changed, because they are now automatically kept in sync.
Signed-off-by: NSven Wegener <sven.wegener@stealer.net>
Reviewed-by: NJulius Volz <juliusv@google.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>

Instead of checking the value in include/net/ip_vs.h, we can just
restrict the range in our Kconfig file. This will prevent values outside
of the range early.
Signed-off-by: NSven Wegener <sven.wegener@stealer.net>
Reviewed-by: NJulius Volz <juliusv@google.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>

Remove an incorrect ip_route_me_harder() that was probably a result of
merging my IPv6 patches with the local client patches. With this, IPv6+NAT
are working again.
Signed-off-by: NJulius Volz <juliusv@google.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>

Now that LVS can load balance locally generated traffic, packets may come
from the loopback device and thus may have a partial checksum.

The existing code allows for the case where there is no checksum at all for
TCP, however Herbert Xu has confirmed that this is not legal.
Signed-off-by: NSimon Horman <horms@verge.net.au>
Acked-by: NJulius Volz <juliusv@google.com>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Acked-by: NStephen Hemminger <shemming@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Bridge as netdevice doesn't cross netns boundaries.

Bridge ports and bridge itself live in same netns.

Notifiers are fixed.

netns propagated from userspace socket for setup and teardown.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Acked-by: NStephen Hemminger <shemming@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

this patch turns the netdev timeout WARN_ON_ONCE() into a WARN_ONCE(),
so that the device and driver names are inside the warning message.
This helps automated tools like kerneloops.org to collect the data
and do statistics, as well as making it more likely that humans
cut-n-paste the important message as part of a bugreport.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>