Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 May 2013 19:07:23 +0200
From:      Spil Oss <>
Cc:, Gleb Smirnoff <>, current <>
Subject:   Re: Problems with ipfw/natd and axe(4)
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Hi YongHyeon,

Without natd this seems to work fine (both on RELEASE and CURRENT).
Both my Hong-Kong no-name and Edimax EU-4208 seem to behave the same.

This works with natd on RELEASE as well, but just for a limited time.
I've yet to establish if it's time or #packets that cause the
processing to stop. I'll try to generate some tcpdump output and
compare working / non-working connected to NIC with txcsum/rxcsum

Any pointers how to dig deeper?

Kind regards,


On Mon, May 13, 2013 at 6:36 AM, YongHyeon PYUN <> wrote:
> On Sat, May 11, 2013 at 12:04:09AM +0400, Gleb Smirnoff wrote:
>>   Spil,
>> On Fri, May 10, 2013 at 09:06:35AM +0200, Spil Oss wrote:
>> S> There seems to be quite a bit of overhaul on the firewall code, pf and
>> S> ipfw have been moved to sys/netpfil? Can there be some regressions in
>> S> there that I hit?
>> Yes, a regression is possible there. However, the issue seems to be
>> axe(4) specific, since there are no reports on more common NICs.
> There was no change to axe(4) except added a new device id so it
> seems the issue is not in driver. In addition, AX88772B engineering
> sample I have works without problems on CURRENT.
> I didn't use ipfw(4) or natd though.

Want to link to this message? Use this URL: <>