wireless connection to the controller

[Mahrokh Abdollahi]

Dear Ramon,

Hope you are doing well.

I tried to run the script that you had shared before as an example  of wireless connection between controller and AP at https://gist.github.com/ramonfontes/7beddaf5eebbfd35750efd7974bf22e4 .

However, I can't see any traffic passed to the controller when test connectivity between h1 and h2. I just provided a video in the below link that is showing the errors and output of Wireshark.

https://studentutsedu-my.sharepoint.com/:v:/r/personal/vijayadurga_chemalamarri_uts_edu_au/Documents/Mah/Screen%20Recording%202021-05-24%20at%201.09.03%20pm.mov?csf=1&web=1&e=6JabhG

I do appreciate your help.

Kind Regards,

Mahrokh

[Ramon Fontes]

Did you start a controller on c1?

Sent from my android

[Mahrokh Abdollahi]

Yes, I did.

--

Sent from Gmail Mobile

[Ramon Fontes]

Which AP you are using? OVS?

Sent from my android

[Mahrokh Abdollahi]

---------- Forwarded message ---------
From: Mahrokh Abdollahi <mahro...@gmail.com>
Date: Tue, 25 May 2021 at 05:39
Subject: Re: wireless connection to the controller
To: Ramon Fontes <ramonre...@gmail.com>

I am using UserAP . I have not changed the script that you have shared.

[Ramon Fontes]

You are certainly using ovs as a userap, while you should be using bofuss, since ovs does not support inNamespace. Btw, I'd appreciate if you provide more information about the issue. For example, I am almost sure that your controller is not connected to the AP and apparently you have not checked the flow tables.  You have been working on this for over a year and could give detailed information about the problem.

Sent from my android

--
You received this message because you are subscribed to the Google Groups "mininet-wifi-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/CAKg2J8Zbbpnz65_SrjqczHAeR53babDUasVXcRh8NDL-3pqMcg%40mail.gmail.com.

[durga]

Hi Ramon,

I am assisting Mahrokh with the problem. Below are steps followed and some observations.

As advised in your earlier email - 

Simple topology:

Below configurations were made:

1. Installed BOFUSS switch using sudo util/install.sh -3f

2. assigned IP address to AP

3. ran the controller application in sta1

When I captured packets using wireshark, I noticed unstable behaviour. As in sometimes OFPT_HELLO packets are exchanged and sometimes  they are not.  When hello messages are not exchanged - no openflow messages are sent across. In the below packet capture : 10.0.0.1 (sta1 running controller) doesn't seem to respond to 10.0.0.10(ap1)

But I can confirm that sometimes the connection is established as shown in the below screenshot. 

I can't exactly pinpoint what is the error - but I do see assertion errors like below too

Cheers!
Durga

To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/CAK8U23ZMc4bSftoMOTNb2zNxcyO3gY28QzbgTBt%3D8uZMkQUTcw%40mail.gmail.com.

[Ramon Fontes]

According to the screenshot the error might be related to the OpenFlow version. I suggest you explicitly define a version (e.g. 1.3).

[durga]

Hi Ramon,

Ryu's simple_switch_13.py application does explicitly set the OF version to 1.3.

For no apparent reason ( ryu --verbose doesn't show any anomalies), the controller session is killed.

Upon restarting the controller, on a few occasions I notice that packetin messages are processed.

As there is no difference in the mode of execution - its quite difficult to exactly pinpoint the exact reason.

Also, feature requests show v1.3. It can also be noticed how ping was successful during this run.

Cheers!
Durga

[durga]

Hi Ramon

In continuation to above email,

syslogs indicate probable reasons for 'killed' ryu process and no communication between APs and controller running on STA.

Ryu-manager process was killed as system was out of memory and for unknown reason the controller @ 10.0.0.1 :6653 (on STA1) is refusing connections.

kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=ryu-manager,pid=9444,uid=0

Jun  1 15:33:40 ubuntu kernel: [ 6433.087412] Out of memory: Killed process 9444 (ryu-manager) total-vm:3102352kB, anon-rss:3016624kB, file-rss:4104kB, shmem-rss:0kB, UID:0 pgtables:6104kB oom_score_adj:0

Jun  1 15:33:40 ubuntu kernel: [ 6433.143756] oom_reaper: reaped process 9444 (ryu-manager), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Jun  1 15:33:41 ubuntu ofprotocol: 00131|rconn|INFO|tcp:10.0.0.1:6653: connecting...

Jun  1 15:33:41 ubuntu ofprotocol: 00132|rconn|INFO|tcp:10.0.0.1:6653: connection failed (Connection reset by peer)

Jun  1 15:33:41 ubuntu ofprotocol: 00133|rconn|WARN|tcp:10.0.0.1:6653: connection dropped (Connection reset by peer)

Jun  1 15:33:41 ubuntu ofprotocol: 00134|rconn|INFO|tcp:10.0.0.1:6653: waiting 4 seconds before reconnect

Jun  1 15:33:45 ubuntu ofprotocol: 00135|rconn|INFO|tcp:10.0.0.1:6653: connecting...

Jun  1 15:33:45 ubuntu ofprotocol: 00136|rconn|INFO|tcp:10.0.0.1:6653: connection failed (Connection refused)

Jun  1 15:33:45 ubuntu ofprotocol: 00137|rconn|WARN|tcp:10.0.0.1:6653: connection dropped (Connection refused)

Jun  1 15:33:45 ubuntu ofprotocol: 00138|rconn|INFO|tcp:10.0.0.1:6653: waiting 4 seconds before reconnect

Jun  1 15:33:49 ubuntu ofprotocol: 00139|rconn|INFO|tcp:10.0.0.1:6653: connecting...

Jun  1 15:33:49 ubuntu ofprotocol: 00140|rconn|INFO|tcp:10.0.0.1:6653: connection failed (Connection refused)

Jun  1 15:33:49 ubuntu ofprotocol: 00141|rconn|WARN|tcp:10.0.0.1:6653: connection dropped (Connection refused)

Jun  1 15:33:49 ubuntu ofprotocol: 00142|rconn|INFO|tcp:10.0.0.1:6653: waiting 4 seconds before reconnect

Jun  1 15:33:53 ubuntu ofprotocol: 00143|rconn|INFO|tcp:10.0.0.1:6653: connecting...

I re-ran the controller to listen on port 6633 and the similar behaviour was exhibited, albeit one instance where the controller actually accepted connections. Do you have any thoughts on what is making the inband controller behave this way?

Jun  1 15:45:47 ubuntu hostapd: ap1-wlan1: STA 00:00:00:00:00:02 IEEE 802.11: associated (aid 1)

Jun  1 15:45:47 ubuntu hostapd: ap1-wlan1: STA 00:00:00:00:00:02 RADIUS: starting accounting session 5061C904442D8276

Jun  1 15:45:51 ubuntu ofprotocol: 00023|rconn|INFO|tcp:10.0.0.1:6633: connecting...

Jun  1 15:45:51 ubuntu ofprotocol: 00024|vconn_tcp|ERR|tcp:10.0.0.1:6633: connect: Network is unreachable

Jun  1 15:45:51 ubuntu ofprotocol: 00025|rconn|WARN|tcp:10.0.0.1:6633: connection failed (Network is unreachable)

Jun  1 15:45:51 ubuntu ofprotocol: 00026|rconn|INFO|tcp:10.0.0.1:6633: waiting 4 seconds before reconnect

Jun  1 15:45:55 ubuntu ofprotocol: 00027|rconn|INFO|tcp:10.0.0.1:6633: connecting...

Jun  1 15:45:55 ubuntu ofprotocol: 00028|rconn|INFO|tcp:10.0.0.1:6633: connection failed (Connection refused)

Jun  1 15:45:55 ubuntu ofprotocol: 00029|rconn|WARN|tcp:10.0.0.1:6633: connection dropped (Connection refused)

Jun  1 15:45:55 ubuntu ofprotocol: 00030|rconn|INFO|tcp:10.0.0.1:6633: waiting 4 seconds before reconnect

Jun  1 15:45:59 ubuntu ofprotocol: 00031|rconn|INFO|tcp:10.0.0.1:6633: connecting...

Jun  1 15:45:59 ubuntu ofprotocol: 00032|rconn|INFO|tcp:10.0.0.1:6633: connection failed (Connection refused)

Jun  1 15:45:59 ubuntu ofprotocol: 00033|rconn|WARN|tcp:10.0.0.1:6633: connection dropped (Connection refused)

Jun  1 15:45:59 ubuntu ofprotocol: 00034|rconn|INFO|tcp:10.0.0.1:6633: waiting 4 seconds before reconnect

Jun  1 15:46:03 ubuntu ofprotocol: 00035|rconn|INFO|tcp:10.0.0.1:6633: connecting...

Jun  1 15:46:03 ubuntu ofprotocol: 00036|rconn|INFO|tcp:10.0.0.1:6633: connection failed (Connection refused)

Jun  1 15:46:03 ubuntu ofprotocol: 00037|rconn|WARN|tcp:10.0.0.1:6633: connection dropped (Connection refused)

Jun  1 15:46:03 ubuntu ofprotocol: 00038|rconn|INFO|tcp:10.0.0.1:6633: waiting 4 seconds before reconnect

Jun  1 15:46:07 ubuntu ofprotocol: 00039|rconn|INFO|tcp:10.0.0.1:6633: connecting...

Jun  1 15:46:07 ubuntu ofprotocol: 00040|rconn|INFO|tcp:10.0.0.1:6633: connection failed (Connection refused)

Jun  1 15:46:07 ubuntu ofprotocol: 00041|rconn|WARN|tcp:10.0.0.1:6633: connection dropped (Connection refused)

Jun  1 15:46:07 ubuntu ofprotocol: 00042|rconn|INFO|tcp:10.0.0.1:6633: waiting 4 seconds before reconnect

Jun  1 15:46:11 ubuntu ofprotocol: 00043|rconn|INFO|tcp:10.0.0.1:6633: connecting...

Jun  1 15:46:11 ubuntu ofprotocol: 00044|rconn|INFO|tcp:10.0.0.1:6633: connection failed (Connection refused)

Jun  1 15:46:11 ubuntu ofprotocol: 00045|rconn|WARN|tcp:10.0.0.1:6633: connection dropped (Connection refused)

Jun  1 15:46:11 ubuntu ofprotocol: 00046|rconn|INFO|tcp:10.0.0.1:6633: waiting 4 seconds before reconnect

Jun  1 15:46:15 ubuntu ofprotocol: 00047|rconn|INFO|tcp:10.0.0.1:6633: connecting...

Jun  1 15:46:15 ubuntu ofprotocol: 00048|rconn|INFO|tcp:10.0.0.1:6633: connected

Jun  1 15:46:15 ubuntu ofdatapath: 00004|dp_acts|WARN|can't directly forward to input port.

Jun  1 15:46:15 ubuntu ofdatapath: 00005|dp_acts|WARN|can't directly forward to input port.

Jun  1 15:46:15 ubuntu ofdatapath: 00006|dp_acts|WARN|can't directly forward to input port.

Jun  1 15:46:15 ubuntu ofdatapath: 00007|dp_acts|WARN|can't directly forward to input port.

Cheers!
Durga

[Ramon Fontes]

Hi,

How can I reproduce this behavior?

[Ramon Fontes]

Dear Durga,

I will be happy if you send the messages to the mailing list. This code works fine for me - you only have to modify the way you start Ryu at L53.

Em ter., 1 de jun. de 2021 às 20:18, durga <c.vijay...@gmail.com> escreveu:

Hi Ramon,

Please find the attached topology generation script.

Upon starting the topology:

add IP address to ap1-wlan1

ap1 ifconfig ap1-wlan1 10.0.0.10 netmask 255.255.255.0 up

xterm sta1

ryu-manager simple_switch_13.py

I checked the logs available at /var/log.

Cheers!
Durga

[durga]

Hi Ramon

Thank you. I can confirm that running the controller as you suggested worked.

PS. I thought I 'replied all' w.r.t mailing list. Will keep that in mind.

Thanks again. Have a nice day

Cheers!
Durga

[durga]

Hi Ramon,

I am noticing that STA connects to only 1 AP when the topology has multiple APs.

According to you, can an STA connect to multiple APs simultaneously?

I am also noticing that based on position changes , the AP to which STA connects also changes. Is this observation valid?

example:

Jun 15 05:00:10 ubuntu kernel: [ 9307.658760] sta1-wlan0: associate with 00:00:00:00:00:03 (try 1/3)

Jun 15 05:00:10 ubuntu hostapd: ap3-wlan1: STA 00:00:00:00:00:fe IEEE 802.11: associated (aid 1)

Jun 15 05:00:10 ubuntu hostapd: ap3-wlan1: STA 00:00:00:00:00:fe RADIUS: starting accounting session 6EF389B8B0CAAB2A

Jun 15 05:00:10 ubuntu kernel: [ 9307.661166] sta1-wlan0: RX AssocResp from 00:00:00:00:00:03 (capab=0x401 status=0 aid=1)

Jun 15 05:09:08 ubuntu kernel: [ 9846.078987] sta1-wlan0: associate with 00:00:00:00:00:05 (try 1/3)

Jun 15 05:09:08 ubuntu hostapd: ap5-wlan1: STA 00:00:00:00:00:fe IEEE 802.11: associated (aid 1)

Jun 15 05:09:08 ubuntu hostapd: ap5-wlan1: STA 00:00:00:00:00:fe RADIUS: starting accounting session DD03D324C4DE4ACC

Jun 15 05:09:08 ubuntu kernel: [ 9846.080700] sta1-wlan0: RX AssocResp from 00:00:00:00:00:05 (capab=0x401 status=0 aid=1)

Thanks & Regards

Durga

[Ramon Fontes]

> I am noticing that STA connects to only 1 AP when the topology has multiple APs.According to you, can an STA connect to multiple APs simultaneously?

How many wifi interfaces does the station have?

> I am also noticing that based on position changes , the AP to which STA connects also changes. Is this observation valid?

This depends on the network topology and signal strength.

[durga]

Hi Ramon,

So STA can connect to multiple APs provided it has one interface for AP. Our topology had just one interface so it makes sense. Thank you.

The second point is concerning though. So if the signal strength is not set right, there are chances that an AP might loose connection with controller running on STA then?

Regards

Durga

--

Cheers!
Durga

[Ramon Fontes]

> The second point is concerning though. So if the signal strength is not set right, there are chances that an AP might loose connection with controller running on STA then?

You can force the association with addLink(). However, if you are using bgscan the association depends on the signal strength.

[durga]

Thank you for the clarification.

We will update the topology to reflect these points .

Thanks again. Have a nice day.

Regards

On Tue, 15 Jun 2021 at 10:51 pm, Ramon Fontes <ramonre...@gmail.com> wrote:

> The second point is concerning though. So if the signal strength is not set right, there are chances that an AP might loose connection with controller running on STA then?

You can force the association with addLink(). However, if you are using bgscan the association depends on the signal strength.

--

Cheers!
Durga