Odd Behavior With gethostbyname
-
As the title states, recently I have seen very strange behavior using
gethostbynameon Windows 10. We are implementing an interface using CIP to talk to a PLC. CIP is a protocol used to talk to industrial I/O devices and PLCs over Ethernet. It has it's own share of weirdness too and is what started all of this. We are talking to Allen Bradley PLCs and it's a real PITA. We configure these "assembly instances" in the PLC and one of their parameters is the IP address of the target computer. To implement the interface we are using a library we bought because the protocol is rather complex. It has this quirk whereby the IP address you configure for your computer will not work directly. To be more precise, it won't work if it is the primary IP address of a NIC. It has to be the secondary address which is configured using the "Advanced Options" of the control panel page for networking. Here is where the really strange part comes in. When I first configure the secondary address for a NIC it won't work. I have to add the address, accept all options, and close the dialogs, then re-open them, delete the address, and close them again. Then I have to re-open the option dialogs and re-enter that address and accept the changes. Only after doing all of that will it work correctly and I have seen this on four different machines. Wheregethostbynamecomes in is it is called to enumerate the addresses and find a match to the one you ask for. Unless the procedure I described is followed it will not see the secondary address so the interface initialization fails. You can open the dialogs and verify it is there but the function just will not see it unless it is deleted and then added back in. I don't recall seeing such weirdness before but, of course, this is Windows 10. Yee haw."They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
As the title states, recently I have seen very strange behavior using
gethostbynameon Windows 10. We are implementing an interface using CIP to talk to a PLC. CIP is a protocol used to talk to industrial I/O devices and PLCs over Ethernet. It has it's own share of weirdness too and is what started all of this. We are talking to Allen Bradley PLCs and it's a real PITA. We configure these "assembly instances" in the PLC and one of their parameters is the IP address of the target computer. To implement the interface we are using a library we bought because the protocol is rather complex. It has this quirk whereby the IP address you configure for your computer will not work directly. To be more precise, it won't work if it is the primary IP address of a NIC. It has to be the secondary address which is configured using the "Advanced Options" of the control panel page for networking. Here is where the really strange part comes in. When I first configure the secondary address for a NIC it won't work. I have to add the address, accept all options, and close the dialogs, then re-open them, delete the address, and close them again. Then I have to re-open the option dialogs and re-enter that address and accept the changes. Only after doing all of that will it work correctly and I have seen this on four different machines. Wheregethostbynamecomes in is it is called to enumerate the addresses and find a match to the one you ask for. Unless the procedure I described is followed it will not see the secondary address so the interface initialization fails. You can open the dialogs and verify it is there but the function just will not see it unless it is deleted and then added back in. I don't recall seeing such weirdness before but, of course, this is Windows 10. Yee haw."They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
Cache? A lot of IP address stuff is cached all over the place. Maybe your magic incantation is what it takes to kick something into a cache refresh.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
As the title states, recently I have seen very strange behavior using
gethostbynameon Windows 10. We are implementing an interface using CIP to talk to a PLC. CIP is a protocol used to talk to industrial I/O devices and PLCs over Ethernet. It has it's own share of weirdness too and is what started all of this. We are talking to Allen Bradley PLCs and it's a real PITA. We configure these "assembly instances" in the PLC and one of their parameters is the IP address of the target computer. To implement the interface we are using a library we bought because the protocol is rather complex. It has this quirk whereby the IP address you configure for your computer will not work directly. To be more precise, it won't work if it is the primary IP address of a NIC. It has to be the secondary address which is configured using the "Advanced Options" of the control panel page for networking. Here is where the really strange part comes in. When I first configure the secondary address for a NIC it won't work. I have to add the address, accept all options, and close the dialogs, then re-open them, delete the address, and close them again. Then I have to re-open the option dialogs and re-enter that address and accept the changes. Only after doing all of that will it work correctly and I have seen this on four different machines. Wheregethostbynamecomes in is it is called to enumerate the addresses and find a match to the one you ask for. Unless the procedure I described is followed it will not see the secondary address so the interface initialization fails. You can open the dialogs and verify it is there but the function just will not see it unless it is deleted and then added back in. I don't recall seeing such weirdness before but, of course, this is Windows 10. Yee haw."They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
As the title states, recently I have seen very strange behavior using
gethostbynameon Windows 10. We are implementing an interface using CIP to talk to a PLC. CIP is a protocol used to talk to industrial I/O devices and PLCs over Ethernet. It has it's own share of weirdness too and is what started all of this. We are talking to Allen Bradley PLCs and it's a real PITA. We configure these "assembly instances" in the PLC and one of their parameters is the IP address of the target computer. To implement the interface we are using a library we bought because the protocol is rather complex. It has this quirk whereby the IP address you configure for your computer will not work directly. To be more precise, it won't work if it is the primary IP address of a NIC. It has to be the secondary address which is configured using the "Advanced Options" of the control panel page for networking. Here is where the really strange part comes in. When I first configure the secondary address for a NIC it won't work. I have to add the address, accept all options, and close the dialogs, then re-open them, delete the address, and close them again. Then I have to re-open the option dialogs and re-enter that address and accept the changes. Only after doing all of that will it work correctly and I have seen this on four different machines. Wheregethostbynamecomes in is it is called to enumerate the addresses and find a match to the one you ask for. Unless the procedure I described is followed it will not see the secondary address so the interface initialization fails. You can open the dialogs and verify it is there but the function just will not see it unless it is deleted and then added back in. I don't recall seeing such weirdness before but, of course, this is Windows 10. Yee haw."They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
On Win NT 4.0, the NIC could support a huge number of IPs. At least 16. The GUI could not handle that many so we would directly edit the registry to add additional IPs. We may have had to reboot after, but it always worked and sounds easier than your procedure.