Closed daviddvs closed 6 years ago
Hi,
I just tested it with tcpdump
and it seems to work as expected.
mininet-wifi> ap1 tcpdump -i ap1-mp1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ap1-mp1, link-type EN10MB (Ethernet), capture size 262144 bytes
12:55:28.352977 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 12575, seq 1, length 64
12:55:28.356927 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 12575, seq 1, length 64
12:55:29.354371 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 12575, seq 2, length 64
12:55:29.355045 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 12575, seq 2, length 64
12:55:30.355524 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 12575, seq 3, length 64
12:55:30.356222 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 12575, seq 3, length 64
mininet-wifi> ap2 tcpdump -i ap2-mp1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ap2-mp1, link-type EN10MB (Ethernet), capture size 262144 bytes
12:58:48.110451 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 13393, seq 6, length 64
12:58:48.110793 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 13393, seq 6, length 64
12:58:49.112366 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 13393, seq 7, length 64
12:58:49.112733 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 13393, seq 7, length 64
12:58:50.113578 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 13393, seq 8, length 64
12:58:50.113922 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 13393, seq 8, length 64
Could you provide more details about the issue?
Hello,
Have you checked using a remote controller?
I know that with the local controller it works fine, my problem is that when I connect the topology to the remote ONOS controller (via OpenFlow 1.3 interface) ICMP packets (and I suppose that the rest of the packets) reach the AP1, they are forwarded via wireless interface (mesh link), but they do not arrive to the AP2.
AP1 has a flow rule to forward traffic from port1 to port2 but AP2 has not any installed rule (I have captured the OpenFlow dialogue between the AP2 and the ONOS controller and there is no PACKET_IN corresponding to the ICMP package). I conclude that, for any reason, packets do not reach the AP2.
Do I need any extra code (apart from the meshAP.py's one) to configure the mesh link between the APs in a remote controller?
My topo: h1----- [port1] AP1 [port2] ))) mesh )))) [port2] AP2 [port1]-----h2
My test: h1 ping h2
David
I just tested it with Ryu:
First I started Ryu with:
~/ryu$ PYTHONPATH=. ./bin/ryu-manager ryu/app/simple_switch_13.py
and then I ran meshAP.py
. After pinging sta2
from sta1
I can see icmp packets crossing ap2-mp1
.
sudo python examples/meshAP.py
[sudo] password for alpha:
*** Creating nodes
Connecting to remote controller at 127.0.0.1:6653
*** Configuring wifi nodes
*** Connecting to wmediumd server /var/run/wmediumd.sock
*** Associating Stations
Associating sta1-wlan0 to ap1
Associating sta2-wlan0 to ap2
*** Starting network
*** Configuring nodes
*** Running CLI
*** Starting CLI:
mininet-wifi> sta1 ping sta2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=12.7 ms
^C
--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 12.797/12.797/12.797/0.000 ms
mininet-wifi> xterm sta1
mininet-wifi> ap2 tcpdump -i ap2-mp1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ap2-mp1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:56:01.980386 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 18412, seq 1, length 64
14:56:01.980890 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 18412, seq 1, length 64
14:56:02.980842 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 18412, seq 2, length 64
14:56:02.981177 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 18412, seq 2, length 64
Ok, so the problem must be with the ONOS controller. I will try to debug and find out the error.
Thank you very much.
I have just tested the meshAP.py
example with the latest version of the ONOS controller and it works correctly.
Thank you very much, David
What happened?
I don't know exactly what the problem is, but the ONOS release 1.11 is not compatible with mesh links between APs. On the contrary, the latest version has no troubles to forward packets between APs connected via mesh link.
Hmm.. ok! Thank you for the pointers.
I’m using the same meshAP example, but no connection with mobility of AP. Is the mobility envisaged in meshAP?
I’m using the same meshAP example, but no connection with mobility of AP. Is the mobility envisaged in meshAP?
Yes.
Also mobility for the AP? Since I thought addLink method caused problems if there was enabled mobility in the APs, in fact I couldn’t ping stations when they are associated to their AP, and the APs connected one another with mesh…
Also mobility for the AP? Yes
Since I thought addLink method caused problems if there was enabled mobility in the APs, in fact I couldn’t ping stations when they are associated to their AP, and the APs connected one another with mesh…
With no detail about L2/L3 we cannot help you. Please note that saying it doesn't ping is too general. It is important that you analyze what you are observing, in detail.
I’m setting up a network where each AP is both AP for stations and mesh link with others APs. All the communication is managed by controller which basically makes routing from interface in mode g eith the station, then along the interfaces of aps mesh network mode s, to the interface between last ap in path and the other peer station in communication. I was implementing mesh network among the APs by setting the addLink as suggested in meshAP. No addLink between sta and AP so no problems with auto association. I implemented the mobility with get trace in order to build a custom model of mobility for both AP and Sta. It is quite strange that without mobility, so just positioning, it works good since controller route both arp and icmp accordingly to my algorithm. Getting the mobility inside the code makes not possible the ping anymore. I followed the example of replaying mobility and meshAP, respecting also the order of the order of the instructions. So my doubt was that the addLink of the mesh was not suitable with mobility… otherwise how can I do to implement mesh?
So my doubt was that the addLink of the mesh was not suitable with mobility…
This is irrelevant.
You didn't provide any information about L2/L3 yet.
`#!/usr/bin/env python
""" This example shows on how to create wireless link between two APs with mesh The wireless mesh network is based on IEEE 802.11s """ import os import sys import subprocess from mininet.log import setLogLevel, info from mn_wifi.link import wmediumd, mesh from mn_wifi.replaying import ReplayingMobility from mn_wifi.cli import CLI from mn_wifi.net import Mininet_wifi from mn_wifi.wmediumdConnector import interference from mininet.node import RemoteController, Controller
def gettrace(sta, file): file = open(file, 'r') rawdata = file.readlines() file_.close()
sta.p = []
pos = (-1000, 0, 0)
sta.position = pos
for data in raw_data:
line = data.split()
x = line[0] # First Column
y = line[1] # Second Column
pos = float(x), float(y), 0.0
sta.p.append(pos)
area_size = 350 avg_speed = 2 # velocità media dei droni
output_folder = os.path.dirname(os.path.abspath(file)) + '/replayingMobilityCustom/'
def starting_position(filename): file_path = os.path.join(output_folder, filename) if os.path.exists(file_path): with open(file_path, 'r') as file: line = file.readline().strip() if line: x, y = line.split() return f'{x},{y},0' return "0,0,0"
def topology(): "Create a network." net = Mininet_wifi(link=wmediumd, wmediumd_mode=interference)
info("*** Creating nodes\n")
aps=[]
for i in range(num_ap):
#min_x, min_y, max_x, max_y = calcola_vertici(starting_position(f'node_{i+1}.txt'), radius)
ap = net.addAccessPoint(f'ap{i+1}',wlans=2, ssid=f'ssid{i+1}', dpid=f'{i+1}', range=55,position=starting_position(f'node_{i+1}.txt'),speed=avg_speed, channel=i+1)
aps.append(ap)
stas=[]
for i in range(num_sta):
sta = net.addStation(f'sta{i+1}', position=starting_position(f'sta_{i+1}.txt'),range=35)
stas.append(sta)
c0 = net.addController('c0',controller=RemoteController)
info("*** Configuring nodes\n")
net.configureNodes()
info("*** Adding mesh links\n")
for i,ap in enumerate(aps):
net.addLink(ap, intf=f'ap{i+1}-wlan2', cls=mesh, ssid='mesh-ssid', channel=5)
#configureMesh(net, ssid='mesh-ssid')
net.plotGraph(max_x=area_size, max_y=area_size)
#tracking della posizione
net.isReplaying = True
#for i, sta in enumerate(stas):
#get_trace(sta, f'{output_folder}sta_{i + 1}.txt') #mobilità station
for i, ap in enumerate(aps):
get_trace(ap, f'{output_folder}node_{i + 1}.txt') #tracce di mobilità AP
info("*** Starting network\n")
net.build()
c0.start()
for ap in aps:
ap.start([c0]) # Avvia ogni AP
info("* Replaying Mobility\n")
ReplayingMobility(net)
info("*** Starting Socket Server\n")
net.socketServer(ip='127.0.0.1', port=12345)
info("*** Running CLI\n")
CLI(net)
info("*** Stopping network\n")
net.stop()
if name == 'main': setLogLevel('info') cleanup_output_folder(output_folder) run_preparation_script(area_size, num_nodes_per_side, node_spacing, radius, num_points_per_circle, output_folder) topology()`
This is the code I built, I just see different behavior if I implement the mobility or not: if there is no mobility then the controller route correctly the arp and icmp packets from an interface to the other, as I projected, according to the mac of the ap interfaces (I just build a binding with the interfaces and the datapath id in order to route the packet following a path provided by my algorithm: e.g. from interface 1 (wlan with sta) to interface 2 (mesh) and so on); if I add the get trace to support my custom mobility on the APs then no arp arrives to the destination neither comes back, I just see the packet in on the controller from the wlan interface of the AP and from the mesh interfaces of all APs (nothing dramatically changes with mobility, the movements are very little and the range is largely satisfied). Also all the stations are correctly associated with the AP in their range (if I perform a sta iwconfig). Please aske me for other details
Any conclusion about the flow tables and flow timeouts?
All set good and work as projected, but some issues across the mesh network: if I decide a path which includes 3 aps, the intermediate ap does not act as a relay node, even if the flow tables are correctly filled, unexpectedly the first ap directly talks with the last of the path, causing most of the packets to be lost due to distance probably… at least this is what I see on and ping method… what I have to focus on? am I forgetting something important?
Il giorno dom 7 lug 2024 alle 21:45 Ramon Fontes @.***> ha scritto:
Any conclusion about the flow tables and flow timeouts?
— Reply to this email directly, view it on GitHub https://github.com/intrig-unicamp/mininet-wifi/issues/192#issuecomment-2212549891, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXQWLN5TA5524SWZCHJM4MLZLGLD5AVCNFSM6AAAAABKPEGYMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJSGU2DSOBZGE . You are receiving this because you commented.Message ID: @.***>
Hi, I need to connect two APs through a wireless mesh link exactly like in the meshAP.py example. My problem is that when I connect the topology to the remote ONOS controller, packets (e.g. ping test) do not cross the wireless link. This link is detected by the controller, forwarding rules are installed in the first AP but no IP packet reaches the second AP.
Any idea on how to solve this problem?
Regards, David