Re: threaded prof signals

2013-10-04 Thread Ted Unangst
On Thu, Oct 03, 2013 at 18:12, Philip Guenther wrote: > How about we take an idea from FreeBSD and have hardclock() just set a > flag on the thread and then have the thread send SIGPROF (and SIGVTALRM) > to itself from userret(). The signal gets sent by the thread itself right > before it checks f

Re: Promiscuous mode and multicast

2013-10-04 Thread Brad Smith
On Fri, Oct 04, 2013 at 03:18:45PM +0200, Martin Pieuchot wrote: > tl;dr > > This diff stop (ab)using the actual SIOC{ADD,DEL}MULTI ioctls with a > magic value for the whole range of multicast addresses used for IPv4/6 > to turn the interface into promiscuous mode. > > > Long story > > Ethe

Re: snmp client (aka "walk")

2013-10-04 Thread Gabriel Guzman
On 10/01, Reyk Floeter wrote: > Hi, > > I just committed a simple SNMP client implementation to snmpctl/snmpd. > You can use it as an in-tree alternative to net-snmp's > snmpwalk/snmpget. > > Examples: > $ snmpctl walk 127.0.0.1 > $ snmpctl walk printer.my.domain version 1 oid printerWorkingGroup

[lists-openbsdt...@bsws.de: Re: ip6_mroute.c m_free() -> m_freem()]

2013-10-04 Thread Loganaden Velvindron
- Forwarded message from Henning Brauer - Date: Fri, 4 Oct 2013 13:34:26 +0200 From: Henning Brauer To: Loganaden Velvindron Subject: Re: ip6_mroute.c m_free() -> m_freem() User-Agent: Mutt/1.5.21 (2010-09-15) ok -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services Gm

Re: nouveau driver help

2013-10-04 Thread Jérémie Courrèges-Anglas
(Redirecting to tech@) Roelof Wobben writes: > Hello, Hi, > To enjoy Gnome 3.10 fully I need the nouveau driver. > But because this is my first attempt to make a port, > I wonder if someone can and is willing to help me. I don't think that porting nouveau is a ports people concern (but rath

Promiscuous mode and multicast

2013-10-04 Thread Martin Pieuchot
tl;dr This diff stop (ab)using the actual SIOC{ADD,DEL}MULTI ioctls with a magic value for the whole range of multicast addresses used for IPv4/6 to turn the interface into promiscuous mode. Long story Ethernet multicast records are currently represented by the ``struct ether_multi'' as ran

Re: getifaddrs() netmasks with af=0 on vlan/lo

2013-10-04 Thread Claudio Jeker
On Fri, Oct 04, 2013 at 11:46:42AM +0100, Stuart Henderson wrote: > It seems that for some interface types (I noticed vlan and lo), a netmask > with af==0 is returned by getifaddrs(). > > Not sure if this was always broken or introduced more recently; happens > on at least 5.3 and -current so it's

Re: ip6_mroute.c m_free() -> m_freem()

2013-10-04 Thread Claudio Jeker
On Fri, Oct 04, 2013 at 12:17:41AM -0700, Loganaden Velvindron wrote: > Hi, > > I came across this small diff in netbsd. It fixes a small case of mbuf > leak possibility. > This is correct. OK claudio@ > Index: sys/netinet6/ip6_mroute.c >

Re: getifaddrs() netmasks with af=0 on vlan/lo

2013-10-04 Thread Martin Pieuchot
On 04/10/13(Fri) 11:46, Stuart Henderson wrote: > It seems that for some interface types (I noticed vlan and lo), a netmask > with af==0 is returned by getifaddrs(). > > Not sure if this was always broken or introduced more recently; happens > on at least 5.3 and -current so it's not anything part

getifaddrs() netmasks with af=0 on vlan/lo

2013-10-04 Thread Stuart Henderson
It seems that for some interface types (I noticed vlan and lo), a netmask with af==0 is returned by getifaddrs(). Not sure if this was always broken or introduced more recently; happens on at least 5.3 and -current so it's not anything particularly recent. Demonstration code (yes I know it's crap

Re: Multicast macros and global list of addresses

2013-10-04 Thread Martin Pieuchot
On 02/10/13(Wed) 21:33, Stuart Henderson wrote: > On 2013/09/19 13:59, Martin Pieuchot wrote: > > Diff below change the macros used to iterate over the multicast > > records linked to an interface without using the global lists of > > addresses. > > > > These records are currently link to the firs

ip6_mroute.c m_free() -> m_freem()

2013-10-04 Thread Loganaden Velvindron
Hi, I came across this small diff in netbsd. It fixes a small case of mbuf leak possibility. Index: sys/netinet6/ip6_mroute.c === RCS file: /cvs/src/sys/netinet6/ip6_mroute.c,v retrieving revision 1.62 diff -u -p -r1.62 ip6_mroute.c