Older blog entries for lkcl (starting at number 161)

well, i got a new printer, hurrah. i hate printers. printers are irritating. if they work, they work. if they go wrong (drivers, hardware etc), it's a _complete_ pain in the neck to fix.

my fun-and-games began when recompiling the kernel. the _actual_ problem was that you have to mkdev a device number of 180 in /dev, which i only discovered later by activating (kernel compile) mounting (/dev/devfs) devfs and doing ls -al /dev/devfs/bus/usb/lp0 AAAAGH.

2.4.4 usb support is crap, it failed to create the device. 2.4.7 created the device but i didn't know about device number 180, so downloaded patches 2.4.10,11,12,13,14,15,16,17, 2.4.14-2.5.0 and 2.5.1. compiled up multiple kernels, got on with the job of running several.

lost all my pcmcia options and i forgot about pcmcia serial support _and_ i forgot about ppp async ARGH. rediscovered them.

discovered devfs - experimental device filesystem support, in 2.5.1, hurrah! it showed me the device number! cat 'hello you stupid printer^L' > /dev/devfs/bus/usb/lp0 hurrah! it worked!

okay, *groan* so there was nothing wrong with 2.4.7, 2.4.10, 12 _or_ 2.5.1. now to recapture my lost settings, including my pcmcia 3c574/serial card...

anyway, the upshot is that i am now the proud owner of a _working_ and cute and very small portable Canon BJC55 deskjet printer. it sings to me when you put the new cartridge in [which is why it's cute - you think i'd call a printer 'cute' otherwise??? :) ] as it tests it.

i have no idea how to print graphics on it, and lpd doesn't recognise it properly, but i don't actually care. cat file.txt > /dev/usblp0 is good enough for me!

i can now print out "stuff" like invoices and faxes and statements for people, which i am ever so pleased about. of course... everyone else i talk to takes this kind of thing totally for granted [well _duur_ of _course_ you can print stuff out these days, this _is_ the modern age you backwards philistine twerp!]

remember the story i told last year about the royal navy in 1850 commissioning sea charts to be a) calculated accurately b) _printed_ accurately, after the royal navy discovered that 1 in 3 charts had copying (yes, copying) errors. an error in the third decimal place on sea charts can result in being off-course by hundreds of miles.

anyway: we seem to have the calculating bit down pat, but the printing is still leaving a lot to be desired... :)

[update: _now_ i read raph's latest diary entry *grin*]

clinton's "dimbleby" lecture at the LSE on wed, broadcast on bbc2 on sun, was fantastic. i am so relieved to hear a prominent american actually talking sense. bush - the stupid one that's been bought by u.s. companies - wouldn't have a hope of coherently stringing any two of the sentences in clinton's lecture together, even if they were placed in front of his nose to read out loud.

i feel really sorry for america. well... not really. democracy results in people getting the leaders that they _deserve_. everyone takes on the consequences of their actions and thoughts, whether they like it or not.

anyway.

the building work, at least, has resulted in me writing a diary, wages, ordering, payment, invoicing and statements database plus a python command-line (enough for me to get by) to view invoices, orders, statements, cash invoices etc. kinda fun.

i get to add sales and other ledgers as soon as heather's explained it clearly enough to me :)

well, i feel a _Lot_ better having worked out that various suspicions regarding open source funding and therefore, by extension, open source companies, have a significantly higher probability attached to them [like, 99% instead of 70% or so].

the likelihood of there existing quite drastically important - and exploitable - security holes in a number of commercial linux vendors distributions is, therefore by extension, quite high.

purely conjecture, by being good at spotting patterns.

and also by being aware that the misnomer "no information", actually "negative results", is actually _useful_.

specifically, a number of statistically significant spurious time-wasting job offers and contracts rolled in at various significant times, leading me to conclude that something is drastically wrong with the popular viewpoint on who _actually_ runs open source.

the thing that _really_ pisses me off is what happened with linuxcare, and how these people jerked me around to the extent that a) i nearly had a nervous breakdown, and definitely went through some seriously heavy trauma b) i lost a lot of friends c) i lost a lot of money d) i lost the means to achieve my goals.

ends open source-related part. begins message to non-open-source individuals.

guys, you know who you are. if you're reading this, you made an enemy out of me. i won't make you pay for it, because you're not worth it. your arrogant manipulative short-sighted and ultimately evil nature contains the means by which you will fail without me having to be of assistance.

your interference causes too many waves to be tolerated and go unnoticed.

anyway. as a result, i am now working as a building labourer, for 12 hours a day, and have no time to spend doing open source software. congratulations, i bet you're real proud of yourselves.

busy. houses. car. no money. passing zero point in two weeks. couple of prospects. might _just_ be enough. still irritated with open source advocates given that there's no money around to even make sure shit happens. i have a hell of a lot to do, and i need about ten to twenty million to make it happen. then i can get on with it without taking shit from anybody. the ridiculous thing is that what i do will save people and businesses hundreds of millions of dollars in license fees, world-wide.

classis quotes from my teenage sister:

i was so ill i couldn't eat the other two chocolate cakes...

teehee. well, i am hoping to get either a positive response or _no_ response from mr william gates, and then EU directives cut in. interesting to note that those law professors declared the DMCA unconstitutional...

well, into the freedce client-side state machine i added the 3-way auth, and off it went, wha-hey. took me a while to notice that the code was fine, i was just using the wrong password... *muuur* :)

progress being rapidly made, have a netlogon.idl file i recreated, and lsarpc.idl, winreg.idl and a couple of others courtesy of matty. the neat thing about dce/rpc is that when you have the IDL file you *automatically* get a header-file and client-side API immediately.

if you already have [someone else's] server to play with, e.g. NT, you can use it IMMEDIATELY.

so, for example, we have a winreg.idl file therefore we AUTOMATICALLY have a complete Windows Registry API - for Unix.

i'm trying to get the wine development team's attention with this one, maybe i should try more eye-catching subject lines... :)

oh, man. the freedce (OSF 1.1 dce/rpc reference implementation) is _deep_.

i just started phase 1 of the NTLMSSP (NT security) server-side implementation, as mentioned earlier, and am now on client-side.

dce/rpc auth negotiation involves potentially multiple packet exchanges, even handling splitting a large authentication request and a large authentication response into multiple PDUs (protocol data units, equivalent to TCP (dis)assembly from UDP).

however, some authentication mechanisms - most notably but not limited to NTLMSSP - require a 3-way handshake. so you get BindRequest, BindAcknowledge, Auth3 and you're done, and then proceed to FnRequest, FnResponse exchanges to do in/out parameters.

so that's send, receive, send, [send, receive]*.

the freedce code implements its packet exchanges, both client and server-side, as a bloody _state_ machine. which explains why there are so many bits and pieces in the various headers because dce/rpc handles _per thread_ security if you need it, etc. etc.

basically, ten threads are allocated and because it's a state machine, a server can pretend to be able to cope with more simultaneous requests than it actually has threads. sort-of :)

very, very neat.

anyway, to cut a long story short, the server-side state machine copes perfectly well with 3-way authentication handshaking and, whilst there are comments in the code regarding client-side 3-way auth, it's not bloody well _in_ there.

argh! :) :)

well, the site goes well: behind the scenes is some quiet work going on. osexchange moved to dcerpc.net. NTLMSSP as an auth/sign/seal module, which is like the first real step in getting NT interoperability, is slowly progressing well. i have a successful server-side authentication and sign/seal decryption working, as long as the password is "test".

the problem here is the dependencies. NT authentication requires NT services and an NT-compatible API. without the NTLMSSP in place, i can't test the authentication because i don't have an API to use to actually validate the user!

_fortunately_ i can use rpcclient which i developed over four years as a test-tool. this i am really pleased about, and am learning a lot more - having access to freedce source - about dce/rpc than i was by just bouncing packets off of NT.

what i am really pleased about is to have a third dce/rpc-compatible "thing" in the picture against which to test interoperability.

_un_fortunately, this finds that there are bugs in the entire TNG/samba rpcclient / samrd NDR marshalling / unmarshalling libraries. well, of _course_ they are. it looks like microsoft was being incredibly lazy and just getting "wire-compatibility" [just like me *grin* except i have an excuse: for copyright and interoperability reasons, i couldn't look at any specifications]. so, if it "worked" when we bounced packets off of NT services, well, then, it worked, and that's the end of it.

but now we have _real_ functionality, by the people who actually _wrote_ dce/rpc, and of course, rpcclient fails in specific instances against freedce because we didn't know any better.

gonna be interesting.

and a lot of work, for which i am still not being paid. which is irritating, to say the least, given that this effort provides the entire open source community with an extremely valuable tool which, if nothing else, finally allows them to catch up with microsoft's last ten [physical, not man] years of development in key, strategic areas.

dcerpc.net

number of development man-hours for TNG / dcerpc.net CRITICAL PATH components comes to over 600 man-hours.

you would do well to look up the reasoning being SURS - SID to UID/GID Resolution System. it sounds like exactly the same sort of thing is needed. draft-lkcl-sidtouidmap-00.txt what is _really_ needed is for Unix systems to adopt GUIDs or SIDs for world-wide user and group identification, rather than locally-applicable uint32s or uint16s that stuff everything up rather badly when it comes to very large networks.

NT is actually far better positioned than unix, due to its use of the VMS security model, to provide worldwide security.