Skip to content

Correctly Configuring MSS in SYN-ACK Handshake #64

@Orvaxis

Description

@Orvaxis

The MSS is not returned when the current handshake is returned, causing the downstream upload to use a default value as the upload speed, resulting in a significantly lower upload speed than the download test.

Reproduce using iperf3 -c 10.3.0.1
And you can see through wireshark that iperf3 has been sending data packets with a content length of 512 to tun.

pub(crate) fn create_raw_packet(
    src_addr: SocketAddr,
    dst_addr: SocketAddr,
    calculate_payload_max_len: impl Fn(usize, usize) -> usize,
    flags: u8,
    ttl: u8,
    seq: u32,
    ack: u32,
    win: u16,
    mut payload: Vec<u8>,
) -> std::io::Result<NetworkPacket> {
    let mut tcp_header = etherparse::TcpHeader::new(src_addr.port(), dst_addr.port(), seq, win);
    tcp_header.acknowledgment_number = ack;
    tcp_header.syn = flags & SYN != 0;
    tcp_header.ack = flags & ACK != 0;
    tcp_header.rst = flags & RST != 0;
    tcp_header.fin = flags & FIN != 0;
    tcp_header.psh = flags & PSH != 0;
    tcp_header
        .set_options(&[TcpOptionElement::MaximumSegmentSize(3960)])
        .map_err(|e| std::io::Error::new(InvalidInput, e))?;
...

A simple hard-coded result will be an improvement from 400Mbps to 2.xGbps

[  5]   0.00-10.00  sec  3.63 GBytes  3.12 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  2.41 GBytes  2.07 Gbits/sec                  receiver

ps. It may be that the lack of flow control causes the sending speed to be higher than the receiving speed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions