[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debconf-team] PSU Network Requirements



Benjamin Kerensa <bkerensa@gmail.com> writes:

>>> - 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.

How does this captive portal work exactly? What kind of verification
code is needed. Of all the restrictions I think the captive portal is
the most problematic. But it depends on how exactly this portal works.
If it's setup in a way that all participants can use it without giving
away excessive private information and if it works reliably (ie does not
cut active connections after some time like many of these portals do),
then it might be acceptable.

If the verification code is sent by SMS I think this is not acceptable.
If not for privacy reasons for the simple reason that it might not work
with international phones. If it just needs email verification this
might be acceptable at least if it also works with throw away addresses.

The other points are less of a problem IMO at least if the network
provided is done well. In this case I agree with Gunnar that it's
actually an advantage that we don't have to care about it.

Gaudenz

>
> 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.
> _______________________________________________
> Debconf-team mailing list
> Debconf-team@lists.debconf.org
> http://lists.debconf.org/mailman/listinfo/debconf-team
>

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


Reply to: