Problems with ipfw/natd and axe(4)

[Spil Oss]

Hi,

There seems to be quite a bit of overhaul on the firewall code, pf and
ipfw have been moved to sys/netpfil? Can there be some regressions in
there that I hit?

Just upgraded to r250404 but that does not help. Should I file a PR?

Kind regards,

Spil.

On Thu, May 9, 2013 at 10:56 AM, Spil Oss <spil.oss at gmail.com> wrote:
> Hi all,
>
> So I bought another AX88772B part, this time an Edimax UE-4208 and it
> behaved exactly like the no-name part I bought on eBay.
>
> Looking at YongHyeong's feedback on his engineering sample I decided
> to revert back to 9.1-RELEASE and try again, this works like expected.
> (see my post
> "Problems with axe(4) and checksum offloading" thread started Apr 7 in
> freebsd-current@)
>
> So somewhere between 9.1-RELEASE and 10-CURRENT r248351 there's a
> regression that breaks this. Any pointers on getting this to work?
>
> Kind regards,
>
> Spil.
>
> On Wed, Apr 17, 2013 at 7:03 AM, Ian Smith <smithi at nimnet.asn.au> wrote:
>> On Tue, 16 Apr 2013 20:52:05 +0200, Spil Oss wrote:
>>  > Hi all,
>>  >
>>  > If I disable checksum offloading on the NIC I do the tcpdump on, then I
>>  > assume that the checksum-check will provide accurate results?
>>
>> It certainly should.
>>
>>  > With checksum disabled, I see that the checksum is incorrect when the
>>  > client does not respond to the SYN,ACK, and correct when it does.
>>
>> I'm having trouble fully parsing that.
>>
>> Using 'tcpdump -vr ue0-ssh-fail.pcap | less -S' shows these incorrect
>> checksums alright; before adding -v I'd only noticed 172.17.2.1 sending
>> SYNs and clearly not responding to 172.17.2.111's SYN/ACKs.
>>
>> Since it works ok with the divert rule bypassed - presumably still with
>> tx/rxcsum enabled - then it seems that (surprise!) Luigi picked the
>> issue being in natd / divert socket handling.
>>
>>  > Out of curiousity I tried with pf as well and it behaves the same.
>>
>> Can't comment on that.  What's not clear is why the NIC "doesn't work"
>> (symptoms?) with -txcsum -rxcsum.  With the 'fail' pcap it seems the
>> received checksum from the client SYN is ok on capture, and the server
>> is responding with SYN/ACK (with mangled cksum), but the rxcsum must be
>> ok after natd, so maybe it's only -txcsum needed?  Might that work?
>>
>> Sorry, I'm just bouncing around on what I can see from here and could be
>> missing something someone else might find obvious, I'm just an amateur..
>>
>>  > On Mon, Apr 15, 2013 at 9:04 PM, Spil Oss <spil.oss at gmail.com> wrote:
>>
>>  > > Network dumps as promised
>>  > > On 172.17.2.1:
>>  > >       tcpdump -p -i bridge0 -s 0 -w ssh-fail.pcap host not 172.17.2.167
>>
>> You didn't post that one; I assume it showed the bad cksums back from
>> 172.17.2.111? ie that the SYN/ACK packet make it to the client's
>> interface, but was dropped for its bad cksum on the client side?
>>
>>  > > From 172.17.2.1 I ran
>>  > >       telnet 172.17.2.111/157 22
>>  > > In Wireshark I trimmed the capture a bit further with expression
>>  > >       'not stp and not http'
>>  > >
>>  > > Initial setup (ue0 ext, re0 int, rule 10 to allow ssh)
>>  > >      -> ue0-ssh-success.pcap
>>  > > Removed rule 10
>>  > >      -> ue0-ssh-fail.pcap
>>  > > Switched re0 and ue0, default ruleset (without 10)
>>  > >      -> re0-ssh-success.pcap
>>  > >
>>  > > According to YungHyeong the sample ASIX NIC he has works normally when
>>  > > checksumming is disabled.
>>
>> I guess trying another of the same NIC is the only way to rule out a
>> faulty unit?  I'm having similarly frustrating issues with a cardbus
>> USB2 card, unrelated but proving just as indeterminate ..
>>
>> [..]
>>
>>  > >> Does anyone know whether this is an issue with libalias(3) generally -
>>  > >> in which case using nat instead of divert shouldn't help - or just with
>>  > >> natd in particular?
>>
>> Question still stands .. I could redo that rc.firewall patch for nat in
>> 'simple' but if the problem is with libalias(3) it won't help with this.
>>
>> cheers, Ian