Solwise WAP-011A

Hello all

I have lost contact with this access point. The default IP is
192.168.1.1/24 but the reset doesn't seem to work.

I last set the ethernet port to dhcp and that's when it broke. I tried port
scanning it, running it on a dhcp subnet and all sorts.

Is is scrap or am I missing something here?

Nick

"Nick" <(E-Mail Removed)> wrote in news:(E-Mail Removed):

> Hello all
>
> I have lost contact with this access point. The default IP is
> 192.168.1.1/24 but the reset doesn't seem to work.
>
> I last set the ethernet port to dhcp and that's when it broke. I tried
> port scanning it, running it on a dhcp subnet and all sorts.
>
> Is is scrap or am I missing something here?
>
> Nick
>
>

Now you know why real (i.e. not SOHO) networking devices have serial ports.
You're not the first, and certainly won't be the last person to "lose" an
access point. This also isn't the first time that I've heard of a funtional
AP refusing to go back to its default settings, no matter what you do to the
reset switch. The fact that you lost connectivity when you changed the device
to become a DHCP client indicates that the change was successful, so I'll
start on that assumption.

Plug the AP into a switch that is serviced by a DHCP server. Cycle the AP's
power. Check the leases on the DHCP server for the MAC address that matches
your AP. The MAC address of your AP should be on a sticker on the bottom of
the device. If you do not have access to the DHCP server, plug another
machine onto the same switch, run ipconfig /release, renew. Fire up your
scanner, and run a ping sweep on that subnet. Immediately after you run the
sweep, go to a command line, and run "arp -a"(no quotes). Once again, you're
looking to match your AP's MAC address. I've found devices this way where a
port 80 scan failed to discover anything.

There are some other ways of tracking the thing down, but first let me know
what your results on executing the preceeding are.

Good luck.

Walter,

you are a networking god.

I used a known good dhcp server, pinged the scope and detected 14 hosts. I
turned on the AP, rescanned the scope and detected 15 hosts.

Inspection of the MAC address in the active leases revealed the IP. I was
able to reconnect to the AP and set a static IP.

Result!

The firmware in these things must be pretty crap if you can't reset from a
dhcp client configuration.

All the best,

Nick van Weede


picked up an IP 10.96.0.1, the
"Walter Simmons" <(E-Mail Removed)> wrote in message
news:Xns9501DE75070FliwhitehatNOSPAMOKho@167.206.3 .3...
> "Nick" <(E-Mail Removed)> wrote in news:(E-Mail Removed):
>
>> Hello all
>>
>> I have lost contact with this access point. The default IP is
>> 192.168.1.1/24 but the reset doesn't seem to work.
>>
>> I last set the ethernet port to dhcp and that's when it broke. I tried
>> port scanning it, running it on a dhcp subnet and all sorts.
>>
>> Is is scrap or am I missing something here?
>>
>> Nick
>>
>>
>
> Now you know why real (i.e. not SOHO) networking devices have serial
> ports.
> You're not the first, and certainly won't be the last person to "lose" an
> access point. This also isn't the first time that I've heard of a
> funtional
> AP refusing to go back to its default settings, no matter what you do to
> the
> reset switch. The fact that you lost connectivity when you changed the
> device
> to become a DHCP client indicates that the change was successful, so I'll
> start on that assumption.
>
> Plug the AP into a switch that is serviced by a DHCP server. Cycle the
> AP's
> power. Check the leases on the DHCP server for the MAC address that
> matches
> your AP. The MAC address of your AP should be on a sticker on the bottom
> of
> the device. If you do not have access to the DHCP server, plug another
> machine onto the same switch, run ipconfig /release, renew. Fire up your
> scanner, and run a ping sweep on that subnet. Immediately after you run
> the
> sweep, go to a command line, and run "arp -a"(no quotes). Once again,
> you're
> looking to match your AP's MAC address. I've found devices this way where
> a
> port 80 scan failed to discover anything.
>
> There are some other ways of tracking the thing down, but first let me
> know
> what your results on executing the preceeding are.
>
> Good luck.