Any Win 10 network adapter experts?

Matthew

Matthew

Touchdown! Greaser!
Joined
Apr 18, 2005
Messages
19,106
Location
kojc, kixd, k34
Display Name
Display name:
Matthew
Got an interesting problem.

I have a new Win 10 PC, an industrial small form factor PC.

2 Ethernet ports, I have both configured for static IP addresses. One is (going from memory right now) 192.168.0.1, the other is 192.168.0.2.

I have two external pieces of equipment, also with static IP addresses, 192.168.0.20 and 192.168.0.40.

I have my own application that communicates with the two peripherals, and both peripherals have their own factory utilities, so I have something I can test with.

The deal is:

After resetting or powering up the PC, communication will fail the first time. I have to retry. Once communication is established, I can close and open applications all day long and not have a connection failure. As soon as I cycle power to the PC or restart it, the connections will fail the first time and need a retry. I thought it might be my application missing something, but the same thing happens with the utilities that come with the peripherals.

I'm suspecting there is some sort of "wake" function for the LANs that I'm missing. This PC is the first time I've used Win10, but not the first time I've used this brand of PC. Does Win 10 have any sort of power-saving that I need to work around? I have turned off all firewalls thinking it might be blocking something.

After power cycle or restart I can ping the IP addresses of the peripherals and get a response, but if I try to connect they will fail...just the first time.

Any ideas?

I'm not some networking genius, so you'll have to type slowly.

Thanks.
 
Sounds more like firewall. Doesn’t open the port in time.

But to kinda answer your question, yes there are “green” Ethernet adapters and drivers that will go to sleep but they usually buffer such stuff until they wake up.

Can you packet sniff at the devices or on the LAN and see if the initial packet actually goes out of the Windoze machine and it’s the return path that’s blocked?

That’s my suspicion. Firewall isn’t opening up the return path fast enough.
 
By the way some of those “green” adapters will drop to 100 Mb/sec until wake up time and then pop back up to Gigabit. Could be losing something in the renegotiation.
 
I've turned off all firewalls that I know of.

I have run into cases where some processes haven't started, or haven't finished starting after a power-up and some extra time has to be allocated before using them. The apps I write control industrial equipment and normally are set to auto start. Unlike a PLC, a PC does need to be given time to get spinning. In the case I'm having problems with right now - I can restart the PC and wait any amount of time. The first connection will fail and I dunno why. I saw it when the peripherals were connected to a switch and straight into the LAN ports.

I keep thinking this is a Win10 deal. I've used this hardware platform before, using XP and Embedded XP, and not seen this. I'll keep digging into whatever settings I can find.
 
Possible IP conflict? Do you have a router on the network? They typically will have a static .1 ip address. And if it has dhcp enabled it maybe giving out the .2 address to some other device unless you have it excluded from the pool. Just something to think about...
 
Try disabling one of the adapters. We had some very strange behavior on laptops that were allowing Windows to manage both wired and WiFi adapters simultaneously at the office. Turn off one or the other, all happy again. The internal “router” inside Win10 wasn’t quite doing what it was supposed to.
 
Go to NIC power management, turn off sleep/power save mode.
 
Oh on startup. Maybe a service not starting. You don't say much about the application.
 
Both adapters are on the same subnet. Why do you have two adapters on the same subnet? There is a possible routing issue. Outbound is probably going out only one of the adapters (default gateway), possibly causing a disparate route issue.
 
Disabled one port, re-addressed the other port to 192.168.0.8 just in case .1 was reserved or being used by something else.

Connected one of the peripheral devices directly (it's a 3-channel LED light source, allows for brightness controls of RGB channels independently). Used the manufacturer supplied utility to keep my application out of the loop (my application uses the same libraries as the manufacturer utility and integrates it into a larger control program.)

After PC reset (power cycle or re-start): When I try to connect to the device, the connection will fail. Try again and it works. Disconnect, using the utility, and then reconnect and it works. The only time there is a connection failure is after a PC reset.

I've worked around it inside my application by adding a retry if it fails to connect the first time.

I thought maybe it was something with the light controller drivers, but I see the same problem on another peripheral from another manufacturer.

I've tried finding all power-save options, but there's something that I'm missing. Worst case, I add a retry for that peripheral, too.

The two devices will eventually be connected to a switch that will be plugged into one of the ethernet ports. The other port will be a spare and will probably be set up for dynamic addressing.

Fun times.
 
Your computer isn’t behaving like a switch, but more like a router. You should disable the second port and buy a cheap switch, like you said. Applications will break if traffic is going out one port and coming in the other for a specific stream.
 
try persistent routes if you need the two nics. (might need to adjust IF1/2 based on your setup)
route add -p 192.168.0.20 255.255.255.255 192.168.0.1 METRIC IF1
route add -p 192.168.0.40 255.255.255.255 192.168.0.2 METRIC IF2


I've also seen where windows can boot faster than the NICs can come online, but this is typically only when connected to a switch that doesn't have portfast enabled and the nogetiation is taking extra long. There is a registry key i'm sure you can find it in google, that delays the services from starting until the network stack is online.
 
ifly4fun said:
try persistent routes if you need the two nics. (might need to adjust IF1/2 based on your setup)
route add -p 192.168.0.20 255.255.255.255 192.168.0.1 METRIC IF1
route add -p 192.168.0.40 255.255.255.255 192.168.0.2 METRIC IF2


I've also seen where windows can boot faster than the NICs can come online, but this is typically only when connected to a switch that doesn't have portfast enabled and the nogetiation is taking extra long. There is a registry key i'm sure you can find it in google, that delays the services from starting until the network stack is online.
Click to expand...
Yeah, that could work, since there is only one destination.

Edit: actually, maybe I am not understanding the full picture. If there is only one device plugged directly into the second port, just renumber it to another subnet. 192.168.1.40/24...
 
ifly4fun said:
try persistent routes if you need the two nics. (might need to adjust IF1/2 based on your setup)
route add -p 192.168.0.20 255.255.255.255 192.168.0.1 METRIC IF1
route add -p 192.168.0.40 255.255.255.255 192.168.0.2 METRIC IF2


I've also seen where windows can boot faster than the NICs can come online, but this is typically only when connected to a switch that doesn't have portfast enabled and the nogetiation is taking extra long. There is a registry key i'm sure you can find it in google, that delays the services from starting until the network stack is online.
Click to expand...

There are two ethernet ports (I named them LAN1, LAN2). LAN1 is set to a defined address, LAN2 (right now) is disabled.

Eventually, LAN1 will connect to a switch and two peripherals will be plugged in, each has a hardcoded IP address. LAN2 will be reserved in case it is ever necessary to connect to the outside world.

For device testing, I've plugged them individually right into LAN1. With all that was going on the other day, I am pretty sure I also plugged both into a switch, and then the switch into LAN1. In all cases, connections failed the first time.

I have seen problems in the past, can't remember the details right now, where Windows would start, then autostart my application, but not all services had finished starting and some conflicts would pop up. This one is something new, and hasn't seemed to be an issue in the past but this is also the first time I've used Win10 so I don't know if it's related or not. It seems I can re-start the PC, go to happy hour or not, and then try to connect to the device and it will fail the first time. It may be a service doesn't get started until there's a request, but I don't think it's because I'm trying to communicate too soon after a reset.

I have also pretty much reached the end of what I know about how network communications work, so I'll have to read up on your suggestions.
 
Years ago a buddy told me he got out of embedded systems when he got tired of being asked, "How long does it TAKE you to just to turn on a light?!?" I've been doing this stuff for 30yrs, and still don't have a good answer.
 
Matthew said:
I've worked around it inside my application by adding a retry if it fails to connect the first time.
Click to expand...

Are you waiting for a good Network up event before starting to use the network?

INetworkConnection::GetConnectivity is probably the most authoritative since it uses a combination of DHCP/DNS/IP/NIC service & miniport events and provides an aggregate answer. It's tricky to do these yourself across all of the race conditions in the protocol stack.
 
Last edited:
I had the same problem accessing an NAS. I've forgotten exactly what it took, but I finally was able to resolve it. As I recall, I worked with driver settings, DNS (yes, for a static IP addressed numerically), and something in the registry. MS has certainly ****ed up networking - as has Apple in their own ways.

Was something about networking starting after some other driver/program.

A pox on all of them. Or should that be "a *nix on all of them".
 
At this point I usually break out a switch that can do port mirroring and a system with Wireshark/tcpdump and see what's really going on. Of course assuming the problem still happens with a switch in the way.
 
With the switch: attempted connection, the first time, to each device (discrete IP address) will error and need to retry at least one time. I don't remember having to retry more than once, but I've been messing with this so much I can't be sure anymore.

I now have 3 devices plugged into a switch (all three hardcoded IP addresses). The switch goes into a single ethernet port on the back the PC. After PC startup (power cycle or restart), each IP address must be retried before a connection is made. Once a connection has been made to that address, I can close and reopen the connection without needing to retry. Each address needs to be retried, even if a connection is made to another address.

So it doesn't seem to be related directly to the LAN hardware itself, it's something to do with "seeing" a particular address at least one time. I just finished testing on another PC (same brand/model) with Win 7, so some drivers might be different and possibly some of the components might be older versions. That system doesn't show this behavior. I've made sure all the network adapter settings are the same.

I have 2 more systems to build, they will be identical to the Win 10 unit I've been working with. Maybe they do the same thing, maybe not. It's going to take a few days to find out.
 
W10 does something horsey with the network connections.

Video and audio files play fine from the local disk, if I move them to the NAS, WMP/Player stops the video and sometimes hangs. It runs OK on a different (non-MS) player. It was fine on Win 7 and the first rendition of Win10. Not so the current version.
 
if you're still stuck, message me and I'll help you out.

Sent from my SM-T397U using Tapatalk
 
#3 -- same thing

3 for 3, all Win 10.

I'm not creating my own sockets or connections, I'm using the vendor libraries and calling their "connect" or equivalent functions. I'm also able to recreate the problem when I use the vendor utilities directly, so it isn't something my program is doing.

My work around was to add retries, max = 2 retries, for each of the 3 external devices. If they don't connect after that, I display an error message and someone will have to do something about it. They almost always take one retry, but at least once I had to retry twice, so 2x seemed like a decent upper limit. I haven't seen any error messages yet, but I haven't started working them hard yet, either. This particular product line will be turned on in the morning and off again at night, so this retry issue will happen every day, one time.

I had to disconnect all these devices from my development PC (Dell), but sometime next week I'll move all these devices over to it and see if that one, also Win 10, has the same issues. I didn't notice it on that system before, but I wasn't looking for it, either.
 
Sounds like a timing issue with the initial connection request and underlying ARP request to get the MAC of the device(s). See if clearing the ARP table enables you to reproduce the problem. If it is related to the ARP, you can set it as a permanent entry in the APR table.

Hint: ARP -? on the cmd to get the correct command.
 
Ray Eaker said:
Sounds like a timing issue with the initial connection request and underlying ARP request to get the MAC of the device(s). See if clearing the ARP table enables you to reproduce the problem. If it is related to the ARP, you can set it as a permanent entry in the APR table.

Hint: ARP -? on the cmd to get the correct command.
Click to expand...
I'll play with that in a few minutes and see if I can find anything.

It's been narrowed down to a single piece of h/w (a power-over-ethernet camera) and a device driver. The first time the driver and camera connect, all other network devices have to re-try when trying to establish communications. I've recreated the conditions on a Win7 system and this does not occur, only on Win10. Closing connections, but leaving the camera physically attached, and then re-storing connections will work first time every time but the first time after a PC reset the device connections always need a retry. I think unplugging and then plugging the camera back in causes some sort of "new hardware found" behavior, and then trying to reconnect to any other device results in problems.

It really is a one-time thing, at power-up, and for now I'm ignoring it.
 
Each release and update to Win 10 screws up some drivers. I still have not resolved the video card driver issue that Win 10 caused with an update in November.
 
You must log in or register to reply here.
Back
Top