Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On 01/25/2015 03:07 AM, Outback Dingo wrote: my first initial and only thought is over stauration on your network, i dont see anything of enterprise grade APs listed with 30+ users, how many connections and how many users? are they all trying to download/move data at the same time. Looking at the leases file we have 90 devices getting IPs. That's about right for the 30 or so people + all the other devices connected. The users are split up now on 3 APs all on different channels. 1 AP on the 11th floor: (tplink stock) 16-20 clients. 2 APs on the 10th floor: (tplink stock and Wndr3700v2 OpenWRT) each 10 floor AP has 10ish clients You can see all AP's from both floors but the AP not on the floor with you has a pretty low signal. Low but still usable. From watching what's going on at the radiotap level via horst I don't see a very high level of utilisation but I've still not been able to catch things in the act of a total fail yet. -- Richard A. Smith ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Sun, 25 Jan 2015 20:39:23 -0800, David Lang said: Much as you may hate the abuse of standards and protocols that F5 and other load balancers use to trick both clients and servers into operating without knowing that there are multiple machines serving a website, they do make things a lot more better than if you tried make a website reliable and scale without them. Oh, I'm fully aware of that. We have several of the beasts across the hall from my office. :) pgp_eZH2qyzNg.pgp Description: PGP signature ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
it doesn't get mixed in with tracking Internet routes as well. On Mon, 26 Jan 2015, dpr...@reed.com wrote: And having every /48 MAC address in your entterprise tracked is cheaper? On Sunday, January 25, 2015 11:44pm, David Lang da...@lang.hm said: On Sun, 25 Jan 2015, valdis.kletni...@vt.edu wrote: On Sun, 25 Jan 2015 18:09:59 -0800, David Lang said: The difference is that the switches and their protocols have been designed from the beginning for this scale of operation, IP routing protocols are designed for much fewer endpoints to track. Anybody who's carrying a full routing table was swallowing on the order of 528,833 routes (as of Friday's weekly routing table report posted to NANOG). Pretty much everybody and their pet llama accepts full tables thesedays. You know anybody who's doing that many entries in an L2 Ethernet broadcast domain? The full IP routing tables are something that you normally only have to deal with in a few devices at the perimeter of your network. What is being talked about here is routing each /32 IP address individually throughout your network so that any IP address can be connected anywhere and have it 'just work' as far as the client on that IP is concerned. David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Mon, 26 Jan 2015, dpr...@reed.com wrote: As far as NAT'ing is concerned - that is done by the gateways. It's possible in principle to create a distributed NAT face to an Enterprise - if you do so, then roaming within the enterprise just amounts to telling the NAT face about the new internal IP address that corresponds to the old one - an update of one address translation with another. remember that the claim was that you could have the APs route, not bridge, but let a device move from being connected to one AP to being connected to another AP without it needing to change it's IP address and without the connections using that IP address getting broken. How you would do this is the problem. Getting traffic to the device could be done if you detect it's movement and change your IP routing tables, but getting data from the device is going to be harder because the device is going to keep sending traffic to the same gateway. So you either need to pull layer 2 tricks to get the packets to the right gateway before processing them, or you need the new AP to handle packets sent to the IP address of the old AP. If you do NAT or stateful packet filtering on the AP, you also need the that state to get migrated somehow. This is how phones roam, by the way. They update their location via an HLR as they roam. the phones get a new IP address as they roam and break existing connections don't they? The software either gets a notification that the network has changed and connect again, or the connections end up timing out. Right?? David Lang On Sunday, January 25, 2015 10:45pm, Dave Taht dave.t...@gmail.com said: On Sun, Jan 25, 2015 at 7:17 PM, dpr...@reed.com wrote: Looking up an address in a routing table is o(1) if the routing table is a hash table. That's much more efficient than a TCAM. My simple example just requires a delete/insert at each node's route lookup table. Regrettably it is not O(1) once you take into account the cpu cache hierarchy, or the potential collisions you will have once you shrink the hash to something reasonable. Also I think you are ignoring the problem of covering routes. Say I have to get something to a.b.c.z/32. I do a lookup of that and find nothing. I then look to find a.b.c.z/31 and find nothing, then /30, then /29, /28, until I find a hit for the next hop. Now you can of course do a binary search for likely subprefixes, but in any case, the search is not O(1). In terms of cache efficient data structures, a straight hash is not the way to go, of late I have been trying to wrap my head around the hat-trie as possibly being useful in these circumstances. Now, if you think about limiting the domain of the problem to something greater than the typical mac table, but less than the whole internet, it starts looking more reasonable to have a 1x1 ratio of destination IPs to hash table entries for lookups, but updates have to probe/change large segments of the table in order to deal with covering prefixes. My point was about collections of WLAN's bridged together. Look at what happens (at the packet/radio layer) when a new node joins a bridged set of WLANs using STP. It is not exactly simple to rebuild the Ethernet layer's bridge routing tables in a complex network. And the limit of 4096 entries in many inexpensive switches is not a trivial limit. Agreed. But see http://en.wikipedia.org/wiki/Virtual_Extensible_LAN Routers used to be memory-starved (a small number of KB of RAM was the norm). Perhaps the thinking then (back before 2000) has not been revised, even though the hardware is a lot more capacious. The profit margins have not been revised. I would not mind, incidentally expanding the scope of the fqswitch project ot try to build something that would scale up at l3 farther than we've ever seen before, however funding for needed gear like: http://www.eetimes.com/document.asp?doc_id=1321334 and time, and fpga expertise, is lacking. I am currently distracted by evaluating a very cool new cpu architecture ( see http://www.millcomputing.com/wiki/Memory ) and even as nifty as that is I foresee a need for a lot of dedicated packet processing logic and memories to get into the 40GBit+ range. Remember, the Ethernet layer in WLANs is implemented by microcontrollers, typically not very capable ones, plus TCAMs which are pretty limited in their flexibility. I do tend to think that the next era of SDN enabled hardware will eventually lead to more innovation in both the control and data plane - however it seems we are still in a me-too phase of development of openvswitch (btw: there is a new software switch for linux called rocker we should look at, and make sure runs fq_codel), and a long way from flexibly programmable switch hardware in general. http://openvswitch.org/pipermail/dev/2014-September/045084.html While it is tempting to use the pre-packaged, proprietary Ethernet switch functionality, routing gets you out of the
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
This got mangled by my IP addr filter On Jan 24, 2015 11:56 PM, Dave Taht dave.t...@gmail.com wrote: I want to make clear that I support dlang's design in the abstract... and am just arguing because it is a slow day. On Sat, Jan 24, 2015 at 10:44 PM, David Lang da...@lang.hm wrote: On Sat, 24 Jan 2015, Dave Taht wrote: A side comment, meant to discourage continuing to bridge rather than route. There's no reason that the AP's cannot have different IP addresses, but a common ESSID. Roaming between them would be like roaming among mesh subnets. Assuming you are securing your APs' air interfaces using encryption over the air, you are already re-authenticating as you move from AP to AP. So using routing rather than bridging is a good idea for all the reasons that routing rather than bridging is better for mesh. The problem with doing this is that all existing TCP connections will break when you move from one AP to another and while some apps will quickly notice this and establish new connections, there are many apps that will not and this will cause noticable disruption to the user. I am under the impression that network-manager and linux, at least, tend to renegotiate IPv6 addresses on an down/up, and preserve ipv4. It can't preserve the ipv4 address if you end up on a different network address range (and trying to have lots of separate networks with the same IP addresses would mean that you have to do NAT at each network, and if you did that, then when you ended up on a different AP with the same IP address, the NAT tables would not have records of your connections and they would terminate the connections when you tried to send the next packets. Hmm? The first thing I ever do to a router is renumber it to a unique IP address range, and rename the subnet in dns to something unique. The 3 sed lines for this are on a cerowrt web page somewhere. Adding ipv6 statically is a pita, but doable with care and a uci script, and mildly more doable as hnetd matures. I run local dns services on each in the hope that at least some will be cached, and a local dhcp server to serve addresses out of that range. I turn off dhcp default route fetching on each routers external interface and use babel instead to find the right route(s) out of the system. On the NAT front, there is no nat on the internal routers, just a flat address space (a /14 in my case). I push all the nat to the main egress gateway(s), and in a case like yours would probably use multiple external IPs and dnat rather than masquarade the entire subnet on one to free up port space. You rapidly run out of ports in a natted evironment with that many users. I've had to turn down NAT timeouts for udp in particular to truly unreasonable levels otherwise (20 seconds in some cases) Doing this I can get a quick status on what is up with ip route, and by monitoring the activity on each ip range, see if traffic is actually being passed, a failure of a given gateway fails over to another, and so on. There's a couple snmp hacks to do things like monitor active leases, and smokeping/mrtg to access other stats. There's a couple beagles that are on wifi that I ping on some APs. The beagles have not been very reliable for me, so they switch on and off with digiloggers gear when they fail a local ping. In fact the main logging beagle failed entirely the other month, sigh. I use the ad-hoc links on cerowrt as backups (if they lose ethernet connectivity) and extenders (if there is no ethernet connectivity), and (as I have 5 different comcast exit nodes spread throughout the network), use babel-pinger on each to see if they are up, and insert default routes into the mix that are automatically the shortest distance between the node and exit gateway. If one gw goes down (usually) all the traffic ends up switching to the next nearest default gateway switching over in 16 seconds or so, breaking all the nat associations for the net they were on (sigh), as well as ipv6 native stuff, but it's happened so often without me noticing it that it's nice not to worry. (I have a mostly failed attempt in play for doing better with ipv6 and hnetd on a couple of exit nodes, but that isn't solid enough to deploy as yet, so it's only sort of working in the yurtlab. I really wish I could buy PI space for ipv6 somehow) (I have been fiddling with dns anycast to try to get more redundancy on the main dns gateways. That works pretty good) Now, your method is simpler! (although mine is mostly scripted) I imagine you bridge everything on a vlan, and use a central dhcp/dns server to serve up dhcp across (say) a 10/16 subnet. And by blocking local multicast/broadcast, in particular, this scales across the 3k user population. You've got a critical single point of failure in your gateway, but at least that's only one, and I imagine you have that duplicated. (In contrast my network is always broken somewhere, but unless
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
my first initial and only thought is over stauration on your network, i dont see anything of enterprise grade APs listed with 30+ users, how many connections and how many users? are they all trying to download/move data at the same time. On Fri, Jan 23, 2015 at 5:19 AM, Richard Smith smithb...@gmail.com wrote: On 01/22/2015 04:18 AM, David Lang wrote: Recently, we picked up the 11th floor as well and moved many people up there. I got a 3rd AP (another TP-Link AC1750) and set that one up on a free channel with a different ESSID. I like to put all the APs on the same ESSID so that people can roam between them. This requires that the APs act as bridges to a dedicated common network, not as routers. That's the ultimate plan but for convenience of being able to easily select what AP I'm talking to or to be able to tell folks to move from one to another I've got them on different ESSIDs. It also helps me keep track of what RF channel things are on. Then about a week before my original post I got notified that Internet was down. Both 10th floor APs had stopped working. The 11th floor (where I am) was still working. On the 10th floor, I could connect to the TP-link via its IP address on its wired interface but it did not seem to be passing wireless traffic. A reboot fixed it. There has been an ongoing bug with Apple devices on 5Ghz that causes the wifi chipset to lockup. We think we've fixed it in the current Cerowrt, but I don't know what kernel versions have this problem. This is likely to affect multiple vendors who use the same chipset (check the openwrt hardware list for details of the chipsets in each model) Oooohhh! That could be it. We have a _lot_ of Apple devices. Most of the company uses MacBook,or Air and a large number of people have iPhones and we use iPods for some of our testing. I'll go dig through the openWRT and get the details. The WNDR3700 was completely unresponsive both via WiFi and when I tried its IP connected directly to it's switch with a Cat-5. I also have a serial port mod on that wndr3700 so I connected up to that instead. hmm, it's not common to have it be unresponsive on the wired network. It's uncommon to me. :) This unit has travelled with me for years while I worked for OLPC and its see a lot of different wireless environments. Granted never one with this many apple clients. Usually 7-8 Linux/Windows machines and a pile of XOs. So this happened a lot at your SCALE setups? room. All the stations are in about a 40 foot radius and all but 1 or 2 have line of sight to the AP. The wndr3700 is in a closet on the side of the room with other equipment so it might be 80 feet away from the furthest station or so. this doesn't sound unreasonable unless your users are trying to use a LOT of bandwidth (although the fact that you refer to the 50Mb bottleneck indicates that you may be) The bottleneck was just a nice side effect. We don't use that much traffic. I only noticed the limit once I started running netperf-wrapper tests from a wired host. Occasional there will be some big download that eats up bandwidth, but when I watch the throughput during the day we peak up in to the 40Mbps but the average is 10Mbps (Download). Can I perhaps approximate signal strength by looking at the bitrate for packets that station sends? The theory being that higher quality RF links should use the higher bitrate encodings when sending. not reliably, too many other things factor in to that. Indeed. Horst tells me I basically have 2 rates happening on the tplink 6Mbs and 24Mbps with a few 12Mbps in there. If need be I can move the wndr to the same location as the tplink and then have stations connect to the wndr so I can watch the rx signal strength. Looks like that's what I'll have to do. There is a lot of room with consumer grade equipment from where you currently are. The Enterprise Grade systems do have a lot of infrastructure to coordinate the different APs. Thanks for the ray of hope. Yeah I don't need all the multi-AP coordination handoff stuff. -- Richard A. Smith ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Sun, Jan 25, 2015 at 01:39:32AM -0800, David Lang wrote: On Sun, 25 Jan 2015, Dave Taht wrote: I want to make clear that I support dlang's design in the abstract... and am just arguing because it is a slow day. I welcome challenges to the design, it's how I improve things :-) On Sat, Jan 24, 2015 at 10:44 PM, David Lang da...@lang.hm wrote: On Sat, 24 Jan 2015, Dave Taht wrote: to clarify, the chain of comments was 1. instead of bridging I should route 2. network manager would preserve the IPv4 address to prevent breaking established connections. I was explaining how that can't work. If you are moving between different networks, each routed independently, they either need to have different address ranges (in which case the old IP just won't work), or they would each need to NAT to get to the outside (in which case the IP may stay the same, but the connections will break since the new router wouldn't have the NAT entries for the existing connections) To keep your IP when roaming: 3. The old school way: use mobile IP or some other tunneling mechanism (or VPN) so you can keep your same IP. 4. Use a virtual subnet model similar to: https://tools.ietf.org/html/draft-ietf-l3vpn-virtual-subnet-03 The draft is focused on data centers and VM migration, but the problem is the same with client migration/mobility. I would argue that it is even easier to discover the location of a client with Wi-Fi because of the association/authentication handshake with the AP rather than relying on a Gratuitous ARP/ND or LLDP, VSI, etc. 5. Use LISP: http://en.wikipedia.org/wiki/Locator/Identifier_Separation_Protocol http://lispmob.org/ (supported on OpenWRT) Has anyone played with this? ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Sun, 25 Jan 2015, valdis.kletni...@vt.edu wrote: On Sun, 25 Jan 2015 18:09:59 -0800, David Lang said: The difference is that the switches and their protocols have been designed from the beginning for this scale of operation, IP routing protocols are designed for much fewer endpoints to track. Anybody who's carrying a full routing table was swallowing on the order of 528,833 routes (as of Friday's weekly routing table report posted to NANOG). Pretty much everybody and their pet llama accepts full tables thesedays. You know anybody who's doing that many entries in an L2 Ethernet broadcast domain? The full IP routing tables are something that you normally only have to deal with in a few devices at the perimeter of your network. What is being talked about here is routing each /32 IP address individually throughout your network so that any IP address can be connected anywhere and have it 'just work' as far as the client on that IP is concerned. David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
Looking up an address in a routing table is o(1) if the routing table is a hash table. That's much more efficient than a TCAM. My simple example just requires a delete/insert at each node's route lookup table. My point was about collections of WLAN's bridged together. Look at what happens (at the packet/radio layer) when a new node joins a bridged set of WLANs using STP. It is not exactly simple to rebuild the Ethernet layer's bridge routing tables in a complex network. And the limit of 4096 entries in many inexpensive switches is not a trivial limit. Routers used to be memory-starved (a small number of KB of RAM was the norm). Perhaps the thinking then (back before 2000) has not been revised, even though the hardware is a lot more capacious. Remember, the Ethernet layer in WLANs is implemented by microcontrollers, typically not very capable ones, plus TCAMs which are pretty limited in their flexibility. While it is tempting to use the pre-packaged, proprietary Ethernet switch functionality, routing gets you out of the binary blobs, and let's you be a lot smarter and more scalable. Given that it does NOT cost more to do routing at the IP layer, building complex Ethernet bridging is not obviously a win. BTW, TCAMs are used in IP layer switching, too, and also are used in packet filtering. Maybe not in cheap consumer switches, but lots of Gigabit switches implement IP layer switching and filtering. At HP, their switches routinely did all their IP layer switching entirely in TCAMs. On Sunday, January 25, 2015 9:58pm, Dave Taht dave.t...@gmail.com said: On Sun, Jan 25, 2015 at 6:43 PM, David Lang da...@lang.hm wrote: On Sun, 25 Jan 2015, Dave Taht wrote: To your roaming point, yes this is certainly one place where migrating bridged vms across machines breaks down, and yet more and more vm layers are doing it. I would certainly prefer routing in this case. What's the difference between roaming and moving a VM from one place in the network to another? I think most people think of roaming as moving fairly rapidly from one piece of edge connectivity to another, and moving a vm is a great deal more permanent operation. As far as layer 2 vs layer 3 goes. If you try to operate at layer 3, you are going to have quite a bit of smarts in the endpoint. Even if it's only connected vi a single link. If you think about it, even if your network routing tables list every machine in our environment individually, you still have a problem of what gateway the endpoint uses. It would have to change every time it moved. Since DHCP doesn't update frequently enough to be transparent, you would need to have each endpoint running a routing protocol. Hmm? I don't ever use a dhcp-supplied default gateway, I depend on the routing protocol to supply that. In terms of each vm running a routing protocol, well, no, I would rely on the underlying bare metal OS to be doing that, supplying the FIB tables to the overlying vms, if they need it, but otherwise the vms just see a default route and don't bother with it. They do need to inform the bare metal OS (better term for this please? hypervisor?) of what IPs they own. static default gateways are evil. and easily disabled. in linux you merely comment out the routers in /etc/dhcp/dhclient.conf, in openwrt, set defaultroute 0 for the interface fetching dhcp. When a box migrates, it tells the hypervisor it's addresses, and then that box propagates out the route change to elsewhere. This can work for individual hobbiests, but not when you need to support random devices (how would you configure an iPhone to support this?) Carefully. :) I do note that this stuff does (or at least did) work on some of the open source variants of android. I would rather like it if android added ipv6 tethering soon, and made it possible to mesh together multiple phones. Letting the layer 2 equipment deal with the traffic within the building and invoking layer 3 to go outside the building (or to a different security domain) makes a lot of sense. Even if that means that layer 2 within a building looks very similar to what layer 3 used to look like around a city. Be careful what you wish for. back to the topic of wifi, I'm not aware of any APs that participate in the switch protocols at this level. I also don't know of any reasonably priced switches that can do anything smarter than plain spanning tree when connected through multiple paths (I'd love to learn otherwise) David Lang -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
Disagree. See below. On Saturday, January 24, 2015 11:35pm, David Lang da...@lang.hm said: On Sat, 24 Jan 2015, dpr...@reed.com wrote: A side comment, meant to discourage continuing to bridge rather than route. There's no reason that the AP's cannot have different IP addresses, but a common ESSID. Roaming between them would be like roaming among mesh subnets. Assuming you are securing your APs' air interfaces using encryption over the air, you are already re-authenticating as you move from AP to AP. So using routing rather than bridging is a good idea for all the reasons that routing rather than bridging is better for mesh. The problem with doing this is that all existing TCP connections will break when you move from one AP to another and while some apps will quickly notice this and establish new connections, there are many apps that will not and this will cause noticable disruption to the user. Bridgeing allows the connections to remain intact. The wifi stack re-negotiates the encryption, but the encapsulated IP packets don't change. There is no reason why one cannot set up an enterprise network to support roaming, yet maintaining the property that IP addresses don't change while roaming from AP to AP. Here's a simple concept, that amounts to moving what would be in the Ethernet bridging tables up to the IP layer. All addresses in the enterprise are assigned from a common prefix (XXX/16 in IPv4, perhaps). Routing in each access point is used to decide whether to send the packet on its LAN, or to reflect it to another LAN. A node's preferred location would be updated by the endpoint itself, sending its current location to its current access point (via ARP or some other protocol). The access point that hears of a new node that it can reach tells all the other access points that the node is attached to it. Delivery of a packet to a node is done by the access point that receives the packet by looking up the destination IP address in its local table, and sending it to the access point that currently has the destination IP address. This is far better than bridging at the Ethernet level from a functionality point of view - it is using routing, not bridging. Bridging at the Ethernet level uses Ethernet's STP feature, which doesn't work very well in collections of wireless LAN's (it is slow to recalculate when something moves, because it was designed for unplug/plug of actual cables, and moving the host from one physical location to another). IMO, Ethernet sometimes aspires to solve problems that are already well-solved in the Internet protocols. (for example the 802.11s mess which tries to do a mesh entirely in the Ethernet layer, and fails pretty miserably). Of course that's only my opinion, but I think it applies to overuse of bridging at the Ethernet layer when there are better approaches at the next layer up.___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Sun, 25 Jan 2015, Dave Taht wrote: To your roaming point, yes this is certainly one place where migrating bridged vms across machines breaks down, and yet more and more vm layers are doing it. I would certainly prefer routing in this case. What's the difference between roaming and moving a VM from one place in the network to another? As far as layer 2 vs layer 3 goes. If you try to operate at layer 3, you are going to have quite a bit of smarts in the endpoint. Even if it's only connected vi a single link. If you think about it, even if your network routing tables list every machine in our environment individually, you still have a problem of what gateway the endpoint uses. It would have to change every time it moved. Since DHCP doesn't update frequently enough to be transparent, you would need to have each endpoint running a routing protocol. This can work for individual hobbiests, but not when you need to support random devices (how would you configure an iPhone to support this?) Letting the layer 2 equipment deal with the traffic within the building and invoking layer 3 to go outside the building (or to a different security domain) makes a lot of sense. Even if that means that layer 2 within a building looks very similar to what layer 3 used to look like around a city. back to the topic of wifi, I'm not aware of any APs that participate in the switch protocols at this level. I also don't know of any reasonably priced switches that can do anything smarter than plain spanning tree when connected through multiple paths (I'd love to learn otherwise) David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Sun, Jan 25, 2015 at 6:43 PM, David Lang da...@lang.hm wrote: On Sun, 25 Jan 2015, Dave Taht wrote: To your roaming point, yes this is certainly one place where migrating bridged vms across machines breaks down, and yet more and more vm layers are doing it. I would certainly prefer routing in this case. What's the difference between roaming and moving a VM from one place in the network to another? I think most people think of roaming as moving fairly rapidly from one piece of edge connectivity to another, and moving a vm is a great deal more permanent operation. As far as layer 2 vs layer 3 goes. If you try to operate at layer 3, you are going to have quite a bit of smarts in the endpoint. Even if it's only connected vi a single link. If you think about it, even if your network routing tables list every machine in our environment individually, you still have a problem of what gateway the endpoint uses. It would have to change every time it moved. Since DHCP doesn't update frequently enough to be transparent, you would need to have each endpoint running a routing protocol. Hmm? I don't ever use a dhcp-supplied default gateway, I depend on the routing protocol to supply that. In terms of each vm running a routing protocol, well, no, I would rely on the underlying bare metal OS to be doing that, supplying the FIB tables to the overlying vms, if they need it, but otherwise the vms just see a default route and don't bother with it. They do need to inform the bare metal OS (better term for this please? hypervisor?) of what IPs they own. static default gateways are evil. and easily disabled. in linux you merely comment out the routers in /etc/dhcp/dhclient.conf, in openwrt, set defaultroute 0 for the interface fetching dhcp. When a box migrates, it tells the hypervisor it's addresses, and then that box propagates out the route change to elsewhere. This can work for individual hobbiests, but not when you need to support random devices (how would you configure an iPhone to support this?) Carefully. :) I do note that this stuff does (or at least did) work on some of the open source variants of android. I would rather like it if android added ipv6 tethering soon, and made it possible to mesh together multiple phones. Letting the layer 2 equipment deal with the traffic within the building and invoking layer 3 to go outside the building (or to a different security domain) makes a lot of sense. Even if that means that layer 2 within a building looks very similar to what layer 3 used to look like around a city. Be careful what you wish for. back to the topic of wifi, I'm not aware of any APs that participate in the switch protocols at this level. I also don't know of any reasonably priced switches that can do anything smarter than plain spanning tree when connected through multiple paths (I'd love to learn otherwise) David Lang -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Sat, 24 Jan 2015, dpr...@reed.com wrote: On Thursday, January 22, 2015 1:19pm, Richard Smith smithb...@gmail.com said: On 01/22/2015 04:18 AM, David Lang wrote: Recently, we picked up the 11th floor as well and moved many people up there. I got a 3rd AP (another TP-Link AC1750) and set that one up on a free channel with a different ESSID. I like to put all the APs on the same ESSID so that people can roam between them. This requires that the APs act as bridges to a dedicated common network, not as routers. That's the ultimate plan but for convenience of being able to easily select what AP I'm talking to or to be able to tell folks to move from one to another I've got them on different ESSIDs. It also helps me keep track of what RF channel things are on. A side comment, meant to discourage continuing to bridge rather than route. There's no reason that the AP's cannot have different IP addresses, but a common ESSID. Roaming between them would be like roaming among mesh subnets. Assuming you are securing your APs' air interfaces using encryption over the air, you are already re-authenticating as you move from AP to AP. So using routing rather than bridging is a good idea for all the reasons that routing rather than bridging is better for mesh. The problem with doing this is that all existing TCP connections will break when you move from one AP to another and while some apps will quickly notice this and establish new connections, there are many apps that will not and this will cause noticable disruption to the user. Bridgeing allows the connections to remain intact. The wifi stack re-negotiates the encryption, but the encapsulated IP packets don't change. I do this with the wifi on it's own VLAN (actually separate VLANs for 2.4 and 5GHz) and have the APs configured not to relay broadcast traffic from one wireless user to another. This cuts down a LOT on the problems of broadcasts. In about a month I'm going to be running the wireless network for SCaLE again, and I would be happy to instrament the network to gather whatever info anyone is interested in. I will be using ~50 APs to handle the ~2800 or so devices that show up, with the footprint of each AP roughly covering a small meeting room (larger rooms have 2 APs in them, the largest room has 3, and I'm adding APs this year to cover the hallways better because the ones in the rooms aren't doing well enough at the low power settings I'm using) David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Sat, 24 Jan 2015, David Lang wrote: On Sat, 24 Jan 2015, Dave Taht wrote: I am of course interested in how fq_codel performs on your ISP link, and are you planning on running it for your wifi? I'm running OpenWRT on the APs but haven't done anything in particular to activate it. I'll check what we have on the firewall (a fairly up to day Debian build) What's the best way to monitor the queues? For that matter, if you have any other monitoring or stats that you would like me to gather? I'm using WNDR3800 and WNDR3700v2 APs Especially anything related to gathering stats related to fast wifi. David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Sat, 24 Jan 2015, Dave Taht wrote: A side comment, meant to discourage continuing to bridge rather than route. There's no reason that the AP's cannot have different IP addresses, but a common ESSID. Roaming between them would be like roaming among mesh subnets. Assuming you are securing your APs' air interfaces using encryption over the air, you are already re-authenticating as you move from AP to AP. So using routing rather than bridging is a good idea for all the reasons that routing rather than bridging is better for mesh. The problem with doing this is that all existing TCP connections will break when you move from one AP to another and while some apps will quickly notice this and establish new connections, there are many apps that will not and this will cause noticable disruption to the user. I am under the impression that network-manager and linux, at least, tend to renegotiate IPv6 addresses on an down/up, and preserve ipv4. It can't preserve the ipv4 address if you end up on a different network address range (and trying to have lots of separate networks with the same IP addresses would mean that you have to do NAT at each network, and if you did that, then when you ended up on a different AP with the same IP address, the NAT tables would not have records of your connections and they would terminate the connections when you tried to send the next packets. Bridgeing allows the connections to remain intact. The wifi stack re-negotiates the encryption, but the encapsulated IP packets don't change. While I actually agree with dlang on having all the same ssid and bridging, and not routing, on a conference, as well as with the idea of disabling broadcast (and I assume direct connectivity between two people seated side by side), it is a pita: More than once I've wanted to share a git tree with someone right next to me. I try to hand them my ip to grab the tree, and they can't even ping me, so I end uploading it somewhere, and he or she downloading it from there. Similarly, breaking interconnectivity precludes sane usage of in-conference True, it also blocks some abuse. People who really want direct connectivity can establish it as an ad-hoc network. For the normal user that we are trying to support at a conference, it's a win. I'll note that we also block streaming sites (which has the side effect of blocking some useful sites that share the same IPs, Amazon for example) to help make things better for everyone else, even at the cost of limiting what some people are able to do. Bandwidth is limited compared to the number of people we have, and we have to make choices. We do provide a local mirror of the debian based distros so that people can do the updates that they always tend to do at the conference (we would do the same for Fedora, but they make it too hard to do so) In my case, since choosing to live in a routed, rather than bridged world, I have modified the nailed up tools I use to be more connectionless. Instead of ssh (tcp), I use mosh-multipath (udp), which is far superior for interactive shells in lousy wifi environments. For vpns, I switched to tinc, which will attempt direct connections over udp, and tcp on both ipv4 and ipv6. For access to google, I adopted quic in my chrome browser. Since doing all these things I rarely notice losing a nailed up connection or migrating from AP to AP. Additionally I use babel (where I control the network) and ad-hoc wifi to transparently migrate from AP to AP, and (often) from AP to wired to AP to wired as I change locations, also with no loss in connectivity. I don't expect the scale userbase to have made these adjustments in behavior. :/ :-) I do this with the wifi on it's own VLAN (actually separate VLANs for 2.4 and 5GHz) and have the APs configured not to relay broadcast traffic from one wireless user to another. This cuts down a LOT on the problems of broadcasts. In about a month I'm going to be running the wireless network for SCaLE again, and I would be happy to instrament the network to gather whatever info anyone is interested in. I will be using ~50 APs to handle the ~2800 or I will look into some tools bismark and others have. Will you attempt to deploy ipv6? We have been offering IPv6 routable addresses for a few years. so devices that show up, with the footprint of each AP roughly covering a small meeting room (larger rooms have 2 APs in them, the largest room has 3, and I'm adding APs this year to cover the hallways better because the ones in the rooms aren't doing well enough at the low power settings I'm using) I am of course interested in how fq_codel performs on your ISP link, and are you planning on running it for your wifi? I'm running OpenWRT on the APs but haven't done anything in particular to activate it. I'll check what we have on the firewall (a fairly up to day Debian build) What's the best way to monitor the queues? David Lang
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Sat, Jan 24, 2015 at 8:35 PM, David Lang da...@lang.hm wrote: On Sat, 24 Jan 2015, dpr...@reed.com wrote: On Thursday, January 22, 2015 1:19pm, Richard Smith smithb...@gmail.com said: On 01/22/2015 04:18 AM, David Lang wrote: Recently, we picked up the 11th floor as well and moved many people up there. I got a 3rd AP (another TP-Link AC1750) and set that one up on a free channel with a different ESSID. I like to put all the APs on the same ESSID so that people can roam between them. This requires that the APs act as bridges to a dedicated common network, not as routers. That's the ultimate plan but for convenience of being able to easily select what AP I'm talking to or to be able to tell folks to move from one to another I've got them on different ESSIDs. It also helps me keep track of what RF channel things are on. My usual use case for using different APs is to find an error in the campus. When someone tells me that Lupin-lodge is down, I know exactly which machine to check. If everything was named Lupin, I'd have to check far more than one AP, and to ask approximately where on the campus they were. A side comment, meant to discourage continuing to bridge rather than route. There's no reason that the AP's cannot have different IP addresses, but a common ESSID. Roaming between them would be like roaming among mesh subnets. Assuming you are securing your APs' air interfaces using encryption over the air, you are already re-authenticating as you move from AP to AP. So using routing rather than bridging is a good idea for all the reasons that routing rather than bridging is better for mesh. The problem with doing this is that all existing TCP connections will break when you move from one AP to another and while some apps will quickly notice this and establish new connections, there are many apps that will not and this will cause noticable disruption to the user. I am under the impression that network-manager and linux, at least, tend to renegotiate IPv6 addresses on an down/up, and preserve ipv4. Bridgeing allows the connections to remain intact. The wifi stack re-negotiates the encryption, but the encapsulated IP packets don't change. While I actually agree with dlang on having all the same ssid and bridging, and not routing, on a conference, as well as with the idea of disabling broadcast (and I assume direct connectivity between two people seated side by side), it is a pita: More than once I've wanted to share a git tree with someone right next to me. I try to hand them my ip to grab the tree, and they can't even ping me, so I end uploading it somewhere, and he or she downloading it from there. Similarly, breaking interconnectivity precludes sane usage of in-conference In my case, since choosing to live in a routed, rather than bridged world, I have modified the nailed up tools I use to be more connectionless. Instead of ssh (tcp), I use mosh-multipath (udp), which is far superior for interactive shells in lousy wifi environments. For vpns, I switched to tinc, which will attempt direct connections over udp, and tcp on both ipv4 and ipv6. For access to google, I adopted quic in my chrome browser. Since doing all these things I rarely notice losing a nailed up connection or migrating from AP to AP. Additionally I use babel (where I control the network) and ad-hoc wifi to transparently migrate from AP to AP, and (often) from AP to wired to AP to wired as I change locations, also with no loss in connectivity. I don't expect the scale userbase to have made these adjustments in behavior. :/ I do this with the wifi on it's own VLAN (actually separate VLANs for 2.4 and 5GHz) and have the APs configured not to relay broadcast traffic from one wireless user to another. This cuts down a LOT on the problems of broadcasts. In about a month I'm going to be running the wireless network for SCaLE again, and I would be happy to instrament the network to gather whatever info anyone is interested in. I will be using ~50 APs to handle the ~2800 or I will look into some tools bismark and others have. Will you attempt to deploy ipv6? so devices that show up, with the footprint of each AP roughly covering a small meeting room (larger rooms have 2 APs in them, the largest room has 3, and I'm adding APs this year to cover the hallways better because the ones in the rooms aren't doing well enough at the low power settings I'm using) I am of course interested in how fq_codel performs on your ISP link, and are you planning on running it for your wifi? David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On 01/21/2015 06:58 PM, David Lang wrote: On Wed, 21 Jan 2015, Richard Smith wrote: Thanks for the response. First I want to say that I'm sensitive to the fact that this is the Cerowrt-devel list and not the small business WiFi help list. If things go too far off-topic or people get tired of the discussion let me know and I'll take it off the list. Ok, this would suggest that you are unlikely to have interference causing your problems. I don't have the earlier part of this thread still in my mailbox, what is the problem that you are trying to solve again? I didn't really describe the problem(s) in detail (see above note) but I'll provide a detailed description of my woes. We have a small network of about 30 people or so with ~60 devices connected. Most of which are wireless of some sort (both 2.4Ghz and 5hz). Here's my issues + my story. :) 1) Periodic reports of poor Internet. However, its not the Internet uplink. I setup a netperf-wrapper test that goes off every 10 minutes with a brief speed+latency test to a well connected host. Tracked across several weeks the uplink/downlink always exactly as expected. So I'm suspecting it's poor wireless rather than poor Internet. 2) Occasional total loss of WiFi. This a bit fuzzy since I have multiple hardware permutations and currently no consistent failure. The story: Originally we had an Engenius 2.4/5Ghz AP and a Netgear AP/router (WiFi turned off). I can't remember the original router model number. I didn't set any of the original hardware up. Several times a week the Engenius AP would stop passing traffic. A power cycle or reboot would fix it. The Engenius forums had lots of people reporting similar problems. We did firmware upgrades which seemed to help but not eliminate the issue. Sometime later we added VoIP phones. But bufferbloat in the cable modem caused large latencies under load and VoIP was unhappy. Enter the trusty WNDR3700v2 from my stash with OpenWRT (pre-barrier breaker build). I replaced both the original router and the Engenius AP with it. QoS solved VoIP issues and for the most part wireless was happy. Still occasionally though 5Ghz would stop working but much less frequent than the Engenius. Rebooting the box would fix it. I suspected the single box running all the AP + DHCP + DNS + routing may not have had the resources for our load or perhaps the pre-release of barrier breaker had issues. Replaced the routing/DHCP/DNS/QoS portion with a x86 box running OpenWRT x86 (using released barrier breaker, but locally built). Now the WNDR3700v2 was just an AP. This also allowed us actually get our rated cable modem speed. QoS on the wndr was capping out at ~60Mbps, a well known limit among members of this list. Around the same time I also added a 2nd AP on a different 5Ghz channel (TP-Link AC1750) to spread the connected clients across multiple channels. They have different ESSIDs. Things seem to be happy. I got the the TP-Link because its on target to be supported by OpenWRT and has 3 external antennas which I though might provided a path for different antenna testing. Recently, we picked up the 11th floor as well and moved many people up there. I got a 3rd AP (another TP-Link AC1750) and set that one up on a free channel with a different ESSID. Then about a week before my original post I got notified that Internet was down. Both 10th floor APs had stopped working. The 11th floor (where I am) was still working. On the 10th floor, I could connect to the TP-link via its IP address on its wired interface but it did not seem to be passing wireless traffic. A reboot fixed it. The WNDR3700 was completely unresponsive both via WiFi and when I tried its IP connected directly to it's switch with a Cat-5. I also have a serial port mod on that wndr3700 so I connected up to that instead. From the serial port everything appeared to be running fine only no would pass on the bridge. Dropping the interfaces with ifconfig and then bringing them back up had no effect and I didn't see anything unusual in the system logs. A power cycle fixed it. I've never seen my wndr3700 do something like that. So then I really began to wonder... that's 3 different hardware vendors with 3 very different firmware's all that had similar issues. 2 of them at exactly the same time. I considered the possibility of a power event but the 2 APs are on different circuits and in physically different locations. The power connection for the wndr3700 also has the x86 router, 2 switches, the cable modem, and a linux box plugged up and all of those devices were still working. That's when I figured I needed to start looking at what was going on in RF land. At that time I didn't have anything like horst to be able to verify that wireless really was broken and not some other mysterious network gremlin. So I started tooling up. When it happens again I can
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Thu, 22 Jan 2015, Richard Smith wrote: On 01/21/2015 06:58 PM, David Lang wrote: On Wed, 21 Jan 2015, Richard Smith wrote: Thanks for the response. First I want to say that I'm sensitive to the fact that this is the Cerowrt-devel list and not the small business WiFi help list. If things go too far off-topic or people get tired of the discussion let me know and I'll take it off the list. Ok, this would suggest that you are unlikely to have interference causing your problems. I don't have the earlier part of this thread still in my mailbox, what is the problem that you are trying to solve again? I didn't really describe the problem(s) in detail (see above note) but I'll provide a detailed description of my woes. We have a small network of about 30 people or so with ~60 devices connected. Most of which are wireless of some sort (both 2.4Ghz and 5hz). Here's my issues + my story. :) 1) Periodic reports of poor Internet. However, its not the Internet uplink. I setup a netperf-wrapper test that goes off every 10 minutes with a brief speed+latency test to a well connected host. Tracked across several weeks the uplink/downlink always exactly as expected. So I'm suspecting it's poor wireless rather than poor Internet. 2) Occasional total loss of WiFi. This a bit fuzzy since I have multiple hardware permutations and currently no consistent failure. The story: Originally we had an Engenius 2.4/5Ghz AP and a Netgear AP/router (WiFi turned off). I can't remember the original router model number. I didn't set any of the original hardware up. Several times a week the Engenius AP would stop passing traffic. A power cycle or reboot would fix it. The Engenius forums had lots of people reporting similar problems. We did firmware upgrades which seemed to help but not eliminate the issue. Sometime later we added VoIP phones. But bufferbloat in the cable modem caused large latencies under load and VoIP was unhappy. Enter the trusty WNDR3700v2 from my stash with OpenWRT (pre-barrier breaker build). I replaced both the original router and the Engenius AP with it. QoS solved VoIP issues and for the most part wireless was happy. Still occasionally though 5Ghz would stop working but much less frequent than the Engenius. Rebooting the box would fix it. I suspected the single box running all the AP + DHCP + DNS + routing may not have had the resources for our load or perhaps the pre-release of barrier breaker had issues. Replaced the routing/DHCP/DNS/QoS portion with a x86 box running OpenWRT x86 (using released barrier breaker, but locally built). Now the WNDR3700v2 was just an AP. This also allowed us actually get our rated cable modem speed. QoS on the wndr was capping out at ~60Mbps, a well known limit among members of this list. Around the same time I also added a 2nd AP on a different 5Ghz channel (TP-Link AC1750) to spread the connected clients across multiple channels. They have different ESSIDs. Things seem to be happy. I got the the TP-Link because its on target to be supported by OpenWRT and has 3 external antennas which I though might provided a path for different antenna testing. Recently, we picked up the 11th floor as well and moved many people up there. I got a 3rd AP (another TP-Link AC1750) and set that one up on a free channel with a different ESSID. I like to put all the APs on the same ESSID so that people can roam between them. This requires that the APs act as bridges to a dedicated common network, not as routers. Then about a week before my original post I got notified that Internet was down. Both 10th floor APs had stopped working. The 11th floor (where I am) was still working. On the 10th floor, I could connect to the TP-link via its IP address on its wired interface but it did not seem to be passing wireless traffic. A reboot fixed it. There has been an ongoing bug with Apple devices on 5Ghz that causes the wifi chipset to lockup. We think we've fixed it in the current Cerowrt, but I don't know what kernel versions have this problem. This is likely to affect multiple vendors who use the same chipset (check the openwrt hardware list for details of the chipsets in each model) The WNDR3700 was completely unresponsive both via WiFi and when I tried its IP connected directly to it's switch with a Cat-5. I also have a serial port mod on that wndr3700 so I connected up to that instead. hmm, it's not common to have it be unresponsive on the wired network. From the serial port everything appeared to be running fine only no would pass on the bridge. Dropping the interfaces with ifconfig and then bringing them back up had no effect and I didn't see anything unusual in the system logs. A power cycle fixed it. I've never seen my wndr3700 do something like that. So then I really began to wonder... that's 3 different hardware vendors with 3 very different firmware's all that had similar issues.
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
I guess Yahoo email is not liked as a source for my reply, can you kindly remove me from more notices as I'm overloaded with work to follow your project thank you and excuse me for steeping on this conversation, maybe this will get thru Sorry, we were unable to deliver your message to the following address. majord...@vger.kernel.org: Remote host said: 553 5.7.1 Hello [72.30.239.75], for your MAIL FROM address rtoledo2...@yahoo.com policy analysis reported: Your address is not liked source for email [MAIL_FROM] --- Below this line is a copy of the message. Received: from [66.196.81.174] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jan 2015 22:52:37 - Received: from [98.139.212.231] by tm20.bullet.mail.bf1.yahoo.com with NNFMP; 22 Jan 2015 22:52:37 - Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 22 Jan 2015 22:52:37 - X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 508745.6516...@omp1040.mail.bf1.yahoo.com Received: (qmail 58276 invoked by uid 60001); 22 Jan 2015 22:52:37 - DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1421967157; bh=+hoVZbV4ePHhwT48DL2jKdAiiEz3u4DphjF7TNJfus4=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=fHXb+lpfFysgslEQ9OIOvtOrJvhcXd46V4xXqBwTpXBRrhQZsFX7deDV37b+rSBPKn9KuxrSVl8TfPRDwWvJrYTX6yNUHX2sTAMQB/+fROQvUiYPijmDAo2FxbK4e7bUUMWHDuGViQWqm3LVMoPPgw5CKJpWayeIvTPLuQrKRZE= X-YMail-OSG: 9YkReVMVM1lcI3gjTh0TFiGFhn620jxFLrWLaxHpAfZTTwP 7BbbFh0sTYi9Zay6Pn8C1oBz1dQ1w6XvjCe3pzINldpd2EEAAWRx3iterebA zfNFrUkvlWSCnod3MZtfZM3ryuIwuvQHe1qocC4BTCxIognNjnVqrefw2IN2 3r3eXNBS6YD2eOXaxIHec0ZRs6x6XfsIFNvLB1_DhWHNhSf58zsWFR6R8cDL L9AU2YgIlO.142L_LjGOqTXDB39yn3FHUueVHgcsmoUmjhC88dfxDXBxRq_n uxBfYxD7rzL6n7Ss_lp2bqZgq4hJs6ezsxKFK9I7qMpJeMofr1rbBhMXPpm0 D9sVMaEcJFRfSEhJrqKFXfmJukEYfAlYMqRcGZpCs8rnQ2uw0LiEFsi1pLEs dcueN.Xs7CcvshWaQ4zaM8s.MYwyYpZrJaaqXtFweRfiryf7LqQk4w9p04FK Pkx1qEGjSdPth8R7QeT6uFwcrwOGyoJr1Brx28jcoPaAHE3SmVSbQpT_SXnX gTjWtJzW9Fz2Ttp_xbyJhbByN8R3uN6f3gtlAKxVDPGNFALUmyz2C9V8lxKk ghP2xkQuA4w-- Received: from [96.251.130.107] by web162203.mail.bf1.yahoo.com via HTTP; Thu, 22 Jan 2015 14:52:37 PST X-Rocket-MIMEInfo: 002.001,DQp1bnN1YnNjcmliZSBuZXRkZXYNCg0KIGluICB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZwEwAQEBAQ-- X-Mailer: YahooMailClassic/948 YahooMailWebService/0.8.203.740 Message-ID: 1421967157.50516.yahoomailba...@web162203.mail.bf1.yahoo.com Date: Thu, 22 Jan 2015 14:52:37 -0800 From: Roman Toledo Casabona rtoledo2...@yahoo.com Subject: unsubscribe netdev To: majord...@vger.kernel.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii unsubscribe netdev in the body of a message to majord...@vger.kernel.org On Thu, 1/22/15, David Lang da...@lang.hm wrote: Subject: Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic? To: Richard Smith smithb...@gmail.com Cc: cerowrt-devel@lists.bufferbloat.net cerowrt-devel@lists.bufferbloat.net Date: Thursday, January 22, 2015, 2:09 PM On Thu, 22 Jan 2015, Richard Smith wrote: The WNDR3700 was completely unresponsive both via WiFi and when I tried its IP connected directly to it's switch with a Cat-5. I also have a serial port mod on that wndr3700 so I connected up to that instead. hmm, it's not common to have it be unresponsive on the wired network. It's uncommon to me. :) This unit has travelled with me for years while I worked for OLPC and its see a lot of different wireless environments. Granted never one with this many apple clients. Usually 7-8 Linux/Windows machines and a pile of XOs. So this happened a lot at your SCALE setups? two years ago we had a problem with the APs dropping off, but last year everything worked wonderfully. David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On 01/22/2015 04:18 AM, David Lang wrote: Recently, we picked up the 11th floor as well and moved many people up there. I got a 3rd AP (another TP-Link AC1750) and set that one up on a free channel with a different ESSID. I like to put all the APs on the same ESSID so that people can roam between them. This requires that the APs act as bridges to a dedicated common network, not as routers. That's the ultimate plan but for convenience of being able to easily select what AP I'm talking to or to be able to tell folks to move from one to another I've got them on different ESSIDs. It also helps me keep track of what RF channel things are on. Then about a week before my original post I got notified that Internet was down. Both 10th floor APs had stopped working. The 11th floor (where I am) was still working. On the 10th floor, I could connect to the TP-link via its IP address on its wired interface but it did not seem to be passing wireless traffic. A reboot fixed it. There has been an ongoing bug with Apple devices on 5Ghz that causes the wifi chipset to lockup. We think we've fixed it in the current Cerowrt, but I don't know what kernel versions have this problem. This is likely to affect multiple vendors who use the same chipset (check the openwrt hardware list for details of the chipsets in each model) Oooohhh! That could be it. We have a _lot_ of Apple devices. Most of the company uses MacBook,or Air and a large number of people have iPhones and we use iPods for some of our testing. I'll go dig through the openWRT and get the details. The WNDR3700 was completely unresponsive both via WiFi and when I tried its IP connected directly to it's switch with a Cat-5. I also have a serial port mod on that wndr3700 so I connected up to that instead. hmm, it's not common to have it be unresponsive on the wired network. It's uncommon to me. :) This unit has travelled with me for years while I worked for OLPC and its see a lot of different wireless environments. Granted never one with this many apple clients. Usually 7-8 Linux/Windows machines and a pile of XOs. So this happened a lot at your SCALE setups? room. All the stations are in about a 40 foot radius and all but 1 or 2 have line of sight to the AP. The wndr3700 is in a closet on the side of the room with other equipment so it might be 80 feet away from the furthest station or so. this doesn't sound unreasonable unless your users are trying to use a LOT of bandwidth (although the fact that you refer to the 50Mb bottleneck indicates that you may be) The bottleneck was just a nice side effect. We don't use that much traffic. I only noticed the limit once I started running netperf-wrapper tests from a wired host. Occasional there will be some big download that eats up bandwidth, but when I watch the throughput during the day we peak up in to the 40Mbps but the average is 10Mbps (Download). Can I perhaps approximate signal strength by looking at the bitrate for packets that station sends? The theory being that higher quality RF links should use the higher bitrate encodings when sending. not reliably, too many other things factor in to that. Indeed. Horst tells me I basically have 2 rates happening on the tplink 6Mbs and 24Mbps with a few 12Mbps in there. If need be I can move the wndr to the same location as the tplink and then have stations connect to the wndr so I can watch the rx signal strength. Looks like that's what I'll have to do. There is a lot of room with consumer grade equipment from where you currently are. The Enterprise Grade systems do have a lot of infrastructure to coordinate the different APs. Thanks for the ray of hope. Yeah I don't need all the multi-AP coordination handoff stuff. -- Richard A. Smith ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On Wed, 21 Jan 2015, Richard Smith wrote: On 01/20/2015 11:59 AM, Rich Brown wrote: One of the first things I would do is a Wifi site survey, to look for conflicts between access points/channels, etc. Two recommendations for tools: MacOSX: WiFi Explorer from Adrian Granados - US$4.99 from the Mac App Store. http://www.adriangranados.com/apps/wifi-explorer Android: WiFi Analyzer from farproc - Donationware from the Android store. https://sites.google.com/site/farproc/wifi-analyzer Thanks for the suggestion. I've done that. I'll offer up a 3rd choice which I have been using. Horst. Runs on OpenWrt perfectly and free. I've not tried it on CeroWrt yet but I don't see why it would not work. http://br1.einfach.org/tech/horst/ With horst I've verified that the 3 AP's we are running are all on 5Ghz channels that don't have another AP on them. We are up on the 10th floor of a tower type building and 3 of our walls have large windows with clear views of surrounding buildings. We are higher than most of the stuff around us. Ok, this would suggest that you are unlikely to have interference causing your problems. I don't have the earlier part of this thread still in my mailbox, what is the problem that you are trying to solve again? When you do a wifi survey, you are not just looking at one spot, or near the APs for what you see. You should also be going to all the areas your users are going to be trying to access your network and see if you have a strong enough signal from at least one AP everywhere. Also note that if you have high-power APs, you may hear a signal from them, but they may not be able to hear the signal from the mobile device very well. Mobile devices tend to have lousy antennas, and try to operate a lower power levels to save battery power. So you may need to look at the stats on the AP showing the signal it sees from the client. Assuming that you have enough signal, the next question is how many people are going to be trying to use the network at one time. You may be better off with more APs operating at lower power levels so that you have fewer people talking to each one. David Lang So when I scan I do see a lot of intermittent probes or wifi traffic from other things but nothing cronic. I haven't been able to run a scan when it all goes to hell though. With horst it shows me the DATA or QDATA packet among the radiotap info and that the contents are encrypted but I've not figured out how to capture decrypted traffic at the same time as radiotap info. This would let me see exactly what sort of dynamic was happening from our network. As an aside if any of the gurus here are near the Boston, MA area and want to do small business Wi-Fi consulting let me know. We will gladly pay someone to fix our wireless. -- Richard A. Smith ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic?
On 01/20/2015 11:59 AM, Rich Brown wrote: One of the first things I would do is a Wifi site survey, to look for conflicts between access points/channels, etc. Two recommendations for tools: MacOSX: WiFi Explorer from Adrian Granados - US$4.99 from the Mac App Store. http://www.adriangranados.com/apps/wifi-explorer Android: WiFi Analyzer from farproc - Donationware from the Android store. https://sites.google.com/site/farproc/wifi-analyzer Thanks for the suggestion. I've done that. I'll offer up a 3rd choice which I have been using. Horst. Runs on OpenWrt perfectly and free. I've not tried it on CeroWrt yet but I don't see why it would not work. http://br1.einfach.org/tech/horst/ With horst I've verified that the 3 AP's we are running are all on 5Ghz channels that don't have another AP on them. We are up on the 10th floor of a tower type building and 3 of our walls have large windows with clear views of surrounding buildings. We are higher than most of the stuff around us. So when I scan I do see a lot of intermittent probes or wifi traffic from other things but nothing cronic. I haven't been able to run a scan when it all goes to hell though. With horst it shows me the DATA or QDATA packet among the radiotap info and that the contents are encrypted but I've not figured out how to capture decrypted traffic at the same time as radiotap info. This would let me see exactly what sort of dynamic was happening from our network. As an aside if any of the gurus here are near the Boston, MA area and want to do small business Wi-Fi consulting let me know. We will gladly pay someone to fix our wireless. -- Richard A. Smith ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
[Cerowrt-devel] Recording RF management info _and_ associated traffic?
I'm trying to track down some poor wireless issues we are having at work. At random times the 5Ghz WLANs we have just go to hell. I've been sniffing in monitor mode which has been quite enlightening there's certainly a lot more going on in the 5Ghz channels than I was expecting. Monitor mode shows me loads of stuff I didn't know was there but what it doesn't show me is how all that other traffic interacts with the traffic on my ESS. From what I've been reading it seems like you with most cards you can't grab the 802.11 management info and actual traffic on the network at the same time. Is this possible with a WNDR3[78]00 CeroWRT (or openWRT) setup? -- Richard A. Smith ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
