If no hw noise generator is available, I do recommend a normal pseudorandom generator as already discussed here for low-end requirements.

If there is any the slightest needs for security etc, then a better solusion would be needed. Something at least making use of true true asynchronous events - possibly by additional hardware just for this use, in case the product doesn't have natural ways to receive the required amount of randomnes.

But the ping time of a packet, or the receive time of a character in relation to a free-running timer, only gives very few bits of random data. The received character may result in a read out of a 16-bit or 32-bit counter, but the size of the counter can't help the fact that the time of the character arrival can be measured. And the random jitter for an ISR is not so high. And a block of data sent continuously from a FIFO-enabled transmitter will not introduce any real jitter between characters.

One little cheaty thing to remove cycles in random data can be to xor the random data with bytes from the code flash. If the code block contains a lot of 0x00 or 0xff, then it will send through the data unchanged or inverted which isn't reducing the quality of the emitted sequence. Blocks of code that contains random machine instructions will invert random bits from the pseudo-random sequence. If there is free flash space, then a real table of one or more kB of random data can be stored for use to invert the data from the pseudo-random sequence. But it is important that the code region used is not sized as 2^n. Selecting a prime number as the size of flash data to xor with the pseudo-random sequence makes the repetition cycle way longer.

Edit: Just two footnotes.

1) If it is important that people can't look at the random number sequence to try to extract machine instructions from the flash, then any xor operation should make use of a dedicated table of random data instead of using a memory region with instructions.

2) Another thing to consider if using a processor that isn't too RAM-limited is to have a reasonably large mixing buffer in RAM. Each asynchronous event is then used to get a couple of bits of random data that is exored with this table in a round-robin fashion, constantly changing the contents.

When random data is needed, then the pseudo-random generator is used, and the result is xored with the random table in a round-robin fashion.

If the table is 1kB large, and there are enough asynchronous events to keep it refreshed faster than what is consumed, then it will be very hard to try to duplicate the full state machine.