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....@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 _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
