Date: Wed, 1 Dec 2010 22:39:20 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Monthadar Al Jaberi <monthadar@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Bridging mesh with wired not working? Message-ID: <AANLkTinJzzdhi65hq3TM0k%2BuPv3Bg%2BFesaDgcaVdtmcc@mail.gmail.com> In-Reply-To: <AANLkTik-EGZx%2BybNoBgXKgmzEMK6vQD0xqhuoYjxaTa0@mail.gmail.com> References: <AANLkTimvjuvYJLbXgMsX%2BsRjGiNeXVFL%2BZZwf3W30oOn@mail.gmail.com> <AANLkTikBv%2BBSQbr0MfzkqhADC-twHsc=WNKTCLOU8x2=@mail.gmail.com> <AANLkTik6E74mcjEMde3MRnKF9PtHqp=eAe-xrZ2hJAW_@mail.gmail.com> <AANLkTinsiFeOGiBZHJf5rhfp83XCcGb6WSf6UxntZjYy@mail.gmail.com> <AANLkTik-EGZx%2BybNoBgXKgmzEMK6vQD0xqhuoYjxaTa0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I don't recall the exact particulars of the setup, I'm sorry.
Adrian
On 1 December 2010 17:03, Monthadar Al Jaberi <monthadar@gmail.com> wrote:
> On Wed, Dec 1, 2010 at 9:22 AM, Adrian Chadd <adrian@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@gmail.com> wrot=
e:
>>> On Wed, Dec 1, 2010 at 5:02 AM, Adrian Chadd <adrian@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
>>> /*
>>> =A0* Iterate the routing table and locate the next hop.
>>> =A0*/
>>> static struct ieee80211_node *
>>> mesh_find_txnode(struct ieee80211vap *vap,
>>> =A0 =A0const uint8_t dest[IEEE80211_ADDR_LEN])
>>> {
>>> ...
>>> if ((rt->rt_flags & IEEE80211_MESHRT_FLAGS_VALID) =3D=3D 0 ||
>>> =A0 =A0 =A0 =A0 =A0 =A0(rt->rt_flags & IEEE80211_MESHRT_FLAGS_PROXY)) {
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IEEE80211_NOTE_MAC(vap, IEEE80211_MSG_ME=
SH, dest,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"%s: !valid or proxy, flags 0x%x=
", __func__, rt->rt_flags);
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* XXX stat */
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return NULL;
>>> }
>>> ...
>>> }
>>>
>>> it stops if the dest node is a proxy. Then after failing in forwarding
>>> it goes out (=3D=3D discard frame?), I put a print message there to ver=
ify
>>> that it goes out:
>>> static int
>>> mesh_input(struct ieee80211_node *ni, struct mbuf *m, int rssi, int nf)
>>> {
>>> ...
>>> /*
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Potentially forward packet. =A0See ta=
ble s36 (p140)
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * for the rules. =A0XXX tap fwd'd packe=
ts not for us?
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dir =3D=3D IEEE80211_FC1_DIR_FROMDS =
||
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0!mesh_isucastforme(vap, wh, mc))=
{
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mesh_forward(vap, m, mc)=
;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dir =3D=3D IEEE80211=
_FC1_DIR_DSTODS)
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out=
;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* NB: fall thru to deli=
ver mcast frames locally */
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>>> ...
>>> }
>>>
>>> I am puzzeled... everyone says it works, did I miss something?! :P
>>>
>>>
>>> br,
>>>
>>>>
>>>>
>>>> adrian
>>>>
>>>> On 30 November 2010 15:38, Monthadar Al Jaberi <monthadar@gmail.com> w=
rote:
>>>>> 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=3D8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>>>>> metric 0 mtu 1500
>>>>> =A0 =A0 =A0 =A0options=3D80000<LINKSTATE>
>>>>> =A0 =A0 =A0 =A0ether XX:XX:XX:XX:XX:XX
>>>>> =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX <full-duplex>)
>>>>> =A0 =A0 =A0 =A0status: active
>>>>> wlan0: flags=3D8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>>>>> metric 0 mtu 1500
>>>>> =A0 =A0 =A0 =A0ether YY:YY:YY:YY:YY:YY
>>>>> =A0 =A0 =A0 =A0inet 192.168.1.91 netmask 0xffffff00 broadcast 192.168=
.1.255
>>>>> =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet autoselect mode 1=
1g <mesh>
>>>>> =A0 =A0 =A0 =A0status: running
>>>>> =A0 =A0 =A0 =A0meshid monty channel 1 (2412 MHz 11g) bssid 00:15:6d:6=
7:21:8d
>>>>> =A0 =A0 =A0 =A0country US ecm authmode OPEN privacy OFF txpower 20 sc=
anvalid 60
>>>>> =A0 =A0 =A0 =A0protmode CTS wme burst meshttl 31 meshpeering meshforw=
ard
>>>>> =A0 =A0 =A0 =A0meshmetric AIRTIME meshpath HWMP hwmprootmode DISABLED=
hwmpmaxhops 31
>>>>> bridge0: flags=3D28943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST=
,PPROMISC>
>>>>> metric 0 mtu 1500
>>>>> =A0 =A0 =A0 =A0ether ZZ:ZZ:ZZ:ZZ:ZZ:ZZ
>>>>> =A0 =A0 =A0 =A0id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddel=
ay 15
>>>>> =A0 =A0 =A0 =A0maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 120=
0
>>>>> =A0 =A0 =A0 =A0root id 00:00:00:00:00:00 priority 32768 ifcost 0 port=
0
>>>>> =A0 =A0 =A0 =A0member: arge0 flags=3D143<LEARNING,DISCOVER,AUTOEDGE,A=
UTOPTP>
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 4 priority 128 path c=
ost 200000
>>>>> =A0 =A0 =A0 =A0member: wlan0 flags=3D143<LEARNING,DISCOVER,AUTOEDGE,A=
UTOPTP>
>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifmaxaddr 0 port 7 priority 128 path c=
ost 370370
>>>>>
>>>>> br,
>>>>> --
>>>>> //Monthadar Al Jaberi
>>>>> _______________________________________________
>>>>> freebsd-net@freebsd.org mailing list
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org=
"
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> //Monthadar Al Jaberi
>>> _______________________________________________
>>> freebsd-net@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>>>
>>
>
>
>
> --
> //Monthadar Al Jaberi
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinJzzdhi65hq3TM0k%2BuPv3Bg%2BFesaDgcaVdtmcc>