OLSR mesh GUI $400 {awarded}
-
" Its starting just fine here. "
I need to discover what setting I changed to cause that then. Perhaps it was assigning Wan to ethernet interface and Lan to wifi interface. I'll do some investigating. -
Try starting olsrd from the console.
I believe the command is olsrd -f /var/etc/olsrd.conf (but I cannot check at the moment)
-
I think I discovered the when/why issue #14 occurs: When the IP/netmask of an interface is improperly set to conflict/overlap with the IP/netmask of another interface, and "Enable Dynamic Gateway" is checked, olsr won't start.
I'm still having problems with issue#10, though.
I look forward to pfSense getting RIP; setting up routes for the non-olsr systems is quite burdensome.
Thanks, -Pete -
To solve issue #10:
Add a check box for "Announce self as Dynamic Gateway" underneath "Enable Dynamic Gateway".
The following line found in olsr.conf should only exist if "Announce self as Dynamic Gateway" is checked:
0.0.0.0 0.0.0.0
Thank you, -Pete -
I
I look forward to pfSense getting RIP; setting up routes for the non-olsr systems is quite burdensome.
Thanks, -Petea route for a non olsrd system you setup with the hna config
adding
10.0.1.0 255.255.255.0
adds a route to 10.0.1.0/24 tru the olsrd server
10.0.1.1 255.255.255.255 adds a olsrd route to pc 10.0.1.1 tru the olsrd server
this you have to do only on the server that nows the route to the non olsrd network or pc
and the olsrd server will let the other olsrd servers now tru hna that tose pc's /networks can be found tru him -
A very handy tip, jeroen234!
Unfortunately, in pfSense imbedded, edits to /var/etc/olsr.conf are Not persisting after reboot. After editing, I deleted /tmp/config.cache but it didn't help. Is there any way to get around this? Or, could a field such as "Announce Dynamic local routes: [IP/Netmask]" be added to the GUI so I don't have to edit the file? This would be added directly below where the "0.0.0.0 0.0.0.0" entry in olsr.conf.
Thanks, -Pete -
Summary Post:
Our tests of OLSR in pfSense are going well, and it appears to be solid. I can go ahead and Award the second half of the Bounty if we can resolve these remaining issues (mostly mundane revisions to gui/config):10. This fixes issue#10:
Add a check box for "Announce [self as] Dynamic Gateway" underneath "Enable [reception of] Dynamic Gateway" in the OLSR config.
The following line found in olsr.conf should only exist if "Announce [self as] Dynamic Gateway" is checked:
0.0.0.0 0.0.0.015. In the OLSR GUI, I recommend making Link Quality Level "2" the default.
16. Please add a field such as "Announce Dynamic local route: [enter IP / Netmask]" in the OLSR GUI (these values should be inserted into olsr.conf directly below the "0.0.0.0 0.0.0.0" entry). Thanks jeroen234!
17. Please allow in the DHCP GUI, a manually entered Netmask, when OLSR is enabled on that interface.
(the purpose of this is to force a node's non-olsr ad-hoc wifi clients to route through the current node as a gateway onto olsr, so it may communicate with nodes that are otherwise out-of-range for non-olsr wifi clients when they use the netmask of the interface).18. Please advise us on how to manually edit/tweak the olsr.conf config, so that changes remain after reboot on imbedded version. At some point in the future we may want to alter values, such as: Willingness and Weight. If this isn't possible, please add more detail fields to the gui.
19. I'm not quite sure how other olsr implimentations do this but… when a "Ping" host is specified in the OLSR GUI, only when ping fails should "Enable [reception of] Dynamic Gateway" be overwriting the default route, and when the ping succeeds, the default route should be set to the specified "Ping" host (or pfSense default route, aka Gateway, specified in the WAN GUI?). Also, at times when there are no Dynamic Gateways being received from the OLSR mesh, instead of deleting the default route in the route table thus leaving no default route, it should set it back to the default route, aka Gateway, specified in the pfSense WAN GUI (or the "Ping" host?). Please advise if this is impossible or if you have no control over any of this.
Thank you,
- Internet Professionals, LLC
- Pete
-
We'll up the total bounty payout to $400 if the issues directly above can be resolved within a week, and made available in an imbedded snapshot/beta shortly thereafter.
Thank you,- Internet Professionals, LLC
- Pete
-
10. This fixes issue#10:
Add a check box for "Announce [self as] Dynamic Gateway" underneath "Enable [reception of] Dynamic Gateway" in the OLSR config.
The following line found in olsr.conf should only exist if "Announce [self as] Dynamic Gateway" is checked:
0.0.0.0 0.0.0.0Done.
15. In the OLSR GUI, I recommend making Link Quality Level "2" the default.
Done.
16. Please add a field such as "Announce Dynamic local route: [enter IP / Netmask]" in the OLSR GUI (these values should be inserted into olsr.conf directly below the "0.0.0.0 0.0.0.0" entry). Thanks jeroen234!
Done.
17. Please allow in the DHCP GUI, a manually entered Netmask, when OLSR is enabled on that interface.
(the purpose of this is to force a node's non-olsr ad-hoc wifi clients to route through the current node as a gateway onto olsr, so it may communicate with nodes that are otherwise out-of-range for non-olsr wifi clients when they use the netmask of the interface).Done.
18. Please advise us on how to manually edit/tweak the olsr.conf config, so that changes remain after reboot on imbedded version. At some point in the future we may want to alter values, such as: Willingness and Weight. If this isn't possible, please add more detail fields to the gui.
This is not so easy, its auto generated on each bootup.
19. I'm not quite sure how other olsr implimentations do this but… when a "Ping" host is specified in the OLSR GUI, only when ping fails should "Enable [reception of] Dynamic Gateway" be overwriting the default route, and when the ping succeeds, the default route should be set to the specified "Ping" host (or pfSense default route, aka Gateway, specified in the WAN GUI?). Also, at times when there are no Dynamic Gateways being received from the OLSR mesh, instead of deleting the default route in the route table thus leaving no default route, it should set it back to the default route, aka Gateway, specified in the pfSense WAN GUI (or the "Ping" host?). Please advise if this is impossible or if you have no control over any of this.
This is out of our control.
-
We'll up the total bounty payout to $400 if the issues directly above can be resolved within a week, and made available in an imbedded snapshot/beta shortly thereafter.
Thank you,- Internet Professionals, LLC
- Pete
I'll have an update for you shortly.
-
My, that was fast! Thank you Scott!
" This is not so easy, its auto generated on each bootup. "
I see, could anything at all be accomplished by adding xml hooks in /cf/conf/config.xml ?
If not, I think we can live with simply having "Weight" added to the olsr gui (though, this could be a little complicated for the gui because a distinct weight should be specified for each interface that olsr is enabled on).
Will test the next imbedded snapshot/beta as soon as I see it, and paypal the bounty.Thanks, -Pete
-
I would copy the file /var/etc/olsrd.conf to /root and then add a script to /usr/local/etc/rc.d/ to copy the file back on bootup.
Something like this:
#!/bin/sh
cp /root/olsrd.conf /var/etc/
killall olsrd
olsrd -f /var/etc/olsrd.conf -
If it allows me to edit olsr.conf without causing any problems for you, me or other users using the olsr gui… seems good to me. I don't know if I realize all the effects that code will have. Will we be able to edit the file then make changes in the olsr gui without undoing our manual edits?
-
If it allows me to edit olsr.conf without causing any problems for you, me or other users using the olsr gui… seems good to me. I don't know if I realize all the effects that code will have. Will we be able to edit the file then make changes in the olsr gui without undoing our manual edits?
You can simply copy /var/etc/olsrd.conf /root/ after making changes to pfSense, then edit the file in /root/ to add or change those settings.
I am uploading a test embedded image to: http://www.pfsense.com/~sullrich/0/pfSense-pc.img.gz
It will be uploaded 10 minutes from the posting of this message.
-
17. Setting the DHCP Netmask caused DHCP not to start. After selecting a Netmask and clicking [Save], the next page showed two Netmask fields:
On the GUI…
Subnet 10.128.0.0
Subnet mask 255.248.0.0
Available range 10.128.0.0 - 10.135.255.255
Subnet Mask [24]
Range [10.130.1.10] to [10.130.1.254]From the logs…
May 17 06:16:13 dhcpd: /var/dhcpd/etc/dhcpd.conf line 9: too few numbers.
May 17 06:16:13 dhcpd: /var/dhcpd/etc/dhcpd.conf line 9: too few numbers.
May 17 06:16:13 dhcpd: subnet 10.128.0.0 netmask 24 {
May 17 06:16:13 dhcpd: subnet 10.128.0.0 netmask 24 {
May 17 06:16:13 dhcpd: ^
May 17 06:16:13 dhcpd: ^
May 17 06:16:13 dhcpd: Configuration file errors encountered -- exiting
May 17 06:16:13 dhcpd: Configuration file errors encountered -- exiting16. I tried setting "Announce Dynamic Local Route" to both "10.130.1.0 255.255.255.0" and "10.130.1.0/255.255.255.0", but OLSR failed to start with either setting. I tried looking in /var/etc/olsr.conf but I didn't see the values anywhere.
-
17. Setting the DHCP Netmask caused DHCP not to start. After selecting a Netmask and clicking [Save], the next page showed two Netmask fields:
On the GUI…
Subnet 10.128.0.0
Subnet mask 255.248.0.0
Available range 10.128.0.0 - 10.135.255.255
Subnet Mask [24]
Range [10.130.1.10] to [10.130.1.254]From the logs…
May 17 06:16:13 dhcpd: /var/dhcpd/etc/dhcpd.conf line 9: too few numbers.
May 17 06:16:13 dhcpd: /var/dhcpd/etc/dhcpd.conf line 9: too few numbers.
May 17 06:16:13 dhcpd: subnet 10.128.0.0 netmask 24 {
May 17 06:16:13 dhcpd: subnet 10.128.0.0 netmask 24 {
May 17 06:16:13 dhcpd: ^
May 17 06:16:13 dhcpd: ^
May 17 06:16:13 dhcpd: Configuration file errors encountered -- exiting
May 17 06:16:13 dhcpd: Configuration file errors encountered -- exitingOk, that should be fixed.
16. I tried setting "Announce Dynamic Local Route" to both "10.130.1.0 255.255.255.0" and "10.130.1.0/255.255.255.0", but OLSR failed to start with either setting. I tried looking in /var/etc/olsr.conf but I didn't see the values anywhere.
Are you sure? It should be in there if it suddenly doesn't start.
-
Very sure. I've tried it and looked in /var/etc/olsr.conf more than five times now just to be sure. I tried these combinations "10.130.1.0/255.255.255.0", "10.130.1.0 255.255.255.0", "10.130.1.0 / 255.255.255.0", "10.130.1.0/24" many times each with no start. One odd thing, I tried setting it to just "10.130.1.0" and also "10.130.1.0 / 24" and the service started, however there is still no sign of "10.130.1.0" in /var/etc/olsr.conf … perhaps this file isn't getting updated? As a side note, I did notice that the "Announce [self as] Dynamic Gateway" (from issue#10) is properly adding and removing the "0.0.0.0 0.0.0.0" entry from olsr.conf. (other than sometimes leaving Hna4 {} empty, see post below)
-
olsr doesn't start when "Announce self as Dynamic Gateway" is Unchecked; perhaps it doesn't like the empty Hna4 { } section as below, so I guess this Hna4{ } section should be absent from the config (or auto-commented out) when ( "Announce [self as] Dynamic Gateway" unchecked AND "Announce Dynamic Local Route" is empty ):
Hna4
{}
It may be more consistant with other forms to change this entry field to two fields with drop-down on the second like:
"Announce Dynamic Local Route IP: [10.130.1.0] / [24]"
Thank you,
-Pete -
olsr doesn't start when "Announce self as Dynamic Gateway" is Unchecked; perhaps it doesn't like the empty Hna4 { } section as below, so I guess this Hna4{ } section should be absent from the config (or auto-commented out) when ( "Announce [self as] Dynamic Gateway" unchecked AND "Announce Dynamic Local Route" is empty ):
Hna4
{}
Done.
It may be more consistant with other forms to change this entry field to two fields with drop-down on the second like:
"Announce Dynamic Local Route IP: [10.130.1.0] / [24]"
Thank you,
-PeteHrm. I'll look into it.
-
17. DHCP is Not functioning when I choose smaller subnet mask in the drop-down box; Right now, it only works when I chose a large enough subnet to encompass both the interface subnet AND my chosen dhcp range:
My Interface IP address & netmask: 10.130.1.1 / 13
DHCP GUI:
Subnet 10.128.0.0
Subnet mask 255.248.0.0
Available range 10.128.0.0 - 10.135.255.255
Subnet Mask [24] <– I entered this.
Range [10.130.1.10] to [10.130.1.254] <– I entered these.I tried to change the subnet mask drop down box to "24" but it failed to serve dhcp and I got the following error lines in the system log {below}. 10.130.1/24 is within the "Available Range" of 10.128/13 (10.128.0.0 - 10.135.255.255), but the logs indicate that DHCP server's validation routine thinks it's available address range to serve should be limited to 10.128/24 when the Netmask is set to [24] … It appears that the DHCP server's validation checking is incorrectly applying the custom Netmask (/24) to the "Available Range" (10.128) instead of correctly validating against either the entered "Range" (10.130) OR interface IP/netmask.
System Logs...
May 18 06:44:15 dhcpd: Address range 10.130.1.10 to 10.130.1.254 not on net 10.128.0.0/255.255.255.0!
May 18 06:44:15 dhcpd: Address range 10.130.1.10 to 10.130.1.254 not on net 10.128.0.0/255.255.255.0!Since I want to set up each olsr node to serve different class-c (/24) range within the common interface range of 10.128/13, I can't be limited to only the first class-c 10.128.0.0/255.255.255.0 within the 10.128/13 range. I've never configured a DHCP server so I'm unsure what setting changes to suggest; perhaps "Subnet" field could be made changable from the default of "10.128.0.0" to either the first "Range" value "10.130.1.10" OR the interface IP/netmask OR allow me to manually enter it? If you run out of ideas, I wonder if there is there a way to simply tell the dhcp server Not to do it's Netmask validation checking, and just push my desired settings out "as is" to the dhcp client.
update: In another forum discussion, it was determined that it may not be possible to change the first two dhcp values "Subnet: 10.128.0.0" & "Subnet mask: 255.248.0.0" (which are also the actual interface subnet & subnet mask) in dhcp.conf, not even to subset values such as: "10.130.1.0/255.255.255.0". If you verify this as true, perhaps I could get around this problem by turning on pfSense DHCP Forwarding and serving the DHCP from another more flexible system; and also if true, could you verify that pfSense gui permits me to enable dhcp forwarding to the WAN interface? Thanks, -Pete