Hello again, First of all, I tried L2 inband mode (APTYPE=2) with VLAN and the AP does not disconnect from the controller. However, with VLAN I can't access the rest of my network so I would still like to use L3 inband (APTYPE=0). Thus, I looked further in the L3 inband configuration and noticed the following:
As mentioned previously, the connection between the AP and the controller has no problem starting up. Like my previous email mentioned, Hello/Hello, Features Request/Reply and Set Config are all passed and ACKed properly. However, remember I mentioned how the 'Flow Mod' command from the controller did not receive an ACK even though the AP received it and sent the ACK? In fact, this is because as soon as the Flow Mod message is received by the AP, the dp0 and eth0 interfaces no longer seem to be 'distinct' (i.e. both controller and datapath are now considered datapath). This causes the ACK to 'Flow Mod' itself to be sent as a 'Packet In' request from the AP! This is clearly not right because the controller path is supposed to be independent from the datapath. Now, because the ACK is sent as a Packet In, the controller is still waiting for the actual ACK and cannot process the new Packet In request. This problem doesn't seem to be unique to 'pyswitch' and 'monitor'. What is int eresting to note is that before the FIRST flow mod/packet out controller message, the controller and datapath interface of the AP function as intended (otherwise it cannot exchange hello and configs). With the default OpenFlow controller (controller ptcp:6633), the first 'Packet Out' command received by the AP causes the same problem. Do you know this type of problem is caused by the controller side or the AP side? I suspect either the 'flow mod' and 'packet out' command of the controller are overwriting the dp0/eth0 setting or that the controller is not aware of the dp0/eth0 separation. Otherwise, there is something off in the L3 inband setup. On the AP, are you using OVS to setup the dp0/eth0? Where is located the actual code to setup the L3 inband (as well as the other mode) on the AP? I know the configuration file is in /etc/ofwifi but which program is reading it? Is it ovs-openflowd? Thanks! Heming ________________________________________ From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap [yap...@stanford.edu] Sent: May 18, 2012 14:24 To: Heming Wen Cc: openflow-discuss@lists.stanford.edu; Masayoshi Kobayashi Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP > For both cases, the AP did send an ACK to the right port but for some reason > the controller never receives it. This is a bit strange because the > controller was able to receive ACK for all the other message prior to > disconnecting. I think you might have your problem there. Try to find out why. Good luck. Regards KK On 18 May 2012 10:52, Heming Wen <heming....@mail.mcgill.ca> wrote: > Hi KK, > > Ok, after examining the content of the packets using the Wireshark openflow > dissector, it seems that the message being blocked is slightly different > depending on the controller used. I capture on both the controller and the AP > side to debug. > > 1) When pyswitch (NOX Classic) is used: > > After Hello, Features Request/Reply and Set Config, a Vendor/Error message > occurs. However, this is still okay as the Pronto switch (which is working as > intended) gets the same message. However, then as part of the pyswitch > routine, the controller sends a Flow Mod: delete all matching flow message, > which never gets ACK back while the AP disconnects. This is strange because > on the AP side, the AP does send a ACK back for Flow Mod only 4ms later. > However, that ACK packet never got back to the controller. Then the AP sends > a Packet In message back to the controller, which never gets it as it's still > waiting for the ACK of Flow Mod. > > 2) When default OF controller is used (controller ptcp:6633): > > After Hello, Features Request/Reply and Set Config, the NiciraNe broadcast a > Packet In message (seems related to L3 inband), which causes the controller > to send a Packet Out reply. However, this Packet Out never gets ACK back and > in the meanwhile the AP disconnects from the controller. Again, on the AP > side, I was able to capture an ACK for Packet Out sent from the AP. However, > that ACK never reaches the controller. > > For both cases, the AP did send an ACK to the right port but for some reason > the controller never receives it. This is a bit strange because the > controller was able to receive ACK for all the other message prior to > disconnecting. > > Thanks, > Regards, > Heming > ________________________________________ > From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap > [yap...@stanford.edu] > Sent: May 18, 2012 11:32 > To: Heming Wen > Cc: openflow-discuss@lists.stanford.edu; Masayoshi Kobayashi > Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP > > Hi, some comments inline. > > Regards > KK > > On 18 May 2012 08:17, Heming Wen <heming....@mail.mcgill.ca> wrote: >> Hello again, >> >> It seems that the same problem persists with the PC Engine AP. The AP can >> connect to the controller. However, once connected, it immediately >> disconnects due to " no response to inactivity probe after 5 seconds". I >> checked the tcpdump on both controller and AP side and it seems that the >> controller, once connected, try to send packets to the AP but never got any >> reply back. Those packets actually arrived on the AP (can be seen on AP >> tcpdump) but the AP never sends an ACK back. Then, the AP disconnects from >> the controller. I have tried with different controllers (OF default >> controller, pyswitch in nox, l2 learning switch in pox) but the same problem >> persists. I have tried with both direct ethernet connection and connection >> through a switch. I am trying the default L3 inband. Should I try another >> type of configuration? > > What are the messages for which there was no reply? > >> Thus, I have a few questions concerning the PC Engine AP with Openflow: >> >> 1) Does the PC Engine AP require the SNMP subagents to be installed and >> running to remain connected to a normal openflow controller? I always >> thought the PC Engine AP was not necessarily OpenRoads specific. I ask this >> because I also tried the setup with the SNMP subagent installed but the same >> problem persists. However, I couldn't get the SNMP keepalive subagent to >> remain active. I believe that's another problem because I probably didn't >> activate snmp on the controller side. > > You are right, the SNMP is not needed. > >> 2) Are any additional crucial steps required on the AP side not contained in >> the PC Engine online installation tutorial? For instance, if I am using L3 >> Inband, other than changing ofwifi.conf file, was there another setup I >> should go through. One thing to note is that I did change the DPID in >> ofwifi.conf and that my AP are not connected to the Internet, so no valid >> gateway (isolated network). Could these configuration be the cause of the >> problem? > > This comment is somewhat general. :) > >> 3) Is there anywhere I can find access to the source code or some >> documentation of the PC Engine Openflow AP itself? It's a little hard to >> find out which sections are part of the default OS installation and which >> part are the customized sections. For instance, are custom/extra kernel >> modules installed? >> >> I am also wondering if anyone has tried the recently-updated PC Engine AP >> image (March 2012) and encountered a similar problem. I am not sure if I >> should use an older version of the image (with the old instructions) and try >> again. >> >> Thank you! >> >> Best Regards, >> Heming _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
