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
