Hi Marco, Yeah, it's a well known problem:
Please comment the 2 lines inside your compat driver files: > clk_disable > clk_enable because clk_disable & clk_enable are already present in Linux kernel 3.4.which you have build for Nexus4. But, you have (clk_disable & clk_enable) inside wcn36xx device driver files so by commenting the same in the device driver files will solve the problem. > You don't have to make any other changes except iw tool > iw tool needs to be build along with Linux kernel 3.4 not w.r.t Android. Hopefully this one helps you to take your projects further. Best regards, Devaraj J -------------------------------------------------------------------------- > Hi Devaraj, > > again thanks for your quick answers. Without your help I would be lost! > > I booted my Nexus 4 with compiled zImage / boot.img. I've checked the phone info: > > Kernel version: > 3.4.0-perf > root@insc00471 #1 > Fri Oct 10 (The date I built the kernel) > > This looks ok or? > > Then I tried to load the modules using insmod: > root@mako:/sdcard/mesh_driver # insmod compat.ko > insmod: init_module 'compat.ko' failed (Exec format error) > root@mako:/sdcard/mesh_driver # dmesg > <3>[ 247.556966] compat: exports duplicate symbol clk_disable (owned by kernel) > > (The same problem when I insmod the wcn36xx_msm.ko before...) do you have > any ideas? > > > You also mentioned the iw tool. I will have to download and build it for Android. (I don't think it is installed by default.) > > Thanks a lot for your help and time!!! It would be great if you have any idea what would be wrong here... > > Kind regards, > Marco > > > > > >>-----Ursprüngliche Nachricht----- >>Von: [email protected] [mailto:[email protected]] Gesendet: Montag, 13. Oktober 2014 12:14 >>An: Steger, Marco >>Cc: [email protected] >>Betreff: Re: AW: AW: 802.11s as link layer in libre-mesh >>Hi Marco, >>You are suppose to execute combat.ko before wcn36xx_msm.ko, >>MESH support needs to be tested from executing "#iw list" command which >> lists >>"Supported interface modes: *mesh point" along with other modes. Create a MESH POINT :- >>Create at-least two mesh points to establish communication. >>General steps for creating MESH NODES to establish "Peer to Peer" Communication between two wireless entities :- >>1. On any Linux machine please, enter in Super User (#SU) mode. 2. #killall wpa_supplicant >>3. #iw dev <wlanX> set type mp >>4. #iw dev <wlanX> set meshid <XXXXXX> >>5. #iw dev <wlanX> set channel <Number> >>6. #ifconfig <wlanX> xx.xx.xx.xx up >>Once after executing the above steps, 2 entities must communicate with >> each >>other & the same can be verified by executing >># ping xx.xx.xx.xx [from both the entities] >>Best regards, >>Devaraj J >>> Hi Devaraj! >>> I had some trouble getting my 64bit Linux machine running. >>> Thatââ¬â¢s >>> why it takes some time to start with your guide to get Mesh working on my Nexus4. >>> First of all thanks for that great guide. Everything worked fine and now I have the 5 .ko files on my Nexus and I was also able to run the new kernel on my device. >>> Then I tried to load the files using insmod. "insmod wcn36xx_msm.ko" seems to work fine but for the other files I got " insmod: init_module 'wcn36xx.ko' failed (No such file or directory)" or " insmod: can't open 'combat.co' " errors. Do you have an idea what could wrong here? Can you also give me a hint what to do next when the insmod finally works? >>> How to connect to the mesh network? >>> I hope you can help me once again!!! >>> Thanks in advance and kind regards, >>> Marco >>>>-----Ursprüngliche Nachricht----- >>>>Von: Devaraj J [mailto:[email protected]] >>>>Gesendet: Mittwoch, 01. Oktober 2014 14:16 >>>>An: Steger, Marco; [email protected] >>>>Betreff: Re: AW: 802.11s as link layer in libre-mesh >>>>Hi All, >>>>I was able to successfully get the MESH up & running on Nexus 4. In Our project we used Linux kernel 3.4.0 But, MESH comes in wcn36xx driver (Linux kernel : 3.16) So we need to back port from 3.16 to 3.4.0 Linux Kernel. >>>>Below are the steps followed to get MESH up on Nexus4. >>>>Download the backport WCN36XX Wireless device driver from URL:- http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/ select: backports-3.16-1 >>>># mv /home/<user>Download/backport-3.16-1.tar.xz ./ # tar -xf >>>> ./backport- >>>>3.16-1.tar.xz # cd backport-3.16-1 # make defconfig-wcn36xx # make menuconfig >>>> [*] Enable mac80211 mesh networking (pre-802.11s) support. >>>> save & exit >>>># make KLIB=<kenrel directory path where zImage compiled> >>>>KLIB_BUILD=<kerenl directory path where zImage compiled> This will create compat.ko , cfg80211.ko , mac80211.ko and wcn36xx.ko. >>>># cd .. >>>>Download the wcn36xx_msm driver source code from URL: >>>>https://github.com/KrasnikovEugene/wcn36xx >>>>click on Download ZIP (right side corner). >>>># mv wcn36xx-master.zip ./ >>>># unzip wcn36xx-master.zip >>>># cd wcn36xx-master/wcn36xx_msm >>>># make KLIB=<kernel directory path where zImage compiled > >>>>KLIB_BUILD=<kernel--directory path where zImage compiled > This will create wcn36xx_msm.ko in current directory. >>>>#cd .. >>>>Hope this works for you. >>>>Br, >>>>Devaraj J >>>>On Wednesday 01 October 2014 11:19 AM, Steger, Marco via Devel wrote: >>>> Dear all, >>>> first of all thank you for your input. >>>> Tomorrow I'm back in my office and I will start to set up the 802.11s >>>>stuff for my nexus 4 according to the steps stated by Bob and the information about wcn36xx (thanks to Yeoh Chun-Yeow) >>>> I will (try to) document all necessary steps to enable mesh on my >>>>Android Smartphone. I will post the documentation here when I'm finished with it and than we can discuss, if there is a good place to put it to help others with the same issue. >>>> Thanks again for your help and I hope that I can count on you if >>>>there are further questions, >>>> Marco >>>> -----Ursprüngliche Nachricht----- >>>> Von: Devel [mailto:[email protected]] Im >>Auftrag >>>>von Ross >>>> Wakelin via Devel >>>> Gesendet: Mittwoch, 01. Oktober 2014 00:47 >>>> An: Javier Cardona >>>> Cc: [email protected] >>>> Betreff: Re: 802.11s as link layer in libre-mesh >>>> Hi Javier >>>> I can't comment for what is in or out of the standards. >>>> Our biggest deployed mesh had 10 nodes, of which 4 were >>repeater >>>>only nodes. >>>> Our kit consists of repeaters and endpoint nodes. Endpoint nodes >>>>have the >>>> openwrt device connected to either a network video recorder >>and 4 >>>>cameras, or >>>> a digital signage device, or a voip node with two sip extension >>>>phones. All the >>>> nodes, including the repeater nodes, publish an SSID for staff >>>>access to all the >>>> other devices, and internet access through a gateway node. >>>> The way we have it, the nodes all have two IP addresses, one for >>the >>>>"internal" >>>> mesh network so the devices can find and talk to each other and >>>>exchange >>>> routing information, and a "behind" >>>> network that contains all the supported devices. We use OLSR to >>>>publish and >>>> share the behind networks over the mesh. The mesh runs on >>5Ghz, and >>>>the >>>> access network is 2.4Ghz. >>>> All our devices are portable, and we can have the mesh up and >>>>running in less >>>> than 10 minutes. >>>> The biggest challenge is finding the best locations for the >>repeater >>>>nodes, and we >>>> have a process that runs on the openwrt device that checks the >>OLSR >>>>"goodness" >>>> for each link, and then shows that as a colour/brightness/blink >>rate >>>>report on an >>>> RGB LED, so we can walk around with the repeater node turned >>on, >>>>looking for >>>> the location that gives the best coverage AND connection back >>to the >>>>mesh. >>>> Our repeaters have 20dBm omni aerials connected (three per >>node for >>>>N) and we >>>> can normally get about 70-150Mbs link rate. >>>> Hope this helps. >>>> Ross >>>> On 1 October 2014 11:24, Javier Cardona <[email protected]> >>>><mailto:[email protected]> wrote: >>>> Hi Ross, >>>> Thanks for the info. May I ask how big a network can >>you support >>>>with >>>> OLSR over 11s? >>>> Early drafts of the 11s amendment supported OLSR in >>addition to >>>>HWMP. >>>> But support for OLSR was dropped because "there are no >>additional >>>>deployment >>>> scenarios or usage models that RA-OLSR enables beyond those >>that are >>>>enabled >>>> by HWMP" [Source: https://mentor.ieee.org/802.11/dcn/07/11- >>>>07-2547-02- >>>> 000s-reconsidering-ra-olsr.ppt ] >>>> I'm curious if that was an accurate statement or the >>proponents of >>>>that >>>> motion were just in a hurry to get the standard ratified... :) >>>> Cheers, >>>> Javier >>>> On Tue, Sep 30, 2014 at 1:13 PM, Ross Wakelin >>>> <[email protected]> <mailto:[email protected]> >>>>wrote: >>>> Hiya >>>> In our mesh platform that is used to support >>emergency >>>> responders, we use an underlying >>>> 11s layer, leveraging the >>>>authentication/encryption capabilities, >>>> and then use OLSR on top >>>> to provide the routing and reporting/managing >>we need. >>>> Sitting on top of 11n and Openwrt, it just >>>> works, >>and its stable. >>>> We use it to carry voice, video >>>> and data across sites. >>>> On 1 October 2014 05:42, Pau via Devel >>>> <[email protected]> >>>><mailto:[email protected]> wrote: >>>> Find my comments in line. >>>> On 30/09/14 17:56, Javier Cardona >>>>wrote: >>>> > Hi Pau, >>>> > >>>> > I agree with your assessment: 11s >>brings a number of >>>> benefits over ad-hoc. >>>> > In addition to the ones you >>>> listed, I >>>>would add: >>>> > >>>> > 6. symmetric security (SAE) >>>> In AdHoc it is possible to use WPA2 PSK, >>however the >>>> implementation of >>>> SAE in 11s is probably better because of >>a cleaner >>>> integration. >>>> > 7. customizable path selection >>>>mechanism (which you >>>> could use with your >>>> > custom routing) >>>> I suppose you mean the possibility of >>using a different >>>> routing protocol >>>> instead of HWMP such as OLSR (I've seen >>there is already >>>> some >>>> implementation on this). However in our >>case we are not >>>> trying to >>>> integrate 11s with bat-adv/bmx6 but just >>use 11s as layer >>>> 1-2 and >>>> bat-adv/bmx6 as layer 2.5/3. >>>> > 8. power save >>>> Yes, that is great, I've seen another >>>> post >>talking about >>>> 802.11s in >>>> Android, that could bring us many >>possibilities too :) >>>> > 9. interoperability: there are some >>incompatible ad- >>>> hoc implementations >>>> > out there as WFA did not test above 11 >>Mbps. >>>> open80211s made vendor >>>> > neutrality and interoperability a >>>> priority >>since day one. >>>> Right, we've experienced such >>>>incompatibilities and this >>>> is actually one >>>> of the points we are sick of Ad-Hoc. >>>> > The only point that is debatable is 2: >>>>there aren't that >>>> many cards/drivers >>>> > that support it. >>>> We try to stick at Atheros drivers so >>>> here >>11s seems to >>>> have even better >>>> support than Ad-Hoc. >>>> > Best of luck, >>>> > >>>> Thank you for your comments Javier. >>>> > Javier >>>> > >>>> > On Tue, Sep 30, 2014 at 6:31 AM, Pau >>via Devel >>>> <[email protected]> >>>><mailto:[email protected]> >>>> > wrote: >>>> > >>>> >> Hello. >>>> >> I'm one of the developers of the >>>> libre- >>mesh project >>>> [1]. Our aim is to >>>> >> develop an OpenWRT based solution >>for quick and >>>> easy building free/libre >>>> >> mesh networks. >>>> >> >>>> >> Our network architecture is quite >>different from the >>>> common ones, we are >>>> >> mixing two routing protocols in >>>> layer2 >>and layer3 >>>> (batman-adv and bmx6). >>>> >> You can find more information about >>it here [2]. >>>> >> >>>> >> Until now we were using Ad-Hoc as >>link layer, >>>> however recently we have >>>> >> started to consider the idea of using >>11s instead. We >>>> are not interested >>>> >> in the routing layer (HWMP) because >>we need some >>>> features provided by >>>> >> batman-adv, so we disable it by >>setting the option >>>> mesh_forwarding to >>>> >> false. >>>> >> >>>> >> I've already performed some tests >>and the results look >>>> quite good. Using >>>> >> 11s instead of ad-hoc bring us some >>advantages which >>>> are: >>>> >> >>>> >> 1. Better support for 11n >>>> >> 2. Better compatibility with drivers >>>> >> 3. You can bridge an 11s interface to >>another >>>> interface if necessary >>>> >> 4. It does NOT try to synchronize the >>TSF counter of >>>> your wifi card >>>> >> 5. You can create up to 8 11s VAP >>mixed with adhoc, >>>> AP, client, etc... >>>> >> 5. Get benefit of a newer protocol >>design >>>> >> >>>> >> I would like to know your opinion on >>this topic. None >>>> of us now deeply >>>> >> how 11s works, so we don't really >>know if what we >>>> are trying to do is a >>>> >> madness or a good idea. It would be >>also very >>>> interesting for us to know >>>> >> which options can we tun for getting >>better profit of >>>> using 11s as link >>>> >> layer. >>>> >> >>>> >> Thank you for your efforts on >>>>developing 11s. >>>> >> >>>> >> Cheers. >>>> >> >>>> >> [1] https://dev.libre- >>>>mesh.org/projects/libre-mesh >>>> >> [2] >>>> >> https://dev.libre- >>>>mesh.org/projects/libre- >>>> mesh/wiki/NetworkArchitecture >>>> >> -- >>>> >> ./p4u >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >>>> >> Devel mailing list >>>> >> [email protected] >>>> >> http://lists.open80211s.org/cgi- >>>> bin/mailman/listinfo/devel >>>> > >>>> -- >>>> ./p4u >>>> _______________________________________________ >>>> Devel mailing list >>>> [email protected] >>>> http://lists.open80211s.org/cgi- >>>> bin/mailman/listinfo/devel >>>> _______________________________________________ >>>> Devel mailing list >>>> [email protected] >>>> http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel > > _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
