❦ 27 septembre 2016 10:04 CEST, Vincent Bernat <ber...@debian.org> :
>>> Dear Maintainer, dnsmasq while govenred by NetworkManager fails to forward
>>> queries to upstream DNS server when recieved server list via DBus for
>>> second time.
>>
>> I have the same problem. Therefore, when switching from one network to
>> another, I have to kill dnsmasq to make it work again. I'll try to debug
>> a bit more next time (but usually, this happens at the most inconvenient
>> moment).
>
> Here is a strace during the problem:
>
> recvmsg(4, {msg_name(16)={sa_family=AF_INET, sin_port=htons(50141),
> sin_addr=inet_addr("127.0.0.1")},
> msg_iov(1)=[{"z\320\1\0\0\1\0\0\0\0\0\0\4push\10services\7mozil"...,
> 4096}], msg_controllen=0, msg_flags=0}, 0) = 43
> sendto(11, "3\202\1\0\0\1\0\0\0\0\0\0\4push\10services\7mozil"..., 43,
> 0, {sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("8.8.8.8")}, 16) = -1 ENODEV (No such device)
> sendto(11, "3\202\1\0\0\1\0\0\0\0\0\0\4push\10services\7mozil"..., 43,
> 0, {sa_family=AF_INET, sin_port=htons(53),
> sin_addr=inet_addr("8.8.4.4")}, 16) = -1 ENODEV (No such device)
>
> FD 11 is:
>
> dnsmasq 21412 nobody 11u IPv4 1438842 0t0 UDP
> *:38279
>
> So, it doesn't really seem to be related to the original bug
> report. Sorry for the noise, I'll dig more and open another bug report
> if needed.
Well, in fact, it seems that's the same problem. The problem is that
dnsmasq as configured by Network Manager uses
--bind-interfaces. Therefore, the above socket is in fact bound to an
interface. This can be checked with "ss --info --extended". So, when the
interface disappear, we are not able to send receive using the socket
anymore. Configuration through DBus doesn't update the interface the
socket is bound to.
--
Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)
signature.asc
Description: PGP signature
