On Thu, Jul 28, 2011 at 08:51:41PM +0200, Claudio Jeker wrote:
> On Wed, Jul 27, 2011 at 10:37:30PM +0200, Christopher Zimmermann wrote:
> > Hi,
> >
> > pppoe0 has 92.203.101.134.
> > this works fine:
> >
> > match out log on egress inet from 192.168.23.0/24 nat-to pppoe0
> >
> > tcpdump while pinging:
> > 92.203.101.134 > 74.125.39.147: icmp: echo request
> > 74.125.39.147 > 92.203.101.134: icmp: echo reply
> > 92.203.101.134 > 74.125.39.147: icmp: echo request
> > 74.125.39.147 > 92.203.101.134: icmp: echo reply
> >
> >
> > But this doesn't:
> >
> > match out log on egress inet from 192.168.23.0/24 nat-to (pppoe0)
> >
> > tcpdump while pinging:
> > 92.203.101.135 > 74.125.39.147: icmp: echo request
> > 92.203.101.135 > 74.125.39.147: icmp: echo request
> >
> > in the (pppoe0) mode the IP address is always incremented by one.
> > This also happens to other ips, not just 92.203.101.134.
> >
> >
> > pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492
> > priority: 0
> > dev: ep1 state: session
> > sid: 0x166f PADI retries: 1 PADR retries: 0 time: 00:11:21
> > sppp: phase network authproto pap
> > groups: pppoe egress
> > status: active
> > inet6 fe80::211:25ff:feae:e0c%pppoe0 -> prefixlen 64 scopeid 0x6
> > inet 92.203.101.134 --> 213.148.133.4 netmask 0xffffffff
>
> What kernel did you use? A few things happend lately in pf(4) that could
> affect nat-to. Please include a dmesg so we have an idea how old your
> kernel is.
>
> I will play a bit tonight and see if I see the porblem as well.
Yup. The weighted round-robin stuff broke it. Here is a diff to fix the
problem. To be honest, I'm not even sure it makes sense to enter the
weight loop in the PF_ADDR_DYNIFTL case since there is no way to specify
a weight on a dynamic table. Ryan, Hennning, Jorg what is you're opinion?
Quick testing seems to indicate that least-state is not affected.
--
:wq Claudio
Index: pf_lb.c
===================================================================
RCS file: /cvs/src/sys/net/pf_lb.c,v
retrieving revision 1.16
diff -u -p -r1.16 pf_lb.c
--- pf_lb.c 27 Jul 2011 00:26:10 -0000 1.16
+++ pf_lb.c 28 Jul 2011 20:29:45 -0000
@@ -416,7 +416,10 @@ pf_map_addr(sa_family_t af, struct pf_ru
return (1);
/* iterate over table if it contains entries which are weighted
*/
- if (rpool->addr.p.tbl->pfrkt_refcntcost > 0) {
+ if ((rpool->addr.type == PF_ADDR_TABLE &&
+ rpool->addr.p.tbl->pfrkt_refcntcost > 0) ||
+ (rpool->addr.type == PF_ADDR_DYNIFTL &&
+ rpool->addr.p.dyn->pfid_kt->pfrkt_refcntcost > 0)) {
do {
if (rpool->addr.type == PF_ADDR_TABLE) {
if (pfr_pool_get(rpool->addr.p.tbl,
@@ -434,11 +437,15 @@ pf_map_addr(sa_family_t af, struct pf_ru
&rpool->curweight, af,
pf_islinklocal))
return (1);
- } else if (pf_match_addr(0, raddr, rmask,
- &rpool->counter, af))
+ } else {
+ log(LOG_ERR, "pf: pf_map_addr: "
+ "weighted RR failure");
return (1);
+ }
+ if (rpool->weight >= rpool->curweight)
+ break;
PF_AINC(&rpool->counter, af);
- } while (rpool->weight < rpool->curweight);
+ } while (1);
weight = rpool->weight;
}
