This discussion may be more fitting for the pox-dev list. But starting with a simple component like l2_pairs, you need to modify its behavior when the input port is the wireless adapter. If the packet is to be flooded, it must be sent not only to the special flood/all virtual port, but also to the input-port virtual port. If the destination MAC has been learned to be on the same port as the input port (and it's the wireless port!), you need to send to the input-port virtual port instead of the numeric port number (since matching input and output port will result in a drop).
-- Murphy On Dec 30, 2013, at 12:51 PM, Sayed Qaiser Ali Shah <[email protected]> wrote: > Can you please help me out by highlighting some areas in code which I have to > modify? > > > On Tue, Dec 31, 2013 at 1:48 AM, Murphy McCauley <[email protected]> > wrote: > I can't answer for other people, but when I built a bunch of OpenFlow access > points, this is exactly what I did. > > -- Murphy > > On Dec 30, 2013, at 12:44 PM, Sayed Qaiser Ali Shah > <[email protected]> wrote: > >> Ok let me try. But I don't know how people have managed to work with >> wireless on openflow. The organizations that are using this. Don't know how >> they did it? Did they use same logic or they used some other way? >> >> >> On Tue, Dec 31, 2013 at 1:41 AM, Murphy McCauley <[email protected]> >> wrote: >> First figure out how to disable the wireless adapter's internal >> switch/bridging. >> >> Then modify your control logic so that it sends packets back through the >> wireless interface when appropriate. >> >> -- Murphy >> >> On Dec 30, 2013, at 12:38 PM, Sayed Qaiser Ali Shah >> <[email protected]> wrote: >> >>> Oh Murphy thanks for you kind help. That is what I was having problem as I >>> mentioned earlier that in port and out port should be wlan0? I mean what >>> you said. So what to do next to solve this issue? From where can I start? >>> >>> >>> On Tue, Dec 31, 2013 at 1:32 AM, Murphy McCauley >>> <[email protected]> wrote: >>> Ah. Wireless interfaces generally have what is basically their own >>> internal switch. When a packet comes in from one wireless client and is >>> destined for another wireless client, you may well never see it in the >>> OpenFlow switch because the packet never comes "out" of the interface and >>> instead takes a hairpin turn somewhere before that. >>> >>> This internal switch can sometimes be disabled (for example, I think you >>> may be able to do this on madwifi by setting ap_bridge to 0). However, >>> you'll usually need to do some modifications to your logic in the >>> controller to make this actually work. If you want the switch to forward >>> between two wireless devices, this looks like you're receiving and sending >>> over the same port. This is usually a bad thing, and OpenFlow doesn't do >>> it without an explicit output action to the special "input port" virtual >>> port. >>> >>> -- Murphy >>> >>> On Dec 30, 2013, at 8:50 AM, Sayed Qaiser Ali Shah >>> <[email protected]> wrote: >>> >>>> Thank you Murphy for your reply. I checked the problem by getting packets >>>> from wireshark and checked packet out. The problem I have is because of >>>> Wireless Interface. I am using wireless interface i.e. wlan0 for >>>> communication. I am pinging systems using WiFi. By checking POX controller >>>> I got that controller is sending flood message to AP. The following code >>>> of POX controller is executing >>>> >>>> else: >>>> if packet.dst not in self.macToPort: # 4 >>>> flood("Port for %s unknown -- flooding" % (packet.dst,)) # 4a >>>> >>>> which means that it not getting destination mac to be saved. Now I am >>>> unable to add flow manually because my data is transferring via wlan0 now >>>> what should I define for in port and out port? >>>> How can I add flow in Openwrt for two PCs using Wireless LAN? >>>> >>>> >>>> On Mon, Dec 30, 2013 at 1:32 PM, Sayed Qaiser Ali Shah >>>> <[email protected]> wrote: >>>> Yes Murphy I am using l2_learning and POX controller log shows switch is >>>> connected but is not taking any action. I am also confused and don't know >>>> what is the problem. >>>> May be there is problem with configuration of switch. Because when >>>> controller is down it still pings devices connected to switch. Don't know >>>> what to do with. >>>> >>>> >>>> On Mon, Dec 30, 2013 at 3:47 AM, Murphy McCauley >>>> <[email protected]> wrote: >>>> I'm confused. You say the controller isn't taking action, but also that >>>> you're running l2_learning (which takes action). >>>> >>>> If you run... >>>> ./pox.py samples.pretty_log --DEBUG openflow.of_01 --address=192.168.1.2 >>>> --port=6633 >>>> .. the POX log should say that the switches have connected and pings >>>> shouldn't go through. Yes? No? >>>> >>>> -- Murphy >>>> >>>> On Dec 29, 2013, at 1:55 PM, Sayed Qaiser Ali Shah >>>> <[email protected]> wrote: >>>> >>>>> Hello everybody, >>>>> >>>>> I am using POX controller on my Laptop. I have installed OpenWRT on TP >>>>> Link 1043 nd. IP's of devices are as follows. >>>>> WAN port of Tp Link to which Laptop (controller is attached) : 192.168.1.1 >>>>> IP of Laptop: 192.168.1.2 >>>>> >>>>> To assign different network to wireless devices >>>>> I have assigned IP to wlan0 via ifconfig. i.e. ifconfig wlan0 192.168.2.1 >>>>> IP of PC1: 192.168.2.2 >>>>> IP of PC2: 192.168.2.3 >>>>> >>>>> I connected PC1 and PC2 to devices successfully. Controller was unplugged >>>>> and when I pinged PC2 from PC1 it was successful. But what I want is >>>>> devices don't ping when controller has not defined a rule for that flow >>>>> and flow is saved in AP. >>>>> Note: I am getting packets (Logs) on controller but controller is not >>>>> taking any decision. I am running l2_learning just for checking by using >>>>> command >>>>> ./pox.py openflow.of_01 --address=192.168.1.2 --port=6633 >>>>> forwarding.l2_learning samples.pretty_log. >>>>> Please anybody help me out of this. I am stuck in this since last month. >>>>> >>>>> >>>>> -- >>>>> Regards >>>>> >>>>> Sayed Qaiser Ali Shah >>>>> MSI >>>>> NUST (SEECS) >>>>> _______________________________________________ >>>>> openflow-discuss mailing list >>>>> [email protected] >>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>> >>>> >>>> >>>> >>>> -- >>>> Regards >>>> >>>> Sayed Qaiser Ali Shah >>>> MSIT-12 >>>> NUST (SEECS) >>>> >>>> >>>> >>>> -- >>>> Regards >>>> >>>> Sayed Qaiser Ali Shah >>>> MSIT-12 >>>> NUST (SEECS) >>> >>> >>> >>> >>> -- >>> Regards >>> >>> Sayed Qaiser Ali Shah >>> MSIT-12 >>> NUST (SEECS) >> >> >> >> >> -- >> Regards >> >> Sayed Qaiser Ali Shah >> MSIT-12 >> NUST (SEECS) > > > > > -- > Regards > > Sayed Qaiser Ali Shah > MSIT-12 > NUST (SEECS)
_______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
