Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 162438 - Bridge Code fails under FC4 w/Transparent Proxy to Squid
Bridge Code fails under FC4 w/Transparent Proxy to Squid
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-07-04 14:00 EDT by Moke
Modified: 2015-01-04 17:20 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-29 18:50:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Addition documentation (3.33 KB, text/plain)
2005-07-04 14:19 EDT, Moke
no flags Details
Fix for netlink conntrack bug in 2.6.12 (1.95 KB, patch)
2005-07-07 23:18 EDT, David Miller
no flags Details | Diff

  None (edit)
Description Moke 2005-07-04 14:00:19 EDT
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):

How reproducible:

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.

Additional info:
Comment 1 Moke 2005-07-04 14:19:33 EDT
Created attachment 116332 [details]
Addition documentation

Some additional information on the setup of transparent bridge
Comment 2 Moke 2005-07-05 11:25:05 EDT
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 
Comment 3 David Miller 2005-07-07 19:00:30 EDT
Do current upstream kernels have the same problem?
If so, it would be great to get a detailed report
posted to netdev@vger.kernel.org so that all the networking
developers can have a look at this problem.

Comment 4 Moke 2005-07-07 20:51:55 EDT
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.
Comment 5 Dan Carpenter 2005-07-07 21:02:39 EDT
You may have the same thing as bug 162388
Comment 6 Moke 2005-07-07 22:04:05 EDT
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? 
Comment 7 David Miller 2005-07-07 23:18:54 EDT
Created attachment 116502 [details]
Fix for netlink conntrack bug in 2.6.12
Comment 8 David Miller 2005-07-07 23:21:00 EDT
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.
Comment 9 Moke 2005-07-08 10:35:20 EDT
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
Comment 10 Moke 2005-07-08 12:20:49 EDT
Oh Well, loading 1390 didn't solve the problem, and I can't find the source 
code for it :(
Comment 11 Dave Jones 2005-07-12 21:54:28 EDT
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.
Comment 12 Moke 2005-07-12 22:03:20 EDT
Thanks so much David, I'll look for it :)
Comment 13 Dave Jones 2005-07-15 17:35:46 EDT
[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

Thank you.
Comment 14 Moke 2005-07-16 09:23:17 EDT
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 :)

Note You need to log in before you can comment on or make changes to this bug.