25 Oct
2020
25 Oct
'20
9:11 a.m.
Model ZBT-APE522II
Architecture MediaTek MT7620A ver:2 eco:6
Firmware Version LiMe master development (master rev. 0e6dbe1f
20201019_1851) / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01
Kernel Version 4.14.195
The device is connected to the ISP router and gets IP via DHCP
Ping of the network diagnostic is successful
No internet for clients
Where to look at?
--
Regards
Jürgen
25 Oct
25 Oct
2:21 p.m.
On 10/25/20 10:11 AM, Juergen Kimmel wrote:
The device is connected to the ISP router and gets IP
via DHCP
Ping of the network diagnostic is successful
No internet for clients
Where to look at?
I suppose this happened after disabling the firewall?
I gave the wrong suggestion: disabling the firewall removes also needed
rules.
The good way to avoid the firewall rule causing the Babeld error is to
either not install the firewall package in the first place (deselecting
it from the menuconfig, as indicated in the Development page on the
website).
Maybe there is also some other way, but to not include the firewall
package is the easiest solution.
The best way would be to understand why this happens and fix it here:
https://github.com/libremesh/lime-packages/issues/787
Ciao!
Ilario
5:54 p.m.
I'm quite sure I deselected the firewall from the menuconfig
But I Got this:
root@d948:~# opkg info firewall
Package: firewall
Version: 2019-11-22-8174814a-3
Depends: libc, libubox20191228, libubus20191227, libuci20130104, libip4tc2,
libip6tc2, libxtables12, kmod-ipt-core, kmod-ipt-conntrack,
kmod-nf-conntrack6, kmod-ipt-nat
Status: install user installed
Architecture: mipsel_24kc
Conffiles:
/etc/config/firewall
303d858071dfcf1d1e8593168eb9c582a2c774211f23cef4bf7c85e4060a5e8c
/etc/firewall.user
bd68324966481011f5e36570258ad97dd422655c16f3119d48325ed8459de510
Installed-Time: 1603568532
and from syslog:
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.094941] ------------[ cut
here ]------------
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.099684] WARNING: CPU: 0
PID: 0 at net/sched/sch_generic.c:320 0x802c39c0
Sun Oct 25 18:45:27 2020 kern.info kernel: [11130.106901] NETDEV WATCHDOG:
eth0 (mtk_soc_eth): transmit queue 0 timed out
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.114000] Modules linked
in: rt2800soc rt2800mmio rt2800lib batman_adv rt2x00soc rt2x00mmio
rt2x00lib nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt76 mac80211
iptable_nat ipt_REJECT ipt_MASQUERADE ebtable_nat ebtable_filter
ebtable_broute cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport
xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT
xt_LOG xt_FLOWOFFLOAD xt_CT nf_reject_ipv4 nf_nat_redirect
nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4
nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4
nf_conntrack_rtcache nf_conntrack macvlan libcrc32c iptable_mangle
iptable_filter ip_tables ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype
ebt_mark_m ebt_mark ebt_limit ebt_ip6 ebt_among ebt_802_3 crc_ccitt compat
nf_log_ipv6 nf_log_common
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.186554] ip6table_mangle
ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 leds_gpio
gpio_button_hotplug crc16 crc32c_generic crypto_hash
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.200716] CPU: 0 PID: 0
Comm: swapper Not tainted 4.14.195 #0
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.206763] Stack : 8046dee0
80054358 80480000 8042d258 00000000 00000000 00000000 00000000
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.215318] 00000000
00000000 00000000 00000000 00000000 00000001 87c07de0 ac07f5da
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.223856] 87c07e78
00000000 00000000 00003c40 00000038 803ccd58 00000008 00000000
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.232409] 00000000
80460000 0003100c 00000000 87c07dc0 00000000 00000000 8042710c
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.240971] 802c39c0
00000140 8046df34 8046def4 00000002 80213fc0 00000000 805b0000
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.249525] ...
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.252022] Call Trace:
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.252034] [<80054358>]
0x80054358
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.258129] [<803ccd58>]
0x803ccd58
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.261697] [<802c39c0>]
0x802c39c0
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.265273] [<80213fc0>]
0x80213fc0
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.268841] [<8000aa50>]
0x8000aa50
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.272397] [<8000aa58>]
0x8000aa58
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.275977] [<80026480>]
0x80026480
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.279543] [<802c39c0>]
0x802c39c0
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.283107] [<80026508>]
0x80026508
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.286701] [<802c39c0>]
0x802c39c0
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.290258] [<8003ac4c>]
0x8003ac4c
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.293823] [<802c385c>]
0x802c385c
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.297395] [<8005ffcc>]
0x8005ffcc
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.300954] [<800012fc>]
0x800012fc
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.304521] [<800601a0>]
0x800601a0
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.308099] [<877a0350>]
0x877a0350 [rt2x00lib@877a0000+0x8890]
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.314152] [<803d2808>]
0x803d2808
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.317724] [<8005a554>]
0x8005a554
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.321281] [<80055ab0>]
0x80055ab0
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.324840] [<80005e90>]
0x80005e90
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.328407]
Sun Oct 25 18:
45:27 2020 kern.warn kernel: [11130.329925] ---[ end trace 1a3f678b5f3667e0
]---
Am So., 25. Okt. 2020 um 15:22 Uhr schrieb Ilario Gelmetti <
iochesonome(a)gmail.com>gt;:
On 10/25/20 10:11 AM, Juergen Kimmel wrote:
The device is connected to the ISP router and
gets IP via DHCP
Ping of the network diagnostic is successful
No internet for clients
Where to look at?
I suppose this happened after disabling the firewall?
I gave the wrong suggestion: disabling the firewall removes also needed
rules.
The good way to avoid the firewall rule causing the Babeld error is to
either not install the firewall package in the first place (deselecting
it from the menuconfig, as indicated in the Development page on the
website).
Maybe there is also some other way, but to not include the firewall
package is the easiest solution.
The best way would be to understand why this happens and fix it here:
https://github.com/libremesh/lime-packages/issues/787
Ciao!
Ilario
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users 
6:32 p.m.
On Sun, Oct 25, 2020 at 06:54:37PM +0100, Juergen Kimmel wrote:
I'm quite sure I deselected the firewall from the
menuconfig
But I Got this:
root@d948:~# opkg info firewall
Package: firewall
Version: 2019-11-22-8174814a-3
Depends: libc, libubox20191228, libubus20191227, libuci20130104, libip4tc2,
libip6tc2, libxtables12, kmod-ipt-core, kmod-ipt-conntrack,
kmod-nf-conntrack6, kmod-ipt-nat
Status: install user installed
Architecture: mipsel_24kc
Conffiles:
/etc/config/firewall
303d858071dfcf1d1e8593168eb9c582a2c774211f23cef4bf7c85e4060a5e8c
/etc/firewall.user
bd68324966481011f5e36570258ad97dd422655c16f3119d48325ed8459de510
Installed-Time: 1603568532
and from syslog:
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.094941] ------------[ cut
here ]------------
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.099684] WARNING: CPU: 0
PID: 0 at net/sched/sch_generic.c:320 0x802c39c0
Sun Oct 25 18:45:27 2020 kern.info kernel: [11130.106901] NETDEV WATCHDOG:
eth0 (mtk_soc_eth): transmit queue 0 timed out
This is usually caused by the built-in switch not being setup
properly. Ie. please see 'swconfig dev switch0' and check your switch
setup in /etc/config/network.
If you can't figure it out, please retest with stock OpenWrt and
compare the switch configuration with what you got in
/etc/config/network.
26 Oct
26 Oct
11:07 a.m.
I learned from the config.buildinfo that firewall has not been selected
The settings of the switches are identical.
May disabling the firewall have been the culprit?
I flashed the same device again there is no error and client has internet.
Am So., 25. Okt. 2020 um 19:32 Uhr schrieb Daniel Golle <
daniel(a)makrotopia.org>gt;:
On Sun, Oct 25, 2020 at 06:54:37PM +0100, Juergen
Kimmel wrote:
I'm quite sure I deselected the firewall
from the menuconfig
But I Got this:
root@d948:~# opkg info firewall
Package: firewall
Version: 2019-11-22-8174814a-3
Depends: libc, libubox20191228, libubus20191227, libuci20130104,
libip4tc2,
libip6tc2, libxtables12, kmod-ipt-core,
kmod-ipt-conntrack,
kmod-nf-conntrack6, kmod-ipt-nat
Status: install user installed
Architecture: mipsel_24kc
Conffiles:
/etc/config/firewall
303d858071dfcf1d1e8593168eb9c582a2c774211f23cef4bf7c85e4060a5e8c
/etc/firewall.user
bd68324966481011f5e36570258ad97dd422655c16f3119d48325ed8459de510
Installed-Time: 1603568532
and from syslog:
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.094941] ------------[
cut
here ]------------
Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.099684] WARNING: CPU: 0
PID: 0 at net/sched/sch_generic.c:320 0x802c39c0
Sun Oct 25 18:45:27 2020 kern.info kernel: [11130.106901] NETDEV
WATCHDOG:
eth0 (mtk_soc_eth): transmit queue 0 timed out
This is usually caused by the built-in switch not being setup
properly. Ie. please see 'swconfig dev switch0' and check your switch
setup in /etc/config/network.
If you can't figure it out, please retest with stock OpenWrt and
compare the switch configuration with what you got in
/etc/config/network.
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
27 Oct
27 Oct
8:14 p.m.
On Mon, Oct 26, 2020 at 12:07:24PM +0100, Juergen Kimmel wrote:
I learned from the config.buildinfo that firewall has
not been selected
The settings of the switches are identical.
May disabling the firewall have been the culprit?
I flashed the same device again there is no error and client has internet.
Ah, of course, without any firewall installed there is also no
NAT / masquerading happening, so if you want that, you do need
something to configure that (such as OpenWrt's 'firewall' package').
Am So., 25. Okt. 2020 um 19:32 Uhr schrieb Daniel Golle <
daniel(a)makrotopia.org>gt;:
> On Sun, Oct 25, 2020 at 06:54:37PM +0100, Juergen Kimmel wrote:
> > I'm quite sure I deselected the firewall from the menuconfig
> >
> > But I Got this:
> > root@d948:~# opkg info firewall
> > Package: firewall
> > Version: 2019-11-22-8174814a-3
> > Depends: libc, libubox20191228, libubus20191227, libuci20130104,
> libip4tc2,
> > libip6tc2, libxtables12, kmod-ipt-core, kmod-ipt-conntrack,
> > kmod-nf-conntrack6, kmod-ipt-nat
> > Status: install user installed
> > Architecture: mipsel_24kc
> > Conffiles:
> > /etc/config/firewall
> > 303d858071dfcf1d1e8593168eb9c582a2c774211f23cef4bf7c85e4060a5e8c
> > /etc/firewall.user
> > bd68324966481011f5e36570258ad97dd422655c16f3119d48325ed8459de510
> > Installed-Time: 1603568532
> >
> > and from syslog:
> >
> >
> > Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.094941] ------------[
> cut
> > here ]------------
> > Sun Oct 25 18:45:27 2020 kern.warn kernel: [11130.099684] WARNING: CPU: 0
> > PID: 0 at net/sched/sch_generic.c:320 0x802c39c0
> > Sun Oct 25 18:45:27 2020 kern.info kernel: [11130.106901] NETDEV
> WATCHDOG:
> > eth0 (mtk_soc_eth): transmit queue 0 timed out
>
> This is usually caused by the built-in switch not being setup
> properly. Ie. please see 'swconfig dev switch0' and check your switch
> setup in /etc/config/network.
> If you can't figure it out, please retest with stock OpenWrt and
> compare the switch configuration with what you got in
> /etc/config/network.
> _______________________________________________
> 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
8:25 p.m.
Hi!
On 10/27/20 5:14 PM, Daniel Golle wrote:
On Mon, Oct 26, 2020 at 12:07:24PM +0100, Juergen
Kimmel wrote:
AFAIK we recommend in the docs to use the package lime-hwd-openwrt-wan that selects
lime-proto-wan.
This package provides the NATing rules without the need of the firewall package.
Daniel maybe you are not using lime-proto-wan in your deploys? Juergen do you have the
lime-proto-wan selected?
Maybe the automatic selection that is donde by lime-hwd-openwrt-wan is not working in this
device?
Best!
SAn
I learned from the config.buildinfo that
firewall has not been selected
The settings of the switches are identical.
May disabling the firewall have been the culprit?
I flashed the same device again there is no error and client has internet.
Ah, of course, without any firewall installed there is also no
NAT / masquerading happening, so if you want that, you do need
something to configure that (such as OpenWrt's 'firewall' package').
8:43 p.m.
On Tue, Oct 27, 2020 at 05:25:32PM -0300, SAn via lime-users wrote:
Hi!
On 10/27/20 5:14 PM, Daniel Golle wrote:
It never matched my requirements and I never saw a reason not to use
OpenWrt's firewall package. I've heard some vague myths about OpenWrt's
firewall not working well with some of the routing protocols used in
libremesh, but all attempts to reproduce that or inquire what the
problem was or is remained without substancial results.
I guess there are some historic reasons for some people to still
hestitate using OpenWrt's firewall (ie. fw3 nowadays), maybe some bug
which has long been resolved or simply not (auto-)adding the rules
needed to also run routing protocols on the WAN interface (which I've
fixed some years ago).
On Mon, Oct 26, 2020 at 12:07:24PM +0100, Juergen
Kimmel wrote:
AFAIK we recommend in the docs to use the package lime-hwd-openwrt-wan that selects
lime-proto-wan.
This package provides the NATing rules without the need of the firewall package. I learned from the config.buildinfo that
firewall has not been selected
The settings of the switches are identical.
May disabling the firewall have been the culprit?
I flashed the same device again there is no error and client has internet.
Ah, of course, without any firewall installed there is also no
NAT / masquerading happening, so if you want that, you do need
something to configure that (such as OpenWrt's 'firewall' package').
Daniel maybe you are not using lime-proto-wan in your deploys? Juergen do you have the
lime-proto-wan selected?
Maybe the automatic selection that is donde by lime-hwd-openwrt-wan is not working in
this device?
Best!
SAn
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
28 Oct
28 Oct
8:49 a.m.
*Juergen do you have the lime-proto-wan selected *
Yes
Am Di., 27. Okt. 2020 um 21:44 Uhr schrieb Daniel Golle <
daniel(a)makrotopia.org>gt;:
On Tue, Oct 27, 2020 at 05:25:32PM -0300, SAn via
lime-users wrote:
that
selects lime-proto-wan.
Hi!
On 10/27/20 5:14 PM, Daniel Golle wrote:
> On Mon, Oct 26, 2020 at 12:07:24PM +0100, Juergen Kimmel wrote:
>> I learned from the config.buildinfo that firewall has not been
selected
>> The settings of the switches are
identical.
>> May disabling the firewall have been the culprit?
>> I flashed the same device again there is no error and client has
internet.
Ah, of course, without any firewall installed there is also no
NAT / masquerading happening, so if you want that, you do need
something to configure that (such as OpenWrt's 'firewall' package').
AFAIK we recommend in the docs to use the package lime-hwd-openwrt-wan This package provides the NATing rules without
the need of the firewall
package.
It never matched my requirements and I never saw a reason not to use
OpenWrt's firewall package. I've heard some vague myths about OpenWrt's
firewall not working well with some of the routing protocols used in
libremesh, but all attempts to reproduce that or inquire what the
problem was or is remained without substancial results.
I guess there are some historic reasons for some people to still
hestitate using OpenWrt's firewall (ie. fw3 nowadays), maybe some bug
which has long been resolved or simply not (auto-)adding the rules
needed to also run routing protocols on the WAN interface (which I've
fixed some years ago).
Daniel maybe you are not using lime-proto-wan in your deploys? Juergen
do you have
the lime-proto-wan selected?
Maybe the automatic selection that is donde by
lime-hwd-openwrt-wan is
not working in this device?
Best!
SAn
_______________________________________________
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
9:03 a.m.
Here are some excerpts from syslog which look suspicious to me:
Tue Oct 27 22:03:09 2020 daemon.err babeld[1491]: Warning: keyword "wired"
is deprecated -- please use "type" instead.
Tue Oct 27 22:03:09 2020 daemon.err babeld[1491]: Warning: keyword "wired"
is deprecated -- please use "type" instead.
Tue Oct 27 22:03:09 2020 daemon.err babeld[1491]: Warning: couldn't
determine channel of interface eth0-1_17.
Tue Oct 27 22:03:09 2020 user.notice mac80211: Failed command: iw phy phy1
set antenna 0xffffffff 0xffffffff
Tue Oct 27 22:03:09 2020 daemon.notice netifd: radio1 (1153): command
failed: Not supported (-122)
Tue Oct 27 22:03:10 2020 user.notice mac80211: Failed command: iw phy phy1
set distance 100
Tue Oct 27 22:03:15 2020 user.notice ucitrack: Setting up
/etc/config/firewall reload dependency on /etc/config/miniupnpd
Tue Oct 27 22:03:15 2020 daemon.crit dnsmasq[2005]: directory
/tmp/resolv.conf.d/resolv.conf.auto for resolv-file is missing, cannot poll
Tue Oct 27 22:03:15 2020 daemon.crit dnsmasq[2005]: FAILED to start up
Tue Oct 27 22:03:15 2020 daemon.info procd: Instance dnsmasq::cfg01411c s
in a crash loop 6 crashes, 0 seconds since last crash
Tue Oct 27 22:03:20 2020 daemon.notice procd: /etc/rc.d/S90batmand: uci:
Entry not found
Tue Oct 27 22:03:21 2020 daemon.err hostapd: Using interface wlan0-ap with
hwaddr 7a:a3:51:16:da:89 and ssid "MarinaMalgrats"
Tue Oct 27 22:03:22 2020 kern.warn kernel: [ 45.557225] ieee80211 phy1:
rt2800_config_channel: Warning - Using incomplete support for external PA
Tue Oct 27 22:03:25 2020 daemon.err babeld[1491]: Warning: couldn't
determine channel of interface wlan0-mesh_17.
Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: Warning: couldn't
determine channel of interface wlan1-mesh_17.
Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: send: Address not
available
Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: send: Address not
available
Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: send: Operation not
permitted
Wed Oct 28 08:32:56 2020 daemon.crit dnsmasq[3050]: directory
/tmp/resolv.conf.d/resolv.conf.auto for resolv-file is missing, cannot poll
Wed Oct 28 08:32:56 2020 daemon.crit dnsmasq[3050]: FAILED to start up
Regards
Jürgen
Am Mi., 28. Okt. 2020 um 09:49 Uhr schrieb Juergen Kimmel <
juergenkimmel(a)gmail.com>gt;:
*Juergen do you have the lime-proto-wan selected *
Yes
Am Di., 27. Okt. 2020 um 21:44 Uhr schrieb Daniel Golle <
daniel(a)makrotopia.org>gt;:
On Tue, Oct 27, 2020 at 05:25:32PM -0300, SAn via
lime-users wrote:
that
selects lime-proto-wan.
Hi!
On 10/27/20 5:14 PM, Daniel Golle wrote:
> On Mon, Oct 26, 2020 at 12:07:24PM +0100, Juergen Kimmel wrote:
>> I learned from the config.buildinfo that firewall has not been
selected
>> The settings of the switches are
identical.
>> May disabling the firewall have been the culprit?
>> I flashed the same device again there is no error and client has
internet.
Ah, of course, without any firewall installed there is also no
NAT / masquerading happening, so if you want that, you do need
something to configure that (such as OpenWrt's 'firewall' package').
AFAIK we recommend in the docs to use the package lime-hwd-openwrt-wan This package provides the NATing rules without
the need of the firewall
package.
It never matched my requirements and I never saw a reason not to use
OpenWrt's firewall package. I've heard some vague myths about OpenWrt's
firewall not working well with some of the routing protocols used in
libremesh, but all attempts to reproduce that or inquire what the
problem was or is remained without substancial results.
I guess there are some historic reasons for some people to still
hestitate using OpenWrt's firewall (ie. fw3 nowadays), maybe some bug
which has long been resolved or simply not (auto-)adding the rules
needed to also run routing protocols on the WAN interface (which I've
fixed some years ago).
Daniel maybe you are not using lime-proto-wan in your deploys? Juergen
do you have
the lime-proto-wan selected?
Maybe the automatic selection that is donde by
lime-hwd-openwrt-wan is
not working in this device?
Best!
SAn
_______________________________________________
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
9:08 a.m.
When I'm connected to this device "thisnode.info" doesn't work
Regards
Jürgen
Am Mi., 28. Okt. 2020 um 10:03 Uhr schrieb Juergen Kimmel <
juergenkimmel(a)gmail.com>gt;:
Here are some excerpts from syslog which look
suspicious to me:
Tue Oct 27 22:03:09 2020 daemon.err babeld[1491]: Warning: keyword "wired"
is deprecated -- please use "type" instead.
Tue Oct 27 22:03:09 2020 daemon.err babeld[1491]: Warning: keyword "wired"
is deprecated -- please use "type" instead.
Tue Oct 27 22:03:09 2020 daemon.err babeld[1491]: Warning: couldn't
determine channel of interface eth0-1_17.
Tue Oct 27 22:03:09 2020 user.notice mac80211: Failed command: iw phy phy1
set antenna 0xffffffff 0xffffffff
Tue Oct 27 22:03:09 2020 daemon.notice netifd: radio1 (1153): command
failed: Not supported (-122)
Tue Oct 27 22:03:10 2020 user.notice mac80211: Failed command: iw phy phy1
set distance 100
Tue Oct 27 22:03:15 2020 user.notice ucitrack: Setting up
/etc/config/firewall reload dependency on /etc/config/miniupnpd
Tue Oct 27 22:03:15 2020 daemon.crit dnsmasq[2005]: directory
/tmp/resolv.conf.d/resolv.conf.auto for resolv-file is missing, cannot poll
Tue Oct 27 22:03:15 2020 daemon.crit dnsmasq[2005]: FAILED to start up
Tue Oct 27 22:03:15 2020 daemon.info procd: Instance dnsmasq::cfg01411c s
in a crash loop 6 crashes, 0 seconds since last crash
Tue Oct 27 22:03:20 2020 daemon.notice procd: /etc/rc.d/S90batmand: uci:
Entry not found
Tue Oct 27 22:03:21 2020 daemon.err hostapd: Using interface wlan0-ap with
hwaddr 7a:a3:51:16:da:89 and ssid "MarinaMalgrats"
Tue Oct 27 22:03:22 2020 kern.warn kernel: [ 45.557225] ieee80211 phy1:
rt2800_config_channel: Warning - Using incomplete support for external PA
Tue Oct 27 22:03:25 2020 daemon.err babeld[1491]: Warning: couldn't
determine channel of interface wlan0-mesh_17.
Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: Warning: couldn't
determine channel of interface wlan1-mesh_17.
Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: send: Address not
available
Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: send: Address not
available
Tue Oct 27 22:03:26 2020 daemon.err babeld[1491]: send: Operation not
permitted
Wed Oct 28 08:32:56 2020 daemon.crit dnsmasq[3050]: directory
/tmp/resolv.conf.d/resolv.conf.auto for resolv-file is missing, cannot poll
Wed Oct 28 08:32:56 2020 daemon.crit dnsmasq[3050]: FAILED to start up
Regards
Jürgen
Am Mi., 28. Okt. 2020 um 09:49 Uhr schrieb Juergen Kimmel <
juergenkimmel(a)gmail.com>gt;:
> *Juergen do you have the lime-proto-wan selected *
> Yes
>
> Am Di., 27. Okt. 2020 um 21:44 Uhr schrieb Daniel Golle <
> daniel(a)makrotopia.org>gt;:
>
>> On Tue, Oct 27, 2020 at 05:25:32PM -0300, SAn via lime-users wrote:
>> > Hi!
>> >
>> > On 10/27/20 5:14 PM, Daniel Golle wrote:
>> > > On Mon, Oct 26, 2020 at 12:07:24PM +0100, Juergen Kimmel wrote:
>> > >> I learned from the config.buildinfo that firewall has not been
>> selected
>> > >> The settings of the switches are identical.
>> > >> May disabling the firewall have been the culprit?
>> > >> I flashed the same device again there is no error and client has
>> internet.
>> > >
>> > > Ah, of course, without any firewall installed there is also no
>> > > NAT / masquerading happening, so if you want that, you do need
>> > > something to configure that (such as OpenWrt's
'firewall' package').
>> >
>> > AFAIK we recommend in the docs to use the package lime-hwd-openwrt-wan
>> that selects lime-proto-wan.
>> > This package provides the NATing rules without the need of the
>> firewall package.
>>
>> It never matched my requirements and I never saw a reason not to use
>> OpenWrt's firewall package. I've heard some vague myths about
OpenWrt's
>> firewall not working well with some of the routing protocols used in
>> libremesh, but all attempts to reproduce that or inquire what the
>> problem was or is remained without substancial results.
>> I guess there are some historic reasons for some people to still
>> hestitate using OpenWrt's firewall (ie. fw3 nowadays), maybe some bug
>> which has long been resolved or simply not (auto-)adding the rules
>> needed to also run routing protocols on the WAN interface (which I've
>> fixed some years ago).
>>
>> >
>> > Daniel maybe you are not using lime-proto-wan in your deploys? Juergen
>> do you have the lime-proto-wan selected?
>> > Maybe the automatic selection that is donde by lime-hwd-openwrt-wan is
>> not working in this device?
>> >
>> > Best!
>> > SAn
>> > _______________________________________________
>> > 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
>
>
1269
days inactive
1272
days old
lime-users@lists.libremesh.org
10 comments
4 participants
participants (4)
-
Daniel Golle -
Ilario Gelmetti -
Juergen Kimmel -
SAn