summaryrefslogtreecommitdiffstats
path: root/sys/netgraph/bluetooth
Commit message (Collapse)AuthorAgeFilesLines
* Eliminate unused argument in PCMCIA_CARD macro.imp2005-06-241-1/+1
| | | | | | | | Provide a backwards compatible way to have the extra macro by defining PCCARD_API_LEVEL 5 before including pccarddevs for driver writers that want/need to have the same driver on 5 and 6 with pccard attachments. Approved by: re (dwhite)
* Move AVM USB Bluetooth-Adapter BlueFritz! from "broken" devices listemax2005-05-281-4/+6
| | | | | | | (where I incorrectly put it initially) to "ignored" devices list (where it should be). Pointy hat goes to me. MFC after: 3 days
* Mark AVM USB Bluetooth-Adapter BlueFritz! as "broken". This device is notemax2005-05-101-1/+1
| | | | | | | | supported by ng_ubt(4) driver and needs its own driver. PR: kern/76205 Submitted by: Tim Hemel < bsd AT timit DOT nl > MFC after: 1 week
* Change the embedded module name from "bluetooth" to "ng_bluetooth" to matchpeter2005-04-081-1/+1
| | | | the rest of the names assigned to this object.
* Correct typo that could cause FIFO overflow.emax2005-04-061-1/+1
| | | | | PR: kern/78431 MFC after: 3 days
* Remove PR_ATOMIC flag in ng_btsocket_protosw[] for BLUETOOTH_PROTO_RFCOMMemax2005-04-061-1/+1
| | | | | | | | protocol. RFCOMM is a SOCK_STREAM protocol not SOCK_SEQPACKET. This was a serious bug caused by cut-and-paste. I'm surprised it did not bite me before. Dunce hat goes to me. MFC after: 3 days
* In ng_btsocket_rfcomm_receive_frame() correctly set length variable whenemax2005-04-061-1/+1
| | | | | | | EA bit is set in hdr->length (16-bit length). This currently has no effect on the rest of the code. It just fixes the debug message. MFC After: 3 weeks
* move ptr use down to after null checksam2005-02-261-3/+3
| | | | | Noticed by: Coverity Prevent analysis tool Reviewed by: emax
* In the current world order, solisten() implements the state transition ofrwatson2005-02-212-25/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a socket from a regular socket to a listening socket able to accept new connections. As part of this state transition, solisten() calls into the protocol to update protocol-layer state. There were several bugs in this implementation that could result in a race wherein a TCP SYN received in the interval between the protocol state transition and the shortly following socket layer transition would result in a panic in the TCP code, as the socket would be in the TCPS_LISTEN state, but the socket would not have the SO_ACCEPTCONN flag set. This change does the following: - Pushes the socket state transition from the socket layer solisten() to to socket "library" routines called from the protocol. This permits the socket routines to be called while holding the protocol mutexes, preventing a race exposing the incomplete socket state transition to TCP after the TCP state transition has completed. The check for a socket layer state transition is performed by solisten_proto_check(), and the actual transition is performed by solisten_proto(). - Holds the socket lock for the duration of the socket state test and set, and over the protocol layer state transition, which is now possible as the socket lock is acquired by the protocol layer, rather than vice versa. This prevents additional state related races in the socket layer. This permits the dual transition of socket layer and protocol layer state to occur while holding locks for both layers, making the two changes atomic with respect to one another. Similar changes are likely require elsewhere in the socket/protocol code. Reported by: Peter Holm <peter@holm.cc> Review and fixes from: emax, Antoine Brodin <antoine.brodin@laposte.net> Philosophical head nod: gnn
* - Use ng_callout() instead of home-grown implementation.glebius2005-01-112-22/+4
| | | | Submitted by: emax
* Make default RFCOMM session MTU match default L2CAP MTU.emax2005-01-111-3/+3
| | | | | | | | | | | | | | | | | | | | This is just a workaround for a know problem with Motorola E1000 phone. Something is wrong with the configuration of L2CAP/RFCOMM channel. Even though we set L2CAP MTU to 132 bytes (default RFCOMM MTU 127 + 5 bytes RFCOMM frame header) and the phone accepts it, the phone still sends oversized L2CAP packets. It appears that the phone wants to use bigger (667 bytes) RFCOMM frames, but it does not segment them according to the configured L2CAP MTU. The 667 bytes RFCOMM frame size corresponds to the default L2CAP MTU of 672 bytes (667 + 5 bytes RFCOMM frame header). This problem only appears if connection was initiated from the phone. I'm not sure who is at fault here, so for now just put workaround in place. Quick look at the spec did not reveal any anwser. Tested by: Jes < jjess at freebsd dot polarhome dot com > MFC after: 3 days
* /* -> /*- for license, minor formatting changesimp2005-01-0748-48/+144
|
* Rename 'class' field to 'uclass' in the ng_hci_inquiry_response structure.emax2005-01-041-1/+1
| | | | | | | class is a reserved word in C++ Submitted by: Markus Brueffer < markus AT brueffer DOT de > MFC after: 3 days
* Mechanically rename s/ng_timeout/ng_callout/g, s/ng_untimeout/ng_uncallout/g.glebius2004-12-012-15/+15
| | | | | | | This is done to keep both versions in RELENG_5 and support both APIs. Reviewed by: scottl Approved by: julian (mentor), implicitly
* Move ng_socket and ng_btsocket initialization to SI_SUB_PROTO_DOMAIN as theymlaier2004-11-301-1/+2
| | | | | | | | | | | | | | | call net_add_domain(). Calling this function too early (or late) breaks assertations about the global domains list. Actually it should be forbidden to call net_add_domain() outside of SI_SUB_PROTO_DOMAIN completely as there are many places where we traverse the domains list unprotected, but for now we allow late calls (mostly to support netgraph). In order to really fix this we have to lock the domains list in all places or find another way to ensure that we can safely walk the list while another thread might be adding a new domain. Spotted by: se Reviewed by: julian, glebius PR: kern/73321 (partly)
* Correct typo. Return ENXIO instead of EIO.emax2004-11-191-1/+1
|
* Initialize struct pr_userreqs in new/sparse style and fill in commonphk2004-11-081-84/+48
| | | | | | default elements in net_init_domain(). This makes it possible to grep these structures and see any bogosities.
* Fix kernel build (caused by recent ng_{un}timeout API change)emax2004-11-035-23/+23
| | | | Submitted by: glebius
* Fix broken ng_h4(4). Basically, do not abuse t_sc field and use new t_lscemax2004-11-021-7/+9
| | | | | field created for line disciplne drivers private use. Also add NET_NEEDS_GIANT warning. For whatever reason ng_tty(4) was fixed but ng_h4(4) was not :(
* Push acquisition of the accept mutex out of sofree() into the callerrwatson2004-10-184-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (sorele()/sotryfree()): - This permits the caller to acquire the accept mutex before the socket mutex, avoiding sofree() having to drop the socket mutex and re-order, which could lead to races permitting more than one thread to enter sofree() after a socket is ready to be free'd. - This also covers clearing of the so_pcb weak socket reference from the protocol to the socket, preventing races in clearing and evaluation of the reference such that sofree() might be called more than once on the same socket. This appears to close a race I was able to easily trigger by repeatedly opening and resetting TCP connections to a host, in which the tcp_close() code called as a result of the RST raced with the close() of the accepted socket in the user process resulting in simultaneous attempts to de-allocate the same socket. The new locking increases the overhead for operations that may potentially free the socket, so we will want to revise the synchronization strategy here as we normalize the reference counting model for sockets. The use of the accept mutex in freeing of sockets that are not listen sockets is primarily motivated by the potential need to remove the socket from the incomplete connection queue on its parent (listen) socket, so cleaning up the reference model here may allow us to substantially weaken the synchronization requirements. RELENG_5_3 candidate. MFC after: 3 days Reviewed by: dwhite Discussed with: gnn, dwhite, green Reported by: Marc UBM Bocklet <ubm at u-boot-man dot de> Reported by: Vlad <marchenko at gmail dot com>
* Get rid of device nodes interface. It is useless and confusing.emax2004-10-122-532/+1
| | | | | | | | | | The original idea was to use it for firmware upgrading and similar operations. In real life almost all Bluetooth USB devices do not need firmware download. If device does require firmware download then ugen(4) (or specialized driver like ubtbcmfw(8)) should be used instead. MFC after: 3 days
* Align netgraph message fields ready for 64-bit (and 128 bit :-) machines.julian2004-08-201-6/+1
| | | | | | | | | | requires a recompile of netgraph users. Also change the size of a field in the bluetooth code that was waiting for the next change that needed recompiles so it could piggyback its way in. Submitted by: jdp, maksim MFC after: 2 days
* Introduce ng_hci_inquiry_response structure and use it in the hccontrol(8)emax2004-08-101-7/+10
|
* MFp4: Last references to dev/usb/usbdevs.h converted.imp2004-06-272-2/+4
|
* Catch up with usbd_get_string_desc() change.le2004-06-261-1/+1
| | | | Spotted by: Tai-hwa Liang <avatar@mmlab.cse.yzu.edu.tw>
* Fix line discipline switching issues: If opening a new ldisc fails,phk2004-06-261-10/+1
| | | | | | | | | | | | | we have to revert to TTYDISC which we know will successfully open rather than try the previous ldisc which might also fail to open. Do not let ldisc implementations muck about with ->t_line, and remove code which checks for reopens, it should never happen. Move ldisc->l_hotchar to tty->t_hotchar and have ldisc implementation initialize it in their open routines. Reset to zero when we enter TTYDISC. ("no" should really be -1 since zero could be a valid hotchar for certain old european mainframe protocols.)
* Add '#include <sys/mbuf.h>' to fix the kernel build.emax2004-06-251-0/+1
|
* Correct merge-o: make sure to unlock symmetrically socket bufferrwatson2004-06-181-2/+2
| | | | | | locks on bluetooth sockets when clearing upcall flags. Submitted by: emax
* Merge additional socket buffer locking from rwatson_netperf:rwatson2004-06-171-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | - Lock down low hanging fruit use of sb_flags with socket buffer lock. - Lock down low hanging fruit use of so_state with socket lock. - Lock down low hanging fruit use of so_options. - Lock down low-hanging fruit use of sb_lowwat and sb_hiwat with socket buffer lock. - Annotate situations in which we unlock the socket lock and then grab the receive socket buffer lock, which are currently actually the same lock. Depending on how we want to play our cards, we may want to coallesce these lock uses to reduce overhead. - Convert a if()->panic() into a KASSERT relating to so_state in soaccept(). - Remove a number of splnet()/splx() references. More complex merging of socket and socket buffer locking to follow.
* Second half of the dev_t cleanup.phk2004-06-172-21/+21
| | | | | | | | | | | The big lines are: NODEV -> NULL NOUDEV -> NODEV udev_t -> dev_t udev2dev() -> findcdev() Various minor adjustments including handling of userland access to kernel space struct cdev etc.
* Do the dreaded s/dev_t/struct cdev */phk2004-06-164-20/+20
| | | | Bump __FreeBSD_version accordingly.
* The socket field so_state is used to hold a variety of socket relatedrwatson2004-06-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | flags relating to several aspects of socket functionality. This change breaks out several bits relating to send and receive operation into a new per-socket buffer field, sb_state, in order to facilitate locking. This is required because, in order to provide more granular locking of sockets, different state fields have different locking properties. The following fields are moved to sb_state: SS_CANTRCVMORE (so_state) SS_CANTSENDMORE (so_state) SS_RCVATMARK (so_state) Rename respectively to: SBS_CANTRCVMORE (so_rcv.sb_state) SBS_CANTSENDMORE (so_snd.sb_state) SBS_RCVATMARK (so_rcv.sb_state) This facilitates locking by isolating fields to be located with other identically locked fields, and permits greater granularity in socket locking by avoiding storing fields with different locking semantics in the same short (avoiding locking conflicts). In the future, we may wish to coallesce sb_state and sb_flags; for the time being I leave them separate and there is no additional memory overhead due to the packing/alignment of shorts in the socket buffer structure.
* Extend coverage of SOCK_LOCK(so) to include so_count, the socketrwatson2004-06-124-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | reference count: - Assert SOCK_LOCK(so) macros that directly manipulate so_count: soref(), sorele(). - Assert SOCK_LOCK(so) in macros/functions that rely on the state of so_count: sofree(), sotryfree(). - Acquire SOCK_LOCK(so) before calling these functions or macros in various contexts in the stack, both at the socket and protocol layers. - In some cases, perform soisdisconnected() before sotryfree(), as this could result in frobbing of a non-present socket if sotryfree() actually frees the socket. - Note that sofree()/sotryfree() will release the socket lock even if they don't free the socket. Submitted by: sam Sponsored by: FreeBSD Foundation Obtained from: BSD/OS
* Integrate accept locking from rwatson_netperf, introducing a newrwatson2004-06-021-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | global mutex, accept_mtx, which serializes access to the following fields across all sockets: so_qlen so_incqlen so_qstate so_comp so_incomp so_list so_head While providing only coarse granularity, this approach avoids lock order issues between sockets by avoiding ownership of the fields by a specific socket and its per-socket mutexes. While here, rewrite soclose(), sofree(), soaccept(), and sonewconn() to add assertions, close additional races and address lock order concerns. In particular: - Reorganize the optimistic concurrency behavior in accept1() to always allocate a file descriptor with falloc() so that if we do find a socket, we don't have to encounter the "Oh, there wasn't a socket" race that can occur if falloc() sleeps in the current code, which broke inbound accept() ordering, not to mention requiring backing out socket state changes in a way that raced with the protocol level. We may want to add a lockless read of the queue state if polling of empty queues proves to be important to optimize. - In accept1(), soref() the socket while holding the accept lock so that the socket cannot be free'd in a race with the protocol layer. Likewise in netgraph equivilents of the accept1() code. - In sonewconn(), loop waiting for the queue to be small enough to insert our new socket once we've committed to inserting it, or races can occur that cause the incomplete socket queue to overfill. In the previously implementation, it was sufficient to simply tested once since calling soabort() didn't release synchronization permitting another thread to insert a socket as we discard a previous one. - In soclose()/sofree()/et al, it is the responsibility of the caller to remove a socket from the incomplete connection queue before calling soabort(), which prevents soabort() from having to walk into the accept socket to release the socket from its queue, and avoids races when releasing the accept mutex to enter soabort(), permitting soabort() to avoid lock ordering issues with the caller. - Generally cluster accept queue related operations together throughout these functions in order to facilitate locking. Annotate new locking in socketvar.h.
* The SS_COMP and SS_INCOMP flags in the so_state field indicate whetherrwatson2004-06-011-1/+1
| | | | | | | | the socket is on an accept queue of a listen socket. This change renames the flags to SQ_COMP and SQ_INCOMP, and moves them to a new state field on the socket, so_qstate, as the locking for these flags is substantially different for the locking on the remainder of the flags in so_state.
* add missing #include <sys/module.h>phk2004-05-303-0/+3
|
* Missed these in the last commit.julian2004-05-293-36/+31
| | | | Change to C99 structure initialisation for the type method structure.
* Switch to using C99 sparse initialisers for the type methods array.julian2004-05-295-62/+49
| | | | | | | | Should make no binary difference. Submitted by: Gleb Smirnoff <glebius@cell.sick.ru> Reviewed by: Harti Brandt <harti@freebsd.org> MFC after: 1 week
* Move to generating pccarddevs.h on the fly, both for the kernel andimp2004-05-261-1/+1
| | | | | | | the modules. Also generate usbdevs.h automatically now, but a non-kernel file is stopping that at the moment.
* Mode few Bluetooth defines into system include filesemax2004-05-103-21/+1
| | | | Reviewed by: imp
* Address few style issues pointed out by bdeemax2004-04-2720-132/+132
| | | | Reviewed by: bde, ru
* Make sure RFCOMM multiplexor channel does not hang in DISCONNECTINGemax2004-04-231-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | state. Apparently it happens when both devices try to disconnect RFCOMM multiplexor channel at the same time. The scenario is as follows: - local device initiates RFCOMM connection to the remote device. This creates both RFCOMM multiplexor channel and data channel; - remote device terminates RFCOMM data channel (inactivity timeout); - local device acknowledges RFCOMM data channel termination. Because there is no more active data channels and local device has initiated connection it terminates RFCOMM multiplexor channel; - remote device does not acknowledges RFCOMM multiplexor channel termination. Instead it sends its own request to terminate RFCOMM multiplexor channel. Even though local device acknowledges RFCOMM multiplexor channel termination the remote device still keeps L2CAP connection open. Because of hanging RFCOMM multiplexor channel subsequent RFCOMM connections between local and remote devices will fail. Reported by: Johann Hugo <jhugo@icomtek.csir.co.za>
* Make sure Bluetooth stuff can be compiled on amd64emax2004-04-0910-36/+36
| | | | Submitted by: ps
* Convert callers to the new bus_alloc_resource_any(9) API.njl2004-03-171-2/+2
| | | | | Submitted by: Mark Santcroos <marks@ripe.net> Reviewed by: imp, dfr, bde
* Rename dup_sockaddr() to sodupsockaddr() for consistency with otherrwatson2004-03-014-7/+7
| | | | | | | | | | | | functions in kern_socket.c. Rename the "canwait" field to "mflags" and pass M_WAITOK and M_NOWAIT in from the caller context rather than "1" or "0". Correct mflags pass into mac_init_socket() from previous commit to not include M_ZERO. Submitted by: sam
* Device megapatch 4/6:phk2004-02-212-0/+4
| | | | | | | | Introduce d_version field in struct cdevsw, this must always be initialized to D_VERSION. Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
* Device megapatch 1/6:phk2004-02-212-14/+0
| | | | | | | Free approx 86 major numbers with a mostly automatically generated patch. A number of strategic drivers have been left behind by caution, and a few because they still (ab)use their major number.
* Replace deprecated NG_NODELEN with the new NG_NODESIZ. There is oneharti2004-01-263-4/+9
| | | | | | | problem here still to be solved: the sockaddr_hci has still a 16 byte field for the node name. The code currently does not correctly use the length field in the sockaddr to handle the address length, so node names get truncated to 15 characters when put into a sockaddr_hci.
* NULL -> 0 where appropriate.alfred2003-12-243-18/+18
|
* Introduce a MAC label reference in 'struct inpcb', which cachesrwatson2003-11-181-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | the MAC label referenced from 'struct socket' in the IPv4 and IPv6-based protocols. This permits MAC labels to be checked during network delivery operations without dereferencing inp->inp_socket to get to so->so_label, which will eventually avoid our having to grab the socket lock during delivery at the network layer. This change introduces 'struct inpcb' as a labeled object to the MAC Framework, along with the normal circus of entry points: initialization, creation from socket, destruction, as well as a delivery access control check. For most policies, the inpcb label will simply be a cache of the socket label, so a new protocol switch method is introduced, pr_sosetlabel() to notify protocols that the socket layer label has been updated so that the cache can be updated while holding appropriate locks. Most protocols implement this using pru_sosetlabel_null(), but IPv4/IPv6 protocols using inpcbs use the the worker function in_pcbsosetlabel(), which calls into the MAC Framework to perform a cache update. Biba, LOMAC, and MLS implement these entry points, as do the stub policy, and test policy. Reviewed by: sam, bms Obtained from: TrustedBSD Project Sponsored by: DARPA, Network Associates Laboratories
OpenPOWER on IntegriCloud