Re: [Debconf-team] PSU Network Requirements
>> - 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.
One thing to consider is their captive portal authentication can takes
several minutes in the best circumstances. Last time I used their
captive portal it took about ten minutes to receive the verification
code.
If the are concerned about exposing services by having a open AP's we
could secure them and also enable client isolation so access to their
WAN is not an issue. But then there is their concerns of wifi
interference... If were using AP's in the just the areas were actually
leasing and their not long range idk why this is an issue at all.
>
>> 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.
I have concerns about their AP's scaling too as it is they do some
heavy rate limiting behind the scenes.
Reply to: