No wireless connection after new router is installed


I installed a new router and changed a lot of the default settings to improve the wireless speed and bandwidth. In the router I can see that there is a connection with the MAC-address of the dongle. However Kodi/OSMC shows no wireless connection.
It all works fine with the old router. It all works fine with the new router with the default settings. Even with the wireless dongle is in a windows machine it works.
So my idea is that one or more of the changes I made in the new router prevents Kodi/OSMC from “seeing” the connection that is actually there.
I want to solve this issue on the Kodi/OSMC side. What are the relevant files to look at?

Thanks in advance and regards,


So what were the changes you made ?

So when you go into MyOSMC->Network->Wireless do you see the network being broadcast at all ?


Thanks for the interest.
The router change is from a linksys WRT54GL version 1.1 to a linksys WRT320N. Both running the DD-WRT firmware.
Changes made to the default setup on both the routers:
Setup bridges to other routers according to the DD-WRT documentation.
Setup static IP addresses also according to the DD-WRT documentation.
Changes made to the new router:
Bandwidth changed from 20MHz to 40MHz.
MIMO buffers changed from auto to 2.
Using the n type instead of the g type.
Channel changed to multiple channels 6, upper.
Got it working on OSMC. Checked the speed with wavemon and that was OK. However my windows laptop did not switch to the higher speed so I start playing with the router settings guided by the DD-WRT wiki.When I got the laptop working at a higher speed I wasn’t able to connect from OSMC. The problem here is that I didn’t keep track of all the changes I made. Only excuse I have is that it was a trial and error approach.
When I go to myOSMC I see the wireless stations. When I select my router it askes for the key. After entering the key it shows no wireless connection.
Using connmanctl on a SSH connection more or less the same thing happens.
For clarity: It’s not a lot of work to start from the default router setup and get it working again. (I hope.) It might be more work to get my windows machine connect at a high speed. So my problem is not fixing it but it is to use the advanced settings of the wireless connection. And using it in a way that it’s not changed after an update!
The higher goal of this is to wirelessly stream the audio with pulseaudio (pa) from Kodi/OSMC.

This doesn’t require high amounts of bandwidth, but it does require low latency.

My guess is that the bandwidth is the sample rate * number of channels * bits per channel. Also there is some overhead and error recovery to take into account.
To get an idea:48k * 2 * 16 = 1.5 Mbps should get over a 54Mbps (54g) easily
But my Pi got stuck the first time I tried. Google revealed that the bandwidth might be an issue. Other issue being a lack of processing power and a not so simple resampling algorithm. For testing it is OK to use a wired connection and then bandwidth is not an issue.
Latency is indeed a problem but a buffer could be used to compensate for the different latencies of the receivers. This however creates a new problem. The clocks needs to be equal. Or in different words all receivers should start reading from the buffers at the “same” time (latency) and the reading speed should be equal (buffer over- or underflow). The reading speed depends on the oscillator. The oscillators are not equal so some sort of synchronisation is needed.Another approach is to control the reading speed of the buffer. Example: We start reading when the buffer is half full. We increase the reading speed when the buffer is more then half full and we decrease the reading speed when the buffer is less then half full. Obviously a more advanced control algorithm is needed but this is the idea. In this case the “synchronisation” comes from the senders sample rate. Compensation for the different latencies of the receivers is done by giving them a “custom” starting point in the buffer. A receiver with a low latency starts when the buffer is 60% full and a receiver with a high latency starts when the buffer is 40% full. A steady flow into the buffer would make the control algorithm easier and more robust. Now we are back to our bandwidth. A higher bandwidth means that there is less jitter in the filling of the buffer. Other users of the bandwidth have less influence! It is all theory and it might not even be correct but I have fun playing with it.


The MIMO - Transmission Fixed Rate setting is causing the problem. Set it back to auto. Speed now is 150 Mbps (Rx and Tx) for all devices. No idea how to get to 300 Mbps.
Thanks for the support.



PulseAudio with RTP seems to have a bug that eats up bandwidth.
I was curious so I had a look at the source code.
The mtu = maximum transfer unit is set to a default of 1280.
#define DEFAULT_MTU 1280
The rtp send function is called whenever there is pushed new data in the buffer.
pa_rtp_send(&u->rtp_context, u->mtu, u->memblockq);
u->mtu is set to 1280
The first code of this function is: (My comments)
int pa_rtp_send(pa_rtp_context *c, size_t size, pa_memblockq q) {
// size is 1280
struct iovec iov[MAX_IOVECS];
int iov_idx = 1;
size_t n = 0;

pa_assert(size > 0);

// If the buffer size is less then the mtu return
// Assumption: The pa_memblockq_get_length function does what I expect.
if (pa_memblockq_get_length(q) < size)
return 0;

Sampling at 48k, 2 channels, 16 bit/channel gives about 160kBits/s.
Each frame has 1280 Bytes = 10kBits so I expect a framerate of 16 frames/s. Clearly this is much higher and the only explaination I have is that there is far more data pushed in the buffer then sampling can account for. To be continued.