Problems with ipfw/natd and axe(4)

[Ian Smith]

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