Hi Frank,

I've now actually tested your fix, and it really makes fragmented  
packets work again. However, now they are passed even when the  
corresponding firewall rule doesn't have the "Allow fragmented  
packets" option (= keep frags in ipfilter) set. Did you observe the  
same behavior?

Thanks,

Manuel

On 21.07.2007, at 03:24, Frank Edwards wrote:

> Gday
>
> I've taken a look at the fragment bug with 1.3b2 and tracked this  
> down to
> the following fix.
>
> What I observe is that IP packets marked as fragments, with offsets  
> not
> equal to zero (i.e. marked by ipfilter with flag FI_FRAGBODY)  
> arrive on the
> WAN interface OK but are dropped by ipfilter in function fr_check()  
> (fil.c).
> Net result - connections hang when inbound fragmentation is occurring.
>
> This occurs when the call to fr_addstate() is made, even though the  
> packet's
> forwarding rule has been set to pass by the NAT & firewall processing.
> fr_addstate() will always return NULL for any packet passed with
> FI_FRAGBODY. fr_check then blocks these packets based on the NULL  
> return
> from fr_addstate.
>
> So the proposed fix is as follows (this is patched against the
> monowall-patched fil.c).
>
> I've tested this fix using 1.3b2 based on RELENG_6_2.
>
> --- fil.c.orig Sat Jul 21 10:38:29 2007
> +++ fil.c Sat Jul 21 10:38:55 2007
> @@ -2488,7 +2488,7 @@
>    * Here rather than fr_firewall because fr_checkauth may decide
>    * to return a packet for "keep state"
>    */
> - if ((pass & FR_KEEPSTATE) && !(fin->fin_flx & FI_STATE)) {
> + if ((pass & FR_KEEPSTATE) && !(fin->fin_flx & FI_STATE) && !(fin- 
> >fin_flx
> & FI_FRAGBODY)) {
>    if (fr_addstate(fin, NULL, 0) != NULL) {
>     ATOMIC_INCL(frstats[out].fr_ads);
>    } else {
>
>
> Regards
>
> Frank
>