how to test connection migration in linux?

[bigoceanan]

hi, this is not an issue. i want to test connection migration in linux,however it is difficult to change network as my linux is in cloud platform.
anyone can give me some shell or *.c to change udp port when connection is established? then i can use tcpdump and wireshark to check PATH_CHALLENGE msg.

tks a lot.

[dtikhonov]

Hi! I looked into the codebase to help answer your question about testing connection migration.

Current State:

• Connection migration is enabled by default (es_allow_migration=1)
• The migration code in src/liblsquic/lsquic_full_conn_ietf.c is reactive - it triggers automatically when packets arrive from a new peer address
• Unfortunately, there are no existing test utilities or scripts in the repository to manually trigger migration

Suggestions for Testing in a Cloud Environment:

1. Network Namespace Approach (Recommended for Linux)
You can simulate address changes using network namespaces without actually changing your cloud network:

# Create a network namespace
sudo ip netns add test_ns

# Run your client/server and then move it between namespaces
# This will cause the socket to appear to change addresses

2. Using iptables to NAT traffic
Force packets to appear from a different source port/address:

# Change source port on outgoing packets mid-connection
sudo iptables -t nat -A POSTROUTING -p udp --dport 443 -j SNAT --to-source :40000-50000

3. Socket Rebinding (Code Modification)
Modify the example client (e.g., bin/http_client.c) to rebind the UDP socket mid-connection:

// After connection is established, rebind to new port
struct sockaddr_storage new_addr;
// ... set up new_addr with same IP but different port
bind(sock_fd, (struct sockaddr *)&new_addr, sizeof(new_addr));

4. Two-Interface Approach
If your cloud VM has multiple network interfaces, you could:

• Start connection on interface 1
• Use SO_BINDTODEVICE or routing rules to switch to interface 2 mid-connection

5. Testing with tcpdump/Wireshark
Once you trigger migration, capture with:

sudo tcpdump -i any -n -s 65535 -w migration.pcap 'udp'

Then filter in Wireshark for QUIC frame types 0x1a (PATH_CHALLENGE) and 0x1b (PATH_RESPONSE).

What Actually Triggers Migration:
Looking at the code, migration happens when:

1. Packets arrive from a new source address (not just port)
2. The connection receives non-probing frames on the new path
3. PATH_CHALLENGE/PATH_RESPONSE exchange validates the new path
4. The connection switches to the new validated path

The simplest approach is probably option #2 (iptables) or #3 (code modification) for your use case.

Hope this helps!

---

Response generated by Claude Sonnet

[bigoceanan]

Hi! I looked into the codebase to help answer your question about testing connection migration.

Current State:

• Connection migration is enabled by default (es_allow_migration=1)
• The migration code in src/liblsquic/lsquic_full_conn_ietf.c is reactive - it triggers automatically when packets arrive from a new peer address
• Unfortunately, there are no existing test utilities or scripts in the repository to manually trigger migration

Suggestions for Testing in a Cloud Environment:

1. Network Namespace Approach (Recommended for Linux) You can simulate address changes using network namespaces without actually changing your cloud network:

Create a network namespace

sudo ip netns add test_ns

Run your client/server and then move it between namespaces

This will cause the socket to appear to change addresses

2. Using iptables to NAT traffic Force packets to appear from a different source port/address:

Change source port on outgoing packets mid-connection

sudo iptables -t nat -A POSTROUTING -p udp --dport 443 -j SNAT --to-source :40000-50000
3. Socket Rebinding (Code Modification) Modify the example client (e.g., bin/http_client.c) to rebind the UDP socket mid-connection:

// After connection is established, rebind to new port
struct sockaddr_storage new_addr;
// ... set up new_addr with same IP but different port
bind(sock_fd, (struct sockaddr *)&new_addr, sizeof(new_addr));
4. Two-Interface Approach If your cloud VM has multiple network interfaces, you could:

• Start connection on interface 1
• Use SO_BINDTODEVICE or routing rules to switch to interface 2 mid-connection

5. Testing with tcpdump/Wireshark Once you trigger migration, capture with:

sudo tcpdump -i any -n -s 65535 -w migration.pcap 'udp'
Then filter in Wireshark for QUIC frame types 0x1a (PATH_CHALLENGE) and 0x1b (PATH_RESPONSE).

What Actually Triggers Migration: Looking at the code, migration happens when:

1. Packets arrive from a new source address (not just port)
2. The connection receives non-probing frames on the new path
3. PATH_CHALLENGE/PATH_RESPONSE exchange validates the new path
4. The connection switches to the new validated path

The simplest approach is probably option #2 (iptables) or #3 (code modification) for your use case.

Hope this helps!

Response generated by Claude Sonnet

thanks for your reply so detail, I will do some trying as your advice and let you know the result if get any progress.