Date: Wed, 17 Apr 2013 15:03:17 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Spil Oss <spil.oss@gmail.com> Cc: freebsd-ipfw@freebsd.org, Michael Sierchio <kudzu@tenebras.com> Subject: Re: Problems with ipfw/natd and axe(4) Message-ID: <20130417133637.W56386@sola.nimnet.asn.au> In-Reply-To: <CAEJyAvMGKr9gZEEhg2KCD2FkZ=F4Xbx20v8iWyu8hhA_Pq8phw@mail.gmail.com> References: <CAEJyAvOZ6fW0i3yT_D4fH1huje-qsJwA7GGeXqAO1PKzge-YNw@mail.gmail.com> <20130415015850.Y56386@sola.nimnet.asn.au> <CAHu1Y73Xu64NY1B=idaKmHKDGOB3AHbcXKi4A48-SNkhJrMy6Q@mail.gmail.com> <20130415160625.K56386@sola.nimnet.asn.au> <CAEJyAvP-4FZ7eZ0o4c3qMzC0nY_gT4GfS3KjBVQiuzNY3aXz4Q@mail.gmail.com> <CAEJyAvMGKr9gZEEhg2KCD2FkZ=F4Xbx20v8iWyu8hhA_Pq8phw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130417133637.W56386>