Description of problem: Kernel bug with SSM multicast in IPv6. Ordinary userspace application sending to IPv6 SSM range causes kernel BUG at net/core/skbuff.c:104! message and (of course) application terminates. Version-Release number of selected component (if applicable): New to 2.6.6-1.453, and then reproduced in all available FC2 kernels up to 2.6.6-1.453.2.3, reverting to FC2 release kernel (2.6.5) eliminates the crash. How reproducible: 100% reproducible for SSM range only on several machines Steps to Reproduce: 1. Get appropriate FC2 & kernel, enable IPv6 on your primary Ethernet adaptor (eth0) if necessary. 2. Install MAD-FLUTE software from site in bug URL, should build out-of-box on FC2 systems. 3. You will need a test file, "test.file" any small-ish file (say 40kbytes) 3. Run command described below, try both variations flute -S -a:IP6 -m:ff05::beef:6181 -p:4000 -t:2 -F:test.file [does not crash, should tran] flute -S -a:IP6 -m:ff35::beef:6181 -p:4000 -t:2 -F:test.file [crashes, kernel log attached] Additional information: The difference between ff05::beef:6181 and ff35::beef:6181 is that the latter is in the SSM address range reserved by an IETF RFC. It's not clear why the kernel cares about this, it's really of importance only for routers but it seems to make all the difference here. It's possible that MAD-FLUTE itself behaves differently in this case, but I'm not sufficiently familiar with the code to be sure. Testers: You should probably be able to reproduce this bug, and test the fix even without globally routeable IPv6 capability of any kind, just so long as you have an Ethernet LAN.
Created attachment 101596 [details] Crashlog from kernel 2.6.6-1.435.2.3
This is identical to the crash I reported in bug 126021 since the original bug reported there is (apparently) fixed, but this persists.
This is definitely fragmentation related. FLUTE works by sending IPv6 UDP packets to a multicast address. It appears that MAD-FLUTE v1.0 sends packets which get fragmented, and that's when the kernel bug is triggered. Limiting the packet size to e.g. 1000 bytes with -l:1000 sidesteps the crash on 2.6.6-1.435.2.3, this is a sufficient workaround for my immediate purpose, but of course that doesn't fix the bug. Is it worth me trying to narrow down the problem, perhaps to a short code segment that can be tested anywhere? I'd be more encouraged if I'd seen any kind of response to this bug in the 11 days since it was filed.
Well, part of this is that I've been away at a networking conference trip all last week. :-) Yes, please try to put together a small test case. When it requires a larger or non-trivial program to be setup, such as flute, it makes it more difficult to work on the bug.
Newly released kernel 2.6.7-1.494.2.2 seems to eliminate the kernel oops or crash/hang seen previously. Thanks. I've been too busy fighting very different but equally annoying bugs in FreeBSD to create a testcase, sorry. The fragmentation itself still happens for default settings on flute, but I will get feedback from core flute developers before deciding whether that's a Linux bug. Presumably you'd prefer to CLOSE this bug as RAWHIDE or whatever the modern equivalent is, and if the frags do turn out to be a kernel bug either we'd re-open it with a lower severity or file a new bug (your choice).