cellular: random socket port number

[ghost]

Description

Random port number (above 49151) into use for TCP and UDP sockets

Pull request type

[ X ] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

[ghost]

@AriParkkila please review

[AriParkkila]

No need to be static.

[kjbracey]

As you're not tracking which ports you've already chosen or are still using, I think it would probably be better to keep a cycling algorithm to maximise time before reuse in one session.

Using some random online birthday paradox calculator, I find the above has a 50% chance of reuse in 150 calls.

If you want to start digging deeper into changing strategies, read https://tools.ietf.org/html/rfc6056, but for now I suggest sticking with the same cycling strategy and just making sure you start at a random point. Nanostack uses algorithm 5 from that paper, but it knows what the current ports in use are:

#define RANDOM_PORT_NUMBER_START 49152
#define RANDOM_PORT_NUMBER_END 65535
#define RANDOM_PORT_NUMBER_COUNT (RANDOM_PORT_NUMBER_END - RANDOM_PORT_NUMBER_START + 1)
#define RANDOM_PORT_NUMBER_MAX_STEP 500
static uint16_t port_counter;
port_counter = randLIB_get_random_in_range(0, RANDOM_PORT_NUMBER_COUNT - 1);


uint16_t count = RANDOM_PORT_NUMBER_COUNT;

do {
    port_counter += randLIB_get_random_in_range(1, RANDOM_PORT_NUMBER_MAX_STEP);
    while (port_counter >= RANDOM_PORT_NUMBER_COUNT) {
        port_counter -= RANDOM_PORT_NUMBER_COUNT;
    }
    uint16_t port = RANDOM_PORT_NUMBER_START + port_counter;
    if (socket_port_validate(port, protocol) == eOK) {
        return port;
    }
} while (--count > 0);

You could use that, but you'd probably want a smaller MAX_STEP unless you can add a validate.

[kjbracey]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 2263
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7097/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

[cmonr]

Halting CI builds until RC3 PRs are completed. Will resume after.

[0xc0170]

/morph test
/morph export-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 1900
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/7097/

[mbed-ci]

Test : SUCCESS

Build number : 2061
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7097/2061

[cmonr]

@TeemuKultala Bringing this into 5.10.0-rc1 since the return value has changed and is therefore an API change.

Is there a specific issue this PR fixing?

[kjbracey]

Problem it solves is difficulty reconnecting to server after reboot, due to reuse of same port number. An issue we've seen before with other stacks, and has recurred with this code.

This is bringing these non-PPP modems into line with the existing behaviour of IP stacks that properly randomise like lwIP and Nanostack - algorithm is based on Nanostack's. So I think it's a 5.9.x fix. PPP modems would be getting proper randomisation already through lwIP.

[0xc0170]

It fixes the values that are returned (generating the random number compare to "i++") - no code should rely on specific number returned. This should be fine for the patch release, labeled as such.