Thanks for the reply Yiannis. The LLDP packets in openflow.discovery are sent to a broadcast MAC address which is why they go through. Is there a sysctl or some sort of config setting to make the wireless driver not drop packets with the 'wrong' MAC address?
Cheers, Alison On Thu, Nov 21, 2013 at 5:03 PM, Yiannis Yiakoumis <yiann...@stanford.edu> wrote: > The wireless part of the kernel might discard packets that don't have > expected addresses (e.g. the AP for client-mode, or an associated station > when on AP-mode). LLDP packets could probably go through in case they are > multicast/broadcast. > > Y. > > > On Thu, Nov 21, 2013 at 8:29 AM, Alison Chan <chan7...@kettering.edu> wrote: >> >> LLDP packets flow over the wireless interface, because pox's >> openflow.discovery sees the wireless link between the two switches. >> Why would the wireless interface be passing LLDP and nothing else? >> >> On Tue, Nov 19, 2013 at 6:15 PM, Alison Chan <chan7...@kettering.edu> >> wrote: >> > I just tried with one controller (my laptop, running pox with >> > info.packet_dump and forwarding.l2_learning) connected to both >> > switches. A host connected to switch A (host 1) was pinging a host >> > connected to switch B (host 2). >> > >> > According to the packet dumper, switch B sees the arp request from >> > host 1 and the arp reply from host 2, and pox installs a flow on >> > switch B from host 2's port (port 1) to the wireless port (port 5). >> > But switch A never sees the arp reply and neither does host 1. >> > >> > This is probably not an issue with switch A. When I connect a wireless >> > client (Ubuntu 12.04 PC with cheapie rt2800usb adapter) to switch A's >> > SSID, packets flow as expected. >> > >> > DEBUG:dump:aa-aa-aa-aa-aa-aa:[70:71:bc:d5:41:40>ff:ff:ff:ff:ff:ff >> > ARP][ARP REQUEST hw:1 p:2048 70:71:bc:d5:41:40>00:00:00:00:00:00 >> > 192.168.1.119>192.168.1.113][18 bytes: 00 00 00 00 00 ...] >> > DEBUG:dump:bb-bb-bb-bb-bb-bb:[70:71:bc:d5:41:40>ff:ff:ff:ff:ff:ff >> > ARP][ARP REQUEST hw:1 p:2048 70:71:bc:d5:41:40>00:00:00:00:00:00 >> > 192.168.1.119>192.168.1.113][18 bytes: 00 00 00 00 00 ...] >> > DEBUG:dump:bb-bb-bb-bb-bb-bb:[70:71:bc:d5:41:20>70:71:bc:d5:41:40 >> > ARP][ARP REPLY hw:1 p:2048 70:71:bc:d5:41:20>70:71:bc:d5:41:40 >> > 192.168.1.113>192.168.1.119][18 bytes: 00 00 00 00 00 ...] >> > DEBUG:forwarding.l2_learning:installing flow for 70:71:bc:d5:41:20.1 >> > -> 70:71:bc:d5:41:40.5 >> > >> > Cheers, >> > Alison >> > >> > On Tue, Nov 19, 2013 at 2:17 PM, Alison Chan <chan7...@kettering.edu> >> > wrote: >> >> Hello, >> >> >> >> I'm trying to interconnect several TL-WR1043ND with Pantou over their >> >> wireless links. I was able to get one (let's call it A) up and running >> >> on its wireless interface using AP mode, and wireless clients' traffic >> >> on that interface was controlled by OpenFlow. However, I am having >> >> some trouble configuring a second one (B) as a wireless client with >> >> that interface OpenFlow controlled. >> >> >> >> B associates to A's SSID and A's controller (pox running host_tracker) >> >> picks up that it's connected. (I think it sees B's arp packets, but I >> >> am not sure. I'll test soon with packet_dump module) However, traffic >> >> from a host attached to A to a host attached to B doesn't pass. >> >> >> >> Is there anything I should try or should be looking at? >> >> >> >> A diagramme of my topology is here: https://copy.com/uLC3xCeTl7Xu >> >> >> >> Thanks! >> >> >> >> -- >> >> Alison Chan >> >> chan7...@kettering.edu >> >> +1 909 278 7753 >> >> >> >> Sedulously eschew obfuscatory hyperverbosity or prolixity. >> > >> > >> > >> > -- >> > Alison Chan >> > chan7...@kettering.edu >> > +1 909 278 7753 >> > >> > Sedulously eschew obfuscatory hyperverbosity or prolixity. >> >> >> >> -- >> Alison Chan >> chan7...@kettering.edu >> +1 909 278 7753 >> >> Sedulously eschew obfuscatory hyperverbosity or prolixity. >> _______________________________________________ >> openflow-discuss mailing list >> openflow-discuss@lists.stanford.edu >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > -- Alison Chan chan7...@kettering.edu +1 909 278 7753 Sedulously eschew obfuscatory hyperverbosity or prolixity. _______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss