<p>I'm really certain this has nothing to do with interfering ad-hoc networks. We were able to reproduce the problem both when there were other ad-hoc networks present, and when there weren't any others. I did extensive testing to show that the olsrd route problem occurred if and only if the client had bad links with all its ad-hoc neighbors. As soon as one good ad-hoc link was established, olsrd started receiving olsrd packets and building a routing table. This indicates that the problem was at the link layer, not application layer.</p>

<p>My working hypothesis is that since the problem occurs inconsistently in the presence of other constant factors, it is indicative of a race condition. I believe the network-manager scripts are running asynchronously, and that this is responsible for screwing up the network stack during the connection process, possibly related to wpa_supplicant.</p>

<p>To test this hypothesis, we'd need to do try joining the same ad-hoc network both through network-manager, and without network-manager. If the later doesn't show the same symptoms, then we'll know the source of the problem.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>Reply to this email directly or <a href='https://github.com/opentechinstitute/commotion-linux-py/issues/14#issuecomment-33415769'>view it on GitHub</a>.<img src='https://github.com/notifications/beacon/3074564__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNjM4NjA0MSwiZGF0YSI6eyJpZCI6MjQzNDc4MTl9fQ==--a72722f5cf1110f9b9bc1d3e6652f084e1e485b7.gif' height='1' width='1'></p>