FANDOM



* WdsAndNagios
* WdsvsAp

{{{ Found solution for WDS problem but need help on ascript Look at Nagios. Depending on how you set up the firewalling you may have to use passive checks. You will have to dummy up a "force fail" active check for your passive checks if you want to be notified if it hasn't checked in within an interval time.Beware. It takes a while to get going on Nagios. But it's well worth it when you do. Read ALL the docs at least once. Also, spend time looking through the standard plugins and the contrib plugins. There are a ton of them.I've used Netsaint, Nagios' predecesor, for about three years. I'm still in the process of switching from one to the other. So I'm useing both rght now.

Has anyone used a script like this for simple monitoring of the nodes to send an email if a ping fails? Could you use a sendmail command if the return value is 0? How else are people monitoring their nodes? I looked at Don's SNMP document, but without creating a VPN session to the mesh, I don't see how you can monitor the downlink nodes (with 1.x.x.x addresses) I'd like to hear how others are handling real time network monitoring.


begin script -----
  1. !/bin/sh # Simple Ping Test Utility.
  2. Usage : " ./pingtest.sh xxx.xxx.xxx.xxx " where x denotes the numeric ip
  3. address of the target machine you wish to test.
  4. The ping utility has a return value of 0 on failure or a value of 1 or
  5. greater upon success. The Standard output has been redirected to the

/dev/null

  1. device as we do not need to see or log it when the script is run from

cron.

  1. Command line options to the ping utility as used here.
  2. -w 5 Time out and fail after 5 seconds regardless of the number of
  3. replies received.
  4. -n return only numeric values ( not strictly necessary but possibly
  5. reduces overhead).
  6. -q quiet mode ( self explanatory )
  7. -c 4 restrict the number of ping requests to 4 then exit.

if [ "$1" != "" ]; then ping -w 5 -n -q -c 4 $1 >> /dev/null if [ $? != 0 ] ; then echo "Failed" # Change this to run a command on failure else echo "Sucess" # comment this echo out if you dont need it i.e.

  1. you only run a command on failure.

fi else echo "No IP Address Supplied" fi --- end script ----

  1. !/bin/sh
  2. Simple Ping Test Utility.
  3. Usage : "./pingtest.sh xxx.xxx.xxx.xxx " where x denotes the numeric
  4. IP address of the target machine you wish to test.
  5. The ping utility has a return value of 0 on failure or a value of 1 or
  6. greater upon success. The Standard output has been redirected to the
  7. /dev/null device as we do not need to see or log it when the script is
  8. run from cron.
  9. Command line options to the ping utility as used here.
  10. -w 5 Time out and fail after 5 seconds regardless of the number of
  11. replies received.
  12. -n return only numeric values ( not strictly necessary but possibly
  13. reduces overhead).
  14. -q quiet mode ( self explanatory )
  15. -c 4 restrict the number of ping requests to 4 then exit.

if [ "$1" != "" ]; then ping -w 5 -n -q -c 4 $1 >> /dev/null if [ $? != 0 ] ; then echo "Failed" # Change this to run a command on failure else echo "Sucess"

  1. comment this echo out if you dont need it i.e.
  2. you only run a command on failure.

fi else echo "No IP Address Supplied" fi

On Wed, 2004-09-22 at 00:01, Wes wrote: I have found the problem / solution. It seem that when the 54G router restarts it fails to trigger something on the LW side to rejoin. So I did a little snooping around in the mysterious HJ folder and I ran across the wscan script. This kicks of a scan to rejoin between AP's. This rejoins the LW node to the 54G AP and everything is happy again. Now for the help from some of you script guru's. I need an example of a script that will ping an IP address and if it fails then an action is taken. I would set the crontab to kick of this scrip every 5 minutes or so and if it didn't see the 54G ip address it would then call the wscan script in the HJ directory. Can anybody point me in the right direction or send me an example? I must say I love how flexible Linux is :) Now all this is preliminary, I don't know how wscan will effect the node when you have other LW nodes connected and you run wscan, that is tonight's pot of coffee. Subject: [MeshAPdev] update on WDS problem I have watched the LW node after rebooting the 54G router and thiS is what I am getting from "dmesg" 1.251.125.53@meshbox:~# dmesg handle_ap_item - addr3(BSSID)=00:0f:66:ba:5e:64 not own MAC handle_ap_item - addr3(BSSID)=00:0f:66:ba:5e:64 not own MAC handle_ap_item - addr3(BSSID)=00:0f:66:ba:5e:64 not own MAC handle_ap_item - addr3(BSSID)=00:0f:66:ba:5e:64 not own MAC handle_ap_item - addr3(BSSID)=00:0f:66:ba:5e:64 not own MAC handle_ap_item - addr3(BSSID)=00:0f:66:ba:5e:64 not own MAC 1.251.125.53@meshbox:~# The 5e:64 MAC is the 54G router. I can reboot only the LW node and

everything works after that :O( So it looks like something is getting stuck in LW but I am not sure what.

Wes Subject: Re: [MeshAPdev] question about a WDS problem Sorry if you received a msg a few times...something was wrong with my Computer. If you didn't receive it, here's a short recap: - there is no routing between the Linksys and the lwbox, only bridging. check both bridge tables before and after rebooting the linksys. (man brctrl or brctl...don't remember) Suggestion: The linksys may only be accepting passive wds links while the lw box actively looks to connect through wds So when you boot the Linksys does nothing, while when you boot the LW it goes out and looks for friends and the Linksys passively accepts a request.. You must enable active wds negotiation for the Linksys or just add the mac address of the LW box to the Linksys' list of wds friends.


Wes wrote: I am currently connecting with WDS only as far as I know. I am not using tunneling just my ssid, wep and wds. Let me elaborate some, I have a LW node that is giving out 192.168.170.x as its local ip range. The wiana ip address is 1.251.125.53 and it is running on 25dev85. The wrt54g is running Alchemy pre 5.3 and the router address is 192.168.170.2 with it's dhcp turn off. I have set the WDS settings on the wrt54g to link with the LW node and the link work fine and anybody connecting to the wrt54g will hit the LW node's dhcp and get an address. This also register the clients MAC on the LW node fulfilling all the requirements for bandthwith control and authentication. The issue arrases when the wrt54g reboots, it can't reconnect with the LW node. This problem seems to be with the LW node at this point. I can leave the wrt54g running and reboot the LW node all day without issue and the WDS link is automatically recreated, but when rebooting the wrt54g something seems to stick in the LW node. I have watched all the files I know to watch "AP and WDS in the proc/net/hostap/wlan0 directory" and it looks like they are functioning correctly but not connection after the original link unless you reboot the LW node. I will include all info requested below and anything else I can think of and thanks for the replies. I hope if this works so I can have a "mesh lite" unit for small clusters of users with out the high price of a regular node. The wrt54g use a 200 mhz processor with a broadcom G wireless card. The mesh lite outdoor unit should run about 125 dollars ready to install and acts as an AP thus increasing your coverage area, this is my motivation. :O)

1.251.125.53@meshbox:~# netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:5280 *:* LISTEN tcp 0 0 *:51010 *:* LISTEN tcp 0 0 *:10085 *:* LISTEN tcp 0 0 *:domain *:* LISTEN tcp 0 0 *:ssh *:*

LISTEN tcp 0 0 *:pptp *:* LISTEN tcp 0 76 192.168.1.101:ssh 192.168.1.100:3639 ESTABLISHED udp 0 0 1.251.125.53:654 *:* udp 0 0 *:domain *:* udp 0 0 *:bootps *:* raw 0 0 *:icmp *:* 7 raw 0 0 1.251.125.53:255 *:* 7 Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 9 [ ] DGRAM 391 /dev/log unix 2 [ ] DGRAM 43380 unix 2 [ ] DGRAM 13990 unix 2 [ ] DGRAM 3200 unix 2 [ ] DGRAM 2837 unix 2 [ ] DGRAM 1358 unix 3 [ ] STREAM CONNECTED 1067 unix 3 [ ] STREAM CONNECTED 1066 unix 2 [ ] DGRAM 1064 unix 2 [ ] DGRAM 322 1.251.125.53@meshbox:~#

1.251.125.53@meshbox:~# ifconfig br0 Link encap:Ethernet HWaddr 00:09:5B:74:01:B7 inet addr:1.251.125.53 Bcast:1.255.255.255

Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3653 errors:0 dropped:0 overruns:0 frame:0 TX packets:6548 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:239808 (234.1 Kb) TX bytes:1070408 (1.0 Mb) br0:1 Link encap:Ethernet HWaddr 00:09:5B:74:01:B7 inet addr:192.168.170.1 Bcast:192.168.170.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth0 Link encap:Ethernet HWaddr 00:00:24:C1:FF:94 inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10340 errors:0 dropped:0 overruns:0 frame:0 TX packets:16940 errors:2 dropped:0 overruns:2 carrier:2 collisions:0 txqueuelen:100 RX bytes:3955816 (3.7 Mb) TX bytes:3484378 (3.3 Mb) Interrupt:11 Base address:0x5000

lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:786 errors:0 dropped:0 overruns:0 frame:0 TX packets:786 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:65736 (64.1 Kb) TX bytes:65736 (64.1 Kb)

wlan0 Link encap:Ethernet HWaddr 00:09:5B:74:01:B7 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:2741 overruns:0 frame:0 TX packets:5432 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:543402 (530.6 Kb) Interrupt:10 Memory:c4833000-c4834000

wlan0wds0 Link encap:Ethernet HWaddr 00:09:5B:74:01:B7 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3719 errors:0 dropped:518 overruns:0 frame:0 TX packets:6499 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:294910 (287.9 Kb) TX bytes:1353386 (1.2 Mb) Interrupt:10 Memory:c4833000-c4834000

PING 192.168.170.2 (192.168.170.2): 56 data bytes 64 bytes from 192.168.170.2: icmp_seq=0 ttl=64 time=8.660 ms 64 bytes from 192.168.170.2: icmp_seq=1 ttl=64 time=4.034 ms 64 bytes from 192.168.170.2: icmp_seq=2 ttl=64 time=4.192 ms --- 192.168.170.2 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.034/5.629/8.660/2.144 ms

1.251.125.53@meshbox:~# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 1.251.125.53 1.251.125.53 255.255.255.255 UGH 40 0 }}}

links Edit

MeshNetworking

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.