I just noticed that whilst the socket code appears to support
IPV6_TCLASS, we don't document it.
I haven't raised a PR for this issue yet nor have I written a patch.
This came up when I started hacking support for setting IP_TOS into
something else.
cheers
BMS
__
Wes Peters wrote:
I see a number of people have replied to this message offering
solutions of how to accomplish your migration, using a variety of
tools available to you in FreeBSD. I've always found this community
very supportive in this fashion, and I'm glad they've jumped in to
help you in
James Snow wrote:
I'm trying to use link-local for the cross-over interface between a pair
of FreeBSD boxes running pf, pfsync, and CARP. These firewalls will
need to be able to route for the whole of RFC1918, and carving off a
piece of that address space isn't an option.
This seemed to be a pe
[EMAIL PROTECTED] wrote:
At Wed, 20 Feb 2008 18:25:05 +,
Bruce M Simpson wrote:
I just noticed that whilst the socket code appears to support
IPV6_TCLASS, we don't document it.
I haven't raised a PR for this issue yet nor have I written a patch.
Please do both :-)
Paul Schmehl wrote:
--On Thursday, February 21, 2008 11:41:05 -0800 Tony Coon
<[EMAIL PROTECTED]> wrote:
I am looking for a way to flush IP addresses, particularly IPv6, from an
interface and have it repeat the initialization process that the
interface
goes through on boot, including IPv6
I looked at this very briefly.
It's gnarly because in_canforward() is a candidate for inlining and is a
predicate which is being overloaded with different meanings by
ip_forward()/ip_input() and icmp_reflect().
So whilst the fix is most likely a 3 liner, it risks making the code
look crap. W
Eric Anderson wrote:
I guess my biggest question is, why do the IPs .128, .129, .130, .131
appear in the routing tables where they're NOT defined? I don't get it?
You are not seeing forwarding table entries. You are seeing ARP entries
- the LLINFO flag is set (L). This is a legacy behaviour w
Hi,
I had to use a search engine to figure out what the acronym NFC was, and
I assume you mean this:
http://en.wikipedia.org/wiki/Near_Field_Communication
It helps if you give more background information when asking a more
general audience for feedback.
zDen wrote:
1) As the NFC device
+1 on increasing the threshold, 1024 is way too low.
Also consider the folk who depend on the existing behaviour: a
predictable ephemeral port range is useful, if for some reason you need
to apply a NAT policy to that traffic, with no other knowledge about how
the applications you must NAT act
Willem Jan Withagen wrote:
£ukasz Bromirski wrote:
Wouldn't it be a case for use of multicast vs unicast? Hardware
is always better anyway, so why not invest in some switch that
can do unicast/multicast in hardware?
Usefull suggestion, only this is going to be in an overlay cloud where
we do n
Robert Watson wrote:
One of those issues is that we need to demonstrate to ourselves that
exclusive access contention is managed as well with rwlocks as with
sleep mutexes, as these locks would continue to be fairly highly
contended in TCP. The other issue is that rwlocks don't support full
p
Sean C. Farley wrote:
I have noticed that with a Linux-based Netgear DG834G (DSL modem)
frequent pauses (example[1]) between external systems and 7-STABLE
(March 14th). At first, I thought it was ipfilter or ipnat, but I took
those out of the picture by activating telnet on the router and
connec
It has come to my attention that the default configuration of PF in
FreeBSD will block legitimate outgoing IGMP messages.
PF is currently not the default firewall in FreeBSD. Anyone using
multicast in any way, even for link-scope multicasts (224.x.x.x/24),
will be affected by this issue if the
Eugene Grosbein wrote:
On Sat, Mar 29, 2008 at 03:43:44PM -0500, Brooks Davis wrote:
I was using following command in FreeBSD 6.2:
# ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0
In FreeBSD 7.0 I got an error:
# ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0
ifconfig
Hi all,
Just to follow up on my message last week.
If I don't hear further feedback, I am likely to commit code which
allows IP Router Alert options through the pf firewall by default.
For further background read on.
cheers
BMS
The lack of support for allowing the IP Route
Dontcha just hate broken vendor NAT?
Yes, it seems reasonable that SACK is the sacrificial victim.
Considering folk normally configure TCP-MD5 between routers which are
usually directly connected on the same switch, doing away with SACK
should be fine.
Funny, I was staring at that define mom
Hi,
I am doing some protocol testing, and I just saw something very odd on
6.3-RELEASE.
If I try to inject multicast traffic via bpf with fxp, bpf will report
that it went out OK, however it never makes it out onto the wire. I have
ruled out firewalls, switches and other layer 2 behaviour.
Just off the top of my head...
...has anyone run into problems with the scalability of this call?
One of the XORP users needs to create »1000 interfaces in Linux, and I'm
wondering if any FreeBSD users need to create that amount of network
interfaces.
As such the getifaddrs() call is likely t
[EMAIL PROTECTED] wrote:
Hi All,
I am working on implementing MPLS in FreeBSD at the moment. I was wondering if
anyone had some links to any references I could use, or recommend any books I
can use to help me in that. Failing that, I am struggling with trying to work
out how to initialise my
Julian Elischer wrote:
Seen ayame? http://www.ayame.org/
looks like a stalled affort.. things stop in 2002
[greater-than] From what I've read of the code, it seems close to KAME
and BSD style, and could actually get merged. With a little bit more
work, the userland could slot into XORP's B
tmm wrote:
So, can anyone suggest how I can send a limited broadcast (on an
interface that has been initalized with an IP and a subnet)?
Use the IP_ONESBCAST option and send to the network broadcast address
for that subnet. The stack will change it into 255.255.255.255 on
output. See man page
Martin Garon wrote:
I am looking for a FreeBSD release with IGMPv3 and was surprised to find
none.
I know the KAME project added support for IGMPv3. Anyone knows why this was
not imported back into the current sources? I was wondering if it had
anything to do with reliability or rather with busi
Maksim Yevmenkin wrote:
please try the following patch. if there is no objections, i will commit it
beetle# diff -u if_tap.c.orig if_tap.c
--- if_tap.c.orig 2007-04-05 10:58:39.0 -0700
+++ if_tap.c2008-04-14 09:42:42.0 -0700
@@ -404,6 +404,7 @@
struct ifnet
Hi,
I noticed a strange issue with tap(4) and if_bridge(4) where the bridge
seems not to be forwarding frames.
6.3-RELEASE, btw.
I have this setup where I use the two to bootstrap QEMU virtual machines.
Up until now I've been using dhcpd for this. This has only ever worked
right for me if I
Christopher Arnold wrote:
Anyone looing at supporting the netfpga card on FreeBSD?
I would love to do that project myself, my time is scarse right now.
I believe there was some interaction between other XORP members and the
NetFPGA people, although I don't know if this resulted in any outcome.
Ingo Flaschberger wrote:
So we are looking for a tool that inject and verify packet with faked
IPs. We want to generate fake traffic between A-B A-C B-C in both
directions.
The aim is to evaluate the routing capacity of openbgpd/freebsd.
We currently didn't find any tool that fit our needs. D
The following reply was made to PR kern/122839; it has been noted by GNATS.
From: "Bruce M. Simpson" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: kern/122839: [multicast] FreeBSD 7 multicast routing problem
Date: Tue, 22 Apr 200
Julian Elischer wrote:
The interaction with routing daemons is something I don't know
enough about. I need someone who knows routing daemons to tell
how to correctly tweek code that sends routing events.
As long as it doesn't break anything...
I think it is possible that events from a partic
Julian Elischer wrote:
A general purpose OS is a different beast as it has no physical
equivalent of the FIB. It may have multiple routing tables, though, to
I think setrib would be a term less likely to cause confusion then
setfib even though, in the case of your FreeBSD patches, it's really
bo
Julian Elischer wrote:
An interface may however be present in entries from multiple FIBs
in which case the INCOMING packets on that interface need to
be disambiguated with respect to which FIB they belong to.
Yes, there is no way the forwarding code alone can do this.
It should not be expected
Bakul Shah wrote:
1) A packet arrives on an interface. If this interface is
associated with more than one FIB, which FIB does it get
given to?
If you only have a single FIB, there is no issue here.
If you have multiple FIBs, the decision gets made by the classifier.
2) If that decis
Bruce M. Simpson wrote:
Wouldn't it make sense to treat each alias as on a separate
logical interface? Then each logical interface belongs to
exactly one FIB. On input you decide which logical inteface
a packet arrived on by looking at its destination MAC
address. That reduces conf
Julian Elischer wrote:
what's SSM?
Source-specific multicast, where multicast flows (channels) are
identified by both their original source address, and group address.
Multicast addresses have no meaning on their own beyond the scope of a
single link.
I haven't changed any of that.. Basi
John Hay wrote:
The linux guys seems to have multiple fibs (or whatever they call them)
which they can chain together by giving them different priorities. The
effect seems to be that a packet will be matched through the highest
priority fib to the lowest until a route match is found en then is us
Julian Elischer wrote:
OLSR is an overlay network
Nope -- the express intention was that it could be used for basic IP
connectivity, for mobile devices. In OLSR, every node is a potential IP
forwarder unless it explicitly advertises itself as being unwilling to
forward.
and any machine th
John Hay wrote:
You don't need to go to the kernel for this sort of thing unless you
specifically need to implement route policy based on which interface(s)
a packet came in on.
Yes I know that. But in the world of adhoc wireless mesh networking
there are very few non-linux people, so the
Paul wrote:
Is there a list of patches that have been applied to -STABLE since
the -RELEASE ?
I can't seem to find a simple organized list of applied patches
(something similar to linux kernel changelog).
I want to know if anything has been fixed or udpated in the network
area to see if it w
Julian Elischer wrote:
you could implement a whole new protocol family of which there
was a single protocol.. divert.
That's sheer overkill for what Edwin needs to be able to do. We already
have a bunch of apps which use divert sockets in the IPv4 space, why
should the existing semantics chang
Julian Elischer wrote:
actually the divert sockets should really not be in PF_INET
they could deliver both inet and inet6 packets.
the sockaddr that they return (and which needs to be read for divert
to make sense) could be used to distinguish between them.
Good point. I'd forgotten that they w
Oleksandr Samoylyk wrote:
looks like UDP in PPP in GRE
I think so. Should we hope for some progress in this direction in future?
Probably not, unless someone is willing to come up to the table and
commit to writing and maintaining a Netgraph node to demux GRE, although
this is only shuffli
Marius Strobl wrote:
If the system is running the simplest thing in order to identifiy
the PHYs is to check the oui= and model= output of `devinfo -v`.
Otherwise boot verbose and check the OUI and model output of
ukphy(4).
There's a project for someone in there I'm sure.
Linux has mii-tool
Volker wrote:
...
In short my original question better reads as "how do I know the kind of
phy if no driver has been attached". Can one retrieve that information
out of a verbose boot dmesg (from probing messages)?
You can't determine which PHY is in use unless a driver is attached,
because
[EMAIL PROTECTED] wrote:
...
Please email me comments. I'd like to commit this to HEAD soon. It
can't be put into 7 without removing the cluster and mbuf counting,
but I might do that as well if there is interest.
People writing servers are going to find the watermark stuff useful. I'm
th
Rudy wrote:
The CARP in BACKUP is arping... why?
Without looking at the carp code, I can tell you that its addressing
hook is implemented as a pass-through in ether_input(). carps are not
IFT_ETHER, therefore they shouldn't emit gratuitous ARP or otherwise
when an address is configured on o
Hi,
It looks like this patch will cause gratuitous ARP to be queued even
when the interface is not IFF_UP, is this intentional?
Niki Denev wrote:
I think arp_gratuit() needs a better name.
arp_announce() ?
Is if_ethersubr.c:ether_ifattach() good place to register the EVENT hook?
Julian Elischer wrote:
While this is a good idea on it's own, the difference between
what that achieves and what a line discipline achieves is that
a line disciplin is hardware independent and can even be used
on a virtual device.
I was under the impression that the back-end for UART was light w
rihad wrote:
Not sure if this is a worthwhile optimization? FreeBSD 7.0
--- /usr/src/sys/net/if_var.h 2007-12-07 09:46:08.0 +0400
+++ if_var.h2008-05-30 18:10:25.0 +0500
@@ -282,7 +282,8 @@
if (m) {\
if
rihad wrote:
Bruce M. Simpson wrote:
It could save dirtying an L2 data cache line at the expense of taking
a conditional branch,
Whoa, why don't you take it easy on me :) I'm not that much into
kernel (or hardware) programming. It's just that reading Ch. 3 of
TCP/IP Illus
Archimedes S. Gaviola wrote:
To Whom It May Concerned:
Good day! Is there any document or web site that lists all the
standard Request for Comments (RFCs) for all the networking protocols
currently implemented on FreeBSD? This will help users identify what
specific sections of a standard a ce
Victor Hugo Bilouro wrote:
Hi,
I'm in architectural phase of tcptest* development, so, I need
understand every possible test it will need cover, because it would
change tcptest architecture.
Hey, have you seen gnn's PCS toolkit?
http://pcs.sourceforge.net/
I've made a lot of changes to
Victor Hugo Bilouro wrote:
I've made a lot of changes to it; diffs are with him but I can send folk a
copy of my Mercurial repo.
I would appreciate that.
Sent (off-list).
As an example of the new PCS syntax and expect() stuff, I'll forward you
the IGMPv2 test off-list. (Also sent.)
Dalibor Gudzic wrote:
Any pointers for someone that wishes to do it?
http://wiki.freebsd.org/NetworkRFCCompliance
...is one place to start...
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscr
[EMAIL PROTECTED] wrote:
Hello;
I started playing a bit with net/pppd23 and I noticed there are some patches for
FreeBSD-3.0 that were never committed (NetBSD certainly has them). Our pppd(8) is derived
from the "samba" pppd port and should have them if we want to continue updating
it.
E
Peter Jeremy wrote:
Note that one downside of your carpdev patches is that (AFAIK) it is
no longer possible to identify which host sent the packet: The source
and destination MAC addresses, as well as the destination IP address
are all defined by CARP. Once you change the source IP address to be
Marc Lörner wrote:
..
First of all I have the problam of misalignment of th_off. Because in this way
always 4 bytes are read and the the bits of th_off are replaced. Then the 4
bytes are written back.
But should (th_x and th_off) not only be 1 byte in whole -> only read and
write 1 byte?
Marc Lörner wrote:
th_x2 and th_off are created as a bitfield. But C-Standard says that bitfields
are accessed as integers => 4-bytes
On itanium integers are read with ld4-command but the address of th_x2/th_off
may not be aligned to 4-bytes => we get an unaligned reference fault.
If we'd ch
Archimedes S. Gaviola wrote:
Hi! I have just read from the FreeBSD-7.0 release notes
http://www.freebsd.org/releases/7.0R/relnotes.html that the mrouted
multicast routing protocol (DVMRP implementation) has been removed
from the base system. I want to know what multicast routing protocol
will
Marc Lörner wrote:
off0 is 0x14 => no problem with that
but address of ip is 0xe00021c8706e => not correct aligned to 32-bits
Can anyone tell me, where ip is allocated, so I can do a little bit more
research?
It really depends on the context! That's a very wide ranging question.
It de
Archimedes S. Gaviola wrote:
...if ever there's a way to implement IP multicasting with PIM-SM and
or PIM-DM in the FreeBSD base system, how big is the work would be?
What are the things that needs to be considered if we are going to
implement PIM-SM and or PIM-DM to the current FreeBSD networ
Paul wrote:
Get these with GRE tunnel on
FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT
2008 :/usr/obj/usr/src/sys/ROUTER amd64
But do not get them with 7.0-RELEASE
Any ideas what changed? :) Wish there was some sort of changelog..
# of messages per second seems consis
Robert Watson wrote:
An FYI on the state of things here: in the last month, John has
updated a number of device drivers to be MPSAFE, and the USB work
remains in-flight. I'm holding fire a bit on disabling IFF_NEEDSGIANT
while things settle and I catch up on driver state, and will likely
sen
Robin Sommer wrote:
Hi all,
we're seeing some strange effects with our libpcap-based application
(the Bro network intrusion detection system) on a FreeBSD 7-RELEASE
system. As the application has always been running fine on 6.x,
we're wondering whether this might be triggered by any of the
chang
[EMAIL PROTECTED] wrote:
The only thing i can think of is that it's the UDP checksum,
residing beyond hlen, which is overwritten somewhere in the
call to if_simloop -- in which case perhaps a better fix is
to m_pullup() the udp header as well ?
It is the checksum that gets trashed, yes.
..
[EMAIL PROTECTED] wrote:
I gather you mean that a fast link on which also we're looping back
the packet will be an issue? Since this packet is only going into the
simloop() routine.
We end up calling if_simloop() from a few "interesting" places, in
particular the kernel PIM packet handler.
[EMAIL PROTECTED] wrote:
Somehow the data that the device needs to do the proper checksum
offload is getting trashed here. Now, since it's clear we need a
writable packet structure so that we don't trash the original, I'm
wondering if the m_pullup() will be sufficient.
If it's serious enoug
M. Warner Losh wrote:
I've been shepherding this patch in my p4 tree for a long time. It
removes the obsolete support for other systems in if_spppsubr.c. Is
there a reason I shouldn't commit this?
Looks fine to me.
___
freebsd-net@freebsd.org mai
Bjoern A. Zeeb wrote:
Hi,
I have a patch, that was inspired by work from Y!, to do porper
IPv4 source address selection for unbound sockets (with multi-IP
jails).
Hi,
This kinda overlaps with some other ideas I'd like to see go in. It
looks good and if it's already been tested, it should pro
Debarshi Ray wrote:
I am implementing a library/utility which basically encompasses the
features of the traditional route utilities and those of newer tools
(like ip from iproute2), which are mostly specific to a particular
kernel. The overpowering objective is to make the library/utility work
un
Debarshi Ray wrote:
...
I was going through the FreeBSD and NetBSD documentation and the
FreeBSD sources of netstat and route. I was suprised to see that while
NetBSD's route implementation has a 'show' command, FreeBSD does not
offer any such thing. Moreover it seems that one can not read the
en
Debarshi Ray wrote:
Why don't you just use XORP's FEA code?
It already does all this under a BSD-type license.
I was not aware of it. What does it do? Is it portable across other
OSes or is it *BSD specific?
XORP's FEA process is responsible for talking to the underlying
forwarding p
Luigi Rizzo wrote:
do you know if any of the *BSD kernels implements some good mechanism
to access a dynamic kernel data structure (e.g. the routing tree/trie,
or even a list or hash table) without the flaws of the two approaches
i indicate above ?
Hahaha. I ran into an isomorphic problem wi
Whenever I call this sysctl, I get an errno of EPROGNOTAVAIL from sysctl():
»···name[0] = CTL_NET;
»···name[1] = PF_LINK;
»···name[2] = NETLINK_GENERIC;
»···name[3] = IFMIB_IFDATA;
»···name[4] = ifindex;
»···name[5] = IFDATA_DRIVERNAME;
»···len = IFNAMSIZ;
»···if
Bruce M Simpson wrote:
It looks like the switch..case in that path could be fubar'd by the
compiler as there are not break statements for each distinct case
label, could this be due to gcc friendly fire?
Possibly false alarm or PEBKAC, I wasn't checking return values right in
Debarshi Ray wrote:
...
By the way, would you want someone to implement 'show' support for
FreeBSD's route implementation? I can give it a go now. :-)
For sure, we'd be very happy to see a patch like that.
Many thanks
BMS
___
freebsd-net@freebsd.o
[EMAIL PROTECTED] wrote:
Old Synopsis: icmp socket receives icmp replies not owned by the process.
New Synopsis: [icmp]: icmp socket receives icmp replies not owned by the
process.
This PR is bogus because:
ICMP has no concept of datagrams being "owned" by a process. There is no
field in t
The following reply was made to PR kern/127528; it has been noted by GNATS.
From: "Bruce M. Simpson" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: freebsd-net@FreeBSD.org, [EMAIL PROTECTED]
Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned
by the pr
Chris Buechler wrote:
This PR is bogus because:
ICMP has no concept of datagrams being "owned" by a process. There is
no field in the ICMP protocol which differentiates ICMP "sessions" on
a per-process basis, and this is because ICMP has no concept of
"sessions" -- ICMP messages are directed
Hi,
I looked at ACE years and years ago (~1997) when Doug Schmidt was first
promoting the ideas behind it. The whole Reactor/Proactor split pretty
much hangs on the event dispatch which your particular OS supports.
The key observation is whether your target OS implements events in an
edge-tr
Hi,
I agree with the intent of the change that IPv4 and IPv6 input queues
should have a tunable queue length. However, the change provided is
going to make the definition of IFQ_MAXLEN global and dependent upon a
variable.
[EMAIL PROTECTED] wrote:
Hi,
It turns out that the last time anyone
[EMAIL PROTECTED] wrote:
...
I found no occurrences of the above in our code base. I used cscope
to search all of src/sys. Are you aware of any occurrences of this?
I have been using IFQ_MAXLEN to size buffer queues internal to some
IGMPv3 stuff.
I don't feel comfortable with a change w
Giulio Ferro wrote:
There are no messages in the logs, and no interface has been
touched. Anyway, since there are a lot of routes and only one
gets deleted I don't think it depends on interface changing
(it would delete them all, wouldn't it?)
Normally static routes only get touched if the st
Hi Ryan,
Did you initialize the .pr_init member of struct protosw for MPLS?
AFAIK, MPLS does not use an outer IP header, so adding a struct
ipprotosw won't work; they are similar structs however.
cheers
BMS
___
freebsd-net@freebsd.org mailing list
h
Yony Yossef wrote:
Hi All,
I'm trying to manually build an mbuf chain with clusters in various sizes.
I'm doing it using the MGETHDR and MEXTADD macros, it works fine.
Now I'm looking for the simplest way to free an mbuf cluster, since I want
to free the clusters seperately. This function will b
Hi,
I have been trying to get FreeBSD onto the Freecom FSG3 Storage Gateway.
It is an xScale based ARM system.
Whilst the npe(4) driver appears to attach, the PHY does not. It is a
Realtel RTL8305SB switch chip in dual miibus mode. Unfortunately the
RTL8305SB does not have ID registers. The RT
Sepherosa Ziehau wrote:
Are you sure you could read from BMSR? Return invalid value from BMSR
is the usual cause of miibus attaching/probing failure. For ID1/ID2
reading, you could just fake some values in npe(4)'s miibus_readreg
implementation.
Thanks for the tip (from you and Pyun). I ha
On Thu, Mar 16, 2006 at 07:35:20PM +0100, Bart Van Kerckhove wrote:
> Is this by design, or just lack of time/interest?
> If anyone feels up to the task of fixing/implementing what's needed to make
> this work, we'd be happy to sponsor its development.
This is a collision between the connected ro
On Thu, Mar 16, 2006 at 10:36:20PM +0100, Bart Van Kerckhove wrote:
> ECMP was indeed one of the features i was looking for at that time, which i
> found to be impossible.
> I just don't like the idea of moving towards another platform just for this
> reason, since I'm very happy with freebsd's p
On Fri, Mar 17, 2006 at 02:00:28PM -0800, Kan Cai wrote:
> I wonder if this is true that sensing function is missing? If yes, is it
> supposed to be implemented in the driver or net80211 layer? Thanks in
> advance!
It's a function of the 802.11 hardware. I assume you're describing the
CSMA/CA
On Mon, Mar 20, 2006 at 12:08:35PM -1000, Dave Cornejo wrote:
> In summary it's a piece missing for FreeBSD to implement the function
> of the Linux socket option SO_BINDTODEVICE, which forces packets
> transmitted on the socket to be sent on the bound device.
I'm currently out of commission with
On Tue, Mar 21, 2006 at 04:15:44AM +0100, Sten Daniel Sørsdal wrote:
> Our first assumption was that adding DF to UDP would solve it, and it
> does in our small tests, but it has a noticable negative effect on the
> network.
Sounds like you need to implement Path MTU Discovery in userland for you
On Wed, Mar 22, 2006 at 04:17:23PM -0600, Matthew Grooms wrote:
> If you are interested in using NAT-T, you should have a look at
> Yvans kernel patch which offers everything but transport
> pre-fragmentation support ...
This looks cool. This looks very, very cool.
Now if only I had free t
On Thu, Mar 30, 2006 at 04:57:42PM -0500, Mikhail Teterin wrote:
> Is there any way to create/alter such a pipe from a C-program without using
> system("ipfw ")?
XORP has a module for IPFW2 which micro-assembles IPFW2 instruction
sequences on the fly from a relatively simple filtering rule re
On Sat, Apr 01, 2006 at 12:28:13AM +0200, VANHULLEBUS Yvan wrote:
> 2) use enc0 support, which is actually pr kern/94829, and which should
>be included soon in kernel.
Oh god! Not another ifnet! NoOO!!
*runs away*
___
freebsd-net@freebsd.org
On Thu, Apr 06, 2006 at 07:36:52PM -0500, Amit Mondal wrote:
> I am a newbie to freeBSD. I am trying to modify freeBSD tcp for some
> security ehancement. Could anyone pls point me to how/where to start or any
> suitable material/tutorial to start with.
The code.
If explanations in natural langua
On Mon, Apr 10, 2006 at 05:41:22PM +0100, Joe Holden wrote:
> Does anyone know if the above card is supported yet, or if it is
> planned? In particular, i'm interested in getting a Zoom 5506 PCI Card
> working under Freebsd, which uses this chipset.
The only ADSL PCI card I know of that Fr
On Mon, Apr 17, 2006 at 04:44:38PM -1000, Dave Cornejo wrote:
> So the question is whether these cards, regardless of their affect on
> throughput, increase usable CPU cycles? I have several Soekris 1401
> cards and am wondering if there would be any point to putting them
> into some machines that
A user recently reported a problem with running into IP_MAX_MEMBERSHIPS
on a system running FreeBSD with IPv4 forwarding enabled, and running
the OSPF routing protocol.
I have been investigating how to address this problem.
Background:
A raw socket was exceeding the permitted number of group me
On Tue, May 09, 2006 at 01:28:01PM +0100, Bruce M Simpson wrote:
> A user recently reported a problem with running into IP_MAX_MEMBERSHIPS
> on a system running FreeBSD with IPv4 forwarding enabled, and running
> the OSPF routing protocol.
More background. People may be wondering why thi
On Thu, May 11, 2006 at 11:12:29PM -0400, Stephen Clark wrote:
> >I'm loosely of the opinion that the membership array should be
> >variable length, and that we should default it to 20, but have a
> >significantly larger maximum. It's not horribly efficient, but also
> >wouldn't be so particula
Hello,
On Fri, May 12, 2006 at 02:12:27PM +0100, Bruce M Simpson wrote:
> Therefore, joining the same group 20 times on different interfaces
> would exceed IP_MAX_MEMBERSHIPS.
> Fixing this in any way would still break the ip_mroute_kmod ABI and
> as such is a HEAD change.
A patch fo
101 - 200 of 613 matches
Mail list logo
