TO make it clear - this happens not on my box, but I got several reports as a samba3 port maintainer for FreeBSD. So, here is the summary of the problem: Periodicaly smbd process dies without any meaningful error log from signal 6. Here is a typical stacktrace: #3 0x081d8e56 in smb_panic2 (why=0x825edec "assert failed", decrement_pid_count=1) at lib/util.c:1464 #4 0x081d8c8f in smb_panic (why=0x825edec "assert failed") at lib/util.c:1353 #5 0x0810cff4 in name_len (s1=0x82e8026 " EGEBFGEPFCEJFEEFCNDBDBEMECEMDCCAE") at libsmb/nmblib.c:1340 #6 0x0809bb46 in reply_special (inbuf=0x82e8000 "\201", outbuf=0x8309000 "\202") at smbd/reply.c:227 #7 0x080d2712 in construct_reply (inbuf=0x82e8000 "\201", outbuf=0x8309000 "\202", size=76, bufsize=131072) at smbd/process.c:995 #8 0x080d2ac0 in process_smb (inbuf=0x82e8000 "\201", outbuf=0x8309000 "\202") at smbd/process.c:1099 #9 0x080d389c in smbd_process () at smbd/process.c:1561 #10 0x08238d46 in main (argc=2, argv=0xbfbfeb3c) at smbd/server.c:910 The typical content of the inbuf will be attached to the report. SO far I have 12 coredumps, all with the same symptoms. Going through gdb we can see that coredump is actually happens due assertion failure in the libsmb/nmblib.c:1340, name_len() function: /* Add up the length bytes. */ for (len = 1; (*s); s += (*s) + 1) { len += *s + 1; SMB_ASSERT(len < 80); } This part. After going through the packet and extracting names of the participating peers, which look pretty legitimate, my only assumption is that the sign in assertion is wrong, and it should look like: SMB_ASSERT(len > 80); Which DO have sence - NetBIOS names expected to be short, actually, not longer than 16 chars, IIRC. Here is the dump of the passed names: Assert: len < 80; 34 Len: 34 |SERGSERVER | Assert: len < 80; 34 |FAVORITE-11LBL2| How to fix: Invert the condition in the assertion to: SMB_ASSERT(len > 80);
Created attachment 835 [details] Memory dump of the packet in char *inbuf. Taken via: dump binary memory
Created attachment 836 [details] dumb program, used to extract names from the packet Very primitive ad-hoc program, that let to extract passed names in the packet.
I don't understand your comment here. The assertion fires if the condition in SMB_ASSERT is False - ie. The assertion ensures that the name length is less than 80 or equal to bytes, and forces a panic if it's greater than 80 bytes. Changing the sign here would panic on short names, which I don't think is what you want. We should probably just ignore the bad name (greater than 80 byte length) rather than panic in smbd. Jeremy.
(In reply to comment #3) > I don't understand your comment here. The assertion fires if the > condition in SMB_ASSERT is False - ie. The assertion ensures that > the name length is less than 80 or equal to bytes, and forces a panic if it's > greater than 80 bytes. I must be too sleepy now :( You absolutely right :( It was just a wilg guess, that sparkled in my mind :( > Changing the sign here would panic on short names, which I don't think is > what you want. Definitely... > We should probably just ignore the bad name (greater than 80 byte length) > rather than panic in smbd. Good point... And, what is actually happening here: #5 0x0810cff4 in name_len (s1=0x82e8026 " EGEBFGEPFCEJFEEFCNDBDBEMECEMDCCAE") at libsmb/nmblib.c:1340 If to check that passed string carefuly it seen, that it actually one charecter longer that it supposed to be. I.e. the sting counter says - 32, but there are 33 ASCII chars before terminating '\0'. So, in name_len() in the cycle on the first iteration 32 characters are skipped and then *s == 'E', which makes loop to continue and len becomes equal 104, which is obviously greater than 80... So, this mistery is solved... But then the question arise - where that extra character comes from? Apparently, it's only name_len() algorithm that is so picky about that length. with that sanity check with name_len() skipped, name_extract() is able to extract proper name from the passed mangled one. This is the server NetBIOS name: | FDEFFCEHFDEFFCFGEFFCCACACACACACA|33 |SERGSERVER | From the coredumps following names were extracted: | FDFFEJEDEJEEEFFCCACACACACACACACAE|34 |SUICIDER | | EDFCEBFDEICACACACACACACACACACACAE|34 |CRASH | | EGEBFFFDFECACACACACACACACACACACAE|34 |FAUST | | EGEBFGEPFCEJFEEFCNDBDBEMECEMDCCAE|34 |FAVORITE-11LBL2| | EEEFEOCACACACACACACACACACACACACAE|34 |DEN | | EGEMFJCACACACACACACACACACACACACAE|34 |FLY | So, it's not one box, that produces such broken name hashes... I suspect that it's one of the ancient Windows versions(or, in opposit - some very new one). I'll try to get more information from the report originator...
At least one box was identified as Windows98. Possibly - localised(russian) version.
Timur. Is this still an issue in 3.0.20 ?
closing