Jacob Dall
|
ARP cache timeout issue, or...
|
Jacob Dall
03/18/2008 5:30 AM
post5890
|
ARP cache timeout issue, or...
We've installed a qnx6.3.2 box in the wild, connecting to it over a wireless network.
The setup is as follows (- is wired, ~ is wireless):
PC (192.168.1.10)
<->
(192.168.1.253) Gateway (192.168.2.254)
<->
Access Point (192.168.2.253)
<~>
Bridge (192.168.2.160)
<->
box (192.168.2.142)
laptop (192.168.2.143)
Now, having powered up the box, I telnet to the box and execute
# route show
Routing tables
Internet:
Destination Gateway Flags
localhost.localdo 127.0.0.1 UH
192.168.2.0 link#2 U
192.168.2.143 00:16:d3:57:96:46 UH
# arp -a
? (192.168.2.143) at 00:16:d3:57:96:46 on en0
From the PC, I try and ping the box:
> ping 192.168.2.142
Pinging 192.168.2.142 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.2.142:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Back in the box, pinging the gateway (that blocks ping from wan):
# ping -c 1 192.168.2.254
PING 192.168.2.254 (192.168.2.254): 56 data bytes
----192.168.2.254 PING Statistics----
1 packets transmitted, 0 packets received, 100% packet loss
And, again from the PC, pinging the box
>ping 192.168.2.142
Pinging 192.168.2.142 with 32 bytes of data:
Reply from 192.168.2.142: bytes=32 time=2ms TTL=255
Reply from 192.168.2.142: bytes=32 time=2ms TTL=255
Ping statistics for 192.168.2.142:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2ms
For the last time, at the box:
# route show
Routing tables
Internet:
Destination Gateway Flags
localhost.localdo 127.0.0.1 UH
192.168.2.0 link#2 U
192.168.2.143 00:16:d3:57:96:46 UH
192.168.2.254 00:1c:f0:4e:71:9b UH
# arp -a
? (192.168.2.143) at 00:16:d3:57:96:46 on en0
? (192.168.2.254) at 00:1c:f0:4e:71:9b on en0
So, in plain english, one can not initially ping the box from the LAN.
Doing a ping of the gateway from the box, one can now ping the box.
But waiting a few minutes, then another ping from LAN fails.
'route show' and 'arp -a' shows the same info as previously, when the ping succeded.
The only way (so far) to get that ping from LAN working again, is to do another ping from the box.
I've tried to make the mac address of the gateway permanent upon startup of the box (arp -s 192.168.2.254 00:1c:f0:4e:71
:9b) - it changes absolutely nothing. Only way around is to do a ping from the box.
So, can someone please tell me what's going on?
What have I missed?
Is this an arp cache issue?
Any ideas how to solve this?
Thanks,
Jacob dall
|
|
|
Sean Boudreau(deleted)
|
Re: ARP cache timeout issue, or...
|
Sean Boudreau(deleted)
03/18/2008 9:52 AM
post5896
|
Re: ARP cache timeout issue, or...
On Tue, Mar 18, 2008 at 05:30:48AM -0400, Jacob Dall wrote:
> We've installed a qnx6.3.2 box in the wild, connecting to it over a wireless network.
>
> The setup is as follows (- is wired, ~ is wireless):
>
> PC (192.168.1.10)
> <->
> (192.168.1.253) Gateway (192.168.2.254)
> <->
> Access Point (192.168.2.253)
> <~>
> Bridge (192.168.2.160)
> <->
> box (192.168.2.142)
> laptop (192.168.2.143)
>
>
> Now, having powered up the box, I telnet to the box and execute
>
> # route show
> Routing tables
>
> Internet:
> Destination Gateway Flags
> localhost.localdo 127.0.0.1 UH
> 192.168.2.0 link#2 U
> 192.168.2.143 00:16:d3:57:96:46 UH
>
> # arp -a
> ? (192.168.2.143) at 00:16:d3:57:96:46 on en0
>
>
> From the PC, I try and ping the box:
>
> > ping 192.168.2.142
> Pinging 192.168.2.142 with 32 bytes of data:
>
> Request timed out.
> Request timed out.
> Request timed out.
> Request timed out.
>
> Ping statistics for 192.168.2.142:
> Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
>
>
> Back in the box, pinging the gateway (that blocks ping from wan):
>
> # ping -c 1 192.168.2.254
> PING 192.168.2.254 (192.168.2.254): 56 data bytes
>
> ----192.168.2.254 PING Statistics----
> 1 packets transmitted, 0 packets received, 100% packet loss
>
>
> And, again from the PC, pinging the box
>
> >ping 192.168.2.142
>
> Pinging 192.168.2.142 with 32 bytes of data:
>
> Reply from 192.168.2.142: bytes=32 time=2ms TTL=255
> Reply from 192.168.2.142: bytes=32 time=2ms TTL=255
>
> Ping statistics for 192.168.2.142:
> Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
> Approximate round trip times in milli-seconds:
> Minimum = 2ms, Maximum = 2ms, Average = 2ms
>
>
> For the last time, at the box:
>
> # route show
> Routing tables
>
> Internet:
> Destination Gateway Flags
> localhost.localdo 127.0.0.1 UH
> 192.168.2.0 link#2 U
> 192.168.2.143 00:16:d3:57:96:46 UH
> 192.168.2.254 00:1c:f0:4e:71:9b UH
>
> # arp -a
> ? (192.168.2.143) at 00:16:d3:57:96:46 on en0
> ? (192.168.2.254) at 00:1c:f0:4e:71:9b on en0
>
>
> So, in plain english, one can not initially ping the box from the LAN.
> Doing a ping of the gateway from the box, one can now ping the box.
>
> But waiting a few minutes, then another ping from LAN fails.
> 'route show' and 'arp -a' shows the same info as previously, when the ping succeded.
> The only way (so far) to get that ping from LAN working again, is to do another ping from the box.
>
> I've tried to make the mac address of the gateway permanent upon startup of the box (arp -s 192.168.2.254 00:1c:f0:4e:
71:9b) - it changes absolutely nothing. Only way around is to do a ping from the box.
>
> So, can someone please tell me what's going on?
> What have I missed?
> Is this an arp cache issue?
> Any ideas how to solve this?
>
> Thanks,
> Jacob dall
>
I don't see how this could ever work. If you try pinging
the 'pc' from the 'box' in this configuration you should get
'no route to host'. You need to add a route to network
192.168.1 on the 'box':
# route add -net 192.168.1/24 192.168.2.254
-seanb
|
|
|
Jacob Dall
|
Re: ARP cache timeout issue, or...
|
Jacob Dall
03/18/2008 10:42 AM
post5898
|
Re: ARP cache timeout issue, or...
Hello sean,
You got me wrong - I'm not trying to ping the PC from the box. In fact that will newer succeed, because the gateway has
a firewall that blocks any attempt to access the lan from the wireless.
What I need, is to be able to access the box from the PC, and NOT the other way around.
The pinging of the gateway from the box, I'm only doing because I discovered that this was a way to 'make a hole' for
the PC-to-box ping to succeed.
One of my wonders/questions are why this 'hole' seems to close after a few minutes with no traffic from the PC to the
box.
Another thing - what is it a ping is doing behind the scene, that 'route show' and 'arp -a' does not reflect. I mean...
after the PC-to-box ping stops working, the route and arp info are the very same as when the ping worked.
Any thoughts?
Thanks,
Jacob
|
|
|
Sean Boudreau(deleted)
|
Re: ARP cache timeout issue, or...
|
Sean Boudreau(deleted)
03/18/2008 10:55 AM
post5899
|
Re: ARP cache timeout issue, or...
On Tue, Mar 18, 2008 at 10:42:28AM -0400, Jacob Dall wrote:
> Hello sean,
>
> You got me wrong - I'm not trying to ping the PC from the box. In fact that will newer succeed, because the gateway
has a firewall that blocks any attempt to access the lan from the wireless.
>
> What I need, is to be able to access the box from the PC, and NOT the other way around.
>
> The pinging of the gateway from the box, I'm only doing because I discovered that this was a way to 'make a hole' for
the PC-to-box ping to succeed.
>
> One of my wonders/questions are why this 'hole' seems to close after a few minutes with no traffic from the PC to the
box.
>
> Another thing - what is it a ping is doing behind the scene, that 'route show' and 'arp -a' does not reflect. I mean..
. after the PC-to-box ping stops working, the route and arp info are the very same as when the ping worked.
>
> Any thoughts?
The traffic is 2 way. The PC might be able to reach the box
(the ping request may reach the box successfully) but the
box also needs a route back to send the reply. That's why I
said I can't see how it would ever work.
-seanb
|
|
|
Jacob Dall
|
Re: ARP cache timeout issue, or...
|
Jacob Dall
03/18/2008 11:16 AM
post5900
|
Re: ARP cache timeout issue, or...
> The traffic is 2 way. The PC might be able to reach the box
> (the ping request may reach the box successfully) but the
> box also needs a route back to send the reply. That's why I
> said I can't see how it would ever work.
Well, in /etc/net.cfg, I have a
route 192.168.2.254 0.0.0.0 0.0.0.0
but it makes no diff whether it's there or not.
And your suggested route -add 192.168.1/24 192.168.2.254 (/24 is not accepted, by the way) also made no diff.
The only op that makes the PC-to-box ping work, is the box-to-gateway ping. Can't say why - that's question #1.
And, again, why does it only help for a short while - what is it that times out and makes this go bad after a few
minutes? That's question #2
How can I make this work for good? That's question #3
Jacob
|
|
|
Sean Boudreau(deleted)
|
Re: ARP cache timeout issue, or...
|
Sean Boudreau(deleted)
03/18/2008 11:32 AM
post5903
|
Re: ARP cache timeout issue, or...
On Tue, Mar 18, 2008 at 11:16:53AM -0400, Jacob Dall wrote:
> > The traffic is 2 way. The PC might be able to reach the box
> > (the ping request may reach the box successfully) but the
> > box also needs a route back to send the reply. That's why I
> > said I can't see how it would ever work.
>
> Well, in /etc/net.cfg, I have a
> route 192.168.2.254 0.0.0.0 0.0.0.0
A default route doesn't show up in your 'route show' output.
>
> but it makes no diff whether it's there or not.
>
> And your suggested route -add 192.168.1/24 192.168.2.254 (/24 is not accepted, by the way) also made no diff.
Hmm, combination of older 'route' and malformation.
# route add -net 192.168.1.0 -netmask 0xffffff00 192.168.2.254
Or if you prefer
# route add default 192.168.2.254
>
> The only op that makes the PC-to-box ping work, is the box-to-gateway ping. Can't say why - that's question #1.
>
> And, again, why does it only help for a short while - what is it that times out and makes this go bad after a few
minutes? That's question #2
>
> How can I make this work for good? That's question #3
I can't think off hand what would cause 1-2. For 3 a route
back is needed.
-seanb
|
|
|
Jacob Dall
|
Re: ARP cache timeout issue, or...
|
Jacob Dall
03/19/2008 5:33 AM
post5932
|
Re: ARP cache timeout issue, or...
Nope, the suggested fix (route add...) for question #3 doesn't fix anything - still can't ping from PC to box.
I keep coming back to the box-to-gateway ping as the only solution to make the PC-to-box ping succeed....
Thanks, Sean, for your suggestions - I really appreciate it. I guess something in my system is not as you would expect.
I think, I one only could figure out what it is that the box-to-gateway ping does behind the scene, maybe one could
figure out how to make this issue go away.
Could be that this is in fact not an issue with the box itself, but with the wireless devices I'm using...
Jacob
|
|
|
Robert Craig
|
RE: ARP cache timeout issue, or...
|
Robert Craig
03/19/2008 10:56 AM
post5954
|
RE: ARP cache timeout issue, or...
Hi Jacob:
It really seems like the problem is on the gateway somehow.
At the end of the day, not only does the PC have to be able to get to the
box, the box has to be able to get back to the PC.
Just to be sure, is the access point set up to bridge traffic (i.e. not
route)?
Can you do a traceroute from the box to the PC and see what happens?
Can you confirm that the routing table contains the default route?
What happens to the ARP table on the gateway? Does the gateway do anything
peculiar like Proxy ARP or is it just doing straight routing?
-----Original Message-----
From: Jacob Dall [mailto:jd@eurisco.dk]
Sent: Wednesday, March 19, 2008 5:33 AM
To: technology-networking
Subject: Re: ARP cache timeout issue, or...
Nope, the suggested fix (route add...) for question #3 doesn't fix anything
- still can't ping from PC to box.
I keep coming back to the box-to-gateway ping as the only solution to make
the PC-to-box ping succeed....
Thanks, Sean, for your suggestions - I really appreciate it. I guess
something in my system is not as you would expect.
I think, I one only could figure out what it is that the box-to-gateway ping
does behind the scene, maybe one could figure out how to make this issue go
away.
Could be that this is in fact not an issue with the box itself, but with the
wireless devices I'm using...
Jacob
_______________________________________________
Technology
http://community.qnx.com/sf/go/post5932
|
|
|
Jacob Dall
|
RE: ARP cache timeout issue, or...
|
Jacob Dall
03/25/2008 5:51 AM
post6082
|
RE: ARP cache timeout issue, or...
Hello Robert,
> It really seems like the problem is on the gateway somehow.
I tend to agree - and then again, I don't. If it was a gateway issue, I
would not expect the PC-to-laptop ping to succeed - but it does, where
at the same time the PC-to-box ping fails. The laptop and box is
connected to the same switch in the opposite end of where the PC is
connected.
>
> At the end of the day, not only does the PC have to be able to get to
> the
> box, the box has to be able to get back to the PC.
I totally agree - but I'm not there yet.
>
> Just to be sure, is the access point set up to bridge traffic (i.e.
not
> route)?
I can't really tell - I don't have the option of one or the other.
>
> Can you do a traceroute from the box to the PC and see what happens?
Doing a traceroute from the PC to the box, I get
C:\>tracert 192.168.2.142
Tracing route to 192.168.2.142 over a maximum of 30 hops
1 3 ms 18 ms 2 ms 192.168.2.142
Trace complete.
Doing a traceroute from the box to the gateway, nothing happens -
besides getting a bunch of *.
> Can you confirm that the routing table contains the default route?
Upon power up (where the PC-to-box pin fails):
# route show
Routing tables
Internet:
Destination Gateway Flags
default 192.168.2.254 UG
localhost.localdo 127.0.0.1 UH
192.168.2.0 link#2 U
192.168.2.143 00:16:d3:57:96:46 UH
192.168.2.254 00:1c:f0:4e:71:9b UH
Note: 2.254 is the gateway and 2.143 is the laptop (from which I telnet
to the box)
Doing a box-to-gateway ping (that fails), the routing table shows no
difference, but now the PC-to-box ping succeeds.
>
> What happens to the ARP table on the gateway? Does the gateway do
> anything
> peculiar like Proxy ARP or is it just doing straight routing?
It's just setup for basic routing.
Thank you for your input,
Jacob
|
|
|
Jacob Dall
|
RE: ARP cache timeout issue, or...
|
Jacob Dall
03/25/2008 6:09 AM
post6083
|
RE: ARP cache timeout issue, or...
Problem solved :)
I did a factory reset of the gateway - and now things work as expected.
It seems like the gateway got an issue with its 'WAN Ping Respond' function. When ping respond is disabled, it not only
makes pinging of the gateway WAN side impossible. It also makes pinging from LAN-to-WAN impossible. And telnet as well.
That's REALLY smart...
Thanks, everyone, for your efforts.
Jacob
|
|
|
|