> 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 >> ________________________________________ >> From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap >> [yap...@stanford.edu] >> Sent: May 11, 2012 14:23 >> To: Heming Wen >> Cc: Dan Talayco; openflow-discuss@lists.stanford.edu >> Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP >> >> Heming, >> >> Can I suggest you run through the OpenFlow tutorial? Getting familiar >> with the OpenFlow wireshark plugin, controller setup, etc should clear >> a lot of your doubts. There are a lot of materials out there (though >> they might not be very organized). The tutorial is usually a great >> start, thanks to Brandon and others' hard work. >> >> Regards >> KK >> >> On 11 May 2012 11:10, Heming Wen <heming....@mail.mcgill.ca> wrote: >>> Hi KK, >>> >>> I am using a controller running on a VM in Virtualbox under bridged mode >>> with its own IP address (192.168.1.203). In order to capture the packet in >>> a cleaner fashion, I used two different setup, both with 6633 as OF port. >>> In each of the setup, there is only the controller and the other device >>> present in the subnet. Here are the four test cases I ran: >>> >>> 1) PC controller with pyswitch (192.168.1.203) <-----> Pronto switch >>> (192.168.1.1) >>> >>> This is working as intended. A connectivity test between the controller and >>> switch is run every 15 seconds. Here is a slice of tcpdump of eth0 on the >>> controller I included for you to compare with the AP one which doesn't work: >>> >>> 1a) When pyswitch is not activated, the switch cannot establish the >>> connection as expected. It retries every 15 seconds. >>> >>> 11:25:54.413729 IP 192.168.1.1.47678 > 192.168.1.203.6633: Flags [S], seq >>> 632326855, win 5840, options [sackOK,TS val 148549274 ecr 0,mss >>> 1460,nop,wscale 5], length 0 >>> 11:25:54.413754 IP 192.168.1.203.6633 > 192.168.1.1.47678: Flags [R.], seq >>> 0, ack 632326856, win 0, length 0 >>> 11:26:09.414071 IP 192.168.1.1.47679 > 192.168.1.203.6633: Flags [S], seq >>> 872002931, win 5840, options [sackOK,TS val 148553024 ecr 0,mss >>> 1460,nop,wscale 5], length 0 >>> 11:26:09.414108 IP 192.168.1.203.6633 > 192.168.1.1.47679: Flags [R.], seq >>> 0, ack 872002932, win 0, length 0 >>> 11:26:14.411074 ARP, Request who-has 192.168.1.1 tell 192.168.1.203, length >>> 28 >>> 11:26:14.411374 ARP, Reply 192.168.1.1 is-at e8:9a:8f:fb:c3:7f, length 46 >>> 11:26:24.414151 IP 192.168.1.1.47680 > 192.168.1.203.6633: Flags [S], seq >>> 1113043895, win 5840, options [sackOK,TS val 148556774 ecr 0,mss >>> 1460,nop,wscale 5], length 0 >>> 11:26:24.414176 IP 192.168.1.203.6633 > 192.168.1.1.47680: Flags [R.], seq >>> 0, ack 1113043896, win 0, length 0 >>> 11:26:29.413669 ARP, Request who-has 192.168.1.203 tell 192.168.1.1, length >>> 46 >>> 11:26:29.413691 ARP, Reply 192.168.1.203 is-at 08:00:27:60:e6:e7, length 28 >>> >>> 1b) When pyswitch is activated, connection is established as intended. No >>> random disconnect occurs. A message is sent between the controller and >>> switch every 15 second. >>> >>> 11:28:09.413993 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack >>> 1, win 183, options [nop,nop,TS val 148583024 ecr 40338360], length 0 >>> 11:28:09.414043 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq >>> 1:9, ack 1, win 183, options [nop,nop,TS val 148583024 ecr 40338360], >>> length 8 >>> 11:28:09.414056 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [.], ack >>> 9, win 91, options [nop,nop,TS val 40338360 ecr 148583024], length 0 >>> 11:28:09.414472 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq >>> 1:9, ack 9, win 91, options [nop,nop,TS val 40338360 ecr 148583024], length >>> 8 >>> 11:28:09.414607 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq >>> 9:17, ack 9, win 91, options [nop,nop,TS val 40338360 ecr 148583024], >>> length 8 >>> 11:28:09.414690 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack >>> 9, win 183, options [nop,nop,TS val 148583024 ecr 40338360], length 0 >>> 11:28:09.414819 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack >>> 17, win 183, options [nop,nop,TS val 148583024 ecr 40338360], length 0 >>> 11:28:09.414927 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq >>> 17:29, ack 9, win 91, options [nop,nop,TS val 40338361 ecr 148583024], >>> length 12 >>> 11:28:09.415514 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack >>> 29, win 183, options [nop,nop,TS val 148583024 ecr 40338361], length 0 >>> 11:28:09.416910 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], seq >>> 9:1457, ack 29, win 183, options [nop,nop,TS val 148583024 ecr 40338361], >>> length 1448 >>> 11:28:09.416949 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq >>> 1457:2633, ack 29, win 183, options [nop,nop,TS val 148583024 ecr >>> 40338361], length 1176 >>> 11:28:09.416962 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [.], ack >>> 2633, win 181, options [nop,nop,TS val 40338361 ecr 148583024], length 0 >>> 11:28:09.417200 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq >>> 29:53, ack 2633, win 181, options [nop,nop,TS val 40338361 ecr 148583024], >>> length 24 >>> 11:28:09.418380 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq >>> 2633:2669, ack 53, win 183, options [nop,nop,TS val 148583025 ecr >>> 40338361], length 36 >>> 11:28:09.418596 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq >>> 53:125, ack 2669, win 181, options [nop,nop,TS val 40338361 ecr 148583025], >>> length 72 >>> 11:28:09.457692 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack >>> 125, win 183, options [nop,nop,TS val 148583035 ecr 40338361], length 0 >>> 11:28:24.413293 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq >>> 2669:2677, ack 125, win 183, options [nop,nop,TS val 148586774 ecr >>> 40338361], length 8 >>> 11:28:24.413536 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq >>> 125:133, ack 2677, win 181, options [nop,nop,TS val 40342110 ecr >>> 148586774], length 8 >>> 11:28:24.413725 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack >>> 133, win 183, options [nop,nop,TS val 148586774 ecr 40342110], length 0 >>> 11:28:39.413913 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq >>> 2677:2685, ack 133, win 183, options [nop,nop,TS val 148590524 ecr >>> 40342110], length 8 >>> 11:28:39.414183 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq >>> 133:141, ack 2685, win 181, options [nop,nop,TS val 40345860 ecr >>> 148590524], length 8 >>> 11:28:39.414403 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack >>> 141, win 183, options [nop,nop,TS val 148590524 ecr 40345860], length 0 >>> 11:28:54.413935 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [P.], seq >>> 2685:2693, ack 141, win 183, options [nop,nop,TS val 148594274 ecr >>> 40345860], length 8 >>> 11:28:54.414204 IP 192.168.1.203.6633 > 192.168.1.1.33405: Flags [P.], seq >>> 141:149, ack 2693, win 181, options [nop,nop,TS val 40349610 ecr >>> 148594274], length 8 >>> 11:28:54.414484 IP 192.168.1.1.33405 > 192.168.1.203.6633: Flags [.], ack >>> 149, win 183, options [nop,nop,TS val 148594274 ecr 40349610], length 0 >>> >>> 2) PC controller with pyswitch (192.168.1.203) <-----> Pc Engine AP >>> (192.168.1.189) >>> >>> Now for the case where it doesn't really work as intended. The AP connect >>> and disconnect from the controller due to " no response to inactivity probe >>> after 5 seconds, disconnecting". >>> >>> 2a) pyswitch not activated. The AP retries every 8 second or so. Just like >>> with the switch, the behaviour seems as expected. >>> >>> 11:03:35.149878 IP 192.168.1.189.60392 > 192.168.1.203.6633: Flags [S], seq >>> 3709438136, win 5840, options [mss 1460,sackOK,TS val 579519 ecr >>> 0,nop,wscale 4], length 0 >>> 11:03:35.149907 IP 192.168.1.203.6633 > 192.168.1.189.60392: Flags [R.], >>> seq 0, ack 3709438137, win 0, length 0 >>> 11:03:43.147437 IP 192.168.1.189.60393 > 192.168.1.203.6633: Flags [S], seq >>> 3834847840, win 5840, options [mss 1460,sackOK,TS val 581519 ecr >>> 0,nop,wscale 4], length 0 >>> 11:03:43.147466 IP 192.168.1.203.6633 > 192.168.1.189.60393: Flags [R.], >>> seq 0, ack 3834847841, win 0, length 0 >>> 11:03:48.146873 ARP, Request who-has 192.168.1.189 tell 192.168.1.203, >>> length 28 >>> 11:03:48.147436 ARP, Reply 192.168.1.189 is-at 00:23:20:d6:06:1f, length 46 >>> 11:03:51.140086 IP 192.168.1.189.60394 > 192.168.1.203.6633: Flags [S], seq >>> 3969455372, win 5840, options [mss 1460,sackOK,TS val 583518 ecr >>> 0,nop,wscale 4], length 0 >>> 11:03:51.140110 IP 192.168.1.203.6633 > 192.168.1.189.60394: Flags [R.], >>> seq 0, ack 3969455373, win 0, length 0 >>> 11:03:59.137615 IP 192.168.1.189.60395 > 192.168.1.203.6633: Flags [S], seq >>> 4090766827, win 5840, options [mss 1460,sackOK,TS val 585518 ecr >>> 0,nop,wscale 4], length 0 >>> 11:03:59.137640 IP 192.168.1.203.6633 > 192.168.1.189.60395: Flags [R.], >>> seq 0, ack 4090766828, win 0, length 0 >>> 11:04:07.130442 IP 192.168.1.189.60396 > 192.168.1.203.6633: Flags [S], seq >>> 4211263035, win 5840, options [mss 1460,sackOK,TS val 587517 ecr >>> 0,nop,wscale 4], length 0 >>> 11:04:07.130469 IP 192.168.1.203.6633 > 192.168.1.189.60396: Flags [R.], >>> seq 0, ack 4211263036, win 0, length 0 >>> 11:04:12.127764 ARP, Request who-has 192.168.1.203 tell 192.168.1.189, >>> length 46 >>> 11:04:12.127788 ARP, Reply 192.168.1.203 is-at 08:00:27:60:e6:e7, length 28 >>> >>> 2b) pyswitch activated. The AP connects to the controller, but then >>> disconnect shortly because it fails to receive keep-alive messages. Here is >>> two cycles of connect/disconnect: >>> >>> 11:36:18.979394 IP 192.168.1.189.56840 > 192.168.1.203.6633: Flags [S], seq >>> 156517514, win 5840, options [mss 1460,sackOK,TS val 1070398 ecr >>> 0,nop,wscale 4], length 0 >>> 11:36:18.979424 IP 192.168.1.203.6633 > 192.168.1.189.56840: Flags [R.], >>> seq 0, ack 156517515, win 0, length 0 >>> 11:36:26.976537 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [S], seq >>> 288016471, win 5840, options [mss 1460,sackOK,TS val 1072397 ecr >>> 0,nop,wscale 4], length 0 >>> 11:36:26.976577 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [S.], >>> seq 631201559, ack 288016472, win 5792, options [mss 1460,sackOK,TS val >>> 40462751 ecr 1072397,nop,wscale 6], length 0 >>> 11:36:26.977088 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [.], ack >>> 1, win 365, options [nop,nop,TS val 1072397 ecr 40462751], length 0 >>> 11:36:26.977144 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [P.], >>> seq 1:9, ack 1, win 365, options [nop,nop,TS val 1072397 ecr 40462751], >>> length 8 >>> 11:36:26.977160 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [.], ack >>> 9, win 91, options [nop,nop,TS val 40462751 ecr 1072397], length 0 >>> 11:36:26.977600 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 1:9, ack 9, win 91, options [nop,nop,TS val 40462751 ecr 1072397], >>> length 8 >>> 11:36:26.977692 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 9:17, ack 9, win 91, options [nop,nop,TS val 40462751 ecr 1072397], >>> length 8 >>> 11:36:26.977786 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 17:29, ack 9, win 91, options [nop,nop,TS val 40462751 ecr 1072397], >>> length 12 >>> 11:36:26.977863 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [.], ack >>> 9, win 365, options [nop,nop,TS val 1072397 ecr 40462751], length 0 >>> 11:36:26.977985 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [.], ack >>> 17, win 365, options [nop,nop,TS val 1072397 ecr 40462751], length 0 >>> 11:36:26.978079 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [.], ack >>> 29, win 365, options [nop,nop,TS val 1072397 ecr 40462751], length 0 >>> 11:36:26.978884 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [P.], >>> seq 9:185, ack 29, win 365, options [nop,nop,TS val 1072397 ecr 40462751], >>> length 176 >>> 11:36:26.979084 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 29:53, ack 185, win 108, options [nop,nop,TS val 40462752 ecr 1072397], >>> length 24 >>> 11:36:26.979634 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [P.], >>> seq 185:221, ack 53, win 365, options [nop,nop,TS val 1072397 ecr >>> 40462752], length 36 >>> 11:36:26.979888 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 53:125, ack 221, win 108, options [nop,nop,TS val 40462752 ecr >>> 1072397], length 72 >>> 11:36:27.182869 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 53:125, ack 221, win 108, options [nop,nop,TS val 40462803 ecr >>> 1072397], length 72 >>> 11:36:27.590900 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 53:125, ack 221, win 108, options [nop,nop,TS val 40462905 ecr >>> 1072397], length 72 >>> 11:36:28.406907 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 53:125, ack 221, win 108, options [nop,nop,TS val 40463109 ecr >>> 1072397], length 72 >>> 11:36:30.038873 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 53:125, ack 221, win 108, options [nop,nop,TS val 40463517 ecr >>> 1072397], length 72 >>> 11:36:33.303980 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 53:125, ack 221, win 108, options [nop,nop,TS val 40464333 ecr >>> 1072397], length 72 >>> 11:36:39.830905 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [P.], >>> seq 53:125, ack 221, win 108, options [nop,nop,TS val 40465965 ecr >>> 1072397], length 72 >>> 11:36:46.975768 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [S], seq >>> 604390870, win 5840, options [mss 1460,sackOK,TS val 1077396 ecr >>> 0,nop,wscale 4], length 0 >>> 11:36:46.975789 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [S.], >>> seq 2165900425, ack 604390871, win 5792, options [mss 1460,sackOK,TS val >>> 40467751 ecr 1077396,nop,wscale 6], length 0 >>> 11:36:46.976299 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [.], ack >>> 1, win 365, options [nop,nop,TS val 1077396 ecr 40467751], length 0 >>> 11:36:46.976456 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [P.], >>> seq 1:9, ack 1, win 365, options [nop,nop,TS val 1077396 ecr 40467751], >>> length 8 >>> 11:36:46.976466 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [.], ack >>> 9, win 91, options [nop,nop,TS val 40467751 ecr 1077396], length 0 >>> 11:36:46.976558 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 1:9, ack 9, win 91, options [nop,nop,TS val 40467751 ecr 1077396], >>> length 8 >>> 11:36:46.976618 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 9:17, ack 9, win 91, options [nop,nop,TS val 40467751 ecr 1077396], >>> length 8 >>> 11:36:46.976668 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 17:29, ack 9, win 91, options [nop,nop,TS val 40467751 ecr 1077396], >>> length 12 >>> 11:36:46.976852 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [.], ack >>> 9, win 365, options [nop,nop,TS val 1077396 ecr 40467751], length 0 >>> 11:36:46.976904 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [.], ack >>> 17, win 365, options [nop,nop,TS val 1077396 ecr 40467751], length 0 >>> 11:36:46.976956 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [.], ack >>> 29, win 365, options [nop,nop,TS val 1077396 ecr 40467751], length 0 >>> 11:36:46.977759 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [P.], >>> seq 9:185, ack 29, win 365, options [nop,nop,TS val 1077396 ecr 40467751], >>> length 176 >>> 11:36:46.977831 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 29:53, ack 185, win 108, options [nop,nop,TS val 40467751 ecr 1077396], >>> length 24 >>> 11:36:46.978361 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [P.], >>> seq 185:221, ack 53, win 365, options [nop,nop,TS val 1077396 ecr >>> 40467751], length 36 >>> 11:36:46.978462 IP 192.168.1.203.6633 > 192.168.1.189.56841: Flags [FP.], >>> seq 125:133, ack 221, win 108, options [nop,nop,TS val 40467751 ecr >>> 1072397], length 8 >>> 11:36:46.978515 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 53:125, ack 221, win 108, options [nop,nop,TS val 40467751 ecr >>> 1077396], length 72 >>> 11:36:46.979196 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [P.], >>> seq 221:313, ack 125, win 365, options [nop,nop,TS val 1077397 ecr >>> 40467751], length 92 >>> 11:36:46.979300 IP 192.168.1.189.56844 > 192.168.1.203.6633: Flags [P.], >>> seq 313:385, ack 125, win 365, options [nop,nop,TS val 1077397 ecr >>> 40467751], length 72 >>> 11:36:46.979306 IP 192.168.1.189.56841 > 192.168.1.203.6633: Flags [R], seq >>> 288016692, win 0, length 0 >>> 11:36:46.980084 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 125:149, ack 385, win 108, options [nop,nop,TS val 40467752 ecr >>> 1077397], length 24 >>> 11:36:46.980990 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 149:229, ack 385, win 108, options [nop,nop,TS val 40467752 ecr >>> 1077397], length 80 >>> 11:36:47.182857 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 125:149, ack 385, win 108, options [nop,nop,TS val 40467803 ecr >>> 1077397], length 24 >>> 11:36:47.590882 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 125:149, ack 385, win 108, options [nop,nop,TS val 40467905 ecr >>> 1077397], length 24 >>> 11:36:48.407692 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 125:149, ack 385, win 108, options [nop,nop,TS val 40468109 ecr >>> 1077397], length 24 >>> 11:36:50.038876 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 125:149, ack 385, win 108, options [nop,nop,TS val 40468517 ecr >>> 1077397], length 24 >>> 11:36:53.302861 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 125:149, ack 385, win 108, options [nop,nop,TS val 40469333 ecr >>> 1077397], length 24 >>> 11:36:59.831044 IP 192.168.1.203.6633 > 192.168.1.189.56844: Flags [P.], >>> seq 125:149, ack 385, win 108, options [nop,nop,TS val 40470965 ecr >>> 1077397], length 24 >>> >>> I noticed that the controller 192.168.1.203, shortly after establishing >>> connection, tries to send a packet to the AP continuously because it >>> doesn't receive any response from the AP. This happened at 11:36:26.979888 >>> and 11:36:46.980084. And then, the AP disconnects from the controller with >>> message " no response to inactivity probe after 5 seconds, disconnecting". >>> I wasn't able to obtain a good slice of the tcpdump on the AP side because >>> the traffic level was extremely high. I'll try to filter out some of it and >>> see if if the AP ever received the message from the controller. >>> >>> Do you have any suggestions for this issue? Should I use a different >>> controller (not pyswitch)? >>> >>> (I apologize for the long log files) >>> >>> Thank you, >>> Regards, >>> >>> Heming >>> ________________________________________ >>> From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap >>> [yap...@stanford.edu] >>> Sent: May 10, 2012 17:52 >>> To: Heming Wen >>> Cc: Dan Talayco; openflow-discuss@lists.stanford.edu >>> Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP >>> >>> Can you grab a tcpdump of the controller traffic and take a look >>> there? Why is the controller going silent? It should have some >>> keep-alive going. Which switch would this be on the AP? >>> >>> Regards >>> KK >>> >>> On 10 May 2012 13:56, Heming Wen <heming....@mail.mcgill.ca> wrote: >>>> Hi KK, >>>> >>>> Here is a "slice" of the log from the AP point of view (accessed through >>>> serial interface): >>>> >>>> Dec 31 16:00:51|00018|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connected >>>> Dec 31 16:00:51|00019|fail_open|WARN|No longer in fail-open mode >>>> [ 40.682489] ath5k phy0: unsupported jumbo >>>> Dec 31 16:01:01|00020|rconn|ERR|dp0<->tcp:192.168.1.203:6633: no response >>>> to inactivity probe after 5 seconds, disconnecting >>>> [ 44.599003] ath5k phy0: unsupported jumbo >>>> [ 44.663382] ath5k phy0: unsupported jumbo >>>> Dec 31 16:01:02|00021|rconn|INFO|dp0<->tcp:192.168.1.203:6633: >>>> connecting... >>>> Dec 31 16:01:03|00022|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connection >>>> timed out >>>> Dec 31 16:01:03|00023|rconn|INFO|dp0<->tcp:192.168.1.203:6633: waiting 2 >>>> seconds before reconnect >>>> [ 46.695553] ath5k phy0: unsupported jumbo >>>> Dec 31 16:01:05|00024|rconn|INFO|dp0<->tcp:192.168.1.203:6633: >>>> connecting... >>>> Dec 31 16:01:07|00025|fail_open|WARN|Could not connect to controller (or >>>> switch failed controller's post-connection admission control policy) for >>>> 15 seconds, failing open >>>> Dec 31 16:01:07|00026|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connection >>>> timed out >>>> Dec 31 16:01:07|00027|rconn|INFO|dp0<->tcp:192.168.1.203:6633: waiting 4 >>>> seconds before reconnect >>>> [ 50.176894] ath5k phy0: unsupported jumbo >>>> [ 53.487164] ath5k phy0: unsupported jumbo >>>> Dec 31 16:01:11|00028|rconn|INFO|dp0<->tcp:192.168.1.203:6633: >>>> connecting... >>>> Dec 31 16:01:11|00029|rconn|INFO|dp0<->tcp:192.168.1.203:6633: connected >>>> >>>> The problem is: " no response to inactivity probe after 5 seconds, >>>> disconnecting". This connect/disconnect cycle continues endlessly. >>>> >>>> On the controller side, here is a slice of the message: >>>> >>>> 00025|nox.coreapps.examples.pyswitch|INFO: Switch 1 has joined the network >>>> 00026|nox.coreapps.examples.pyswitch|INFO: Switch 1 has left the network >>>> 00027|nox.coreapps.examples.pyswitch|INFO: Switch 1 has joined the network >>>> 00028|nox.coreapps.examples.pyswitch|INFO: Switch 1 has left the network >>>> >>>> So it seems it's AP who's disconnecting on its own, not the controller. Do >>>> you know if this is a normal behavior? Did I miss something in the setup >>>> of the wireless AP? >>>> >>>> @Dan: >>>> >>>> Currently, the error I see above occur even if I have a direct ethernet >>>> connection between the AP and the controller PC. >>>> >>>> However, in the future setup, I plan to use a desktop switch to allow the >>>> same controller to control both the management port of the switch and the >>>> AP attached to the switching plane of the switch. In that setup, there >>>> will be a situation where the controller connection with the AP needs to >>>> be configured through OpenFlow. So I was wondering if the following still >>>> holds: >>>> >>>>> The main thing you want (need) to avoid is having the traffic for an >>>>> OpenFlow controller connection travel over a data plane that is itself >>>>> controlled by the same connection >>>> >>>> Because technically in my setup, the traffic of the OpenFlow controller >>>> connection with AP are travelling over the data plane controlled by a >>>> connection between the switch and the OpenFlow controller. So technically, >>>> it's two connections, one between switch and controller, the other between >>>> AP and controller. The controller connection with the switch does not go >>>> through the switching plane of itself (instead it goes through the >>>> switching plane of a third non-openflow switch). Would the concern you >>>> have still be valid in this case? Also, would the introduction of a third >>>> non-openflow switch be problematic? >>>> >>>> Here is a schematic of my planned setup: >>>> >>>> [controller PC] <----------> [D-link desktop switch (No Openflow)] >>>> [Pronto switch management port] <----------> [D-link desktop switch (No >>>> Openflow)] >>>> [Pronto switching plane port] <------------> [D-link desktop switch (No >>>> Openflow)] >>>> [Pc Engine AP] <---------------> [Pronto switching plane port] >>>> >>>> So the ports controlled by Openflow are the Pronto switch port. Since the >>>> only way the AP can be accessed by the controller is through the Pronto >>>> switch, the OF control messages with AP would be themselves flow entries >>>> in the OF-controlled switch. Would that be an issue? >>>> >>>> Thank you for your kind response, >>>> Regards, >>>> >>>> Heming >>>> ________________________________________ >>>> From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap >>>> [yap...@stanford.edu] >>>> Sent: May 10, 2012 15:51 >>>> To: Dan Talayco >>>> Cc: Heming Wen; openflow-discuss@lists.stanford.edu >>>> Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine AP >>>> >>>> Hi, >>>> >>>> If you are having the connection to AP come and go, you are probably >>>> having a connection. Question is why is the AP disconnecting. Look >>>> at the log of the controller. That should say something. >>>> >>>> Regards >>>> KK >>>> >>>> On 10 May 2012 12:30, Dan Talayco <dtala...@stanford.edu> wrote: >>>>> Sorry for the non-specific response. >>>>> >>>>> The main thing you want (need) to avoid is having the traffic for an >>>>> OpenFlow controller connection travel over a data plane that is itself >>>>> controlled by the same connection. In theory this can be made to work, >>>>> but >>>>> probably not without firmware changes to one or more of the devices >>>>> involved. >>>>> >>>>> -Dan >>>>> >>>>> On Thursday, May 10, 2012 at 12:09 PM, Heming Wen wrote: >>>>> >>>>> Hi KK, >>>>> >>>>> Thanks for the heads up. I am currently trying approach #1 (using extra >>>>> switch to connect everything under 1 subnet). Before doing that though, I >>>>> was trying to test the connection between nox and the PC engine AP. When I >>>>> was using pyswitch to test the connection, it seems that the AP's >>>>> connection >>>>> to the controller is constantly on and off (join and left the network >>>>> constantly). I am not sure if this is the normal behavior because pyswitch >>>>> probably was not designed for controlling the APs. Right now, the AP keeps >>>>> disconnecting from the controller. However, it did recognize the DPID I >>>>> set >>>>> for the AP (which was "1"). >>>>> >>>>> I am not sure if this is because I am using pyswitch instead of the >>>>> intended >>>>> OpenRoads controller. I will be using a different controller eventually >>>>> but >>>>> I wanted to know if there was something wrong with the AP-controller >>>>> connection to start off with. >>>>> >>>>> Thank you again, >>>>> >>>>> Heming >>>>> ________________________________________ >>>>> From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap >>>>> [yap...@stanford.edu] >>>>> Sent: May 10, 2012 13:55 >>>>> To: Heming Wen >>>>> Cc: Dan Talayco; openflow-discuss@lists.stanford.edu >>>>> Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine >>>>> AP >>>>> >>>>> Hi Heming, >>>>> >>>>> Some comments inline. >>>>> >>>>> Regards >>>>> KK >>>>> >>>>> On 10 May 2012 09:18, Heming Wen <heming....@mail.mcgill.ca> wrote: >>>>> >>>>> Hi KK, >>>>> >>>>> In terms of physical hardware, I believe we have the exact same set of >>>>> hardware mentioned in the Stanford OpenRoads testbed. We are using PC >>>>> Engine >>>>> AP and Pronto 3290 switches with Indigo installed. Right now, a controller >>>>> VM is running on a PC workstation connected to the management port of the >>>>> Pronto switch. Using simple pyswitch.py controller to detect devices, a >>>>> successful connection has been established between the switch and the >>>>> controller. >>>>> >>>>> When you say "make sure the controller is also accessible to the AP on the >>>>> datapath", I am not extremely sure about the approach I should take. Do >>>>> you >>>>> mean using a second switch (a smaller one, D-Link desktop switch for >>>>> instance) to connect the control port of the switch, the port of the Pc >>>>> workstation controller and the switching plane of the switch (on which the >>>>> AP is attached) together? >>>>> >>>>> >>>>> This should work in theory. I assume Indigo allows this. Dan should >>>>> be able to comment on this. It is setting up an out-of-band control >>>>> network. >>>>> >>>>> Or do you mean by having an extra network card installed on the controller >>>>> PC in order to be connected to both the control port of the switch and the >>>>> switching plane (using two subnets). >>>>> >>>>> >>>>> Yes, this is what Dan was describing and we have done this before. >>>>> With a NEC though. >>>>> >>>>> Or are you referring to something else entirely? Is it possible for us to >>>>> use the same approach you used in your setup so we can recreate it? >>>>> >>>>> >>>>> We had this setup in various forms over time, using different switches >>>>> and APs. There isn't a "particularly right" way to do this. It all >>>>> depends on the equipment you have at hand and what you are trying to >>>>> do. >>>>> >>>>> >>>>> Sorry for asking so many questions at once as I am still relatively new >>>>> with >>>>> networking in general. >>>>> >>>>> Thank you for your swift response and support. >>>>> >>>>> Heming >>>>> ________________________________________ >>>>> From: yap...@gmail.com [yap...@gmail.com] on behalf of kk yap >>>>> [yap...@stanford.edu] >>>>> Sent: May 9, 2012 22:19 >>>>> To: Heming Wen >>>>> Cc: Dan Talayco; openflow-discuss@lists.stanford.edu >>>>> Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine >>>>> AP >>>>> >>>>> Hi Heming, >>>>> >>>>> One way is to have only the AP in inband mode. Get your switch to the >>>>> controller, then make sure the controller is also accessible to the AP >>>>> on the datapath. We have had such a setup before. It should work. >>>>> >>>>> Regards >>>>> KK >>>>> >>>>> On 9 May 2012 18:42, Heming Wen <heming....@mail.mcgill.ca> wrote: >>>>> >>>>> Hi Dan, >>>>> >>>>> Actually, I was wondering about how the OpenRoads deployment was setup. I >>>>> thought the APs were attached to the OpenFlow switches? Or are they not >>>>> Pronto switches? In other words, how is the OpenRoads controller setup in >>>>> order to control both the switches and the AP at the same time? >>>>> >>>>> Thank you, >>>>> >>>>> Heming >>>>> ________________________________________ >>>>> From: Dan Talayco [dan.tala...@bigswitch.com] on behalf of Dan Talayco >>>>> [dtala...@stanford.edu] >>>>> Sent: May 9, 2012 18:00 >>>>> To: Heming Wen >>>>> Cc: openflow-discuss@lists.stanford.edu >>>>> Subject: Re: [openflow-discuss] OpenRoads controller link with PC Engine >>>>> AP >>>>> >>>>> I believe you're basically asking the switch to route (or at least switch) >>>>> between the management port and the dataplane. The short answer is that >>>>> the >>>>> switch won't do this and it's not planned to be supported. >>>>> >>>>> You probably want "physical in-band management" where the Pronto switch is >>>>> managed by a connection accessed through a data plane port. This feature >>>>> is >>>>> not yet fully supported on the Pronto platforms, although some people are >>>>> working with it now. Note that although physically on a dataplane port, >>>>> the >>>>> connection may still be logically separated from the OpenFlow controlled >>>>> traffic. >>>>> >>>>> If you take this approach (of physical in-band) would you expect to be >>>>> able >>>>> to dedicate a VLAN to management (including the controller traffic)? The >>>>> alternative is to have OpenFlow controlling the traffic to the controller, >>>>> something that has enough pitfalls that no one has really gotten it to >>>>> work >>>>> reliably. >>>>> >>>>> -Dan >>>>> >>>>> >>>>> On Wednesday, May 9, 2012 at 1:17 PM, Heming Wen wrote: >>>>> >>>>> Greetings, >>>>> >>>>> We are currently setting up a basic Openflow Wireless testbed with three >>>>> PC >>>>> Engine AP and a Pronto 3290 switch in our labs. We have a few questions >>>>> regarding the connection between the elements: >>>>> >>>>> 1) There are three controller path setups possible: L3 inband, tunneling >>>>> and >>>>> L2 inband. If we want to setup a small demo (n-casting for instance), is >>>>> there a preference for a particular configuration? >>>>> >>>>> 2) How must the Openflow controller connected to the network in order to >>>>> control the AP? Right now, the openflow controller is connected to the >>>>> special ethernet port of the Pronto switch (in order to control the >>>>> switch). >>>>> The default pyswitch controller can detect the Indigo/Pronto switch. >>>>> However, the AP is connected to the switching plane of the Pronto switch. >>>>> Is >>>>> there a way to access the switching plane ports from the control port or >>>>> must the controller be connected in a different fashion? Right now, >>>>> pinging >>>>> doesn't work between the switching plane and the control plane. >>>>> >>>>> Thank you for your help, >>>>> >>>>> Heming >>>>> _______________________________________________ >>>>> openflow-discuss mailing list >>>>> openflow-discuss@lists.stanford.edu<mailto:openflow-discuss@lists.stanford.edu> >>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>>> >>>>> _______________________________________________ >>>>> openflow-discuss mailing list >>>>> openflow-discuss@lists.stanford.edu >>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>>> >>>>> _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
