busdma MFC broke ipfw fwd for RELENG_6

[Eugene Grosbein]

Hi!

I understand that it is "a bit" late for RELENG_6 reports as 6.4-RELEASE was out in 2008
but the breakage had happened due to MFC so it's possible same problem exists in newer branches.

Long story short: I've updated my old 6.4-STABLE system for recent zoneinfo updates
and found the update broke 'ipfw fwd' feature: forwarded packets get corrupted,
routed packets go just fine.

The commit in question has been performed in 2010/08/06:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/Attic/busdma_machdep.c.diff?r1=1.74.2.6;r2=1.74.2.7

I've rolled it back using recent RELENG_6 sources and packet corruption have disappeared.

Full commit can be seen with the following command:

cvs -q diff -u -j "RELENG_6:2010/08/06 00:00:00 GMT" -j "RELENG_6:2010/08/07 00:00:00 GMT"

There was only one commit to RELENG_6 that day.
I do not understand how and why it broke "ipfw fwd" but that's the fact.

Some details: I have FreeBSD 6.4-STABLE router with LAN interface (rl0)
and WAN interface (re0) and L2TP tunnel (ng1) built with mpd5.
I forward some packets from LAN to ng0 with "ipfw fwd" and before the MFC
that setup worked just fine.

After update to recent RELENG_6, forwarded packets arrive corrupted to other side of L2TP tunnel
or get lost in between (due to bad headers, I guess). At sending side, tcpdump shows no problems
not for ng1 interface nor for re0 where it shows l2tp traffic with IP packets inside but really
ougouing L2TP packets go damaged (e.g. payload with zero bytes only), that can be seen
at receiving side of tunnel.

If I replace "ipfw fwd" with static route into the tunnel, packets go through just fine again,
so there is no problem with intermediate network.

But I need policy based routing and rollback of mentioned MFC has revived my setup again.
The guilty commit was found with simple "time dichotomy" (csup/build kernel/reboot/test/again etc.)

Just for archives.

Eugene Grosbein

P.S. Most of my production routers are still 6.4-STABLE