[lime-users] Gateways fail to be offered on latest chef builds

List overview All Threads
Download

newer

older

[lime-users] DIY signal boosters

[lime-users] LiMe FAQ

Paul Harmor

4 Mar 2018 4 Mar '18

5:08 p.m.

After weeks of trial and error and troubleshooting on several different Chef builds (1x ar71xx/wndr3700v2, 3x x86 of all different hardware), default LiMe 802.11s profile, I've come to the conclusion that watchping or some other link in the chain is failing to offer the gateway. At any time, if any node loses WAN uplink, it and it's clients will sit without internet for hours, while still communicating with all other nodes and machines on the network. After some chat in the dev channel, the fact that I was using USB WiFi devices as WAN interfaces, set up with the LEDE/OPENWRT default WWAN iface name, became suspect as the cause. Unfortunately however, neither changing the reference in the watchping settings in /etc/config/system, nor changing WWAN to WAN as the actual interface used made any difference. The nodes CAN communicate (thus not the usual "can't ping" bug), Uplink is recognized as lost by watchping, but the node with one does not ever offer it up. Once again, this is with the default 802.11s profile, meaning BMX6. I have not yet tried BMX7, as I'm not sure how to migrate from one to the other in place.

Attachments:

attachment.html (text/html — 1.3 KB)

Show replies by date

Nicolas Pace

12 Mar 12 Mar

12:02 p.m.

On Sun, 2018-03-04 at 17:08 +0000, Paul Harmor wrote:

...

Hi Paul! Despite your scenario is not the straightforward one (having a usb wifi interface as WAN), if this is a common scenario it would be good to have it included. Please, do share with us a little bit more on why you have that setup so we can understand the case!

...

At any time, if any node loses WAN uplink, it and it's clients will sit without internet for hours, while still communicating with all other nodes and machines on the network.

Based on https://github.com/libremesh/lime-packages/blob/develop/packages/watchp ing/files/etc/uci-defaults/90_watchping watchping should be trying to test the connection every 20s and if inet found (by pinging google's dns 8.8.8.8 host) will run triggers. If you have a vanilla libremesh setup, that means it will run this: https://github.com/libremesh/lime-packages/blob/develop/packages/bmx6-a uto-gw-mode/files/etc/watchping/wan-ok.d/bmx6-gw and by doing so configuring bmx6 to be aware of that route to internet for both your local device and your networks. If the network falls, this gets run: https://github.com/libremesh/lime-packages/blob/develop/packages/bmx6-a uto-gw-mode/files/etc/watchping/wan-fail.d/bmx6-gw so it should change the path it takes to go to internet to one neighbour of yours.

...

After some chat in the dev channel, the fact that I was using USB WiFi devices as WAN interfaces, set up with the LEDE/OPENWRT default WWAN iface name, became suspect as the cause. Unfortunately however, neither changing the reference in the watchping settings in /etc/config/system, nor changing WWAN to WAN as the actual interface used made any difference. The nodes CAN communicate (thus not the usual "can't ping" bug), Uplink is recognized as lost by watchping, but the node with one does not ever offer it up.

Based on this: https://github.com/libremesh/lime-packages/blob/55a063678fc570000ceb99b 9382ed22ccda8fce3/packages/watchping/files/etc/uci- defaults/90_watchping#L6 it uses the interface wan for the check... so if you add your interface to it should do.

...

Once again, this is with the default 802.11s profile, meaning BMX6. I have not yet tried BMX7, as I'm not sure how to migrate from one to the other in place.

Paul Harmor

14 Mar 14 Mar

4:19 a.m.

You'll have to forgive me where I sound like a smart-ass. It happens. The FitPC2i (the current and best x86 machine I have for the purpose) that I'm presently using has NOTHING BUT USB wifi capability. The BUILT-IN interface is a USB rt2070-based radio. ANYTHING ELSE is going to be USB also (since there is no PCI expansion capability). But, it DID NOT MATTER whether or not the FitPC was the host I used, and now I can state that BMX 6/7 mattered not, or even no BMX at all (batman-adv only in use right this moment, STILL no autogw functionality). The autogw functionality is BROKEN! At least from my perspective, as someone who would dd=of several usb / sd medium, for distribution throughout my community for the sake of EXACTLY WHAT MESH NETWORKING IS SUPPOSED TO BE ABOUT... On Mon, Mar 12, 2018 at 6:02 AM, Nicolas Pace <nico(a)libre.ws> wrote:

...

On Sun, 2018-03-04 at 17:08 +0000, Paul Harmor wrote:

At any time, if any node loses WAN uplink, it and it's clients will sit without internet for hours, while still communicating with all other nodes and machines on the network.

Once again, this is with the default 802.11s profile, meaning BMX6. I have not yet tried BMX7, as I'm not sure how to migrate from one to the other in place.

BMX7 is not the default on LibreMesh, so you should not expect better support there than on the default one. Can you send the output of logread regarding this things? Try to see what watchping says, it should be saying like the ones here: https://github.com/libremesh/lime-packages/blob/develop/packages/watchp ing/files/usr/bin/watchping#L63 Regards, _______________________________________________ lime-users mailing list lime-users(a)lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users

Paul Spooren

11:36 a.m.

Hi, I can't completely follow your setup but if I understood correctly the problem is the following? Your device is connected via WWAN but it doesn't announce it to the rest of the network? Did you manually ping 8.8.8.8? Did you manually announce the uplink connection by running /etc/watchping/wan-ok/bmx6-gw or bmx7-gw? Best On Mi, Mär 14, 2018 at 5:19 AM, Paul Harmor <psharmor(a)gmail.com> wrote:

...

On Sun, 2018-03-04 at 17:08 +0000, Paul Harmor wrote:

After weeks of trial and error and troubleshooting on several different Chef builds (1x ar71xx/wndr3700v2, 3x x86 of all

different

hardware), default LiMe 802.11s profile, I've come to the

conclusion

that watchping or some other link in the chain is failing to offer the gateway.

At any time, if any node loses WAN uplink, it and it's clients will sit without internet for hours, while still communicating with all other nodes and machines on the network.

After some chat in the dev channel, the fact that I was using USB WiFi devices as WAN interfaces, set up with the LEDE/OPENWRT

default

WWAN iface name, became suspect as the cause. Unfortunately

however,

neither changing the reference in the watchping settings in /etc/config/system, nor changing WWAN to WAN as the actual

interface

used made any difference. The nodes CAN communicate (thus not the usual "can't ping" bug), Uplink is recognized as lost by watchping, but the node with one does not ever offer it up.

Once again, this is with the default 802.11s profile, meaning

BMX6. I

have not yet tried BMX7, as I'm not sure how to migrate from one to the other in place.

Paul Harmor

15 Mar 15 Mar

3:40 p.m.

This is now resolved. All of the things you suggested Paul, had been done, and then some. Manually announcing the Gateway would sometimes cause it to come up under bmx6, but once I switched to BMX7 even that would not happen. In the end, the solution came from installing an image on each directly downloaded from libremesh.org, instead of built on the chef server. Seems the chef server is building them broken. On Wed, Mar 14, 2018, 05:36 Paul Spooren <spooren(a)informatik.uni-leipzig.de> wrote:

...

On Sun, 2018-03-04 at 17:08 +0000, Paul Harmor wrote:

After weeks of trial and error and troubleshooting on several different Chef builds (1x ar71xx/wndr3700v2, 3x x86 of all

different

hardware), default LiMe 802.11s profile, I've come to the

conclusion

that watchping or some other link in the chain is failing to offer the gateway.

At any time, if any node loses WAN uplink, it and it's clients will sit without internet for hours, while still communicating with all other nodes and machines on the network.

After some chat in the dev channel, the fact that I was using USB WiFi devices as WAN interfaces, set up with the LEDE/OPENWRT

default

WWAN iface name, became suspect as the cause. Unfortunately

however,

neither changing the reference in the watchping settings in /etc/config/system, nor changing WWAN to WAN as the actual

interface

used made any difference. The nodes CAN communicate (thus not the usual "can't ping" bug), Uplink is recognized as lost by watchping, but the node with one does not ever offer it up.

Once again, this is with the default 802.11s profile, meaning

BMX6. I

have not yet tried BMX7, as I'm not sure how to migrate from one to the other in place.

_______________________________________________ lime-users mailing list lime-users(a)lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users

bruno vianna

8:54 p.m.

...

In the end, the solution came from installing an image on each directly downloaded from libremesh.org, instead of built on the chef server. Seems the chef server is building them broken.

Paul Harmor

9:53 p.m.

Well damn, Bruno... Horrible and ugly as this may sound, glad I wasn't the only one. But why did nobody seem to have any clue of the issue? I've been struggling with this for weeks now, and chatting about it for over a week, and nobody seemed to be aware of what you and I experienced with the chef builds. I was very clear about the fact that I was building from chef, and nobody said a word about it being a known issue. I VERY much agree, that the chef server should either be taken offline, or at the VERY LEAST no longer linked from the main page of libremesh.org, until these issues have been resolved. Hopefully by experience (and publicizing of it) will get the ball rolling in the right direction, on that. On Thu, Mar 15, 2018 at 2:54 PM, bruno vianna <bruno(a)pobox.com> wrote:

...

In the end, the solution came from installing an image on each directly

downloaded from libremesh.org, instead of built on the chef server. Seems the chef server is building them broken.

We had the same experience at the installations we've made. IMHO, the new chef should be off-line until these issues are worked out. It's been creating a frustrating experience for many users. On the other hand, the lime-sdk cooker script is working really well. Bruno _______________________________________________ lime-users mailing list lime-users(a)lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users

Daniel Golle

16 Mar 16 Mar

4:41 a.m.

Hi! On Thu, Mar 15, 2018 at 03:53:37PM -0600, Paul Harmor wrote:

...

I also saw that gateway detection now doesn't work well with bmx7 and investigated the issue and it's much more simple than you think: The hook in /etc/watchping/wan-ok.d/bmx7-gw gets called before bmx7 is even up and running in case the wan interface is being brought up too quickly during boot. To work-around that issue, please try the patch below and let me know if it resolved the issue for you as well diff --git a/packages/bmx7-auto-gw-mode/files/etc/watchping/wan-fail.d/bmx7-gw b/packages/bmx7-auto-gw-mode/files/etc/watchping/wan-fail.d/bmx7-gw index cfb9e2e..988aa3d 100755 --- a/packages/bmx7-auto-gw-mode/files/etc/watchping/wan-fail.d/bmx7-gw +++ b/packages/bmx7-auto-gw-mode/files/etc/watchping/wan-fail.d/bmx7-gw @@ -1,4 +1,12 @@ #!/bin/sh +timeout=60 +while ! bmx7 -c -v 2>&1 >/dev/null ; do + logger -t bmx7-auto-gw "waiting for bmx7 to come up..." + sleep 1 + timeout=$((timeout - 1)) + [ $timeout -lt 1 ] && break +done + logger -t bmx7-auto-gw "Searching Internet access into the mesh" bmx7 -c tunIn -inet4 bmx7 -c tunOut inet4 /network 0.0.0.0/0 /maxPrefixLen 0 diff --git a/packages/bmx7-auto-gw-mode/files/etc/watchping/wan-ok.d/bmx7-gw b/packages/bmx7-auto-gw-mode/files/etc/watchping/wan-ok.d/bmx7-gw index a55f532..592c904 100755 --- a/packages/bmx7-auto-gw-mode/files/etc/watchping/wan-ok.d/bmx7-gw +++ b/packages/bmx7-auto-gw-mode/files/etc/watchping/wan-ok.d/bmx7-gw @@ -1,4 +1,12 @@ #!/bin/sh +timeout=60 +while ! bmx7 -c -v 2>&1 >/dev/null ; do + logger -t bmx7-auto-gw "waiting for bmx7 to come up..." + sleep 1 + timeout=$((timeout - 1)) + [ $timeout -lt 1 ] && break +done + logger -t bmx7-auto-gw "We got Internet access, announcing it to the mesh" bmx7 -c tunOut -inet4 bmx7 -c tunIn inet4 /n 0.0.0.0/0 ---

...

I VERY much agree, that the chef server should either be taken offline, or at the VERY LEAST no longer linked from the main page of libremesh.org, until these issues have been resolved. Hopefully by experience (and publicizing of it) will get the ball rolling in the right direction, on that. On Thu, Mar 15, 2018 at 2:54 PM, bruno vianna <bruno(a)pobox.com> wrote: > > In the end, the solution came from installing an image on each directly >> downloaded from libremesh.org, instead of built on the chef server. >> Seems the chef server is building them broken. >> >> > > We had the same experience at the installations we've made. IMHO, the new > chef should be off-line until these issues are worked out. It's been > creating a frustrating experience for many users. > > On the other hand, the lime-sdk cooker script is working really well. > > Bruno > > _______________________________________________ > lime-users mailing list > lime-users(a)lists.libremesh.org > https://lists.libremesh.org/mailman/listinfo/lime-users >

...

_______________________________________________ lime-users mailing list lime-users(a)lists.libremesh.org https://lists.libremesh.org/mailman/listinfo/lime-users

2226

days inactive

2238

days old

lime-users@lists.libremesh.org

Manage subscription

7 comments

5 participants

tags (0)

participants (5)

bruno vianna
Daniel Golle
Nicolas Pace
Paul Harmor
Paul Spooren