#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
197083 |
|
10-Sep-2009 |
emax |
Get those pesky RFCOMM RPM data bits right. This is likely a noop.
MFC after: 1 month
|
#
160549 |
|
21-Jul-2006 |
rwatson |
Change semantics of socket close and detach. Add a new protocol switch function, pru_close, to notify protocols that the file descriptor or other consumer of a socket is closing the socket. pru_abort is now a notification of close also, and no longer detaches. pru_detach is no longer used to notify of close, and will be called during socket tear-down by sofree() when all references to a socket evaporate after an earlier call to abort or close the socket. This means detach is now an unconditional teardown of a socket, whereas previously sockets could persist after detach of the protocol retained a reference.
This faciliates sharing mutexes between layers of the network stack as the mutex is required during the checking and removal of references at the head of sofree(). With this change, pru_detach can now assume that the mutex will no longer be required by the socket layer after completion, whereas before this was not necessarily true.
Reviewed by: gnn
|
#
157370 |
|
01-Apr-2006 |
rwatson |
Chance protocol switch method pru_detach() so that it returns void rather than an error. Detaches do not "fail", they other occur or the protocol flags SS_PROTOREF to take ownership of the socket.
soclose() no longer looks at so_pcb to see if it's NULL, relying entirely on the protocol to decide whether it's time to free the socket or not using SS_PROTOREF. so_pcb is now entirely owned and managed by the protocol code. Likewise, no longer test so_pcb in other socket functions, such as soreceive(), which have no business digging into protocol internals.
Protocol detach routines no longer try to free the socket on detach, this is performed in the socket code if the protocol permits it.
In rts_detach(), no longer test for rp != NULL in detach, and likewise in other protocols that don't permit a NULL so_pcb, reduce the incidence of testing for it during detach.
netinet and netinet6 are not fully updated to this change, which will be in an upcoming commit. In their current state they may leak memory or panic.
MFC after: 3 months
|
#
157366 |
|
01-Apr-2006 |
rwatson |
Change protocol switch pru_abort() API so that it returns void rather than an int, as an error here is not meaningful. Modify soabort() to unconditionally free the socket on the return of pru_abort(), and modify most protocols to no longer conditionally free the socket, since the caller will do this.
This commit likely leaves parts of netinet and netinet6 in a situation where they may panic or leak memory, as they have not are not fully updated by this commit. This will be corrected shortly in followup commits to these components.
MFC after: 3 months
|
#
151888 |
|
30-Oct-2005 |
rwatson |
Push the assignment of a new or updated so_qlimit from solisten() following the protocol pru_listen() call to solisten_proto(), so that it occurs under the socket lock acquisition that also sets SO_ACCEPTCONN. This requires passing the new backlog parameter to the protocol, which also allows the protocol to be aware of changes in queue limit should it wish to do something about the new queue limit. This continues a move towards the socket layer acting as a library for the protocol.
Bump __FreeBSD_version due to a change in the in-kernel protocol interface. This change has been tested with IPv4 and UNIX domain sockets, but not other protocols.
|
#
140027 |
|
10-Jan-2005 |
emax |
Make default RFCOMM session MTU match default L2CAP MTU.
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
|
#
139823 |
|
06-Jan-2005 |
imp |
/* -> /*- for license, minor formatting changes
|
#
122634 |
|
14-Nov-2003 |
emax |
Change double include protection style in headers to match the rest of Netgraph code.
Reviewed by: imp, ru Approved by: imp (mentor)
|
#
114878 |
|
10-May-2003 |
julian |
Part one of undating the bluetooth code to the newest version
Submitted by: Maksim Yevmenkin <m_evmenkin@yahoo.com> Approved by: re@
|