Problems with ipfw/natd and axe(4)

[Spil Oss]

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
disabled.

Any pointers how to dig deeper?

Kind regards,

Spil.

On Mon, May 13, 2013 at 6:36 AM, YongHyeon PYUN <pyunyh at gmail.com> 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.