I only see this issue in Win7. Linux does not exhibit this symptom.
I have some USB NICs in Windows that are not always physically connected to a LAN or switch. I start opendhcpserver -v with those NICs disconnected, and see:
Warning: Section [LISTEN_ON], Interface %s not available, ignored
When I then connect those NICs back-to-back with endstations, OpenDHCPServer never detects NetworkAddrChange, and hence never starts listening on those newly-connected interfaces. I have to restart OpenDHCPServer to get it to listen (which is not permissible in my environment).
If I then stop OpenDHCPServer, disconnect all those NICs, and restart OpenDHCPServer, I instead now see:
Warning: Section [LISTEN_ON], Interface %s is not Static, ignored
At first I thought you had forgotten to initialize network.allServers, but then I finally found the memset(&network, 0, sizeof(netowrk)) at the top of getInteraces().
I have rebuilt your OpenDHCPServer source with vc6, vs2010, and even mingw, and my own binaries always work. They instead display "No Static Interface ready, Waiting..." one time, and when I finally plug into one of them, OpenDHCPServer (the one I built, not yours) consistently detects NetworkAddrChange.
It would seem like the issue must be the difference between your build environment and mine. Can you post here your compiler/SDK versions (and do you use a makefile or anything, or are you manually typing out the command line?), so that I can try to replicate your environment and see if I can build a binary that exhibits your symptoms? I mean, I could just rebuild and use my own, but it bugs me that I can't figure out why yours should be behaving any differently at all.
If there is some sort of defect, I'd be happy to help debug, but I think I'm missing some key details here.
Thanks,
- Matthew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The source is compiled using g++ same way as you do. But I use Windows2000 to compile. Looks like issue is there. As now a days no body use windows 2000 I will compile using Windwos 7 or higher.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I only see this issue in Win7. Linux does not exhibit this symptom.
I have some USB NICs in Windows that are not always physically connected to a LAN or switch. I start opendhcpserver -v with those NICs disconnected, and see:
Warning: Section [LISTEN_ON], Interface %s not available, ignored
When I then connect those NICs back-to-back with endstations, OpenDHCPServer never detects NetworkAddrChange, and hence never starts listening on those newly-connected interfaces. I have to restart OpenDHCPServer to get it to listen (which is not permissible in my environment).
If I then stop OpenDHCPServer, disconnect all those NICs, and restart OpenDHCPServer, I instead now see:
Warning: Section [LISTEN_ON], Interface %s is not Static, ignored
At first I thought you had forgotten to initialize network.allServers, but then I finally found the memset(&network, 0, sizeof(netowrk)) at the top of getInteraces().
I have rebuilt your OpenDHCPServer source with vc6, vs2010, and even mingw, and my own binaries always work. They instead display "No Static Interface ready, Waiting..." one time, and when I finally plug into one of them, OpenDHCPServer (the one I built, not yours) consistently detects NetworkAddrChange.
It would seem like the issue must be the difference between your build environment and mine. Can you post here your compiler/SDK versions (and do you use a makefile or anything, or are you manually typing out the command line?), so that I can try to replicate your environment and see if I can build a binary that exhibits your symptoms? I mean, I could just rebuild and use my own, but it bugs me that I can't figure out why yours should be behaving any differently at all.
If there is some sort of defect, I'd be happy to help debug, but I think I'm missing some key details here.
Thanks,
- Matthew
The source is compiled using g++ same way as you do. But I use Windows2000 to compile. Looks like issue is there. As now a days no body use windows 2000 I will compile using Windwos 7 or higher.