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?
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. 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? 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
