On Fri, 18 Nov 2005, Adam Rosi-Kessel wrote: > > Just as a last resort. But the problem is so strange, I can't recall any > > patch related to such a behaviour. > > Unfortunately, I just tried a kernel upgrade (which pulled in a new libc6) > which totally hosed my RAID/LVM. It took me the better part of the evening > to get the RAID working again on the old kernel, so now I'm quite wary of > further kernel upgrades until/unless I figure out what happened there. That can happen, unfortunately. It'd be good to know the kernel version, however, which caused the problem with RAID/LVM. > So are there no diagnostics, absent rebuilding with netfilters debugging on, > for tracing a packet in between mangle PREROUTING and nat PREROUTING? Without further aid, no. > When exactly does the packet get connection tracked? In between mangle > and nat, or at the start of nat but before entering the PREROUTING > chain? The order is raw table, connection tracking, mangle, nat and filter tables. > And how is it that conn_track thinks the connection is ASSURED when there > actually hasn't been a single packet forwarded from the external server back > to the internal client? The answer is in above. Conntrack saw the packet as did the mangle table. Something strange happens in the nat table and without further informations nothing much can be said. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
