Looks like that caused them to re-poll.<div><br></div><div>Still futzing with iptables...</div><div><br><div class="gmail_quote">On Wed, May 9, 2012 at 7:58 PM, Jonathan Lassoff <span dir="ltr"><<a href="mailto:jof@thejof.com" target="_blank">jof@thejof.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, May 9, 2012 at 7:48 PM, Jonathan Lassoff <span dir="ltr"><<a href="mailto:jof@thejof.com" target="_blank">jof@thejof.com</a>></span> wrote:<br>
</div></div><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's the oddest thing with bikeshed...<div><br></div><div>I'm trying to do some DNAT for traffic coming inbound, and I can see the traffic with I pcap the interface, but if I add a logging statement in raw/PREROUTING matching on just the external destination IP and having it LOG... it never logs from a remote source.</div>
<div><br></div><div>However, it works from another external IP in the same external LAN (minotaur -> MC Hawking external IP).</div><div><br></div><div><br></div><div>The only thing I can think of as blocking this from getting from there to there is ebtables filtering, but there's no ebtables binary available.</div>
<div>Maybe something else it setting stuff in there with it's own binary support for the right netlink messages.</div><div><br></div><div>Any ideas?</div></blockquote><div><br></div></div></div><div>Actually, I may have figured it out. Sonic.net seems to have somehow learned the address 52:54:00:2a:80:90 for <a href="http://75.101.62.93" target="_blank">75.101.62.93</a>:</div>
<div><br></div><div>02:52:27.348405 00:22:be:3c:d6:44 > 52:54:00:2a:80:90, ethertype IPv4 (0x0800), length 78: REMOTE_IP_SCRUBBED.PORT > 75.101.62.93.22: Flags [S], seq xxxxxxxxxx, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 30107305 ecr 0,sackOK,eol], length 0</div>
<div><br></div><div>But locally, hosts are learning the right MAC:</div><div><br></div><div><div>.-(~)--------------------------------------------------------------------------------------------------(jof@minotaur)-</div>
<div>`--> sudo arping -I eth0 75.101.62.93</div><div>ARPING 75.101.62.93 from 75.101.62.92 eth0</div><div>Unicast reply from 75.101.62.93 [00:00:24:C8:DF:FE] 0.835ms</div><div>Unicast reply from 75.101.62.93 [00:00:24:C8:DF:FE] 0.832ms</div>
<div>^CSent 2 probes (1 broadcast(s))</div><div>Received 2 response(s)</div></div><div><br></div><div><div>root@bikeshed:~# ifconfig eth2</div><div>eth2 Link encap:Ethernet HWaddr 00:00:24:c8:df:fe </div><div> inet addr:75.101.62.88 Bcast:75.101.62.255 Mask:255.255.255.0</div>
<div> inet6 addr: fe80::200:24ff:fec8:dffe/64 Scope:Link</div><div> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1</div><div> RX packets:115779121 errors:0 dropped:16042396 overruns:0 frame:0</div>
<div> TX packets:71834438 errors:0 dropped:0 overruns:0 carrier:0</div><div> collisions:0 txqueuelen:1000 </div><div> RX bytes:3468915913 (3.2 GiB) TX bytes:<a href="tel:4157264755" value="+14157264755" target="_blank">4157264755</a> (3.8 GiB)</div>
<div> Interrupt:9 Base address:0xe300</div>
</div><div><br></div><div><br></div><div>Let's see if they accept gratuitous ARPs.</div></div><br>
</blockquote></div><br></div>