Attention is currently required from: laforge, pespin.

fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/37964?usp=email )

Change subject: pfcp_peer: do not route incoming PDUs without SEID ......................................................................

Patch Set 4:

(1 comment)

This change is ready for review.

File src/pfcp_peer.erl:

https://gerrit.osmocom.org/c/erlang/osmo-s1gw/+/37964/comment/ae4d5fe2_840cd... : PS1, Line 233: ?LOG_NOTICE("Rx unexpected PFCP PDU: ~p", [PDU])

Acknowledged

Going back to this idea, I checked 3GPP TS 29.244 and here is what it states:

``` 7.6.4 Unknown PFCP Message

If a PFCP entity receives a message with an unknown Message Type value, it shall silently discard the message.

7.6.5 Unexpected PFCP Message

If a PFCP entity receives an unexpected request message, for example a known message that is sent over an interface for which the message is not defined, or a message that is sent over an interface for which the message is defined, but the direction is incorrect, then the PFCP entity shall silently discard the message and shall log an error.

If a PFCP entity receives an unexpected response message which is not a request message, for example a message for which there is no corresponding outstanding request, it shall discard the message and may log an error. ```

In our specific case we implement only a limited subset of PFCP procedures/messages, and I am not sure if the rules described in 7.6.4-5 apply to not supported messages. From the spec. point of view we shall implement all procedures and the related messages.

Regardless of how we interpret the spec. requirements, implementing the response logic is a significant effort. The problem is that there exists no single message type to indicate an error, so we would need to craft a proper response for each unexpected request kind, which involves adding all mandatory IEs.

Taking the above into account, I suggest merging this patch as-is.