Bridging mesh with wired not working?
Adrian Chadd
adrian at freebsd.org
Wed Dec 1 14:39:24 UTC 2010
I don't recall the exact particulars of the setup, I'm sorry.
Adrian
On 1 December 2010 17:03, Monthadar Al Jaberi <monthadar at gmail.com> wrote:
> 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