|
@@ -433,6 +433,13 @@ AF_RXRPC sockets support a few socket options at the SOL_RXRPC level:
|
|
|
Encrypted checksum plus entire packet padded and encrypted, including
|
|
|
actual packet length.
|
|
|
|
|
|
+ (*) RXRPC_UPGRADEABLE_SERVICE
|
|
|
+
|
|
|
+ This is used to indicate that a service socket with two bindings may
|
|
|
+ upgrade one bound service to the other if requested by the client. optval
|
|
|
+ must point to an array of two unsigned short ints. The first is the
|
|
|
+ service ID to upgrade from and the second the service ID to upgrade to.
|
|
|
+
|
|
|
|
|
|
========
|
|
|
SECURITY
|
|
@@ -588,7 +595,7 @@ A server would be set up to accept operations in the following manner:
|
|
|
The keyring can be manipulated after it has been given to the socket. This
|
|
|
permits the server to add more keys, replace keys, etc. whilst it is live.
|
|
|
|
|
|
- (2) A local address must then be bound:
|
|
|
+ (3) A local address must then be bound:
|
|
|
|
|
|
struct sockaddr_rxrpc srx = {
|
|
|
.srx_family = AF_RXRPC,
|
|
@@ -604,11 +611,22 @@ A server would be set up to accept operations in the following manner:
|
|
|
parameters are the same. The limit is currently two. To do this, bind()
|
|
|
should be called twice.
|
|
|
|
|
|
- (3) The server is then set to listen out for incoming calls:
|
|
|
+ (4) If service upgrading is required, first two service IDs must have been
|
|
|
+ bound and then the following option must be set:
|
|
|
+
|
|
|
+ unsigned short service_ids[2] = { from_ID, to_ID };
|
|
|
+ setsockopt(server, SOL_RXRPC, RXRPC_UPGRADEABLE_SERVICE,
|
|
|
+ service_ids, sizeof(service_ids));
|
|
|
+
|
|
|
+ This will automatically upgrade connections on service from_ID to service
|
|
|
+ to_ID if they request it. This will be reflected in msg_name obtained
|
|
|
+ through recvmsg() when the request data is delivered to userspace.
|
|
|
+
|
|
|
+ (5) The server is then set to listen out for incoming calls:
|
|
|
|
|
|
listen(server, 100);
|
|
|
|
|
|
- (4) The kernel notifies the server of pending incoming connections by sending
|
|
|
+ (6) The kernel notifies the server of pending incoming connections by sending
|
|
|
it a message for each. This is received with recvmsg() on the server
|
|
|
socket. It has no data, and has a single dataless control message
|
|
|
attached:
|
|
@@ -620,13 +638,13 @@ A server would be set up to accept operations in the following manner:
|
|
|
the time it is accepted - in which case the first call still on the queue
|
|
|
will be accepted.
|
|
|
|
|
|
- (5) The server then accepts the new call by issuing a sendmsg() with two
|
|
|
+ (7) The server then accepts the new call by issuing a sendmsg() with two
|
|
|
pieces of control data and no actual data:
|
|
|
|
|
|
RXRPC_ACCEPT - indicate connection acceptance
|
|
|
RXRPC_USER_CALL_ID - specify user ID for this call
|
|
|
|
|
|
- (6) The first request data packet will then be posted to the server socket for
|
|
|
+ (8) The first request data packet will then be posted to the server socket for
|
|
|
recvmsg() to pick up. At that point, the RxRPC address for the call can
|
|
|
be read from the address fields in the msghdr struct.
|
|
|
|
|
@@ -638,7 +656,7 @@ A server would be set up to accept operations in the following manner:
|
|
|
|
|
|
RXRPC_USER_CALL_ID - specifies the user ID for this call
|
|
|
|
|
|
- (8) The reply data should then be posted to the server socket using a series
|
|
|
+ (9) The reply data should then be posted to the server socket using a series
|
|
|
of sendmsg() calls, each with the following control messages attached:
|
|
|
|
|
|
RXRPC_USER_CALL_ID - specifies the user ID for this call
|
|
@@ -646,7 +664,7 @@ A server would be set up to accept operations in the following manner:
|
|
|
MSG_MORE should be set in msghdr::msg_flags on all but the last message
|
|
|
for a particular call.
|
|
|
|
|
|
- (9) The final ACK from the client will be posted for retrieval by recvmsg()
|
|
|
+(10) The final ACK from the client will be posted for retrieval by recvmsg()
|
|
|
when it is received. It will take the form of a dataless message with two
|
|
|
control messages attached:
|
|
|
|
|
@@ -656,7 +674,7 @@ A server would be set up to accept operations in the following manner:
|
|
|
MSG_EOR will be flagged to indicate that this is the final message for
|
|
|
this call.
|
|
|
|
|
|
-(10) Up to the point the final packet of reply data is sent, the call can be
|
|
|
+(11) Up to the point the final packet of reply data is sent, the call can be
|
|
|
aborted by calling sendmsg() with a dataless message with the following
|
|
|
control messages attached:
|
|
|
|