resolution to: advice for quick hack on _old_ code?
wow. that new ethereal is really nice!! What a difference a few months will make. The new ethereal told me that the NT error code I was getting (0x0580) is called STATUS_BUFFER_OVERFLOW. I guessed from this that I possibly needed to increase the max_data_size I send to the NT server and increase the size of the local response packet buffer. I tried the authentication again after making this simple change and found that the reponse packet was still getting truncated but the error code went away _and_, to my suprise, an NBSS Continuation Packet was sent after the first which contained the missing data. my lib handled that new packet without a hitch. I'm wondering now why no one around here tried that before. Thanks for your help Kevin. - Ben
Re: advice for quick hack on _old_ code?
Thanks for your response Kevin . It came just as I was leaving for a
much needed vacation. I hope you are still willing to take a look at
this.
I have done a packet capture. That's how I was able to get as far as I
have. The following is an example of one group-names request and one NT
response that my sources treat as an error.
sent smb request.
tcp .. ff 53 4d 42 25 00
00 00 00 18 03 80 00 00 00 00 00 00 00 00 00 00
41 43 00 08 87 00 00 08 fb 00 10 00 00 d8 00 00
00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 54
00 d8 00 54 00 02 00 26 00 00 08 e9 00 00 5c 00
50 00 49 00 50 00 45 00 5c 00 00 00 00 00 05 00
00 03 10 00 00 00 d8 00 00 00 06 00 00 00 c0 00
00 00 00 00 12 00 00 00 00 00 5a 40 71 c7 7d 85
d6 11 81 62 d2 88 9b 52 df 61 27 00 00 00 e8 03
00 00 00 00 00 00 27 00 00 00 01 02 00 00 ee 03
00 00 ed 03 00 00 fc 03 00 00 f4 03 00 00 f5 03
00 00 f6 03 00 00 f7 03 00 00 f8 03 00 00 f9 03
00 00 fa 03 00 00 fb 03 00 00 fd 03 00 00 fe 03
00 00 ff 03 00 00 00 04 00 00 01 04 00 00 02 04
00 00 03 04 00 00 04 04 00 00 05 04 00 00 24 04
00 00 23 04 00 00 11 04 00 00 12 04 00 00 13 04
00 00 14 04 00 00 15 04 00 00 16 04 00 00 17 04
00 00 18 04 00 00 1b 04 00 00 1c 04 00 00 1d 04
00 00 1e 04 00 00 1f 04 00 00 20 04 00 00 21 04
00 00 22 04 00 00
The help from ethereal and from looking at the code this is my
interpretation of the sent packet.
sent packet as recorded by ethereal
{
uchar msg_type == 0xff;
uchar server_comp[3] == {SMB}; //0x534d42
uchar command== 0x25; //smb trans
uchar error_class== 0x00; //success
uchar reserved == 0x00;
ushort error_code == 0x; //none
uchar flags == 0x18;
ushort flags2 == 0x8003;
uchar reserved[12] == 0x4143; //AC ?
ushort TID== 0x0008; //2048 (0800)
ushort PID== 0x8700; //135 (0087)
ushort UID== 0x0008; //2048 (0800)
ushort MID== 0xfb00; //251 (00fb)
uchar word_count == 0x10; //16
ushort total_parm_cnt == 0x;
ushort total_data_cnt == 0xd800; //216 (00d8)
ushort max_parm_count == 0x;
ushort max_data_count == 0x0004; //1024 (0400)
uchar max_setup_cnt == 0x00;
uchar reverved1 == 0x00;
ushare Flags == 0x;
uint timeout== 0x;
ushort reverved2 == 0x;
ushort parm_count == 0x;
ushort parm_offset== 0x5400; //84 (0054)
ushort data_count == 0xd800; //216 (00d8)
ushort data_offset== 0x5400; //84 (0054)
uchar setup_count== 0x02;
uchar reserved3 == 0x00;
ushort setup1 == 0x2600; //38 (0026)
ushort setup2 == 0x0008; //2048 (0800)
ushort byte_count == 0xe900; //233 (00e9)
uchar trans_name[14] == 0x5c0050004900500045005c00 // {\.P.I.P.E.\...}
ushort unnamed== 0x; // padding? ethereal ignores this
data
{
generic transaction header
{
??? == 05 00 00 03 10 00 00 00
uDataByte == d8 00 00 00 //216
(00d8) uDataByte == (0x3C + dwGroups * 4)
uSequence == 06 00 00 00 //6
(0006) ???
??? == c0 00 00 00 //192
(00c0) ??? == (uDataByte - 0x18)
??? == 00 00
byCommand == 12 //18
#define GET_GROUP_NAMES 0x12
};
??? == 00 00 00 00 00
uchar UID[16] == 5a 40 71 c7 7d 85 d6 11 81 62 d2 88 9b 52 df 61 // I don't
understand this.
dwGroups== 27 00 00 00 //39
(0027) number of group id's
command == e8 03 00 00 00 00 00 00
//GetGroupNames command.
dwGroups== 27 00 00 00 // why do this
again?
gids[dwGroups] ==
{
01 02 00 00
ee 03 00 00
ed 03 00 00
fc 03 00 00
f4 03 00 00
f5 03 00 00
f6 03 00 00
f7 03 00 00
f8 03 00 00
f9 03 00 00
fa 03 00 00
fb 03 00 00
fd 03 00 00
fe 03 00 00
ff 03 00 00
00 04 00 00
01 04 00 00
02 04 00 00
03 04 00 00
04 04 00 00
05 04 00 00
24 04 00 00
23 04 00 00
11 04 00 00
12 04 00 00
13 04 00 00
14 04 00 00
15 04 00 00
16 04 00 00
17 04 00 00
18 04 00 00
1b 04 00 00
1c 04 00 00
1d 04 00 00
1e 04 00 00
1f 04 00 00
20 04 00 00
21 04 00 00
22 04 00 00
};
};
};
And this is the packet that is returned that the library I'm working
with can't handle.
ff 53 4d 42 25 05 ÿSMB%.
00 00 80 98 03
advice for quick hack on _old_ code?
Hi. I'm a junior engineer (who's starting to grow up) at WatchGuard
Tech. We use some extremely old Samba code in our firewall to provide
user authentication against an NT server. I've been working on and off
on a number of bugs in this type of authentication for more than a year
now, and I am finally making some headway.
I have found a work around for one of our bugs earlier today, but I am
hoping to fix it the right way, if that's possible.
The bug: if the concatenated groupnames a user is in form a string of
greater than 255 characters long, the authentication fails.
I found that the problem occurs when the first of presumably many
packets containing group names returns from the NT server with a status
code of 0x8005. Our code interpreted this as a failure.
I found that if I ignore it I can get a truncated list of groups from
the single packet. Better yet, if I send a number of packets, each
asking for a small number of groups, then I can get the entire list in
chunks with no error code at all. This seems awfully hackish though.
I've tried sending the same packet to the server more than once when I
get a 0x8005 status. I've tried sending a new packet that asks for
only the groups that weren't returned in the first reply. None of this
has worked. The result is a new error code: 0xC0AE, which I don't
know how to interpret.
I have feeling that what I need is a transaction definition that tells
the NT server that I am ready to receive more of the group names. I
don't know how to find that though. And, unfortunately, all our
transaction command definitions are defined as raw byte arrays, which is
difficult to interpret. example...
// CreateFile(\samr)
const UCHAR Transaction00[] = { // DB
0x05,0x00,0x0B,0x00,0x10,0x00,0x00,0x00, 0x48,0x00,0x00,0x00,0x67,0x00,0x68,0x00,
0x30,0x16,0x30,0x16,0x00,0x00,0x00,0x00, 0x01,0x00,0x00,0x00,0x00,0x00,0x01,0x00,
0x78,0x57,0x34,0x12,0x34,0x12,0xCD,0xAB, 0xEF,0x00,0x01,0x23,0x45,0x67,0x89,0xAC,
0x01,0x00,0x00,0x00,0x04,0x5D,0x88,0x8A, 0xEB,0x1C,0xC9,0x11,0x9F,0xE8,0x08,0x00,
0x2B,0x10,0x48,0x60,0x02,0x00,0x00,0x00};
Can anyone help me out, or should I just go with my
ask-for-many-small-lists workaround?
Thanks a lot for any help.
- Ben
Re: advice for quick hack on _old_ code?
As far as I know we do publish the open source code we use. I don't know where or how it is published, but there is so much open source code in it that I can't imagine we'd make that kind of mistake. It's build around a Linux kernel and I believe most new features added start with GPL'd code. I am sure someone would be happy to talk to you about this though. - Ben On Fri, Jun 21, 2002 at 01:37:48PM -0700, Jeremy Allison wrote: On Fri, Jun 21, 2002 at 12:51:52PM -0700, Ben Johnson wrote: Hi. I'm a junior engineer (who's starting to grow up) at WatchGuard Tech. We use some extremely old Samba code in our firewall to provide user authentication against an NT server. I've been working on and off on a number of bugs in this type of authentication for more than a year now, and I am finally making some headway. You do publish the code you're linking to Samba code, don't you. You do know about the GPL (the license that Samba is under) I assume. I ask as I just did a google search for your product, and came up with this : http://www.watchguard.com/products/wgls.asp and I don't see any mention of the GPL or releasing source code anywhere. Can you please give more information as to how you're using Samba code in your product, I think we need to talk to you about this. Soon. Jeremy Allison, Samba Team.
Re: advice for quick hack on _old_ code?
On Fri, Jun 21, 2002 at 01:47:04PM -0700, Ben Johnson wrote: As far as I know we do publish the open source code we use. I don't know where or how it is published, but there is so much open source code in it that I can't imagine we'd make that kind of mistake. It's build around a Linux kernel and I believe most new features added start with GPL'd code. I am sure someone would be happy to talk to you about this though. Ok, cool - fair enough :-). It didn't appear obvious that it was a Linux based box so I was immediately somewhat wary :-). Thanks for letting us know :-). Jeremy.
