Broadcast/Multicast & NTP - CAPWAP

[Patrick Dohman]

At this point it appears that openbsd security configurations may result in a los of UDP ICMP traffic to all hosts on a segment.
If possible please clarify if any of the following are required foe the proper operation of NTP/CAPWAP on a broadcast/multicast segment.

[***@bully ~]$sysctl | grep multi
net.inet.ip.multipath=0
net.inet6.ip6.multipath=0
net.inet6.ip6.multicast_mtudisc=0

[***@bully ~]$sysctl | grep 'net.inet' | grep '=0'
net.inet.ip.forwarding=0
net.inet.ip.sourceroute=0
net.inet.ip.directed-broadcast=0
net.inet.ip.encdebug=0
net.inet.ip.ipsec-soft-allocs=0
net.inet.ip.ipsec-allocs=0
net.inet.ip.ipsec-soft-bytes=0
net.inet.ip.ipsec-bytes=0
net.inet.ip.ifq.len=0
net.inet.ip.ifq.drops=0
net.inet.ip.mforwarding=0
net.inet.ip.multipath=0
net.inet.ip.arpqueued=0
net.inet.icmp.maskrepl=0
net.inet.icmp.bmcastecho=0
net.inet.icmp.rediraccept=0
net.inet.ipip.allow=0
net.inet.tcp.ackonpush=0
net.inet.tcp.ecn=0
net.inet.tcp.always_keepalive=0
net.inet.gre.allow=0
net.inet.gre.wccp=0
net.inet.mobileip.allow=0
net.inet.etherip.allow=0
net.inet.ipcomp.enable=0
net.inet.carp.preempt=0

Regards
Patrick

[Philip Guenther]

Post by Patrick Dohman
At this point it appears that openbsd security configurations may result
in a los of UDP ICMP traffic to all hosts on a segment. If possible
please clarify if any of the following are required foe the proper
operation of NTP/CAPWAP on a broadcast/multicast segment.

Do you just want to hope that someone on this list has already deployed
"CAPWAP" with OpenBSD and wait for them to answer, or are you interested
in trying to debug it?

If the latter, then you should take it down a level and describe what you
tried to do, what you expected to see "on the wire/in the air", and what
you _actually_ saw there?


(Reading at least one 120+ page standard written by Cisco just to
understand the background to someone else's problem is a high barrier to
assistance by others who are familiar with networking but not with CAPWAP
and/or LWAPP.)


Philip Guenther

[Patrick Dohman]

Thanks for the reply.
I’m looking to determine if the cause of intermittent subnet “collisions” that necessitate power cycle of numerous networks hosts is the result of OpenBSD security configurations
Please note the openbsd host is reachable via SSH however ICMP form the host and from other hosts on the subnet fail and DNS lookups on the Puffy machine fail following the network failure.
In addition wifi appears related as 802.11 is constantly active and may be requesting configuration change during channel/frequency update.
Essentially If security configurations that disable for example broadcast echo & address mask query can lead to unexpected results.
For example MTU size & TCP window scaling options requiring the results of a broadcast ICMP echo.
Or if unintended result of the stateless UDP traffic never reaching it’s destination due to security config can result in ICMP UDP MTU errors.
Regards
Patrick

Post by Philip Guenther

Post by Patrick Dohman
At this point it appears that openbsd security configurations may result
in a los of UDP ICMP traffic to all hosts on a segment. If possible
please clarify if any of the following are required foe the proper
operation of NTP/CAPWAP on a broadcast/multicast segment.

Do you just want to hope that someone on this list has already deployed
"CAPWAP" with OpenBSD and wait for them to answer, or are you interested
in trying to debug it?
If the latter, then you should take it down a level and describe what you
tried to do, what you expected to see "on the wire/in the air", and what
you _actually_ saw there?
(Reading at least one 120+ page standard written by Cisco just to
understand the background to someone else's problem is a high barrier to
assistance by others who are familiar with networking but not with CAPWAP
and/or LWAPP.)
Philip Guenther

[Philip Guenther]

Post by Patrick Dohman
I’m looking to determine if the cause of intermittent subnet
“collisions” that necessitate power cycle of numerous networks hosts is
the result of OpenBSD security configurations

You haven't described your setup or what you're actually running on your
OpenBSD box, so I don't know how OpenBSD is even *involved* in what you're
asking about.

...

Post by Patrick Dohman
Essentially If security configurations that disable for example
broadcast echo & address mask query can lead to unexpected results. For
example MTU size & TCP window scaling options requiring the results of a
broadcast ICMP echo.

Path MTU detection is dependent on ICMP "fragmentation required"
responses, but OpenBSD generates, processes, and passes those by default.
TCP window scaling is not dependent on any sort of ICMP.

Post by Patrick Dohman
Or if unintended result of the stateless UDP traffic never reaching it’s
destination due to security config can result in ICMP UDP MTU errors.

Uh, no.

Frankly, this sounds like grasping at straws; you need to pause and
actually write down *testable* details before trying to come up with

Post by Patrick Dohman

Post by Philip Guenther
If the latter, then you should take it down a level and describe what you
tried to do, what you expected to see "on the wire/in the air", and what
you _actually_ saw there?

Philip Guenther

[Patrick Dohman]

Post by Philip Guenther
Uh, no.
Frankly, this sounds like grasping at straws; you need to pause and
actually write down *testable* details before trying to come up with

Post by Philip Guenther
If the latter, then you should take it down a level and describe what you
tried to do, what you expected to see "on the wire/in the air", and what
you _actually_ saw there?

I’ll go ahead update the Wi-Fi password & see if that makes things worse.
Regards
Patrick

[Patrick Dohman]

Philip
I’ve recreated a wireless connectivity issue with the OpenBSD 6.2 machine powered off & RJ45 disconnected.
At this point I’m chalking things up to living in proximity to a airport.
In effort to resolve the issue I’ve implemented a spare hawking AP.
Regards
Patrick

Post by Philip Guenther

Post by Patrick Dohman
I’m looking to determine if the cause of intermittent subnet
“collisions” that necessitate power cycle of numerous networks hosts is
the result of OpenBSD security configurations

You haven't described your setup or what you're actually running on your
OpenBSD box, so I don't know how OpenBSD is even *involved* in what you're
asking about.
...

Post by Patrick Dohman
Essentially If security configurations that disable for example
broadcast echo & address mask query can lead to unexpected results. For
example MTU size & TCP window scaling options requiring the results of a
broadcast ICMP echo.

Path MTU detection is dependent on ICMP "fragmentation required"
responses, but OpenBSD generates, processes, and passes those by default.
TCP window scaling is not dependent on any sort of ICMP.

Post by Patrick Dohman
Or if unintended result of the stateless UDP traffic never reaching it’s
destination due to security config can result in ICMP UDP MTU errors.

Uh, no.
Frankly, this sounds like grasping at straws; you need to pause and
actually write down *testable* details before trying to come up with

Post by Patrick Dohman

Post by Philip Guenther
If the latter, then you should take it down a level and describe what you
tried to do, what you expected to see "on the wire/in the air", and what
you _actually_ saw there?

Philip Guenther