Refresh Internal Windows Network State

Question

Hey,

I am working on a piece of software that effectively needs to talk to server sockets on the other side of an XP Windows Network Bridge. Now, this works ok, but if one of the connections that is part of the bridge fails (e.g. the physical cable is removed), and then re-established, the Network Connections viewer will not update the display.

Now, this wouldn't normally be that much of a big deal, however, no socket connection can be established through the bridge until I right-click in Network Connections, and select the 'Refresh' context menu entry. Upon which, all the connections in the Network Connections window indicate a solid connection, and my software can establish a socket across the bridge.

I am assuming that the windows software bridge uses some internal windows network state in order to decide whether or not to route packets from the various connections.

So, my question is, what does that magical 'Refresh' button do exactly? And, more specifically, is there a way I can automate whatever that is in my software?

Cheers

Answer 1

The only place I know of to start looking for this is at MSDN -Windows Networking Functions. I looked around but didn't find anything specific that mentions the refresh thou.

Answer 2

Perhaps you could do a work around till you find the direct call? Repair Network Connection

Or use SysInternals tools to see what DLL/Reg calls are executed when you perform that manually? That might lead you to the Google searches at least. ;-)

Answer 3

I didn't find a direct solution to my problem, but I did find a workaround in the following form:

The PC in question has a firewire connection, and therefore has an 1394 Net Adapter (which is never used). I found that disabling and re-enabling the 1394 adapter (from device manager) caused all the states to update themselves properly.

However, I don't really want to disable and then enable the device all the time, since the icon in Network Connections would grey out, and then return to normal, each time I carried out that cycle. So, instead, using the DevCon tool, I executed a device restart, which is quiet (in that there is no visible change in the adapter in the Network Connections panel), and successfully updates the Network connections state.

It turns out that the problem was caused in the first place by the software bridge that is in place for everything else to work.

It is hardly an ideal solution, but it does appear to do the job.