ARPing
-
I'm learning as I go with my new pfsense box and having managed to get it up and running with all my Firewall and NAT rules I decided to start testing the network. When I ping any host on my network using the ARPing package, it comes back with:
ARPING 192.168.1.2
60 bytes from 02:18:e5:00:09:0b (192.168.1.2): index=0 time=131.845 usec
60 bytes from 02:18:e5:00:09:0b (192.168.1.2): index=1 time=25.034 usec–- 192.168.1.2 statistics ---
3 packets transmitted, 2 packets received, 33% unanswered (0 extra)Even though everything seems to be working ok, I take it that this means it's not as reliable or quick as it should be. I'm just wondering what steps I need to take to identify where the problem is and how exactly to rectify it. Could someone point me in the right direction please : )
And thanks for all the help on here that I've received so far, it's been spot on!
-
are these hosts your pinging wireless? you got your first arp back, and your second one - so how many do you miss if you let it run for a while?
-
I'm just using the Arping tool in services. There's no option to let it run, I'm basically just entering different IP's of hosts on my network and they all come back as above.
-
Try running it at the command line:
[2.1.5-RELEASE][root@pfsense.fire.box]/root(5): arping 192.168.4.13 ARPING 192.168.4.13 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=0 time=249.147 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=1 time=7.868 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=2 time=5.960 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=3 time=10.014 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=4 time=7.153 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=5 time=11.921 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=6 time=10.967 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=7 time=12.159 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=8 time=7.153 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=9 time=7.153 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=10 time=9.060 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=11 time=6.199 usec ^C --- 192.168.4.13 statistics --- 13 packets transmitted, 12 packets received, 8% unanswered (0 extra)I'm seeing one lost probe both at the CLI and GUI.
Arping first sends a broadcast packet and then unicast packets which I assume explains the initial much longer response time.
Steve
-
Interersting, if you do this:
[2.1.5-RELEASE][root@pfsense.fire.box]/root(21): arping -c 10 -u 192.168.4.13 ARPING 192.168.4.13 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=0/0 time=274.181 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=1/2 time=6.199 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=2/3 time=6.914 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=3/4 time=5.960 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=4/5 time=7.868 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=5/6 time=5.960 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=6/7 time=5.960 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=7/8 time=7.153 usec 60 bytes from 00:13:d4:1b:b8:da (192.168.4.13): index=8/9 time=5.960 usec --- 192.168.4.13 statistics --- 10 packets transmitted, 9 packets received, 10% unanswered (0 extra)You can see it's actually the second packet sent (send index 1) that isn't replied to.
Steve
-
How do I stop it arping? lol
I've typed arping 192.168.1.16 from a telnet session and I can't stop it now.
Ok had to reboot to stop it, is there a command to only do a few lines, the arping -c 10 -u command wouldn't work for me for some reason.
-
Ctrl+C to stop it. That's what the '^C' is in my output.
I forget, are you running 2.1.5 or 2.2?Steve
-
Yes it just looks as though every time there's a packet dropped but it would make sense i suppose if it's the initial packet that's transmitted. So I guess this looks ok?
-
Well it looks the same as I'm seeing, whether that's ok or not…... ;)
As I said above using the '-u' switch it looks like the second packet that fails. I have no explanaition for that. The first or last packets would seem more likely suspects. The first unicast packet? :-\Steve
-
I think I'm almost there with everything I need it to do now. I've managed to get OpenVPN setup along with IPVanish today. It's taken me literally all weekend but I've now got specific traffic such as my torrent server and FreeNAS system all going out through a separate VPN gateway. My PC and laptop connect through the normal WAN interface.
I've made sure I've got a back up of the config, I'd hate to have to start from scratch again, I don't actually know how or what settings got some of the services working! :o
I'm going to continue playing around with it though there's more I want to learn, although I've already realised my box isn't powerful enough for what I'm going to need. I guess it's fine for the basics, firewall and NAT stuff but now I've got openvpn and also snort installed, the cpu usage is maxed out at 100% and I'm also seeing latency on the VPN gateway. It's only got a Intel Celeron M processor 600MHz, with 2gb ddr2 ram, although the memory seems sufficient.
Anyway, thanks for all your help Stephen, it's been spot on and also much appreciated. I'm sure I'll be back with more questions in the near future ;D
-
So using the arping under services.. I have pinged multiple physical machines, multiple vms on multiple segments even and not seeing any losses.
I am on the 2.2 snapshot as of yesterday..
-
I've just updated to 2.2 and it seems to have resolved it.
