Bugs related to DNS, DHCP, Bridging and the GUI
-
I can confirm that the "Services: DHCP server" tabs now work correctly (third bug).
Thank you very much for the fix :D :D
(I did not check first bug).Bugs 2, 4, and 6 have workarounds.
However, I have been looking a little more into the TinyDNS issues (5) and created two bug reports:
http://redmine.pfsense.org/issues/show/439
http://redmine.pfsense.org/issues/show/440
I have no workaround for those (although solution proposals are included in the bug reports) -
http://redmine.pfsense.org/issues/show/440 has been updated with a patch.
Any help in testing and checking in this patch would be most appreciated.See also http://redmine.pfsense.org/issues/show/442 which contains a patch for re-installation of TinyDNS
-
Should I create redmine bug reports for bug 2, 4 and 6 ?
-
resolv.conf file generation should be ok on latest snaps.
-
I have been watching the git repo, but did not see the fix ???
Could you point me to where this was fixed? -
Now the GUI cannot be contacted (neither on .222 nor on .254)
Did you gave time for it to be available?!
Usually it will take around 40-50 seconds for the gui to restart.@kaparasoft
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/1033de7481dacd83ee5a1a16078e89c7b4e9efd8 -
I need to do a complete reinstall, so I will try again, making sure I wait at least one minute for the GUI to come up.
I am not so sure the 033de7481dacd83ee5a1a16078e89c7b4e9efd8 commit fixes the problem.
TinyDNS is reading and writing /etc/resolv.conf, not /var/etc/nameservers_*
But I will try it out! -
Unfortunately, I can confirm that the fix did not work.
I did a clean install of 20100324-0246.
Even without TinyDNS, resolving is borked, as /etc/resolv.conf does not contain any nameservers!
(I will continue to see if I can pinpoint the problem…) -
can you please show me the output of ls /var/etc/nameserver_*
Do they have any ip on them? -
Found the problem!
It is in system.inc function get_nameservers. You have:
$master_list[] = $item;but it should be:
$master_list[] = $dns; -
Regarding bug #2:
@ermal:
Now the GUI cannot be contacted (neither on .222 nor on .254)
Did you gave time for it to be available?!
Usually it will take around 40-50 seconds for the gui to restart.I can confirm (20100324-0246 snapshot) that after 10 minutes, neither GUI nor SSH can be contacted on .222 or .254.
After reboot GUI and SSH are available on .254 -
An ifconfig and netstat -rn would be useful
-
netstat -f inet -l
shows nothing listening on any ports.I will try the "netstat -rn" next time I am rebuilding the box.
-
kaarposoft: netstat -rn is for showing the routing table, not the status of ports.
-
I know, but I can only do it when I reinstall the box!
-
I tried again: Installing 20100324-0246, upgrading to 20100324-2048 from console.
Following the steps of the original post.After activating the bridge and setting LAN to "none", I get:
netstat -rn Destination Gateway Flags Refs Use Netif Expire default 87.52.xx.1 UGS 0 15 vr0 87.52.xx.0/24 link#1 U 0 708 vr0 87.52.xx.120 link#1 UHS 0 0 lo0 127.0.0.1 link#12 UH 0 1127 lo0 127.0.0.2 127.0.0.1 UHS 0 0 lo0 192.168.yy.254 link#13 UHS 0 0 lo0(plus a lot of IPv6; xx and yy are my sanitizing).
Link#1 is the LAN, #12 is lo0 and #13 is the bridge.After reboot I get:
Destination Gateway Flags Refs Use Netif Expire default 87.52.xx.1 UGS 0 47 vr0 87.52.xx.0/24 link#1 U 0 137 vr0 87.52.xx.120 link#1 UHS 0 0 lo0 127.0.0.1 link#12 UH 0 19 lo0 127.0.0.2 127.0.0.1 UHS 0 0 lo0 192.168.yy.0/24 link#13 U 0 1 bridge 192.168.yy.254 link#13 UHS 0 0 lo0But this time, I get no working GUI even after reboot :o