I just got back from renewing my training experience with Red Hat Linux.
Its always full of new stuff, and this time it included details about RHEL 7.0
We haven't fully adopted RHEL 7.0 yet, but its on the horizon. If RHEL5.0 were Windows XP then RHEL6.0 would be Windows 7 and RHEL7.0 would be Windows 8 or 10. There is so much change.
But one of the things that hasn't changed is the use of LVM.
LVM stands for Logical Volume Mangement, and I had a revelation.. which I have not had before. I know not everyone 'gets it' and some even fear it. But after this 'new point of view' you might like it too.
I was sitting there in class and noticed that LVM parallels what we do with fdisk/gdisk, make file system and so forth. It was like the older partitioning tools were handling the 'Physical Volume Management' or 'PVM' where the 'LVM' tools were handling dicing up the Virtual Volumes that were created from the 'Physical Volumes'.
Its not really quite as simple as that.. but it forced a tunnel vision like focus.. that really LVM was just a 'terribly' poorly named system of tools for performing this 'Virtual Volume Management' function.
LVM truth be told is not its full name, its actually LVM2 because there was an earlier attempt called LVM1 or generically 'EVM' for 'Enterprise Volume Management'.
Enterprise Volume Management was needed because the 'Enterprise' could not afford down time, and needed to speed up the maintenance of replacing drives, extending or shrinking file systems on a live system.
This is critically important in Server class hardware systems, but why is it also useful to Desktop users?
Because the same abstraction allows re-swizeling or reallocating more or less drive space to 'Volumes' which can contain either the entire '/' root file system or any compartmentalized portion of it, like a /home branch.
Its also really nice when drive sizes out strip the ability of BIOS or a particular version of UEFI to access a block on a physical disk and need a shim, or driver provided by the hardware vendor to make it accessible.
The crux of the 'learning curve' however for newbies seems a pathological 'need' by instructors to make it sexy or 'include more stuff'.. usually tacking on things like MDRAID or synthetic software RAID, or more resilient file systems like journaled file systems in the discussion.. distracting and confusing.. and blending the information into this monolithic mess.. that leave a lot of smart people thinking they are inherent or part and parcel of the LVM system.. they are not.. they may depend on LVM to some degree.. but only as much as a file depends on a file system (any file system) for storage blocks.
So what is LVM ?
Put simply, its fdisk for Virtual Volumes.. or fdisk for Volume Groups.
You see to create a Virtual Volume (aka a Volume Group) you first need building blocks, these are called 'Physical Extents' or 'PEs' in Physical disk terms they are 'blocks' of storage. They can be made from carving up whole disks, or carving up MBR partitions of disks, or GPT partitions.. it doesn't matter.. its an abstraction of the 'Physical Blocks on Disk' to virtual 'Physical Extents'.
Once a whole disk or partition has been carved up into PEs they are then 'used' to compose or build a 'Volume Group'. (and you can 'size' these PEs independent of the block sizes on the Physical disks underneath this abstraction, at pgcreate time you can define the PEs 'size' in bytes)
A Volume Group then is like this 'Virtual Hard Disk' which like a thanksgiving turkey, needs to be carved up into smaller Virtual Partitions before you can use them, or mount them in your operating system. Those Virtual Partitions are then called 'Not Logical Partitions' but 'Logical Volumes'.. I can hear you scream.. why.. but why? are they not logically called 'Logical Partitions?' -- well that's because that term is already used down in the cellar of Physical Volume Management.. and we would not want to get confused using that term again. An MBR disk can have four and only four Primary Partitions, after that you cannot create any more.
So planning ahead you can use one of your remaining Primary partition slots to make a special 'Extended' partition.. which is never actually addressed.. except as a pointer to a chain of 'Logical Partitions' underneath... these Logical Partitions (have absolutely nothing to do with Virtual Volume "Logical Partitions").
Sooo.. waay up Topside..on top of Virtual Volumes made from Volume Groups.. we call them 'Logical Volumes'.. ironic.. irritating.. and confusing. (they're [partitions] for cotton pick'n sake..! )
Let me state that again...
A Virtual Volume (which "really" is a Volume Group) is called a Logical Volume.. grrr.
The tools for performing this magic are exceedingly simple.. but hard to remember until you master their names.. and reasons for the choice of their names.. even if that reason is rather obscure and never really discussed.
First Physical Extents (the building blocks) are "made" using the pgcreate tool. (why isn't it called pecreate? I have no idea.. grrr)
Then the Volume Groups (the virtual hard drives or "volumes") are "made" using the vgcreate tool.
Finally the Logical Volumes (the virtual hard drive "partitions") are "made" using the lvcreate tool.
1. pgcreate - "pe create" - makes virtual "leggos" or "virtual disk storage blocks"
2. vgcreate - "vhdd create" - makes "virtual hard drives"
3. lvcreate - "lpart create" - makes "virtual (logical) partitions"
Each tool has a corresponding sister tool called "xx-display" to inspect the results and keep track of the "Virtual environment"
1. pgdisplay - "pe display"
2. vgdisplay - "vhdd display"
3. lvdisplay - "lpart display"
Now once these "virtual volume - (logical) partitions" are created they can be accessed from the /dev or /dev/mapper points just like physical hardware.
And the same tools used for creating a file system can be used on logical volumes to create file systems. Mkfs could then be used to lay down a fresh xfs file system and will
be handled by the kernel device driver for xfs just like a physical
hardware device file system.
# mkfs -t xfs /dev/vg-group1/lv-volume1
(think of it "like" )
# mkfs -t xfs /dev/vhdd1/lp1
("or")
# mkfs -t xfs /dev/vg1/lv1
Then the mount command or the /etc/fstab file can be used to attach the new device and connect it to a mount point on the current file system.
Anything that happens below the "virtual volume" or "volume group" layer.. will be hidden or transparent to the activities of the overlaid pavement of the logical volume (aka the virtual volume 'logical partition' ) and file system.. this is the 'Enterprise quality feature,, which desktop users can also use'
If we need to add more space to a full Logical Volume file system.. we can simply add a hard disk, carve it up into more PEs with the pgcreate command and add those to the volume group, then use an LV tool called "lvextend" to make the partition "bigger" while the file system is being used.. and without backing up the contents and resizing the file system and then restoring the files (a lot of maintenance down time).
Likewise, if we need to "remove" or "replace" a disk (perhaps it failed, is failing or S.M.A.R.T. tells us its expected to fail or some other reason) we can use pvmove ( it stands for 'physical volume Move' why not PEmove ? I have no idea...), to clean out all of the PEs from one disk or partition that is part of a volume group.. without notifying the upper layers, like the LV or file system.. or user.. this "frees up" the physical hard disk or partition and we can take it out of service and replace it. All while the system is running.
The major difference between 'Enterprise' and 'Desktop' is really in the details of whether 'While the system is running' means 'hot' as in 'Live to the world' or 'warm' as in 'Being used but can be rebooted to perform some quick task then back to service'. The game is to minimize system unavailability.
MDRAID or Multidisk RAID (aka software raid) or its likewise drivers can use LVs just like real physical disks or physical partitions to create fast RAID 0 or slow but resilient fail safe RAID 1 drives or anything in between. But they really don't require LVM.
LVM can also do nice things like make Copy on Write or Snapshot images possible.. but those are not fundamental reasons or purposes for LVM to exist.
Including obscure things like ( MDRAID, CoW, journaled file systems et. al. while 'sexy' ) in a newbie introduction simply flys over the important details of LVM and serves to confuse newbies about a very important tool that has become essential in daily life.
The terminology is a quagmire of a historical word swamp and does nothing to make it understandable.
1/19/2017
1/16/2017
Czur, project review for 2016
I don't work for Czurtek, but I contributed to their Indiegogo project and received an ET16 document or book scanner early in 2016. Here is a few thoughts on how my perception of this project has changed.
First, I don't want to make this a long article, but wanted to pull together my shifting thoughts on this project here on January 15, 2017.
When I started with the scanner I had thoughts it would be similar to a Aztec Booksnap or Fujitsu 4220c or somewhere inbetween. I was wrong.
It does scanning well and produces a collection of scan images [per session] and then provides a [work table] on which you can perform clean-up of the images individually or in bulk, then choose to create OCR - Optical Character Recognition, and bind the touched up images and the OCR information into a Searchable PDF file for archiving or reading later.
That was the dream, but it fell short in a few areas.
The Desktop PC for Windows software had some challenges in communicating what it could do, how you should use it, and in how to update it.
The Desktop PC for MacOSX software was not released and its been quite a while, but a new pre-release demo now exists which appears very similar and very good.. but so far also lacks good documentation.
The Desktop PC for Linux (if it is planned) has also not been sighted.
Over the last year I have had good luck at contacting support and they have responded with a private Twain32 driver for Windows, and an updated Twain32 driver for Windows (I have yet to review).
They have also shown me an SDK for developing programs on Windows that by-pass the Desktop software and scan images direct to the file system.
On my own I've come to understand that they are not very precise on releasing details about the chipsets or optics used in the hardware, and my guess is that this is due to Non-Disclosure Agreements with iCatchtek, or SunPlus which seem to do a good job of keeping their datasheets and programming guides off the Internet.
But on the good side, it seems the resolution and optics are so good as to put precisely considering and managing those details are not as important as they once were. From an engineering or obsessive detail persepective this can be frustrating.. but in the end really not that important. Any optical barrel distortion effects are confined to such a small field of view its just not that important.
This is also not that much different from the level of detail available for the Apple iPhone.
Its important to understand too that USB 2.0 or USB 3.0 has limits in the available bandwidth for capturing an image and moving it over to the PC across USB. Too long a delay is simply not acceptable, so often MJPEG or Motion JPEG of a high resolution is used to moved scan images across the USB cable. YUY2 (uncompressed raw) is available, but only at lower resolutions.
The controls on the desktop software are more or less like the [Auto] or coarse level controls available on 'Point and Shoot' pocket Cameras, demanding few specifics. These limited Profiles set the scanner camera, lights and image capture chip up based on the general question [what are we scanning today?] by way of -- 1. Is it a Full Color Photo? 2. Is it Color Line Art? 3. Is it a B&W Photo? 4. Is it Simple B&W Text?
Considerations like Dots Per Inch, Filters for Moire, and other things are left to "post processing" after the image is acquired.
On the PC the post processing is carried out using the OpenCV libraries.
As best I can tell the OpenCV libraries for the PC running Windows, use the DirectShow interface to create a FilterGraph, which is an object that continuously grabs frames from the scanner and passes them into a Null render object. On its was to Null however is a general purpose [grabber] object which can copy a single frame and place it in a memory buffer setup by OpenCV to receive the image, then any of the functions in OpenCV can be used to "Post process" the image in preview to optimize what will be scanned and captured then post processed into an image file on the PC.
Since the original scanned image is also available, before processing it can be saved too. This is as close to raw as we can get for now.. but its really not that important.
The major features touted for "this" scanner are the ability to "automatically" straighten or flatten the image, based on the additional ability to take a lower resolution scan with Laser beam guides. The high-res image and the low-res image are then "stretched" in OpenCV to mask and correct the 3D distortion from bending or folding until the Laser bean guidelines are straight. Quite a marvelous item in one combined product if all goes well. Some people call this "De-warping" the image.
I am not sure how, but original images can also seemingly be re-examined and re-post processed, which suggest the lo-res image may be embedded into the original hi-res image file for possible later use.. but I could be wrong and just not understand the system.
The long term goal however is to make scanning and binding into an electronic document or eBook (in the form of a PDF) easy and without much thought. I think this would have worked.. if details about how it was handling the images were provided, and demos included clear instructions from A to Z on how to do this.
While certainly possible on Windows with the Desktop PC software, until recently it hasn't even been possible on the MacOS with the Desktop PC software.
The cloud solution seems to have trouble that users outside China experience as long unacceptable delays requiring an always connect state with the Internet.
The scanner is partially UVC compatible, meaning default programs on Windows, MacOS and Linux identify it, load their drivers and will use it for taking pictures, but generally low resolution pictures, and the default programs do not 1. provide fine control over the image contrast and brightness or colors 2. provide 2D straightening or 3D flattening 3. provide automatic OCR 4. provide a work table for touch up or binding into a PDF document.
In summary my perspective and expectations have changed over the year.
This is an Amazing product, still in development, and will be a great value when it is complete. And the renewed release of new firmware and Desktop software, the release of Desktop software for the Mac, release of Twain32 and release of a second generation of Twain32 driver plus an SDK that includes the ability to 2D straighten and 3D flatten.. all point to a very bright future for this project and product -- but -- it is not finished!
The biggest challenges are the "language" barrier and lack of sufficient documentation to not only "achieve" document scanning and binding.. but that guides and teaches.. and makes you comfortable with it.. are its biggest challenges today.
I regularly receive a lot of offline commentary and inquiry about this scanner and requests for my opinions.. but I always preface those conversations with 'I do not work for Czurtek..' so I cannot and do not speak for them.
I can say I wouldn't mind serving in some way to help with the documentation, but I think the language barrier flows two-ways.. I do not think they always understand what I am saying when suggesting small improvements that would make a 'big' difference in how people perceive their product.
Luckily I have a full time job, so the only benefit I get from making videos or answering questions about the Czur ET16 is when I learn something for myself or someone politely says a video or article helped them. And for that I thank anyone who happens to read these articles..it motivates me to keep going and not give up on the ET16..and sometimes I do feel like giving up.
But with patience and time, I can see its potential.. and that really there is nothing currently on the market like it. Its super simple, its complete, the results are really good.. and its still being improved.
Usually when something comes to market, all development stops and its frozen in feature time.
This scanner is not.. its improving and its getting better.
First, I don't want to make this a long article, but wanted to pull together my shifting thoughts on this project here on January 15, 2017.
When I started with the scanner I had thoughts it would be similar to a Aztec Booksnap or Fujitsu 4220c or somewhere inbetween. I was wrong.
It does scanning well and produces a collection of scan images [per session] and then provides a [work table] on which you can perform clean-up of the images individually or in bulk, then choose to create OCR - Optical Character Recognition, and bind the touched up images and the OCR information into a Searchable PDF file for archiving or reading later.
That was the dream, but it fell short in a few areas.
The Desktop PC for Windows software had some challenges in communicating what it could do, how you should use it, and in how to update it.
The Desktop PC for MacOSX software was not released and its been quite a while, but a new pre-release demo now exists which appears very similar and very good.. but so far also lacks good documentation.
The Desktop PC for Linux (if it is planned) has also not been sighted.
Over the last year I have had good luck at contacting support and they have responded with a private Twain32 driver for Windows, and an updated Twain32 driver for Windows (I have yet to review).
They have also shown me an SDK for developing programs on Windows that by-pass the Desktop software and scan images direct to the file system.
On my own I've come to understand that they are not very precise on releasing details about the chipsets or optics used in the hardware, and my guess is that this is due to Non-Disclosure Agreements with iCatchtek, or SunPlus which seem to do a good job of keeping their datasheets and programming guides off the Internet.
But on the good side, it seems the resolution and optics are so good as to put precisely considering and managing those details are not as important as they once were. From an engineering or obsessive detail persepective this can be frustrating.. but in the end really not that important. Any optical barrel distortion effects are confined to such a small field of view its just not that important.
This is also not that much different from the level of detail available for the Apple iPhone.
Its important to understand too that USB 2.0 or USB 3.0 has limits in the available bandwidth for capturing an image and moving it over to the PC across USB. Too long a delay is simply not acceptable, so often MJPEG or Motion JPEG of a high resolution is used to moved scan images across the USB cable. YUY2 (uncompressed raw) is available, but only at lower resolutions.
The controls on the desktop software are more or less like the [Auto] or coarse level controls available on 'Point and Shoot' pocket Cameras, demanding few specifics. These limited Profiles set the scanner camera, lights and image capture chip up based on the general question [what are we scanning today?] by way of -- 1. Is it a Full Color Photo? 2. Is it Color Line Art? 3. Is it a B&W Photo? 4. Is it Simple B&W Text?
Considerations like Dots Per Inch, Filters for Moire, and other things are left to "post processing" after the image is acquired.
On the PC the post processing is carried out using the OpenCV libraries.
As best I can tell the OpenCV libraries for the PC running Windows, use the DirectShow interface to create a FilterGraph, which is an object that continuously grabs frames from the scanner and passes them into a Null render object. On its was to Null however is a general purpose [grabber] object which can copy a single frame and place it in a memory buffer setup by OpenCV to receive the image, then any of the functions in OpenCV can be used to "Post process" the image in preview to optimize what will be scanned and captured then post processed into an image file on the PC.
Since the original scanned image is also available, before processing it can be saved too. This is as close to raw as we can get for now.. but its really not that important.
The major features touted for "this" scanner are the ability to "automatically" straighten or flatten the image, based on the additional ability to take a lower resolution scan with Laser beam guides. The high-res image and the low-res image are then "stretched" in OpenCV to mask and correct the 3D distortion from bending or folding until the Laser bean guidelines are straight. Quite a marvelous item in one combined product if all goes well. Some people call this "De-warping" the image.
I am not sure how, but original images can also seemingly be re-examined and re-post processed, which suggest the lo-res image may be embedded into the original hi-res image file for possible later use.. but I could be wrong and just not understand the system.
The long term goal however is to make scanning and binding into an electronic document or eBook (in the form of a PDF) easy and without much thought. I think this would have worked.. if details about how it was handling the images were provided, and demos included clear instructions from A to Z on how to do this.
While certainly possible on Windows with the Desktop PC software, until recently it hasn't even been possible on the MacOS with the Desktop PC software.
The cloud solution seems to have trouble that users outside China experience as long unacceptable delays requiring an always connect state with the Internet.
The scanner is partially UVC compatible, meaning default programs on Windows, MacOS and Linux identify it, load their drivers and will use it for taking pictures, but generally low resolution pictures, and the default programs do not 1. provide fine control over the image contrast and brightness or colors 2. provide 2D straightening or 3D flattening 3. provide automatic OCR 4. provide a work table for touch up or binding into a PDF document.
In summary my perspective and expectations have changed over the year.
This is an Amazing product, still in development, and will be a great value when it is complete. And the renewed release of new firmware and Desktop software, the release of Desktop software for the Mac, release of Twain32 and release of a second generation of Twain32 driver plus an SDK that includes the ability to 2D straighten and 3D flatten.. all point to a very bright future for this project and product -- but -- it is not finished!
The biggest challenges are the "language" barrier and lack of sufficient documentation to not only "achieve" document scanning and binding.. but that guides and teaches.. and makes you comfortable with it.. are its biggest challenges today.
I regularly receive a lot of offline commentary and inquiry about this scanner and requests for my opinions.. but I always preface those conversations with 'I do not work for Czurtek..' so I cannot and do not speak for them.
I can say I wouldn't mind serving in some way to help with the documentation, but I think the language barrier flows two-ways.. I do not think they always understand what I am saying when suggesting small improvements that would make a 'big' difference in how people perceive their product.
Luckily I have a full time job, so the only benefit I get from making videos or answering questions about the Czur ET16 is when I learn something for myself or someone politely says a video or article helped them. And for that I thank anyone who happens to read these articles..it motivates me to keep going and not give up on the ET16..and sometimes I do feel like giving up.
But with patience and time, I can see its potential.. and that really there is nothing currently on the market like it. Its super simple, its complete, the results are really good.. and its still being improved.
Usually when something comes to market, all development stops and its frozen in feature time.
This scanner is not.. its improving and its getting better.
1/12/2017
Czur, (beta) Mac OSX scanning software
This is a demo of the Czurtek scanning software for the Apple Mac on my MacBook Pro 2012. Its really good already and can only get better.
1/10/2017
Programming, windows usb devices
I feel it useful to document by diary/journal when learning something new. In the confusion that exists before consolidating memories are "perspectives" born of a time when I did not know how things actually worked. In that narrrow twilight zone of understanding are common tropes or "pathways" that other people may travel.. perhaps because of a common heritage of prior experience. -- by documenting the misconceptions and "wrong headed" failures.. I hope other people can enjoy the "trip" and arrive at their personal destination (or similar understanding) that much quicker.
USB comes in three versions or "flavors" 1.0, 2.0, and 3.0 generally defined by their speed or data rate, but also defined by the hardware chipsets that enable the ports that physical devices are plugged into a computer.
The wire "signal" is a complex "balanced" overlapping arrangement of virtual bit trains and virtual "frame sets" which indicate chunks of information. Embedded in this stream are timing and data information and multiplexed "purposes" as there are co-existing "different" [types] of virtual pipes with differing behavior. For example, some traffic is "prioritized" over other traffic, such as for pseudo CPU "interrupt" driver processing service. Other types are for "lossy" communication in which dropped packets of data in exchange for "realtime" or "current" data is acceptable (think a telephone voice call where 'crackle or noise' is acceptable as long as the voice is pseudo-realtime and not delayed). Still other types are for absolutely "reliable" traffic even if it is delayed.
Quite a bit of the wire protocol is encapsulated inside the silicon "chips" which are embedded into the computer motherboard or inside the external hubs and usb devices themselves.
These are connected together with USB cabling to provide service.
There are standards for USB cabling and different capabilites with each type of cabling. But I won't get into those feature here.. since I'm more interested in learning to write a program or driver that opens communications and actually makes use of a usb device.
Within Microsoft Windows is an arrangement between user application and kernel applications where by the User Mode and Kernel Mode programs are written using two different sets of Headers and Libraries. Each has their own set of APIs (application programming interfaces).
For the most part these APIs are C/C++ compatible and most User Mode or Kernel Model programs are written in C or C++. Then compiled using either the SDK for User Mode or DDK for Kernel Mode. Each of these "Development Kits" contains their own "complier" customized and setup to reference the correct set of Headers and Libraries at compile time.
Windows also includes a general purpose "database" which the User Mode or Kernel Mode programs can access at runtime called the "Registry". Historically evolved from a collection of [INI] files into a unified set of binary files to gain speed of access and to allow the database to grow much larger and faster than an ordinary text file based database would make possible. It also allows a certain obscurity or ofuscation (opaqueness) to the database which was later given.. even an access permission control system to prevent certain entries from being accessed or changed without the proper user permissions. All of this means even the User Mode and Kernel Mode programs have parts of their APIs dedicated to accessing the registry, which they access to make use of dynamic runtime libraries and COM/DCOM runtime objects.
All of that is history and window dressing for the main stage of developing application to access USB devices.
In the early days of windows, even in DOS, there were no USB "drivers". Each program had to initate the USB port and manage the abstracted protocol features the chipsets provided to communicated with USB endpoints which represented devices connected by USB cable.
In time however "Kernel mini-port" drivers were created to manage and "share" access first to USB Host controllers, then USB hubs, and finally USB devices. As this "Stack" of drivers came into being Microsoft sought to make driver writing simpler and faster, as well as less error prone.
So the evolution from "mini-port" drivers was to "device driver frameworks" to assist driver writers in creating drivers based on examples or "templates" which guided them in making similar drivers that had similar features.. like debugging or other features.. so that they could all be treated similarly by the overall operating sytem. -- in particular the jump from 9x (VxD) and NT kernel device drivers, was to the WDM - Windows Device Model kernel mode device drivers. (soon to be replaced by the WDF- Windows Driver Framework)... Which led to frameworks for creating all kinds of device drivers.
Specific to USB however was the establishment of the [winusb.sys] device driver which took over much of the job of older or vendor specific device drivers and co-operated with the central operating system kernel to share and manage the USB [bus] as a common "thing" that might be used simultaneously by many programs at the kernel and user mode levels.
USB is a "shared" communications medium, even if it may appear at times to be a cascading set of point-to-point connections. At any one time the total bandwidth of a singular USB port on the computer may be prioritized or divided out among many USB devices on the virtual "bus" shared by all the connected devices.
So once the WDM framework made device driver writing easier and the shared USB bus management made using multiple USB devices simultaneously possible.
Microsoft set about co-operating with the USB Special Interests Group (SIG) or USB Forum, which had shared interests in "standardizing" groups of similar USB devices and coming up with agreed upon minimal protocols to use these groups of USB devices. They were called USB "classes".. not in the sense that they were abstract Programming classes, but that they shared a common set of designs and features which could be probed and expected to exist, and thus similar drivers with "vendor specific" deviances or functions could be accessed.
The win for Microsoft was they could include [in-the-box] with a new version of Windows both a winusb.sys driver for oddball USB devices that were unique, and "Class" device drivers which would provide certain minimal services for "recognized" USB devices.
The USB devices were "recognized" by a process called discovery or "Plug and Play" detection and device driver loading.
USB devices generally have an established protocol where "descriptors" or "strings" of information can be retreived from a USB device after it is assigned an address on the USB bus.
The end result is a User mode program can start up and probe the system device list for a target which represents the USB device it needs to peform its function. And by sending IRB (Input/Output Request Blocks) to the Class driver communicate with the USB device.
IRBs are very low-level however and generally a Class driver has a predefined set of headers and library or APIs for communicating with the USB device it manages.. abstracting away (or simplifying) the level of effort required to write an application that uses the USB device.
The really hard part (I think) about all of this is knowing the history of what came before, so that not only you have perspective, but can also "filter" or "ignore" whispers of irrelevant data .. such as information about a VxD, or about a long deprecated protocol like VfW - Video for Windows, which trying to get a foot hold in the current era can distract you.. or prevent you from choosing the most appropriate API to use for the Class driver your interested in probing and using.
There are "models" within "models" describing both "abstract" representations (or "perfect" idealized models of how things work) and then "real" representations of actual devices which have [some] of the chracteristics of the ideal "model" + plus "extentions" or features that the model does not address, which you then have to figure out how to address. Some Class drivers build in (vendor specific) methods to access these other features.. but some do not.. in which case you may have to consider writing a mini-port driver to co-operate with a Class driver (an extension "plugin") .
The USB forum (or SIG) also describes many of these same things in similar but not identical terms, so that an abstract model in Microsoft documentation may not line up with the description of the same thing in a generic USB forum Spec written with the idea of serving multiple purposes beyond Windows programming.. such as programming for Linux or Apple OS products.
In the perfect Microsoft Windows programming world. A USB device will have a high level, high functioning Class driver and the end user User Mode Application will have an available "framework" specific to their task.. such as DirectX Direct Show for Video, and the end user will not have to write a device driver, or understand many of the details of how the actual silicon or the device performs its task.. it just appears to do so.. like "magic"
A further "funny" detail is that you should not loose sight of the fact that a USB bus is a negotiation between two independent devices arbiting over communcations and services. The USB device is itself its own computer, with its own operating system (however simple that may be) and thus has its own programming. Often called "firmware", it can have bugs, it can change, and features that were available in one version of the firmware can change or be removed in the next.
Generally the USB descriptors are used as the IUnknown or COM type object feature of "discovery" and "enumeration" or list of available features.
It is through the USB descriptors a USB device provides about itself that Class drivers can setup and expose features of the device to the operating system user mode programs.
In the inital release of a hardware USB device, the firmware may not be 100 percent complete. And the USB descriptors may describe features or functions that are not quite bug free, or even implemented yet.
USB comes in three versions or "flavors" 1.0, 2.0, and 3.0 generally defined by their speed or data rate, but also defined by the hardware chipsets that enable the ports that physical devices are plugged into a computer.
The wire "signal" is a complex "balanced" overlapping arrangement of virtual bit trains and virtual "frame sets" which indicate chunks of information. Embedded in this stream are timing and data information and multiplexed "purposes" as there are co-existing "different" [types] of virtual pipes with differing behavior. For example, some traffic is "prioritized" over other traffic, such as for pseudo CPU "interrupt" driver processing service. Other types are for "lossy" communication in which dropped packets of data in exchange for "realtime" or "current" data is acceptable (think a telephone voice call where 'crackle or noise' is acceptable as long as the voice is pseudo-realtime and not delayed). Still other types are for absolutely "reliable" traffic even if it is delayed.
Quite a bit of the wire protocol is encapsulated inside the silicon "chips" which are embedded into the computer motherboard or inside the external hubs and usb devices themselves.
These are connected together with USB cabling to provide service.
There are standards for USB cabling and different capabilites with each type of cabling. But I won't get into those feature here.. since I'm more interested in learning to write a program or driver that opens communications and actually makes use of a usb device.
Within Microsoft Windows is an arrangement between user application and kernel applications where by the User Mode and Kernel Mode programs are written using two different sets of Headers and Libraries. Each has their own set of APIs (application programming interfaces).
For the most part these APIs are C/C++ compatible and most User Mode or Kernel Model programs are written in C or C++. Then compiled using either the SDK for User Mode or DDK for Kernel Mode. Each of these "Development Kits" contains their own "complier" customized and setup to reference the correct set of Headers and Libraries at compile time.
Traditionally Visual Studio was used to create User mode programs and Visual Studio was used to possibly edit Kernel mode programs, however when it came time to compile.. Visual Studio would use its complier to compile User mode programs and Kernel mode programs would have to be compiled manually with the DDK compiler.. this has changed back and forth between Visual Studio for both or separately for User mode programs only.. it generally depends on the era and which Visual Studio product is used.
Windows also includes a general purpose "database" which the User Mode or Kernel Mode programs can access at runtime called the "Registry". Historically evolved from a collection of [INI] files into a unified set of binary files to gain speed of access and to allow the database to grow much larger and faster than an ordinary text file based database would make possible. It also allows a certain obscurity or ofuscation (opaqueness) to the database which was later given.. even an access permission control system to prevent certain entries from being accessed or changed without the proper user permissions. All of this means even the User Mode and Kernel Mode programs have parts of their APIs dedicated to accessing the registry, which they access to make use of dynamic runtime libraries and COM/DCOM runtime objects.
All of that is history and window dressing for the main stage of developing application to access USB devices.
In the early days of windows, even in DOS, there were no USB "drivers". Each program had to initate the USB port and manage the abstracted protocol features the chipsets provided to communicated with USB endpoints which represented devices connected by USB cable.
In time however "Kernel mini-port" drivers were created to manage and "share" access first to USB Host controllers, then USB hubs, and finally USB devices. As this "Stack" of drivers came into being Microsoft sought to make driver writing simpler and faster, as well as less error prone.
So the evolution from "mini-port" drivers was to "device driver frameworks" to assist driver writers in creating drivers based on examples or "templates" which guided them in making similar drivers that had similar features.. like debugging or other features.. so that they could all be treated similarly by the overall operating sytem. -- in particular the jump from 9x (VxD) and NT kernel device drivers, was to the WDM - Windows Device Model kernel mode device drivers. (soon to be replaced by the WDF- Windows Driver Framework)... Which led to frameworks for creating all kinds of device drivers.
Specific to USB however was the establishment of the [winusb.sys] device driver which took over much of the job of older or vendor specific device drivers and co-operated with the central operating system kernel to share and manage the USB [bus] as a common "thing" that might be used simultaneously by many programs at the kernel and user mode levels.
USB is a "shared" communications medium, even if it may appear at times to be a cascading set of point-to-point connections. At any one time the total bandwidth of a singular USB port on the computer may be prioritized or divided out among many USB devices on the virtual "bus" shared by all the connected devices.
So once the WDM framework made device driver writing easier and the shared USB bus management made using multiple USB devices simultaneously possible.
Microsoft set about co-operating with the USB Special Interests Group (SIG) or USB Forum, which had shared interests in "standardizing" groups of similar USB devices and coming up with agreed upon minimal protocols to use these groups of USB devices. They were called USB "classes".. not in the sense that they were abstract Programming classes, but that they shared a common set of designs and features which could be probed and expected to exist, and thus similar drivers with "vendor specific" deviances or functions could be accessed.
The win for Microsoft was they could include [in-the-box] with a new version of Windows both a winusb.sys driver for oddball USB devices that were unique, and "Class" device drivers which would provide certain minimal services for "recognized" USB devices.
The USB devices were "recognized" by a process called discovery or "Plug and Play" detection and device driver loading.
USB devices generally have an established protocol where "descriptors" or "strings" of information can be retreived from a USB device after it is assigned an address on the USB bus.
The assigning of the USB address is a base function of the USB bus driver after a USB device is plugged in and powered up.Once the "Strings" are retrieved a search of the strings returns a PCI Vendor ID "like" unique finger print which identifies the device as a possible member of a device class, and a specific vendors product. Depending on the device drivers registered in the Windows Registry or the INF flat file database an appropriate driver or driver "set" of device driver files will be loaded and start execution on behalf of the device in the Windows memory space, in general these are Kernel mode device drivers of the WDM type, a USB bus manager, device driver and class device driver.
The end result is a User mode program can start up and probe the system device list for a target which represents the USB device it needs to peform its function. And by sending IRB (Input/Output Request Blocks) to the Class driver communicate with the USB device.
IRBs are very low-level however and generally a Class driver has a predefined set of headers and library or APIs for communicating with the USB device it manages.. abstracting away (or simplifying) the level of effort required to write an application that uses the USB device.
The really hard part (I think) about all of this is knowing the history of what came before, so that not only you have perspective, but can also "filter" or "ignore" whispers of irrelevant data .. such as information about a VxD, or about a long deprecated protocol like VfW - Video for Windows, which trying to get a foot hold in the current era can distract you.. or prevent you from choosing the most appropriate API to use for the Class driver your interested in probing and using.
There are "models" within "models" describing both "abstract" representations (or "perfect" idealized models of how things work) and then "real" representations of actual devices which have [some] of the chracteristics of the ideal "model" + plus "extentions" or features that the model does not address, which you then have to figure out how to address. Some Class drivers build in (vendor specific) methods to access these other features.. but some do not.. in which case you may have to consider writing a mini-port driver to co-operate with a Class driver (an extension "plugin") .
The USB forum (or SIG) also describes many of these same things in similar but not identical terms, so that an abstract model in Microsoft documentation may not line up with the description of the same thing in a generic USB forum Spec written with the idea of serving multiple purposes beyond Windows programming.. such as programming for Linux or Apple OS products.
The USB Specs are also [very] hard to read as the knowledge base of the authors is both jargon filled, presumptive and lacking in details, and written "backwards" or "upside down" in that they are written more like legal contracts preceeding object of discussion with adjectives or descriptions "before" refering to what they are actually talking about. In Germaic descendent languages like English, it can be very hard to [overlook] or [ignore] the fact that the document appears to have no purpose or subject matter, until "after" the discourse on the descriptions and actions.. leaving motivation to "finish" reading the Spec document..very difficult to find. (I believe) certain speakers in other languages will have an easier time reading the documents as I have seen similar "speech" patterns in other languages. -- once "consumed" however Germaic readers can generally "re-organize" the material almost subconsciously within their mind.. much as when translating a foreign language internally.. and its easy to "forget" how hard the first reading of the material was to understand.. a certain amount of "faith" or experience in readin RFC or Spec documents may make this easier.. but for the inexperienced or "uninitated" newbie.. this can be a very difficult barrier to overcome.
In the perfect Microsoft Windows programming world. A USB device will have a high level, high functioning Class driver and the end user User Mode Application will have an available "framework" specific to their task.. such as DirectX Direct Show for Video, and the end user will not have to write a device driver, or understand many of the details of how the actual silicon or the device performs its task.. it just appears to do so.. like "magic"
A further "funny" detail is that you should not loose sight of the fact that a USB bus is a negotiation between two independent devices arbiting over communcations and services. The USB device is itself its own computer, with its own operating system (however simple that may be) and thus has its own programming. Often called "firmware", it can have bugs, it can change, and features that were available in one version of the firmware can change or be removed in the next.
Generally the USB descriptors are used as the IUnknown or COM type object feature of "discovery" and "enumeration" or list of available features.
It is through the USB descriptors a USB device provides about itself that Class drivers can setup and expose features of the device to the operating system user mode programs.
In the inital release of a hardware USB device, the firmware may not be 100 percent complete. And the USB descriptors may describe features or functions that are not quite bug free, or even implemented yet.
1/09/2017
CHM, Help 1.x files missing Contents Index Search
CHM - Compiled HTML for Microsoft files can appear damaged or unreadable. But they are not, they are often distributed in multiple "pieces" rather than a "singular" name.chm file in older Microsoft PDK, SDK and DDK documentation. (accidentally) moving only the .chm file can result in missing functions when opening the .chm file for viewing.
For example:
The image has been deliberately "blurred" to protect the rights of the publisher. However the controls and navigation pane to the Left have not been "blurred".
You will notice that The usual [Contents][Index][Search] tabs are "missing" from the tab menu.
Typing "anything" into the [ Type in the keyword to find: ] then [List Topics] is equally useless:
The word "untitled" will be returned over and over in the topics list, and link nowhere.
The problem in this case is the directory contains only "one" file:
C:\doc>
|
\_directx.chm
But the original document directory in the original install folder contained:
C:\sdk documentation>
|
\_directx.chm
\_directx.chi
The "missing" .chi file is in fact an index file, and was intended to "separate" changable information from static information when distributing the files on CDROM. It is described somewhat in this old link to Microsoft HTML Help
When you recover or "move" the .chi file into the same directory as the .chm file it (automatically) indexes "on the fly" and the results are as expected (minus the "blurring" effect I added to the image).
That is the "expected" navigation controls on the Left return and are available again.
Also the "existence" of the .chi file causes a "new" file to be created when the .chm file is opened. In fact the procedure is that as soon as the .chm file is opened a compatible .chi file is searched for in the current directory and then a new .chw file is created if the directory is "writable" - this is described as a combined kwords file.. or "chw"ords file. "k" is often used to mean "Index" file in other CHM contexts.. so this could mean "Compile Help Index Words" or "Compile Help Key Words" to support the Index and Search tabs (without the extra "k").
Its further confusing that [some] in fact [many] files compiled in more recent years, especially by third party software programmers, include the index (inside) the single .chm file.
So those .chm file behave as if the .chi file were included in the current location, but are in fact "standalone".
This change in behavior really makes troubleshooting older documentation harder, especially since Compiled Help documentation (about the CHM format) is somewhat rare.. and the change in Help document formats and ramping up of Security blockades to disable and deprecate older Help file formats. -- there simply isn't a lot of care taken to "learn from the past" and "document for the future".
Note: further online research led to the tacky "political" situation between "Public" chm files and "Private" Internal Microsoft MSDN formats. HTML Help versions 1.x 2.x and 3 or 4,5 were on a very rocky road at the end of the last Century (1999-2000) and after announcing and "using internally" a new version of CHM they basically cancelled and did not deliver. The result was a split or division between versions of CHM 1.x and 2.x (which was never released outside Microsoft). The MSDN Library released on CDROM would use this new "splitted" CHM/CHI/CHW version.. and apparently without formal notice the SDK, DDK documentation.. and perhaps Microsoft Press CDROMs.. but it was never formally documented.
Some people took to reverse engineering the new pseudo-unoffical/official format and came up with tools and "ways" of adding their own .CHM documents to the MSDN versions.. before the later versions of CHM.. so the internal strife were recognized and "patterned" around.. which is nothing new for this era with the company.
The CHM format appears abadonned, but maintained in more and more projects, outside the oversight of Microsoft.. and as they do not maintain much of a corporate history.. perhaps the less involvement and further they get from it the better. But the standard for CHM while not open, or well documented lives on. With only .MD or HTML markup showing a hint at replacing it on GitHub.
For example:
The image has been deliberately "blurred" to protect the rights of the publisher. However the controls and navigation pane to the Left have not been "blurred".
You will notice that The usual [Contents][Index][Search] tabs are "missing" from the tab menu.
Typing "anything" into the [ Type in the keyword to find: ] then [List Topics] is equally useless:
The problem in this case is the directory contains only "one" file:
C:\doc>
|
\_directx.chm
But the original document directory in the original install folder contained:
C:\sdk documentation>
|
\_directx.chm
\_directx.chi
The "missing" .chi file is in fact an index file, and was intended to "separate" changable information from static information when distributing the files on CDROM. It is described somewhat in this old link to Microsoft HTML Help
When you recover or "move" the .chi file into the same directory as the .chm file it (automatically) indexes "on the fly" and the results are as expected (minus the "blurring" effect I added to the image).
That is the "expected" navigation controls on the Left return and are available again.
Also the "existence" of the .chi file causes a "new" file to be created when the .chm file is opened. In fact the procedure is that as soon as the .chm file is opened a compatible .chi file is searched for in the current directory and then a new .chw file is created if the directory is "writable" - this is described as a combined kwords file.. or "chw"ords file. "k" is often used to mean "Index" file in other CHM contexts.. so this could mean "Compile Help Index Words" or "Compile Help Key Words" to support the Index and Search tabs (without the extra "k").
Its further confusing that [some] in fact [many] files compiled in more recent years, especially by third party software programmers, include the index (inside) the single .chm file.
So those .chm file behave as if the .chi file were included in the current location, but are in fact "standalone".
This change in behavior really makes troubleshooting older documentation harder, especially since Compiled Help documentation (about the CHM format) is somewhat rare.. and the change in Help document formats and ramping up of Security blockades to disable and deprecate older Help file formats. -- there simply isn't a lot of care taken to "learn from the past" and "document for the future".
Note: further online research led to the tacky "political" situation between "Public" chm files and "Private" Internal Microsoft MSDN formats. HTML Help versions 1.x 2.x and 3 or 4,5 were on a very rocky road at the end of the last Century (1999-2000) and after announcing and "using internally" a new version of CHM they basically cancelled and did not deliver. The result was a split or division between versions of CHM 1.x and 2.x (which was never released outside Microsoft). The MSDN Library released on CDROM would use this new "splitted" CHM/CHI/CHW version.. and apparently without formal notice the SDK, DDK documentation.. and perhaps Microsoft Press CDROMs.. but it was never formally documented.
Some people took to reverse engineering the new pseudo-unoffical/official format and came up with tools and "ways" of adding their own .CHM documents to the MSDN versions.. before the later versions of CHM.. so the internal strife were recognized and "patterned" around.. which is nothing new for this era with the company.
The CHM format appears abadonned, but maintained in more and more projects, outside the oversight of Microsoft.. and as they do not maintain much of a corporate history.. perhaps the less involvement and further they get from it the better. But the standard for CHM while not open, or well documented lives on. With only .MD or HTML markup showing a hint at replacing it on GitHub.
12/22/2016
DSLAM, homebrewing an ADSL test lab
Trivial pursuits.. I bought a ZyXEL IES-1000 and successfully hypothesized enough to reconfigure and enable it to bridge ADSL traffic between a Cisco 877 adsl router and the ZyXEL ethernet port.
Then used the RASPPPOE third party protocol driver on XP Pro to build an add-hoc Access Concentrator. -- and.. it works.. now I can test various ADSL modems.
The [ Incoming ] connections on XP are usually a single instance of a "listening" daemon per Ethernet interface. Connections "spawn" a new instance of an Incoming connection listed below the daemon with a status of (connected).
When a PPPoE client on the LAN sends out Ethernet PADI-nitiate packets to discover any access concentrator servers over Ethernet broadcast, the "listeners" send a uni-cast reply as a PADO-ffer packet with the servers Ethernet MAC address.. so that the PPPoE client can then uni-cast directly to an (A)ccess (C)oncentrator server and begin to setup a PPP session.
The PPP session then (Authenticates using CHAP) and bargains for privileges and concessions until the two reach an agreement on authentication, tunnel service parameters and TCP/IP addresses for each end of the tunnel.
Then the session spawns a Virtual TCP/IP Interface on both the client and server 'end-points' and assigns those the negotiated IP addresses.
Ethernet is not TCP/IP -- this is "waaay" below that on the OSI scale.. its the original bare bones and knuckles wire protocol of one of the oldest and first networks. ADSL basically "borrows" raw Ethernet.. so it can take stabs in the dark and make end to end connections on top of an ATM "circuit". An ATM circuit is really more or less like a USB or Serial connection, its bidirectional and carries signals back and forth.. with some ability to prioritize signals if you use VPI and VCI and PVCs.. which most people do not.
Then used the RASPPPOE third party protocol driver on XP Pro to build an add-hoc Access Concentrator. -- and.. it works.. now I can test various ADSL modems.
The [ Incoming ] connections on XP are usually a single instance of a "listening" daemon per Ethernet interface. Connections "spawn" a new instance of an Incoming connection listed below the daemon with a status of (connected).
When a PPPoE client on the LAN sends out Ethernet PADI-nitiate packets to discover any access concentrator servers over Ethernet broadcast, the "listeners" send a uni-cast reply as a PADO-ffer packet with the servers Ethernet MAC address.. so that the PPPoE client can then uni-cast directly to an (A)ccess (C)oncentrator server and begin to setup a PPP session.
The PPP session then (Authenticates using CHAP) and bargains for privileges and concessions until the two reach an agreement on authentication, tunnel service parameters and TCP/IP addresses for each end of the tunnel.
Then the session spawns a Virtual TCP/IP Interface on both the client and server 'end-points' and assigns those the negotiated IP addresses.
Ethernet is not TCP/IP -- this is "waaay" below that on the OSI scale.. its the original bare bones and knuckles wire protocol of one of the oldest and first networks. ADSL basically "borrows" raw Ethernet.. so it can take stabs in the dark and make end to end connections on top of an ATM "circuit". An ATM circuit is really more or less like a USB or Serial connection, its bidirectional and carries signals back and forth.. with some ability to prioritize signals if you use VPI and VCI and PVCs.. which most people do not.
The whole setup and connection from ATM to Ethernet to PPP to TCP/IP was relatively easy. The hard part was recognizing that the ADSL ports on the DSLAM were "tagged" or enabled to be members of a default Ethernet VLAN, which was switched off.
The net effect was I could see "PADI(client).. PADO(server).. PADI(client).. PADO(server)" while using wireshark to monitor the XP ethernet port that was acting as the access concentrator server.
But the client never seemed to "see" the servers "PADOffer reply".. once the VLAN was "enabled" replies traveling from the ZyXEL Ethernet management port started getting back to the ADSL ports.. and the connection pretty much immediately locked on like a snapper turtle and wouldn't let go.
After that the Cisco or the ZyXEL seemed to be sending "keep-alive" echo and reply requests to monitor each side of the ATM connection.
[Concept-wise] it also took a moment to "think" about how ADSL works.
The ADSL modem and ADSL DSLAM (DSL A-ccess M-ultiplier) are essentially "standalone" ATM switches. Each has an Ethernet port (ingress/egress) point, both on the customer DSL modem side and on the DSLAM modem side. As far as the customer and provider are concerned the ADSL "cloud" they plug into is "magic".
The ADSL part just fires up and starts blasting "tones" over a dedicated circuit looking for a partner.
A customers phone line that is "provisioned" for DSL is always ready to respond to those tones which are mostly beyond the range of human hearing. And normal old-fashioned phones are fitted with a low-pass filter to make sure you can't hear them.. and make sure the low frequency human voices can't interfere with the higher frequency DSL tones.
Its all slightly similar to USB signaling except USB signals are much higher frequency and more complex. DSL technology was developed in the 1990's primarily for carrying digital television signals.. but that didn't work out so well.. so it got repurposed for carrying digital data. Initially the chips that encapsulated ATM communications were expensive.. but over nearly 30 years they have come down in cost quite a bit due to volume discounting.
Really old-fashioned acoustic modems worked in the much lower frequency voice range and could work sending audible (to humans) "tones" over the switched voice lines of ancient central offices.
They could also leverage the switch voice line "phone number" database for addressing both humans, fax machines and destinations listening for data connections (like bulletin boards or Internet service providers).
The thinking back then was there was no need for high data rates and the infrastructure was too costly to replace.. that changed over the years.. but also the aging and failing voice lines were poor conductors of reliable communications. The longer the wire the worse the ability to carry high speed or reliable signals.
In any event -- The connection from ADSL modem to ADSL switch (or DSLAM) had to be setup first. Its a "bridge" because it [bridges] two types of travel (or communications) in this case it [bridges] Ethernet networks so that they appear as (one) broadcast zone.
That is an Ethernet station on one end with a MAC address can [shout] (or broadcast) a message to all other stations on the entire broadcast zone.. including the ADSL switch (or DSLAM) side.
A PPPoE server called an [Access Concentrator] can then listen for and respond to a request for service and "Offer" its services to the ADSL connected Ethernet "client". -- they then begin a PPP setup conversation and turn that into a PPP "established session" over Ethernet.
PPP "bridges" TCP/IP connections.. and the PPP client on the ADSL modem "Creates" a TCP/IP virtual interface and assigns it the TCP/IP address the two PPPoE speakers agreed upon.
At this point the ADSL modem has become an end-point on the Internet and it can go on to perform NAT or Firewall protection and even act as a DHCP server to hand out additional or NAT'ted TCP/IP addresses to clients on its local private network.
Of course the ADSL modem could have simply acted as a [bridge] for Ethernet traffic and permitted or enabled a different computer connected to its Ethernet port (broadcast zone) to perform PPPoE all by itself and establish a similar set of features for the local customer side LAN.. but that's a minor design choice.
A simple Ping from the XP concentrator confirmed both ends of the connection were responding.
12/20/2016
RRAS/IAS, fails to start service Error 340
Its always bothered me that Win2003 and XP had a RRAS (Routing and Remote Access Service) that was frequently broken. Its not the same thing as ICS (Internet Connection Service). The usual failure comes after removing software or running a Registry cleaner. Then the RRAS service fails to start with error 340. Here is how to fix that.
First the failure mode is (attempting to start "Routing and Remote Access") from the [services.msc] mmc snapi, the service briefly starts then stops and throws a dialog referring to Service specific error 340
The [System] Event log records:
If you enable "tracing" you can get a more detailed break down by the service, its helpers and it dependent services.
Enabling logs for RRAS - essentially a netsh command to "enable/disable" causes the logs to "appear" in the C:\WINDOWS\tracing directory.
Then when you try to start the "routing and remote access service" again, it will create new log files with more details as to status and why certain things fail (in detail). Fail and Detail, seem like a Yin and Yang don't they?
The logs are in plain text and easily readable if somewhat undocumented.
In general however they refer to services and dependent services, their calls (successful or not) and somewhat verbosely why they succeed, or why they fail.
RRAS for example has depedencies on NetbiosGroup and the RPC service, but also the Remote Access Connection Manager.. and more importantly the IAS authentication database.
All of these have more familar names and achieved their wild and wacky names through history and marketing strategy to avoid tripping over possible legal issues. Or simply to "sound" unique and different while implementing common everyday protocols used across the Internet. Balmy "Peanut butter SOAP" sounds better than simply lard butter bar.
For me IAS on XP is usually the problem.
IAS is not the "full daemon" service it is on Windows 2003 Server, its a stripped down ODBC jet engine backed microsoft access database file in the C:\Windows\system32\IAS directory which holds a few tables. It takes the place of a general purpose RADIUS authentication daemon and backend and can interface with the local accounts to validate and authorize incoming users making connection attempts. Like all file based databases its vulberable to attack and damage by "outside" forces lurking on the hard disk and in the greater operating system. Occasionally it needs to be restored or "reset" back to pristine condition from a copy of the original .mdb files that come with the WindowsXP installer on the cdrom.
MMC snapins for Windows2000 worked to manage the RRAS service on XP up through XP SP2 but after SP3 stopped working, so your reduced to using netshell or netsh commands, or third party tools to manage a "Remote Access Concentrator" or as XP calls it the "Routing and Remote Access Service". An mmc snapin is available for Win2003 but will not work on XP even if it copied over to an XP system. XPLite is a tool from Australia which appears to be able to disable the Windows File Protection system so that you can remove and reinstall RRAS.. but takes a lot of work, intuition and luck.. and does not address "missing" or corrupt registry keys.. or unregistered DLLs due to indirect software withdrawls from the system.
So first IAS may need to have its C:\WINDOWS\system32\ias default dnary.mdb and ias.mdb files restored from the Windows XP install media.. use the Expand tool basically to unzip them and replace them, carefully moving the suspect corrupt ones to a safe backup location.
Next "missing registry keys and values"
This has been posted in many places on the internet, but I put this in a Fixme.reg file and saved it, dbl clicked on it and merged it into the existing registry (mostly its about fixing IAS 'record store' support for RRAS):
You then need to "re-register" a DLL which may have become unbound by some other software removal, which is referenced in the REG patch above. (as far as I can tell its the SQLquery tool that RRAS needs to get at the records in the database tables in the .mdb files)
The registry branch for the
After the above, and a reboot for good measure.
You can RT Click [My Network Places] > Properties
Then DB Click [New Connection Wizard]
May need to be reset to a known condition, this is mine (its more or less an out of the box example):
You need to backup your existing registry branch (for RemoteAccess) or perform a system restore "point" (or backup) in case this doesn't work for you and you want to back out the changes.
First the failure mode is (attempting to start "Routing and Remote Access") from the [services.msc] mmc snapi, the service briefly starts then stops and throws a dialog referring to Service specific error 340
The [System] Event log records:
If you enable "tracing" you can get a more detailed break down by the service, its helpers and it dependent services.
Enabling logs for RRAS - essentially a netsh command to "enable/disable" causes the logs to "appear" in the C:\WINDOWS\tracing directory.
“netsh ras set tracing * enabled”
“netsh ras set tracing * disabled”
Then when you try to start the "routing and remote access service" again, it will create new log files with more details as to status and why certain things fail (in detail). Fail and Detail, seem like a Yin and Yang don't they?
The logs are in plain text and easily readable if somewhat undocumented.
In general however they refer to services and dependent services, their calls (successful or not) and somewhat verbosely why they succeed, or why they fail.
RRAS for example has depedencies on NetbiosGroup and the RPC service, but also the Remote Access Connection Manager.. and more importantly the IAS authentication database.
All of these have more familar names and achieved their wild and wacky names through history and marketing strategy to avoid tripping over possible legal issues. Or simply to "sound" unique and different while implementing common everyday protocols used across the Internet. Balmy "Peanut butter SOAP" sounds better than simply lard butter bar.
For me IAS on XP is usually the problem.
IAS is not the "full daemon" service it is on Windows 2003 Server, its a stripped down ODBC jet engine backed microsoft access database file in the C:\Windows\system32\IAS directory which holds a few tables. It takes the place of a general purpose RADIUS authentication daemon and backend and can interface with the local accounts to validate and authorize incoming users making connection attempts. Like all file based databases its vulberable to attack and damage by "outside" forces lurking on the hard disk and in the greater operating system. Occasionally it needs to be restored or "reset" back to pristine condition from a copy of the original .mdb files that come with the WindowsXP installer on the cdrom.
MMC snapins for Windows2000 worked to manage the RRAS service on XP up through XP SP2 but after SP3 stopped working, so your reduced to using netshell or netsh commands, or third party tools to manage a "Remote Access Concentrator" or as XP calls it the "Routing and Remote Access Service". An mmc snapin is available for Win2003 but will not work on XP even if it copied over to an XP system. XPLite is a tool from Australia which appears to be able to disable the Windows File Protection system so that you can remove and reinstall RRAS.. but takes a lot of work, intuition and luck.. and does not address "missing" or corrupt registry keys.. or unregistered DLLs due to indirect software withdrawls from the system.
So first IAS may need to have its C:\WINDOWS\system32\ias default dnary.mdb and ias.mdb files restored from the Windows XP install media.. use the Expand tool basically to unzip them and replace them, carefully moving the suspect corrupt ones to a safe backup location.
Next "missing registry keys and values"
This has been posted in many places on the internet, but I put this in a Fixme.reg file and saved it, dbl clicked on it and merged it into the existing registry (mostly its about fixing IAS 'record store' support for RRAS):
Very Important!
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{6BC096C4-0CE6-11D1-BAAE-00C04FC2E20D}]
"AppID"="{A5CEB593-CCC3-486B-AB91-9C5C5ED4C9E1}"
@="IAS OLE-DB Data Store"
[HKEY_CLASSES_ROOT\CLSID\{6BC096C4-0CE6-11D1-BAAE-00C04FC2E20D}\InprocServer32]
"ThreadingModel"="Free"
@="C:\\WINDOWS\\System32\\iasrecst.dll"
[HKEY_CLASSES_ROOT\CLSID\{6BC09693-0CE6-11D1-BAAE-00C04FC2E20D}]
"AppID"="{A5CEB593-CCC3-486B-AB91-9C5C5ED4C9E1}"
@="IAS Netsh Jet Helper"
[HKEY_CLASSES_ROOT\CLSID\{6BC09693-0CE6-11D1-BAAE-00C04FC2E20D}\InprocServer32]
"ThreadingModel"="Free"
@="C:\\WINDOWS\\System32\\iasrecst.dll"
[HKEY_CLASSES_ROOT\CLSID\{6BC09692-0CE6-11D1-BAAE-00C04FC2E20D}]
"AppID"="{A5CEB593-CCC3-486B-AB91-9C5C5ED4C9E1}"
@="IAS Attribute Dictionary"
[HKEY_CLASSES_ROOT\CLSID\{6BC09692-0CE6-11D1-BAAE-00C04FC2E20D}\InprocServer32]
"ThreadingModel"="Free"
@="C:\\WINDOWS\\System32\\iasrecst.dll"
You then need to "re-register" a DLL which may have become unbound by some other software removal, which is referenced in the REG patch above. (as far as I can tell its the SQLquery tool that RRAS needs to get at the records in the database tables in the .mdb files)
regsvr32 C:\WINDOWS\System32\iasrecst.dllNot done Yet!
The registry branch for the
HKLM\System\ControlSet001\Services\RemoteAccessI put a copy of mine at the bottom of this blog post.
After the above, and a reboot for good measure.
You can RT Click [My Network Places] > Properties
Then DB Click [New Connection Wizard]
Get a list of available Inbound Connectors, Ethernet Cards, Modems Ect..
Choose whether to Modify the Firewall to allow VPN connections (I think its IPSEC)
Pick existing Windows user accounts to Auth Incoming Connection Attempts, or create new ones
Pick a networking stack over which to conduct the Auth exchange
And complete the RRAS connection type
The new type shows up in RT Click > Properties for [Network Connections]
The Properties of the New Connection type reveal its configuration settings
You need to backup your existing registry branch (for RemoteAccess) or perform a system restore "point" (or backup) in case this doesn't work for you and you want to back out the changes.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess]
"Type"=dword:00000020
"Start"=dword:00000003
"ErrorControl"=dword:00000001
"ImagePath"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\
74,00,25,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,73,\
00,76,00,63,00,68,00,6f,00,73,00,74,00,2e,00,65,00,78,00,65,00,20,00,2d,00,\
6b,00,20,00,6e,00,65,00,74,00,73,00,76,00,63,00,73,00,00,00
"DisplayName"="Routing and Remote Access"
"DependOnService"=hex(7):52,00,70,00,63,00,53,00,53,00,00,00,00,00
"DependOnGroup"=hex(7):4e,00,65,00,74,00,42,00,49,00,4f,00,53,00,47,00,72,00,\
6f,00,75,00,70,00,00,00,00,00
"ObjectName"="LocalSystem"
"Description"="Offers routing services to businesses in local area and wide area network environments."
@=""
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Accounting]
"AccountSessionIdStart"=dword:00000003
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Accounting\Providers]
"ActiveProvider"="{1AA7F846-C7F5-11D0-A376-00C04FC9DA04}"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Accounting\Providers\{1AA7F840-C7F5-11D0-A376-00C04FC9DA04}]
"ConfigClsid"="{1AA7F840-C7F5-11D0-A376-00C04FC9DA04}"
"DisplayName"="RADIUS Accounting"
"Path"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,72,00,\
61,00,73,00,72,00,61,00,64,00,2e,00,64,00,6c,00,6c,00,00,00
"ProviderTypeGUID"="{76560D80-2BFD-11d2-9539-3078302C2030}"
"VendorName"="Microsoft"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Accounting\Providers\{1AA7F846-C7F5-11D0-A376-00C04FC9DA04}]
"ConfigClsid"=""
"DisplayName"="Windows Accounting"
"Path"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
70,00,72,00,64,00,64,00,6d,00,2e,00,64,00,6c,00,6c,00,00,00
"ProviderTypeGUID"="{76560D81-2BFD-11d2-9539-3078302C2030}"
"VendorName"="Microsoft"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Authentication]
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Authentication\Providers]
"ActiveProvider"="{1AA7F841-C7F5-11D0-A376-00C04FC9DA04}"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Authentication\Providers\{1AA7F83F-C7F5-11D0-A376-00C04FC9DA04}]
"ConfigClsid"="{1AA7F83F-C7F5-11D0-A376-00C04FC9DA04}"
"DisplayName"="RADIUS Authentication"
"Path"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,72,00,\
61,00,73,00,72,00,61,00,64,00,2e,00,64,00,6c,00,6c,00,00,00
"VendorName"="Microsoft"
"ProviderTypeGUID"="{76560D00-2BFD-11d2-9539-3078302C2030}"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Authentication\Providers\{1AA7F841-C7F5-11D0-A376-00C04FC9DA04}]
"ConfigClsid"=""
"DisplayName"="Windows Authentication"
"Path"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
70,00,72,00,64,00,64,00,6d,00,2e,00,64,00,6c,00,6c,00,00,00
"VendorName"="Microsoft"
"ProviderTypeGUID"="{76560D01-2BFD-11d2-9539-3078302C2030}"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\DemandDialManager]
"DllPath"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\
74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,\
00,70,00,72,00,64,00,64,00,6d,00,2e,00,64,00,6c,00,6c,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Interfaces]
"Stamp"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Interfaces\0]
"InterfaceName"="Loopback"
"Type"=dword:00000005
"Enabled"=dword:00000001
"Stamp"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Interfaces\0\Ip]
"ProtocolId"=dword:00000021
"InterfaceInfo"=hex:01,00,00,00,68,00,00,00,03,00,00,00,05,00,ff,ff,38,00,00,\
00,00,00,00,00,40,00,00,00,04,00,ff,ff,04,00,00,00,01,00,00,00,40,00,00,00,\
07,00,ff,ff,10,00,00,00,01,00,00,00,48,00,00,00,00,00,00,00,01,00,00,00,00,\
00,00,00,58,02,c2,01,08,07,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Interfaces\1]
"InterfaceName"="Internal"
"Type"=dword:00000004
"Enabled"=dword:00000001
"Stamp"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Interfaces\1\Ip]
"ProtocolId"=dword:00000021
"InterfaceInfo"=hex:01,00,00,00,68,00,00,00,03,00,00,00,05,00,ff,ff,38,00,00,\
00,00,00,00,00,40,00,00,00,04,00,ff,ff,04,00,00,00,01,00,00,00,40,00,00,00,\
07,00,ff,ff,10,00,00,00,01,00,00,00,48,00,00,00,00,00,00,00,01,00,00,00,00,\
00,00,00,58,02,c2,01,08,07,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Interfaces\2]
"InterfaceName"="{27A054EB-CD1B-4B1F-9155-4870F6D2F7F0}"
"Type"=dword:00000003
"Enabled"=dword:00000001
"Stamp"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Interfaces\2\Ip]
"ProtocolId"=dword:00000021
"InterfaceInfo"=hex:01,00,00,00,68,00,00,00,03,00,00,00,05,00,ff,ff,38,00,00,\
00,00,00,00,00,40,00,00,00,04,00,ff,ff,04,00,00,00,01,00,00,00,40,00,00,00,\
07,00,ff,ff,10,00,00,00,01,00,00,00,48,00,00,00,00,00,00,00,01,00,00,00,00,\
00,00,00,58,02,c2,01,08,07,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Interfaces\3]
"InterfaceName"="{2997EDE8-4DF4-4409-BF1D-E35E6F580C2F}"
"Type"=dword:00000003
"Enabled"=dword:00000001
"Stamp"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Interfaces\3\Ip]
"ProtocolId"=dword:00000021
"InterfaceInfo"=hex:01,00,00,00,68,00,00,00,03,00,00,00,05,00,ff,ff,38,00,00,\
00,00,00,00,00,40,00,00,00,04,00,ff,ff,04,00,00,00,01,00,00,00,40,00,00,00,\
07,00,ff,ff,10,00,00,00,01,00,00,00,48,00,00,00,00,00,00,00,01,00,00,00,00,\
00,00,00,58,02,c2,01,08,07,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Parameters]
"RouterType"=dword:00000001
"ServerFlags"=dword:00802702
"ServiceDll"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\
00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\
6d,00,70,00,72,00,64,00,69,00,6d,00,2e,00,64,00,6c,00,6c,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Parameters\AccountLockout]
"MaxDenials"=dword:00000000
"ResetTime (mins)"=dword:00000b40
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Parameters\AppleTalk]
"EnableIn"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Parameters\Ip]
"AllowClientIpAddresses"=dword:00000000
"AllowNetworkAccess"=dword:00000001
"EnableIn"=dword:00000001
"IpAddress"="0.0.0.0"
"IpMask"="0.0.0.0"
"UseDhcpAddressing"=dword:00000001
"EnableNetbtBcastFwd"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Parameters\Ip\StaticAddressPool]
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Parameters\Ip\StaticAddressPool\0]
"From"=dword:00000000
"To"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Parameters\Ipx]
"EnableIn"=dword:00000001
"AcceptRemoteNodeNumber"=dword:00000001
"AllowNetworkAccess"=dword:00000001
"AutoWanNetAllocation"=dword:00000001
"FirstWanNet"=dword:00000000
"GlobalWanNet"=dword:00000001
"LastWanNet"=dword:00000000
"WanNetPoolSize"=dword:000003e8
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Parameters\Nbf]
"EnableIn"=dword:00000001
"AllowNetworkAccess"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Performance]
"Open"="OpenRasPerformanceData"
"Close"="CloseRasPerformanceData"
"Collect"="CollectRasPerformanceData"
"Library"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\
74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,72,\
00,61,00,73,00,63,00,74,00,72,00,73,00,2e,00,64,00,6c,00,6c,00,00,00
"First Counter"=dword:000007de
"First Help"=dword:000007df
"Last Help"=dword:00000805
"Last Counter"=dword:00000804
"WbemAdapFileSignature"=hex:b0,b0,d7,90,5a,c7,1b,c2,78,f1,7f,45,5e,18,26,11
"WbemAdapFileTime"=hex:00,a0,a1,10,27,9e,c8,01
"WbemAdapFileSize"=dword:00002e00
"WbemAdapStatus"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy]
"ProductDir"="C:\\WINDOWS\\system32\\IAS"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline]
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\01]
@="IAS.ProxyPolicyEnforcer"
"Requests"="0 1 2"
"Responses"="0 1 2 3 4"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\02]
@="IAS.NTSamNames"
"Providers"="1"
"Requests"="0"
"Responses"="0 1 3"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\03]
@="IAS.BaseCampHost"
"Requests"="0 1"
"Responses"="0 1 2 4"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\04]
@="IAS.RadiusProxy"
"Providers"="2"
"Responses"="0"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\05]
@="IAS.NTSamAuthentication"
"Providers"="1"
"Requests"="0"
"Responses"="0"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\06]
@="IAS.AccountValidation"
"Providers"="1"
"Requests"="0"
"Responses"="0 1"
"Reasons"="33"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\07]
@="IAS.PolicyEnforcer"
"Providers"="1"
"Requests"="0"
"Responses"="0 1 3"
"Reasons"="33"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\08]
@="IAS.NTSamPerUser"
"Providers"="1"
"Requests"="0"
"Responses"="0 1 3"
"Reasons"="33"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\09]
@="IAS.EAP"
"Providers"="1"
"Requests"="0 2"
"Responses"="0"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\10]
@="IAS.URHandler"
"Providers"="0 1"
"Requests"="0 2"
"Responses"="0 1"
"Reasons"="33"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\11]
@="IAS.ChangePassword"
"Providers"="1"
"Requests"="0"
"Responses"="0 1"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\12]
@="IAS.AuthorizationHost"
"Requests"="0 1 2"
"Responses"="0 1 2 4"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\13]
@="IAS.Accounting"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Policy\Pipeline\14]
@="IAS.MSChapErrorReporter"
"Providers"="0 1"
"Requests"="0"
"Responses"="2"
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\RouterManagers]
"Stamp"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\RouterManagers\Ip]
"ProtocolId"=dword:00000021
"GlobalInfo"=hex:01,00,00,00,80,00,00,00,02,00,00,00,03,00,ff,ff,08,00,00,00,\
01,00,00,00,30,00,00,00,06,00,ff,ff,3c,00,00,00,01,00,00,00,38,00,00,00,00,\
00,00,00,00,00,00,00,01,00,00,00,07,00,00,00,02,00,00,00,01,00,00,00,03,00,\
00,00,0a,00,00,00,16,27,00,00,03,00,00,00,17,27,00,00,05,00,00,00,12,27,00,\
00,07,00,00,00,0d,00,00,00,6e,00,00,00,08,00,00,00,78,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00
"DLLPath"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\
74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,69,\
00,70,00,72,00,74,00,72,00,6d,00,67,00,72,00,2e,00,64,00,6c,00,6c,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\RoutingTableManager]
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\RoutingTableManager\Instance 00000]
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\RoutingTableManager\Instance 00000\AddressFamily 00002]
"AddressSize"=dword:00000004
"ViewsSupported"=dword:00000003
"MaxChangeNotifyRegistrations"=dword:00000010
"MaxOpaqueInfoPointers"=dword:00000005
"MaxNextHopsInRoute"=dword:00000003
"MaxHandlesReturnedInEnum"=dword:00000019
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Security]
"Security"=hex:01,00,14,80,90,00,00,00,9c,00,00,00,14,00,00,00,30,00,00,00,02,\
00,1c,00,01,00,00,00,02,80,14,00,ff,01,0f,00,01,01,00,00,00,00,00,01,00,00,\
00,00,02,00,60,00,04,00,00,00,00,00,14,00,fd,01,02,00,01,01,00,00,00,00,00,\
05,12,00,00,00,00,00,18,00,ff,01,0f,00,01,02,00,00,00,00,00,05,20,00,00,00,\
20,02,00,00,00,00,14,00,8d,01,02,00,01,01,00,00,00,00,00,05,0b,00,00,00,00,\
00,18,00,fd,01,02,00,01,02,00,00,00,00,00,05,20,00,00,00,23,02,00,00,01,01,\
00,00,00,00,00,05,12,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\RemoteAccess\Enum]
"0"="Root\\LEGACY_REMOTEACCESS\\0000"
"Count"=dword:00000001
"NextInstance"=dword:00000001
Subscribe to:
Posts (Atom)