Problems with ipfw/natd and axe(4)
Spil Oss
spil.oss at gmail.com
Thu May 9 08:56:55 UTC 2013
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
More information about the freebsd-ipfw
mailing list