lime-dev December 2015

lime-dev@lists.libremesh.org

3 participants
5 discussions

by Ilario Gelmetti

From AirOS 5.5.X to 5.6.X the size of memories on the flash changes so that flashing OpenWRT (or other non AirOS firmwares) bricks the device. From https://wiki.openwrt.org/toh/ubiquiti/airmaxm "Special Firmware Note: AirOS XM.v5.5.X images used U-Boot 1.1.4.2-s594 (Dec 5 2012 - 15:23:07). The OpenWRT image can be successfully flashed onto these versions of firmware. However, in July 2015 Ubiquiti released a new version of firmware XM.v5.6.X. With this firmware a new U-Boot version was released, U-Boot 1.1.4.2-s956 (Jun 10 2015 - 10:54:50). The newer U-Boot version changes the memory size and starting address for rootfs, cfg, and EEPROM. LOADING AN OPENWRT IMAGE ON A U-Boot 1.1.4.2-s956 WILL CAUSE THE DEVICE TO BE BRICKED!!! If the device has XM.v5.6.X, an older version of XM firmware can be loaded from the AirOS webgui (for example XM.v5.5.10) and U-Boot will be overwritten with the older version. OpenWRT can then be loaded onto the device successfully." Anyway if you have a way for un-bricking such devices let me know, as I have 4 devices bricked this way. There's also a bug report on this problem https://dev.openwrt.org/ticket/20982 Bye, Ilario PS sorry for cross-posting -- Ilario Gelmetti iochesonome(a)gmail.com igelmetti(a)iciq.es ilario.gelmetti(a)estudiants.urv.cat

8 years, 3 months

Ground routing on TP-Link WR1043ND-v1

by Ilario Gelmetti

Hi all! I was trying to set up two nodes with the ground routing approach [1] using lime-hwd-ground-routing module. For the first node the ground router was a TP-Link WDR3600 and everything worked like a charm, amazing. The problems come with the second node where the ground router was a TP-Link WR1043ND-v1. I configured the ground routing copying the example in lime.example file [2] and changing just "option vlan" to "7", "option switch_cpu_port" to "5" (from OpenWRT wiki [3]) and "list switch_ports" to "2". Then lime-config, uci commit and reboot, as usual. The autogenerated /etc/config/network did look ok. The problem was that no vlan Q with id 7 tagged packets were coming out from port 2. I didn't have time to save logs, files or to do much debugging, I just throw the ground routing approach and installed Libre-Mesh on every device. Does anyone have this router (TP-Link WR1043ND-v1) for reproducing the problems or any ideas of why this was happening? Thanks, Ilario [1] http://libre-mesh.org/projects/libre-mesh/wiki/Ground_routing [2] https://github.com/libre-mesh/lime-packages/blob/develop/packages/lime-syst… [3] https://wiki.openwrt.org/toh/tp-link/tl-wr1043nd#switch_ports_for_vlans -- Ilario Gelmetti iochesonome(a)gmail.com igelmetti(a)iciq.es ilario.gelmetti(a)estudiants.urv.cat

8 years, 3 months

lime-full: why not also batman-adv-auto-gw-mode and lime-hwd-usbradio

by Ilario Gelmetti

Hi all! Why the module batman-adv-auto-gw-mode is not included in lime-full? Does it have a negative impact when all the remaining lime-full modules are active? I would like to understand this because I'm going to use a set-up with lime-full + lime-hwd-ground-routing + batman-adv-auto-gw-mode. And lime-hwd-usbradio? Isn't safe to include it in standard Libre-Mesh? Thanks, Ilario -- Ilario Gelmetti iochesonome(a)gmail.com igelmetti(a)iciq.es ilario.gelmetti(a)estudiants.urv.cat

8 years, 3 months

Notifications about GitHub Issues on ML?

by Ilario Gelmetti

Hi! Do you all get notified when a new issue is files on our GitHub repositories? For example I just filed a feature request and an issue and there are 8 more on lime-packages [1]. If not, is there a way for having the notifications sent on this mailing list? Byye, Ilario [1] https://github.com/libre-mesh/lime-packages/issues -- Ilario Gelmetti iochesonome(a)gmail.com igelmetti(a)iciq.es ilario.gelmetti(a)estudiants.urv.cat

8 years, 3 months

Re: [lime-dev] Info linux bridging

by Gio

On Thursday, December 17, 2015 06:37:02 PM vittgam(a)mietitrebbia.rocks wrote: > On 17/12/2015 12:14:53 CET, Gio wrote: > > On Wednesday, December 16, 2015 06:17:30 PM vittgam(a)mietitrebbia.rocks wrote: > >> La soluzione dovrebbe essere quella di cambiare il MAC di eth0 o eth0.10. > >> Proverò su eigenNet e ti farò sapere (mi è venuta in mente ora tutta > >> sta cosa :D) > > > > Questo l'ho già provato io pero cosi' si rompe lo stack di networking di > > linux in realtà anche se eth0.X si espone come un'interfaccia ethernet > > all'utente non lo e' dentro, quello che succede a me e' che se i > > macaddress > > di eth0 ed eth0.X non sono gli stessi non ti arrivano piu' i pacchetti > > sull'interfaccia taggata, in tutto questo si potrebbero fare prove per > > esempio l'interfaccia eth0 in modo promisc ( non sembra una cosa pulita e > > non ho pensate alle implicazioni che possa avere ) e vedere che succede > > oppure l'altra strada che ho provato e' fare altri tentativi con macvlan > > + vlan che pero non hanno funzionato visto che quando metti > > un'interfaccia dentro a un bridge non sei piu' cosi' libero... > > Io credo che la modalità promisc sia impostata internamente da linux... > In ogni caso se eth0 fa parte del bridge allora è già promisc di per sé, > anche se ifconfig non lo dice (se ad esempio fai tcpdump -ni eth0 vedi > che il kernel non dice più che l'interfaccia è entrata e poi uscita > dal promiscuous mode; poi invece se non sbaglio lo dice appena la si > mette nel bridge). Yep, Other tests i have done are: - While eth0 is bridged to create a macvlan on top of eth0 the kernel refuses to create the macvlan saying that the device is busy - Create a macvlan on top of eth0 and put the macvlan in the bridge, the kernel accept to do it but seems a macvlan port is not capable of learning and stuff like that, probably is that the kernel is not propagating the promisc flag to eth0 meybe setting manually eth0 promisc mode may be helpful but i didn't try it yet - Don't use macvlan but change the mac address of br-lan the mac address is changed but "br-lan: received packet with same mac" keep being printed on dmesg > > Per far funzionare la macvlan con il bridge l'ho dovuta mettere in modo > > passthru tuttavia questa modalità forza che il macaddress sia lo stesso > > sull'interfaccia base e su quella macvlan tornando quindi alla situazione > > iniziale... > > > > https://github.com/libre-mesh/lime-packages/commit/c0e945c6b25dd1d802b188d > > dcbc88047e614db7d > > > > Ho fatto prove con altre modalita di macvlan ma non sembrano funzionare in > > presenza di bridge > > Mi sembra strano, le macvlan mi funzionavano su kernel più vecchi (3.2) in > passthru e con mac addresses diversi (cioè è questo il punto delle macvlan), > però su x86 e schede di rete Intel... Devo provare con OpenWrt su ar71xx. Are you sure the macvlan was in passthru mode ? I noticed it have different behaviour on different devices when you change the macaddress of a passthru on a tl-wdr4300 it changes the macaddress of eth0 too while doing the same on a mynet-n600 have no effect in the sense that no error message is printed as the mac address was changed but doing ip link show the old mac address both for eth0 and passthru, > > Ti succede anche con batman recenti e/o con devices non ubiquity (ubnt > > hanno bachi hardware/driver nelle schede ethernet -_- ) ? > > Batman 2013.4.0 e Ubiquiti PicoStation M2 su OpenWrt CC r46767, appunto. > > I bug delle ubiquiti sono assurdi, sembra che ce li hanno tutti loro... > Anche alle nostre unifi gli si resetta l'ethernet a caso per colpa di > un bug dell'ar7240... On some nanostation M2 I do have in Sicilia disabling the ethernet rate autonegotiation and fixing it to 100mbps full duplex with ethtool have reduced the number of failures now the device is usable but i am not sure it solve all problems > > Mentre invece purtroppo sembra che non sia lo stesso per macvlan :( > > Farò delle prove.. forse non è implementato ancora, perché la situazione > era così per le VLAN ma ora hanno risolto da un pezzo... > > > Non ho capito bene come finiscono i pacchetti batman sugli AP > > Se allo stesso switch sono collegate due antenne (che parlano batman tra > loro con una VLAN e allo stesso tempo bridgeano eth0 con bat0) e client > ethernet e anche gli AP (gli AP non parlano batman), allora il traffico > della VLAN di batman entrerebbe nel bridge degli AP e uscirebbe da wlan0. > > > pero sembra sia > > un fattore fondamentale quello di usare firmware deversi nello stesso > > spazio/tempo vero ? > > Per ora stiamo usando questo su CC r46767: > > https://gitlab.com/VittGam/eigenfw/tree/feed > > Prima usavamo un miscuglio di vecchi AA e BB con versioni di batman diverse > (il firmware "eigennet" insomma). > La rete ora è uniforme e funziona, e appena è stabile potremo cominciare ad > aggiornare tutto a Libre-Mesh. > > Una cosa carina di questo firmware è che crea un'immagine unica > autoconfigurante che decide configurazione (anche hostname e ipv4) in base > al mac address dell'antenna su cui è flashato, non so se lime lo prevede, > nel caso si potrebbe aggiungere ;) LibreMesh has the same behavior by default ;) > (Comunque l'approccio dell'eth0 con mac diverso da eth0.10 sta fungendo qui. > eth0 fa sempre parte di br-lan qui comunque...) Yeah i remember we used that approach in Pisa but it was with an old kernel, with newer kernels on tl-wdrXXXX i don't get the packets on the vlan if the mac address get changed > > Che te ne pare se continuiamo la discussione su dev(a)lists.libre-mesh.org ? > > Perché no? Mi sono appena iscritto, credo che un admin debba autorizzare > però. Please add Vittorio in our list soon ;) Cheers!

8 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

lime-dev December 2015