-
Notifications
You must be signed in to change notification settings - Fork 840
-
Notifications
You must be signed in to change notification settings - Fork 840
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Corrupted data packet at SRT receiver output when using encryption / decryption #2502
Comments
If you are talking about the continuity count error in MPEG-TS or DVB-SI streams as defined by TR 101 290, then one thing is important about SRT: the only way how the input stream can be modified in the output is when SRT drops packets that were abandoned due to delivery time requirements (as required by TLPKTDROP mechanism). Apart from that, there are no mechanisms in SRT that would anyhow modify the transmitted data, encrypted or not, and definitely not in exactly the 4-th byte of the payload. SRT doesn't even know what kind of data it transmits. If you can show us an example of an input stream that is perfectly correct (at least as it comes to the continuity bits) on the input and SRT has modified this stream anyhow during the transport and caused errors, we can investigate. Without this we don't even know where to search for anything. |
Yes this is about the CC count in an MPEG-TS stream. AES encryption does change the data wright ? |
If the problem was with decryption, you would see these packets as missing. There is also in the statistics structure the The encryption key change mechanism is executing the procedure in 3 steps: PREANNOUNCE, SWITCH, DECOMMISSION. The SWITCH event happens after transmitting the number of packets configured as It will still help if you show us the configuration of your transmission; maybe we can figure out where to hook up. If you experience CC errors then likely also the PES packets for which are incomplete and contain further errors, but if this is anyhow caused by SRT, then you should be losing usually 7 TS packets for one lost UDP packet. The continuity counter is 4 bits, so up to 16 you should be able to find out precisely, how many network packets are missing. |
Thanks for your feedback. The configuration is: |
The RTP transport stream capture at the output of the SRT receiver confirms there's a missing RTP packet (and CC errors). |
In a new test we have changed the code to not encrypt/decrypt the first 16 bytes of the data so the RTP sequence headers remain clear in our SRT traffic capture. With this change and during a CC error event, we see no missing RTP packet sequence number in the SRT capture around the key change. More important, with every CC error logged by our monitoring system, there's also a sync byte error. So our previous conclusion that there's a missing RTP packet is probably not correct, the capture may have dropped it based on a unrecognized RTP version or first sync byte being incorrect (to be confirmed). |
A capture of the receiver output with the original code (that encrypts all data) indeed shows a malformed RTP packet, I previously overlooked that in Wireshark. So confirms the non matching key theory. |
To further debug we've added the encryption key data in the last bytes of the RTP packet and with that found that the problem is introduced at the SRT sender side. This can be seen in a capture of the SRT packets around the CC error event: in the last SRT packet with encryption status "encrypted with odd key", the key data already is the key data for the next packet with encryption status "encrypted with even key". Do you have enough information to investigate ? |
Proposed Test CaseUse Network: localhost, with artificial impairments 1% packet loss and 50 ms RTT. The KM refresh period can be set using the (receive)
.srt-xtransmit receive "srt://:4200?passphrase=abcdefghijk" --enable-metrics --logfa "HAICRYPT" -v
srt-xtransmit generate "srt://127.0.0.1:4200?passphrase=abcdefghijk&kmrefreshrate=1024" --enable-metrics \
--sendrate 1Mbps -v --logfa "HAICRYPT" --loglevel note On the sender side the KM refresh events can be found by the following log lines: 11:47:25.050000/T19568.N:SRT.hc: KM[0] Pre-announced
11:47:30.421000/T19568.N:SRT.hc: KM[0] Activated
11:47:35.828000/T19568.N:SRT.hc: KM[1] Deprecated The [I] RECEIVE Latency, us: avg 125979, min 123590, max 127155. Jitter: 254us. Delay Factor: 3564us.
Pkts: rcvd 116998, reordered 0 (dist 0), lost 0, wrong checksums 0, wrong lengths 0 |
Hi Max, thanks for your suggestion. I believe it will not bring more information by checking MD5 checksum and length. As I indicated above, the capture of the SRT receive side output showed a malformed RTP packet with correct length. It was malformed because it was decrypted with a non matching key and resulting in corrupted RTP data. |
Hi @mvandenbroecke |
The RcvQ Thread switches the active key (odd/even): CUDT::processCtrlAck(..)
⋅ ⋅ CUDT::checkSndTimers(..)
⋅ ⋅ ⋅ ⋅ CCryptoControl::sendKeysToPeer(..) // Key refresh The SndQ Thread first sets the KK frags of a data packet, then encrypts the packet, potentially with a different key if KM refresh has happened. CUDT::packUniqueData(..)
⋅ ⋅ CCryptoControl::encrypt(..) |
Transport stream delivered by the SRT receiver now and then has a continuity count error.
Steps to reproduce the behavior:
Expect no CC errors.
OS: Linux
SRT Version: 1.4.4
The text was updated successfully, but these errors were encountered: