headers
YAMAMOTO Takashi | 1 Nov 2005 09:56
Picon

Re: sosend_loan tweak

hi,

> Surely this is what the watermark setsockopt()s are for? If one
> desires one's application to send `large' chunks, to gain more from
> page loanout, then shouldn't one be setting the send-side watermark to
> be at least one page?

do you mean sb_lowat?

> Or if you don't want to put the setsockopt()s into your application,
> how about changing the default watermarks to be more friendly to sosend()?

do you think it's acceptable?

YAMAMOTO Takashi
Permalink | Reply | 0 comments |
headers
Martin J. Laubach | 2 Nov 2005 15:39
Picon

IP-Filter changes wrt keeping state

  I recently upgraded my firewall machine from 1.6 to 2.0 and
found that something in ip-filter seems to have changed in a
rather strange way.

  I basically have access lists for each interface. On the internal
one I do

	block in all on internal-IF head 10
	pass out proto tcp from any to any port = 1234 keep state group 10

  and on the external one

	block out all on external-IF head 20
	pass out proto tcp from any to 1.2.3.4 port = 1234 keep state group 20

  Under 1.6 this worked fine, restricting the reachable hosts for port
1234 to 1.2.3.4. Under 2.0, this lets connect to ANY host on port 1234.

  I'm a bit stumped -- has something dramatic changed or is my ipf.conf
logic flawed?

	mjl
Permalink | Reply | 4 comments |
headers
Martin J. Laubach | 2 Nov 2005 18:29
Picon

Re: IP-Filter changes wrt keeping state

|    I recently upgraded my firewall machine from 1.6 to 2.0 and
|  found that something in ip-filter seems to have changed in a
|  rather strange way.

  I did some more experimenting: with the ipf.conf below, I would
expect connections on port 6667 to be blocked on ex0. However, I can
freely traverse the firewall to any host port 6667. So it looks to me
as if the "keep state" does not take the interface into account. I'm
pretty sure this was different in 1.6, am I mistaken...?

	mjl

---
# Note: ex0 = external interface, tlp0 = internal interface
pass in quick on lo0 all
pass out quick on lo0 all

pass in quick from any to any port = 22 keep state

block in on tlp0 from any to any head 10
pass in quick on tlp0 from any to any port = 6667 keep state group 10

block out on ex0 from any to any 
---
Permalink | Reply | 0 comments |
headers
Hauke Fath | 2 Nov 2005 20:05
Picon

Re: IP-Filter changes wrt keeping state

At 14:39 Uhr +0000 2.11.2005, Martin J. Laubach wrote:
>  I recently upgraded my firewall machine from 1.6 to 2.0 and
>found that something in ip-filter seems to have changed in a
>rather strange way.

Apart from the problem in question, 2.0 came with an early 4.x version of
ipfilter that has, erm, "interesting features". I'd recommend upgrading at
least to 2.1, or even tracking netbsd-3, which is what I do on two
filtering routers.

>  I basically have access lists for each interface. On the internal
>one I do
>
>	block in all on internal-IF head 10
>	pass out proto tcp from any to any port = 1234 keep state group 10
>
>  and on the external one
>
>	block out all on external-IF head 20
>	pass out proto tcp from any to 1.2.3.4 port = 1234 keep state group 20
>
>  Under 1.6 this worked fine, restricting the reachable hosts for port
>1234 to 1.2.3.4. Under 2.0, this lets connect to ANY host on port 1234.

Is the rule set supposed to be complete? External has an implicit 'pass in
all', right? And internal an implicit 'pass out all'? Unless you configure
your kernel with IPF_DEFAULT_BLOCK...

I tend to set things up the other way round: Block or pass with state on
incoming packets. But we have >2 interfaces.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin J. Laubach | 2 Nov 2005 21:30
Picon

Re: IP-Filter changes wrt keeping state

| >  I basically have access lists for each interface. On the internal
| >one I do
| >
| >	block in all on internal-IF head 10
| >	pass out proto tcp from any to any port = 1234 keep state group 10
| >
| >  and on the external one
| >
| >	block out all on external-IF head 20
| >	pass out proto tcp from any to 1.2.3.4 port = 1234 keep state group 20
| >
| >  Under 1.6 this worked fine, restricting the reachable hosts for port
| >1234 to 1.2.3.4. Under 2.0, this lets connect to ANY host on port 1234.
| 
| Is the rule set supposed to be complete? External has an implicit 'pass in
| all', right? And internal an implicit 'pass out all'? Unless you configure
| your kernel with IPF_DEFAULT_BLOCK...

  Yes, that's a complete minimal ruleset for reproducing the problem.
I do have a IPF_DEFAULT_BLOCK in place and the kernel is in fact 2.1.

NetBSD fw.emsi.priv.at 2.1 NetBSD 2.1 (CACTUS) #0: Tue Oct 25 17:05:57 CEST 2005 
mjl <at> asparagus.emsi.priv.at:/home/users/mjl/netbsd/cvs/src/sys20/arch/i386/compile/CACTUS i386

  Should I upgrade to netbsd-3 to get a more reasonable ip filter?

	mjl
Permalink | Reply | 0 comments |
headers
mouss | 3 Nov 2005 00:05
Picon
Favicon

Re: IP-Filter changes wrt keeping state

Martin J. Laubach a écrit :

> 
>	block in all on internal-IF head 10
>	pass out proto tcp from any to any port = 1234 keep state group 10
>  
>
Does the last rule really uses "out" as the group defintion or is it a typo?

>  and on the external one
>
>	block out all on external-IF head 20
>	pass out proto tcp from any to 1.2.3.4 port = 1234 keep state group 20
>  
>
so you allow outbound to port 1234 on the internal iface and outbound to 
1.2.3.4 port 1234 on the outside external interface? I fail to see what 
you wanna do.

>
>  Under 1.6 this worked fine, restricting the reachable hosts for port
>1234 to 1.2.3.4. Under 2.0, this lets connect to ANY host on port 1234.
>
>  I'm a bit stumped -- has something dramatic changed or is my ipf.conf
>logic flawed?
>
>	mjl
>
>  
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tomi Nylund | 3 Nov 2005 21:01
Picon
Picon

Where is ipl.h?

Hello,

I'm trying to cross-compile netbsd-2.1 under linux, and after dealing with
groff (see toolchain/31983 and follow-ups), the build now fails with
ipl.h. According to bug reports and tickets, ipl.h should be included in
2.1, but the actual file is NOT inside my source tree (CVS tag
netbsd-2-1).

I grepped the whole src, but only found references to IPL_VERSION, no
#define's anywhere. Am I missing something here, or is ipl.h really AWOL?!

Regards,

Tomi
Permalink | Reply | 1 comment |
headers
Eric Haszlakiewicz | 4 Nov 2005 02:45

Re: Where is ipl.h?

On Thu, Nov 03, 2005 at 10:01:03PM +0200, Tomi Nylund wrote:
> Hello,
> 
> I'm trying to cross-compile netbsd-2.1 under linux, and after dealing with
> groff (see toolchain/31983 and follow-ups), the build now fails with
> ipl.h. According to bug reports and tickets, ipl.h should be included in
> 2.1, but the actual file is NOT inside my source tree (CVS tag
> netbsd-2-1).
> 
> I grepped the whole src, but only found references to IPL_VERSION, no
> #define's anywhere. Am I missing something here, or is ipl.h really AWOL?!

I've got it in .../sys/dist/ipf/netinet/ipl.h

eric
Permalink | Reply | 0 comments |
headers
Tomi Nylund | 4 Nov 2005 21:21
Picon
Picon

Re: Where is ipl.h?

Sigh..

Guess who forgot -d when updating source from 1-6 to 2-1?
Thanks for the tip, sorry for the noise :)

Regards,

Tomi
Permalink | Reply | 0 comments |
headers
Jonathan Stone | 4 Nov 2005 20:43
Picon

A good, cheap, wire-speed PCI-e NIC for NetBSD?


Any recommendations for PCI-e NICs for eventual use with NetBSD?
I'm looking for:

    * Desktop pricing
    * Wire speed Tx and Rx (simultaneously)
    * At least one of: datasheets, existing NetBSD PCI driver
      for related PCI, chip FreeBSD driver.
    * IP/TCP checksum offload
    * TCP Segmentation Offload (Tso, aka Large Send).

Intel "desktop" PCI-e NICs are scheduled to hit market this month; but
aren't shipping quite yet.  I know Reatek has a chip, related to their
existing PCI/cardbus chips but I haven't yet found a NIC with chip.

The broadcom 5721 doesn't have desktop pricing, but neither of the
{net,free}BSD drivers can push the send path above ~90 Mbyte/sec.

I'm left wonedring about the follwoing:
    * D-link DGE-560T, which has some close relative of
      the Sundance/Tamarak MAC. Datasheets (and FreeBSD-4 drivers)
      are allegedly available from the Taiwanese chip vendor;
or

   * The S&K SK-9E22, which is yet another sk/skc combo, of which
     I vaguely heard Thor commenting about compatibiliity issues
     with various variants (Marvell? I forget).
     SysKonnect provides  binary-only FreeBSD-5 drivers, and a
     Linux source driver from which TSO support could be
     reverse-engineered into our sk/skc code.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane