Re: Problems with ipfw/natd and axe(4)

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_at_)

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