Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162438 - Bridge Code fails under FC4 w/Transparent Proxy to Squid
Summary: Bridge Code fails under FC4 w/Transparent Proxy to Squid
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-04 18:00 UTC by Moke
Modified: 2015-01-04 22:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-29 22:50:31 UTC

Attachments (Terms of Use)
Addition documentation (deleted)
2005-07-04 18:19 UTC, Moke
no flags Details
Fix for netlink conntrack bug in 2.6.12 (deleted)
2005-07-08 03:18 UTC, David Miller
no flags Details | Diff

Description Moke 2005-07-04 18:00:19 UTC
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 18:19:33 UTC
Created attachment 116332 [details]
Addition documentation

Some additional information on the setup of transparent bridge

Comment 2 Moke 2005-07-05 15:25:05 UTC
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 23:00:30 UTC
Do current upstream kernels have the same problem?
If so, it would be great to get a detailed report
posted to so that all the networking
developers can have a look at this problem.


Comment 4 Moke 2005-07-08 00:51:55 UTC
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-08 01:02:39 UTC
You may have the same thing as bug 162388

Comment 6 Moke 2005-07-08 02:04:05 UTC
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-08 03:18:54 UTC
Created attachment 116502 [details]
Fix for netlink conntrack bug in 2.6.12

Comment 8 David Miller 2005-07-08 03:21:00 UTC
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 14:35:20 UTC
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 16:20:49 UTC
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-13 01:54:28 UTC
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-13 02:03:20 UTC
Thanks so much David, I'll look for it :)

Comment 13 Dave Jones 2005-07-15 21:35:46 UTC
[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 13:23:17 UTC
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.