From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4
Description of problem:
After upgrading to FC4 from FC3, a previously working Ethernet bridge ceases to function. No modifications were made to any control files during or after the upgrade. Although bridge and iptables logging indicate that redirection has taken place to Squid, the packets are lost. Directly pointing a workstation at the squid port does work, using transparency does not.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Upgrade existing Ethernet Bridge unit using transparent proxy from FC3 to FC4
2. Attempt to reboot and use the bridge.
Actual Results: I was unable to perform transparent proxy through the bridge using redirection to Squid from the internal interface, although the process worked successfully under FC3.
Expected Results: Everything should have continued to work as under FC3.
Created attachment 116332 [details]
Some additional information on the setup of transparent bridge
It would appear from other bug reports that I am not alone, and that the
problem also appears in more recent versions of FC3 kernels. As indicated in
the logs, traffic is getting to iptables rules, but dies there. This would
seem to be a significant problems with Fedora, and should be given high
Do current upstream kernels have the same problem?
If so, it would be great to get a detailed report
posted to email@example.com so that all the networking
developers can have a look at this problem.
As you can see the ruleset I'm using for testing is extremely simple. Both
kernel releases for FC4 appear the same, and I have de-installed and re-
installed all pertinent software. Several posts have started to appear stating
similar problems when moving up to FC4, but I don't have specific URL's for
them. I would be happy to supply with additional information if I can, but I
will need to drop the box back to FC3 pretty soon because this is a critical
needs for me.
You may have the same thing as bug 162388
I did see a reference to the fact that newer versions of FC3 manifested the
same problem also. Does this mean that I have to patch the kernel source and
recompile the kernel, or will the Fedora guys work out the details?
Created attachment 116502 [details]
Fix for netlink conntrack bug in 2.6.12
The attached patch in comment #7 is the correct one for this bug and
also for bug 162388.
David, please add that to the fedora kernels.
Thanks Guys- It's really great to have people really working on a problem,
even better when someone stands up to say it's my job to fix it. The kernel
developers even admitted their mistake in trying to go for the easy fix. What
a great community!
I'm currently running FC4 kernel 2.6.12-1.1387 on my test unit, and notice
today that kernel 2.6.12-1.1390 is available. Is this the fixed version, or
should I try applying the patch myself (I probably need to experience this at
least once in my life)?
Also, is there a link for the list of changes made to new versions of the
Thanks again, Mike
Oh Well, loading 1390 didn't solve the problem, and I can't find the source
code for it :(
This missed the 1394 testing update that went out this afternoon, but just got
committed to CVS. It'll make it into the final update that'll go out in a few days.
Thanks so much David, I'll look for it :)
[This comment has been added as a mass update for all FC4 kernel bugs.
If you have migrated this bug from an FC3 bug today, ignore this comment.]
Please retest your problem with todays 2.6.12-1.1398_FC4 update.
If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..
mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
Just installed the 2.6.12-1.1398_FC4 kernel, and everything is operational
again. Thanks to all for your help. Life is good again :)