potential mbuf corruption

net/netinet/tcp-input.c

-------------------------------
int
syn_cache_respond(struct syn_cache *sc, struct mbuf *m)
{
#ifdef INET6
	struct rtentry *rt;
#endif
	struct route *ro;
	u_int8_t *optp;
	int optlen, error;
	u_int16_t tlen;
	struct ip *ip = NULL;
#ifdef INET6
	struct ip6_hdr *ip6 = NULL;
#endif
	struct tcpcb *tp = NULL;
	struct tcphdr *th;
	u_int hlen;
	struct socket *so;

	ro = &sc->sc_route;
	switch (sc->sc_src.sa.sa_family) {
	case AF_INET:
		hlen = sizeof(struct ip);
		break;
#ifdef INET6
	case AF_INET6:
		hlen = sizeof(struct ip6_hdr);

routing cleanup project

Hi All,
When looking for some simple networking task in netbsd, i found this 
project : http://netbsd.org/contrib/projects.html#routing-cleanup.

It stated : "It's necessary to modify rtalloc(), at least".
But, i can't find rtalloc() function, only rtalloc1().

So, it seems that the code already cleaned by someone else.

It raises another question, is the project listed on 
http://netbsd.org/contrib/projects.htm still up to date?

Thanks

Re: potential mbuf corruption

On Thu, 2 Dec 2010, Alexander Danilov wrote:

> net/netinet/tcp-input.c
>
> wrong check
> 	if (m && tlen > MHLEN) {
> should be
> 	if (m && (tlen + max_linkhdr) > MHLEN) {

you are correct and I have fixed it (v1.306), though I'm not sure there
are enough supported options to actually overrun an mbuf?

iain

Re: routing cleanup project

On Fri, Dec 03, 2010 at 01:56:36AM +0700, iwan bk wrote:
> Hi All,
> When looking for some simple networking task in netbsd, i found this
> project : http://netbsd.org/contrib/projects.html#routing-cleanup.
>
> It stated : "It's necessary to modify rtalloc(), at least".
> But, i can't find rtalloc() function, only rtalloc1().
> 
> So, it seems that the code already cleaned by someone else.

I think you're right, that task must not be up-to-date with the code.

I have thought of a related, simple networking task: use a suitable
abstraction to hide the details of the radix trie (sys/net/radix.c)
implementation of routing-table lookups from the networking code in
sys/net/, sys/netinet/, sys/netinet6/, et cetera.  The idea is that we
should be able to replace the radix trie with a data structure that is
more SMP-friendly, *and* we should be able to improve the networking
stacks with features like multipath routing, lookups based on different
different keys than the packet destination, and so on.

To get an idea how many/few places our networking code is touching the
radix trie directly, look for symbols beginning with RNF_, rnh_, rn_ in
sys/net*/*.[ch].

> It raises another question, is the project listed on
> http://netbsd.org/contrib/projects.htm still up to date?

Probably not.

Re: LDP

Pe 12.08.2010 14:49, basteon a scris:
> hi, it working well?
> you didn't it in a RUMP?
>
> the main troube because here no peer auth(it must happens through
> extended ip-header), i did it about 1yr ago, but freeze.
>

It works. If no objections are made I'll commit it next week into 
usr.sbin/ldpd. After that I'll take a look to ldp authentication, it 
should be done via TCP signature, iirc.

"name-based sockets" standardization efforts

It seems that there's some effort afoot to standardize so-called
'name-based sockets'; to quote the IETF draft 
( http://www.ietf.org/id/draft-ubillos-name-based-api-00.txt ) as to
what those are:

   We suggest a unified API for networked applications.  Isomorphic to the
   existing name-based solutions, but with added network-related
   functionality.  Providing an existing application-layer protocols with
   network features such as mobility, multi-homing, IPv4/IPv6
   interoperability, NAT-traversal and so on...

As, historically, the IETF hasn't been that great at defining APIs,
I thought it might be worthwhile to point some of y'all at it.

----- Forwarded message from Andrew Josey <ajosey <at> opengroup.org> -----

From: Andrew Josey <ajosey <at> opengroup.org>
Date: Fri, 3 Dec 2010 09:59:11 +0000
To: austin-group-l <at> opengroup.org
Cc: Javier Ubillos <jav <at> sics.se>
Subject: IETF liaison: Defining APis. [Fwd: A name-oriented API: What should it look like? How should it behave?]
Message-Id: <ABD2C7D5-AB8C-49D0-B966-07B04A171FFE <at> opengroup.org>
X-Mailer: Apple Mail (2.1082)

hi All

I wanted to alert you to an activity at IETF that may be of interest. They have indicated 
to me that would be very much interested in liaising with us on a API as described below.

If you are interested in this please contact Javier Ubillos <jav <at> sics.se>

patch: avoid wm(4) resets when adding/deleting vlan(4)

After a wm(4) is reset, it takes about 30 seconds for the NIC to get
back "on net."  It's really painful.

I've attached a patch for -current that stops wm(4) from needlessly
resetting when you add or delete a vlan(4):

ifconfig vlan0 create vlan 2 vlanif wm0
ifconfig vlan0 destroy

Please give it a look or give it a try.  I will commit it next week.

A patch for netbsd-5 is on the way.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933

Index: if_wm.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_wm.c,v
retrieving revision 1.215
diff -u -p -r1.215 if_wm.c
--- if_wm.c	16 Oct 2010 06:31:49 -0000	1.215
+++ if_wm.c	3 Dec 2010 21:14:01 -0000
 <at>  <at>  -516,6 +516,7  <at>  <at>  static int	wm_read_mac_addr(struct wm_so
 static void	wm_tick(void *);

Re: patch: avoid wm(4) resets when adding/deleting vlan(4)

> After a wm(4) is reset, it takes about 30 seconds for the NIC to get
> back "on net."  It's really painful.

Are you sure it's the wm's fault?  This sounds suspiciously like a
spanning tree holddown time, in which case anything that interrupts
link will cause the same symptom, and the proper cure is to not run
spanning tree on ports connected to hosts.

Indeed, I just now tried your example (on 4.0.1, that being the only
wm-using NetBSD machine I have easy root access to as far as I know)
and the wm dropped off the net for almost exactly five seconds.  (The
machine has an fxp, and I was logged in to it, pinging out through the
wm.)

> I've attached a patch for -current that stops wm(4) from needlessly
> resetting when you add or delete a vlan(4):

This strikes me as a good thing regardless.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: patch: avoid wm(4) resets when adding/deleting vlan(4)

On Fri, Dec 03, 2010 at 05:07:46PM -0500, der Mouse wrote:
> > After a wm(4) is reset, it takes about 30 seconds for the NIC to get
> > back "on net."  It's really painful.
> 
> Are you sure it's the wm's fault?  This sounds suspiciously like a

It's typically a combination of wm and the link partner behavior.  The
minimum interval appears to be several seconds.

Thor

Re: patch: avoid wm(4) resets when adding/deleting vlan(4)

On Fri, Dec 03, 2010 at 05:28:40PM -0500, Thor Lancelot Simon wrote:
> On Fri, Dec 03, 2010 at 05:07:46PM -0500, der Mouse wrote:
> > > After a wm(4) is reset, it takes about 30 seconds for the NIC to get
> > > back "on net."  It's really painful.
> > 
> > Are you sure it's the wm's fault?  This sounds suspiciously like a
> 
> It's typically a combination of wm and the link partner behavior.  The
> minimum interval appears to be several seconds.

FWIW, I have my wm(4) under test plugged into a 24-port 3Com gigabit
switch, and the delay seems to be partly the fault of the switch.  When
I plug my MacBook Pro into the same switch in the morning, there is
a long delay before a DHCP lease is acquired.  My MacBook Pro uses a
Marvell chip:

Marvell Yukon Gigabit Adapter 88E8053 Singleport Copper SA:

  Name:	ethernet
  Type:	Ethernet Controller
  Bus:	PCI
  Vendor ID:	0x11ab
  Device ID:	0x4362
  Subsystem Vendor ID:	0x11ab
  Subsystem ID:	0x5321
  Revision ID:	0x0022
  Link Width:	x1
  BSD name:	en0
  Kext name:	AppleYukon2.kext
  Location:	/System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleYukon2.kext