[ previous ] [ next ] [ threads ]
 
 From:  "Quark IT - Hilton Travis" <hilton at quarkit dot com dot au>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] FW: DNS information/error in event log
 Date:  Fri, 27 Aug 2004 08:12:27 +1000
Hi Fred,

> -----Original Message-----
> From: Fred Wright [mailto:fw at well dot com] 
> Sent: Tuesday, 24 August 2004 16:00
> 
> Back on-list.
> 
> On Fri, 20 Aug 2004, Quark IT - Hilton Travis wrote:
> > > From: Fred Wright [mailto:fw at well dot com]
> > > Sent: Friday, 20 August 2004 12:01
> > > On Fri, 20 Aug 2004, Quark IT - Hilton Travis wrote:
> > > 
> > > > I have noticed in our W2k3 SBS Error Logs the following 
> > > > types of errors, starting at 2024 (local) last night.  
> > > > Just thought I'd post this here in case it is a m0n0wall 
> > > > bug - never seen these  errors before.  I am running 
> > > > 1.1b17 on a net4501 if that helps, and 1.1b17 has been 
> > > > running since within about 24h of it being released.
> > > [...]
> > > > 	The DNS server encountered a bad packet from 
> > > > 192.168.69.254. Packet processing leads beyond packet 
> > > > length. The event data contains the DNS packet.
> > > 
> > > Do you have "allow fragments" checked on the rule that 
> > > applies to this traffic?
> > 
> > Unless the default rules have this selected, there are no 
> > additional rules at all relating to DNS traffic.  This is 
> > a pretty standard m0n0wall installation right now.
> 
> No, there's no option to have this on the default rule (there 
> probably should be), so if you need it you'll need to create 
> a specfic rule for it.
> 
> I'm actually surprised that the client was able to get the 
> incomplete packet at all.  Normally a packet is discarded 
> unless all fragments are present.  A Windows "feature" 
> perhaps. :-)
> 
> 					Fred Wright

Windows has a great many features that other operating systems fail to
offer.  And the vast majority of these features are not offered for
very, very good reasons.  :)

As for Windows actually receiving this packet, I'm kinda thinking that
it saw it and dropped it because it was only one fragment in a group,
and then logged the error instead of just staying quiet about it (as
Windows normally does wrt bad sh1+ happening).

Now, as for the option of having an "allow fragments" option on the
default rules, if this will help this error, and if m0n0wall is the
cause of this error - as I mentioned, it only started happening recently
(shortly after 1.1b17 was installed, and it continues happening with 1.1
final) - than I agree that this should be available in the advanced
section.  If m0n0wall is creating the problem, then it should also be
able to uncreate it.  :)  If it is not the cause, I'd like to find out
what is, and fix it there.

--

Regards,

Hilton Travis                          Phone: +61 (0)7 3343 3889
(Brisbane, Australia)                  Phone: +61 (0)419 792 394
Manager, Quark IT                      http://www.quarkit.com.au
         Quark AudioVisual             http://www.quarkav.net

http://www.threatcode.com/ <-- its now time to shame poor coders 
into writing code that is acceptable for use on today's networks

War doesn't determine who is right.  War determines who is left.