-
-
Notifications
You must be signed in to change notification settings - Fork 308
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
Initial support for SCTP protocol. #70
Conversation
This commits adds support for processing the headers for SCTP packets. This does not include support for any interpretation of the packet payload of SCTP data chunks. This also does no validation of the checksum value in the header.
Just noticed I failed to update the copyright header dates. Also I guessed at the version to include in the @SInCE tag. |
Thank you for your big work! |
Great, thanks! In case you're interested, I was able to verify that the packet headers were interpreted properly using nmap port scans with the -sY and -sZ options, which exercise the SCTP protocol: https://nmap.org/book/man-port-scanning-techniques.html |
That's great! |
I will implement the checksum calculation. |
Other than that, your implementation looks perfect! Thanks. |
I encountered that issue with the SctpPacket payload when I started working on the chunk support. Is there any way to have the payload be a SimplePacket until the chunk processing is added in? On the checksum - I thought that'd be a little tricky since the protocol initially used the Adler-32 algorithm, then was updated to be based on CRC32c. I found there was an implementation of Adler-32 and CRC32 in java.util.zip, but I haven't found CRC32c anywhere in the base library (it is present in Guava). |
Eventually we will need to collect payload data from Payload Data chunks, concatenate them, and pass it to the packet factory to build a payload. Until then, I think there is no other way but to leave the payload field null. On the checksum, we can provide uses an option (a system property and/or a method argument) to choose Adler-32 or CRC32c. |
I would like to get your thoughts and advice on how to go about handling the payload chunks. I was planning on implementing each chunk type as an extension of an abstract SctpChunkPacket (which handles the chunk header containing the chunk type, flags and length), then including an List within the SctpPacket in a field called chunks. I couldn't find any examples of an existing packet type with a variable number of packets as a payload, and the AbstractPacket.getPayload() method returns a single Packet. To maintain the API contract I was thinking of having SctpPacket.getPayload() return the first element in the chunks list (if present) and have a separate getChunks() method to return all of the chunks in the packet. What do you think? I also wasn't sure whether it makes sense to have the chunk objects extend Packet, but it seems like they'd work nicely as such. |
My idea is to copy SctpHeader and build a pseudo packet which has the header and a single payload for each payload chunk.
Pcap4J returns the following 3 packet objects:
This way fits Pcap4J API such as Packet.get() well. |
Sounds good and makes sense. The only weird thing I could see is the header checksum value present in the pseduo packets won't reflect the value of the payload of the pseduo packet. Maybe it'd be better to populate the checksum in the pseudo packets header with null, and only have it populated in the first packet. |
The checksum is calculated form the SCTP header and the chunks only (the payload is not included), so it's still valid in a pseudo packet. |
This commits adds support for processing the headers for SCTP packets.
This does not include support for any interpretation of the packet
payload of SCTP data chunks. This also does no validation of the
checksum value in the header.