Joining the two discussions...
If you watch "snoop -v" output, does it suggest that the TCP checksum might be wrong?
I did do this, looking for that very issue of checksums, but the guide where I saw checksum being mentioned, it seemed to be about eri nic specifically, I should have tried either way of course...
set ip:dohwcksum=0
... however, this made no difference.
Meanwhile I also tried ip_fil4.1 - that was not a good idea. Instant panic, reboot and instant panic, reb... Took me a while to get a key and boot CD to fix that. Luckily it doesn't call savecore until after ipf had paniced, so /var/crash wasn't filling up.
However:
> I would be very interested to know if some changes I've made to the locking > fix this problem. > > If you can do stress testing, please download: > > http://coombs.anu.edu.au/~avalon/ip_fil4.1next.tar.gz
This works like a charm.
210.172.128.225 -> 204.152.190.12 TCP D=22 S=55198 Syn Seq=3164144531 Len=0 Win=65535 Options=<mss 1460,nop,wscale 6,nop,nop,tstamp 0 0>
204.152.190.12 -> 210.172.128.225 TCP D=55198 S=22 Syn Ack=3164144532 Seq=2314966196 Len=0 Win=32768 Options=<mss 1460,nop,wscale 0,nop,nop,tstamp 0 0>
So NAT is working well. Now I can stress test it to see how it behaves. It could be my earlier post regarding 4.1.3 panicing was due to that it wasn't actually working, but with 12,000 rules hitting it "something" was bound to fill up.
This is a complete vanilla box, for testing. If shell access would in any help with your work then this is no problem. But I suspect you perhaps knew what was wrong since 4.1next seems to work. I will report how the stress test pans out.
Sincerely,
Lundy
-- Jorgen Lundman | <[EMAIL PROTECTED]> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)
