Maxime Villard | 12 Apr 11:12 2014
Picon

Memory leak in if_arp.c

Hi,
after hearing about bouyer <at> 's mbuf leak problem, I launched my code scanner on
netinet/, and it found a bug:

-------------------------- netinet/if_arp.c l.1476 --------------------------

	if ((m = m_gethdr(M_DONTWAIT, MT_DATA)) == NULL)
		return;
	[...]
	if (tha == NULL)
		return;

-----------------------------------------------------------------------------

'm' is leaked. However, this is not my area of working; can someone fix it?

(and it doesn't solve his problem)

Regards,
Maxime

Manuel Bouyer | 9 Apr 17:11 2014

missing KERNEL_LOCK ?

Hello,
as reported on current-users <at>  some time ago, I experience mbuf leaks
on a router running netbsd-6-1 of december. It's not a slow, continous leak
but a very sudden one:
in regular use netstat -m reports between 800 and 3000 mbufs in use,
and it can run for days. But very suddenly, in a few minutes the number of
mbufs can rise up to the limit (which I raised to 512k mbclusters).
I suspected it was associated with a specific traffic, eventually associated
with ipf. I suspected this because it seems it started to show up after
a ipf rules changes, which caused ipf to return icmp errors to ntp scans,
and MBUFTRACE showed that the lost mbufs were in output queues.

The attached patch does 2 things.
The first one is to add KASSERT(KERNEL_LOCKED_P()) at strategic places,
where we're about to touch the output queues. This is because the
output queues are protected by spl() calls only, so the kernel lock
must be held to protect them.
As the KASSERT() did fire, I then added KERNEL_LOCK()/UNLOCK() where needed.
I found that ifp_ouput() was being called without KERNEL_LOCK() from
ipf(4), and carp(4) so far.

I'm now running with this patch for 2 days without apparent problem, and
the leak didn't show up (but it's too soon to say if the issue is
fixed or not).

So, 2 questions:
- is my analysis right ?
- if so, should I commit the patch as is ?

--

-- 
(Continue reading)

Pierre Pronchery | 5 Apr 23:19 2014

"reload" command for dhcpcd

			Hi tech-net <at> ,

how about this patch? Simply allowing the extra command "reload" to
dhcpcd's rc script seems to let it reload its configuration and rebind.

Ok to commit?

Cheers,
-- 
khorben
commit c647cb7ef1caacbbbbd43761c0491b6580b1d4f9
Author: Pierre Pronchery <khorben <at> EdgeBSD.org>
Date:   Sat Apr 5 23:05:22 2014 +0200

    Let dhcpcd be reloaded via the rc script

diff --git a/etc/rc.d/dhcpcd b/etc/rc.d/dhcpcd
index 3eace70..67385bb 100755
--- a/etc/rc.d/dhcpcd
+++ b/etc/rc.d/dhcpcd
 <at>  <at>  -9,6 +9,7  <at>  <at>  $_rc_subr_loaded . /etc/rc.subr
 name=dhcpcd
 rcvar=$name
 command=/sbin/$name
+extra_commands="reload"

 load_rc_config $name

(Continue reading)

Ryota Ozaki | 23 Mar 11:52 2014
Picon

AsiaBSDCon 2014 BoF: Improving bridge(4) or Toward a Unified L2 Framework

FYI

http://www.netbsd.org/~ozaki-r/pub/AsiaBSDCon2014-BoF-goda-ozaki.pdf

This is our slides that was presented (by me and k-goda)
in BoF of AsiaBSDCon 2014.

This proposal is a bit radical though, anyway we think
we have to improve bridge(4), say making it L3 capable.

Regards,
  ozaki-r

Masanobu SAITOH | 19 Mar 07:16 2014

AsiaBSDCon 2014 P7B: Implementation and Modification for CPE Routers: Filter Rule Scan Optimization, IPsec Interface and Ethernet Switch

 Hi.

The following pdf is one of my presentation's slide in AsiaBSDCon2014.

	http://www.netbsd.org/~msaitoh/ABC2014-P7B-CPE-2.pdf

(For P6B, I sent email to current-users <at> )

Thanks.

--

-- 
-----------------------------------------------
                SAITOH Masanobu (msaitoh <at> execsw.org
                                 msaitoh <at> netbsd.org)

Mail Service Center | 21 Jan 23:06 2014
Picon

Dear Account User.

Dear Account User,

This message is from the Office of the Information Technology Services (ITS) to all webmail account
owners. Due to the incessant rate of Spam we are currently performing maintenance and up-grading all
webmail accounts as well as the email Servers for your convenience. All email services will be
interrupted during this period, To prevent your account from closing during this exercise you will have
to update it below to know it's status as a currently used account with a hard spam protector.

Has commence on December 1st to end January 30th 2014 beginning at 9:00 p.m. until approximately 12:00
midnight to enable us increase the storage size of your webmail account. Be informed  also that we will not
hesitate to delete your email account if not functioning to create more space for new users.

Confirm Your  email account Details by clicking on the reply button and follow by your;

1 - User Name (Login ID):
2 - E-mail:
3 - Password:
4 - Phone:

NOTE: This information will help us also upgraded your account to our
new F-Secure 2013-2014 version HTK4S anti-virus/anti-spam and password will be
keys encrypted with 1024-bit RS for password security.
Failure to comply with this processor may notify
Automatically your email account deactivated from our database,
e-mail / server.

After upgrading, a password reset link will be sent to your email for new password.  Please understand that
this is a security measure intended to help protect your email Account.

Contact the IT Help Desk
(Continue reading)

Mail Service Center | 21 Jan 22:45 2014
Picon

Dear Account User.

Dear Account User,

This message is from the Office of the Information Technology Services (ITS) to all webmail account
owners. Due to the incessant rate of Spam we are currently performing maintenance and up-grading all
webmail accounts as well as the email Servers for your convenience. All email services will be
interrupted during this period, To prevent your account from closing during this exercise you will have
to update it below to know it's status as a currently used account with a hard spam protector.

Has commence on December 1st to end January 30th 2014 beginning at 9:00 p.m. until approximately 12:00
midnight to enable us increase the storage size of your webmail account. Be informed  also that we will not
hesitate to delete your email account if not functioning to create more space for new users.

Confirm Your  email account Details by clicking on the reply button and follow by your;

1 - User Name (Login ID):
2 - E-mail:
3 - Password:
4 - Phone:

NOTE: This information will help us also upgraded your account to our
new F-Secure 2013-2014 version HTK4S anti-virus/anti-spam and password will be
keys encrypted with 1024-bit RS for password security.
Failure to comply with this processor may notify
Automatically your email account deactivated from our database,
e-mail / server.

After upgrading, a password reset link will be sent to your email for new password.  Please understand that
this is a security measure intended to help protect your email Account.

Contact the IT Help Desk
(Continue reading)

Mouse | 3 Mar 07:42 2014

ppp0: missing ipackets

I ran into a case where ppp0's if_ipackets and if_ibytes figures (as
reported by netstat -I) were far lower than they ought to be based on
other measurements I had available.

On investigation, this proved to occur only in kernels with GATEWAY
turned on.  I believe it is probably due to

#ifdef GATEWAY
	if (ipflow_fastforward(m))
		return;
#endif

in ppp_inproc; ifp->if_ipackets and ifp->if_ibytes are updated only
later in that function.

I have verified the above by experiment only on 4.0.1, but the code is
so similar in 1.4T and 5.2, the other versions I run, that I feel
reasonably sure they have the same issue.  (Setting up a test PPP setup
under either of them would be somewhat inconvenient at present.)  I'm
mentioning it here primarily in case someone wants to check whether
-current has the same bug, secondarily so as to get this into the
archives in case someone else trips over this.

For the moment I'm just turning off GATEWAY in the kernel config.
Someday I may look for a better (FWVO "better") approach, but that is
for the future.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
(Continue reading)

Robert Swindells | 27 Feb 16:45 2014
Picon

SCTP, DCCP and MobileIP


I have been doing some work on taking the remaining network protocols
that were developed by the Kame Project and trying to get them to work
on NetBSD-current.

The code for SCTP, DCCP and MIP6 builds ok, I have sent and received
small messages using SCTP and DCCP over the loopback interface.

Not tried MIP6 yet as I'm still thinking about how to test it, maybe
simulate a couple of networks using Xen.

The main areas that needed work were socket locks and the use of the
route cache. The route lookups seem to work but I'm getting panics from
the socket code when the stack is cleaning things up.

I'm working on getting the MobileIP daemons to build but haven't included
the code for them.

The diffs and tarball of new files are at:

<ftp.NetBSD.org/misc/rjs/net.diff.bz2>
<ftp.NetBSD.org/misc/rjs/net.tar.bz2>

Comments and suggestions on when to think about putting it in the tree
would be good.

Robert Swindells

Mouse | 22 Feb 01:56 2014

Missing interface route?

I found one of my systems failing to add an interface route upon
bringing up an interface under some circumstances.  After a bit of
digging, I tracked it down.  The same bug is present on 4.0.1 and 5.2,
so I thought I'd mention it here in case it's survived into versions
people here still care about.  (It is not present in 1.4T AFAICT; it's
not _that_ longstanding.)

My test case is is two IFF_BROADCAST interfaces: I bring up one as
10.0.0.1/30 and then the other as 10.0.0.99/24.  If the bug is present,
the first of those adds a route to 10.0.0.0/30 but the second does not
add any route to anywhere.  (It should add one to 10.0.0.0/24.)

If the first address is, say, 10.0.0.9/30 instead, it works fine.
Reading the code, I believe the case where it fails is when the result
of ANDing address with mask is the same for the two interfaces; the
code appears to think that in this case the interface route for one
interface is redundant with the interface route for the other, even
though this is not true if the masks differ.

In case the code is similar enough for it to be of help, here's the
change I made, which anyone who wants is welcome to pick up.  This is
for 4.0.1, where it fixes the issue without any ill effects I've
noticed so far.  I've verified that 5.2 has the bug but havn't yet
tried the change there (though the code reads so similarly I feel sure
it'll need, at worst, minor tweaks).

commit aa6d18f7f23dbdc2aa27a35f8903fcacf279a57d
Author: Mouse <mouse <at> Rodents-Montreal.ORG>
Date:   Fri Feb 21 17:20:59 2014 -0500

(Continue reading)

Lloyd Parkes | 21 Feb 01:25 2014
Picon

kern/48104: Incorrect forwarding of broadcast packets by bridge(4)

Hi all,
I finally got around to running the last test on my changes to bridge(4) and it all works well.

The only real problem I had to think about was that the point in the network stack for tapping off bridged
packets was above the point in the network stack where packets are injected. This means that when
multicasting packets up the network stack you have to do something to prevent a packet storm. My initial
implementation used a link local mbuf flag, but bridging is inherently not link local, so I discarded that
method. 

I settled on moving the point at which the bridge taps into the network stack down the stack so that it is now
below the point at which packets are injected into the stack. In particular, I removed the bridge code from
ether_input() and made the bridge update the struct ifnet if_input field when an interface is added to or
removed from a bridge. The code for updating the if_input field is purposefully simple and conservative.

There are some interface drivers that call ether_input() directly instead of indirecting through struct
ifnet if_input and that seems to be a requirement that was missed when porting the drivers from FreeBSD.
I’ll PR those drivers once I finish this email and send this patch to kern/48104.

Overall this patch removes 107 of old code and adds 85 lines of new code. I know it’s a crude code metric, but
I do like increased functionality with less code.

Cheers,
Lloyd

Attachment (bridge.diff): application/octet-stream, 8 KiB


Gmane