On 21/02/14 09:07, Nikita N. wrote: > >> All the clients are quite common, and in use all around the world, if >> there was a general problem with this, we'd probably have heard about it >> by now. > Hi, well you are hearing it now :)
True, but it's not clear what to do about it. The modification to dnsmasq which you suggested is a hack, and may well have unexpected effects which break more installations than it fixes. > >> It seems likely that the problem is something in your network, rather >> than the DHCP clients or servers. > While I was waiting for a feedback, I tried to workaround the issue > myself. > I tried to have a look to your code, and understood that maybe also > there its needed just a flag bit to switch in the kernel.. but didnt > modify nothing, didnt feel enough skilled to modify your code.. ;) > Instead I modified the code at transportation layer, the software which > actually sends the frames up in the air. > Very simply, I instructed it to duplicate all frames with > dest=broadcast, setting dest=sta mac. > It works perfectly with *ALL* my test clients so far, also the ones > affected by the dhcp-broadcast issue. > Of course as you can understand by yourself, its a dirty workaround, as > it works only in very simple cases, e.g. it does *NOT* work in the case > of multiple concurrent connections. > So it doesnt seem to me a problem in my network, but rather a glitching > bug in some wireless drivers.. > I'm not clear which simply setting --dhcp-broadcast doesn't do fix this. Cheers, Simon. > Thanks anyway, and keep on the good job! :) > We're doing our best. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
