G'day.. this problem/bug is prob. already known... but still. when fireingup anny usermanager within a NT enviremnt. the manager gives back a: "STUB RECEIVED BAD DATA" and/or "ARRAY BOUND ARE INVALID" this only happens, with the mysql plugin.. (as far as i tested) i tryed the tdbsam, and there it works all fine.. (so no worry there) it's prob. a small typo error with assigning the expsam orso ?? (dunno) (don't think it's the actual sql plug in) the rest of the mysql plugin works fine Greet's Collen Blijenberg (MLHJ)
Somehow, i think the problem of this bug is not the mysql-plugin. we tested it several way's, and in ethereal dump's & debug log's it show's that the sql data get's send, but i gues not i the right way. there for it might be possible that the bug is where the plugin get's called, or where the plugin data get's handled... ???!? l8r, Collen dunno, just doing sugestions...
The bug is certainly not in the passdb code (the code you are referring to), since this code is exactly equal when using tdb or mysql. The bug is either in the mysql plugin or caused by illegal data in the MySQL database.
Jelmer, what's the resolution on this one ?
From Collen: > As far as i know, it's still open... > the bug still exist within samba 3.0.2 > can't seem to find the cure...
replease retest against 3.0.11.
Well i upgraded the network (pdb and bdc) to 3.0.11 version. but the bug is still there. stub received bad data. mysql 3.23.54. staingely the network works fine, users can login, i get home dirs and profiles ect ect. it's just when i try to get, the Fullname or Description or some other data, that stupid stub error pops up. same with the MS usermanager from nt4, i get an overview from the users and groups. clicking on a group works, klicking on a user for the userinfo fails.. ? so the issue is still there. i'm wondering if other exp_backends have the some problem orso.. Later Collen
jelmer, please fix this or mark as won't fix. You're call. No one else is maintaining these modules.
This error was raised whenever unknown_6 (size_is?) was lower then hours_len (length_is?). Fixed by setting the default for unknown_6 to 1260, which apparently is what tdb uses.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.