Multiple mesh gate on same network

[akshaypython]

Hi

I am trying to implement two mesh gates with one mesh point on same network. For mesh gates, I have set up the bridge between mesh interface and ethernet interface and have also enabled proactive PREQ with PREP on both nodes. (I have referred How To)

mesh gate 1 ----br0---eth0 mesh gate 2-----br1---eth0

Both these nodes start peer link management protocol and do four way handshake. But when I turn on mesh point to form a mesh network with these nodes. This mesh point starts peer link management protocol with only one of the mesh gate instead of doing with both.

However, Mesh point sends "mesh peering open" action packet for the mesh gate (which is not forming mesh network or starting peer management protocol). I think this node is in the range of other mesh nodes but somehow not sending or receiving any packet via mesh interface.

Could you please suggest how can I implement two mesh gate on same IP network? and how can mesh point able to start peer management protocol with both mesh gates?

Thanks, Akshay Jindal *Sorry If i have used wrong terminology as I new to mesh networks.

[chunyeow]

You need to turn on STP for both mesh gates to avoid loop formation.

For established mesh peering, as long as they are closed to each others, it should have no problem. Try using tcpdump or wireshark to trace the mesh peering open frame whether it is sent by your node.

---

Chun-Yeow

On Tue, Aug 23, 2016 at 5:07 PM, akshaypython notifications@github.com wrote:

Hi

I am trying to implement two mesh gates with one mesh point on same network. For mesh gates, I have set up the bridge between mesh interface and ethernet interface and have also enabled proactive PREQ with PREP on both nodes. (I have referred How To)

mesh gate 1 ----br0---eth0 mesh gate 2-----br1---eth0

Both these nodes start peer link management protocol and do four way handshake. But when I turn on mesh point to form a mesh network with these nodes. This mesh point starts peer link management protocol with only one of the mesh gate instead of doing with both.

However, Mesh point sends "mesh peering open" action packet for the mesh gate (which is not forming mesh network or starting peer management protocol). I think this node is in the range of other mesh nodes but somehow not sending or receiving any packet via mesh interface.

Could you please suggest how can I implement two mesh gate on same IP network? and how can mesh point able to start peer management protocol with both mesh gates?

Thanks, Akshay Jindal *Sorry If i have used wrong terminology as I new to mesh networks.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/o11s/open80211s/issues/51, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewmcOyUh0ZrKYvlQ4aMJe361Iq6xsks5qirhegaJpZM4JqtJN .

[akshaypython]

Thanks Chun-Yeow

It is working now, I can see peering management packets from both mesh gates and mesh point . But I am still not sure how turning on STP solved this issue? Can you please explain what bridging and STP are doing?

How can I observe that mesh peer open packet (sent by mesh gate) is lost due to broadcast storm or looping when STP is off?

Bridging mesh interface and ethernet is the only way to create mesh gate?

I am using Raspberry Pis as my mesh nodes and sniffing packets on my laptop by running wlan0 into monitor mode. I am not able to capture what happened at bridge interface when STP was off or looping.

Thanks.

[chunyeow]

STP may not affects the mesh peering management frame. If you bridge both mesh node to your ethernet interface, you need STP to be turned on.

For mesh peering management, try to sniff whether your mesh gateway sending out the beacon frame or mesh peering frame.

Also use "iw mesh0 station dump" to check the mesh plink state. You should at least have LISTEN state if the mesh node can hear from another mesh node.

On Fri, Aug 26, 2016 at 9:04 PM, akshaypython notifications@github.com wrote:

Thanks Chun-Yeow

It is working now, I can see peering management packets from both mesh gates and mesh point . But I am still not sure how turning on STP solved this issue? Can you please explain what bridging and STP are doing?

How can I observe that mesh peer open packet (sent by mesh gate) is lost due to broadcast storm or looping when STP is off?

Bridging mesh interface and ethernet is the only way to create mesh gate?

I am using Raspberry Pis as my mesh nodes and sniffing packets on my laptop by running wlan0 into monitor mode. I am not able to capture what happened at bridge interface when STP was off or looping.

Thanks.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/o11s/open80211s/issues/51#issuecomment-242729705, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewp2tAbch3Z4IxnTvyuSpxxFnaWqjks5qjuRzgaJpZM4JqtJN .

[akshaypython]

Okay.. Thanks. I am trying to capture mesh peering packets on mesh gate using tshark but somehow i am no able to capture these packets.

There are three interfaces at mesh gate

1. mesh
2. eth0
3. br0 (bridhe between mesh and ethernet)

I tried to run tshark on mesh interface as soon as mesh node turned on but it does not show me peering packets as well as path req-reply packets. If i ping mesh node from mesh gate then i can see icmp packets.

Could you please tell how can I capture mesh peering packets on mesh gate and on which interface?

I actually want to see what happens at mesh gate with the mesh peering packet when STP is off.

[chunyeow]

You need monitor mode on WiFi interface to capture 802.11 management/control frame.

On Mon, Aug 29, 2016 at 4:39 PM, akshaypython notifications@github.com wrote:

Okay.. Thanks. I am trying to capture mesh peering packets on mesh gate using tshark but somehow i am no able to capture these packets.

There are three interfaces at mesh gate

1. mesh
2. eth0
3. br0 (bridhe between mesh and ethernet)

I tried to run tshark on mesh interface as soon as mesh node turned on but it does not show me peering packets as well as path req-reply packets. If i ping mesh node from mesh gate then i can see icmp packets.

Could you please tell how can I capture mesh peering packets on mesh gate and on which interface?

I actually want to see what happens at mesh gate with the mesh peering packet when STP is off.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/o11s/open80211s/issues/51#issuecomment-243065902, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewsekB9fYlTqQLdRKqojKGPcKtk68ks5qkprFgaJpZM4JqtJN .

[akshaypython]

Okay.. Thank you.

Both mesh gates are setting peer management protocol with mesh station and also with each other. One of the mesh gate can communicate with mesh station within mesh network. But other mesh gate is communicating via router because I can see extended address in the packet.

mesh gate 1 - >within mesh communication as no extended addresses -> mesh station 1 mesh gate 2 -> ICMP packet is going via ethernet to router then to mesh gate 2 -> mesh station 1

Could you please tell why mesh gate 2 is not communicating within mesh?

[chunyeow]

Both mesh gates connected to the same LAN?

On Thu, Sep 1, 2016 at 4:53 PM, akshaypython notifications@github.com wrote:

Okay.. Thank you.

Both mesh gates are setting peer management protocol with mesh station and also with each other. One of the mesh gate can communicate with mesh station within mesh network. But other mesh gate is communicating via router because I can see extended address in the packet.

mesh gate 1 - >within mesh communication as no extended addresses -> mesh station 1 mesh gate 2 -> ICMP packet is going via ethernet to router then to mesh gate 2 -> mesh station 1

Could you please tell why mesh gate 2 is not communicating within mesh?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/o11s/open80211s/issues/51#issuecomment-244017462, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewuL1j76fjCGs35A2HBbmHP8MQZLgks5qlpKmgaJpZM4JqtJN .

[akshaypython]

Yes both mesh gates are connected to same router via Ethernet cable.

when STP is on : 1) Peering done between all nodes 2) mesh gate 1 (bridged br0 - mesh interface and eth0) - >within mesh communication as no extended addresses -> mesh station 1 2) mesh gate 2 (bridged br1 - mesh interface and eth0) -> ICMP packet is going via ethernet to router then to mesh gate 1 -> mesh station 1

when STP is turned off: 1) mesh gate 2 will not be able to start peering management protocol with mesh station 1. Mesh station 1 keep sending mesh peering open frame for this mesh gate 2 but there is no peer open frames from mesh gate 2. 2) Now if mesh station 1 pings that mesh gate 2 then it seems to be outside node for the mesh network. ICMP packets were going from mesh station 1 to mesh gate 1 over mesh network and then to mesh gate 2 via Ethernet or vice versa because we saw mesh extended addresses in the packets.

-- Why there are extended addresses when mesh station 1 is sending packets to mesh gate 2 whether stp is on or off?

DHCP server is running on the router and it is assigning dynamic addresses to all nodes.

[chunyeow]

STP on is correct behaviour, one of the mesh gate will not allow the packet with destination MAC address to mesh station 1 to pass through and close the port.

STP can't be turned off if your bridge both mesh gate with Ethernet. It will cause broadcast storm.

You can disable the bridging first in the mesh gates, let them peers with each others, then bridge it with Ethernet interface. To say that, your topology needs STP on to avoid switching loop.

On Fri, Sep 2, 2016 at 5:26 PM, akshaypython notifications@github.com wrote:

Yes both mesh gates are connected to same router via Ethernet cable.

[image: peerlink1] https://cloud.githubusercontent.com/assets/19374502/18199314/09f52a82-7100-11e6-9dda-2af6692d1de3.jpg

when STP is on : 1) Peering done between all nodes 2) mesh gate 1 (bridged br0 - mesh interface and eth0) - >within mesh communication as no extended addresses -> mesh station 1 2) mesh gate 2 (bridged br1 - mesh interface and eth0) -> ICMP packet is going via ethernet to router then to mesh gate 1 -> mesh station 1

when STP is turned off: 1) mesh gate 2 will not be able to start peering management protocol with mesh station 1. Mesh station 1 keep sending mesh peering open frame for this mesh gate 2 but there is no peer open frames from mesh gate 2. 2) Now if mesh station 1 pings that mesh gate 2 then it seems to be outside node for the mesh network. ICMP packets were going from mesh station 1 to mesh gate 1 over mesh network and then to mesh gate 2 via Ethernet or vice versa because we saw mesh extended addresses in the packets.

-- Why there are extended addresses when mesh station 1 is sending packets to mesh gate 2 whether stp is on or off?

DHCP server is running on the router and it is assigning dynamic addresses to all nodes.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/o11s/open80211s/issues/51#issuecomment-244327532, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBewkWcbpraw9hTfoQ5MamZd7uG8cfXks5ql-vGgaJpZM4JqtJN .

[akshaypython]

Yes only one mesh gate (mesh gate 1) will allow packets to go outside mesh (for example google.com) or vice versa. But my problem is that the other mesh gate (mesh station with added functionalities) should behave like a mesh station 1 with in mesh network.

mesh gate 1----ping----mesh gate 2

if mesh station 1 ping mesh gate 2 then its reply should come out from mesh interface (basically packets should remain within mesh). However, it is going over Ethernet in my case.

Now I assume if STP is doing something over bridge interface and setting path in such way that packets from mesh gate (ICMP reply packets from mesh gate 2 and destined for mesh station 1) are going over Ethernet. Is this allowed conceptually or as per standards?

Shouldn't they remain within mesh as peering is already done? Is there any way to analyse STP over bridge network?

Thanks !!

[chunyeow]

On Fri, Sep 2, 2016 at 7:38 PM, akshaypython notifications@github.com wrote:

Yes only one mesh gate (mesh gate 1) will allow packets to go outside mesh (for example google.com) or vice versa. But my problem is that the other mesh gate (mesh station with added functionalities) should behave like a mesh station 1 with in mesh network.

mesh gate 1----ping----mesh gate 2

if mesh station 1 ping mesh gate 2 then its reply should come out from mesh interface (basically packets should remain within mesh). However, it is going over Ethernet in my case.

mesh station 1 or mesh gate 1, confuse.

Now I assume if STP is doing something over bridge interface and setting path in such way that packets from mesh gate (ICMP reply packets from mesh gate 2 and destined for mesh station 1) are going over Ethernet. Is this allowed conceptually or as per standards?

STP turned on, one of the port will be blocked to avoid bridging loop.

Shouldn't they remain within mesh as peering is already done? Is there any way to analyse STP over bridge network?

You can dig into the source code. Or else do tcpdump to analyze further