Wait, do not configure anything via LuCI web interface, it could work
but it could as well not work at all!
Additionally, when you configure LibreMesh via lime-app or via SSH, the
changes you did via LuCI could be overwritten.
I suggest to stop using the one PicoStation with SquashFS errors, likely
it is broken.
Regarding the other PicoStation: I would flash it with a clean LibreMesh
(so that you start from a clean configuration) and configure the WAN via
SSH.
Connect to it via SSH and edit the /etc/config/lime-node adding these
lines at its bottom:
config net mywan
option linux_name 'eth0'
list protocols 'wan'
save and run the lime-config command and reboot.
There's no need to understand issue #658 :)
It basically says that if you connect a LibreMesh LAN port to a
non-LibreMesh LAN port weird things can happen.
In general, the valid connections are:
* LibreMesh LAN connected to LibreMesh LAN
* non-LibreMesh LAN connected to LibreMesh WAN
while the connections which should **never** be used (because very weird
things can happen) are:
* non-LibreMesh LAN connected to LibreMesh LAN (and this is #658)
* LibreMesh LAN connected to LibreMesh WAN (NAT could create troubles)
* LibreMesh WAN connected to LibreMesh WAN (no IP will be assigned and
in the future this could be broken due to the usage of OpenWrt's
firewall, see https://github.com/libremesh/lime-packages/issues/280)
Ciao!
Ilario
On 10/15/20 1:12 PM, Juergen Kimmel wrote:
> Ok I added the WAN interface with physical setting ETH0 and I deleted
> ETH0 from LAN interface.
> Then WAN is up and running and Luci >> overview shows connected to
> router and the IP address.
> Network Diagnostic ping to openwrt.org <http://openwrt.org> ok
> But connected to AP no internet
>
> Am Do., 15. Okt. 2020 um 12:37 Uhr schrieb Juergen Kimmel
> <juergenkimmel@gmail.com <mailto:juergenkimmel@gmail.com>>:
>
> I changed the MTU because of this advice:
> [ 34.145677] batman_adv: bat0: Adding interface: eth0_252
> [ 34.151286] batman_adv: bat0: The MTU of interface eth0_252 is
> too small (1496) to handle the transport of batman-adv packets.
> Packets going over this interface will be fragmented on layer2 which
> could impact the performance. Setting the MTU to 1532 would solve
> the problem.
>
> Having internet means I can browse the internet.
>
> There is only one Picostation having the squashfs error but not
> always and even then it is meshing.
>
> I didn't config eth0 as WAN
> Connecting immediately after boot device was unresponsive, Fing
> listed all devices of my network, internet ok, distant node internet
> as well
> Then device rebooted and was responsive via anygw (10.236.0.1) Does
> this mean I should wait a while?
> Should I try to add the WAN interface manually?
>
> I looked at the issue 658 but that is beyond my understanding ;-)
> (80 years+ and never been in this business)
>
>
>
> Am Do., 15. Okt. 2020 um 11:21 Uhr schrieb Ilario Gelmetti
> <iochesonome@gmail.com <mailto:iochesonome@gmail.com>>:
>
> We always had the MTU message from Batman-adv and I think you can
> increase the MTU over 1500 for an ethernet interface only if it
> supports
> jumbo frames (which usually happens for gigabit interfaces).
> Contrarywise, on the wifi interfaces the limit should be higher
> and we
> can use an MTU that suites Batman-adv usage.
> LibreRouter people in the list should know much more than me on
> this topic.
>
> On the squashfs error, I have no idea.
> Looks like one of the two PicoStation's flash or RAM memory is
> damaged.
> Do you see that message in both PicoStations?
>
> Can you specify better what you mean with "both have internet"?
> Can you ping some internet domain from inside SSH on a router?
> If you didn't configure the ethernet interface as WAN, it could
> be that
> the client you're connecting with has internet due to
> https://github.com/libremesh/lime-packages/issues/658
> but this would imply a very erratic behaviour, in which some
> times you
> accept the home router's DHCP offer (and the internet connection
> works
> BUT thisnode.info <http://thisnode.info> do not work and this
> would explain why thisnode.info <http://thisnode.info>
> stops working) and some times you accept the PicoStation's DHCP
> offer
> (and you do not have internet as you did not configure any WAN
> interface).
>
> Ciao!
> Ilario
>
> On 10/15/20 10:18 AM, Juergen Kimmel wrote:
> > New findings:
> > After a while the device gets unresponsive with thisnode.info
> <http://thisnode.info>
> > <http://thisnode.info> but responds at the ip address of
> anygw (10.236.0.1)
> > moreover dmesg:
> > [ 34.041779] batman_adv: bat0: The MTU of interface eth0_252
> is too
> > small (1496) to handle the transport of batman-adv packets.
> Packets
> > going over this interface will be fragmented on layer2 which could
> > impact the performance. Setting the MTU to 1532 would solve
> the problem.
> > [ 34.066138] batman_adv: bat0: Interface activated: eth0_252
> > [ 38.885984] SQUASHFS error: xz decompression failed, data
> probably
> > corrupt
> > [ 38.892962] SQUASHFS error: squashfs_read_data failed to
> read block
> > 0x17c8b2
> >
> > I changed the MTU but I think this has nothing to do with this
> error
> >
> >
> > Am Di., 13. Okt. 2020 um 19:36 Uhr schrieb Juergen Kimmel
> > <juergenkimmel@gmail.com <mailto:juergenkimmel@gmail.com>
> <mailto:juergenkimmel@gmail.com <mailto:juergenkimmel@gmail.com>>>:
> >
> > Situation has changed for whatever reason.
> > Now I have two Picostations meshing, one connected to a router
> > There is no wan interface visible from luci, but both have
> internet
> >
> > Ifconfig
> > eth0 Link encap:Ethernet HWaddr DC:9F:DB:0B:17:CA
> > UP BROADCAST MULTICAST MTU:1500 Metric:1
> > RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> > Interrupt:4
> >
> > So one Picostation acts as gateway but is not configured
> as such
> >
> > network:
> >
> > config interface 'loopback'
> > option ifname 'lo'
> > option proto 'static'
> > option ipaddr '127.0.0.1'
> > option netmask '255.0.0.0'
> >
> > config globals 'globals'
> >
> > config interface 'lan'
> > option type 'bridge'
> > option proto 'static'
> > option ip6assign '60'
> > option netmask '255.255.0.0'
> > option mtu '1500'
> > option ip6addr 'fdec:9fee:f1aa::ca17:b00/64'
> > option ipaddr '10.236.23.202'
> > list ifname 'bat0'
> > list ifname 'eth0'
> >
> > config interface 'bat0'
> > option proto 'batadv'
> > option bridge_loop_avoidance '1'
> > option multicast_mode '0'
> > option distributed_arp_table '0'
> > option gw_mode 'client'
> >
> > config device 'lm_net_br_lan_anygw_dev'
> > option type 'macvlan'
> > option name 'anygw'
> > option ifname 'br-lan'
> > option macaddr 'aa:aa:aa:ec:9f:aa'
> >
> > config interface 'lm_net_br_lan_anygw_if'
> > option ifname 'anygw'
> > option auto '1'
> > option netmask '255.255.0.0'
> > option proto 'static'
> > option ipaddr '10.236.0.1'
> > option ip6addr 'fdec:9fee:f1aa::1/64'
> >
> > config rule6 'lm_net_anygw_rule6'
> > option src 'fdec:9fee:f1aa::1/128'
> > option lookup '170'
> >
> > config route6 'lm_net_anygw_route6'
> > option interface 'lm_net_br_lan_anygw_if'
> > option target 'fdec:9fee:f1aa::/64'
> > option table '170'
> >
> > config rule 'lm_net_anygw_rule4'
> > option src '10.236.0.1/32 <http://10.236.0.1/32>
> <http://10.236.0.1/32>'
> > option lookup '170'
> >
> > config route 'lm_net_anygw_route4'
> > option interface 'lm_net_br_lan_anygw_if'
> > option target '10.236.0.0'
> > option netmask '255.255.0.0'
> > option table '170'
> >
> > config device 'lm_net_eth0_batadv_dev'
> > option type '8021ad'
> > option name 'eth0_252'
> > option ifname 'eth0'
> > option vid '252'
> > option macaddr '02:95:39:0b:17:ca'
> > option mtu '1496'
> >
> > config interface 'lm_net_eth0_batadv_if'
> > option auto '1'
> > option ifname 'eth0_252'
> > option proto 'batadv_hardif'
> > option master 'bat0'
> >
> > config device 'lm_net_eth0_babeld_dev'
> > option type '8021ad'
> > option name 'eth0_17'
> > option ifname 'eth0'
> > option vid '17'
> > option mtu '1496'
> >
> > config interface 'lm_net_eth0_babeld_if'
> > option auto '1'
> > option ifname 'eth0_17'
> > option proto 'static'
> > option ipaddr '10.236.23.202'
> > option netmask '255.255.255.255'
> >
> > config interface 'lm_net_wlan0_mesh'
> > option proto 'none'
> > option mtu '1536'
> > option auto '1'
> >
> > config device 'lm_net_wlan0_mesh_batadv_dev'
> > option type '8021ad'
> > option name 'wlan0-mesh_252'
> > option ifname '@lm_net_wlan0_mesh'
> > option vid '252'
> > option mtu '1532'
> >
> > config interface 'lm_net_wlan0_mesh_batadv_if'
> > option auto '1'
> > option ifname 'wlan0-mesh_252'
> > option proto 'batadv_hardif'
> > option master 'bat0'
> >
> > config device 'lm_net_wlan0_mesh_babeld_dev'
> > option type '8021ad'
> > option name 'wlan0-mesh_17'
> > option ifname '@lm_net_wlan0_mesh'
> > option vid '17'
> >
> > config interface 'lm_net_wlan0_mesh_babeld_if'
> > option auto '1'
> > option ifname 'wlan0-mesh_17'
> > option proto 'static'
> > option ipaddr '10.236.23.202'
> > option netmask '255.255.255.255'
> >
> > Am Mo., 12. Okt. 2020 um 16:57 Uhr schrieb Ilario Gelmetti
> > <iochesonome@gmail.com <mailto:iochesonome@gmail.com>
> <mailto:iochesonome@gmail.com <mailto:iochesonome@gmail.com>>>:
> >
> > Hi!
> > Some comments in line:
> >
> > On 10/11/20 2:38 PM, Juergen Kimmel wrote:
> > > Powered by LuCI openwrt-19.07 branch
> (git-20.247.75781-0d0ab01)
> > > <https://github.com/openwrt/luci> / LiMe master
> development
> > (master rev.
> > > 7181c3b 20200927_1250)
> > >
> > > Picostation connected to the router is no longer
> accessible
> > via wifi.
> >
> > This is weird.
> > The Picostation M2 is not emitting any accessible
> network via wifi?
> >
> > It could be a RAM problem: Ubiquiti Picostation *2
> have just 32
> > MB of
> > RAM memory.
> > Connect via ethernet cable and check the dmesg command
> output,
> > looking
> > for any "out of memory OOM kill" message.
> > In order to have less memory usage you can disable the
> web interface
> > (LuCI or lime-app) with:
> > /etc/init.d/uhttpd disable
> > and reboot.
> >
> > In case the problem was not a RAM limitation, please
> upload
> > somewhere
> > the output of the lime-report command or, if you don't
> have the
> > lime-report command, the content of:
> >
> > /etc/config/wireless
> > /etc/config/network
> >
> > and the output of the commands:
> >
> > wifi status
> > iwinfo
> >
> > > Obviously the internet access is not detected and no wan
> > interface is
> > > configured.
> > > lime-hwd-openwrt-wan and check-internet are installed I
> > thought they
> > > would do some kind of magic here.
> >
> > This is normal instead: both vendor and OpenWrt
> recognize the only
> > ethernet port of Ubiquiti Picostation as LAN (not as WAN).
> > What the lime-hwd-openwrt-wan package is designed to
> do is: check if
> > OpenWrt would use an ethernet port as WAN, if positive,
> > configure that
> > port as WAN.
> > In this case, OpenWrt use the port as LAN and thus
> > lime-hwd-openwrt-wan
> > does not do anything.
> > In these cases what you have to write is an
> interface-specific
> > configuration in /etc/config/lime-node as documented here:
> >
> https://github.com/libremesh/lime-packages/blob/e572b4531b2fdcc89965974e0b2268cf4f269b32/packages/lime-docs/files/lime-example#L197-L205
> >
> > Something like this should be enough:
> >
> > config net mywan
> > option linux_name 'eth0'
> > list protocols 'wan'
> >
> > > Regards
> > > Jürgen
> >
> > Let us know how it goes!
> > Ciao,
> > Ilario
--
Ilario
iochesonome@gmail.com
ilario@sindominio.net
_______________________________________________
lime-users mailing list
lime-users@lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users