ForumsHardware ← Soundplane client filling logs with icmp unreachable messages


I know your not looking at the soundplane software at the moment, but for your 'issue' list, when you get to it after Verta

I notice my console logs filling up with hundreds of :

4/2/16 00:12:36,000 kernel[0]: Limiting icmp unreach response from 6710 to 250 packets per second
4/2/16 00:12:40,000 kernel[0]: Limiting icmp unreach response from 22822 to 250 packets per second

a quick tcproute trace led me back to the source being the soundplane client software.
as i could see it constantly trying to reach ports 3123 to 3138


00:14:10.331996 IP > ICMP udp port 3123 unreachable, length 36
00:14:10.332014 IP > ICMP udp port 3124 unreachable, length 36
00:14:10.332022 IP > ICMP udp port 3125 unreachable, length 36
00:14:10.332025 IP > ICMP udp port 3126 unreachable, length 36
00:14:10.332028 IP > ICMP udp port 3127 unreachable, length 36
00:14:10.332034 IP > ICMP udp port 3128 unreachable, length 36
00:14:10.332038 IP > ICMP udp port 3129 unreachable, length 36

I had a look at the code, and in sendFrame(), sure enough I can see it attempting to transmit to every port offset for every frame.

from a quick test it appears this can be rectified by adding to the loop

if(!mSocketInitialized[portOffset]) continue;

Im not sure if this is the full picture however, as it may not cover the split case,
I also assume there is some 'logic' behind this, to do with the fact that the frame message needs to go to every client regardless of if theres a touch or not.
Id need to do further testing to check this, though of course I'm limited on how I can fix the protocol as I cannot alter the client software (aalto/kaivo)

btw: I suspect mFrame++ is not correct, should it not be contiguous for each client, i.e. you want it outside the port offset loop.

as I said, I know your busy with Virta, but I hope once thats done you will have some time to resolve some of the issues in the soundplane software, so hope the above will assist you,


Thanks. Obviously this shouldn't be happening. Possibly it's a an endless loop involving both client and server—does it happen with only the Soundplane app running? If not, you could try adding components again until the flood occurs, and that would be a helpful test. In any case I'll make a note of this issue and check into it soon.

happens with just the soundplane client running.

the above fix, I think is fine, I just need to check some of the surrounding logic to check that the initialised flag is set in the appropriate cases.

hope virta development is progressing nicely :)

OK, weird, will investigate ASAP.

yes, Virta is taking its final form and will be done soon.