YAMAMOTO Takashi | 4 Feb 11:39 2008
Picon

Re: CVS commit: [yamt-lazymbuf] src/sys/arch/amd64/include

> On Thu, Jan 24, 2008 at 12:11:42PM +0900, YAMAMOTO Takashi wrote:
> > are you suggesting to sprinkle manual map calls instead of
> > "automatic" one in mtod (and its equivalent in asm code)?
> 
> Yes, I would strongly prefer to do this in the high-level C code instead
> of touching the assembly. If mtod does that, that's ok, but I would
> prefer if the MD in_cksum backend does not have to deal with it.
> 
> Joerg

if we go that route, isn't it better to remove mbuf knowledge from
the MD backend completely?  ie. like linux.

YAMAMOTO Takashi

Joerg Sonnenberger | 4 Feb 13:46 2008
Picon

Re: CVS commit: [yamt-lazymbuf] src/sys/arch/amd64/include

On Mon, Feb 04, 2008 at 07:39:23PM +0900, YAMAMOTO Takashi wrote:
> > On Thu, Jan 24, 2008 at 12:11:42PM +0900, YAMAMOTO Takashi wrote:
> > > are you suggesting to sprinkle manual map calls instead of
> > > "automatic" one in mtod (and its equivalent in asm code)?
> > 
> > Yes, I would strongly prefer to do this in the high-level C code instead
> > of touching the assembly. If mtod does that, that's ok, but I would
> > prefer if the MD in_cksum backend does not have to deal with it.
> > 
> > Joerg
> 
> if we go that route, isn't it better to remove mbuf knowledge from
> the MD backend completely?  ie. like linux.

The MD backend only needs a very limited understanding of mbufs:
- m_len
- m_data
- m_next

Removing that would mean one function call per mbuf, possible register
savings and complications for handling misaligned / odd length mbufs.
That in turn would likely have a measurable performance effect.

Joerg

John D. Baker | 4 Feb 20:54 2008

pf synproxy doesn't pass to local services

I've run into trouble with pf's "synproxy state" option on
NetBSD-4.0_STABLE.  The examples are on i386--haven't had a chance to
try other ports yet.

If I have a pf rule that allows access to a locally-running service,
"synproxy state" proxies the TCP handshake, but the connection is never
passed on to the local service.

For example, to allow incoming SSH on my laptop:

   pass in on $ext_if proto tcp to ($ext_if) port ssh synproxy state

No further segments are sent after the client ACK.

If I revert to "modulate state" or just "keep state" incoming connections
to local services succeed.

"synproxy state" works properly if the rule pertains to a redirected
connection.  For example, my firewall redirects SSH to an internal host
with:

   rdr on $ext_if proto tcp from !($ext_if) to ($ext_if) port ssh \
       -> $ssh_host port ssh

   pass in on $ext_if proto tcp to $ssh_host port ssh synproxy state

pf synproxy state works correctly with local services on OpenBSD 4.2.

Has anyone else see this?

(Continue reading)

Dutta Dwaip | 6 Feb 07:51 2008
Picon

Issue with Ipv6 Link local address

Hi,

I am using some older verion of NetBSD code and landed up into a issue with TCP
connect code when my destination address is Link local address.
On investigation I found that in6_pcblookup_hash() called from
tcp_input() fails and it sent RST back. The reason for failure is that
foreign address of inpcb structure
is not embedded with scope Id and therefore IN6_ARE_ADDR_EQUAL fails as
the local and foreign address passed from ip6_input are embeddedd with scope id
for Link local address.

I am sure this must have been addressed in latest code of NetBSD, which I have
failed to figure out . Can someone help me on this.

Regards
DD

John D. Baker | 6 Feb 14:20 2008

Re: pf synproxy doesn't pass to local services

I've repeated my tests on -current/macppc and it behaves the same way.

If a pf rule allowing access to a local service (such as SSH) uses
"synproxy state", the TCP handshake is proxied with the client, but
the connection is apparently not passed to the daemon, (such as 'sshd').

If the rule uses "modulate state" or just "keep state", the connection
to the service succeeds.

It the rule allows access to a service through a connection redirected
to another host, "synproxy state" works fine.

--

-- 
John D. Baker, KN5UKS                    NetBSD     Darwin/MacOS X
jdbaker(at)mylinuxisp(dot)com                 OpenBSD            FreeBSD
BSD -- It just sits there and _works_!
GPG fingerprint:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

Picon

Re: Issue with Ipv6 Link local address

At Wed, 6 Feb 2008 12:21:20 +0530,
"Dutta Dwaip" <dwaipayand <at> gmail.com> wrote:

> I am using some older verion of NetBSD code and landed up into a issue with TCP
> connect code when my destination address is Link local address.
> On investigation I found that in6_pcblookup_hash() called from
> tcp_input() fails and it sent RST back. The reason for failure is that
> foreign address of inpcb structure
> is not embedded with scope Id and therefore IN6_ARE_ADDR_EQUAL fails as
> the local and foreign address passed from ip6_input are embeddedd with scope id
> for Link local address.
> 
> I am sure this must have been addressed in latest code of NetBSD, which I have
> failed to figure out . Can someone help me on this.

I don't have an environment to test the very latest code, but I'm
pretty sure that the problem you described doesn't exist in the
current by code inspection of netinet6/in6_pcb.c, rev 1.94.  I also
tried NetBSD 3.1 and didn't see the problem.  Could you be more
specific about with which version of the kernel you experienced it?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

Gerald Lee | 7 Feb 18:14 2008

Compilation warning on current (4.99.53) sys/net/if.c


	Subject says it all, recently updated and was building for the
ev64260.  Yes I know, no one builds without INET6 set, but that's what
I'm building until I start on the real hardware.  Once more, just wanted
to let you all know.

	The warning:

NetBSD_current/src/sys/net/if.c: In function 'ifioctl':
NetBSD_current/src/sys/net/if.c:1510: warning: unused variable 's'

	This is used to elevate the spl for one call, s holding the
current level.  Only used in this place, I would probably declare 's' in
the context of the 'if' where this call was made.  However, being a bit
uncertain about how it might be fixed used the more cluttered:

Index: sys/net/if.c
===================================================================
RCS file: /cvsroot/src/sys/net/if.c,v
retrieving revision 1.216
diff -r1.216 if.c
1510c1510,1513
<       int s, error = 0;
---
>       int error = 0;
> #ifdef INET6
>       int s;
> #endif

(Continue reading)

Joerg Sonnenberger | 8 Feb 00:18 2008
Picon

in6_clearscope vs in6_cksum_phdr

Hi all,
can someone illuminate me why in6_cksum_phdr does not check for
IN6_IS_ADDR_MC_INTFACELOCAL for the addresses like in6_clearscope?

Joerg

Jan Vlk | 8 Feb 12:15 2008
Picon

W83627 GPIO

Hallo,

we have new HW where was used chip Winbond W83627 for GPIO of expand 4x = 1G cards.
On the expand cards are relays which are plan to using bypass. In this
time all relays are default switch off, so for using as router I need = default
switch on. From the one developer I receive describe how to switch this = one.
see bellow. Do you know any solution (for sample by gpioctl) for = switching=20
by BSD utilites?

thanks
--

-- 
Jan Vlk <vlk <at> gjbi.cz>

YAMAMOTO Takashi | 9 Feb 13:48 2008
Picon

in_cksum (Re: CVS commit: [yamt-lazymbuf] src/sys/arch/amd64/include)

> On Mon, Feb 04, 2008 at 07:39:23PM +0900, YAMAMOTO Takashi wrote:
> > > On Thu, Jan 24, 2008 at 12:11:42PM +0900, YAMAMOTO Takashi wrote:
> > > > are you suggesting to sprinkle manual map calls instead of
> > > > "automatic" one in mtod (and its equivalent in asm code)?
> > > 
> > > Yes, I would strongly prefer to do this in the high-level C code instead
> > > of touching the assembly. If mtod does that, that's ok, but I would
> > > prefer if the MD in_cksum backend does not have to deal with it.
> > > 
> > > Joerg
> > 
> > if we go that route, isn't it better to remove mbuf knowledge from
> > the MD backend completely?  ie. like linux.
> 
> The MD backend only needs a very limited understanding of mbufs:
> - m_len
> - m_data
> - m_next

yes.

> Removing that would mean one function call per mbuf, possible register
> savings and complications for handling misaligned / odd length mbufs.
> That in turn would likely have a measurable performance effect.
> 
> Joerg

does it really matter?
i think the fetch-and-add part is dominant for performance.

(Continue reading)


Gmane