Bug in binding

[dtaht]

I setup a test where I had 240 virtual IP addresses setup with different shapers, and ran a test to each one. I think,
that the udp server in this case is not responding on the same IP address it was connected to, instead
on the last address it was given via the OS.

In the above image, the test should have been connecting to fd77::2:1, not 240.

udpst server is on this machine with 240 addresses, the udpst client, 3...

PLANS="c25-3 c25-5 c60-20 b10-10 c100-100 c100-40 c25-10 b50-50 b100-20 b200-200 b250-250 b500-100 c500-50"

for i in $PLANS
do
        udpst -6 -d -A C $i > $i-d.txt
done

Another item, given the structure of the test, might be that the cake "blue" algorithm kicks in.

UDP Speed Test
Software Ver: 7.5.1, Protocol Ver: 9, Built: Dec 20 2022 02:50:56
Mode: Client, Payload Default[Max]: 1202[8952], Authentication: Unavailable, Sen
dMMsg(): Available
Upstream Test Int(sec): 10, DelayVar Thresh(ms): 30-90 [RTT], Trial Int(ms): 50,
 Ignore OoO/Dup: Enabled, Payload: zeroes,
    SendRate Index: <Auto>, Cong. Thresh: 3, High-Speed Delta: 10, SeqError Thre
sh: 10, Algo: C, IPv6 TClass: 0
Sub-Interval[1](sec):   1, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms)
: 0/0/1, RTTVar(ms): 0-0, Mbps(L3/IP): 126.41
Sub-Interval[2](sec):   2, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms)
: 0/0/1, RTTVar(ms): 0-1, Mbps(L3/IP): 115.28
REMOTE WARNING: Incoming traffic has completely stopped
Sub-Interval[3](sec):   3, Delivered(%):   0.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms)
: 0/0/0, RTTVar(ms): 0-0, Mbps(L3/IP): 0.00
Sub-Interval[4](sec):   4, Delivered(%):   0.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms)
: 0/0/0, RTTVar(ms): 0-0, Mbps(L3/IP): 0.00
LOCAL WARNING: Incoming traffic has completely stopped

[lc9892]

It may be worth clarifying the current behavior a little in case I am misunderstanding the issue description. Pertinent details can also be found in the README at:
https://github.com/BroadbandForum/obudpst/blob/main/README.md#overview
https://github.com/BroadbandForum/obudpst/blob/main/README.md#test-processing-walkthrough-all-messaging-and-pdus-use-udp

The server utilizes a single control port (default 25000) to receive test setup requests from all clients. When one is received, it then requests a new socket from the OS in the ephemeral port range and communicates this port number back to the client via the setup response. The client then sends the test activation request (the second part of the setup process) to this new port number. After the server sends the test activation response, from this new socket back to the client, this socket is then used for the actual testing. Note, the process is structured this way to allow the client to test from behind a firewall/NAT device (i.e., the typical home broadband user).

Does this behavior sync with what you are observing?

[dtaht]

but does it lock to the received IP address for the test? Port, yes, IP addr? I can do a packet capture later today.

[dtaht]

Yep. It choses the wrong IP to send from. It should instead send from the IP it was connected to. I think this is a single setsockopt.....

1 0.000000 fd77::3 → fd77::1:5 0x000e 110
2 0.001441 fd77::1:240 → fd77::3 0x000e 110
3 0.001481 fd77::3 → fd77::1:240 0x000e 118
4 0.001985 fd77::1:240 → fd77::3 0x000e 118
5 0.002932 fd77::1:240 → fd77::3 0x000e 90

1525 0.718983 fd77::1:240 → fd77::3 0x000e 1264
1526 0.718984 fd77::1:240 → fd77::3 0x000e 1264
1527 0.718985 fd77::1:240 → fd77::3 0x000e 1264
1528 0.718985 fd77::1:240 → fd77::3 0x000e 1264
1529 0.718986 fd77::1:240 → fd77::3 0x000e 1264
1530 0.718986 fd77::1:240 → fd77::3 0x000e 1264
1531 0.719093 fd77::1:240 → fd77::3 0x000e 514
1532 0.719997 fd77::1:240 → fd77::3 0x000e 1264
1533 0.719998 fd77::1:240 → fd77::3 0x000e 1264
1534 0.719999 fd77::1:240 → fd77::3 0x000e 1264

[lc9892]

Thanks for the additional info, I think I see what's happening. Can you try a quick test (that may also serve as a workaround depending on how it works in your test environment)? Can you run the server with an explicit IP address on the command line (instead of it using the "any" designation internally).

[acmacm]

Len, Thanks for investigating this issue. Dave, please give the IPaddrs in your setup. I have a host with two interfaces: one on wired LAN (192.168.0.70) and another on WiFi LAN (192.168.4.75) When I start a server $ ./udpst 192.168.0.70 # server on wired LAN And then start a client from the WLAN (with verbose Debug enabled) I see: ./udpst -vD -t 5 -d 192.168.0.70 UDP Speed Test Software Ver: 7.5.1, Protocol Ver: 9, Built: Dec 20 2022 13:53:15 Mode: Client, Payload Default[Max]: 1222[8972], Authentication: Available, SendMMsg(): Available [1]Socket created with SO_SNDBUF/SO_RCVBUF of 425984/425984 [1]Setup request sent from 0.0.0.0:43642 to 192.168.0.70:25000 [1]Setup response received from 192.168.0.70:25000 [1]Test activation request sent from 192.168.0.70:43642 to 192.168.0.70:52108 [1]Test activation response received from 192.168.0.70:52108 [1]Downstream Test Int(sec): 5, DelayVar Thresh(ms): 30-90 [RTT], Trial Int(ms): 50, Ignore OoO/Dup: Enabled, Payload: zeroes, SendRate Index: <Auto>, Cong. Thresh: 3, High-Speed Delta: 10, SeqError Thresh: 10, Algo: B, IPv4 ToS: 0 [1]DEBUG Status Feedback [Loss/OoO/Dup: 0/0/0, OWDVar(ms): 0/0/1, RTTVar(ms): -1] Mbps(L3/IP): 0.10 ... All the control exchanges (Setup and Activation) use the wired LAN addresses. I expected to see the requests go out with WiFi addresses, but not... Al From: Len Ciavattone ***@***.***> Sent: Tuesday, December 20, 2022 3:09 PM To: BroadbandForum/obudpst ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [BroadbandForum/obudpst] Bug in binding (Issue #9) Thanks for the additional info, I think I see what's happening. Can you try a quick test (that may also serve as a workaround depending on how it works in your test environment)? Can you run the server with an explicit IP address on the command line (instead of it using the "any" designation internally). — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/BroadbandForum/obudpst/issues/9*issuecomment-1360097049__;Iw!!BhdT!nrY1p7wIFFX9XpHmWexnnmXtZ8S-OKvdNma8vPUWmnlFEWPd_adFG0t6MDAyX6qrz0x-8BDU0JVAJHrvNUe0gw$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ACILYGGAYDZ7BERZ7HXVUH3WOIG6DANCNFSM6AAAAAATEBIUUY__;!!BhdT!nrY1p7wIFFX9XpHmWexnnmXtZ8S-OKvdNma8vPUWmnlFEWPd_adFG0t6MDAyX6qrz0x-8BDU0JVAJHrlj59aHw$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[dtaht]

I keep hoping there is a simpler way than the universal ipv6 method laid out here:

https://stackoverflow.com/questions/3062205/setting-the-source-ip-for-a-udp-socket

[lc9892]

That is where I ended up while thinking through options. Needless to say, it's not a first choice.

Did you try specifying a local bind address when you run the server? Would that happen to help with the specific testing you are trying to do?

[dtaht]

in most cases ipv6 has two addresses minimum. So actually fixing this bug is prefereable.