aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/Makefile
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2015-03-21 10:56:28 +0100
committerAnders Svensson <[email protected]>2015-03-23 13:15:29 +0100
commit5228b6e5e3906a7a26e2e730b9f0213844e967a8 (patch)
treebc7b5523cd76a0fe0ba3713ca1ddf4b89783aaad /lib/diameter/Makefile
parent7d05e55951b4f3fc4af0febb965d3075e5ddf324 (diff)
downloadotp-5228b6e5e3906a7a26e2e730b9f0213844e967a8.tar.gz
otp-5228b6e5e3906a7a26e2e730b9f0213844e967a8.tar.bz2
otp-5228b6e5e3906a7a26e2e730b9f0213844e967a8.zip
Be lenient with errors in incoming DPR
To avoid having the peer interpret the error as meaning the connection shouldn't be closed, which probably does more harm than ignoring syntactic errors in the DPR. Note that RFC 6733 says this about incoming DPR, in 5.4 Disconnecting Peer Connections: Upon receipt of the message, the Disconnect-Peer-Answer message is returned, which SHOULD contain an error if messages have recently been forwarded, and are likely in flight, which would otherwise cause a race condition. The race here is presumably between answers to forwarded requests and the outgoing DPA, but we have no handling for this: whether or not there are pending answers is irrelevant to how DPR is answered. It's questionable that a peer should be able to prevent disconnection in any case: it has to be the node sending DPR that decides if it's approriate, and the peer should take it as an indication of what's coming. Incoming DPA is already treated leniently: the only error that's not ignored is mismatching End-to-End and Hop-by-Hop Identifiers, since there's no distinguishing an erroneous value from an unsolicited DPA. This mismatch could also be ignored, which is the case for DWA for example, but this problem is already dealt with by dpa_timeout, which causes a connection to be closed even when the expected DPA isn't received.
Diffstat (limited to 'lib/diameter/Makefile')
0 files changed, 0 insertions, 0 deletions