Changes between Version 18 and Version 19 of Internal/OpenFlow/DemoAPImage


Ignore:
Timestamp:
Oct 5, 2010, 4:36:45 PM (14 years ago)
Author:
ssugrim
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Internal/OpenFlow/DemoAPImage

    v18 v19  
    300300I've rolled all the startup commands into a script called start_ap.rb (I use ruby to wrap the exec calls). The start ap script assumes the database has already been primed with the bridge interfaces, etc... And that hostapd starts on reboot, it also has to bring up eth0 (nothing in the bridge does this). Currently it does not accept any paramters, it does however Invoke some calls. At some point I might need to adjust this to fix the SSID. I've saved an image and am trying to push it out to multiple nodes so that I can run some more tests.
    301301
    302 
    303 
     302=== 10/05/2010 ===
     303
     304After some experiments we discovered that the arp replies never get transmitted by the clients them selves. This is apparently a design feature intended to prevent arp table poisoning, and merging of the wireless and wired Ethernet broadcast domains. It's then the job of the access point, (the bridge in specific) to answer arps on behalf of the hosts on opposite sides of the bridge. This was confirmed by running a capture in the air and on the wire simultaneously, then originating a ping from the wired side in the winlab network with CISCO ap. On the originating client I can see an arp request go out and an arp reply come back, but in the air an independent listener sees the arp request but not the reply.
     305
     306The next step was to check if the Linux bridge tools did this as well. I installed a baseline system and then installed hostapd and bridge-utils.
     307
     308I modified hostapd in a similar fashsion, and used brctl to create a br0 and added the interfaces to it. Initally this did not work but looking at the [http://en.gentoo-wiki.com/wiki/Atheros_Ath5k_Wireless_Access_Point refrence] , it was pointed out that I needed assign an ip to the bridge interface as well. I guess the bridge interface needs an IP to craft packets IP packet responses, even tho this ip had nothing to do with the subnet I was passing traffic for,