summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: Change RFCOMM to use BT_CONNECT2 for BT_DEFER_SETUPMarcel Holtmann2009-02-271-0/+11
| | | | | | | | | 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>
* Bluetooth: Fix poll() misbehavior when using BT_DEFER_SETUPMarcel Holtmann2009-02-271-4/+3
| | | | | | | | | 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>
* Bluetooth: Set authentication requirement before requesting itMarcel Holtmann2009-02-271-6/+4
| | | | | | | | | | 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>
* Bluetooth: Fix authentication requirements for L2CAP security checkMarcel Holtmann2009-02-271-10/+20
| | | | | | | | | | | 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>
* Bluetooth: Ask upper layers for HCI disconnect reasonMarcel Holtmann2009-02-276-10/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Bluetooth: Add CID field to L2CAP socket address structureMarcel Holtmann2009-02-272-21/+35
| | | | | | | | | | | | | | 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>
* Bluetooth: Request L2CAP fixed channel list if availableMarcel Holtmann2009-02-272-9/+32
| | | | | | | | | | 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>
* Bluetooth: Don't enforce authentication for L2CAP PSM 1 and 3Marcel Holtmann2009-02-272-1/+7
| | | | | | | | | | | | | | | | | 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>
* Bluetooth: Fix double L2CAP connection requestMarcel Holtmann2009-02-272-0/+9
| | | | | | | | | | | 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>
* Bluetooth: Fix race condition with L2CAP information requestMarcel Holtmann2009-02-272-4/+16
| | | | | | | | | | 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>
* Bluetooth: Set authentication requirements if not availableMarcel Holtmann2009-02-271-0/+3
| | | | | | | | | | | | 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>
* Bluetooth: Use general bonding whenever possibleMarcel Holtmann2009-02-274-17/+40
| | | | | | | | 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>
* Bluetooth: Add SCO fallback for eSCO connection attemptsMarcel Holtmann2009-02-273-2/+31
| | | | | | | | | | | | | | | | | 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>
* Bluetooth: Don't check encryption for L2CAP raw socketsMarcel Holtmann2009-02-271-0/+3
| | | | | | | | | | | | 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>
* Bluetooth: Submit bulk URBs along with interrupt URBsMarcel Holtmann2009-02-271-17/+23
| | | | | | | | | | | | | | Submitting the bulk URBs for ACL data transfers only on demand has no real benefit compared to just submit them when a Bluetooth device gets opened. So when submitting the interrupt URBs for HCI events, just submit the bulk URBs, too. This solves a problem with some Bluetooth USB dongles that has been reported over the last few month. These devices require that the bulk URBs are actually present. These devices are really broken, but there is nothing we can do about it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: When encryption is dropped, do not send RFCOMM packetsJaikumar Ganesh2009-02-271-0/+3
| | | | | | | | | | | 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>
* Bluetooth: Eliminate a sparse warning in bt3c driverAndre Haupt2009-02-271-2/+2
| | | | | | | This eliminates a sparse warning that symbol 'stat' shadows an earlier one. Signed-off-by: Andre Haupt <andre@bitwigglers.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove CONFIG_DEBUG_LOCK_ALLOC ifdefsDave Young2009-02-271-6/+0
| | | | | | | | | | | | | | | | 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 e8f6fbf62de37cbc2e179176ac7010d5f4396b67 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>
* Bluetooth: Update version numbersMarcel Holtmann2009-02-273-3/+3
| | | | | | | | | | | 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>
* Bluetooth: Restrict application of socket optionsMarcel Holtmann2009-02-272-0/+32
| | | | | | | | | | | 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>
* Bluetooth: Disconnect L2CAP connections without encryptionMarcel Holtmann2009-02-271-7/+19
| | | | | | | | | | | | | 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>
* Bluetooth: Pause RFCOMM TX when encryption dropsMarcel Holtmann2009-02-272-10/+22
| | | | | | | | | | | | | | | | | 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>
* Bluetooth: Replace RFCOMM link mode with security levelMarcel Holtmann2009-02-273-31/+79
| | | | | | | Change the RFCOMM internals to use the new security levels and remove the link mode details. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Replace L2CAP link mode with security levelMarcel Holtmann2009-02-272-52/+113
| | | | | | | Change the L2CAP internals to use the new security levels and remove the link mode details. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add enhanced security model for Simple PairingMarcel Holtmann2009-02-277-191/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Bluetooth: Fix SCO state handling for incoming connectionsMarcel Holtmann2009-02-271-1/+2
| | | | | | | | | | | | 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>
* Bluetooth: Reject incoming SCO connections without listenersMarcel Holtmann2009-02-271-2/+22
| | | | | | | | 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>
* Bluetooth: Add support for deferring L2CAP connection setupMarcel Holtmann2009-02-271-9/+101
| | | | | | | | | 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>
* Bluetooth: Add support for deferring RFCOMM connection setupMarcel Holtmann2009-02-273-18/+88
| | | | | | | | | | | | 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>
* Bluetooth: Add global deferred socket parameterMarcel Holtmann2009-02-272-2/+9
| | | | | | | | | | | | | 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>
* Bluetooth: Preparation for usage of SOL_BLUETOOTHMarcel Holtmann2009-02-273-5/+124
| | | | | | | | | | 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>
* Bluetooth: Fix issue with return value of rfcomm_sock_sendmsg()Victor Shcherbatyuk2009-02-271-1/+4
| | | | | | | | 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>
* Merge branch 'master' of ↵David S. Miller2009-02-2511-77/+206
|\ | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/wireless/orinoco/orinoco.c
| * Merge branch 'master' of ↵David S. Miller2009-02-243-11/+44
| |\ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
| | * rtl8187: New USB ID's for RTL8187LLarry Finger2009-02-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add new USB ID codes. These come from two postings on forums and mailing lists, and four are derived from the .inf that accompanies the latest Realtek Windows driver for the RTL8187L. Thanks to Viktor Ilijašić <viktor.ilijasic@gmail.com> and Xose Vazquez Perez <xose.vazquez@gmail.com> for reporting these new ID's. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * ath9k: Fix panic upon attach failureVasanthakumar Thiagarajan2009-02-231-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [246916.338046] [246916.338048] Pid: 29265, comm: insmod Not tainted (2.6.29-rc4-wl #64) 9461DUU [246916.338051] EIP: 0060:[<c02ca274>] EFLAGS: 00010202 CPU: 0 [246916.338055] EIP is at rollback_registered+0x24/0x220 [246916.338057] EAX: 00000001 EBX: 00000000 ECX: 00000000 EDX: f122e8fc [246916.338059] ESI: 00000000 EDI: 00000000 EBP: f6595d30 ESP: f6595d1c [246916.338062] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [246916.338064] Process insmod (pid: 29265, ti=f6594000 task=f7343fe0 task.ti=f6594000) [246916.338067] Stack: [246916.338068] c04a2920 22222222 f6595d48 00000000 f122f080 f6595d48 c02ca489 f122e8fc [246916.338076] f122e220 f122f080 f122e220 f6595d5c f8a03156 f122e220 f122f080 f122e220 [246916.338085] f6595d80 f87359af f122f080 00002000 f874e129 f122f150 f122f080 f6290000 [246916.338094] Call Trace: [246916.338096] [<c02ca489>] ? unregister_netdevice+0x19/0x70 [246916.338100] [<f8a03156>] ? ieee80211_unregister_hw+0x36/0xd0 [mac80211] [246916.338112] [<f87359af>] ? ath_detach+0xcf/0x250 [ath9k] [246916.338127] [<f8735d9c>] ? ath_attach+0x26c/0x740 [ath9k] [246916.338139] [<f873c33a>] ? ath_pci_probe+0x13a/0x310 [ath9k] [246916.338151] [<c0233e28>] ? _raw_spin_unlock+0x68/0x80 [246916.338158] [<c023ab8e>] ? local_pci_probe+0xe/0x10 [246916.338162] [<c023b8e0>] ? pci_device_probe+0x60/0x80 [246916.338169] [<c029e042>] ? driver_probe_device+0x82/0x1b0 [246916.338174] [<c029e1f9>] ? __driver_attach+0x89/0x90 [246916.338180] [<c029d97b>] ? bus_for_each_dev+0x4b/0x70 [246916.338184] [<c023b820>] ? pci_device_remove+0x0/0x40 [246916.338190] [<c029ded9>] ? driver_attach+0x19/0x20 [246916.338193] [<c029e170>] ? __driver_attach+0x0/0x90 [246916.338197] [<c029d317>] ? bus_add_driver+0x1b7/0x230 [246916.338203] [<c023b820>] ? pci_device_remove+0x0/0x40 [246916.338206] [<c029e399>] ? driver_register+0x69/0x140 [246916.338212] [<f859d000>] ? ath9k_init+0x0/0x54 [ath9k] [246916.338221] [<c023bb4e>] ? __pci_register_driver+0x4e/0x90 [246916.338225] [<f859d000>] ? ath9k_init+0x0/0x54 [ath9k] [246916.338232] [<f859d06b>] ? ath_pci_init+0x17/0x19 [ath9k] [246916.338238] [<f859d017>] ? ath9k_init+0x17/0x54 [ath9k] [246916.338245] [<c017148e>] ? tracepoint_update_probe_range+0x7e/0xb0 [246916.338249] [<c010111a>] ? do_one_initcall+0x2a/0x170 [246916.338252] [<c0149f26>] ? up_read+0x16/0x30 [246916.338256] [<c014aa9d>] ? __blocking_notifier_call_chain+0x4d/0x60 [246916.338265] [<c0162b1a>] ? sys_init_module+0x8a/0x1c0 [246916.338269] [<c022f888>] ? trace_hardirqs_on_thunk+0xc/0x10 [246916.338272] [<c0103ebf>] ? sysenter_do_call+0x12/0x43 [246916.338276] Code: 8d bc 27 00 00 00 00 55 89 e5 56 89 c6 53 83 ec 0c a1 74 27 4a c0 85 c0 0f 85 4b 01 00 00 e8 04 7d 00 00 85 c0 0f 84 c9 01 00 00 <8b> 86 18 03 00 00 85 c0 0f 84 86 01 00 00 83 e8 01 0f 85 71 01 [246916.338328] EIP: [<c02ca274>] rollback_registered+0x24/0x220 SS:ESP 0068:f6595d1c [246916.338335] ---[ end trace 76357c56a75ea34e ]--- Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * orinoco: do not resgister NULL pm_notifier functionAndrey Borzenkov2009-02-231-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With DEBUG_NOTIFIERS it results in [11330.890966] WARNING: at /home/bor/src/linux-git/kernel/notifier.c:88 notifier_call_chain+0x91/0xa0() [11330.890977] Hardware name: PORTEGE 4000 [11330.890983] Invalid notifier called! ... Without DEBUG_NOTIFIERS it most likely crashes on NULL pointer. Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru> Acked-by: David Kilroy <kilroyd@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | asix: new device idsGreg Kroah-Hartman2009-02-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds two new device ids to the asix driver. One comes directly from the asix driver on their web site, the other was reported by Armani Liao as needed for the MSI X320 to get the driver to work properly for it. Reported-by: Armani Liao <aliao@novell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | tcp_scalable: Update malformed & dead urlJoe Perches2009-02-241-1/+1
| | | | | | | | | | | | | | | Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * | Merge branch 'master' of ↵David S. Miller2009-02-246-65/+153
| |\ \ | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6
| | * | netfilter: xt_recent: fix proc-file addition/removal of IPv4 addressesJosef Drexler2009-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * | netfilter: make proc/net/ip* print names from foreign NFPROTOJan Engelhardt2009-02-181-57/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When extensions were moved to the NFPROTO_UNSPEC wildcard in ab4f21e6fb1c09b13c4c3cb8357babe8223471bd, they disappeared from the procfs files. Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
| | * | netfilter: nf_conntrack: don't try to deliver events for untracked connectionsPatrick McHardy2009-02-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The untracked conntrack actually does usually have events marked for delivery as its not special-cased in that part of the code. Skip the actual delivery since it impacts performance noticeably. Signed-off-by: Patrick McHardy <kaber@trash.net>
| | * | netfilter: nfnetlink_log: fix timeout handlingEric Leblond2009-02-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NFLOG timeout was computed in timer by doing: flushtimeout*HZ/100 Default value of flushtimeout was HZ (for 1 second delay). This was wrong for non 100HZ computer. This patch modify the default delay by using 100 instead of HZ. Signed-off-by: Eric Leblond <eric@inl.fr> Signed-off-by: Patrick McHardy <kaber@trash.net>
| | * | netfilter: nfnetlink_log: fix per-rule qthreshold overrideEric Leblond2009-02-182-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In NFLOG the per-rule qthreshold should overrides per-instance only it is set. With current code, the per-rule qthreshold is 1 if not set and it overrides the per-instance qthreshold. This patch modifies the default xt_NFLOG threshold from 1 to 0. Thus a value of 0 means there is no per-rule setting and the instance parameter has to apply. Signed-off-by: Eric Leblond <eric@inl.fr> Signed-off-by: Patrick McHardy <kaber@trash.net>
| | * | netfilter: nf_conntrack_ipv6: fix nf_log_packet message in icmpv6 conntrackEric Leblond2009-02-181-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a trivial typo that was adding a new line at end of the nf_log_packet() prefix. It also make the logging conditionnal by adding a LOG_INVALID test. Signed-off-by: Eric Leblond <eric@inl.fr> Signed-off-by: Patrick McHardy <kaber@trash.net>
| | * | Merge branch 'master' of /repos/git/net-2.6Patrick McHardy2009-02-185-20/+12
| | |\ \
| * | \ \ Merge branch 'master' of /home/davem/src/GIT/linux-2.6/David S. Miller2009-02-24754-7709/+17542
| |\ \ \ \
* | | | | | qlge: Use one path to (re)fill rx buffers.Ron Mercer2009-02-241-111/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently there are two paths for filling rx buffer queues. One is used during initialization and the other during runtime. This patch removes ql_alloc_sbq_buffers() and ql_alloc_lbq_buffers() and replaces them with a call to the runtime functions ql_update_lbq() and ql_update_sbq(). Signed-off-by: Ron Mercer <ron.mercer@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | | | | qlge: Optimize rx buffer refill process.Ron Mercer2009-02-241-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RX Buffers are refilled in chunks of 16 at a time before notifying the hardware with a register write. This can cause several writes to take place in a given napi poll call. This change causes the write to take place only once at the end of the call. Signed-off-by: Ron Mercer <ron.mercer@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
OpenPOWER on IntegriCloud