search

libremesh / lime-packages

LibreMesh packages configuring OpenWrt for wireless mesh networking
https://libremesh.org/
GNU Affero General Public License v3.0
278 stars 96 forks source link

Internet connectivity drops comes back again #346

Closed modante closed 5 years ago

modante commented 6 years ago

I have a mesh with this nodes topology: A(gateway) <> B <> C <> D A, B and C are connected through 5 GHz mesh wlan and C and D are connected through 2,4 GHz mesh wlan. They are connected in a linear form; this means that in order to get internet connection in C or D, B has to work fine.

The mesh with Nodes A, B and C has been working for 2 months without issues with clean installs of lime dayboot firmwares. Yesterday I added node D and did a clean reinstall of the firmwares in all the 4 routers and since them I got drops of internet connectivity continuously. When I saw to the tunnels of bmx6 in nodes B, C and D I saw that inet tunnel was empty. Disconnecting and connecting WAN interface on node A restored the tunnels in the rest of the net restoring the internet connectivity.

But I got this strange trouble a few minutes ago:

I tried different workarround from this script: https://github.com/libremesh/network-profiles/blob/master/openNET.io/1144-W2PA-LIME-XXXX/etc/uci-defaults/92-cron-workaround-tasks I tried manually all of them in the node B without success:

/etc/init.d/bmx6 reload ---> Nothing bmx6 -c tunouttimeout=20000; bmx6 -c tunouttimeout=20001 ---> Nothing /etc/init.d/dnsmasq stop; kill -9 cat /var/run/dnsmasq/dnsmasq*.pid; /etc/init.d/dnsmasq start ---> Nothing /etc/init.d/network reload ---> Nothing Only when I run /etc/init.d/network restart on B I got to revive it.

Any idea about these issues?

Notes: Node A: TL-WDR3500ND Node B: TL-WDR4300ND Node C: TL-WDR3600ND Node D: TL-WDR2543ND No any additional software installed in any of them (neither luci-proto-ppp in the node A that acts like gateway through the WAN port with pppoe)

modante commented 6 years ago

Ok. 40 hour after the cleaning made in all the nodes of the mesh, I can conclude that almost in all the cases what happens is that:

When all is working fine, in nodes B, C and D, in the list of "Gateways tunnel announcements" under BMX6 I can see this:

inet4p | LiMe-WDR3500 | Internet | 960 | 0.0.0.0/0 | 38279 | 442K | 1000 | 0.0.0.0/0 | LiMe-WDR3500. inet4 | LiMe-WDR3500 | Internet | 960 | 0.0.0.0/0 | 38279 | 36864 | 100 | 0.0.0.0/0 | .

But when there is no internet connectivity on nodes B, C and D, this two lines are empty. If I try all the workarounds (mentioned in the las post) in the nodes A and B, nothing changes, internet connectivity doesn't returns and the list of gateway tunnels remains empty. Only when I disconnect and connect WAN interface or run /etc/init.d/network restart on node A, the internet connectivity returns to all the nodes and the gateway tunnels lines returns to be filled with the right parameters.

Any idea of why is this happening? Could be caused by the adding of the D node? Why it worked fine before the cleaning (reflashing of all the routers deleting the configs) when I am doing the same I did 3 months ago? I flashed with the same firmwares and restored the configs manually in all the routers. Please help, I am really desperated and I don't know what to say to my neighbors :-/ Thank you very much :-)

gmarcos87 commented 6 years ago

I have a similar problem, and what I do is reboot the gateway's BMX (/etc/init.d/bmx6 restore). That seems to spread over the network again that that node is a gateway node. After about a minute all the nodes recover Intenret. If fails again, you can try to do that and let me know if he solves it. We may have the same problem.

I recommend you to use the mailing list, it seems to be much more active than the github issues https://lists.libremesh.org/mailman/listinfo/lime-users

modante commented 6 years ago

A new discovery. I ran a ping script in the node B in order to know exactly when internet connectivity dropped and the last pong was at this time:

Thu Apr 19 10:35:08 -03 2018: 64 bytes from 74.125.130.94: icmp_req=547 ttl=38

At 10:35:08 was the last pong. I adviced that Node A just rebooted at 10:31 I don't know why: Thu Apr 19 10:31:04 2018 kern.notice kernel: [ 0.000000] Linux version 4.4.71 (buildbot@builds-02.infra.lede-project.org) (gcc version 5.4.0 (LEDE GCC 5.4.0 r3101-bce140e) ) #0 Wed Jun 7 19:24:41 2017

This is the log of Node A just before the drop of connectivity:

Thu Apr 19 10:34:17 2018 daemon.info pppd[1325]: System time change detected.
Thu Apr 19 10:34:28 2018 daemon.info dnsmasq-dhcp[1840]: RTR-SOLICIT(anygw) 20:82:c0:39:f8:0b
Thu Apr 19 10:34:28 2018 daemon.info dnsmasq-dhcp[1840]: RTR-ADVERT(anygw) 2a00:1508:a0d:fe00::
Thu Apr 19 10:34:41 2018 cron.info crond[848]: USER root pid 1917 cmd /usr/bin/bmx6hosts_dnsmasq_update
Thu Apr 19 10:34:41 2018 cron.info crond[848]: USER root pid 1918 cmd if ping -c 5 -W 5 8.8.8.8 &> /dev/null; then logger -t workarounds 'ping frecuente a AguaditaGateway OK'; else logger -t workarounds '*ping frecuente* a torreunc FAIL. Recreando tuneles bmx6'; bmx6 -c tunouttimeout=20000; bmx6 -c tunouttimeout=20001; fi
Thu Apr 19 10:34:41 2018 cron.info crond[848]: USER root pid 1919 cmd if ping -c5 -w10 8.8.8.8; then if nslookup google.com 127.0.0.1 &>/dev/null; then logger -t workarounds 'OK. dnsmasq is alive'; else logger -t workarounds '*dnsmasq* FAIL. name resolution unsuccessful. Restarting the process'; /etc/init.d/dnsmasq stop; kill -9 2507; /etc/init.d/dnsmasq start; logger -t workarounds 'restarted zombie dnsmasq'; fi; else logger -t workarounds 'skipping dnsmasq check because Internet is unreachable'; fi
Thu Apr 19 10:34:42 2018 user.notice bmx6hosts: New bmx6 hosts found, updating dnsmasq
Thu Apr 19 10:34:42 2018 daemon.info dnsmasq[1840]: read /etc/hosts - 4 addresses
Thu Apr 19 10:34:42 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/bmx6 - 13 addresses
Thu Apr 19 10:34:42 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/dhcp.cfg02411c - 1 addresses
Thu Apr 19 10:34:42 2018 daemon.info dnsmasq-dhcp[1840]: read /etc/ethers - 0 addresses
Thu Apr 19 10:34:42 2018 daemon.info dnsmasq-dhcp[1840]: read /tmp/dhcp.hosts_remote
Thu Apr 19 10:34:45 2018 user.notice workarounds: ping frecuente a AguaditaGateway OK
Thu Apr 19 10:34:45 2018 user.notice workarounds: OK. dnsmasq is alive
Thu Apr 19 10:34:50 2018 daemon.info dnsmasq[1840]: read /etc/hosts - 4 addresses
Thu Apr 19 10:34:50 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/bmx6 - 13 addresses
Thu Apr 19 10:34:50 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/dhcp.cfg02411c - 1 addresses
Thu Apr 19 10:34:50 2018 daemon.info dnsmasq-dhcp[1840]: read /etc/ethers - 0 addresses
Thu Apr 19 10:34:50 2018 daemon.info dnsmasq-dhcp[1840]: read /tmp/dhcp.hosts_remote
Thu Apr 19 10:35:00 2018 cron.info crond[848]: USER root pid 1949 cmd /usr/sbin/smonit
Thu Apr 19 10:35:00 2018 cron.info crond[848]: USER root pid 1950 cmd ( for file in /etc/alfred/* ; do [ -x $file ] && $file ; done )
Thu Apr 19 10:35:00 2018 cron.info crond[848]: USER root pid 1951 cmd if ping -c 5 -W 5 8.8.8.8 &> /dev/null; then logger -t workarounds 'ping frecuente a AguaditaGateway OK'; else logger -t workarounds '*ping frecuente* a torreunc FAIL. Recreando tuneles bmx6'; bmx6 -c tunouttimeout=20000; bmx6 -c tunouttimeout=20001; fi
Thu Apr 19 10:35:00 2018 cron.info crond[848]: USER root pid 1952 cmd iw wlan0-ap scan
Thu Apr 19 10:35:00 2018 cron.info crond[848]: USER root pid 1953 cmd iw wlan1-mesh scan
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /etc/hosts - 4 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/d-d-h_64:66:b3:fa:a5:94 - 2 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/d-d-h_64:70:02:ed:f9:5e - 2 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/d-d-h_f8:d1:11:c4:6b:0b - 2 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/bmx6 - 13 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/dhcp.cfg02411c - 1 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq-dhcp[1840]: read /etc/ethers - 0 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq-dhcp[1840]: read /tmp/dhcp.hosts_remote
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /etc/hosts - 4 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/dnsmasq-lease-share - 12 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/d-d-h_64:66:b3:fa:a5:94 - 2 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/d-d-h_64:70:02:ed:f9:5e - 2 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/d-d-h_f8:d1:11:c4:6b:0b - 2 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/bmx6 - 13 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq[1840]: read /tmp/hosts/dhcp.cfg02411c - 1 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq-dhcp[1840]: read /etc/ethers - 0 addresses
Thu Apr 19 10:35:00 2018 daemon.info dnsmasq-dhcp[1840]: read /tmp/dhcp.hosts_remote
Thu Apr 19 10:35:04 2018 user.notice workarounds: ping frecuente a AguaditaGateway OK
Thu Apr 19 10:35:11 2018 daemon.info hostapd: wlan0-ap: STA 70:e7:2c:9a:54:a9 IEEE 802.11: authenticated
Thu Apr 19 10:35:11 2018 daemon.info hostapd: wlan0-ap: STA 70:e7:2c:9a:54:a9 IEEE 802.11: associated (aid 2)
Thu Apr 19 10:35:11 2018 daemon.notice hostapd: wlan0-ap: AP-STA-CONNECTED 70:e7:2c:9a:54:a9
Thu Apr 19 10:35:11 2018 daemon.info hostapd: wlan0-ap: STA 70:e7:2c:9a:54:a9 WPA: pairwise key handshake completed (RSN)
Thu Apr 19 10:35:40 2018 daemon.info dnsmasq-dhcp[1840]: RTR-SOLICIT(anygw) e8:93:09:d7:38:9e
Thu Apr 19 10:35:40 2018 daemon.info dnsmasq-dhcp[1840]: RTR-ADVERT(anygw) 2a00:1508:a0d:fe00::
Thu Apr 19 10:35:41 2018 daemon.info dnsmasq-dhcp[1840]: RTR-SOLICIT(anygw) e8:93:09:d7:38:9e
Thu Apr 19 10:35:41 2018 daemon.info dnsmasq-dhcp[1840]: RTR-ADVERT(anygw) 2a00:1508:a0d:fe00::
Thu Apr 19 10:35:42 2018 daemon.info dnsmasq-dhcp[1840]: RTR-SOLICIT(anygw) e8:93:09:d7:38:9e
Thu Apr 19 10:35:42 2018 daemon.info dnsmasq-dhcp[1840]: RTR-ADVERT(anygw) 2a00:1508:a0d:fe00::
Thu Apr 19 10:35:43 2018 daemon.info dnsmasq-dhcp[1840]: RTR-SOLICIT(anygw) e8:93:09:d7:38:9e
Thu Apr 19 10:35:43 2018 daemon.info dnsmasq-dhcp[1840]: RTR-ADVERT(anygw) 2a00:1508:a0d:fe00::
Thu Apr 19 10:35:44 2018 daemon.info dnsmasq-dhcp[1840]: RTR-SOLICIT(anygw) e8:93:09:d7:38:9e
Thu Apr 19 10:35:44 2018 daemon.info dnsmasq-dhcp[1840]: RTR-ADVERT(anygw) 2a00:1508:a0d:fe00::
Thu Apr 19 10:35:45 2018 daemon.info dnsmasq-dhcp[1840]: RTR-SOLICIT(anygw) e8:93:09:d7:38:9e
Thu Apr 19 10:35:45 2018 daemon.info dnsmasq-dhcp[1840]: RTR-ADVERT(anygw) 2a00:1508:a0d:fe00::
Thu Apr 19 10:35:45 2018 daemon.info dnsmasq-dhcp[1840]: RTR-SOLICIT(anygw) e8:93:09:d7:38:9e
Thu Apr 19 10:35:45 2018 daemon.info dnsmasq-dhcp[1840]: RTR-ADVERT(anygw) 2a00:1508:a0d:fe00::
Thu Apr 19 10:35:49 2018 daemon.info dnsmasq-dhcp[1840]: RTR-SOLICIT(anygw) e8:93:09:d7:38:9e
Thu Apr 19 10:35:49 2018 daemon.info dnsmasq-dhcp[1840]: RTR-ADVERT(anygw) 2a00:1508:a0d:fe00::
Thu Apr 19 10:35:53 2018 daemon.info dnsmasq-dhcp[1840]: RTR-SOLICIT(anygw) e8:93:09:d7:38:9e
Thu Apr 19 10:35:53 2018 daemon.info dnsmasq-dhcp[1840]: RTR-ADVERT(anygw) 2a00:1508:a0d:fe00::
Thu Apr 19 10:36:00 2018 cron.info crond[848]: USER root pid 2025 cmd /usr/bin/bmx6hosts_dnsmasq_update
Thu Apr 19 10:36:00 2018 cron.info crond[848]: USER root pid 2026 cmd if ping -c 5 -W 5 8.8.8.8 &> /dev/null; then logger -t workarounds 'ping frecuente a AguaditaGateway OK'; else logger -t workarounds '*ping frecuente* a torreunc FAIL. Recreando tuneles bmx6'; bmx6 -c tunouttimeout=20000; bmx6 -c tunouttimeout=20001; fi
Thu Apr 19 10:36:00 2018 cron.info crond[848]: USER root pid 2027 cmd if ping -c5 -w10 8.8.8.8; then if ping -c5 -w10 8.8.8.8; then logger -t workarounds 'OK. gateway reachable and Internet too'; else logger -t workarounds 'FAIL. gateway is reachable but Internet is not. *Reloading bmx6*'; /etc/init.d/bmx6 reload; fi; fi
Thu Apr 19 10:36:04 2018 user.notice workarounds: ping frecuente a AguaditaGateway OK
Thu Apr 19 10:36:08 2018 user.notice workarounds: OK. gateway reachable and Internet too
Thu Apr 19 10:37:00 2018 cron.info crond[848]: USER root pid 2060 cmd if ping -c 5 -W 5 8.8.8.8 &> /dev/null; then logger -t workarounds 'ping frecuente a AguaditaGateway OK'; else logger -t workarounds '*ping frecuente* a torreunc FAIL. Recreando tuneles bmx6'; bmx6 -c tunouttimeout=20000; bmx6 -c tunouttimeout=20001; fi
Thu Apr 19 10:37:04 2018 user.notice workarounds: ping frecuente a AguaditaGateway OK
Thu Apr 19 10:38:00 2018 cron.info crond[848]: USER root pid 2114 cmd if ping -c 5 -W 5 8.8.8.8 &> /dev/null; then logger -t workarounds 'ping frecuente a AguaditaGateway OK'; else logger -t workarounds '*ping frecuente* a torreunc FAIL. Recreando tuneles bmx6'; bmx6 -c tunouttimeout=20000; bmx6 -c tunouttimeout=20001; fi
modante commented 6 years ago

Thanks @gmarcos87 I will try this the next time. By now I am going to try something that I tried months ago related with an issue about whatchping (https://github.com/libremesh/lime-packages/issues/265)

modante commented 6 years ago

More tests: I have added sleep 10 to the /etc/init.d/watchping in order to give the enough time to the WAN connection on Node A to establish. When I add this sleep at the beginning of the watchping script, after rebooting the gateway tunnels propagates fine. If I don't add this line, after rebooting I have to manually disconnect and connect WAN in order to get the propagation.

#!/bin/sh /etc/rc.common
# Copyright (C) 2012 Gui Iribarren
# Copyright (C) 2017 Daniel Golle
# This is free software, licensed under the GNU General Public License v3.

sleep 10
START=99
USE_PROCD=1
PROG=/usr/bin/watchping

Before adding the sleep and after manually reboot node A, I tried to run /etc/init.d/bmx6 restart without success.

I hope this temporary fix will work. I'll pray for that.

Thanks :-)

modante commented 6 years ago

After 4 reboots with sleep 10 at the beginning of watchping script, I would say that the temporal workarround works. Now, after 7 hours without reboots in Node A (gateway) and internet connectivity in all the nodes, suddenly the inet4 in the "Gateways tunnel announcements" under BMX6 disappeared. Definitively, running /etc/init.d/bmx6 restart doesn't announces the inet4 tunnel. But running manually the script /etc/watchping/wan-ok.d/bmx6-gw made the trick. Instantaneously the inet4 tunnel was announced through the network and internet connectivity returned in all the nodes. this is what the script makes:

#!/bin/sh
logger -t bmx6-auto-gw "We got Internet access, announcing it to the mesh"
bmx6 -c tunOut -inet4
bmx6 -c tunIn inet4 /n 0.0.0.0/0

I am not so technical to understand well how watchping works, but I am afraid that something is not working properly with this script, at least on my setup. If anybody could help me would be great :-) Thank you very much.

modante commented 6 years ago

Back again with my homemade workarounds. I have added a line to the cron service in Node A (gateway) in order to announce the WAN each 3 minutes: /3 * /etc/watchping/wan-ok.d/bmx6-gw Probably is not very orthodox but is the further that I can get by myself and has been working the last 12 hours.

Off topic: @gmarcos87 asked me to post in the lime users mailing list and I did it. Then there somebody asked me to post in the lime devs mailing list that I don't know. The irc/matrix chat is not the right place for this. Resuming: Maybe there are too many places and the devs and users are too dispersed? Could be possible to rearrange and join the resources for a better integration and interaction?

Thanks and regards :-)

dangowrt commented 6 years ago

This bug is due to bmx6 (or bmx7) crashing and restarting and then loosing it's temporary settings created by the previous wan-up event. I guess the best would be to keep watchping's state and make sure it is re-applied when ever the routing daemon restarts for any reason -- of course it'd be desireable to have bmx not crash, and for that it'd also be great to know the cause of the crash. Maybe something like https://github.com/bmx-routing/bmx7/issues/20 ?

modante commented 6 years ago

@dangowrt ok I understand. By now I am going to keep my homemade workaround because I am not sure about how to get what you say. But is great to feel I am not alone :-) What I cannot understand is why didn't happened before the reflashing because I am recreating the same configuration! Thank you very much and regards :-)

axn commented 6 years ago

On 20.04.2018 16:53, Daniel Golle wrote:

This bug is due to bmx6 (or bmx7) crashing and restarting and then

Could anyone please give some evidence that bmx6 crashes? Like a logread dump that reports bmx6s crash (and ideally the bmx6 error code or even better a core dump?

loosing it's temporary settings created by the previous wan-up event. I guess the best would be to keep watchping's state and make sure it is re-applied when ever the routing daemon restarts for any reason -- of course it'd be desireable to have bmx not crash, and for that it'd also be great to know the cause of the crash.

Full ack

Maybe something like bmx-routing/bmx7#19 https://github.com/bmx-routing/bmx7/issues/19 ?

Have you seen this bug causing bmx6 to crash? The issue just reports that bmx6 detects wrong interface properties

axn commented 6 years ago

@dangowrt thx for https://github.com/bmx-routing/bmx7/issues/20

On 21.04.2018 10:06, Axel Neumann wrote:

On 20.04.2018 16:53, Daniel Golle wrote:

This bug is due to bmx6 (or bmx7) crashing and restarting and then

Could anyone please give some evidence that bmx6 crashes? Like a logread dump that reports bmx6s crash (and ideally the bmx6 error code or even better a core dump?

loosing it's temporary settings created by the previous wan-up event. I guess the best would be to keep watchping's state and make sure it is re-applied when ever the routing daemon restarts for any reason -- of course it'd be desireable to have bmx not crash, and for that it'd also be great to know the cause of the crash.

Full ack

Maybe something like bmx-routing/bmx7#19 https://github.com/bmx-routing/bmx7/issues/19 ?

Have you seen this bug causing bmx6 to crash? The issue just reports that bmx6 detects wrong interface properties

modante commented 6 years ago

@axn: Sorry but I don't have enough skill to answer your questions. If you give me details about which log you need I will paste it here. By now, the homemade workaround is working. Thanks and regards :-)

axn commented 6 years ago

I think I could fix the analogue problem for bmx7 [1,2]. Once I get some feedback if they work I'll backport to bmx6.

[1] https://github.com/bmx-routing/bmx7/issues/20#issuecomment-383291996 [2] https://github.com/bmx-routing/bmx7/issues/19#issuecomment-383298443

On 21.04.2018 14:58, Modante wrote:

@axn https://github.com/axn: Sorry but I don't have enough skill to answer your questions. If you give me details about which log you need I will paste it here. By now, the homemade workaround is working. Thanks and regards :-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libremesh/lime-packages/issues/346#issuecomment-383293811, or mute the thread https://github.com/notifications/unsubscribe-auth/ABQQnpf2mZ1RPwO6g1kQE_oNGDDwqNu6ks5tqy0RgaJpZM4Ta55x.

modante commented 6 years ago

I think I could fix the analogue problem for bmx7 [1,2]. Once I get some feedback if they work I'll backport to bmx6.

I can test it if you publish the package or whatever.

axn commented 6 years ago

If no more problems with the bmx7 fixes ( https://github.com/bmx-routing/bmx7/commits/fixes ) are reported today i'll work on the bmx6 backports packages this evening

Am 23. April 2018 23:05:00 MESZ schrieb Modante notifications@github.com:

I think I could fix the analogue problem for bmx7 [1,2]. Once I get some feedback if they work I'll backport to bmx6.

I can test it if you publish the package or whatever.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/libremesh/lime-packages/issues/346#issuecomment-383722643

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

axn commented 6 years ago

For bmx6 you could test by using the lede-17.01 feed from here: https://github.com/bmx-routing/openwrt-routing-packages.git If you can report that it works stable i can fix that upstream. Later I'll also provide a bmx6 version bump for openwrt-routing master branch

Am 23. April 2018 23:05:00 MESZ schrieb Modante notifications@github.com:

I think I could fix the analogue problem for bmx7 [1,2]. Once I get some feedback if they work I'll backport to bmx6.

I can test it if you publish the package or whatever.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/libremesh/lime-packages/issues/346#issuecomment-383722643

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

modante commented 6 years ago

@axn: sorry but I don't have skills to install the new bmx patched version without any help. If anybody can explain me how should I proceed, I have some time these days to test it. Is there any ipk to install? Or should I compile anything? Because I don't know how to compile on lede.

ghost commented 6 years ago

@modante I think I can assist on that:

Try this guide I wrote: https://github.com/guifi-exo/wiki/blob/master/howto/lime-sdk.md

To select a particular bmx6 commit: https://github.com/guifi-exo/wiki/blob/master/howto/openwrt_template.md#how-to-use-a-particular-bmx6-commit

(feedback about clarity is appreciated)

Looks like lede-17.01 feed is the default feed in lime-sdk

root@host:~/lime-sdk/feeds/routing/bmx6# git branch
* lede-17.01
modante commented 6 years ago

@pedro-nonfree sorry but still I am lost about how to get bmx patched in order to test it in my setup. I have no skill in git, branches, compilations, and all this stuff and the links you gave me doesn't help me because I would need to start from almost zero :-( Thanks and regards :-)

nicopace commented 6 years ago

I think this got already patched, so you can try doing ./cooker --update-communities --update-feeds and then rebuild the packages with ./cooker -b ` before you rebuild your images.

ilario commented 5 years ago

Updates?

ilario commented 5 years ago

As this seems to be BMX6 related and quite old issue, I'm closing.