Hi,
I am running both ipfilter 4.1.8 (pfil 2.1.6) and 4.1.10 (pfil 2.1.7) on two
separate Solaris 9 systems.
I setup the following simple rule set on both systems to track down some
problems I was having with UDP fragments:
pass in quick proto udp from any to A.B.C.D port=5060 keep frags
block in quick from any to any
When I sent a large UDP packet (2 IP fragments) from another Solaris system
(also Solaris 9) to port 5060 on the 4.1.8 system, everything worked fine.
IPF matched the second fragment of the message with the first fragment, even
though the second fragment had no port information.
When I sent the same large UDP packet to port 5060 on the 4.1.10 system, the
second fragment was rejected by ipf, with the following message:
02/02/2006 13:15:59.632107 bge1 @0:2 b AA.BB.CC.DD -> A.B.C.D PR udp len 20
(550) (frag 50344:[EMAIL PROTECTED]) IN bad
After further analysis, I determined that the problem is caused by the
number of bytes in the second fragment. If the number of bytes in the
fragment is not a multiple of 8, the packet is marked 'bad' on ipf v4.1.10.
I tracked this check to module fil.c, and the patch below seems to correct
the problem (this has only been tested on Solaris 9).
Can anyone else confirm whether they are seeing this problem? If the patch
is ok, can this be incorporated into the next 'official' ipf build?
-Amruth
--- fil.c@@/main/dev/1 Fri Dec 9 00:57:23 2005
+++ fil.c Fri Feb 3 15:33:40 2006
@@ -1313,6 +1313,7 @@
u_short off;
fr_ip_t *fi;
ip_t *ip;
+ int mf = 0;
fi = &fin->fin_fi;
hlen = fin->fin_hlen;
@@ -1348,6 +1349,7 @@
*/
off &= IP_MF|IP_OFFMASK;
if (off != 0) {
+ mf = off & IP_MF;
fi->fi_flx |= FI_FRAG;
off &= IP_OFFMASK;
if (off != 0) {
@@ -1354,7 +1356,7 @@
fin->fin_flx |= FI_FRAGBODY;
off <<= 3;
if ((off + fin->fin_dlen > 65535) ||
- (fin->fin_dlen == 0) || (fin->fin_dlen & 7)) {
+ (fin->fin_dlen == 0) || ((fin->fin_dlen & 7) &&
mf)) {
/*
* The length of the packet, starting at its
* offset cannot exceed 65535 (0xffff) as
the
