FBWF and Registry Filter (Changing IP Address)
Bingo500
I installed a XPE on a flash drive with the FBWF, and all seams to
work.
Now I wanted to extend with the registry filter to be able to change
the IP address without
rebooting twice. I added some more Monitored Keys (System
\CurrentControlSet\Services\Tcpip\Parameters\Interfaces,
System\CurrentControlSet\Services\{20027EA1-D9D4-41B0-9D92-
F12B0527B0CB})
The Keys are set to the new IP Address when changing through the TCPIP-
Properties Dialog.
But after a reboot the new IP address is seen in the property dialog
and the netsh interface ip,
but with ipconfig my "old" IP address is assigned - I cannot find this
old IP address in the registry. What have I done wrong, or is there
another key that I have to monitor.
Thanks a lot for any help
Best regards
Klaus
KM
Hmm.. The same registry modification trick worked ok for me on heavy XPe image (as well as XP Pro) and on really small Minlogon
based XPe image as well. The ipconfig always returned (showed) the right IP address after reboot. That way I would easy change the
IP.
However, never tried to make the key persistent with Registry Filter.
Just to make sure you are not experiencing problems because of other missing components, if you disable EWF, does the registry
modification changes the IP properly on your system (does the ipconfig shows the right IP after reboot?).
Also, what IP you can ping after reboot - old or new?
--
=========
Regards,
KM
Bingo500
thanks for the response.
I do not change the IP-Address through the Registry I only use the
Property Editor in the Network settings, but I can see that the
Registry get´s changed after applying the settings.
Of course with disabled FBWF it´s working with the ipconfig and netsh.
Best regards
Klaus
KM
Either way, if you change the reg.value directly or change it with TCPIP GUI, it works well without the filter on.
Let me ask you this.
Did you make sure the GUIDs match for the keys you set for the Registry Filter to monitor?
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{<Interface GUID>}],"IPAddress"
and
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{<Interface GUID>}\Parameters\Tcpip],"IPAddress"
From your original post it is hard to get what exactly keys you are monitoring.
--
=========
Regards,
KM
"Bingo500" <klaus-...@machx.de> wrote in message news:1179505169.8...@u30g2000hsc.googlegroups.com...
Hi KM,
thanks for the response.
I do not change the IP-Address through the Registry I only use the
Property Editor in the Network settings, but I can see that the
Registry get愀 changed after applying the settings.
Of course with disabled FBWF it愀 working with the ipconfig and netsh.
Best regards
Klaus
Bingo500
thanks again.
Yes the settings seams to be correct. If I search through the whole
regsitry after reboot,
I only can find the "new" IP-Address. There is no match for the "old"
one, but the ipconfig
connects to the "old" one while the TCPIP GUI displays the "new" one.
Is there perhaps another to monitor which saves the IP for example
binary, or as a word,...
Regards
Klaus
On 18 Mai, 22:30, "KM" <konstmor@nospam_yahoo.com> wrote:
> Klaus,
>
> Either way, if you change the reg.value directly or change it with TCPIP GUI, it works well without the filter on.
>
> Let me ask you this.
> Did you make sure the GUIDs match for the keys you set for the Registry Filter to monitor?
>
> [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{<Interface GUID>}],"IPAddress"
> and
> [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{<Interface GUID>}\Parameters\Tcpip],"IPAddress"
>
> From your original post it is hard to get what exactly keys you are monitoring.
> --
> =========
> Regards,
> KM
>
> "Bingo500" <klaus-buc...@machx.de> wrote in messagenews:1179505169.8...@u30g2000hsc.googlegroups.com...
>
> Hi KM,
>
> thanks for the response.
> I do not change the IP-Address through the Registry I only use the
> Property Editor in the Network settings, but I can see that the
> Registry get´s changed after applying the settings.
> Of course with disabled FBWF it´s working with the ipconfig and netsh.
>
> Best regards
> Klaus
KM
I spent a little bit more time on the issue and got some results.
First I created an image where I could perfectly repro the problem in a similar setup (Minlogon, netsh, EWF, RegFilter). Then I
debugged some system stacks to understand what's going on there when we change the IP with the RegFilter on and set to monitor the
keys I mentioned earlier. (I picked up EWF vs FBWF to simplify the debugging, having FBWF there won't change the picture)
I must admit the result was a bit surprising to me. Despite the fact that the behavior of the protected system with IP changed and
rebooted was quite strange - no sync in the results from ipconfig.exe tool and "netsh interface ip show address" command (the same
as you do with TCPIP GUI) - the source of the problem was not in the Tcpip stack or the registry keys picked up for the monitoring.
The tcpip driver (or a driver from the ipv4 stack) indeed reads the network adapters info into a buffer (link list) at
initialization off the registry Tcpip\Interfaces key. This, of course, includes the IP addresses. When you do "ipconfig /all" it
doesn't really go into the registry again but rather queries the driver for that info stored in the cache (buffer). While the netsh
commands are more "dynamic" and will scan and return the results from the registry.
It is important to understand that RegFilter doesn't make the monitored keys transparent to the registry hives. The RegFilter rather
applies the new registry values - the values that were saved in the monitored keys on the protected system volume - to the image's
registry hives at the next boot time. Some time during the driver init it loads the ramdisk and reads the files on it. Then it sets
the actual values in registry to whatever values it reads from the file contents on ramdisk.
The tcpip driver will populate the internal stack buffer very early during the system boot. Looks like the initialization actually
happens before the RegFilter is loaded. This leads to the Tcpip structures populated with the old data but the registry info already
reflects the new data (laid out by the RegFilter) after the boot. So we end up with the IP addresses reported out of sync between
the ipconfig and the registry.
To summarize the above, the real problem there seems to be that the Regfilter and one of the drivers from Tcpip stack belong to the
same driver load group. Without the RegFilter enabled the IP would be changed properly (assuming the change can be flushed). This
fact is extremely easy to prove with the following simple experiment.
Forgot for a minute about the RegFilter. In fact remove the Tcpip related registry paths from its MonitorKeys branch, commit EWF and
gracefully shutdown the image (now the RegFilter doesn't "unprotect" the tcpip keys). Load up the image SYSTEM hive offline (open it
with a regedit on a XP Pro machine). Go to the
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{<Interface GUID>}] key and modify the value of the
"IPAddress" property there. Unload the hive and boot to the embedded image and verify that the address has changed and is in sync
between ipconfig and netsh results (or GUI). Note that you don't even have to mess with the
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{<Interface GUID>}\Parameters\Tcpip] key as it will be automatically updated
during the boot (tcpip driver does that at the init time).
It is also easy to confirm with a hex editor that the ramdisk image from the runtime contains the new registry value (new IP
address) but the system registry hive has the old one (and this is ok when you think about the Regfilter architecture and design).
At this point I don't have a workaround for the Tcpip issue. Changing the loading order or adding extra dependencies for the Tcpip
driver to delay its load until RegFilter is loaded didn't help so there is probably some other drivers I'm missing from the picture
that may interfere with the Tcpip parameters in registry at the boot time. If I figure it out, I'll post the results here.
Note that the Domain Secret Key and TSCAL issues were "easier" to fix for Microsoft with the RegFilter approach since those keys are
only read late the boot process (by Winlogon and Terminal Services).
--
=========
Regards,
KM
"Bingo500" <klaus-...@machx.de> wrote in message news:1179526631.9...@l77g2000hsb.googlegroups.com...
Bingo500
wow thank you very much. (totally cracy, that was really much work for
you.)
Did not hoped that someone looks so deep into this issue, in spite a
very good
solution seams not to be possible.
I already made a workaround in commiting the whole Registry when IP
changed.
This seams to work, but of course not my prefered solution.
(But I think the customers will not change it every day :-))
Again thank you very very much.
Best regards
Klaus
> [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{<Interface GUID>}] key and modify the value of the
> "IPAddress" property there. Unload the hive and boot to the embedded image and verify that the address has changed and is in sync
> between ipconfig and netsh results (or GUI). Note that you don't even have to mess with the
> [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{<Interface GUID>}\Parameters\Tcpip] key as it will be automatically updated
> during the boot (tcpip driver does that at the init time).
>
> It is also easy to confirm with a hex editor that the ramdisk image from the runtime contains the new registry value (new IP
> address) but the system registry hive has the old one (and this is ok when you think about the Regfilter architecture and design).
>
> At this point I don't have a workaround for the Tcpip issue. Changing the loading order or adding extra dependencies for the Tcpip
> driver to delay its load until RegFilter is loaded didn't help so there is probably some other drivers I'm missing from the picture
> that may interfere with the Tcpip parameters in registry at the boot time. If I figure it out, I'll post the results here.
>
> Note that the Domain Secret Key and TSCAL issues were "easier" to fix for Microsoft with the RegFilter approach since those keys are
> only read late the boot process (by Winlogon and Terminal Services).
>
> --
> =========
> Regards,
> KM
>
> "Bingo500" <klaus-buc...@machx.de> wrote in messagenews:1179526631.9...@l77g2000hsb.googlegroups.com...
> > Klaus- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -
KM
Yes, I agree. Changing static IP is not a frequent operation and you can get away with committing the entire SYSTEM hive (FBWF) or
even the volume (EWF).
The downside of such workaround is that you may be committing some user data that you'd rather want to discard. Typically a reboot
helps with such.
Looks like last night I wasn't careful in playing with the driver load order and missed the right value. With the following value
monitored by the RegFilter:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfac苟s\{<Interface GUID>}]
Please try to change the following value for the Tcpip driver:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip],"Start"=dword:2
That will put the driver in the auto-start group (started by the service control manager) instead of the system started (kernel or
loader started).
This is a pretty safe change unless you've got some custom drivers in your image that demand the network connectivity (IP) very
early at the system boot.
With the changes above committed, you can try to change the IP and reboot (without an extra commit) and the IP should be the correct
one reported by the netsh (or GUI) and the ipconfig as well. At least this is what I am seeing working here.
Always better to get some sleep and start debugging fresh! :-)
Btw, the above change confirms the theory I described earlier.
--
=========
Regards,
KM
"Bingo500" <klaus-...@machx.de> wrote in message news:1179589588.0...@p77g2000hsh.googlegroups.com...
Hi KM,
> [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfac苟s\{<Interface GUID>}] key and modify the value of the
> > [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfac限es\{<Interface GUID>}],"IPAddress"
> > and
> > [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{<Interface GUID>}\Parameters\Tcpip],"IPAddress"
>
> > From your original post it is hard to get what exactly keys you are monitoring.
> > --
> > =========
> > Regards,
> > KM
>
> > "Bingo500" <klaus-buc...@machx.de> wrote in messagenews:1179505169.8...@u30g2000hsc.googlegroups.com...
>
> > Hi KM,
>
> > thanks for the response.
> > I do not change the IP-Address through the Registry I only use the
> > Property Editor in the Network settings, but I can see that the
> > Registry get愀 changed after applying the settings.
> > Of course with disabled FBWF it愀 working with the ipconfig and netsh.
Bingo500
sorry for the late answer, but yesterday I was out of the office, I
tried it immediatley
today morning, and that´s the perfect solution, it works very great,
without committing the
the SYSTEM hive.
Only set the Montiorkey and delay the start of the TCPIP (Indeed I do
not it it early in the Bootprocess)
How much work did you spend on debugging? You don´t need to do this
for nothing.
Best regards
Klaus
On 19 Mai, 22:06, "KM" <konstmor@nospam_yahoo.com> wrote:
> Klaus,
>
> Yes, I agree. Changing static IP is not a frequent operation and you can get away with committing the entire SYSTEM hive (FBWF) or
> even the volume (EWF).
> The downside of such workaround is that you may be committing some user data that you'd rather want to discard. Typically a reboot
> helps with such.
>
> Looks like last night I wasn't careful in playing with the driver load order and missed the right value. With the following value
> monitored by the RegFilter:
> [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{<Interface GUID>}]
> Please try to change the following value for the Tcpip driver:
> [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip],"Start"=dword:2
> That will put the driver in the auto-start group (started by the service control manager) instead of the system started (kernel or
> loader started).
> This is a pretty safe change unless you've got some custom drivers in your image that demand the network connectivity (IP) very
> early at the system boot.
>
> With the changes above committed, you can try to change the IP and reboot (without an extra commit) and the IP should be the correct
> one reported by the netsh (or GUI) and the ipconfig as well. At least this is what I am seeing working here.
> Always better to get some sleep and start debugging fresh! :-)
> Btw, the above change confirms the theory I described earlier.
>
> --
> =========
> Regards,
> KM
>
> "Bingo500" <klaus-buc...@machx.de> wrote in messagenews:1179589588.0...@p77g2000hsh.googlegroups.com...
> > [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{<Interface GUID>}] key and modify the value of the
> > > [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{<Interface GUID>}],"IPAddress"
> > > and
> > > [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{<Interface GUID>}\Parameters\Tcpip],"IPAddress"
>
> > > From your original post it is hard to get what exactly keys you are monitoring.
> > > --
> > > =========
> > > Regards,
> > > KM
>
> > > "Bingo500" <klaus-buc...@machx.de> wrote in messagenews:1179505169.8...@u30g2000hsc.googlegroups.com...
>
> > > Hi KM,
>
> > > thanks for the response.
> > > I do not change the IP-Address through the Registry I only use the
> > > Property Editor in the Network settings, but I can see that the
> > > Registry get´s changed after applying the settings.
> > > Of course with disabled FBWF it´s working with the ipconfig and netsh.
>
> > > Best regards
> > > Klaus- Zitierten Text ausblenden -
>
> > - Zitierten Text anzeigen -- Zitierten Text ausblenden -
KM
Actually, not that much time. Minlogon image is the way to debug things on XP/XPe - runs quickly, boots very fast.
And after the thread I got a nice tip page on my blog :-)
--
=========
Regards,
KM
"Bingo500" <klaus-...@machx.de> wrote in message news:1179731910.3...@z28g2000prd.googlegroups.com...
Hi KM,
sorry for the late answer, but yesterday I was out of the office, I
tried it immediatley
today morning, and that愀 the perfect solution, it works very great,
without committing the
the SYSTEM hive.
Only set the Montiorkey and delay the start of the TCPIP (Indeed I do
not it it early in the Bootprocess)
How much work did you spend on debugging? You don愒 need to do this
for nothing.
Best regards
Klaus
On 19 Mai, 22:06, "KM" <konstmor@nospam_yahoo.com> wrote:
> Klaus,
>
> Yes, I agree. Changing static IP is not a frequent operation and you can get away with committing the entire SYSTEM hive (FBWF) or
> even the volume (EWF).
> The downside of such workaround is that you may be committing some user data that you'd rather want to discard. Typically a reboot
> helps with such.
>
> Looks like last night I wasn't careful in playing with the driver load order and missed the right value. With the following value
> monitored by the RegFilter:
> [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfac限es\{<Interface GUID>}]
> > [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfac限es\{<Interface GUID>}] key and modify the value of
> > > [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfac限苟s\{<Interface GUID>}],"IPAddress"
> > > and
> > > [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{<Interface GUID>}\Parameters\Tcpip],"IPAddress"
>
> > > From your original post it is hard to get what exactly keys you are monitoring.
> > > --
> > > =========
> > > Regards,
> > > KM
>
> > > "Bingo500" <klaus-buc...@machx.de> wrote in messagenews:1179505169.8...@u30g2000hsc.googlegroups.com...
>
> > > Hi KM,
>
> > > thanks for the response.
> > > I do not change the IP-Address through the Registry I only use the
> > > Property Editor in the Network settings, but I can see that the
> > > Registry get愀 changed after applying the settings.
> > > Of course with disabled FBWF it愀 working with the ipconfig and netsh.