Re: Filtering question: checking for many addresses in a single rule?

Jos Backus wrote: If one has many (thousands) hosts/addresses that the same filter action needs to be taken for, what would be the most efficient way to implement this using, say, ipfw or ipfilter? I'm referring to the ability to create/load a large hashed set of addresses and a way to refer to the

Filtering question: checking for many addresses in a single rule?

If one has many (thousands) hosts/addresses that the same filter action needs to be taken for, what would be the most efficient way to implement this using, say, ipfw or ipfilter? I'm referring to the ability to create/load a large hashed set of addresses and a way to refer to the set in a filter r

Re: Remote Boot

Hi Atanu, you're right. I've recompiled the diskless kernel and now it's working fine. I also would like to thank everybody who took time to help me with this issue. Thank you all! Best regards, Tobias. Atanu Ghosh wrote: > > >From my notes when trying to get diskless booting working: > > We

Re: setsockopt IP_ADD_MEMBERSHIP not honored

Sounds good to me :) At the very least, this would improve the performance of the mDNSResponder. mDNSResponder has some additional code to get the interface the packet was received on so it can filter out the packet if it wasn't received on the interface that socket is bound to/associated with

Re: Help Broadcasting a UDP packet on the LAN:URGENT

Bruce M Simpson wrote pointing out AODV (RFC 3561) as an example of a routing protocol needing to send to 255.255.255.255 on multiple interfaces at once. I withdraw my scorn of kernel mods to facilitate this. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract o

Re: natd+ipfw+trafic shaping

Remember that rules checked twice if not defined "in" or "out". Look at net.inet.ip.fw.one_pass sysctl > Hi all, > can anyone explane why this rules doesn't work: > > rl0 EXTINF > rl1 INTINF > > add 1000 divert 8668 ip from any to any via rl0 > add 1200 allow ip from any to any via lo0 > add 130

Re: setsockopt IP_ADD_MEMBERSHIP not honored

On Tuesday, October 21, 2003, at 12:59PM, Joshua Graessley wrote: On Oct 21, 2003, at 12:28 PM, William A.Carrel wrote: I have two such sockets set up, one on each of the interfaces I'm interested in. The problem is that a packet that comes in on one interface winds up in the receive queue for

Re: setsockopt IP_ADD_MEMBERSHIP not honored

This is "by design". When you perform IP_ADD_MEMBERSHIP, it assures you that the interface you've selected will receive packets destined for the multicast address you specify. It will deal with any IGMP traffic necessary for joining the group. When a packet is received on any interface, the pac

Re: SACK?

On Tue, Oct 21, 2003 at 03:04:11PM -0400, Garrett Wollman wrote: > < said: > > > Are there any plans to incorporate SACK in FreeBSD? > > We plan to add SACK to FreeBSD whan a compatible implementation is > available. in my book this reads as "we have no plans" :) And to follow up on the topic,

Re: Remote Boot

On Tue, Oct 21, 2003 at 03:07:32PM -0400, Mikel King wrote: > Just curious would it be better to add a rule to allowe 67 & 68 (tcp & > udp) in from the dhcp server instead of leaving the box all open? > Understand I've never attempted this booting a diskless, but it seems > like something worth

setsockopt IP_ADD_MEMBERSHIP not honored

I've been working on a miniature multicast routing program and am encountering some troubles with getting setsockopt(2) to create the right behavior. I pass in setsockopt(the_sock, IP_ADD_MEMBERSHIP, &the_mreq); with the_mreq having in_addr's for the link-local multicast channel I'm interested

Re: Remote Boot

Just curious would it be better to add a rule to allowe 67 & 68 (tcp & udp) in from the dhcp server instead of leaving the box all open? Understand I've never attempted this booting a diskless, but it seems like something worth trying Atanu Ghosh wrote: From my notes when trying to get dis

SACK?

< said: > Are there any plans to incorporate SACK in FreeBSD? We plan to add SACK to FreeBSD whan a compatible implementation is available. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscr

Re: SACK?

In reply to Mark Allman <[EMAIL PROTECTED]> : > > Hi folks! > > Are there any plans to incorporate SACK in FreeBSD? It'd sure be > handy for me to have (I prefer the *BSDs, and, alas, they are the > only remaining SACK-less systems worth mentioning). I think there > are research implementati

Re: Remote Boot

>From my notes when trying to get diskless booting working: We usually have the firewall and dummynet enabled in our configs. The default is therefore not to allow any packets in or out. This stops the DHCP packets leaving a diskless kernel. Override this default. options IPFIREWALL_DE

SACK?

Hi folks! Are there any plans to incorporate SACK in FreeBSD? It'd sure be handy for me to have (I prefer the *BSDs, and, alas, they are the only remaining SACK-less systems worth mentioning). I think there are research implementations that could be used as a basis (Luigi Rizzo did one, I thin

natd+ipfw+trafic shaping

Hi all, can anyone explane why this rules doesn't work: rl0 EXTINF rl1 INTINF add 1000 divert 8668 ip from any to any via rl0 add 1200 allow ip from any to any via lo0 add 1300 deny ip from any to 127.0.0.1/8 add 1400 deny ip from 127.0.0.1/8 to any add 1500 check-state add 1550 allow icmp from a

Re: Help Broadcasting a UDP packet on the LAN:URGENT

On Mon, Oct 20, 2003 at 08:42:50PM -0400, Barney Wolff wrote: > And of course any application that actually needs to send such a packet > on every interface can loop through the interfaces, using the technique > on each one, getting the reply, removing the 255.0.0.0/8 alias, and > moving on to the