Bug 162438

Summary: Bridge Code fails under FC4 w/Transparent Proxy to Squid
Product: [Fedora] Fedora Reporter: Moke <owenml>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: davej, dwmw2, pfrields, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-07-29 22:50:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Addition documentation
none
Fix for netlink conntrack bug in 2.6.12 none

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:
Always

Steps to Reproduce:
1. Upgrade existing Ethernet Bridge unit using transparent proxy from FC3 to FC4
2. Attempt to reboot and use the bridge.
3.
  

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 
priority.

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 netdev.org so that all the networking
developers can have a look at this problem.

Thanks.


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.
Thanks.


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 
kernel?

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
kudzu


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 :)