summaryrefslogtreecommitdiff
path: root/drivers/rtc/ftrtc010.c
diff options
context:
space:
mode:
authorJoe Hershberger <joe.hershberger@ni.com>2012-05-23 08:00:13 +0000
committerJoe Hershberger <joe.hershberger@ni.com>2012-05-23 17:53:08 -0500
commitc697576262be11ddab48e1890428495e2fef1751 (patch)
tree0e97e4c1ef9f79ad72d8db6ebf3c6579aa9cef9f /drivers/rtc/ftrtc010.c
parentd22c338e07cc98276ea5cc4feaa5a370baa63243 (diff)
downloadu-boot-imx-c697576262be11ddab48e1890428495e2fef1751.zip
u-boot-imx-c697576262be11ddab48e1890428495e2fef1751.tar.gz
u-boot-imx-c697576262be11ddab48e1890428495e2fef1751.tar.bz2
net: Work-around for brain-damaged Cisco equipment with arp-proxy
Cisco's arp-proxy feature fails to ignore the link-local address range This means that a link-local device on a network with this Cisco equipment will reply to ARP requests for our device (in addition to our reply). If we happen to reply first, the requester's ARP table will be populated with our MAC address, and one packet will be sent to us... shortly following this, the requester will get an ARP reply from the Cisco equipment telling the requester to send packets their way instead of to our device from now on. This work-around detects this link-local condition and will delay replying to the ARP request for 5ms so that the first packet is sent to the Cisco equipment and all following packets are sent to our device. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
Diffstat (limited to 'drivers/rtc/ftrtc010.c')
0 files changed, 0 insertions, 0 deletions