Bridging mesh with wired not working?
Monthadar Al Jaberi
monthadar at gmail.com
Wed Dec 1 09:03:01 UTC 2010
On Wed, Dec 1, 2010 at 9:22 AM, Adrian Chadd <adrian at freebsd.org> wrote:
> The mesh code is really a proof of concept. It definitely needs
> someone to actually sit down and use it, then document all of the
> things that aren't working.
>
> I tried it for about 5 minutes and discovered that although it seems
> to basically work, MAC addresses migrating from wired<->wireless
> didn't migrate destinations in the mesh table, so the mesh network
> would treat it incorrectly. I ran out of time (my spare time is
how was your setup? Was it like mine? did you ping? I can ping the
MESH PORTAL itself but not the MESH POINT behind it.
> focused on understanding and implementing Atheros 11n at the moment)
> so I had to stop.
Thank you for your time :)
>
> If you'd like to be the person who sits down and tries to use the
> meshing stuff then please, by all means. :-)
I have been trying to understand the code for some time now, its hard
especially that the standard changed a lot?
I found that if you set it up like I did, it wont ping at all, cause
it would stop at the place I noted.
I tried to make it run the rest of the code instead of going out when
it is a proxy dest, and it did ping!!!
but! if I change anything in how the mesh is set up it wont invalidate
old values and thus stop working for proxy addresses :(
>
>
>
> Adrian
br,
>
> On 1 December 2010 15:48, Monthadar Al Jaberi <monthadar at gmail.com> wrote:
>> On Wed, Dec 1, 2010 at 5:02 AM, Adrian Chadd <adrian at freebsd.org> wrote:
>>> I believe that's supposed to work. :-)
>>
>> Did you try it? on current? I am running 201010 Current. From the code
>> I see some comments like "/* XXX add support for proxied addresses
>> */". For me it looks like the code for proxy is half done, if I may
>> say so myself :P
>>
>> see this method in net80211/ieee80211_mesh.c
>> /*
>> * Iterate the routing table and locate the next hop.
>> */
>> static struct ieee80211_node *
>> mesh_find_txnode(struct ieee80211vap *vap,
>> const uint8_t dest[IEEE80211_ADDR_LEN])
>> {
>> ...
>> if ((rt->rt_flags & IEEE80211_MESHRT_FLAGS_VALID) == 0 ||
>> (rt->rt_flags & IEEE80211_MESHRT_FLAGS_PROXY)) {
>> IEEE80211_NOTE_MAC(vap, IEEE80211_MSG_MESH, dest,
>> "%s: !valid or proxy, flags 0x%x", __func__, rt->rt_flags);
>> /* XXX stat */
>> return NULL;
>> }
>> ...
>> }
>>
>> it stops if the dest node is a proxy. Then after failing in forwarding
>> it goes out (== discard frame?), I put a print message there to verify
>> that it goes out:
>> static int
>> mesh_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf)
>> {
>> ...
>> /*
>> * Potentially forward packet. See table s36 (p140)
>> * for the rules. XXX tap fwd'd packets not for us?
>> */
>> if (dir == IEEE80211_FC1_DIR_FROMDS ||
>> !mesh_isucastforme(vap, wh, mc)) {
>> mesh_forward(vap, m, mc);
>> if (dir == IEEE80211_FC1_DIR_DSTODS)
>> goto out;
>> /* NB: fall thru to deliver mcast frames locally */
>> }
>> ...
>> }
>>
>> I am puzzeled... everyone says it works, did I miss something?! :P
>>
>>
>> br,
>>
>>>
>>>
>>> adrian
>>>
>>> On 30 November 2010 15:38, Monthadar Al Jaberi <monthadar at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Can anyone confirm that bridging a mesh with a wired interface is not
>>>> working? I want to make sure that it is not a problem from my side.
>>>>
>>>> When I ping from outside the mesh I get: "!valid or proxy" and "frame
>>>> not fwd'd, no path" from the debug information.
>>>>
>>>> My setup is simple
>>>>
>>>> STA --- MPP )) -- (( MP
>>>>
>>>> STA: Ubuntu PC
>>>> MPP: RSPRO mesh portal bridging wired and mesh
>>>> MP: RSPRO mesh point
>>>>
>>>> ifconfig for MPP:
>>>> arge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>>>> metric 0 mtu 1500
>>>> options=80000<LINKSTATE>
>>>> ether XX:XX:XX:XX:XX:XX
>>>> media: Ethernet autoselect (100baseTX <full-duplex>)
>>>> status: active
>>>> wlan0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>>>> metric 0 mtu 1500
>>>> ether YY:YY:YY:YY:YY:YY
>>>> inet 192.168.1.91 netmask 0xffffff00 broadcast 192.168.1.255
>>>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <mesh>
>>>> status: running
>>>> meshid monty channel 1 (2412 MHz 11g) bssid 00:15:6d:67:21:8d
>>>> country US ecm authmode OPEN privacy OFF txpower 20 scanvalid 60
>>>> protmode CTS wme burst meshttl 31 meshpeering meshforward
>>>> meshmetric AIRTIME meshpath HWMP hwmprootmode DISABLED hwmpmaxhops 31
>>>> bridge0: flags=28943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC>
>>>> metric 0 mtu 1500
>>>> ether ZZ:ZZ:ZZ:ZZ:ZZ:ZZ
>>>> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>>>> maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
>>>> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>>>> member: arge0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>> ifmaxaddr 0 port 4 priority 128 path cost 200000
>>>> member: wlan0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>>> ifmaxaddr 0 port 7 priority 128 path cost 370370
>>>>
>>>> br,
>>>> --
>>>> //Monthadar Al Jaberi
>>>> _______________________________________________
>>>> freebsd-net at freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>>>
>>>
>>
>>
>>
>> --
>> //Monthadar Al Jaberi
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>
>
--
//Monthadar Al Jaberi
More information about the freebsd-net
mailing list