[ previous ] [ next ] [ threads ]
 
 From:  Christiaens Joachim <jchristi at oce dot be>
 To:  "'Manuel Kasper '" <mk at neon1 dot net>
 Cc:  "'list at m0n0wall dot neon1 dot net'" <list at m0n0wall dot neon1 dot net>
 Subject:  RE: [m0n0wall] pb8 released!
 Date:  Thu, 1 May 2003 18:34:27 +0200
Yesss...

still proving you're worth being my hero ;)

Thanks for the great work (and implementing the Caching DNS, remember?)!

Joachim

-----Original Message-----
From: Manuel Kasper
To: list at m0n0wall dot neon1 dot net
Sent: 30/04/03 21:38
Subject: [m0n0wall] pb8 released!

Good evening!
(at least to the part of the world where it's actually evening ;)

pb8 has just been released; new features:

- caching DNS forwarder, thanks to Bob Zoller! Great job again, dude!

- RADIUS server support for PPTP VPN (may be used with e.g. Microsoft
IAS)

- bug in ipfilter's MSS clamping feature fixed

I've spent too much time again fixing bugs in other people's code. I
figured that ipfilter didn't fix up the MSS properly on some packets,
while it worked fine on others (MSS = maximum segment size; a TCP
option;
fixing this up is necessary for PPPoE connections (DSL) since the MTU is
1492 instead of 1500 bytes because of the PPPoE header - all DSL routers
do that). At first it wasn't clear what exactly was causing the MSS
clamping to fail (I noticed it because my mail server was unable to
receive mail from users of a particular Swiss ISP while it worked fine
with others); extensive debugging with tcpdump and ethereal (sniffing
raw
PPPoE frames between m0n0wall and my ADSL modem) showed only one
difference: the SYN packets on which ipfilter failed had MSS as their
only
TCP option, while it worked with packets where MSS was followed by other
options (like timestamp or window scale).

With this in mind, I went over ipfilter's MSS clamping code and spotted
the mistake - an off-by-one security check (anti-buffer-overflow I
suppose) caused the clamping to fail for those packets. The fix is
trivial
(spotting the mistake wasn't ;) - a patch is attached for those who are
interested.

The impact was that transferring more than 1452 bytes of data at once
from/to hosts which:

- do not send any TCP options other than MSS clamping in their SYN
  (as such the bug depended on the operating system of the hosts)
and, at the same time
- block ICMP "fragmentation needed" messages

was impossible.

I've reported the bug to the author of ipfilter, Darren Reed, on Monday,
but so far I haven't got a response. Since the fix is so obvious, I
decided to roll it into m0n0wall without waiting for his
acknowledgement.

That's all for the moment; I guess I'll spend more time on "m0n0BSD"
now. :)

Greets,

Manuel


--- sys/contrib/ipfilter/netinet/ip_nat.c.orig	Mon Apr 28 18:08:46 2003
+++ sys/contrib/ipfilter/netinet/ip_nat.c	Mon Apr 28 18:09:10 2003
@@ -2984,7 +2984,7 @@
 			if (&cp[1] >= ep)
 				break;
 			advance = cp[1];
-			if (&cp[advance] >= ep)
+			if (&cp[advance] > ep)
 				break;
 			switch (opt) {
 			case TCPOPT_MAXSEG:


---------------------------------------------------------------------
To unsubscribe, e-mail: list dash unsubscribe at m0n0wall dot neon1 dot net
For additional commands, e-mail: list dash help at m0n0wall dot neon1 dot net


-----------------------------------------------
MISSION STATEMENT 
-----------------------------------------------

effectively by offering innovative print and document management products
and services for professional environments.

-----------------------------------------------
DISCLAIMER 
-----------------------------------------------
This e-mail message and any attachment are intended for the sole use of the
recipient(s) named above and may contain information which is confidential
and/or protected by intellectual property rights.
Any use of the information contained herein (including, but not limited to,
total or partial reproduction, communication or distribution in any form) by
other persons than the designated recipient(s) is prohibited.

If you have received this e-mail in error, please notify the sender either
by telephone (0032-2-729.48.11) or by e-mail and delete the material from
any computer.
Oce-Belgium/Oce-Interservices is nor responsible for the correct and
complete transfer of the contents of the sent e-mail, neither for the
receipt on due time.  This e-mail message does not bring about a contractual
obligation for Oce-Belgium/Oce-Interservices.

Thank you for your cooperation.

For further information about Oce-Belgium/Oce-Interservices please see our
website at www.oce.be

-----------------------------------------------