Background: I am a designer of embedded wired networking device, which works in almost all set ups, but there are circumstances when it does not work, and I am dealing with troubleshooting the root causes and fixing the issues.

This is multi-part question, however about two related things.

Question 1 - port not ready right after it gets carrier

Scenario: I set up Windows 7 PC as bridge between WiFi (internet through router with DHCP/DNS) and wired embedded device (direct connect). When wired embedded device is off, Windows PC port it is connected to is down. When I power device up, it, within several seconds, sends DHCP discover, but it seems Windows PC's port (or its driver part) is not yet ready, and there is no response to DHCP packet. If I manually issue DHCP request later, it works; If I put hub in between so that when embedded device does not power off the PC's port, device gets IP config from DHCP properly after power up.

It seems I caught the same issue in (too much) intelligent routers like Cisco, they also do not want to work properly just after carrier appears in the wire.

Is there any setting in operating systems - Windows, Linux and Cisco IOS which I can tune so that port becomes available as quick as possible after it senses carrier?

Question 2 - DNS response is blocked

Same setup as above - Windows PC as bridge between WiFi (internet) and wired (embedded device). Embedded device issues DNS request in the wire, I can see that request appears at the WiFi side, and can see that PC's WiFi side receives response from the router, but this response does not appear on the wired side.

I have no idea what may be the cause of this block, however I found out by comparing packets sent by another PC connected instead of embedded device that packets embedded device sends have don't fragment flag forcefully set.

Update: I can see that SYN/ACK TCP packets are also being blocked within Windows 7 PC bridge on the way to embedded device. There must me some setting to prevent this blocking, but I can not qualify what it can be.

  • Is there a switch? This could be spanning tree setting the interface to blocking until STP has converged after a change. Cisco, for example, has the portfast command to skip the whole blocking, listening, learning, forwarding process so that an interface goes straight to forwarding for access interfaces. – Ron Maupin Oct 10 '17 at 21:56
  • Topology is: embedded device, then windows PC with wired and WiFi ports, then WiFi router/switch (which responds with DNS answers), and then outer internet (which responds with SYN/ACK messages). Blocking is performed within Windows PC - packet at one interface (WiFi) is present, at another (wired) it is absent in the embedded device direction. DHCP response packets are not blocked (they are answered by router). – Anonymous Oct 10 '17 at 22:02

I have found an answer to bizarre behavior with blocked packets by the windows host. The answer is simple - Windows PC was thinking that those packets was for itself!

The bridging mechanism seems to be related to translation of the packets from one interface to another, putting bridge's MAC address into the packets. In my case I set Windows PC host to receive IP address using DHCP, however when wired device was trying DHCP, Windows PC was substituting that device's MAC address with its own, and of course router was giving the same IP address to that device. Thus there were two devices with same IP addresses, and whatever embedded device was sending, (almost) all replies (except DHCP as they are broadcasts) were ending at the entrance to the first device in the daisy-chain having that IP address (thus at Windows PC).

The solution is simple - I gave fixed IP address to Windows host, outside of DHCP address pool.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.