Hi, I just want to ask if anybody has already tested some 802.11n hardware. Does 802.11n provides the full-duplex using several radios? Best, -- -- Benjamin Henrion <bhenrion at ffii.org> FFII Brussels - +32-484-566109 - +32-2-4148403
Hi, To my understanding,in 802.11s,path selection is intended to create a L2 Routing table, data is forwarded according to the L2 routing table and bridge table, but I also notice that OLSR will ultimately update the L3 routing table, by this I mean OLSR does not build a L2 routing table for data forwarding use. Does anyone tell me something about this? Many thanks in advance. ----- Original Message ----- From: "Benjamin Henrion" <bh <at> udev.org> To: "OLSR discussion and development" <olsr-users <at> olsr.org> Sent: Saturday, December 02, 2006 1:18 AM Subject: [OLSR-users] 802.11n and full duplex > Hi, > > I just want to ask if anybody has already tested some 802.11n hardware. > > Does 802.11n provides the full-duplex using several radios? > > Best, > > -- > Benjamin Henrion <bhenrion at ffii.org> > FFII Brussels - +32-484-566109 - +32-2-4148403 > > _______________________________________________(Continue reading)
_______________________________________________ olsr-users mailing list olsr-users <at> olsr.org https://www.olsr.org/mailman/listinfo/olsr-users
Hi, 201 and 202 are the LQ versions of HELLO and TC. You are mixing LQ enabled nodes with reguar OLSR nodes. - Andreas shuprabha shakya wrote: > Hi, > > I think there is some bug in the windows version of unik OLSR. I tried > to capture the packets usin pcap and also verified by using ethereal. > On running the OLSR switch, I can found only Unkown packet or HNA > packet with message type no 201 or 202. But when i run OLSR in cygwin, > I can get HELLO, TC packets and so on. > > I think, there is some mistake in type numbering. In my opinion, the > type of HELLO has been mistaken from 1 to 201 and TC from 2 to 202 or > so on. > > I may not be correct but I think there is some problem on this. I > would be grateful to have any idea about it. > > > shupa > > ------------------------------------------------------------------------ > Need a quick answer? Get one in minutes from people who know. Ask your > question on Yahoo! Answers > <http://answers.yahoo.com/;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx>. > > ------------------------------------------------------------------------ > > _______________________________________________ > olsr-users mailing list > olsr-users <at> olsr.org > https://www.olsr.org/mailman/listinfo/olsr-users >
_______________________________________________ olsr-users mailing list olsr-users <at> olsr.org https://www.olsr.org/mailman/listinfo/olsr-users
_______________________________________________ olsr-users mailing list olsr-users <at> olsr.org https://www.olsr.org/mailman/listinfo/olsr-users
Hello - I think it should be better communicated on the web page that olsrd only works reasonable if ETX/LQ *and* LinkQualityFishEye is used. Without the LinkQualityFishEye-Mechanism and redundant TC-messages (they should be more frequent than Hello messages, I'd say two or three times) olsrd creates nice routing tables as long as there is no payload. As soon as payload is introduced routes flap and routing loops occur. So it is no longer true that LinkQualityFishEye-Mechanism is a experimental feature - it was that important missing improvement that made olsr finally functional for the Freifunk networks. Since LinkQualityFishEye it is no problem anymore to perform a FTP download over a route of 8 hops here in Berlin... I think the configuration-file with ETX/LQ *and* LinkQualityFishEye in /files/ should become the default when performing a make install. LinkQualityFishEye is compatible with olsr-nodes that don't use the algorithm - but I would recommend to update all nodes in your mesh-networks as soon as possible to have the mesh work nicely. See the Readme about FishEye. When I was in Dharamsala/India it became obvious that the AirJaldi mesh suffered Routing Loops because they didn't know how to configure olsrd for stable and reliable routes. They were using it with LQ/ETX and a sliding window size that was too small and didn't know about LinkQualityFishEye. LinkQualityDjikstraLimit is important in large mesh-networks like Berlin on embedded systems - otherwise the CPUs will overheat. But the implementation in 0.4.10 is still buggy, I think. I'd suggest is high time to release a new 'stable' release of olsrd - there are too many important bugs in 0.4.10 which have been fixed in CVS. Last important one was the limitation of 32 hops max. that causes olsrd to crash. I wrote a short text called 'The olsr-story' for www.open-mesh.net - Thomas Lopatic read it and we both think it would be a interesting read for people interested in the background of the development at Freifunk. It will give people a good insight about our experiences and thoughts about olsr. Some people subscribed to the olsr-mailinglists may also be interested in the development of the B.A.T.M.A.N routing-daemon that we started after olsr-0.4.10. B.A.T.M.A.N-III-0.1 binaries and sources will be available from December 13th at www.open-mesh.net. Let's see how it performs in real life :) I'm still using olsrd-0.5 pre every day - but I'm looking forward to the experiences with B.A.T.M.A.N. Gateway switching is a constant annoyance in olsrd when using stateful protocols like IM, VOIP etc. cu elektra
Hi, I have a patch to make the olsr name service plugin work with IPv6 at: http://people.freebsd.org/~jhay/olsrd/patch-lib:nameservice:src:nameservice.c Most of it is pretty straight forward I think. The biggest change is in write_resolv_file() where instead of using olsr_lookup_routing_table() I wrote host_lookup_routing_table() which will look through the "main" routing table and also through the hna table. One feature that I still would love is to have a way to dynamically add entries that the plugin will then propagate into the olsr net and not have to edit olsr.conf and restart olsrd everytime. Maybe instead of just copying the "add-hosts" file over to the "hosts-file", to propagate it into the olsr net as well. My other patches to make olsr work with ipv6 on FreeBSD is also in that directory. John -- -- John Hay -- John.Hay <at> meraka.csir.co.za / jhay <at> FreeBSD.org
Hi John, I've applied your patches. In cvs HEAD it had to be done pretty much manually due to the diff from the latest release. Could you please check out the current version and verify that it works? Thanks. Everybody, Could everyone that has patches they feel should be part of the next release please check out the 0.4 branch(and preferably HEAD as well) and see if the fixes are already applied? If not let us know! - Andreas > Hi, > > I have a patch to make the olsr name service plugin work with IPv6 at: > > http://people.freebsd.org/~jhay/olsrd/patch-lib:nameservice:src:nameservice.c > > Most of it is pretty straight forward I think. The biggest change is in > write_resolv_file() where instead of using olsr_lookup_routing_table() > I wrote host_lookup_routing_table() which will look through the "main" > routing table and also through the hna table. > > One feature that I still would love is to have a way to dynamically > add entries that the plugin will then propagate into the olsr net and > not have to edit olsr.conf and restart olsrd everytime. Maybe instead > of just copying the "add-hosts" file over to the "hosts-file", to > propagate it into the olsr net as well. > > My other patches to make olsr work with ipv6 on FreeBSD is also in > that directory. > > John > -- > John Hay -- John.Hay <at> meraka.csir.co.za / jhay <at> FreeBSD.org > > _______________________________________________ > olsr-users mailing list > olsr-users <at> olsr.org > https://www.olsr.org/mailman/listinfo/olsr-users >
Hi again John, I've also added your FreeBSD IPv6 patches. Could you also verify these? Thanks for the contribution! - Andreas > Hi, > > I have a patch to make the olsr name service plugin work with IPv6 at: > > http://people.freebsd.org/~jhay/olsrd/patch-lib:nameservice:src:nameservice.c > > Most of it is pretty straight forward I think. The biggest change is in > write_resolv_file() where instead of using olsr_lookup_routing_table() > I wrote host_lookup_routing_table() which will look through the "main" > routing table and also through the hna table. > > One feature that I still would love is to have a way to dynamically > add entries that the plugin will then propagate into the olsr net and > not have to edit olsr.conf and restart olsrd everytime. Maybe instead > of just copying the "add-hosts" file over to the "hosts-file", to > propagate it into the olsr net as well. > > My other patches to make olsr work with ipv6 on FreeBSD is also in > that directory. > > John > -- > John Hay -- John.Hay <at> meraka.csir.co.za / jhay <at> FreeBSD.org > > _______________________________________________ > olsr-users mailing list > olsr-users <at> olsr.org > https://www.olsr.org/mailman/listinfo/olsr-users >
RSS Feed42 | |
|---|---|
32 | |
19 | |
52 | |
12 | |
62 | |
37 | |
23 | |
45 | |
31 | |
25 | |
17 | |
17 | |
7 | |
35 | |
67 | |
23 | |
16 | |
56 | |
10 | |
63 | |
9 | |
45 | |
101 | |
75 | |
98 | |
21 | |
93 | |
44 | |
67 | |
61 | |
87 | |
22 | |
49 | |
51 | |
43 | |
17 | |
40 | |
25 | |
107 | |
63 | |
58 | |
39 | |
63 | |
38 | |
18 | |
35 | |
43 | |
86 | |
27 | |
56 | |
141 | |
56 | |
51 | |
57 | |
126 | |
126 | |
53 | |
82 | |
88 | |
7 | |
45 | |
47 | |
24 | |
26 | |
82 | |
27 | |
17 | |
21 | |
23 | |
15 | |
39 | |
47 | |
21 | |
67 | |
65 | |
21 | |
15 | |
23 | |
23 | |
15 | |
62 | |
75 | |
41 | |
57 | |
78 | |
85 | |
28 | |
28 | |
48 | |
28 | |
3 | |
76 | |
80 | |
104 | |
67 | |
188 | |
54 | |
132 | |
93 | |
81 | |
58 | |
72 | |
25 |
