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.