Hi Bob... The funny thing is that the ONLY change on the network before
this panicing started was that I shut down their 9 year old Linux djbdns
server and fired up the new virtual Gentoo Linux djbdns server within
their VMWare ESX 3.5 server.
Nothing else changed. The old dns server ran djbdns. I run djbdns at all
of my client's sites (all with m0n0walls on WRAPs too)
Before increasing my CACHESIZE variable, I did watch the dnscache log
file on the new dns server and it was pretty busy. After increasing it,
as well as increasing it on the email server (I run dnscache there too
to ease the load on the internal dns server) I noticed that after an
initial 'burst' of activity, it quieted down quickly as expected and all
ran smoothly for about 20 hours.
In actuality, YOUR issue interests me even more since I have djbdns
running in some rather large networks with mix of MACs, Windows and
Linux systems and have had 100% success with it, and nothing like you
describe. As a matter of fact even in this current case, djbdns never
stops working, is super-fast in replying to all requests and it is just
the firewall that is kernel panicing and rebooting.
Bob Gustafson wrote:
> I'm interested. I run a djbdns split horizon server with the external
> (outward looking?) dnscache running as FORWARDONLY.
> When I reboot any LAN machines (running Fedora8 and Firefox) with lots
> of windows and tabs open on Firefox, the sessions are saved, the box
> reboots and then when I say resume session on Firefox, apparently the
> dns chokes and all the firefox windows time out.
> I am not running m0n0wall in the path to the outside, but the
> strangeness of the djbdns might be both of our problems.
> Bob G
> On Wed, 2008-03-19 at 15:10 -0400, mtnbkr wrote:
>> I ran into a situation yesterday that I have yet to find a solution to.
>> A client's a 3-LAN WRAP with m0n0wall v1.3b4 firewall started kernel
>> panicing and rebooting... After connecting to the serial port, I noticed
>> the following additional information being logged:
>> ipf_nattable_max reduced to X
>> (where X is between about 20000 and about 29000)
>> Now, some random amount of time passes, during which time the web GUI
>> interface is inaccessible and the firewall stops syslogging to the
>> remote syslog server then,
>> panic: kmem_malloc(4096): kmem_map too small: 36687872 total allocated
>> At which point the system complains about no place to write a dump file
>> (it's on a WRAP so this makes sense) and it reboots.
>> Initially, this was a WRAP w/m0n0wall v1.3b4. I upgraded it to m0n0wall
>> v1.3b10 - same thing. So I swapped it out for a new 3-LAN port ALIX box
>> with m0n0wall v1.3b10 - same results.
>> After looking into the states page I noticed a high amount of outbound
>> dns queries from the "new" djbdns dns server so I increased the
>> CACHESIZE variable from its default 10 1Meg to 100Meg, and also
>> increased the DATALIMIT variable and restarted the djbdns service.
>> The firewall ran fine (stopped rebooting every 5-10 minutes) so I
>> thought I was home-free. It ran for almost 24 hours after those changes
>> but then again restarted itself.
>> This client is a school, and the students are away this week. I am
>> concerned that when they come back things will get worse. Does anyone
>> have any ideas as to how I may debug this further and get their network
>> back to the rock solid stability they have been used to?
>> Bill Arlofski
>> Reverse Polarity, LLC
>> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch