Inter-APs communication localhost

697 views
Skip to first unread message

Robert Erneborg

unread,
Mar 29, 2016, 3:59:40 AM3/29/16
to mininet-wifi-discuss
Hi,

recently I've been playing around with mininet-wifi and noticed that APs (as a node) communicates with each other through localhost, e.g. if AP1 pings AP2 it does this using localhost "outside" the topology. This is true even if there is no link between the two APs. I guess this i possible because of the (out of band) control network set up towards the controller?

Is there a way to force the APs to use the emulated network instead, and what interfaces (or python calls) needs to be set up? The reason I'm asking is because I want to run wifi control applications "inside" the AP. Essentially I need this software to run as if it was running on a host (using in-band data plane network). Any thoughts on the latter?

Best Regards,
Robert

Ramon Fontes

unread,
Mar 29, 2016, 9:16:55 AM3/29/16
to Robert Erneborg, mininet-wifi-discuss
Yes, you're right. I am just following the same structure of mininet, because in Mininet-WiFi APs are switches that have at least one wifi interface. The last question is another interesting question and makes sense. I am going to think about this for the next release. 

Best Regards,
Ramon Fontes

--
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 post to this group, send email to mininet-wi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mininet-wifi-discuss/3926ca1c-8a25-488a-9b3f-3c6b9ed8bc59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ramon Fontes

unread,
Mar 29, 2016, 2:37:48 PM3/29/16
to mininet-wifi-discuss, robert....@gmail.com
Did you try out the in-band control provided by ovs (https://github.com/openvswitch/ovs/blob/master/DESIGN.md)?


Em terça-feira, 29 de março de 2016 10:16:55 UTC-3, Ramon Fontes escreveu:
Yes, you're right. I am just following the same structure of mininet, because in Mininet-WiFi APs are switches that have at least one wifi interface. The last question is another interesting question and makes sense. I am going to think about this for the next release. 

Best Regards,
Ramon Fontes
2016-03-29 4:59 GMT-03:00 Robert Erneborg <robert....@gmail.com>:
Hi,

recently I've been playing around with mininet-wifi and noticed that APs (as a node) communicates with each other through localhost, e.g. if AP1 pings AP2 it does this using localhost "outside" the topology. This is true even if there is no link between the two APs. I guess this i possible because of the (out of band) control network set up towards the controller?

Is there a way to force the APs to use the emulated network instead, and what interfaces (or python calls) needs to be set up? The reason I'm asking is because I want to run wifi control applications "inside" the AP. Essentially I need this software to run as if it was running on a host (using in-band data plane network). Any thoughts on the latter?

Best Regards,
Robert

--
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-discuss+unsub...@googlegroups.com.
To post to this group, send email to mininet-wifi-discuss@googlegroups.com.

Robert Erneborg

unread,
Mar 30, 2016, 3:29:18 AM3/30/16
to mininet-wifi-discuss, robert....@gmail.com
no but will give it a go!


Den tisdag 29 mars 2016 kl. 20:37:48 UTC+2 skrev Ramon Fontes:
Did you try out the in-band control provided by ovs (https://github.com/openvswitch/ovs/blob/master/DESIGN.md)?

Em terça-feira, 29 de março de 2016 10:16:55 UTC-3, Ramon Fontes escreveu:
Yes, you're right. I am just following the same structure of mininet, because in Mininet-WiFi APs are switches that have at least one wifi interface. The last question is another interesting question and makes sense. I am going to think about this for the next release. 

Best Regards,
Ramon Fontes
2016-03-29 4:59 GMT-03:00 Robert Erneborg <robert....@gmail.com>:
Hi,

recently I've been playing around with mininet-wifi and noticed that APs (as a node) communicates with each other through localhost, e.g. if AP1 pings AP2 it does this using localhost "outside" the topology. This is true even if there is no link between the two APs. I guess this i possible because of the (out of band) control network set up towards the controller?

Is there a way to force the APs to use the emulated network instead, and what interfaces (or python calls) needs to be set up? The reason I'm asking is because I want to run wifi control applications "inside" the AP. Essentially I need this software to run as if it was running on a host (using in-band data plane network). Any thoughts on the latter?

Best Regards,
Robert

--
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-discuss+unsub...@googlegroups.com.
To post to this group, send email to mininet-wi...@googlegroups.com.

Robert Erneborg

unread,
Apr 4, 2016, 11:19:04 AM4/4/16
to mininet-wifi-discuss
I've been working on in-band control now for a wile. I have got it working, however I am experiencing unwanted/weird behaviors. My test file contains the following topology:
                h0   h1
                   \   /
                    s1  
                   /   \ 
                s2    s3  
               /       /    \
            h2    h3     s4
                            /    \ 
                         h4    h5
Where h0 is the in-band controller (OF default controller). All switches are connected to the controller (using in-band data network). I can see the switches registered at the controller and the controller registered at the switches. Furthermore, all switches has been assigned an IP (in the same subnet as the hosts), i.e. not the interfaces of the switches (e.g. s1-eth2 etc) but instead the sn interface (e.g. s1). I have tried assigning all interfaces but this didn't change a thing, and is also not preferable.

All hosts can communicate once the controller is up and running. Both host-switch and switch-switch connections appears to be working but are not.

If a switch pings another switch ("s4 ping s2" || "s4 ping -I s4 s2") the pings are only picked up by wireshark on localhost. The result is the same if i run a small echo server/client on the switches.
If I from h5 ping s2 wireshark will pick it up on all switches (in the path to s2) but s2 (which does not).

Am I missing something obvious? I want the switches to always use the in-band network. It's still unclear what traffic, and to what extent localhost is used although it appears to work using in-band.

Best Regards, Robert

Ps. I have attached the source of my test if that is to any help. Further more I had to do some modifications in the node.py source in order to get in-band to even slightly work:
- removed command self.checkListening() ---- (row 1445) in Controller class init.
- set inband default parameter to True. inband=True ---- (row 1088) OVSSwitch class init.
- self.controlIntf = Intf( name, self, port=0 ) --- Switch init (don't think this did anything)

Also Im using switches to make this conf a bit less complex and I assume that there really shouldn't be any difference to APs in terms of controller. Right?
remote.py

Ramon Fontes

unread,
Apr 4, 2016, 3:50:26 PM4/4/16
to Robert Erneborg, mininet-wifi-discuss
Yes, sure. ;)

Please add the parameter inband=True when you add switches. 

Note:
Add this class in you code:

class InbandController( RemoteController ):

    def checkListening( self ):
        "Overridden to do nothing."
        return

Then, call this class when you add the controller:
net.addController( 'c0', controller=InbandController, ip='10.0.0.1', port=6653 )

Thus you can run an in-band controller without modifying the mininet code itself.

I've just tried it with an external openflow controller, but you can do the same with reference controller. Change the OpenFlow controller port if necessary.

Cheers,
Ramon Fontes

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

Ramon Fontes

unread,
Apr 4, 2016, 6:57:44 PM4/4/16
to Robert Erneborg, mininet-wifi-discuss
Hi,

My full code looks like this:

I've tried to do the same with reference controller, but nothing happens when I start the controller. Actually, the command ˜controller -v ptcp:6633˜ do nothing and I don't know explain why. Alternatively you can open a new term to h0 and run an external controller from this host.

Ah! I had to set manually the IP address for all hosts (look at the code).

Let me know if you find a solution for reference controller.

Cheers,
Ramon Fontes 

Robert Erneborg

unread,
Apr 5, 2016, 2:06:17 PM4/5/16
to mininet-wifi-discuss, robert....@gmail.com
Hi,

Yes I got the reference controller working, but it was very strange. I couldn't get your source running but if I modified my code to look EXACTLY the same, row by row my worked.

Anyhow, the problem remains that the connection between the switches and the controller is not used by the links in the topology. I verified this by removing s3 and all its links in the topology. So s4, h4 and h5 are partitioned from the rest (espessially the controller on h0). The controller still connects to the switches, and this is also true if I run pox l2_learning controller. 

What I basically want to do is this:

where the author runs the ovs instances in their own network namespaces. I have not tried this yet. However, in the end I want this to run using APs and not switches and the linked solution is not applicable directly since the BaseStation class does much more. 

Do you think this is possible to achieve within a reasonable amount of time. To keep in mind is that I'm not really caught up in the mn source.

Also, do you know if anyone actually has gotten in-band control working properly before (i.e. in mn wifi)?

Best Regards, Robert

And thanks for all the feedback!
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-discuss+unsub...@googlegroups.com.

Ramon Fontes

unread,
Apr 6, 2016, 9:32:29 AM4/6/16
to Robert Erneborg, mininet-wifi-discuss
Hi,

I am using mn-wifi, but with your code (or the code that I sent you). I didn't try it with basestations yet, but I think the results should be the same. Look at this: https://www.dropbox.com/s/qgoa7pgq1l2jnsd/Screencast%202016-04-06%2010%3A25%3A47.mp4?dl=0

I cannot understand why you are able to run reference controller and I don't.

Are the results presented on the video different of your results?

Cheers,
Ramon Fontes

To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

Robert Erneborg

unread,
Apr 7, 2016, 4:37:14 AM4/7/16
to mininet-wifi-discuss, robert....@gmail.com
No, I don't understand it either. could be some weird ass python text formatting problem maybe (since your script didn't work for me either).

However, to answer your question. It's a bit difficult to see the exact addresses in wireshark in the vid but the problem I have is different.

I suspected that something was wrong with the connection between switches and controller (hosted by h0), so I changed the topology to look like this:
                h0   h1
                   \  /
                   s1  
                       
                s2    
               /          
              h2         s4
                          /   \ 
                       h4   h5

I just removed s3, h3 and the link between s2 and s1. Since its in-band control s4 (for example) should NOT be able to connect to the controller (you would think). But it does. Why this is, is beyond me. I think it loopback is used somehow, even though I specify the 'correct' addresses.

When browsing the interwebs I find it fairly difficult to find examples of mn in-band control. The one I linked is one (if not the only one) i found. The author forces the switch to use the emulated topology by starting it from a host, thus giving it a separate namespace (or that's what I think is happening). Since I haven't tested I can't confirm, but if it works and a similar solution would be possible for APs I think it would solve the problem.

Best Regards, Robert

PS. What controller are you running? i.e. software (pox, onos etc) and if you run any of the 'stock'(?) sources (e.g. l2_learning in pox) or you run some custom source.
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-discuss+unsub...@googlegroups.com.

--
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-discuss+unsub...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

Ramon Fontes

unread,
Apr 7, 2016, 6:19:09 PM4/7/16
to Robert Erneborg, mininet-wifi-discuss

I don't have my computer now to test it again, but I will.

I am running floodlight controller, but you can use any external controller (I'm not using any of the stock sources - just started the controller). You can see the video when I run the controller.

Please, give me more days. I am traveling and I will come back in 3 or 4 days.

-- Sent from my android

To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

Robert Erneborg

unread,
Apr 8, 2016, 4:52:57 AM4/8/16
to mininet-wifi-discuss, robert....@gmail.com
I see. For when you get back. I attached my topo script. To achieve the unwanted behavior I do the following.

1. run mn script.
2. h0 ping h1 - not successfull.
3. h4 ping h5 - not successfull
4. xterm h0 -> start controller
5. h4 ping h5 - successfull
6. h0 ping h1 - successfull
7. h4 ping h0 - not successfull.

2. and 3. are not supposed to be successful since there is no running controller. I then start the controller and try ping h5 from h4. This should not be possible since s4 is not in reach of s1-h0. Furthermore, h0 ping h1 should be possible since s1 is in reach of h0. h4 ping h0 (or the reverse) is not successful, nor should it.

My guess why this behavior is: Since the hosts are in separate namespaces they have to use the mn topo, thus they work as they should, i.e. can ping when they should be able to, and cant when they shouldn't. The switches (or APs) are not in a separate namespace and have access to all interfaces of the host machine. My guess, s4 connects to s1 (behind the scenes*) and via s1 to h0. I can partly verify this by removing the link between h0 and s1. If this is done then no switch can connect to the controller.

* behind the scenes is probably either using loopback or the interfaces (s1, s4) directly. since they are in the root namespace they can do this.

PS. I use the same topo as last post, i.e no links between s1, s2 or s4 (and s3 is removed entirely).
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-discuss+unsub...@googlegroups.com.

--
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-discuss+unsub...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

--
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-discuss+unsub...@googlegroups.com.
remote.py

Ramon Fontes

unread,
Apr 10, 2016, 8:43:24 PM4/10/16
to Robert Erneborg, mininet-wifi-discuss
Did you see this http://stackoverflow.com/questions/29985762/open-vswitch-in-band-control-how-it-works? It seems that even if the switches are not capable to communicate with the controller, OVS installs those hidden flows in in-band mode.

Typing  sh sudo ovs-appctl bridge/dump-flows s4, you can see:
mininet-wifi> sh sudo ovs-appctl bridge/dump-flows s4
duration=1s, priority=180005, n_packets=0, n_bytes=0, priority=180005,arp,arp_tpa=10.0.0.1,arp_op=2,actions=NORMAL
duration=1s, priority=180008, n_packets=0, n_bytes=0, priority=180008,tcp,nw_src=10.0.0.1,tp_src=6653,actions=NORMAL
duration=1s, priority=180000, n_packets=0, n_bytes=0, priority=180000,udp,in_port=LOCAL,dl_src=6e:dc:5c:55:d2:4e,tp_src=68,tp_dst=67,actions=NORMAL
duration=1s, priority=180006, n_packets=0, n_bytes=0, priority=180006,arp,arp_spa=10.0.0.1,arp_op=1,actions=NORMAL
duration=1s, priority=180007, n_packets=0, n_bytes=0, priority=180007,tcp,nw_dst=10.0.0.1,tp_dst=6653,actions=NORMAL
duration=1s, priority=180002, n_packets=0, n_bytes=0, priority=180002,arp,dl_src=6e:dc:5c:55:d2:4e,arp_op=1,actions=NORMAL
duration=1s, priority=180004, n_packets=0, n_bytes=0, priority=180004,arp,dl_src=64:70:02:79:5e:a4,arp_op=1,actions=NORMAL
duration=1s, priority=180003, n_packets=0, n_bytes=0, priority=180003,arp,dl_dst=64:70:02:79:5e:a4,arp_op=2,actions=NORMAL
duration=1s, priority=180001, n_packets=0, n_bytes=0, priority=180001,arp,dl_dst=6e:dc:5c:55:d2:4e,arp_op=2,actions=NORMAL
table_id=254, duration=1s, priority=0, n_packets=0, n_bytes=0, priority=0,reg0=0x3,actions=drop
table_id=254, duration=1s, priority=0, n_packets=13, n_bytes=1094, priority=0,reg0=0x1,actions=controller(reason=no_match)
table_id=254, duration=1s, priority=0, n_packets=0, n_bytes=0, priority=0,reg0=0x2,actions=drop

The problem here is the in_port=Local.

Alternatively you could do this:
1- Setting a new controller with a new port - sh ovs-vsctl set-controller s4 tcp:127.0.0.1:8000
2- Then, to remove hidden flows:
    sh ovs-vsctl set controller s4 connection-mode=out-of-band
    sh ovs-vsctl set bridge s4 other-config:disable-in-band=true
3- Hosts cannot ping each other.
4- You might add rows 1 and 2 in your code. Only 1 is enough to drop the communication between h4 and h5.




To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

Robert Erneborg

unread,
Apr 12, 2016, 5:40:20 AM4/12/16
to mininet-wifi-discuss, robert....@gmail.com
ok cool, maybe will take a look at it. I actually got switches and APs to run in their own separate netns. I have not verified that everything is working properly (yet) but can provide my solution (once verified polished a bit) if you're interested. Had to do quite a few modifications to the source.
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-discuss+unsub...@googlegroups.com.

--
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-discuss+unsub...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

--
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-discuss+unsub...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

--
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-discuss+unsub...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

Ramon Fontes

unread,
Apr 12, 2016, 9:35:31 AM4/12/16
to Robert Erneborg, mininet-wifi-discuss
Yes, of course. Please feel free to share/add any information regarding to this issue either here or in our wiki page. I would appreciate it. ;)


To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-dis...@googlegroups.com.

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

--
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 post to this group, send email to mininet-wi...@googlegroups.com.

Chih-Heng Ke

unread,
Apr 20, 2016, 10:40:00 PM4/20/16
to mininet-wifi-discuss, robert....@gmail.com
Hi,

    I provide a simple in-band control example.

h7-----s1-----AP1-----AP2

under AP1 cover area, there are three stations, sta2, sta3, and sta4.
under AP2 cover area, there is on station, i.e. sta5

I am using ./pox.py forwarding.l2_learning  Pox controller in h7.
The IP address for ap1 is 10.0.0.254.
The IP address for ap2 is 10.0.0.253.

stations can ping each other. Also station can ping AP1 and AP2.

.............................................................................................................................            

#!/usr/bin/python

from mininet.net import Mininet
from mininet.node import Controller, RemoteController, OVSKernelSwitch, IVSSwitch, UserSwitch
from mininet.link import Link, TCLink
from mininet.cli import CLI
from mininet.log import setLogLevel

class InbandController( RemoteController ):

    def checkListening( self ):
        "Overridden to do nothing."
        return

def topology():

    "Create a network."
    net = Mininet( controller=RemoteController, link=TCLink, switch=OVSKernelSwitch )

    print "*** Creating nodes"
    ap1 = net.addBaseStation( 'ap1', ssid= 'ssid1', mode= 'g', channel= '1', cls=OVSKernelSwitch, inband=True)
    ap2 = net.addBaseStation( 'ap2', ssid= 'ssid2', mode= 'g', channel= '6', cls=OVSKernelSwitch, inband=True)
    s1 = net.addSwitch( 's1', cls=OVSKernelSwitch, inband=True)
    sta2 = net.addStation( 'sta2', wlans=1, mac='00:02:00:00:00:02', ip='10.0.0.2/8' )
    sta3 = net.addStation( 'sta3', wlans=1, mac='00:02:00:00:00:03', ip='10.0.0.3/8' )
    sta4 = net.addStation( 'sta4', wlans=1, mac='00:02:00:00:00:04', ip='10.0.0.4/8' )
    sta5 = net.addStation( 'sta5', wlans=1, mac='00:02:00:00:00:05', ip='10.0.0.5/8' )
    c5 = net.addController( 'c5', controller=InbandController, ip='10.0.0.7', port=6633)
    h7 = net.addHost( 'h7', mac='00:00:00:00:00:07', ip='10.0.0.7/8' )
    
    print "*** Creating links"
    net.addLink(sta4, ap1)
    net.addLink(sta3, ap1)
    net.addLink(sta2, ap1)
    net.addLink(s1,ap1)
    net.addLink(h7,s1)
    net.addLink(ap1,ap2)
    net.addLink(sta5, ap2)
    
    print "*** Starting network"
    net.build()
    c5.start()
    s1.start( [c5] )
    ap1.start( [c5] )
    ap2.start( [c5] )
    
    s1.cmd("ifconfig s1 10.0.0.252 255.255.255.0")
    s1.cmd("ifconfig s1 up")

    ap1.cmd("ifconfig ap1 0")
    ap1.cmd("ip addr add 10.0.0.254/8 brd + dev ap1")
    ap1.cmd("ifconfig ap1 up")

    ap2.cmd("ifconfig ap2 0")
    ap2.cmd("ip addr add 10.0.0.253/8 brd + dev ap2")
    ap2.cmd("ifconfig ap2 up")


    print "*** Running CLI"
    CLI( net )

    print "*** Stopping network"
    net.stop()

if __name__ == '__main__':
    setLogLevel( 'info' )
    topology()

          

Venkat Iyer

unread,
Nov 2, 2016, 10:55:47 PM11/2/16
to mininet-wifi-discuss, robert....@gmail.com
how do i setup controller on another port? when i do sh ovs-vsctl set-controller s4 tcp:127.0.0.1:8000
it gives
sh: 0: Can't open ovs-vsctl

Is there anyway we can get over it?
To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-discuss+unsub...@googlegroups.com.

--
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-discuss+unsub...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

--
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-discuss+unsub...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

--
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-discuss+unsub...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

Ramon Fontes

unread,
Nov 3, 2016, 7:16:51 AM11/3/16
to Venkat Iyer, mininet-wifi-discuss
Defining a value for port should work fine, for example:

c0 = net.addController('c0', controller=Controller, ip='127.0.0.1', port=8000 )

To unsubscribe from this group and stop receiving emails from it, send an email to mininet-wifi-discuss+unsubscrib...@googlegroups.com.

--
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-discuss+unsubscrib...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

--
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-discuss+unsubscrib...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

--
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-discuss+unsubscrib...@googlegroups.com.

To post to this group, send email to mininet-wi...@googlegroups.com.

--
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-discuss+unsub...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages