IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Otherwise we find spurious mid sign records on reply_ntcancel calls (they cancel
by mid). That took a *lot* of tracking down. I still need to remove the mid
records from the sign state on reply_ntcancel to avoid leaking memory....
Jeremy.
bug with w2k. Turns out that when we're doing a trans/trans2/nttrans call
the MID and send_sequence_number and reply_sequence_number must remain constant.
This was something we got very wrong in earlier versions of Samba. I can now
get a directory listing from WINNT\SYSTEM32 with the older earlier parameters
for clilist.c
This still needs to be fixed for the server side of Samba, client appears to
be working happily now (I'm doing a signed smbtar download of an entire W2K3
image to test this :-).
Jeremy.
from RFC but I'm smelling a client bug here.
/* only look at the first OID for determining the mechToken --
accoirding to RFC2478, we should choose the one we want
and renegotiate, but i smell a client bug here..
Problem observed when connecting to a member (samba box)
of an AD domain as a user in a Samba domain. Samba member
server sent back krb5/mskrb5/ntlmssp as mechtypes, but the
client (2ksp3) replied with ntlmssp/mskrb5/krb5 and an
NTLMSSP mechtoken. --jerry */
* use DsEnumerateDomainTrusts() instead of LDAP search.
wbinfo -m now lists all trusted downlevel domains and
all domains in the forest.
Thnigs to do:
o Look at Krb5 connection trusted domains
o make sure to initial the trusted domain cache as soon
as possible
maintain another tree then please apply!
On non-X86 machines out byte-order macros fails for one particular
value. If you asked for IVAL() of 0xFFFFFFFF and assigned it to a 64
bit quantity then you got a 63 bit number 0x7FFFFFFFFFFFFFFF rather
than the expected 0xFFFFFFFF. This is due to some rather bizarre and
obscure sign extension rules to do with unsigned chars and arithmetic
operators (basically if you | together two unsigned chars you get a
signed result!)
This affected a byte range lock using the large lockingX format and a
lock of offset 0 and length 0xFFFFFFFF. Microsoft Excel does one of
these locks when opening a .csv file. If the platform you run on does
not then handle locks of length 0x7FFFFFFFFFFFFFFF then the posix lock
fails and the client is given a lockingX failure. This causes the .csv
file to be trunated!!
