Re: [Dnsmasq-discuss] ra-only segfault
On 11/03/13 15:33, Gene Czarcinski wrote: Just happened so I am still collecting information but ... having a conf file with nothing much specified but: ... interface=eth2 dhcp-range=fd00:ff:11::2,ra-only ... results in a segfault I got this on real hardware with libvirt but have been able to duplicate it virtually. Attached are the syslog messages from the guests syslog. dnsmasq 2.65-4 on Fedora 18. Gene I just fed exactly those options into 2.65 as released by me, and it didn't crash, so we're going to have to pin this down a bit more. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] ra-only segfault
On 03/11/2013 12:22 PM, Simon Kelley wrote: On 11/03/13 15:33, Gene Czarcinski wrote: Just happened so I am still collecting information but ... having a conf file with nothing much specified but: ... interface=eth2 dhcp-range=fd00:ff:11::2,ra-only ... results in a segfault I got this on real hardware with libvirt but have been able to duplicate it virtually. Attached are the syslog messages from the guests syslog. dnsmasq 2.65-4 on Fedora 18. Gene I just fed exactly those options into 2.65 as released by me, and it didn't crash, so we're going to have to pin this down a bit more. It would be too easy to be that repeatable. I will set something up to be simple and yet demonstrate the failure. Gene ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] ra-only segfault
On 03/11/2013 12:44 PM, Gene Czarcinski wrote: On 03/11/2013 12:22 PM, Simon Kelley wrote: On 11/03/13 15:33, Gene Czarcinski wrote: Just happened so I am still collecting information but ... having a conf file with nothing much specified but: ... interface=eth2 dhcp-range=fd00:ff:11::2,ra-only ... results in a segfault I got this on real hardware with libvirt but have been able to duplicate it virtually. Attached are the syslog messages from the guests syslog. dnsmasq 2.65-4 on Fedora 18. Gene I just fed exactly those options into 2.65 as released by me, and it didn't crash, so we're going to have to pin this down a bit more. It would be too easy to be that repeatable. I will set something up to be simple and yet demonstrate the failure. More data. I took the dnsmasq.conf file that I used with libvirt and simplified it even further. Attached the simplified file and the output from ip addr. I tried other options: static, ra-stateless, and slaac worked OK (at least did not segfault). Both ra-only and ra-names segfaulted. The system is Fedora 18 which is more or less current. I also tried Fedora 17 but it only had 2.64 and 2.65 (or 2.59 which did not work at all). OK, ran it from the command line to get (a lot) more info. This is now in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=920300 I have not really look at the info yet, just doing the collection. Gene # Mon 11 Mar 2013 12:57:16 EDT #strict-order #domain-needed #local=// #except-interface=lo #bind-dynamic interface=eth2 dhcp-range=fd00:ff:11:1::2,ra-only,64 #log-queries #log-dhcp 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:51:a9:bc brd ff:ff:ff:ff:ff:ff inet 192.168.7.166/24 brd 192.168.7.255 scope global eth0 inet6 fd00:beef:10:7::1:37/128 scope global valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe51:a9bc/64 scope link valid_lft forever preferred_lft forever 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:05:ad:c2 brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:fe05:adc2/64 scope link valid_lft forever preferred_lft forever 4: eth2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:31:55:fb brd ff:ff:ff:ff:ff:ff inet 192.168.223.1/24 brd 192.168.223.255 scope global eth2 inet6 fd00:ff:11:1::2/64 scope global valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe31:55fb/64 scope link valid_lft forever preferred_lft forever ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] ra-only segfault
On 11/03/13 18:29, Gene Czarcinski wrote: On 03/11/2013 12:44 PM, Gene Czarcinski wrote: On 03/11/2013 12:22 PM, Simon Kelley wrote: On 11/03/13 15:33, Gene Czarcinski wrote: Just happened so I am still collecting information but ... having a conf file with nothing much specified but: ... interface=eth2 dhcp-range=fd00:ff:11::2,ra-only ... results in a segfault I got this on real hardware with libvirt but have been able to duplicate it virtually. Attached are the syslog messages from the guests syslog. dnsmasq 2.65-4 on Fedora 18. Gene I just fed exactly those options into 2.65 as released by me, and it didn't crash, so we're going to have to pin this down a bit more. It would be too easy to be that repeatable. I will set something up to be simple and yet demonstrate the failure. More data. I took the dnsmasq.conf file that I used with libvirt and simplified it even further. Attached the simplified file and the output from ip addr. I tried other options: static, ra-stateless, and slaac worked OK (at least did not segfault). Both ra-only and ra-names segfaulted. The system is Fedora 18 which is more or less current. I also tried Fedora 17 but it only had 2.64 and 2.65 (or 2.59 which did not work at all). OK, ran it from the command line to get (a lot) more info. This is now in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=920300 I have not really look at the info yet, just doing the collection. Gene Ok, this bug is long gone in the 2.66 releases, as the code has been completely re-written. The problem is that line 643 of src/dnsmasq.c uses daemon-dhcp_buff2 which is not allocated unless some DHCP service is configured. A minimal patch for RH would be something like daemon-dhcp_buff2=malloc(256); just before that line, workaround is to configure DHCP service as well as RA. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
