Re: svn commit: r317383 - in head: . etc/mtree include lib/libc/net rescue/rescue sbin sbin/atm sbin/atm/atmconfig share/man/man4 sys/boot/forth sys/conf sys/dev/en sys/dev/fatm sys/dev/hatm sys/dev/p

[Bruce Simpson]

On 27/04/17 18:44, Bruce Simpson wrote:
> Hopefully, with packet mode DSL, none of this should be needed again.
> 

JFYI I'm referring to ye olde Packet Transfer Mode (PTM) DSL, TR-009...
which dispenses with the need for ATM framing on DSL circuits.

Some US ISPs have been observed doing this in the wild. DSL isn't going
away any time soon, though -- many of us still use it as a backup
circuit for other things (vs Metro Ethernet, G.FAST, DOCSIS etc.)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317383 - in head: . etc/mtree include lib/libc/net rescue/rescue sbin sbin/atm sbin/atm/atmconfig share/man/man4 sys/boot/forth sys/conf sys/dev/en sys/dev/fatm sys/dev/hatm sys/dev/p

[Bruce Simpson]

Hopefully, with packet mode DSL, none of this should be needed again.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r316676 - in head/sys/netinet: . tcp_stacks

[Bruce Simpson]

This is a really good thing to have in. Thanks, Steven and others, for
optimizing for this big case.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r316435 - in head: sbin/ipfw sys/conf sys/modules sys/modules/ipfw_pmod sys/netpfil/ipfw/pmod

[Bruce Simpson]

On 03/04/17 15:12, Julian Elischer wrote:
> On 3/4/17 11:07 am, Andrey V. Elsukov wrote:
>> Author: ae
>> Date: Mon Apr  3 03:07:48 2017
>> New Revision: 316435
>> URL: https://svnweb.freebsd.org/changeset/base/316435
> 
> it was always my intention to hook netgraph modules into ipfw in this way

In my humble opinion, in an ideal world, everything warrants a rethink -
in terms of "abstract forwarding elements". This is how a lot of the
newer integrated routing/switching hardware seems to behave; designs
like the FM6000, Juniper's Trio, and so on.

For now, we've got several bodies of firewall code available in the
FreeBSD base system. The MSS tweak is much appreciated; it makes DSL and
Cable access more usable for many.

But I appreciate the sentiment of taking what is - on the face of it - a
simple network protocol transformation at a FreeBSD hop, as something
which really, we'd ideally have a common way of expressing.

I struggle to keep track of all of this development, personally. It
would be great if we could take the best from all of them, incorporate
scalability for LRO and so on, and hybrid forwarding chips, or other
offload stack approach, in the same code base somehow.

It's worth a trip down to the 1.4Tbit/s Alien Superchannel to see what
I'm getting at. Multi-100GBE into 1U is a reality now.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Bruce Simpson]

On 17/10/16 21:23, Bruce Simpson wrote:

On 17/10/16 18:40, John Baldwin wrote:

I'm a bit hesitant to do all the type parsing in the kernel vs userland.
However, I think having smbios(4) export a /dev/smbios that you can
either
read() or mmap() to access the table would be very convenient and let you
keep the bits to parse the table in userland (and not require root if we
allow read-only access to mortals on /dev/foo).


This is probably a bit left-field, but I'm wondering if both methods
(expose-to-loader-kenv and user-space-accessible devfs node) can be
re-used for things like the Linux-oriented kernel environment page
exported by SYSLINUX/PXELINUX memdisk, which I've used with some success
to boot FreeBSD installers in heterogeneous private cloud/lab setups.


PS Hit send too soon -- the main reason a FreeBSD installer, or image 
wrapper for a FreeBSD installer tool (akin to the Debian style of 
network driven installer), would need access to the memdisk's ACPI-style 
table (containing boot & textual 'environment' page, filled out by the 
TFTP boot server, perhaps by scripted means) is...


...where it can't intuit all system configuration settings by reference 
to its primary MAC address alone, or where it needs network bootstrap 
information to proceed with other provisioning methods (straight to 
Puppet/Ansible, and/or fetching a list of pkgng pkgs to grab from some 
trusted package server).


The code required would just pretty much resemble what you guys are 
doing for EFI right now, but for BIOS-era systems (of which we've got a 
large installed base, and mass provisioning those would be great, for 
the sake of recycling.)

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Bruce Simpson]

On 17/10/16 18:40, John Baldwin wrote:

I'm a bit hesitant to do all the type parsing in the kernel vs userland.
However, I think having smbios(4) export a /dev/smbios that you can either
read() or mmap() to access the table would be very convenient and let you
keep the bits to parse the table in userland (and not require root if we
allow read-only access to mortals on /dev/foo).


This is probably a bit left-field, but I'm wondering if both methods 
(expose-to-loader-kenv and user-space-accessible devfs node) can be 
re-used for things like the Linux-oriented kernel environment page 
exported by SYSLINUX/PXELINUX memdisk, which I've used with some success 
to boot FreeBSD installers in heterogeneous private cloud/lab setups.


It exports this information using an ACPI-like table in that BIOS HBA 
type area in x86 address space, but the table is not DSDT linked (it's 
not produced by the BIOS).


Having a coherent means of dealing with it would be very useful, as such 
FreeBSD installers (which I've deployed as mfsBSD images) can then 
basically re-use what's been done for EFI variables for those legacy 
systems which don't support/can't use EFI network boot. As yet, I've not 
tried this with 64-bit EFI systems.


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306652 - head/usr.sbin/arp

[Bruce Simpson]

On 03/10/16 20:22, Eric van Gyzen wrote:

The collision is unfortunate, but I agree that the context should be enough.


Agreed -- other technical writers have also used this version of the 
GARP acronym in doco.



However, that GARP -- 802.1ak -- is due to be replaced with MRP.


The "Mental-map Rewriting Protocol"?  ;-)


Multiple Registration Protocol (MRP) is intended to fill most of the 
roles GARP/GVRP did, for dynamic VLAN, end-station MAC and L2 multicast 
registration. (Think Ethernet multicast without IP.)


Actually, being reminded of this gave me an idea -- adding a subset of 
what's needed to support MRP to if_bridge would probably also help for 
supporting Ethernet rings; those protocols need to call into VLAN 
registration and port blocking too.


It would make for some good junior kernel hacker tasks...
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306652 - head/usr.sbin/arp

[Bruce Simpson]

On 03/10/16 20:02, Eric van Gyzen wrote:

Author: vangyzen
Date: Mon Oct  3 19:02:22 2016
New Revision: 306652
URL: https://svnweb.freebsd.org/changeset/base/306652

Log:
  Update arp(4) to document the net.link.ether.inet.garp_rexmit_count sysctl.


Meh, acronym collision.

It's probably obvious in this context that GARP stands here for 
Gratuitous ARP, but my mental autocomplete reads it as Generic Attribute 
Registration Protocol (GARP).


However, that GARP -- 802.1ak -- is due to be replaced with MRP.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

Slawa,

I'm afraid this may be a bit of a non-sequitur. Sorry.. I seem to be 
missing something. As I understand it this thread is about Ryan's change 
to netinet for broadcast.


On 26/08/16 15:49, Slawa Olhovchenkov wrote:

On Sun, Aug 21, 2016 at 03:04:00AM +0300, Slawa Olhovchenkov wrote:

On Sun, Aug 21, 2016 at 12:25:46AM +0100, Bruce Simpson wrote:

Whilst I agree with your concerns about multipoint, I support the
motivation behind Ryan's original change: optimize the common case.


Oh, common case...
I am have pmc profiling for TCP output and see on this SVG picture and
don't find any simple way.
You want to watch too?


At time peak network traffic (more then 25K connections, about 20Gbit
total traffic) half of cores fully utilised by network stack.

This is flamegraph from one core: http://zxy.spb.ru/cpu10.svg
This is same, but stack cut of at ixgbe_rxeof for more unified
tcp/ip stack view http://zxy.spb.ru/cpu10u.svg

...

I appreciate that you've taken the time to post a flamegraph (a 
fashionable visualization) of relative performance in the FreeBSD 
networking stack.


Sadly, I am mostly out of my depth for looking at stack wide performance 
for the moment; for the things I look at involving FreeBSD at work just 
at the moment, I would not generally go down there except for specific 
performance issues (e.g. with IEEE 1588).


It sounds as though perhaps you should raise a wider discussion about 
your results on -net. I would caution you however that the Function 
Boundary Trace (FBT) provider for DTrace can introduce a fair amount of 
noise to the raw performance data because of the trap mechanism it uses. 
This ruled it out for one of my own studies requiring packet-level accuracy.


Whilst raw pmc(4) profiles may require more post-processing, they will 
provide less equivocal data (and a better fix) on the hot path, due also 
to being sampled effectively on a PMC interrupt (a gather stage- poll 
core+uncore MSRs), not purely a software timer interrupt.


thanks
Bruce

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 21/08/16 00:47, Adrian Chadd wrote:

[snip]

Just for everyone else on the list, would you mind distilling the
original versus now-from-ryan meaning of M_BCAST and M_MCAST ? And how
they're supposed to be used?


(With my best Liam Neeson 'Dad' voice from Fallout 3)

They stay as-is, but IP is allowed to slip the tag.

But it has to slip another tag in there, to say it slipped the tag.

The rest is M_PROTOFLAG style hand-off hygeine, along the mbuf pipeline.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 21/08/16 00:25, Bruce Simpson wrote:

On 20/08/16 23:05, Slawa Olhovchenkov wrote:

In router case receiving broadcast packet in any way need additional
check for dst IP address (host part is all zero or all one? what about
handling this broadcast type (RFC talk about conroling variation of
this)? what about sysctl control of receiving routed broadcast
packets? what about handling 255.255.255.255?)


I believe most of this is already special-cased in ip_fastfwd.c (which
gnn@ of course has merged, as it's full of sensible FIB-like operators
which most router forwarding planes adopt on *their* IP input paths up
to the forwarding decision), assuming the Ethernet input path colours
packets with the right flags.


Just for reference, many of these 'sensible FIB operators' in the former 
ip_fastfwd.c came from the experience of James Jun at Towardex Systems. 
I merged his patch on the job whilst staying in Berkeley, CA and working 
on XORP at ICSI.


I was only too happy to do that on their ticket, as it covered a lot of 
little performance cases which the pure rtalloc() fallthrough made us 
wince about.


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 21/08/16 00:25, Bruce Simpson wrote:

[Use a predicted branch in favour of Ethernet to optimize common case 
comments snipped]



...we ensure that M_BCAST is cleared at all times before possible
re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols
decide themselves if re-entered about M_BCAST based on DMAC.


Better still, rename it to M_IPBCAST, because that is exactly what that 
flag would be. Treat it like M_PROMISC, hands off, use THAT test instead 
of M_BCAST in the code (but predictive branch the original 
in_broadcast() call), make sure M_BCAST is cleared before possible 
Netgraph handoff, but leave M_IPBCAST set.


That way, anyone can tell IP set the M_BCAST bit - not Ethernet - just 
by XORing them together.


I'd code this, but I don't have a -CURRENT box. :-(
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 23:05, Slawa Olhovchenkov wrote:

I am think this substitution is very bad idea (by design).
Also, on transmit side this is must be irrelevant on received L2
header (and this in many cases this is will be L2 unicast packet). For
other cases packet will be created on host and don't have any received
information.



Whilst I agree with your concerns about multipoint, I support the 
motivation behind Ryan's original change: optimize the common case.


On the other hand, I'm suggesting a slight extension to it -- one which 
would probably require adoption across some L2-exposed subsystems, or 
anywhere which might reinterpret an M_BCAST from re-entrant 
encapsulation (i.e. I receive a UDP broadcast packet, but my VPN daemon 
then decides it needs to be NATted and forwarded somewhere else).


Whilst I believe the scope for problems like this are limited (and 
perhaps to Netgraph permutations), I do believe they exist, and should 
be defensively coded for.


And: If, the logic for this can be factored out into one additional bit, 
in a conditional branch (or small set of those) in terms of delta to the 
existing FreeBSD data plane path -- i.e. my suggestion;


Then: we should be able to preserve correctness for multipoint 
configurations, without sacrificing performance.


Or, a possible tie-breaker:

...we ensure that M_BCAST is cleared at all times before possible 
re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols 
decide themselves if re-entered about M_BCAST based on DMAC.



On received side for host relaing on L2 information for accepting
packet as host targeting sound like security hole.

In router case receiving broadcast packet in any way need additional
check for dst IP address (host part is all zero or all one? what about
handling this broadcast type (RFC talk about conroling variation of
this)? what about sysctl control of receiving routed broadcast
packets? what about handling 255.255.255.255?)


I believe most of this is already special-cased in ip_fastfwd.c (which 
gnn@ of course has merged, as it's full of sensible FIB-like operators 
which most router forwarding planes adopt on *their* IP input paths up 
to the forwarding decision), assuming the Ethernet input path colours 
packets with the right flags.


Although, no direct distinction between IPv4 directed or undirected 
broadcast is made, until that code (or a full rtalloc()) is hit.


In the past, I have tried to "hack around" the issue on the output 
(send) side, by introducing IP_ONESBCAST from BSD/OS.


The fundamental problem there is that the IPv4 socket APIs were never 
designed to deal with 'with link' as well as 'with destination' 
particularly well -- i.e. to direct traffic to a particular host, with 
correct L2 resolution, but over a specific choice of link (or even, 
class of link).


So, for correct behaviour when handling packets like this, the XORP FEA 
and libfeaclient frameworks would attempt to fully-bind control sockets 
requiring broadcast input where possible (OLSR being one candidate, but 
there are also other protocols requiring them).



In any way, this is irrelevant to L2 broadcast MAC and present L2
broadcast flags.


On the contrary, I believe in teasing as much explanation about the 
Layer 2 Soup 'out there' and how in FreeBSD it is treated, as this lends 
much background to the original problem posed by Ryan's change, to those 
who may not be from a primarily networking-oriented background.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 22:17, Bruce Simpson wrote:

However, we still have to keep the FreeBSD-on-Ethernet ship sailing
smoothly. The intent of the original input path change is clearly for
performance, but perhaps slipping the M_BCAST tag in the stack is the
right way forward.

I would also suggest: we add ability to qualify where in the stack
M_BCAST was raised (in case of any possible re-entry), by allocating one
more MBUF flag to Layer 2.

Then, the same M_PROMISC flag trick can be applied... and Ryan's
broadcast performance boost could perhaps even carry across L2 bridging
tiers, e.g. stacked if_bridge or netgraph, providing we know what
direction in the stack it's traveling in (and its absolute ifnet origin)


The main motivation for this: retain the original meaning of M_BCAST.

(in addition to Ryan's intended new meaning that IP indicate to itself 
"This is IPv4 broadcast" and to others - it could be used to expedite 
delivery with some form of map).


But, say, let's add a second flag which allows for controlled stacking 
of L2 in situations like this.


Let's call it M_BCPROXY. It can be tracked for the original meaning, 
i.e. without the new meaning Ryan proposes for M_BCAST.


When M_BCAST is set and M_BCPROXY is clear, we know the packet is 
broadcast, but we don't know for sure that this isn't because IP 
inspected it, and set the M_BCAST flag due to the destination IPv4 
address being identified as such (and valid for its link, if you are 
enforcing the Strong IP End-Station model, RFC 1122 style, as is the BSD 
default).


However, if we set M_BCPROXY at the same time, then, in situations where 
we might potentially re-enter the stack holding the same broadcast 
packet, we know that IP marked the packet as broadcast, and - on entry - 
can change our routing/switching/allocation/replication strategies 
accordingly.


(This is not information which, on its own, holding the origin ifnet 
pointer provides; the flag is needed to sense direction in the stack.)


So, as the mbuf chain is handed-off between other L2 entities (this can 
easily happen with stacked VLAN tags, in Q-in-Q and provider 
environments, which pfSense can service very well) - and, if the node 
itself determines that it is also a recipient of the broadcast, for 
correct hand-off if the broadcast does need to be forwarded by some 
other FreeBSD subsystem.


It could also be checked by firewalls: e.g. for a corroborated check, 
from the mask of these two flags, where in the stack (or link forest) a 
purported broadcast packet actually originated from.


(Pretty much essential for maintaining audit trail if a Smurf-like 
amplification attack is caught in the act, or if an NTP relay (or other 
association) terminates in an NTP broadcast association. And, of course, 
to trace dodgy broadcast Sun-style XDR RPC back to its source.)


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 21:41, Slawa Olhovchenkov wrote:

On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote:

So, Ryan -- your original reading of how in_broadcast() behaves is
correct, modulo the all-ones bypassing it.

What purpose to analyse L2 header?


I was just checking for possible edge cases for a substitution of the 
in_broadcast() check with some other way of logically summarising the 
real broadcast disposition of the interface in bits, given your mGRE 
example below.


Like M_BCAST, but 'This packet is flagged as broadcast, but only by a 
proxy method, not L2'.



Yes, curently FreeBSD don't support multiaccess media other then
ethernet (i.e. ATM, FrameRelay), but in case of mGRE L2 header will be
absent.


Exactly! People forget that certain legitimate multipoint protocols 
already exist as overlays already. It is easy when all we grow up with 
is Ethernet. :-) Until we peek under the hood, we may not know.


Slawa, you have hit the nail on the head.

The situation can naturally arise anywhere we bridge L2/L3 in certain 
directions, be that in VPN aggregation or PPPoE aggregation.


In many ways I regret never being able to have executed work on a design 
for ng_pppoa in 2005/6. But, given the pain people in the UK are having 
with BT and VDSL modem provision right now... it comes as no surprise 
that the next generation of DSL access, for us, can be as bad.


For some, multipoint is less important now we have SR-IOV VFs and other 
means of allocating discrete unicast Ethernet MACs and using them as 
links, but...


Roundabout the time I merged M_PROMISC from NetBSD to FreeBSD in 2006/7, 
I considered that we should add an abstraction to ifnet to permit 
multiple unicast (or special) MACs to be bound to existing ifnets, and 
-- where the card permits it, expedite that MAC in some way.


That capability was present on the (legacy) Adaptec Starfire quad 100TX 
from that era. Today, it exists in e.g. Chelsio T4/5 TCAM filter, or 
multiple perfect hashes on the previous generations of cards. (Currently 
the FreeBSD stack does nothing about such.)


I suspect it is less important now we have RSS for raw TCP throughput, 
but, for those of us -- e.g. in internet service provider (ISP) type 
environments, we have to keep a careful eye on how well FreeBSD plays 
nice with other Ethernet equipment, with a view to these types of 
potential optimizations in future.


However, we still have to keep the FreeBSD-on-Ethernet ship sailing 
smoothly. The intent of the original input path change is clearly for 
performance, but perhaps slipping the M_BCAST tag in the stack is the 
right way forward.


I would also suggest: we add ability to qualify where in the stack 
M_BCAST was raised (in case of any possible re-entry), by allocating one 
more MBUF flag to Layer 2.


Then, the same M_PROMISC flag trick can be applied... and Ryan's 
broadcast performance boost could perhaps even carry across L2 bridging 
tiers, e.g. stacked if_bridge or netgraph, providing we know what 
direction in the stack it's traveling in (and its absolute ifnet origin).


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 21:05, Bruce Simpson wrote:

Unless I am missing something crucial here? As far as I can tell,
arpresolve() unconditionally resolves L2 next-hop to the value of
ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by
default for Ethernet ifnets: FF:FF:FF:FF:FF:FF.

Would that not get past the M_BCAST check which replaced the call to
in_broadcast()?


Based on my reading of the UDP-and-plumbing layer, it looks like we will 
only see FF:FF:FF:FF:FF:FF being used by the undirected IPv4 broadcast 
address, 255.255.255.255.


But, in fact, this is probably a far more valid address to use for 
discovery services than the x.x.x.255-style IPv4 directed broadcast 
address, as, for Ethernet at least, it is guaranteed not to propagate 
beyond 1 union-of (on-link broadcast domain (layer 2, hop 1) & other 
ways that IPv4 subnet is bridged).


So, Ryan -- your original reading of how in_broadcast() behaves is 
correct, modulo the all-ones bypassing it.


(I believe dhclient and isc-dhcpd bypass it at BPF injection, though.)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 19:57, Ryan Stone wrote:



On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov > wrote:

You also can recive this on ethernet too, IMHO, in case of /32.
Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be
relaxed on this.


There is no broadcast address on a /32 network.  Independent of my
change, we would not treat a packet received on a /32 network as a
broadcast here because in_broadcast() will return 0 for it.


Hmm. That is not entirely true for /32.

Even though the link layer might be Ethernet in that case, in the 
traditional BSD ifnet sense, while the broadcast address slot may have 
the same value (and actual location) as the peer end of a P2P (as in 
generically IFF_PPP, not just pppd(8)) interface), because it's on an 
Ethernet (IFF_BROADCAST) interface, the host part of the /32's value in 
in the broadcast address is still valid, and will probably get mapped 
that way if M_BCAST is set on outgoing traffic. (You are, after all, 
going to go through ARP on Ethernet, even for a /32, so that mapping 
will be triggered.)


Unless I am missing something crucial here? As far as I can tell, 
arpresolve() unconditionally resolves L2 next-hop to the value of 
ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by 
default for Ethernet ifnets: FF:FF:FF:FF:FF:FF.


Would that not get past the M_BCAST check which replaced the call to 
in_broadcast()?

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 19:09, Adrian Chadd wrote:

On 20 August 2016 at 11:02, Ryan Stone  wrote:

On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov  wrote:

For host enought have [hidden] alias with broadcsts bits.
Anyway, don't should relay on the L2 information, you can recive L3
unicast addressed packets (with alien dst IP address) in L2 broadcas
packet.


This is still handled correctly.  The new code only checks for L3 broadcast
addresses on L2 broadcast packets, but we still check the L3 address before
treating it as a broadcast. The problem is that I assumed that all paths
into the IP stack would set M_BCAST, but as Bruce has pointed out there are
cases like PPP which do not.


So why not fix those paths?


Because it would involve doing something similar to what if_ethersubr.c 
does right now: a direct comparison with FF:FF:FF:FF:FF:FF. Doing so 
outside of Ethernet would be invasive and one of those 'bad' layer 
crossings.


This is tricky to get right. NetBSD introduced the M_PROMISC flag to 
cover situations which can occur when Ethernet can be re-entered by 
layers 'above' its original invocation. (I merged it here.)


Ryan proposes slipping the definition of M_BCAST to include the network 
layer, inside ip_input() itself. That would not strictly violate 
layering, but bends the original meaning of the flag somewhat.


That may work, provided it doesn't tread on the toes of anything above 
it. However the situation is somewhat similar to that of M_PROMISC.


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 18:30, Slawa Olhovchenkov wrote:

Anyway, don't should relay on the L2 information, you can recive L3
unicast addressed packets (with alien dst IP address) in L2 broadcas
packet.


That is exactly what the egress routers in chapter 6 of my PhD do, but 
in a very controlled way -- by setting and clearing M_MCAST !


http://hdl.handle.net/10023/8681

In Ch6, ILNPv6 packets are effective being routed, using a multicast 
next-hop address (as distinct from the destination I-LV, which in turn 
is distinct from an IPv6 destination -- it just uses the same format.)


It's counter-intuitive (and should not happen outside of that 
constrained scenario), but it has real world applications.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 17:49, Bruce Simpson wrote:

- Providing a mechanism for ip_input() to signal to udp_input() that the
packet was addressed to an L3 broadcast address would require
rototilling the pr_input interface, and I'd have to carefully ensure
that if anything might interpose itself between the two layers (IPSec?)
that the flag would have to be passed through correctly.

(We had to do something similar for ILNPv6, because of how IPv6 input
works, so it allocates an unused bit from the IPv6 flow label.)


In case anyone's interested, IPSEC is one big reason we had to do this.

Performance was another; without marking ILNPv6 traffic, demultiplexing 
an ILNPv6 packet -- even 'just enough' to forward it -- would have 
required processing all IPv6 extension headers, and additional state 
lookups.


Using a bit from the flow label means ILNPv6 routers don't need to do 
any of that, and it got translated into an M_ILNP mbuf flag internally.


I shudder to think what gymnastics the FreeBSD stack may have to endure 
to accommodate modern Ethernet switching capabilities, though.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 17:36, Ryan Stone wrote:

+ adrian@, who prompted me to look at UDP in the first place

I'm really not sure what my next step should be.  I'm willing to revert
r304436, but I really don't want to revert r304437 because we've seen
crashes in the real world due to the missing locking.  Unfortunately,
reverting r304436 would mean that every UDP packet would incur the
overhead of an additional rlock/runlock call, which is what I've been
trying to avoid.  I don't see a particularly good path forward.


Your changes have the same motivations as my historical change to move 
group-level IP multicast lookups (and locking) out of the output path.


Source-specific multicast (SSM) requires support for reception filters 
on individual sockets, so I moved those multicast-specific input checks 
into the socket layer.



- The if_addr_lock would appear to be an excellent candidate to be
converted into an rmlock, but unfortunately we made the mistake of
exposing the lock through the ifnet KPI.  Fixing that would require
rototilling every single Ethernet/WiFi/etc driver in the tree.


Oops...


- Providing a mechanism for ip_input() to signal to udp_input() that the
packet was addressed to an L3 broadcast address would require
rototilling the pr_input interface, and I'd have to carefully ensure
that if anything might interpose itself between the two layers (IPSec?)
that the flag would have to be passed through correctly.

- mbuf flags are far too precious to allocate a new one for such a
narrow use-case


Agree.

Then it may be that slipping the definition of M_BCAST to mean 'And IP 
identified that this is network-layer broadcast' is the most expedient 
solution.


A quick look around suggests you may be able to get away with it. You'd 
essentially be widening the definition of the existing M_BCAST flag.


Given the ultimate consumer of the mbuf in the case you are addressing 
in the code (bad pun) is udp_input(), that may be fine.


(We had to do something similar for ILNPv6, because of how IPv6 input 
works, so it allocates an unused bit from the IPv6 flow label.)


But it has to be qualified very carefully. If L2 is re-entered from IP 
(e.g. a netgraph IP-level hook), it may have unexpected side-effects. I 
have not given this the KScope treatment, just a quick fxr.watson.org.


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 17:27, Bruce Simpson wrote:

Alternatively, the L2 destination MAC may be rewritten for that specific
address, to avoid the destination being interpreted by routers in the
Metro Ethernet core.


s/routers/switches/ -- in some views of the world, they are the same :)

PBB is also known as 'MAC-in-MAC' for this reason. There's also L2TP 
pseudowires, but we're not really there yet.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 16:42, Bruce Simpson wrote:

On 20/08/16 16:27, Ryan Stone wrote:

Can you send a broadcast packet through an L3 tunnel?  I thought that a
L2 tunnel was required.


Yes. This is perfectly legal and necessary for forwarding of IPv4
broadcasts to work. (it is Internet Protocol after all, not
Infernal-ethernet-extension Protocol. ;-))


For completeness: This does not hold true for L2 in L2, the most obvious 
example being Metro Ethernet VMAN style service. There, Ethernet is the 
transport (link layer), as well as the payload. That's a concrete 
example of the kind of L2 'tunnel' you may be referring to.


Sometimes, specific Ethernet [broad|multi]cast destinations -- notably 
L2 control protocols, e.g. RSTP within the customer VLAN, may need to be 
tunnelled (Provider-Backbone-Bridges (PBB) style).


Alternatively, the L2 destination MAC may be rewritten for that specific 
address, to avoid the destination being interpreted by routers in the 
Metro Ethernet core. It can be considered a crude form of Ethernet NAT, 
but it's common practice.


But, for IP, forwarding IPv4 directed broadcast packets over a 
non-broadcast link is completely legal (and required for normal operation).

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 16:27, Ryan Stone wrote:

Can you send a broadcast packet through an L3 tunnel?  I thought that a
L2 tunnel was required.


Yes. This is perfectly legal and necessary for forwarding of IPv4 
broadcasts to work. (it is Internet Protocol after all, not 
Infernal-ethernet-extension Protocol. ;-))


The change is in UDP input so it will not affect routers. But if a 
FreeBSD system were at the end of a link layer, and was the final 
recipient of the IPv4 broadcast packet, then if that link layer is not 
Ethernet, all bets are off.


That situation could occur very easily where FreeBSD is hanging off the 
end of a PPPoE link: e.g. consumer DSL, microwave, etc.


The underlying link layer for the tunnel might be Ethernet, but it will 
be demuxed as a PPP tunnel. PPP is treated as a bit pipe and does not 
normally distinguish between unicast, broadcast, multicast.


Broadcast destined for the host on its PPP address would be transported 
inside the tunnel, encapsulated as a normal unicast Ethernet packet.



But this mbuf flag is not guaranteed to be set in all situations;
e.g. where the link layer does not have the concept of broadcast
being distinct from other kinds of network traffic. PPP and ATM are
the most obvious examples.


We don't support ATM, but PPP is a good example.  I hadn't thought of
that.  Hm, ip_input() already has to check for a broadcast IP.  What it
set M_BCAST on the mbuf at that time?


ATM is one of those things everyone kind of has to support by default in 
some way because of the ITU ADSL specs. It is literally written into 
G.992.x.


Linux can do it, FreeBSD can't. PPP over ATM is something BT inflicted 
on the UK all by themselves, though, and we wish it would just go away.


Whilst your suggestion may work, it may be dangerous, as you are then 
stepping on the meaning of the flags. Some of them are intended to be 
used for one layer to signal another.


M_BCAST is pretty rigidly defined in mbuf.h as "The link layer received 
this as a broadcast / I intended for link layer to send this as a 
broadcast". M_PROTOFLAGS is normally used to clear flags with different 
meaning in different protocol layers.


M_MCAST also has similar status. On my PhD, I wrote code which uses a 
private Ethernet link between FreeBSD routers for load distribution; it 
distributes unicast traffic using IPv6 multicast.


It uses multicast both as convenience, and as a way to 'channelise' 
traffic if the Ethernet link supports it, using multicast groups. 
(Modern shared memory switches can slice L2 multicast traffic like this 
quite efficiently. So one slice of unicast traffic could be switched 
across locations purely at L2. However, the distribution of actual IPv6 
multicast was out of scope.)


The routers have to very carefully clear M_MCAST on egress, to ensure 
normal L2 next-hop resolution for IPv6 destinations.


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 15:52, Ryan Stone wrote:

It is perfectly legal for broadcast packets to be addressed to the
end of a P2P or non-Ethernet link, which may not set M_BCAST or
M_MCAST. The classic example is ATM (Non-Broadcast, Multiple Access
(NBMA)) but the situation may be readily observed with loopback or
tunnels.

Can you give an example of a tunneling protocol support by FreeBSD that
may be affected?  I looked and didn't see any.  OpenVPN, as best that I
can tell, injects frames into a tap interface, which appears as a
Ethernet interface, for example.


Potentially any and all PPP, tun(4); any link layer with plain IP on top 
of it other than Ethernet, which may not set M_BCAST for an IPv4 
broadcast packet (or does not distinguish between broadcast and 
unicast/multicast packets).


if_ethersubr.c does set M_BCAST correctly for Ethernet broadcast packets 
in the receive path. That is guaranteed, and the majority of Ethernet 
network drivers will pass packets up the stack through it more or less 
directly.


tap(4) is an exception because, as you rightly point out, it is pretty 
faithfully Ethernet, although I may have had to add code around Ethernet 
address conditions like this to it in the very distant past.


tun(4) on the other hand is a plain, PPP-like, IP tunnel.

But this mbuf flag is not guaranteed to be set in all situations; e.g. 
where the link layer does not have the concept of broadcast being 
distinct from other kinds of network traffic. PPP and ATM are the most 
obvious examples.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

On 20/08/16 12:33, Bruce Simpson wrote:

This potentially breaks reception of IPv4 broadcasts where FreeBSD is
the endpoint at the end of a P2P interface, or other forms of links,
where there is no guarantee that the link layer will set M_BCAST (or
indeed M_MCAST).


I appreciate it probably looks like a quick win, but if it's only been 
tested with Ethernet (it looks like it has only been written with 
Ethernet in mind), it does strongly look as if it breaks broadcast for 
UDP/IPv4 in other situations.


So, maybe it should be backed out ASAP. (I haven't tested this code.)

It is perfectly legal for broadcast packets to be addressed to the end 
of a P2P or non-Ethernet link, which may not set M_BCAST or M_MCAST. The 
classic example is ATM (Non-Broadcast, Multiple Access (NBMA)) but the 
situation may be readily observed with loopback or tunnels.


The same issue doesn't exist in your output path change, which looks 
sane. The same issue doesn't exist with IPv6 where broadcast is dead.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304436 - in head: . sys/netinet

[Bruce Simpson]

This potentially breaks reception of IPv4 broadcasts where FreeBSD is 
the endpoint at the end of a P2P interface, or other forms of links, 
where there is no guarantee that the link layer will set M_BCAST (or 
indeed M_MCAST).


On 18/08/16 23:59, Ryan Stone wrote:

Author: rstone
Date: Thu Aug 18 22:59:05 2016
New Revision: 304436
URL: https://svnweb.freebsd.org/changeset/base/304436

Log:
  Don't check for broadcast IPs on non-bcast pkts

  in_broadcast() can be quite expensive, so skip calling it if the
  incoming mbuf wasn't sent to a broadcast L2 address in the first
  place.

  Reviewed by: gnn
  MFC after: 2 months
  Sponsored by: EMC / Isilon Storage Division
  Differential Revision: https://reviews.freebsd.org/D7309

Modified:
  head/UPDATING
  head/sys/netinet/udp_usrreq.c

Modified: head/UPDATING
==
--- head/UPDATING   Thu Aug 18 22:59:00 2016(r304435)
+++ head/UPDATING   Thu Aug 18 22:59:05 2016(r304436)
@@ -32,6 +32,14 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12
"ln -s 'abort:false,junk:false' /etc/malloc.conf".)

 20160818:
+   The UDP receive code has been updated to only treat incoming UDP
+   packets that were addressed to an L2 broadcast address as L3
+   broadcast packets.  It is not expected that this will affect any
+   standards-conforming UDP application.  The new behaviour can be
+   disabled by setting the sysctl net.inet.udp.require_l2_bcast to
+   0.
+
+20160818:
Remove the openbsd_poll system call.
 __FreeBSD_version has been bumped because of this.


Modified: head/sys/netinet/udp_usrreq.c
==
--- head/sys/netinet/udp_usrreq.c   Thu Aug 18 22:59:00 2016
(r304435)
+++ head/sys/netinet/udp_usrreq.c   Thu Aug 18 22:59:05 2016
(r304436)
@@ -126,6 +126,11 @@ SYSCTL_INT(_net_inet_udp, OID_AUTO, blac
 _NAME(udp_blackhole), 0,
 "Do not send port unreachables for refused connects");

+static VNET_DEFINE(int, udp_require_l2_bcast) = 1;
+SYSCTL_INT(_net_inet_udp, OID_AUTO, require_l2_bcast, CTLFLAG_VNET | 
CTLFLAG_RW,
+_NAME(udp_require_l2_bcast), 0,
+"Only treat packets sent to an L2 broadcast address as broadcast packets");
+
 u_long udp_sendspace = 9216;   /* really max datagram size */
 SYSCTL_ULONG(_net_inet_udp, UDPCTL_MAXDGRAM, maxdgram, CTLFLAG_RW,
 _sendspace, 0, "Maximum outgoing UDP datagram size");
@@ -523,7 +528,8 @@ udp_input(struct mbuf **mp, int *offp, i

pcbinfo = udp_get_inpcbinfo(proto);
if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) ||
-   in_broadcast(ip->ip_dst, ifp)) {
+   ((!VNET_NAME(udp_require_l2_bcast) || m->m_flags & M_BCAST) &&
+   in_broadcast(ip->ip_dst, ifp))) {
struct inpcb *last;
struct inpcbhead *pcblist;
struct ip_moptions *imo;



___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r304070 - svnadmin/conf

[Bruce Simpson]

On 14/08/16 05:35, Glen Barber wrote:

Author: gjb
Date: Sun Aug 14 04:35:04 2016
New Revision: 304070
URL: https://svnweb.freebsd.org/changeset/base/304070

Log:
  Do not include C function changes by default in svn commit
  email.


Please back out -- this makes the diff output much less useful.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303716 - head/crypto/openssh

[Bruce Simpson]

On 08/08/16 11:36, Dag-Erling Smørgrav wrote:

Bruce Simpson <b...@fastmail.net> writes:

Alcatel-Lucent OmniSwitch 6800 login broken

...

This patch did not remove weak DH groups.  That happened in 7.0p1 back
in January.


So my reading of this is that PuTTy may be the best workaround for 
end-users who have to speak to older SSH implementations.


That's what I ended up using to get around some of the SSH interop mess 
with the Proxim AP4000, although much of that was not directly related 
to the cipher suite!


(But ideally it should support X11-headless operation. To my knowledge, 
and as others have mentioned, it is currently believed to require it.)

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303811 - in head/sys: net net80211

[Bruce Simpson]

On 07/08/16 20:23, Peter Jeremy wrote:

On 08/07/16 05:48, Adrian Chadd wrote:

+#defineETHER_IS_BROADCAST(addr) \

...

IMHO, Adrian's code is clearer and micro-optimisations like this belong
in the complier, not the code.


*cough* *cough* 2007 wants its patch back.

https://people.freebsd.org/~bms/dump/old/latest-8021p.diff

The whole point of using bcmp() was to allow it to be inlined by the 
compiler for the target arch, rather than forcing it to play guessing 
games with (lowest-common-denominator machine-word-size) integer accesses.


ETHER_IS_MULTICAST(), by contrast, only needs to check a single bit in 
the 48-bit MAC.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303716 - head/crypto/openssh

[Bruce Simpson]

On 07/08/16 18:34, Andrey Chernov wrote:

Alcatel-Lucent OmniSwitch 6800 login broken (pfSense 2.3.2 which
accepted the upstream change, workaround no-go)

[2.3.2-RELEASE][r...@gw.lab]/root: ssh -l admin
-oKexAlgorithms=+diffie-hellman-group1-sha1 192.168.1.XXX
Fssh_ssh_dispatch_run_fatal: Connection to 192.168.1.XXX port 22: DH GEX
group out of range

DH prime size must be at least 2048, openssh now refuse lower values.
Commonly used DH size 1024 can be easily broken. See https://weakdh.org


diffie-hellman-group1-sha1 use DH 1024 and insecure sha1 both.



I appreciate that, but what do I as a user do about it? My distribution 
has changed behaviour I rely on in an operational setting. My initial 
reaction is likely to be one of confusion, and general dismay.


I appreciate that this is done for security reasons, but it could take 
an arbitrarily long time for a lot of deployed hardware in current use 
to be updated.


(On the other hand, the introduction of, say ED25519 has been more 
gradual, and has tended to see uptake in e.g. Linux-based ARM products.)

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303716 - head/crypto/openssh

[Bruce Simpson]

On 07/08/16 15:40, Warner Losh wrote:

That’s a cop-out answer. We, as a project, need to articulate to our
users, whom we care about, why this rather obnoxious hit to usability
was taken. The answer must be more complete than “We just disabled
it because upstream disabled it for reasons we’re too lazy to explain
or document how to work around"


Alcatel-Lucent OmniSwitch 6800 login broken (pfSense 2.3.2 which 
accepted the upstream change, workaround no-go)


[2.3.2-RELEASE][r...@gw.lab]/root: ssh -l admin 
-oKexAlgorithms=+diffie-hellman-group1-sha1 192.168.1.XXX
Fssh_ssh_dispatch_run_fatal: Connection to 192.168.1.XXX port 22: DH GEX 
group out of range


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303716 - head/crypto/openssh

[Bruce Simpson]

On 07/08/16 12:43, Oliver Pinter wrote:

I was able to override this (somewhat unilateral, to my mind)
deprecation of the DH key exchange by using this option:
-oKexAlgorithms=+diffie-hellman-group1-sha1


You can add this option to /etc/ssh/ssh.conf or ~/.ssh/config too.


Can this at least be added (commented out, if you really want to enforce 
this policy on users out-of-the-box) to the former file in FreeBSD 
itself? And a note added to UPDATING?


Otherwise, it's almost as though those behind the change are assuming 
that users will just know exactly what to do in their operational 
situation. That's a good way to cause problems for folk using FreeBSD in 
IT operations.


(systemd epitomises this kind of foot shooting.)

I understand already - you want to deprecate a set of key exchanges, and 
believe in setting an example - but the rest of the world might not be 
ready for that just yet.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303716 - head/crypto/openssh

[Bruce Simpson]

On 07/08/16 11:58, Bruce Simpson wrote:

Is there a way to revert this change, at least on an ongoing operational
basis (e.g. configuration file) for those of us who use FreeBSD to
connect directly to such devices?


I was able to override this (somewhat unilateral, to my mind) 
deprecation of the DH key exchange by using this option: 
-oKexAlgorithms=+diffie-hellman-group1-sha1


Obviously that is too much of a mouthful for day-to-day operational 
memory. I shudder to think how a novice SSH user, who is otherwise 
competent with network switches, is going to cope with this confusion.


OK, so deprecating the (unwanted/vulnerable/obsolete for whatever other 
reason) cipher suite is an ideologically sound move, but the road to 
hell is paved with good intentions.


But surely the operational implications of this on people who use SSH on 
a daily basis could have been better thought out, given many of these 
devices cannot just magically be updated to stop using DH?


As I've said this may not affect just Netonix devices, but a wide range 
of network devices which -- let's be frank -- be grateful they even have 
a basic SSH implementation. I'm staring at $VENDOR_A and $VENDOR_H.


Strikes me as foot shooting. Just my 2c.

Please, at least add a central knob for overriding this. pfSense took 
the change too. I couldn't log in to our local Netonix this morning 
(without booting up a Linux laptop), which violated POLA horribly for me.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303716 - head/crypto/openssh

[Bruce Simpson]

DES,

I believe this breaks logging into various embedded network devices, 
unfortunately. E.g. the Netonix WISP Switch, which uses an embedded 
Linux variant with dropbear 0.51. It is expecting to use DSA not RSA for 
the key exchange.g


Is there a way to revert this change, at least on an ongoing operational 
basis (e.g. configuration file) for those of us who use FreeBSD to 
connect directly to such devices?


I speculate this might affect folk logging into Cisco UCS IPMI 
controllers, also.


thanks
Bruce
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303522 - head/sys/dev/cxgbe

[Bruce Simpson]

On 01/08/16 17:49, Ian Lepore wrote:
...

In addition, the strerror() output for ENOTTY says nothing about a
typewriter, the text is "Inappropriate ioctl for device."


If that semantic gap has already been plugged, ignore my message.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303574 - head/sys/dev/gpio

[Bruce Simpson]

On 31/07/16 07:24, Adrian Chadd wrote:

  [gpioled] add support for inverting the LED polarity.
  No, this isn't a star trek science joke - sometimes LEDs are wired
  up to be active low, so this is needed.


Actually, just about every bit of hardware I have interacted with on 
that level recently lights on low.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303522 - head/sys/dev/cxgbe

[Bruce Simpson]

"Yes, I know it's not a typewriter. Why is this command not working?"

Perhaps this errno code should be aliased... and strerror() massaged in 
places... assuming we strictly follow the POSIX.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r301496 - in head: sbin/ifconfig share/man/man4 sys/net sys/sys

[Bruce Simpson]

On 06/06/16 13:48, Marcelo Araujo wrote:

We have on ipfw(8) support for DSCP[1], I'm not sure if this is the
same/similar case you mentioned for IP DS(DiffServices?).


Background: I introduced the code to process VLAN 0 tags inline as 
normal traffic several years ago for 802.1p.


I'm referring to a mapping between IP DS bits and priority bits in the 
802.1p header. We have that for 802.11 to some extent already, IIRC.


Data point: OS X allows applications to request LEDBAT style congestion 
control (i.e. BitTorrent-style background traffic) for arbitrary TCP 
sockets through the priority/DS API there.



About the MPLS, the main problem for me is: I have no "network link"
with MPLS that I could even make a test, back in 2008 I was looking for
options that I could reuse on FreeBSD to have a MPLS router support,
nowadays I'm not that keen on MPLS anymore.


Yes, it has downsides but there are still potential use cases for it.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r301496 - in head: sbin/ifconfig share/man/man4 sys/net sys/sys

[Bruce Simpson]

It's good to see this patch being aired out and going into mainline 
finally. However, what about IP DS mapping and/or application layer 
mapping? We may not need full-on MPLS style classification, unless we 
plan to take that code later on. (I'm looking at you, NetBSD.)

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r300207 - in head: sbin/camcontrol sys/cam/ata sys/cam/scsi sys/dev/ahci sys/geom sys/geom/eli sys/kern sys/sys usr.sbin usr.sbin/diskinfo usr.sbin/zonectl

[Bruce Simpson]

Right On Commander!

Now here is hoping the random-write issues with OpenZFS are solved...
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r296826 - in head/sys/arm: conf mv

[Bruce Simpson]

On 14/03/16 07:14, Wojciech Macek wrote:

Log:
   Add support for USB3.0 on Armada38x


Very cool. Do you know if any Armada (or other embedded) XHCI 
implementations like this support XHCI Debug Port 1.0 ?


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r296261 - in head/sys: kern sys

[Bruce Simpson]

All,

On 01/03/16 10:57, Svatopluk Kraus wrote:

Author: skra Date: Tue Mar  1 10:57:29 2016 New Revision: 296261 URL:
https://svnweb.freebsd.org/changeset/base/296261

Log: Mark other parts of interrupt framework as INTR_SOLO option
specific.


IMHO... The general rationalisation of the FreeBSD kernel-mode
driver API surface probably warrants updating this document:

https://www.freebsd.org/doc/en/books/arch-handbook/

Describing the general case in terms of ISA device drivers is probably 
confusing these days, although it reflects how the code has evolved.


cheers
Bruce
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r287780 - in head: share/man/man9 sys/kern sys/sys

[Bruce Simpson]

Ian,

To paraphrase what I said privately to the various dramatis personae in 
January:


Changes like this need to be reviewed before they go in. As timing is 
central to the entire OS, change review has to be meticulous, on par 
with the virtual memory management. We have a VM tsar; we do not have a 
timing tsar.


On 19/09/15 18:39, Ian Lepore wrote:

I'm afraid this message can be interpetted as "reviews are now mandatory
for a 'core component of the system' (whatever that means)".  If so,
this would be a Big Change from the last thing I heard about code
reviews, which was basically: as much as some people would like it to be
so, they are not mandatory.

...

a definition as meaningless and vague as[.]


I don't believe for one moment that George is advocating for mandatory 
reviews. But common sense should apply, _as timing is central to the 
entire OS_. It touches absolutely everything.


Hell, I wouldn't feel comfortable checking anything in to e.g. 
timecounters without at least running it by phk first.


So, +1 from me for backout until the change can be reviewed.

But to be fair to all involved, perhaps Hans should set out a timeline 
for how he wants to proceed, subject to the jitter inherent to an 
all-volunteer project.


thanks
Bruce
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r285160 - head/sys/conf

[Bruce Simpson]

On 05/07/15 20:53, Oliver Pinter wrote:

Log:
   Ensure all the required files get built when you include the IPSEC
option.



+1. IETF position these days is that IPSEC should be a standard feature.

Key management is a separate issue, and support for newer ciphers like 
ChaCha20 (see NaCL by Daniel Bernstein et al) and authenticated 
encryption schemes please.



Umm.. This looks more like that IPSEC should require that the crypto
device be specified instead of fixing it this way...


+1. Expressing static dependencies at the granularity of file rather 
than module or subsystem is a PITA, and leads to having to 
depth-first enumerate the deps like this, introducing clutter.



Is there any way to specify implication rules to config?
Ergo if I specify IPSEC without device crypto, then it's auto enable/include.
Similar to linux's Kconfig framework..


+1. I know this can be done at module granularity, but I have always 
found the options and files syntax somewhat arcane. I almost always 
copy-paste-edit existing stanzas.


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r284198 - head/bin/ls

[Bruce Simpson]

On 15/06/2015 19:49, Warner Losh wrote:

I’ve yet to see why ls —libxo is better than a separate program articulated
anywhere other than libxo all the things.” Having a clear statement about
why it is needed, why changing it vs having a separate program, etc would
help. But is seems overly gratuitous with little benefit.


+1, I don't see how libxo-ized ls(1) adds value.

e.g. in Python, one can use pathlib and scandir to walk arbitrarily wide 
and deep hierarchies, much as 'file ... | xargs foo'.


It has even (with hard work by koobs) supported FreeBSD's stat.st_flags 
since 2.3. So anything ls(1) can do, Python could do anyway.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r284198 - head/bin/ls

[Bruce Simpson]

On 14/06/2015 11:00, Slawa Olhovchenkov wrote:

On Sat, Jun 13, 2015 at 05:13:31PM -0700, Craig Rodrigues wrote:


The people I talk to use scripting languages like Python or Ruby,
and devops frameworks like Ansible, Saltstack, Puppet, and Chef.
They may do some quick prototyping and UI work with Javascript and HTML/CSS.
Being able to generate JSON directly from system-level tools,
and then analyze that in a Python script,


You need JSON from system-level tools for analyze that in a Python
script? Realy? Not plain text? or tab/space separated?



So, I am broadly in favour of keeping libxo -- providing the problems 
with its introduction are fixed.


I'm not even thinking of the DevOps space, but the RD space, where 
Python and R are king.


Man pages are small beer and can be dealt with easily.

Control flow and regressions from previous functionality are another 
issue, and I am not for a moment going to duck out and suggest those 
responsible for introducing it aren't also responsible for fixing these 
specific issues.


But I have yet to see a coherent argument here -- size(1) numbers, RSS 
figures etc. -- about how it allegedly adds bloat. Most of what I've 
seen so far is POLA, NIH resistance, and hand-wavery.


If anything it helps to future proof the code as it stands, and make it 
easier for us to actually engineer the system for performance.


I tend to look upon counter-arguments against that last point as The 
more we obfuscate, the harder it is to get found out that the code isn't 
actually that good.


So, if you read my previous response to this thread, I've clearly 
pointed out that: there are specific problems in parsing the output of 
these system tools as they stand.


If you don't believe this, you can have my yesterday morning/afternoon, 
where I was post-processing the output of 4000 individual vmstat -z 
and vmstat -m reports.


Another 1000 this morning, with more to follow. Oh boy, I'd say to 
myself, I wish I had libxo!


This argument is not limited to base system utilities. For example: 
iperf 3.x has had a similar reworking of its reporting format to include 
JSON.


This is a massive improvement over iperf 2.x, which does not even 
clearly document its CSV fields; you have to read the source for that. 
JSON actually tags each field.


This reduces the time from experiment to analysed result significantly, 
just because I can easily see what each god damned number means.


Given, you need to read the source to understand why its naive 
sequencing algorithm breaks in multipath networking scenarios, but one 
should not have to do this just to get basic throughput results tabulated.


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r284198 - head/bin/ls

[Bruce Simpson]

On 14/06/2015 18:10, Steve Kargl wrote:

On Sun, Jun 14, 2015 at 11:22:03AM +0100, Bruce Simpson wrote:


But I have yet to see a coherent argument here -- size(1) numbers, RSS
figures etc. -- about how it allegedly adds bloat. Most of what I've
seen so far is POLA, NIH resistance, and hand-wavery.



It is not alleged.  I actaully measured the bloat libxo
caused when w(1) was converted.

...

Here's the bloat with ls(1)

...

Steve, that's still less than one 4KB page.

OK, so I find it difficult to believe -- in this day and age of 
pipeline-saving CMOV instructions -- that the overhead is as large as 
~2800 bytes, where I would have expected roughly half that.


But not knowing what compile options you used, or having information 
about sizes (and working sets - just listing file sizes is hand waving) 
across the libxo modified binaries, this still doesn't give a complete 
picture of the relative cost of the feature.


However, that's still a very modest increase, considering the 
architectural scope of the libxo change and what it provides.


Warner suggests that for some targets it is too much, and he might have 
a point. But if you look at That Other Operating System, this is 
generally dealt with there by deploying something like BusyBox instead.


I can understand why we don't want to go down that road -- in my 
experience, the choice of BusyBox sacrifices too much usability -- and 
would support a WITH_LIBXO for that reason alone. The extra bytes might 
even disappear in the noise after crunchgen.


I think it is also fair that the people who advocated for this in the 
beginning (not I, though I support it in principle) and did the work 
(not I either, ENOTIME) should have done this work up front. I've had to 
do it to justify similar changes in other projects.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r284198 - head/bin/ls

[Bruce Simpson]

On 13/06/2015 16:38, David Chisnall wrote:

On 13 Jun 2015, at 11:17, Ian Lepore i...@freebsd.org wrote:


If you would have told me a year ago that you had a simple scheme that
could make 30 years of experience maintaining code for unix-like systems
completely worthless I would have been skeptical, but it seems we're
well on our way.


There is a lot of heckling and unhelpful hyperbole in this thread.


Agree -- teething trouble. I am trying to push something out right now 
based on 8.x, and all the little gotchas (e.g. vmstat -z not using a 
uniform delimiter set) are like little landmines on the highway in front 
of my Pursuit Special.


Personally I prefer the new formats, they're less ambiguous, and closer 
to the analytics where they actually get used.


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r284116 - head/sys/boot/ficl

[Bruce Simpson]

On 07/06/2015 18:06, Garrett Cooper wrote:

This commit's explicitly polluting the ficl interpreter with code from x86 on 
all platforms.


+1

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r284146 - in head/tools/bus_space: . C Python

[Bruce Simpson]

Marcel,

(Cc: Will as he's expressed interest in this)

No problem... still tied up here...

On Mon, 8 Jun 2015, at 06:10, Marcel Moolenaar wrote:
  On Jun 7, 2015, at 9:52 PM, Bruce Simpson b...@fastmail.net wrote:
  Nice! Is there a man page or documentation for this anywhere?
 
 Not yet. I want to flesh it out further before documenting.
 I’m not sure the API is stable enough yet. I’m still figure
 things out as I go.

  Also: is it feasible to extend to build/attach to a VirtIO function?
  (May be PCI, not MMIO).
 
 I think so. If there’s an easy environment for me to play
 with, I can take a look. I think qemu would do right?

If you load a FreeBSD VM into KVM, and turn on host-guest sharing,
you'll see a VirtIO function for Plan 9's v9fs exposed on the PCI bus.
This speaks a Linux-specific variant of the 9P protocol, 9P2000.L.

FreeBSD currently does not understand how to talk to it, nor do our
existing 9p ports. BHyve doesn't support host-guest sharing (yet).

Note: I neither claim nor argue that this is the most efficient
host-guest solution -- there are anecdotal reports that the claims IBM
have made in published papers cannot be verified in production -- but it
makes sense to re-use (and perhaps improve upon) what IBM have done
here, for the sake of interop more than anything else.

There is a FUSE-based implementation in Python, py9p, which might serve
as the basis for a prototype. NetBSD have a newer alternative but it
looks like more work to make it talk to the VirtIO function.

-- 
BMS (sent via webmail)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r284146 - in head/tools/bus_space: . C Python

[Bruce Simpson]

Marcel,

On Mon, 8 Jun 2015, at 04:23, Marcel Moolenaar wrote:
 Log:
   Add busdma_mem_alloc  busdma_mem_free.

Nice! Is there a man page or documentation for this anywhere?

Also: is it feasible to extend to build/attach to a VirtIO function?
(May be PCI, not MMIO).

cheers
Bruce

-- 
BMS (sent via webmail)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r284146 - in head/tools/bus_space: . C Python

[Bruce Simpson]

On Mon, 8 Jun 2015, at 06:10, Marcel Moolenaar wrote:
  Also: is it feasible to extend to build/attach to a VirtIO function?
  (May be PCI, not MMIO).
 
 I think so. If there’s an easy environment for me to play
 with, I can take a look. I think qemu would do right?

I can't speak to the MMIO case, but it may be of interest for CHERI.

This was added to VirtIO to support paravirtualization in emulators for
non-x86 SoCs (e.g. ARM, MIPS).

[See VirtIO spec white paper.]

-- 
BMS (sent via webmail)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r283424 - in head/sys: amd64/linux modules/linux64

[Bruce Simpson]

All,

The enhancements to the Linux runtime are probably of more interest to 
folk porting server applications; I am particularly happy to see 
recvmmsg() and sendmmsg() go in.


It might also be wise to emulate the getrandom() API, even if this is 
only in terms of wrapping the relevant sysctl for now.


On 25/05/2015 18:27, Slawa Olhovchenkov wrote:
Currenly I don't see any linux in Acrobat Reader support OS: 
https://get.adobe.com/reader/otherversions/ 


It got pulled. Of course, support for PDF's forms varies greatly outside 
of official Adobe product.


A better alternative might be the MuPDF backend for KDE Okular, or for 
Zathura, neither of which are packaged  anywhere in the Linux world yet. 
Of course, this could be built natively, without needing the Linux 
runtime support.


I've noticed that rendering performance seems disappointing in the open 
source Linux PDF readers, as compared to OS X Preview.app on similar 
hardware.


Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r279028 - in head/usr.sbin: . ifmcstat

[Bruce Simpson]

On 21/02/2015 00:50, Gleb Smirnoff wrote:
   


May be you refer to code that was always under #if 0, disabled due to
difficulty to go through RB-trees via kvm(3)?


My bad - yes - this code was unfinished as of SVN rev 192923, it seems I 
ran into problems with RB-tree walks through KREAD().


To implement this as a sysctl, one might copy the backend implementation 
of getsourcefilter(3) and work from there, specifically the internal 
IP_MSFILTER socket option.


Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r279028 - in head/usr.sbin: . ifmcstat

[Bruce Simpson]

Gleb,

Correct me if I'm wrong -- but doesn't this set of changes remove the 
ability for the user to see the stack-wide membership filters on each 
link? The implementation required KVM as it must inspect the SSM filters 
themselves to obtain this information.


On 19/02/2015 22:42, Gleb Smirnoff wrote:

   Now that IGMP and MLD sysctls provide a clean API structures that do not
   leak kernel internal stuff, reconnect ifmcstat(1) back to build.


The change is well motivated, but the job is only half done.

The backend code you have added simply reflects the per-link information 
to userland as a flat data structure; it does not appear to report what 
the membership filters are.


This would require taking a lock, walking the RB-tree for the in-mode 
filters, and serializing the data to userland as a variable length 
structure.


regards
Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r277054 - in head: share/man/man4 sys/modules/cc sys/modules/cc/cc_dctcp sys/netinet sys/netinet/cc

[Bruce Simpson]

On 12/01/2015 08:33, Hiren Panchasara wrote:

Log:
   DCTCP (Data Center TCP) implementation.
   


Right On Commander!
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r276083 - head/etc

[Bruce Simpson]

On 22/12/2014 21:26, Dmitry Morozovsky wrote:

Log:
   Add VAMI (VMware Appliance Management Interface) port.
   


This is vApp / VMware Studio related; any plans to get FreeBSD guests 
working?


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r275038 - in stable: 10/usr.sbin/rtadvd 8/usr.sbin/rtadvd 9/usr.sbin/rtadvd

[Bruce Simpson]

rtadvd(8) has a few other bugs apart from this. It could probably stand
to use CLOCK_MONOTONIC where that's possible, also...

-- 
BMS (sent via webmail)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r274672 - in head/contrib/libxo: . libxo xolint

[Bruce Simpson]

On 20/11/2014 21:10, Craig Rodrigues wrote:


Converting these (and other) utilities to use libxo will make it a lot 
easier to write analysis tools like eagleeye.


It'll also make it easier for anyone doing systems-level study. Right 
now I have a bunch of shell scripts which hoover up command output, use 
sed/awk/grep for basic post-processing into CSV/TSV, and throw the lot 
into a tarball.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r274017 - head/sys/kern

[Bruce Simpson]

On Mon, 3 Nov 2014, at 08:21, Julian Elischer wrote:
 I'm open to being persuaded but I think we need to have a discussion
 about stack usage. We used to say that anything greater that, say
 64 bytes should probably be allocated.

I have to admit the level of stack usage in my current $DAYJOB project
worries me (although I haven't profiled for this).

Every struct in6_addr{} is 16 bytes, and those mount up quickly.

-- 
BMS (sent via webmail)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r273855 - head/sys/netinet6

[Bruce Simpson]

Hello,

This is a really inconvenient time for me (I am up against a deadline)
but I am not 100% comfortable with this change.

On Thu, 30 Oct 2014, at 10:59, Andrey V. Elsukov wrote:
 Log:
   Fix mbuf leak in IPv6 multicast code.
   When multicast capable interface goes away, it leaves multicast groups,
   this leads to generate MLD reports, but MLD code does deffered send and
   MLD reports are queued in the in6_multi's in6m_scq ifq. The problem is
   that in6_multi structures are freed when interface leaves multicast
   groups
   and thread that does deffered send will not take these queued packets.

A few comments:

1) Stylistic -- a change of this kind should probably be part of
inm_purge() itself because it modifies state which is private to the
group membership.

2) Logical -- The patch forces pending (queued) state change record
fragments to be freed when the parent interface is taken down.
Unfortunately, those are pending for a reason; there has been a state
change, and MLD needs to communicate it upstream to on-link routers (and
snooping switches).

So - there is a risk with this approach that upstream MLD listener (e.g.
router, switch) will be inconsistent, at least until the next General
Query.

A better approach might be to force an INCLUDE {} to be sent for the
group (there are other parts of the code which try to do this for
similar events), but if the parent interface has already been taken
down, all bets are off. As of writing - The FreeBSD networking stack
doesn't provide any hints either way about the nature of the teardown.

Perhaps need to be a distinction between use cases where a hasty
teardown is unlikely to have operational impact (e.g. an ephemeral VPN
session between two nodes which is point-to-point in nature, and not
generally used for forwarding traffic), and cases where it may impact
other users (e.g. an MLD membership residing on a wireless interface,
which might result in unwanted multicast traffic being relayed to an
802.11 ESS).

-- 
BMS (sent via webmail)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r273274 - head/sys/netpfil/ipfw

[Bruce Simpson]

On Sun, 19 Oct 2014, at 13:02, Andriy Gapon wrote:
 I think that on platforms where an optimized version of fls() is
 available that
 would work faster than this cool piece of bit magic.

This is a common enough idiom that perhaps a macro should be added:

sys/param.h:
#define roundup(x, y)   x)+((y)-1))/(y))*(y))  /* to any y */
#define roundup2(x, y)  (((x)+((y)-1))(~((y)-1))) /* if y is powers of
two */
#define powerof2(x) x)-1)(x))==0)

sys/amd64/amd64/mp_machdep.c:
/*
 * Round up to the next power of two, if necessary, and then
 * take log2.
 * Returns -1 if argument is zero.
 */
static __inline int
mask_width(u_int x)
{

return (fls(x  (1 - powerof2(x))) - 1);
}


-- 
BMS (sent via webmail)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r271735 - head/sys/net

[Bruce Simpson]

On Thu, 18 Sep 2014, at 07:04, Kevin Lo wrote:
 Sorry, I overlooked that.  Marcelo has a patch with 802.1p tagging
 support,
 I thought the patch was committed.

I agree the comment change should be reverted. I changed if_ethersubr.c
many years ago to decode 802.1p tags into the mbuf packet header if they
are present.

However, to my knowledge, there is no support (e.g. in the form of a
DiffServ / IntServ mapping) further up in the stack. If someone plans to
add this, great -- that would be needed for any form of tangible 802.1p
support.

-- 
BMS (sent via webmail)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r271023 - stable/10/sys/dev/vt

[Bruce Simpson]

On Thu, 4 Sep 2014, at 10:05, Jean-Sébastien Pédron wrote:
 Unfortunately, reading from the video memory is very expensive. The new
 version of vt_vga never reads from the video memory. Instead, it uses
 the console history to know what those 8 pixels should look like and
 write one byte which doesn't need further processing.
... 
 Those two problems combined explain the slownness of vt(4), especially
 with discrete GPU and virtual machines; i915 users were mostly spared.

It may be a good idea to monitor the performance of vt(4) under virtual
KVM systems (e.g. Supermicro IPMI, VMware VNC, Cisco UCS etc.) for the
following reasons:

1) users of FreeBSD are likely to rely on them for operations,
2) many of these systems already work along similar principles (i.e.
delta compression),
3) to be sure that cascaded updates don't cause additional display
latency.

-- 
BMS (sent via webmail)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r269621 - head/sys/boot/common

[Bruce Simpson]

On 06/08/2014 01:36, Marcel Moolenaar wrote:

Log:
   Optionally include the install command as found on Juniper products
   like EX and SRX. The install command uses pkgfs to extract a kernel,
   zero or more modules and a root file system from the specified package
   and boots the kernel. The name of the kernel, the list of modules and
   the name of the root file system can be specified by putting a
   file called metatags in the package.


Nice. This is going to be really useful for people building appliances, 
both as a low-level recovery mechanism, and/or upgrade mechanism.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r268943 - in head: include lib/libc/stdlib

[Bruce Simpson]

On 03/08/2014 15:27, Warner Losh wrote:

What, if anything, can be done about qsort_r() API incompatibility?

qsort_r is non-standard and we did it first, plus we will want to stay 
compatible with Apple :).

I guess we could do some ugly parameter swapping in the case where _GNU_SOURCE
is defined, but I won’t volunteer to do that.

Are there any ABI considerations for the change?

I'm in agreement with Pedro here. Some form of compile-time checking is 
the best one can hope for in that situation, as it would be difficult to 
ret-con the qsort_r() ABI itself. The glibc implementation swaps two 
pointers in its signature. One of those points to executable code.


The last time this caused problems for me was when testing the new 
CScope indexing backend by Elad Lahav on BSD/Mac. He had developed on 
Linux, however the quick fix was to fall back to using non-reentrant 
qsort().


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r268566 - head/usr.bin/users

[Bruce Simpson]

On 12/07/2014 12:34, Bruce Evans wrote:


This joke is bad.  The C++ version is worse in every way.


I concur with everything you have said in your message. Moral of story: 
it is very, very easy to introduce bloat using C++, and using a higher 
level language does not automatically lead to better code quality.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r268566 - head/usr.bin/users

[Bruce Simpson]

On 12/07/2014 16:31, Ian Lepore wrote:

It is in no way established that any kind of mess exists.
On the contrary, the metrics and analysis which bde@ has presented seem 
pretty clear to me.



   All we have
is some people who appear to hate C++ expressing their opinions about
how they hate C++.  All the whining about how many more bytes the
compiled code is or many milliseconds something takes to compile don't
add up to any actual problem.


Other developers may quite reasonably look out for code quality and 
preservation of non-functional requirements across the board. I am 
bemused that you characterize this as whining, thus taking a technical 
discussion into ad hominem territory.




My opinion is that the original commit message was exactly correct:  The
code was rewritten to be cleaner and easier to understand and maintain.
We need more of the same.
Metadata is not the same thing as content -- the commit message can be 
as erudite as one likes, but at the end of the day, if the change is of 
dubious value, people will call you on it.


Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r268210 - stable/10/sys/dev/glxiic

[Bruce Simpson]

Daichi-san,

Just FYI: I could not get IIC to work with the glxiic(4) driver in tree 
on my PC Engines ALIX 6D2, although this driver [1] appears to work. 
Tested with a Dallas Semiconductor DS1337 RTC module some time ago.


Bruce

[1] http://www.phisch.org/website/glxiic/
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r267633 - head/sys/sys

[Bruce Simpson]

On 19/06/2014 06:28, Hans Petter Selasky wrote:

Author: hselasky
Date: Thu Jun 19 05:28:42 2014
New Revision: 267633
URL: http://svnweb.freebsd.org/changeset/base/267633

Log:
   Initialize sysctl OID structure by record.


So, has there been any traction on rethinking / backing out this change 
(which breaks the compilation of C++ kernel modules) ?

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r267633 - head/sys/sys

[Bruce Simpson]

On 19/06/2014 21:05, Hans Petter Selasky wrote:


Are there any existing C++ kernel modules, or in ports? Even though, 
C++ kernel modules can be compiled with C files aswell, containing the 
sysctls.


The Click Modular Router is implemented in C++, I have occasionally 
pitched in with keeping it up to date and building on FreeBSD (although 
not for a few years now).


Putting myself in the shoes of a third party developer, I can see that 
C++ compatibility would be important, so I hope a solution can be found 
here.


Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266242 - in stable/9: share/man/man4 sys/conf sys/dev/mrsas sys/modules sys/modules/mrsas

[Bruce Simpson]

On 16/05/2014 08:46, Doug Ambrisko wrote:

   mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
   show up as /dev/daX.  mfiutil(8) does not work with mrsas.


This is a big improvement. When using ZFS with mfi(4), mfiutil(8) can be 
used to create an un-RAID configuration by creating several stripes 
spanning single disks. The MegaRAID BIOS does not make the relevant 
options easily available. Having native CAM support for each disk will 
be a big help here.


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r266098 - stable/10/sys/arm/ti

[Bruce Simpson]

On 14/05/2014 16:57, Ian Lepore wrote:

TI Programmable Realtime Unit Subsystem.
OK, so PRUSS is one vowel change away from the name of a killer android 
in a work by Philip K. Dick.


Are there applications for this driver? I'm just curious having skimmed 
this document [1]:


The PRU subsystem on the OMAP-L1x processors, C674x DSPs, and AM1x 
Sitara ARM MPUs allows the application developer to implement soft 
peripherals; peripherals implemented using a combination of on-chip 
hardware and software.


[1] http://www.ti.com/lit/wp/spry136a/spry136a.pdf
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r265456 - head/libexec/rtld-elf

[Bruce Simpson]

Mark,

On 06/05/2014 19:07, Mark Johnston wrote:

Log:
   Add a postinit debugger hook to rtld. This will be used by dtrace(1) to halt
   the victim process before its entry point is called, at which point probes
   and DOF data are registered with the kernel.


I recently had a situation where I had to run gdb on a static (and 
stripped) Linux binary, under the Linuxolator. Perhaps this change can 
be used there too?


Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r265456 - head/libexec/rtld-elf

[Bruce Simpson]

On 07/05/2014 18:31, Mark Johnston wrote:
The Linuxulator makes use of Linux's loader rather than rtld; this was 
the source of the problem fixed in r254018, for example. Static 
binaries are not invoked through rtld either, so I don't think this 
change would have helped anyway.


I'm aware that the rtld code is otherwise unrelated to how Linux ELF 
images are activated, and should have been clearer in my original 
message. Sorry about that.


My question is really: is there an easy way of setting a start of 
program breakpoint for such binaries  e.g. where _start and/or main 
are not exposed in the (nonexistent) symbol table?


Currently I have to inspect the ELF load address and set a breakpoint 
manually in such cases. This is something which might be addressed by a 
GDB macro, although we may not always be using GDB.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r253841 - head/sys/netinet6

[Bruce Simpson]

On 01/08/13 17:55, Rui Paulo wrote:

On 1 Aug 2013, at 09:27, Alexander V. Chernikov melif...@freebsd.org wrote:

Because thay aren't really interfaces. All they need is BPF.
There is a cleaner approach described here: 
http://lists.freebsd.org/pipermail/freebsd-net/2012-December/034031.html


I don't agree with this patch as-is, but I'll need to spend some time writing 
an email... To be continued later.



+1 with Rui here. A few comments.

I would like to see a cleaner approach to the networking data plane, but 
this would need to be considered in some depth. One place to start might 
be the informational RFC for the Netlink socket API.


Whilst the gap between BPF and ifnet is acknowledged, there is still a 
place for virtual interfaces. Lacking other management mechanisms, the 
ifnet (and its name) ends up being used as a convenient handle.


I have code in development which tries to address more general issues of 
IPvX address dependency by using such an interface.




___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r253590 - in head/sys: kern net sys

[Bruce Simpson]

On 24/07/13 05:24, Marcel Moolenaar wrote:

Log:
   Decouple the UUID generator from network interfaces by having MAC
   addresses added to the UUID generator using uuid_ether_add(). The
   UUID generator keeps an arbitrary number of MAC addresses, under
   the assumption that they are rarely removed (= uuid_ether_del()).
   This achieves the following:
   1.  It brings up closer to having the network stack as a loadable
   module.
   2.  It allows the UUID generator to filter MAC addresses for best
   results (= highest chance of uniqeness).
   3.  MAC addresses can come from anywhere, irrespactive of whether
   it's used for an interface or not.


I like this change, because it's interface agnostic. The fallback 
behaviour in uuidgen (of choosing the first Ethernet interface) isn't 
desirable in many situations.


Also I like the line of thinking in point 1. In some embedded and niche 
environments, not having any IP4/6 at all is quite desirable (kernel 
size, security).

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r253841 - head/sys/netinet6

[Bruce Simpson]

On 07/08/13 13:05, Gleb Smirnoff wrote:

Yes, lack of good management mechanism creates a temptation to create
a foo(4) interface for any new FOO protocol, with its own if_ioctl method
that will provide a clean entry into its management. I suspect that was one
of the reasons to implement carp(4) as interface.


My concern is that whilst the BPF change is well intentioned, we may be 
unravelling a loose thread; other issues loom in the FreeBSD network 
stack elsewhere. These might be considered artefacts of FreeBSD's fairly 
informal approach to network stack management.


This approach has served us reasonably well for many years -- it is 
simple and easier to maintain than the somewhat byzantine NDIS/TDI 
sandwich in Microsoft Windows. This doesn't change the fact that dealing 
with the venerable PF_ROUTE socket is a royal pain.


However we should be careful with refactoring. Changes to network stack 
management may affect stack elements such as net-snmp, snort, ntop, 
Netflow collectors, etc. A managed infrastructure might also use SNMP to 
track network configuration data.


I foresee that this change could help in those deployment scenarios; as 
SNMP is platform agnostic, Netdot (and other management tools) must 
parse and filter out the non-proto-bound ifnets (*) as their 
statistics are not normally considered useful. In Netdot, a set of 
heuristics are applied based on the sysObjectID MIB variable.


(*) It's entirely possible someone may want to log these things for 
development purposes, though.





What do you mean about virtual interfaces? An interface must represent
a sink where a route entry can point to and incoming packets can come in.
With this definition a vlan(4) is a real interface, but pfsync(4), pflog(4),
ipfwlog(4) are not.


At the moment we have a model whereby protocol families get bound to 
ifnets statically (not dynamically). It's OK for ifnets to be in a state 
of change where they may not have protocols bound to them during early 
system boot. (I guess my question is: packet sockets - why not?)


The specific case I am working with does satisfy this criterion, however 
it relies on other changes which restore the  legacy BSD behaviour where 
loopback traffic will only appear on the BPF instance specific to the 
ifnet. E.g. currently FreeBSD will present all locally looped back 
traffic on lo0 (or the current vnet's primary lo(4) instance).




The situation with lack of management mechs should be fixed, and BPF
providers should be decoupled from ifnet, and no new not-a-true-interface
ifnets should be introduced in FreeBSD. All these not-a-true-interfaces
require dozens of special handling around the kernel, an example is a
commit we are discussing.



Agreed. carp(4) does not quite fit the model well at all. FreeBSD's 
implementation of it relies on ipprotosw[] and some other hooks in 
ether(4) leading to nested conditionals (my import of  M_PROMISC from 
NetBSD around 2007 may have helped limit code churn here.)


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r191651 - head/usr.sbin/mtest

[Bruce Simpson]

John,

That's news to me. I'm pretty sure I tested this code with and without
INET6 when I checked it in, given I was mostly testing without INET6.

This was a very long time ago, so I was surprised to receive your
message. Could something have changed to have broken mtest?

thanks
BMS

John Baldwin wrote:
 On Wednesday, April 29, 2009 5:50:04 am Bruce M Simpson wrote:
 Author: bms
 Date: Wed Apr 29 09:50:04 2009
 New Revision: 191651
 URL: http://svn.freebsd.org/changeset/base/191651

 Log:
   Merge IPv6-capable mtest(8) from MLDv2 branch.

 Modified:
   head/usr.sbin/mtest/Makefile
   head/usr.sbin/mtest/mtest.8
   head/usr.sbin/mtest/mtest.c
 
 This is completely broken as it fails to work if you don't have INET6 
 compiled 
 into the kernel, even if all you want to do is test joining IPv4 multicast 
 groups.
 
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r206452 - head/sys/netinet

[Bruce Simpson]

On 04/16/10 09:23, Alexander Leidinger wrote:


IP multicast group membership is always scoped to physical links [1]. 
The 4.4BSD API originally used the primary IP address to identify 
each link. Unfortunately this is not a persistent identifier, 
especially so in the use-case which had problems.



Is/was this the reason why multicast does not work in jails?


The above point is totally unrelated to jail.

I think the problem with jail is the fact that to receive multicast, 
sockets normally need to be bound to INADDR_ANY. Obviously, jail changes 
socket behaviour in interesting ways.


This may require refactoring udp_input() considerably. We use the 4.4BSD 
legacy LIST_FOREACH() loop to deliver, rather than using a fan-in map 
(which is the Windows/Solaris approach).


Linux also has 4.4BSD semantics, but can work around this by examining 
the SO_BINDTODEVICE option in the same path.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r206701 - in stable/8/sys: amd64/include conf dev/hwpmc i386/include modules/hwpmc sys

[Bruce Simpson]

Right On Commander!

On 04/16/10 16:43, Fabien Thomas wrote:

Log:
   MFC r206089, r206684:

   - Support for uncore counting events: one fixed PMC with the uncore
  domain clock, 8 programmable PMC.
   - Westmere based CPU (Xeon 5600, Corei7 980X) support.
   - New man pages with events list for core and uncore.
   - Updated Corei7 events with Intel 253669-033US December 2009 doc.
 There is some removed events in the documentation, they have been
 kept in the code but documented in the man page as obsolete.
   - Offcore response events can be setup with rsp token.
   


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r206452 - head/sys/netinet

[Bruce Simpson]

On 04/10/10 13:05, Bruce M Simpson wrote:

Log:
   Fix a few issues related to the legacy 4.4 BSD multicast APIs.

   IPv4 addresses can and do change during normal operation. Testing by
   pfSense developers exposed an issue where OpenOSPFD was using the IPv4
   address to leave the OSPF link-scope multicast groups on a dynamic
   OpenVPN tun interface, rather than using RFC 3678 with the interface
   index, which won't be raced when the interface's addresses change.
   


I should point out that IP multicast is counter-intuitive in many areas. 
It seems that knowledge of how to work with it effectively is not that 
widespread. People who have a need to use it, often have very specific 
requirements.


IP multicast group membership is always scoped to physical links [1]. 
The 4.4BSD API originally used the primary IP address to identify each 
link. Unfortunately this is not a persistent identifier, especially so 
in the use-case which had problems.


In the updated API specified in RFC 3678, the primary key for multicast 
memberships, changes to the interface index. routed(8) in FreeBSD's SVN 
tree uses this new API; thanks to phk for reviewing and testing my change.


In the case of OpenOSPFD+OpenVPN, the issue manifested itself in 
situations where this primary IP address changed. OpenVPN shims 
address assignment as part of its wire protocol, which is where the 
address change originates.


This is purely a by-product of using an API which depends on using an 
IPv4 address as a key (IP_ADD_MEMBERSHIP/IP_DROP_MEMBERSHIP), when that 
key may change at any time.


There's some time domain uncertainty with that change. PF_ROUTE is an 
out-of-band mechanism used by OpenOSPFD to learn about the address 
change, and it is dispatched separately from the change itself; there 
may be queueing and context switches involved. It also creates some 
ambiguity for in_multi instances, which the kernel may not be able to 
resolve, if that key has been blown away. Fortunately, such ambiguity is 
private to each socket.


Furthermore, this makes IGMP somewhat unreliable, although mechanisms do 
exist in the protocol to work-around the end-station's identifier being 
lost in this way. The upstream IGMP querier (usually the mcast router) 
will hold state based on the end-station's primary IP address, this 
will eventually time out due to unanswered queries.


MLD side-steps this by always requiring an IPv6 link-scope address in 
control traffic. Using the more recent multicast RFCs, supported now by 
Windows, Linux, OpenSolaris, and now FreeBSD, can side-step these 
issues; it is the preferred API.


P.S. HEAD was probably already resilient against this for joins. I plan 
to MFC a similar version of this change to 8 soon.


[1] sendto() to an IP multicast address, without an interface specified, 
makes no sense -- unless the host is also an mcast forwarder. You can 
get away with default route resolution through the routing tables up to 
a point, but if your box is multihomed, all bets are off.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r205104 - in head/sys: dev/xen/netback netinet netinet6

[Bruce Simpson]

On 03/13/10 13:53, Robert N. M. Watson wrote:

On Mar 13, 2010, at 1:50 PM, Randall Stewart wrote:
   

I could refactor that this way if you want... it would mean a few more de-ref's 
and
looking to see if its a v4 or v6 packet and then doing the proper offset...
 


This is the sort of thing which M_PROTO* flags are good for.

Derefs in the hot path should be amortized whenever that makes sense.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r204870 - head/sys/modules

[Bruce Simpson]

On 03/08/10 15:01, Nathan Whitehorn wrote:

Log:
   Enable tmpfs unconditionally on all platforms. No one I spoke to could
   remember why it was x86 only, and it works just as well on at least powerpc
   as on x86.
   


Thanks, What with 7.3 coming up and all, this would make for a nice MFC. :-)


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r204493 - head/lib/libc/stdlib

[Bruce Simpson]

Hey Jason,

Have you looked at sys/tree.h ? It is used by pf and the multicast code.

cheers
Bruce

On 02/28/10 22:57, Jason Evans wrote:

Author: jasone
Date: Sun Feb 28 22:57:13 2010
New Revision: 204493
URL: http://svn.freebsd.org/changeset/base/204493

Log:
   Rewrite red-black trees to do lazy balance fixup.  This improves
   insert/remove speed by ~30%.
   


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r203574 - head/etc

[Bruce Simpson]

On 07/02/2010 04:38, Doug Barton wrote:


Are all the port numbers that have been added recently things that 
have been requested by users? IIUC there is a cost albeit small for 
parsing the /etc/services file each time it's read, so traditionally 
we've tried to keep it as small as possible while still meeting the 
needs of our users.


I've been running sane-backends with this mod locally on all my FreeBSD 
desktop clients for some time. Given that it's been given an official 
allocation by IANA it seemed reasonable to add it to our own 
/etc/services to support this use. It's pretty essential for day-to-day 
office use of FreeBSD as a desktop system.


The intention is to be able to use pfSense as a lightweight appliance 
platform for scan/print, to reduce my power bill, and get rid of noisy 
old boxes.


I have a diff to add an RC script to the existing graphics/sane-backends 
port here, and it requires that saned-port be present in /etc/services:

http://people.freebsd.org/~bms/dump/sane-backends-saned.diff

Note well the comments about devd.conf configuration being a bit of a 
pain for USB endpoints.


What could use further care and attention is the configuration of sane 
itself. Just using scanimage -L with the default out-of-box 
configuration causes a coredump; if I reduce dll.conf to the bare 
minimum required, it's fine.


Others have commented that AHCI in HEAD accepting arbitrary SCSI 
commands can cause the driver to hang briefly, I observed this earlier; 
commenting out the SCSI backends worked around this, and I know mav@ has 
a patch for it which hasn't been MFCed just yet.


thanks,
Bruce
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r203108 - in head/sys: cam cam/ata cam/scsi dev/ahci dev/asr dev/ata dev/ciss dev/hptiop dev/hptrr dev/mly dev/mpt dev/ppbus dev/siis dev/trm dev/twa dev/usb/storage

[Bruce Simpson]

I just tested this patch in -STABLE right now, and it's looking fine so far.

Plugging the eSATA box in triggers:
ada1 at ahcich3 bus 0 scbus3 target 0 lun 0
ada1: WDC WD5000AADS-00S9B0 01.00A01 ATA-8 SATA 2.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)
ada1: Command Queueing enabled
ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)

anglepoise:~ % camcontrol devlist
WDC WD1600YD-01NVB1 10.02E01 at scbus0 target 0 lun 0 (pass0,ada0)
WDC WD5000AADS-00S9B0 01.00A01   at scbus3 target 0 lun 0 (ada1,pass5)
HL-DT-ST RW/DVD GCC-4481B C103   at scbus4 target 1 lun 0 (pass1,cd0,sg0)
Generic 2.0 Reader-0 1.00at scbus6 target 0 lun 0 (sg1,da0,pass2)
Generic 2.0 Reader-1 1.00at scbus6 target 0 lun 1 (sg2,da1,pass3)
Generic 2.0 Reader-2 1.00at scbus6 target 0 lun 2 (sg3,da2,pass4)

Playing an AVI with VLC off the external drive is fine, didn't do any 
more I/O tests.


Unplugging it (after unmounting) triggers:
(ada1:ahcich3:0:0:0): lost device
(ada1:ahcich3:0:0:0): removing device entry

anglepoise:~ % camcontrol devlist
WDC WD1600YD-01NVB1 10.02E01 at scbus0 target 0 lun 0 (pass0,ada0)
HL-DT-ST RW/DVD GCC-4481B C103   at scbus4 target 1 lun 0 (pass1,cd0,sg0)
Generic 2.0 Reader-0 1.00at scbus6 target 0 lun 0 (sg1,da0,pass2)
Generic 2.0 Reader-1 1.00at scbus6 target 0 lun 1 (sg2,da1,pass3)
Generic 2.0 Reader-2 1.00at scbus6 target 0 lun 2 (sg3,da2,pass4)

Update of the gstat display is almost instantaneous, I see the GEOM 
providers appear and disappear when [un]patching.


Great job!
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: moving sctp to a separate directory ? (Re: svn commit: r201523 - head/sys/netinet)

[Bruce Simpson]

On 04/01/2010 22:23, Luigi Rizzo wrote:

I also think that the name of the new directory or the exact percentage of
ipv4-ness or netinet-ness of the sctp* and tcp* and multicast* stuff
is irrelevant.  Moving directories with svn is so easy that we should not
worry even if we need a couple of attempts to find a good name.
   


On a related, but different, note:
I actually think that the mcast code could have benefitted from C++ 
style templates. There's a lot of code duplication between the IPv6 and 
IPv4 versions of those modules.
It's the entry points, and argument types, which ultimately 
mattered, so when integrating the MLD implementation into FreeBSD back 
last April, I found myself doing 'cp', 'sed', and manual edits mostly to 
deal with only *slight* semantic differences between IPv4 and IPv6 in 
the kernel.


Having said all that, it seems to me like the netinet/ code overall 
could do with being split up further into individual files, to make it 
more manageable. This has sort of already happened as time has gone on.


cheers,
BMS
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r201472 - in head/sys: kern sys

[Bruce Simpson]

On 04/01/2010 05:27, David Xu wrote:

Log:
   Add user-level semaphore synchronous type...
   


Nice work! Will this be MFC-able to 8.x?
A lot of things could benefit from this, especially Boost.Interprocess.

cheers,
BMS

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r201204 - head/lib/libc/sys

[Bruce Simpson]

On 29/12/2009 15:58, Konstantin Belousov wrote:

Author: kib
Date: Tue Dec 29 15:58:10 2009
New Revision: 201204
URL: http://svn.freebsd.org/changeset/base/201204

Log:
   Document _FAST and _PRECISE clocks.
   


I saw a speed increase with CLOCK_MONOTONIC_FAST vs CLOCK_MONOTONIC 
during pmcstat and kcachegrind profiling of a process which makes a lot 
of calls to clock_gettime().


Thanks for doing this.

best,
BMS

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r201139 - in head/sys: cam/ata geom sys

[Bruce Simpson]

On 28/12/2009 20:08, Alexander Motin wrote:

Author: mav
Date: Mon Dec 28 20:08:01 2009
New Revision: 201139
URL: http://svn.freebsd.org/changeset/base/201139

Log:
   Add BIO_DELETE support to ada(4):
   - For SSDs use TRIM feature of DATA SET MANAGEMENT command, as defined by
   ACS-2 specification working draft.
   - For CompactFlash use CFA ERASE command, same as ad(4) does.
   


A thought popped into my head as I read this.
Is anyone implementing these ATA commands, intended for CF and SSD 
devices, in e.g. VirtualBox, QEMU?
They could probably help out with block allocation for copy-on-write 
disk images there.


Just a thought.

cheers,
BMS
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r200797 - head/lib/libc/stdtime

[Bruce Simpson]

On 12/22/09 20:19, Doug Barton wrote:

I know that there is a huge cultural bias towards shipping a complete
system, and don't get me wrong, I am fully supportive of that. I am
NOT suggesting that we dike out the existing toolchain. Just that we
make it easier to use toolchains from ports.
   


+1

The modularity we have now is great.

We need more modularity to support stuff like cross-builds.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r200432 - in stable/8: . contrib/top lib/libusb sbin/atacontrol sys/arm/mv sys/cam/ata sys/cam/scsi sys/conf sys/dev/ata sys/dev/ata/chipsets sys/powerpc/powermac sys/powerpc/psim tool

[Bruce Simpson]

Alexander Motin wrote:

Log:
  MFC r200171, r200182, r200275, r200295, r200359:
  Introduce ATA_CAM kernel option, turning ata(4) controller drivers into
  cam(4) interface modules. When enabled, this option deprecates all ata(4)
  peripheral drivers (ad, acd, ...) and interfaces and allows cam(4) drivers
  (ada, cd, ...) and interfaces to be natively used instead.
  
   Does this not mean there are now two AHCI drivers? i.e. ata(4) with 
ATA_CAM, and ahci(4).

   If so, which one is preferred?

   ahci(4) seems subjectively faster (I have not measured it), although 
it has a minor issue on my motherboard with ATI SB700 that it does not 
turn off the HDD activity led.


   I can see though that this could be difficult to roll out/deploy for 
default installations from universal media (-RELEASE disc1, memstick), 
different drivers yield different device names.
   In one embedded product build I've had to deal with, I use atapicam 
just to make sure the kernel expects to mount / from the same device, vs 
when it's booted from an attached USB CDROM drive.


   I'm using GEOM labels on my home systems to deal with this now, 
which was a little tricky to set up, but deals with the problem very 
nicely, as well as making it possible for me to swap disks between 
physical controllers.
   tunefs will return no error when the -L option is used when booted 
into single-user mode -- but if the fs is then mounted, the superblock 
change seems to be lost. In all other cases, rewriting the superblock is 
denied.


Anyway thanks for all your hard work on this so far...

cheers!
BMS
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r197652 - stable/7/sys/kern

[Bruce Simpson]

Nice fix.

Timing problems are the subtlest.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r196797 - in head: sys/net sys/netinet usr.bin/netstat

[Bruce Simpson]

Robert Watson wrote:
For sysctls, explicit versioning doesn't help too much -- what I've 
been pondering for another structure was including spares and having a 
capabilities field in the structure where flags are set when fields 
are known by the kernel.  That way userspace can tell if the kernel 
knows about the field it cares about and therefore whether they're 
worth looking at.


One thing that Thrift did was to explicitly all number fields in their 
implementation of RPC. This is useful, because if anything changes over 
time, implementations can be updated to keep track of that.


Whilst I agree that it's unlikely 'struct arpstat' would change, if it 
did, it would be great to have a length field, at a minimum, in front. 
sysctl can determine size at runtime, however, kmem interfaces cannot. 
That's the only real reason why I'd nudge about it. :-)


For igmpstat, at least, the SSM drop adds a LOT of state to the network 
stack which wasn't there before, so having an explicit version field is 
warranted for backwards compatibility (and this is something Robert 
chewed me out about many months ago). Much respect, big yo'self up yo...


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r196797 - in head: sys/net sys/netinet usr.bin/netstat

[Bruce Simpson]

George V. Neville-Neil wrote:

Author: gnn
Date: Thu Sep  3 21:10:57 2009
New Revision: 196797
URL: http://svn.freebsd.org/changeset/base/196797

Log:
  Add ARP statistics to the kernel and netstat.
  


Thanks very much for this change.
Any chance this struct can get explicitly versioned (i.e. as for struct 
igmpstat) as it is a new struct?


cheers,
BMS
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r196550 - in head: etc/defaults etc/rc.d share/man/man5

[Bruce Simpson]

Xin LI wrote:

Log:
  Add a new rc.d script, static_arp, which enables the administrator to
  statically bind IPv4 - MAC address at boot time.
  


Thanks for doing this -- users will love this!

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r196039 - in head/sys: contrib/pf/net dev/cxgb/ulp/tom net netinet netinet6

[Bruce Simpson]

Hey Robert,

I didn't see any changes which directly touched ip_mroute in this rev. 
Can you clarify how this touches ip_mroute? It wasn't obvious from the diff.


thanks,
BMS

Robert Watson wrote:

Log:
  Many network stack subsystems use a single global data structure to hold
  all pertinent statatistics for the subsystem.  These structures are
  sometimes borrowed by kernel modules that require a place to store
  statistics for similar events.
...
  The following modules are affected by this change:
  
if_bridge

if_cxgb
if_gif
ip_mroute
  


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r196039 - in head/sys: contrib/pf/net dev/cxgb/ulp/tom net netinet netinet6

[Bruce Simpson]

Robert Watson wrote:


You're right, it was included in error.  ip_mroute is on the list of 
modules that uses a stats structure with an accessor macro, but that 
structure make it onto the list of structures requiring accessor 
functions because it's accessed only from within ip_mroute (actually, 
two such functions/macros).  I must have made a transcription error 
when writing up the commit message.  My notes on accessor macros and 
files that consume them below.


No worries, I was just going 'Hurm hah hurm wtf'. :-)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org