FBWF and Registry Filter (Changing IP Address)

[Bingo500]

Hi all,

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]

Klaus,

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?

 

[Bingo500]

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]

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


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

 

[Bingo500]

Hi KM,
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

 

[KM]

Klaus,

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


Hi KM,
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

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\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


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

 

[Bingo500]

Hi KM,

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

Klaus,

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 thatthe 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 theregistry.

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 itloads 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 relatedregistry 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\Interfac­es\{<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 theloading 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 forMicrosoft with the RegFilter approach since those keys are
only read late the boot process (by Winlogon and Terminal Services).

--
=========
Regards,
KM


Hi KM,
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

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 RegistryFilter to monitor?

[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.

"Bingo500" <[email protected]> wrote in messagenews:[email protected]...

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 -

 

[KM]

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>}]
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


Hi KM,

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

Klaus,

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\Interfac­es\{<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


Hi KM,
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

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\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.

"Bingo500" <[email protected]> wrote in messagenews:[email protected]...

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 -

 

[Bingo500]

Hi KM,
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

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>}]
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


Hi KM,

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

Klaus,

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 asimilar setup (Minlogon, netsh, EWF, RegFilter). Then I
debugged some system stacks to understand what's going on there when wechange 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 driverfor 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 monitoredkeys 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 filecontents 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 weend 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\Interfac­­es\{<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 thereis 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).
"Bingo500" <[email protected]> wrote in messagenews:[email protected]...

Hi KM,
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

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\Interfac­­­es\{<Interface GUID>}],"IPAddress"
and
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{<InterfaceGUID>}\Parameters\Tcpip],"IPAddress"
From your original post it is hard to get what exactly keys you are monitoring.
--
=========
Regards,
KM
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 -

- Zitierten Text anzeigen -

 

[KM]

Klaus,

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


Hi KM,
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

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>}]
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


Hi KM,

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

Klaus,

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\Interfac­­es\{<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).
"Bingo500" <[email protected]> wrote in messagenews:[email protected]...

Hi KM,
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

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\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
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 -

- Zitierten Text anzeigen -

 

[Cédric]

FBWF and Registry Filter: Problem changing IP Address)

Hi,

This post was quite interesting since we are trying to deal with the same problem but it still not work for us.

KM, we tried to follow the instruction found on your blog (XPE tip #36: Changing IP with EWF/FBWF On) but the new IP adress is not visible anywhere after a reboot.

We add un monitored key,we tried both paths : System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interfaces ID} as you say on your blog
and
System\ControlSet001\Services\Tcpip\Parameters\Interfaces\{Interfaces ID} as you told to Bingo500
Which is the right one ?


Then have modified the tcpip driver dy modifying the following key :
HKEY_LOCAL_MACHINE\System\ControlSet001\Services\Tcpip
"Start" = 2


But the IP adress is still not modified after a reboot.

What have we done wrong ?

The regfdata is protected by FBWF and seems to not keep changes after a reboot, is it a problem ?

Changing IP adress without rebooting and writing through the FBWF is an important point for us and we hope you will be able helping us to find a solution to this issue.

Regards.

Cédric

 

[Cédric]

Hi,

This post was quite interesting since we are trying to deal with the same problem but it still not work for us.

KM, we tried to follow the instruction found on your blog (XPE tip #36: Changing IP with EWF/FBWF On) but the new IP adress is not visible anywhere after a reboot.

We add un monitored key,we tried both paths : System\CurrentControlSet\Services\Tcpip\Parameters \Interfaces\{Interfaces ID} as you say on your blog
and
System\ControlSet001\Services\Tcpip\Parameters\Int erfaces\{Interfaces ID} as you told to Bingo500
Which is the right one ?


Then have modified the tcpip driver dy modifying the following key :
HKEY_LOCAL_MACHINE\System\ControlSet001\Services\T cpip
"Start" = 2


But the IP adress is still not modified after a reboot.

What have we done wrong ?

The regfdata is protected by FBWF and seems to not keep changes after a reboot, is it a problem ?

Changing IP adress without rebooting and writing through the FBWF is an important point for us and we hope you will be able helping us to find a solution to this issue.

Regards.

Cédric