- 25 Sep, 2013 6 commits
-
-
Johan Hedberg authored
This patch adds a new mgmt setting for LE advertising and hooks up the necessary places in the mgmt code to operate on the HCI_LE_PERIPHERAL flag (which corresponds to this setting). This patch does not yet add any new command for enabling the setting - that is left for a subsequent patch. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Johan Hedberg authored
This patch updates the code to use an asynchronous request for handling the enabling and disabling of LE support. This refactoring is necessary as a preparation for adding advertising support, since when LE is disabled we should also disable advertising, and the cleanest way to do this is to perform the two respective HCI commands in the same asynchronous request. Signed-off-by:
-
Johan Hedberg authored
The settings_rsp and cmd_status_rsp functions can be useful for all mgmt command handlers when asynchronous request callbacks are used. They will e.g. be used by subsequent patches to change set_le to use an async request as well as a new set_advertising command. Therefore, move them higher up in the mgmt.c file to avoid unnecessary forward declarations or mixing this trivial change with other patches. Signed-off-by:
-
Johan Hedberg authored
We should return a "busy" error always when there is another mgmt_set_powered operation in progress. Previously when powering on while the auto off timer was still set the code could have let two or more pending power on commands to be queued. This patch fixes the issue by moving the check for duplicate commands to an earlier point in the set_powered handler. Signed-off-by:
-
Johan Hedberg authored
This patch cleans up the locking login in l2cap_sock_recvmsg by pairing up each lock_sock call with a release_sock call. The function already has a "done" label that handles releasing the socket and returning from the function so the fix is rather simple. Signed-off-by:
-
Johan Hedberg authored
The bt_sock_wait_state requires the sk lock to be held (through lock_sock) so document it clearly in the code. Signed-off-by:
-
- 22 Sep, 2013 1 commit
-
-
Peter Senna Tschudin authored
Convert 0 to false and 1 to true when assigning values to bool variables. Inspired by commit 3db1cd5c. The simplified semantic patch that find this problem is as follows (http://coccinelle.lip6.fr/): @@ bool b; @@ ( -b = 0 +b = false | -b = 1 +b = true ) Signed-off-by:
Peter Senna Tschudin <peter.senna@gmail.com> Acked-by:
-
- 19 Sep, 2013 2 commits
-
-
Johan Hedberg authored
For those controller that support the HCI_Set_Event_Mask_Page_2 command we should include it in the init sequence. This patch implements sending of the command and enables the events in it based on supported features (currently only CSB is checked). Signed-off-by:
-
Johan Hedberg authored
This patch adds support for reading the synchronization train parameters for controllers that support the feature. Since the feature is detectable through the local features page 2, which is retreived only in stage 3 of the HCI init sequence, there is no other option than to add a fourth stage to the init sequence. For now the patch doesn't yet add storing of the parameters, but it is nevertheless convenient to have around to see what kind of parameters various controllers use by default (analyzable e.g. with the btmon user space tool). Signed-off-by:
-
- 18 Sep, 2013 8 commits
-
-
Johan Hedberg authored
In the case of blocking sockets we should not proceed with sendmsg() if the socket has the BT_SK_SUSPEND flag set. So far the code was only ensuring that POLLOUT doesn't get set for non-blocking sockets using poll() but there was no code in place to ensure that blocking sockets do the right thing when writing to them. This patch adds a new bt_sock_wait_ready helper function to sleep in the sendmsg call if the BT_SK_SUSPEND flag is set, and wake up as soon as it is unset. It also updates the L2CAP and RFCOMM sendmsg callbacks to take advantage of this new helper function. Signed-off-by:
-
Johan Hedberg authored
When we have an LE link we should not respond to any data on the BR/EDR L2CAP signaling channel (0x0001) and vice-versa when we have a BR/EDR link we should not respond to LE L2CAP (CID 0x0005) signaling commands. This patch fixes this issue by checking for a valid link type and ignores data if it is wrong. Signed-off-by:
-
Johan Hedberg authored
When L2CAP packets return a non-zero error and the value is passed onwards by l2cap_bredr_sig_cmd this will trigger a command reject packet to be sent. However, the core specification (page 1416 in core 4.0) says the following: "Command Reject packets should not be sent in response to an identified Response packet.". This patch ensures that a command reject packet is not sent for any identified response packet by ignoring the error return value from the response handler functions. Signed-off-by:
-
Johan Hedberg authored
There are several possible reason codes that can be sent in the command reject L2CAP packet. Before this patch the code has used a hard-coded single response code ("command not understood"). This patch adds a helper function to map the return value of an L2CAP handler function to the correct command reject reason. Signed-off-by: -
Johan Hedberg authored
If we receive an L2CAP Disconnect Request for an unknown CID we should not just silently drop it but reply with a proper Command Reject response. This patch fixes this by ensuring that the disconnect handler returns a proper error instead of 0 and will cause the function caller to send the right response. Signed-off-by:
-
Johan Hedberg authored
The EFAULT error should only be used for memory address related errors and ENOENT might be needed for other purposes than invalid CID errors. This patch fixes the l2cap_config_req, l2cap_connect_create_rsp and l2cap_create_channel_req handlers to use the unique EBADSLT error to indicate failed lookups on a given CID. Signed-off-by:
-
Johan Hedberg authored
When an L2CAP request handler returns non-zero the calling code will send a command reject response. The l2cap_create_chan_req function will in some cases send its own response but then still return a -EFAULT error which would cause two responses to be sent. This patch fixes this by making the function return 0 after sending its own response. Signed-off-by:
-
Johan Hedberg authored
The struct for HCI_Set_Event_Mask is never used. Instead a local 8-byte array is used for sending this command. Therefore, remove the unnecessary struct definition. Signed-off-by:
-
- 16 Sep, 2013 13 commits
-
-
Marcel Holtmann authored
When the user channel is set and an user application has full control over the device, do not bother trying to schedule any queues except the raw queue. This is an optimization since with user channel, only the raw queue is in use. Signed-off-by:
-
Marcel Holtmann authored
There is no need to use GFP_ATOMIC with skb_clone() when the code is executed in a workqueue. Signed-off-by:
-
Marcel Holtmann authored
When the device has the user channel flag set, it means it is driven by an user application. In that case do not allow any connections from L2CAP or SCO sockets. This is the same situation as when the device has the raw flag set and it will then return EHOSTUNREACH. Signed-off-by:
-
Marcel Holtmann authored
So far the only option to create a virtual AMP controller was by setting a module parameter for the hci_vhci driver. This patch adds the functionality to define inline to create either a BR/EDR or an AMP controller. In addition the client will be informed which HCI controller index it got assigned. That is especially useful for automated end-to-end testing. To keep backwards compatibility with existing userspace, the command for creating a controller type needs to be send right after opening the device node. If the command is not send, it defaults back to automatically creating a BR/EDR controller. Signed-off-by:
-
Marcel Holtmann authored
To allow creating /dev/vhci device node, add the proper module alias for this driver. Signed-off-by:
-
Marcel Holtmann authored
This patch introcuces a new HCI socket channel that allows user applications to take control over a specific HCI device. The application gains exclusive access to this device and forces the kernel to stay away and not manage it. In case of the management interface it will actually hide the device. Such operation is useful for security testing tools that need to operate underneath the Bluetooth stack and need full control over a device. The advantage here is that the kernel still provides the service of hardware abstraction and HCI level access. The use of Bluetooth drivers for hardware access also means that sniffing tools like btmon or hcidump are still working and the whole set of transaction can be traced with existing tools. With the new channel it is possible to send HCI commands, ACL and SCO data packets and receive HCI events, ACL and SCO packets from the device. The format follows the well established H:4 protocol. The new HCI user channel can only be established when a device has been through its setup routine and is currently powered down. This is enforced to not cause any problems with current operations. In addition only one user channel per HCI device is allowed. It is exclusive access for one user application. Access to this channel is limited to process with CAP_NET_RAW capability. Using this new facility does not require any external library or special ioctl or socket filters. Just create the socket and bind it. After that the file descriptor is ready to speak H:4 protocol. struct sockaddr_hci addr; int fd; fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI); memset(&addr, 0, sizeof(addr)); addr.hci_family = AF_BLUETOOTH; addr.hci_dev = 0; addr.hci_channel = HCI_CHANNEL_USER; bind(fd, (struct sockaddr *) &addr, sizeof(addr)); The example shows on how to create a user channel for hci0 device. Error handling has been left out of the example. However with the limitations mentioned above it is advised to handle errors. Binding of the user cahnnel socket can fail for various reasons. Specifically if the device is currently activated by BlueZ or if the access permissions are not present. Signed-off-by: -
Marcel Holtmann authored
This patch introduces a new user channel flag that allows to give full control of a HCI device to a user application. The kernel will stay away from the device and does not allow any further modifications of the device states. The existing raw flag is not used since it has a bit of unclear meaning due to its legacy. Using a new flag makes the code clearer. A device with the user channel flag set can still be enumerate using the legacy API, but it does not longer enumerate using the new management interface used by BlueZ 5 and beyond. This is intentional to not confuse users of modern systems. Signed-off-by:
-
Marcel Holtmann authored
The various legacy ioctls used with HCI sockets are limited to raw channel only. They are not used on the other channels and also have no meaning there. So return an error if tried to use them. Signed-off-by:
-
Marcel Holtmann authored
The HCI sockets for monitor and control do not support any HCI specific socket options and if tried, an error will be returned. However the error used is EINVAL and that is not really descriptive. To make it clear that these sockets are not handling HCI socket options, return EBADFD instead. Signed-off-by:
-
Marcel Holtmann authored
Even if this is legacy API, there is no reason to not report a proper error when trying to reset a HCI device that is down. Signed-off-by:
-
Marcel Holtmann authored
The hci_dev check is not protected and so move it into the socket lock. In addition return the HCI channel identifier instead of always 0 channel. Signed-off-by:
-
Marcel Holtmann authored
The HCI sockets do not have a peer associated with it and so make sure that getpeername() returns EOPNOTSUPP since this operation is actually not supported on HCI sockets. Signed-off-by:
-
Marcel Holtmann authored
The handling of the raw socket filter is rather obscure code and it gets in the way of future extensions. Instead of inline filtering in the raw socket packet routine, refactor it into its own function. Signed-off-by:
-
- 04 Sep, 2013 10 commits
-
-
Daniel Borkmann authored
Document force_mld_version parameter in ip-sysctl.txt. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
We already have mld_{gq,ifc,dad}_start_timer() functions, so introduce mld_{gq,ifc,dad}_stop_timer() functions to reduce code size and make it more readable. Signed-off-by: -
Daniel Borkmann authored
Make igmp6_event_query() a bit easier to read by refactoring code parts into mld_process_v1() and mld_process_v2(). Signed-off-by:
-
Daniel Borkmann authored
Similarly as we do in MLDv2 queries, set a forged MLDv1 query with 0 ms mld_maxdelay to minimum timer shot time of 1 jiffies. This is eventually done in igmp6_group_queried() anyway, so we can simplify a check there. Signed-off-by:
-
Daniel Borkmann authored
RFC3810, 10. Security Considerations says under subsection 10.1. Query Message: A forged Version 1 Query message will put MLDv2 listeners on that link in MLDv1 Host Compatibility Mode. This scenario can be avoided by providing MLDv2 hosts with a configuration option to ignore Version 1 messages completely. Hence, implement a MLDv2-only mode that will ignore MLDv1 traffic: echo 2 > /proc/sys/net/ipv6/conf/ethX/force_mld_version or echo 2 > /proc/sys/net/ipv6/conf/all/force_mld_version Note that <all> device has a higher precedence as it was previously also the case in the macro MLD_V1_SEEN() that would "short-circuit" if condition on <all> case. Signed-off-by:
-
Daniel Borkmann authored
Get rid of MLDV2_MRC and use our new macros for mantisse and exponent to calculate Maximum Response Delay out of the Maximum Response Code. Signed-off-by:
-
Daniel Borkmann authored
Replace the macro with a function to make it more readable. GCC will eventually decide whether to inline this or not (also, that's not fast-path anyway). Signed-off-by:
-
Daniel Borkmann authored
i) RFC3810, 9.2. Query Interval [QI] says: The Query Interval variable denotes the interval between General Queries sent by the Querier. Default value: 125 seconds. [...] ii) RFC3810, 9.3. Query Response Interval [QRI] says: The Maximum Response Delay used to calculate the Maximum Response Code inserted into the periodic General Queries. Default value: 10000 (10 seconds) [...] The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval]. iii) RFC3810, 9.12. Older Version Querier Present Timeout [OVQPT] says: The Older Version Querier Present Timeout is the time-out for transitioning a host back to MLDv2 Host Compatibility Mode. When an MLDv1 query is received, MLDv2 hosts set their Older Version Querier Present Timer to [Older Version Querier Present Timeout]. This value MUST be ([Robustness Variable] times (the [Query Interval] in the last Query received)) plus ([Query Response Interval]). Hence, on *default* the timeout results in: [RV] = 2, [QI] = 125sec, [QRI] = 10sec [OVQPT] = [RV] * [QI] + [QRI] = 260sec Having that said, we currently calculate [OVQPT] (here given as 'switchback' variable) as ... switchback = (idev->mc_qrv + 1) * max_delay RFC3810, 9.12. says "the [Query Interval] in the last Query received". In section "9.14. Configuring timers", it is said: This section is meant to provide advice to network administrators on how to tune these settings to their network. Ambitious router implementations might tune these settings dynamically based upon changing characteristics of the network. [...] iv) RFC38010, 9.14.2. Query Interval: The overall level of periodic MLD traffic is inversely proportional to the Query Interval. A longer Query Interval results in a lower overall level of MLD traffic. The value of the Query Interval MUST be equal to or greater than the Maximum Response Delay used to calculate the Maximum Response Code inserted in General Query messages. I assume that was why switchback is calculated as is (3 * max_delay), although this setting seems to be meant for routers only to configure their [QI] interval for non-default intervals. So usage here like this is clearly wrong. Concluding, the current behaviour in IPv6's multicast code is not conform to the RFC as switch back is calculated wrongly. That is, it has a too small value, so MLDv2 hosts switch back again to MLDv2 way too early, i.e. ~30secs instead of ~260secs on default. Hence, introduce necessary helper functions and fix this up properly as it should be. Introduced in 06da9228 ("[IPV6]: Add MLDv2 support."). Credits to Hannes Frederic Sowa who also had a hand in this as well. Also thanks to Hangbin Liu who did initial testing. Signed-off-by:
-
Yuchung Cheng authored
Commit 1b7fdd2a("tcp: do not use cached RTT for RTT estimation") removes important comments on how RTO is initialized and updated. Hopefully this patch puts those information back. Signed-off-by:
Yuchung Cheng <ycheng@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Pravin B Shelar authored
vxlan-udp-recv function lookup vxlan_sock struct on every packet recv by using udp-port number. we can use sk->sk_user_data to store vxlan_sock and avoid lookup. I have open coded rcu-api to store and read vxlan_sock from sk_user_data to avoid sparse warning as sk_user_data is not __rcu pointer. Signed-off-by:
Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
