Garbled apinger messages in the system log
-
This may be a side effect of the ipv6 code. I haven't heard of that happening on a stock 2.0 image, and there are probably several places in the ipv6 where such a buglet may have slipped in. I moved the thread to the ipv6 board in case someone else there might have seen it.
-
Not sure if this is related to the IPv6 code at all. Never seen it before though.
-
Not sure if this is related to the IPv6 code at all. Never seen it before though.
I thought since apinger was reporting the garbled message and the apinger application on my system is dated 2009 that it probably was more an apinger problem than a problem in the IPv6 mods. But maybe the IPv6 mods touch a file used by apinger in a way that causes confusion in apinger.
-
Here are the current apinger configuration file and status file.
It is perhaps curious that though there are 4 targets in the configuration file (SROUTE1 seemingly duplicating SROUTE0) there seem to be only 3 entries in the status file.
more /var/etc/apinger.conf
pfSense apinger configuration file. Automatically Generated!
User and group the pinger should run as
user "root"
group "wheel"Mailer to use (default: "/usr/lib/sendmail -t")
#mailer "/var/qmail/bin/qmail-inject"
Location of the pid-file (default: "/var/run/apinger.pid")
pid_file "/var/run/apinger.pid"
Format of timestamp (%s macro) (default: "%b %d %H:%M:%S")
#timestamp_format "%Y%m%d%H%M%S"
status {
## File where the status information whould be written to
file "/tmp/apinger.status"
## Interval between file updates
## when 0 or not set, file is written only when SIGUSR1 is received
interval 5s
}########################################
RRDTool status gathering configuration
Interval between RRD updates
rrd interval 60s;
These parameters can be overriden in a specific alarm configuration
alarm default {
command on "/usr/local/sbin/pfSctl -c 'filter reload'"
command off "/usr/local/sbin/pfSctl -c 'filter reload'"
combine 10s
}"Down" alarm definition.
This alarm will be fired when target doesn't respond for 30 seconds.
alarm down "down" {
time 10s
}"Delay" alarm definition.
This alarm will be fired when responses are delayed more than 200ms
it will be canceled, when the delay drops below 100ms
alarm delay "delay" {
delay_low 200ms
delay_high 500ms
}"Loss" alarm definition.
This alarm will be fired when packet loss goes over 20%
it will be canceled, when the loss drops below 10%
alarm loss "loss" {
percent_low 10
percent_high 20
}target default {
## How often the probe should be sent
interval 1s
## How many replies should be used to compute average delay
## for controlling "delay" alarms
avg_delay_samples 10
## How many probes should be used to compute average loss
avg_loss_samples 50## The delay (in samples) after which loss is computed
## without this delays larger than interval would be treated as loss
avg_loss_delay_samples 20## Names of the alarms that may be generated for the target
alarms "down","delay","loss"## Location of the RRD
#rrd file "/var/db/rrd/apinger-%t.rrd"
}
target "121.50.212.5" {
description "GW_WAN"
srcip "203.144.5.171"
alarms override "loss","delay","down";
rrd file "/var/db/rrd/GW_WAN-quality.rrd"
}target "192.168.211.217" {
description "SROUTE0"
srcip "192.168.211.173"
alarms override "loss","delay","down";
rrd file "/var/db/rrd/SROUTE0-quality.rrd"
}target "192.168.211.217" {
description "SROUTE1"
srcip "192.168.211.173"
alarms override "loss","delay","down";
rrd file "/var/db/rrd/SROUTE1-quality.rrd"
}target "2001:470:1f04:14b3::1" {
description "HE_NET"
srcip "2001:470:1f04:14b3::2"
alarms override "loss","delay","down";
rrd file "/var/db/rrd/HE_NET-quality.rrd"
}more /tmp/apinger.status
sh<91><ed>|?
<dd>?<bc>t<93>^X^DV<d6>?^_<85><eb>Q<b8>^^<d5>?'<ac>^\Z<e0>?ESC/</e0></ac></d5></b8></eb></d6></bc></dd>
<dd>$^F<81><d5>?<d1>"<db><f9>~j<e0>?^Y^DV^N- <b2><d5>? <c5><b0>rh<91></b0></c5></d5></b2></e0></f9></db></d1></d5></dd>
<dd>?|203.144.5.171|GW_WAN|56|55|1299819488|40.422ms||none
192.168.211.217|192.168.211.173|SROUTE1|56|55|1299819488|0.473ms||none
2001:470:1f04:14b3::1|2001:470:1f04:14b3::2|HE_NET|56|0|0|0.000ms||down
#</dd></ed>I guess the two apinger targets seemingly the same are from two static routes: 192.168.217.0/24 and 192.168.51.0/24 are both accessible through 192.168.211.217.
-
Looks like the entry with 203.144.5.171 is corrupt, that "sh …" stuff shouldn't be there. It should look like the other lines.
Side note: The timestamp is kept on some files even if their contents have been updated. It's unlikely that your apinger binary is really from 2009.
-
Ok, that is a upgrade bug that exists in 2.0-RC1. When we originally wrote the static route upgrade code it appears we've forgotten to collapse the routes by target. This is a clear bug.
2 routes pointing to the same IP should always result in a single target. This was clearly a oversight.
Is this a install upgraded from 1.2.3 or is this a upgrade from a 2.0-RC or BETA install
-
Is this a install upgraded from 1.2.3 or is this a upgrade from a 2.0-RC or BETA install
Upgrade from 1.2.3 through various 2.0 BETA snapshot builds.
-
Aha! That explains it
-
Can you please provide the 1.2.3 config static route section?
-
Create a 1.2.3 vm, create 2 routes to a lan IP. Upgrade that and it should trigger it
