The previous patch made cfg80211 generally aware of the signal
type a given hardware will give, so now it can implement
SIOCGIWRANGE itself, removing more wext stuff from mac80211.
Might need to be a little more parametrized once we have
more hardware using cfg80211 and new hardware capabilities.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It wasn't a good idea to make the signal type a per-BSS option,
although then it is closer to the actual value. Move it to be
a per-wiphy setting, update mac80211 to match.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's no particular reason to not let untrusted users see
this information -- it's just the stations we're talking to,
packet counters for them and possibly some mesh things.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Due to various bugs in the software stack we end up having
to fill qual.qual; level should be used, but wpa_supplicant
doesn't properly ignore qual.qual, NM should use qual.level
regardless of that because qual.qual is 0 but doesn't handle
IW_QUAL_DBM right now.
So fill qual.qual with the qual.level value clamped to
-110..-40 dBm or just the regular 'unspecified' signal level.
This requires a mac80211 change to properly announce the
max_qual.qual and avg_qual.qual values.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Scanned BSS entries are timestamped with jiffies, which doesn't
increment across suspend and hibernate. On resume, every BSS in the
scan list looks like it was scanned within the last 10 seconds,
irregardless of how long the machine was actually asleep. Age scan
results on resume with the time spent during sleep so userspace has a
clue how old they really are.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The TX/RX packet counters are needed to fill in RADIUS Accounting
attributes Acct-Output-Packets and Acct-Input-Packets. We already
collect the needed information, but only the TX/RX bytes were
previously exposed through nl80211. Allow applications to fetch the
packet counters, too, to provide more complete support for accounting.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This extends the NL80211_CMD_TRIGGER_SCAN command to allow applications
to specify a set of information element(s) to be added into Probe
Request frames with NL80211_ATTR_IE. This provides support for the
MLME-SCAN.request primitive parameter VendorSpecificInfo and can be
used, e.g., to implement WPS scanning.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add empty function for case of CONFIG_NL80211=n:
net/wireless/scan.c:35: error: implicit declaration of function 'nl80211_send_scan_aborted'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The AP can switch dynamically between 20/40 Mhz channel width,
in which case we switch the local operating channel, but the
rate control algorithm is not notified. This patch adds a new callback
to indicate such changes to the RC algorithm.
Currently, HT channel width change is notified, but this callback
can be used to indicate any new requirements that might come up later on.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch splits out the ibss code and data from managed (station) mode.
The reason to do this is to better separate the state machines, and have
the code be contained better so it gets easier to determine what exactly
a given change will affect, that in turn makes it easier to understand.
This is quite some churn, especially because I split sdata->u.sta into
sdata->u.mgd and sdata->u.ibss, but I think it's easier to maintain that
way. I've also shuffled around some code -- null function sending is only
applicable to managed interfaces so put that into that file, some other
functions are needed from various places so put them into util, and also
rearranged the prototypes in ieee80211_i.h accordingly.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hardware with AMPDU queues currently has broken aggregation.
This patch fixes it by making all A-MPDUs go over the regular AC queues,
but keeping track of the hardware queues in mac80211. As a first rough
version, it actually stops the AC queue for extended periods of time,
which can be removed by adding buffering internal to mac80211, but is
currently not a huge problem because people rarely use multiple TIDs
that are in the same AC (and iwlwifi currently doesn't operate as AP).
This is a short-term fix, my current medium-term plan, which I hope to
execute soon as well, but am not sure can finish before .30, looks like
this:
1) rework the internal queuing layer in mac80211 that we use for
fragments if the driver stopped queue in the middle of a fragmented
frame to be able to queue more frames at once (rather than just a
single frame with its fragments)
2) instead of stopping the entire AC queue, queue up the frames in a
per-station/per-TID queue during aggregation session initiation,
when the session has come up take all those frames and put them
onto the queue from 1)
3) push the ampdu queue layer abstraction this patch introduces in
mac80211 into the driver, and remove the virtual queue stuff from
mac80211 again
This plan will probably also affect ath9k in that mac80211 queues the
frames instead of passing them down, even when there are no ampdu queues.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 currently assumes init_net for all interfaces,
so really will not cope well with network namespaces,
at least at this time.
To change this, we would have keep track of the netns
in addition to the ifindex, which is not something I
want to think about right now.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is possible that some broken AP might send HT IEs in it's
assoc response even though the STA has not sent them in assoc req
when WEP/TKIP is used as pairwise cipher suite. Also it is important
to check this bit before enabling ht mode in beacon receive path.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drr_change_class lacks a check for NULL of tca[TCA_OPTIONS], so oops
is possible.
Reported-by: Denys Fedoryschenko <denys@visp.net.lb>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add RDS Kconfig and Makefile, and modify net/'s to add
us to the build.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Although most of IB and iWARP are separated from each other,
there is some common code required to handle their shared
CM listen port. This code listens for CM events and then
dispatches the event to the appropriate transport, either
IB or iWARP.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Support for iWARP NICs is implemented as a separate
RDS transport from IB. The code, however, is very
similar to IB (it was forked, basically.) so let's keep
it in one changeset.
The reason for this duplicationis that despite its similarity
to IB, there are a number of places where it has different
semantics. iwarp zcopy support is still under development,
and giving it its own sandbox ensures that IB code isn't
disrupted while iwarp changes. Over time these transports
will re-converge.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Header parsing, ring refill. It puts the incoming data into an
rds_incoming struct, which is passed up to rds-core.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Specific to IB is a credits-based flow control mechanism, in
addition to the expected usage of the IB API to package outgoing
data into work requests.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Registers as an RDS transport and an IB client, and uses IB CM
API to allocate ids, queue pairs, and the rest of that fun stuff.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some transports may support RDMA features. This handles the
non-transport-specific parts, like pinning user pages and
tracking mapped regions.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Upon receiving a datagram from the transport, RDS parses the
headers and potentially queues an ACK.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Parsing of newly-received RDS message headers (including ext.
headers) and copy-to/from-user routines.
page.c implements a per-cpu page remainder cache, to reduce the
number of allocations needed for small datagrams.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
RDS exposes a few tunable parameters via sysctls.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A simple rds transport to handle loopback connections.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
While arguably the fact that the underlying transport needs a
connection to convey RDS's datagrame reliably is not important
to rds proper, the transports implemented so far (IB and TCP)
have both been connection-oriented, and so the connection
state machine-related code is in the common rds code.
This patch also includes several work items, to handle connecting,
sending, receiving, and shutdown.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
RDS currently generates a lot of stats that are accessible via
the rds-info utility. This code implements the support for this.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
RDS supports multiple transports. While this initial submission
only supports Infiniband transport, this abstraction allows others
to be added. We're working on an iWARP transport, and also see
UDP over DCB as another possibility.
This code handles transport registration.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
RDS handles per-socket congestion by updating peers with a complete
congestion map (8KB). This code keeps track of these maps for itself
and ones received from peers.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
RDS's main data structure definitions and exported functions.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Implement the RDS (Reliable Datagram Sockets) interface.
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Impact: Attribute functions with __acquires(...) resp. __releases(...).
Fix this sparse warnings:
net/wanrouter/wanproc.c:82:13: warning: context imbalance in 'r_start' - wrong count at exit
net/wanrouter/wanproc.c:103:13: warning: context imbalance in 'r_stop' - unexpected unlock
net/wanrouter/wanmain.c:765:13: warning: context imbalance in 'lock_adapter_irq' - wrong count at exit
net/wanrouter/wanmain.c:771:13: warning: context imbalance in 'unlock_adapter_irq' - unexpected unlock
Signed-off-by: Hannes Eder <hannes@hanneseder.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Impact: Attribute function with __releases(...)
Fix this sparse warning:
net/ipv4/inet_fragment.c:276:35: warning: context imbalance in 'inet_frag_find' - unexpected unlock
Signed-off-by: Hannes Eder <hannes@hanneseder.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Impact: Remove redundant variable declarations, resp. rename
inner scope variable.
Fix this sparse warnings:
net/decnet/af_decnet.c:1252:40: warning: symbol 'skb' shadows an earlier one
net/decnet/af_decnet.c:1223:24: originally declared here
net/decnet/af_decnet.c:1582:29: warning: symbol 'val' shadows an earlier one
net/decnet/af_decnet.c:1527:22: originally declared here
net/decnet/dn_dev.c:687:21: warning: symbol 'err' shadows an earlier one
net/decnet/dn_dev.c:670:13: originally declared here
net/decnet/sysctl_net_decnet.c:182:21: warning: symbol 'len' shadows an earlier one
net/decnet/sysctl_net_decnet.c:173:16: originally declared here
Signed-off-by: Hannes Eder <hannes@hanneseder.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Impact: Attribute functions with __acquires(...) resp. __releases(...).
Fix this sparse warnings:
net/decnet/dn_dev.c:1324:13: warning: context imbalance in 'dn_dev_seq_start' - wrong count at exit
net/decnet/dn_dev.c:1366:13: warning: context imbalance in 'dn_dev_seq_stop' - unexpected unlock
Signed-off-by: Hannes Eder <hannes@hanneseder.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Impact: Include header file.
Fix this sparse warning:
net/core/sysctl_net_core.c:123:32: warning: symbol 'net_core_path' was not declared. Should it be static?
Signed-off-by: Hannes Eder <hannes@hanneseder.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Impact: Use 'static const char[]' instead of 'static char[]', and
since the data is const now it can be placed in __initconst.
Fix this warning:
net/appletalk/ddp.c: In function 'atalk_init':
net/appletalk/ddp.c:1894: warning: format not a string literal and no format arguments
Signed-off-by: Hannes Eder <hannes@hanneseder.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Impact: Trust in the comment and add '__force' to the cast.
Fix this sparse warning:
net/9p/trans_fd.c:420:34: warning: cast adds address space to expression (<asn:1>)
Signed-off-by: Hannes Eder <hannes@hanneseder.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Impact: Attribute function with __acquires(...) resp. __releases(...).
Fix this sparse warnings:
net/802/tr.c:492:21: warning: context imbalance in 'rif_seq_start' - wrong count at exit
net/802/tr.c:519:13: warning: context imbalance in 'rif_seq_stop' - unexpected unlock
Signed-off-by: Hannes Eder <hannes@hanneseder.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Userspace pairing code can be simplified if it doesn't have to fall
back to using L2CAP_LM in the case of L2CAP raw sockets. This patch
allows the BT_SECURITY socket option to be used for these sockets.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The CID value of L2CAP sockets need to be set to zero. All userspace
applications do this via memset() on the sockaddr_l2 structure. The
RFCOMM implementation uses in-kernel L2CAP sockets and so it has to
make sure that l2_cid is set to zero.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In the future the L2CAP layer will have full support for fixed channels
and right now it already can export the channel assignment, but for the
functions bind() and connect() the usage of only CID 0 is allowed. This
allows an easy detection if the kernel supports fixed channels or not,
because otherwise it would impossible for application to tell.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When BT_DEFER_SETUP is enabled on a RFCOMM socket, then switch its
current state from BT_OPEN to BT_CONNECT2. This gives the Bluetooth
core a unified way to handle L2CAP and RFCOMM sockets. The BT_CONNECT2
state is designated for incoming connections.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When BT_DEFER_SETUP has been enabled on a Bluetooth socket it keeps
signaling POLLIN all the time. This is a wrong behavior. The POLLIN
should only be signaled if the client socket is in BT_CONNECT2 state
and the parent has been BT_DEFER_SETUP enabled.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The authentication requirement got only updated when the security level
increased. This is a wrong behavior. The authentication requirement is
read by the Bluetooth daemon to make proper decisions when handling the
IO capabilities exchange. So set the value that is currently expected by
the higher layers like L2CAP and RFCOMM.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The L2CAP layer can trigger the authentication via an ACL connection or
later on to increase the security level. When increasing the security
level it didn't use the same authentication requirements when triggering
a new ACL connection. Make sure that exactly the same authentication
requirements are used. The only exception here are the L2CAP raw sockets
which are only used for dedicated bonding.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Some of the qualification tests demand that in case of failures in L2CAP
the HCI disconnect should indicate a reason why L2CAP fails. This is a
bluntly layer violation since multiple L2CAP connections could be using
the same ACL and thus forcing a disconnect reason is not a good idea.
To comply with the Bluetooth test specification, the disconnect reason
is now stored in the L2CAP connection structure and every time a new
L2CAP channel is added it will set back to its default. So only in the
case where the L2CAP channel with the disconnect reason is really the
last one, it will propagated to the HCI layer.
The HCI layer has been extended with a disconnect indication that allows
it to ask upper layers for a disconnect reason. The upper layer must not
support this callback and in that case it will nicely default to the
existing behavior. If an upper layer like L2CAP can provide a disconnect
reason that one will be used to disconnect the ACL or SCO link.
No modification to the ACL disconnect timeout have been made. So in case
of Linux to Linux connection the initiator will disconnect the ACL link
before the acceptor side can signal the specific disconnect reason. That
is perfectly fine since Linux doesn't make use of this value anyway. The
L2CAP layer has a perfect valid error code for rejecting connection due
to a security violation. It is unclear why the Bluetooth specification
insists on having specific HCI disconnect reason.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In preparation for L2CAP fixed channel support, the CID value of a
L2CAP connection needs to be accessible via the socket interface. The
CID is the connection identifier and exists as source and destination
value. So extend the L2CAP socket address structure with this field and
change getsockname() and getpeername() to fill it in.
The bind() and connect() functions have been modified to handle L2CAP
socket address structures of variable sizes. This makes them future
proof if additional fields need to be added.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the extended features mask indicates support for fixed channels,
request the list of available fixed channels. This also enables the
fixed channel features bit so remote implementations can request
information about it. Currently only the signal channel will be
listed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The recommendation for the L2CAP PSM 1 (SDP) is to not use any kind
of authentication or encryption. So don't trigger authentication
for incoming and outgoing SDP connections.
For L2CAP PSM 3 (RFCOMM) there is no clear requirement, but with
Bluetooth 2.1 the initiator is required to enable authentication
and encryption first and this gets enforced. So there is no need
to trigger an additional authentication step. The RFCOMM service
security will make sure that a secure enough link key is present.
When the encryption gets enabled after the SDP connection setup,
then switch the security level from SDP to low security.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the remote L2CAP server uses authentication pending stage and
encryption is enabled it can happen that a L2CAP connection request is
sent twice due to a race condition in the connection state machine.
When the remote side indicates any kind of connection pending, then
track this state and skip sending of L2CAP commands for this period.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When two L2CAP connections are requested quickly after the ACL link has
been established there exists a window for a race condition where a
connection request is sent before the information response has been
received. Any connection request should only be sent after an exchange
of the extended features mask has been finished.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When no authentication requirements are selected, but an outgoing or
incoming connection has requested any kind of security enforcement,
then set these authentication requirements.
This ensures that the userspace always gets informed about the
authentication requirements (if available). Only when no security
enforcement has happened, the kernel will signal invalid requirements.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When receiving incoming connection to specific services, always use
general bonding. This ensures that the link key gets stored and can be
used for further authentications.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When attempting to setup eSCO connections it can happen that some link
manager implementations fail to properly negotiate the eSCO parameters
and thus fail the eSCO setup. Normally the link manager is responsible
for the negotiation of the parameters and actually fallback to SCO if
no agreement can be reached. In cases where the link manager is just too
stupid, then at least try to establish a SCO link if eSCO fails.
For the Bluetooth devices with EDR support this includes handling packet
types of EDR basebands. This is particular tricky since for the EDR the
logic of enabling/disabling one specific packet type is turned around.
This fix contains an extra bitmask to disable eSCO EDR packet when
trying to fallback to a SCO connection.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
For L2CAP sockets with medium and high security requirement a missing
encryption will enforce the closing of the link. For the L2CAP raw
sockets this is not needed, so skip that check.
This fixes a crash when pairing Bluetooth 2.0 (and earlier) devices
since the L2CAP state machine got confused and then locked up the whole
system.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
During a role change with pre-Bluetooth 2.1 devices, the remote side drops
the encryption of the RFCOMM connection. We allow a grace period for the
encryption to be re-established, before dropping the connection. During
this grace period, the RFCOMM_SEC_PENDING flag is set. Check this flag
before sending RFCOMM packets.
Signed-off-by: Jaikumar Ganesh <jaikumar@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Due to lockdep changes, the CONFIG_DEBUG_LOCK_ALLOC ifdef is not needed
now. So just remove it here.
The following commit fixed the !lockdep build warnings:
commit e8f6fbf62d
Author: Ingo Molnar <mingo@elte.hu>
Date: Wed Nov 12 01:38:36 2008 +0000
lockdep: include/linux/lockdep.h - fix warning in net/bluetooth/af_bluetooth.c
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
With the support for the enhanced security model and the support for
deferring connection setup, it is a good idea to increase various
version numbers.
This is purely cosmetic and has no effect on the behavior, but can
be really helpful when debugging problems in different kernel versions.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The new socket options should only be evaluated for SOL_BLUETOOTH level
and not for every other level. Previously this causes some minor issues
when detecting if a kernel with certain features is available.
Also restrict BT_SECURITY to SOCK_SEQPACKET for L2CAP and SOCK_STREAM for
the RFCOMM protocol.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
For L2CAP connections with high security setting, the link will be
immediately dropped when the encryption gets disabled. For L2CAP
connections with medium security there will be grace period where
the remote device has the chance to re-enable encryption. If it
doesn't happen then the link will also be disconnected.
The requirement for the grace period with medium security comes from
Bluetooth 2.0 and earlier devices that require role switching.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
A role switch with devices following the Bluetooth pre-2.1 standards
or without Encryption Pause and Resume support is not possible if
encryption is enabled. Most newer headsets require the role switch,
but also require that the connection is encrypted.
For connections with a high security mode setting, the link will be
immediately dropped. When the connection uses medium security mode
setting, then a grace period is introduced where the TX is halted and
the remote device gets a change to re-enable encryption after the
role switch. If not re-enabled the link will be dropped.
Based on initial work by Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The current security model is based around the flags AUTH, ENCRYPT and
SECURE. Starting with support for the Bluetooth 2.1 specification this is
no longer sufficient. The different security levels are now defined as
SDP, LOW, MEDIUM and SECURE.
Previously it was possible to set each security independently, but this
actually doesn't make a lot of sense. For Bluetooth the encryption depends
on a previous successful authentication. Also you can only update your
existing link key if you successfully created at least one before. And of
course the update of link keys without having proper encryption in place
is a security issue.
The new security levels from the Bluetooth 2.1 specification are now
used internally. All old settings are mapped to the new values and this
way it ensures that old applications still work. The only limitation
is that it is no longer possible to set authentication without also
enabling encryption. No application should have done this anyway since
this is actually a security issue. Without encryption the integrity of
the authentication can't be guaranteed.
As default for a new L2CAP or RFCOMM connection, the LOW security level
is used. The only exception here are the service discovery sessions on
PSM 1 where SDP level is used. To have similar security strength as with
a Bluetooth 2.0 and before combination key, the MEDIUM level should be
used. This is according to the Bluetooth specification. The MEDIUM level
will not require any kind of man-in-the-middle (MITM) protection. Only
the HIGH security level will require this.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When the remote device supports only SCO connections, on receipt of
the HCI_EV_CONN_COMPLETE event packet, the connect state is changed to
BT_CONNECTED, but the socket state is not updated. Hence, the connect()
call times out even though the SCO connection has been successfully
established.
Based on a report by Jaikumar Ganesh <jaikumar@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
All SCO and eSCO connection are auto-accepted no matter if there is a
corresponding listening socket for them. This patch changes this and
connection requests for SCO and eSCO without any socket are rejected.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In order to decide if listening L2CAP sockets should be accept()ed
the BD_ADDR of the remote device needs to be known. This patch adds
a socket option which defines a timeout for deferring the actual
connection setup.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In order to decide if listening RFCOMM sockets should be accept()ed
the BD_ADDR of the remote device needs to be known. This patch adds
a socket option which defines a timeout for deferring the actual
connection setup.
The connection setup is done after reading from the socket for the
first time. Until then writing to the socket returns ENOTCONN.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The L2CAP and RFCOMM applications require support for authorization
and the ability of rejecting incoming connection requests. The socket
interface is not really able to support this.
This patch does the ground work for a socket option to defer connection
setup. Setting this option allows calling of accept() and then the
first read() will trigger the final connection setup. Calling close()
would reject the connection.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The socket option levels SOL_L2CAP, SOL_RFOMM and SOL_SCO are currently
in use by various Bluetooth applications. Going forward the common
option level SOL_BLUETOOTH should be used. This patch prepares the clean
split of the old and new option levels while keeping everything backward
compatibility.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In case of connection failures the rfcomm_sock_sendmsg() should return
an error and not a 0 value.
Signed-off-by: Victor Shcherbatyuk <victor.shcherbatyuk@tomtom.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We already have a valid net in that place, but this is not just a
cleanup - the tw pointer can be NULL there sometimes, thus causing
an oops in NET_NS=y case.
The same place in ipv4 code already works correctly using existing
net, rather than tw's one.
The bug exists since 2.6.27.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The functions time_before is more robust for comparing
jiffies against other values.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The functions time_before is more robust for comparing
jiffies against other values.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The functions time_before is more robust for comparing
jiffies against other values.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove some pointless conditionals before kfree_skb().
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
expression E;
@@
- if (E)
- kfree_skb(E);
+ kfree_skb(E);
// </smpl>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch changes the return value of nlmsg_notify() as follows:
If NETLINK_BROADCAST_ERROR is set by any of the listeners and
an error in the delivery happened, return the broadcast error;
else if there are no listeners apart from the socket that
requested a change with the echo flag, return the result of the
unicast notification. Thus, with this patch, the unicast
notification is handled in the same way of a broadcast listener
that has set the NETLINK_BROADCAST_ERROR socket flag.
This patch is useful in case that the caller of nlmsg_notify()
wants to know the result of the delivery of a netlink notification
(including the broadcast delivery) and take any action in case
that the delivery failed. For example, ctnetlink can drop packets
if the event delivery failed to provide reliable logging and
state-synchronization at the cost of dropping packets.
This patch also modifies the rtnetlink code to ignore the return
value of rtnl_notify() in all callers. The function rtnl_notify()
(before this patch) returned the error of the unicast notification
which makes rtnl_set_sk_err() reports errors to all listeners. This
is not of any help since the origin of the change (the socket that
requested the echoing) notices the ENOBUFS error if the notification
fails and should resync itself.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix regression introduded by commit 079aa88 (netfilter: xt_recent: IPv6 support):
From http://bugzilla.kernel.org/show_bug.cgi?id=12753:
Problem Description:
An uninitialized buffer causes IPv4 addresses added manually (via the +IP
command to the proc interface) to never match any packets. Similarly, the -IP
command fails to remove IPv4 addresses.
Details:
In the function recent_entry_lookup, the xt_recent module does comparisons of
the entire nf_inet_addr union value, both for IPv4 and IPv6 addresses. For
addresses initialized from actual packets the remaining 12 bytes not occupied
by the IPv4 are zeroed so this works correctly. However when setting the
nf_inet_addr addr variable in the recent_mt_proc_write function, only the IPv4
bytes are initialized and the remaining 12 bytes contain garbage.
Hence addresses added in this way never match any packets, unless these
uninitialized 12 bytes happened to be zero by coincidence. Similarly, addresses
cannot consistently be removed using the proc interface due to mismatch of the
garbage bytes (although it will sometimes work to remove an address that was
added manually).
Reading the /proc/net/xt_recent/ entries hides this problem because this only
uses the first 4 bytes when displaying IPv4 addresses.
Steps to reproduce:
$ iptables -I INPUT -m recent --rcheck -j LOG
$ echo +169.254.156.239 > /proc/net/xt_recent/DEFAULT
$ cat /proc/net/xt_recent/DEFAULT
src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
[At this point no packets from 169.254.156.239 are being logged.]
$ iptables -I INPUT -s 169.254.156.239 -m recent --set
$ cat /proc/net/xt_recent/DEFAULT
src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
src=169.254.156.239 ttl: 255 last_seen: 126184 oldest_pkt: 4 125434, 125684, 125934, 126184
[At this point, adding the address via an iptables rule, packets are being
logged correctly.]
$ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT
$ cat /proc/net/xt_recent/DEFAULT
src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992
$ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT
$ cat /proc/net/xt_recent/DEFAULT
src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992
[Removing the address via /proc interface failed evidently.]
Possible solutions:
- initialize the addr variable in recent_mt_proc_write
- compare only 4 bytes for IPv4 addresses in recent_entry_lookup
Signed-off-by: Patrick McHardy <kaber@trash.net>
