Kees, Thanks for following up on this. While the answers weren't the ones we were hoping for, I don't think the situation is all that bad... I see several ways we can still make this work. On Wed, Jun 04, 2014 at 06:33:55PM -0700, Kees Cook wrote: > I talked on the phone today with the head of the PSU network. I can't say > I have good news at all. > They don't want us setting up our own wifi network because it will > collide with theirs. The /16 they'd mentioned is for their entire campus, > not just for our conference. I don't think there's any requirement for the wifi to hand out public IPs. So scarcity of public IPs should not be an issue, as long as they understand that a /24 for the wifi DHCP pool is *not* going to be sufficient. > - light up 1 port per conf room with access to their wired network > - disable port security for our rooms so we can add our own switches > - add hardcoded MACs to the wifi guest ACL that avoids the captive portal > - support thousands of people on their wifi network That mostly sounds ok to me. > Non-negotiable items: > - they will not allow us to set up unauthenticated bridged wifi to their > wired network since this exposes campus services to the outside world. What does "unauthenticated" mean here? Are APs with a shared WPA passphrase sufficient? (This is what we've used in the past for DebConf.) If they're going to allow us to run our own switches, I don't see any significant difference between this, and WPA-PSK-secured wifi. OTOH, if we have to accept a captive portal on the wifi, I'm not sure that's a blocker (even if it doesn't make sense to me) as long as we have wired ports available. > Do we _need_ to not have a captive portal on the wifi? If so, why? TTBOMK no, but don't take my word as authoritative. > Do we _need_ to have arbitrary inbound access? If so, why? > Do we _need_ wired switches in all the rooms? If so, why? (I suspect I can > answer this one, but I want to hear other voices.) We do need wired switches in the hacklabs, and the video team will need wired ports for their transport in the talk rooms. For the hacklabs, the switches are used both to reduce wifi contention, and to allow people to hack on devices that may not have wifi. This includes hacking on embedded systems (e.g., we have a sponsor this year who wants to set up some demo machines which are not going to be wifi), and also hacking on the Debian installer, which has no support for captive portals. > Do we expect to host an archive mirror or other services somewhere on > the wired network? If so, why? We normally rely on having a full local Debian mirror in order to minimize upstream bandwidth consumption. I know that PSU already *has* a local Debian mirror, so this may not be an issue. If PSU can arrange transparent proxying to redirect to their mirror (which I believe is what we've traditionally done at DebConf), we can potentially save the university some bandwidth and improve QoS for the conference. If PSU doesn't care about the bandwidth use, then we can probably make do without a transparent proxy; but having one would still improve overall latency for the conference. (To be sure, I fully expected that this year we would want to redirect to mirrors.cat.pdx.edu rather than porting in a separate conference mirror.) Personally, my only real concern in all of this is that PSU may severely underestimate the device density, and their wifi infrastructure may not actually be up to the task. I expect the device-per-person ratio to be about 2:1 for DebConf. While SMSU has hosted conferences of Open Source folks before (e.g. Linux Plumbers), it's been several years now, and smartphones are much more ubiquitous - and I think the Debian audience is much less likely to fall back to wireless connectivity for their devices in the face of contention than a more US-centric attendee base might. So as has already been mentioned, we should figure out if their AP density is really up to the challenge of handling 500+ simultaneous wifi connections in this space. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature