ARP only, no ICMP packets?
freebsd at dreamchaser.org
Mon Nov 10 21:06:46 UTC 2014
On 11/08/14 19:41, Gary Aitken wrote:
> On 11/08/14 14:24, Michael Ross wrote:
>> On Sat, 08 Nov 2014 21:33:44 +0100, Gary Aitken <vagabond at blackfoot.net>
>>> After reconfiguring my internal network to private ip addrs,
>>> I'm trying to reconfigure a DLink wireless access point.
>>> At first I tried using the old IP addrs and configuring my
>>> workstation with an alias on the old network. That didn't
>>> work, so I've reset the wap. The manual says default addr is
>>> 192.168.0.50 netmask 255.255.255.0
>>> The box I'm trying to access it from has an ip of 192.168.151.122/24.
>>> I've added an alias to the interface for the 192.168.0 subnet:
>>> Routing tables
>>> Destination Gateway Flags Refs Use Netif
>>> default 192.168.151.101 UGS 0 0 re0
>>> 127.0.0.1 link#10 UH 0 59752 lo0
>>> 192.168.0.0/24 link#1 U 0 121 re0
>>> 192.168.0.122 link#1 UHS 0 0 lo0
>>> 192.168.151.0/24 link#1 U 0 54 re0
>>> 192.168.151.122 link#1 UHS 0 0 lo0
>>> When I attempt to access the WAP, I see only ARP requests,
>>> and it appears not to answer:
>>> $ arp -n -a
>>> ? (192.168.151.122) at f4:6d:04:78:70:62 on re0 permanent [ethernet]
>>> ? (192.168.0.122) at f4:6d:04:78:70:62 on re0 permanent [ethernet]
>>> ? (192.168.151.101) at 00:01:02:c2:a1:a8 on re0 expires in 339 seconds
>>> # tcpdump -flnt -i re0 | grep 192.168.0.50
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>> listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
>>> ARP, Request who-has 192.168.0.50 tell 192.168.0.122, length 28
>> No ARP reply...
>>> I have difficulty believing the wap unit is defective, as
>>> "it worked before I changed all the addresses..."
>> Maybe not defective as such, but some DLinks ( mine for example )
>> ignore everything not originating from their own /24,
>> so unless packets come from 192.168.0.x, they will be silently
> In this case, they are originating from 192.168.0.122, so should be ok there.
> (see ARP request above)
> On 11/08/14 16:34, Jon Radel wrote:
>> Have you swept the /24 on the off chance that the manual is fibbing about
>> 192.168.0.50 but not about it being some address in 192.168.0.0/24? If
>> that fails, try 192.168.1.0/24. Other addresses D-Link seems to favor as
>> the default:
> Yes, I swept all of 192.168.0.* and .1.*
I started a sweep of 192.168.* a day or so ago, and it was plodding along.
Nothing was rebooted in the meantime, although ipfw and natd on the gateway
machine on the same network had their rules modified. But the router and
the pinging machine(s) share the same hardware switch so ipfw and natd
should not affect the response.
This morning, out of the ether, I get a login prompt on a browser window
where I had been pointing to 192.168.0.50 for the past three days. There
is some possibility that ipfw and natd rules on the firewall box would have
prevented anything coming in on an external network from reaching the wap;
or preventing the wap from reaching outside. But I don't see how they
could prevent something connected to the same hardware switch from reaching
I could blame it on a cat5 cable but I tried three different ones, all of
which work in other circumstances, and both the switch light and the wap
LAN light went on when cables were plugged in, and blinked when packets
In any case, it is now where I want it and operating properly, happily
responding to pings and configuration html; but I am mystified.
Thanks to those who responded.
More information about the freebsd-questions