Hi Lars, Le Sun, 15 Jan 2017 10:21:01 +0200 Lars Noodén <lars.noo...@gmail.com> a écrit:
> On 01/15/2017 09:55 AM, Albert ARIBAUD wrote: > > Hi Lars, > > > > Le Sat, 14 Jan 2017 20:18:13 +0200 > > Lars Noodén <lars.noo...@gmail.com> a écrit: > >... > >> Because it's not my system and it is remote, I > >> have to go step by step, slowly. > > > > ... Do you mean that you have good control of the remote system but > > have to go there physically to run tests, or that you do not have > > control of the system and must ask someone else to perform tests > > there? This makes a difference in the way you can run your tests > > I have to describe the steps in e-mail and they are then carried out > on site by a non-technical person. Argh. > >> Since everything on that system, in > >> regards to DNS, is going via Dnsmasq, I'd like to see what it has > >> loaded and is using. > > > > This bring me back to your description of the bug above: "somewhere > > early on the DNS fails". What do you mean with that? Did you check > > that the client keeps sinding DNS requests to your dnsmasq? > > The client application (Blink) will apparently default to Google's DNS > if it cannot connect to the server right away. What's happening is > that half the time DNS replies, half the time it times out. Thus the > client can start to register with the SIP server, but then fails to > publish its presence or be able to initiate a call. > > > ... Or is > > it that they come back from your dnsmasq with an error code for > > domains which you know your dns should resolve properly? > > It seems to be this -- sometimes. > > So is the short answer that there's no direct or easy way to poll a > running Dnsmasq instance and see what it's pointing to? If so, then > I'll not bother the list more with this issue. However, may I put in > a feature request if there is a wish list? See my other replies, but I'll make the main suggestion: the way to get the info you want (and more, which might be useful for your diagnostics) is to run tcpdump on the dnsmasq host on the "any' interface (or run two tcpdumps, one on the interface used to talk to the client, one on the interface used to talk to the Internet) with a capture filter set for DHCP and DNS protocols, and write the capture into a file (or two, if running two tcpdump instances). Then if you have two captures you can use Wireshark's mergecap tool to merge them into a single one. Last, you open the single capture file in Wireshark and see: - whether your client was sent out a DHCP reply configuring DNS servers - which DNS requests your client sent to dnsmasq - which DNS requests your dnsmasq sent to which upstream server - which DNS replies your dnsmasq received from which upstream server - which DNS replies your client received from dnsmasq That's the info you're asking for (of course, I assume you have control of the host running dnsmasq) and much more. The method can be useful for diagnosing other network or protocol issues as well. Speaking of which, my first hunch re your problem is that it's not a dnsmasq problem, but a problem with the client's networking configuration. I suspect it connects through some VPN and gets an additional (or replacement) DNS, and that at some point the VPN connection goes bad and the client reverts (in part or in full) to its original DNS. In any case, the test above will give you a hint about that too: if you see that the client stops sending requests at some point, you can pretty much conclude it stopped using your dnsmasq as its DNS (you can even know when it last did, and compare that with logs from the client if you can get the non-tech person to do it. BTW: I suspect there is no way to get the non-tech person to install a remote access client (even ssh would be enough) and also no way for you to get root privileges on it? > Regards, > /Lars Amicalement, -- Albert. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
