From owner-freebsd-questions@FreeBSD.ORG Mon Nov 10 21:06:46 2014 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B953D5B0 for ; Mon, 10 Nov 2014 21:06:46 +0000 (UTC) Received: from nightmare.dreamchaser.org (ns.dreamchaser.org [66.109.141.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 85A13BD4 for ; Mon, 10 Nov 2014 21:06:45 +0000 (UTC) Received: from breakaway.dreamchaser.org (breakaway.dreamchaser.org. [192.168.151.122]) by nightmare.dreamchaser.org (8.13.6/8.13.6) with ESMTP id sAAL3WbR030181; Mon, 10 Nov 2014 14:03:33 -0700 (MST) (envelope-from freebsd@dreamchaser.org) Message-ID: <546128DD.9070504@dreamchaser.org> Date: Mon, 10 Nov 2014 14:06:37 -0700 From: Gary Aitken Reply-To: freebsd@dreamchaser.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Freebsd Questions Subject: Re: ARP only, no ICMP packets? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (nightmare.dreamchaser.org [192.168.151.101]); Mon, 10 Nov 2014 14:03:33 -0700 (MST) Cc: gmx@ross.cx X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 21:06:46 -0000 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 > 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