Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Nov 2014 14:06:37 -0700
From:      Gary Aitken <freebsd@dreamchaser.org>
To:        Freebsd Questions <questions@freebsd.org>
Cc:        gmx@ross.cx
Subject:   Re: ARP only, no ICMP packets?
Message-ID:  <546128DD.9070504@dreamchaser.org>
In-Reply-To: <b62bfb80fceac3f7a4748f15825edf67.squirrel@webmail.blackfoot.net>
References:  <b62bfb80fceac3f7a4748f15825edf67.squirrel@webmail.blackfoot.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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@blackfoot.net>
> wrote:
>>> 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
>>> Internet:
>>> Destination        Gateway            Flags    Refs      Use  Netif
> Expire
>>> 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
> [ethernet]
>>> # tcpdump -flnt -i re0 | grep 192.168.0.50
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
>>> 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
>> discarded.
> 
> 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:
>> 192.168.0.1
>> 192.168.0.30
>> 192.168.1.1
> 
> Thanks.
> Yes, I swept all of 192.168.0.* and .1.*
> nada.

Bizarre.  
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 
it.

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 
went out.

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.

Gary



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?546128DD.9070504>