Hi,
For a while now I have had a patch available to teach olsrd to use
IP_ONESBCAST instead of using libnet/bpf just to send broadcast
datagrams in FreeBSD, which has had IP_ONESBCAST for a few years now.
If anyone is using olsrd on FreeBSD I would greatly appreciate testing
and feedback
Yar Tikhiy wrote:
Quagga still uses it, too, if its configure script detects FreeBSD
or NetBSD. I'm afraid it was me who submitted the patch to the
Quagga folks when I'd found that Quagga's ospfd couldn't handle
unnumbered P2P interfaces in FreeBSD because their local IPs weren't
unique.
Rajkumar S wrote:
Hi,
I have a low cost 128kbps and a high cost 512 kbps link to internet.
Is it possible to do a spillover routing so that the high cost link
is used only when the low cost link is, say, used more than 80%.
This feature is almost certainly not going to be present in the base
I am very close to merging support for RFC 3678 to -CURRENT. I will
make a patch available before I commit.
The only userland consumer in the tree which is likely to be affected by
the removal of ip_multicast_if() from the kernel is routed, which I will
update to use the new
I'm all for this in principle. I believe that the case for FAST_IPSEC
over KAME IPSEC is fairly clear for those of us who have read the USENIX
paper. Qualitatively speaking I can say FAST_IPSEC has been more
pleasant to work with when introducing the TCP-MD5 support.
I will try to look at the
I can only speak about IPv4 router alert in detail; we do nothing with
IPv4 RA nor would it appear that it would make any real difference in
performance given how the code is laid out. RSVP packets should be
passed verbatim to userland from ip_input() via rip_input() there.
I think your IPv6
Da Rock wrote:
So I could use some guidance as to what I can do to rectifiy this
problem. I have 2 goals:
1. setup iwi to start on boot, and attach to my ap whenever its in range.
2. make sure iwi stays connected without manually monitoring it.
3. prioritise my routes via the rl0 and iwi if's
For what it's worth, the code I wrote for XORP is only for IPFW2, and
uses its tables feature to atomically transcribe XORP rulesets to IPFW
ones before swapping them in.
Regards,
BMS
___
freebsd-net@freebsd.org mailing list
Mike Makonnen wrote:
I would
especially like feedback from folks more familiar with IPv6. One
gotcha I've noticed is that if you boot with ipv6_enable turned
off, then try to start IPv6 on an interface later on, it doesn't
work because none of the interfaces (except lo0) has a link-local
address
Zhu Yan wrote:
When I send the broadcast in FreeBSD with address 255.255.255.255, the
packet can not be received by other OS.
FreeBSD applications need to use the IP_ONESBCAST option to send
all-ones broadcasts. See the ip(4) man page.
Regards,
BMS
Andrea Venturoli wrote:
Jordan Gordeev wrote:
The only load balancing that CARP supports, to my knowledge, is ARP
level load balancing. From carp(4):
The ARP load balancing has some limitations. First, ARP balancing only
works on the local network segment. It cannot balance traffic that
Synopsis: A new protocol family, PF_IPOPTION, to handle IP options at socket
interface
State-Changed-From-To: suspended-closed
State-Changed-By: bms
State-Changed-When: Mon Mar 26 14:36:38 UTC 2007
State-Changed-Why:
It is unlikely this code will ever be committed.
Reasons:
1) This information
Cristian KLEIN wrote:
Hello everybody,
I am new to FreeBSD kernel hacking, so please excuse my perhaps stupid
questions.
I would like to add key support to gre(4). I have already been able to
use gre(4) with a hardcoded key. The single thing remaining to do is to
transfer the key from
Sam Wun wrote:
Hi,
Is there any MPLS implementation for FreeBSD?
I found a port ayame mpls for netbsd, but the last implementation was
dated
back to 2003, seems very old.
There is NISTswitch, but it is most likely very bit-rotted by now.
I would suggest helping Anihudda Bodhra out on the
I have a patch attached to http://wiki.freebsd.org/Networking to
rate-limit ICMP which is generated by the forwarding path.
It would be useful to find out if this offers symptomatic relief in this
situation, although as Chuck points out, it is most likely being caused
by a routing loop.
Hi,
I propose that we merge the RFC3678 advanced multicast APIs. Doing so
gets us closer to IGMPv3 and SSM. I would greatly appreciate suggestions
about how to deal with the include header issue below.
I have already started merging the basic definitions into p4 branch
bms_netdev.
Hi,
I plan to get rid of the ugly little ip_multicast_if() hack in the IP
stack.=
Before I do, is anyone actually using this?
RFC 3678 specifies a protocol independent API for socket group
memberships which allow joins on interfaces referenced by index. This is
intended to support IGMPv3
Eugene Grosbein wrote:
I recall that routed and ripd used to utilize something similar
long time ago. I'm not sure if they have switched to another API.
You're right -- this would break routed on point-to-point interfaces.
They didn't, unless it was updated at the upstream, i.e.
Hi,
A patch against -CURRENT is now available:
http://people.freebsd.org/~bms/dump/multi_refcounting.diff
This is a fairly sweeping architectural change which should resolve
memory leaks and potential panics with the network stack as a whole, to
better support interface detach at runtime.
Ignacio Rey wrote:
...
The question is: Have calls to these functions been wrapped? or are they
simply not used in this context?
splx() and friends have been no-ops since FreeBSD 5.x was branched.
Synchronization is now done using other mechanisms such as mutexes and
spin locks. See the new
Kevin Lahey wrote:
The boxes were running FreeBSD-6.1, but I can't really vouch for the
particular kernel configuration. It could well be that the problem is
with the loose nut behind the wheel, rather than with FreeBSD. :-)
I believe PMTU measurements may only be relied upon for active
Andre Oppermann wrote:
http://people.freebsd.org/~bms/dump/multi_refcounting.diff
Patch looks good. :-)
Committed, with some changes.
Regards,
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To
I have just committed reference counting for multicast structures in p4.
Change list number is 116036.
This should fix the problems with pfsync and carp since the scalability
fixes for IPv4 multicast last September. A further cumulative fix for
pfsync is present in this branch.
Basic
The change itself is very simple;
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in.c.diff?r1=1.95r2=1.96
This change is necessary before IPv4 address scope and source selection
policy may be implemented.
Does anyone see any potential problems with this? It is possible that
there
Anton Yuzhaninov wrote:
Thursday, March 15, 2007, 7:30:54 PM, Andre Oppermann wrote:
AO IMO when configuring a interface with an IP address and network it should
AO kick out previous host and/or network routes matching it. Unless those
AO are from locally configured interfaces, then it should
Yar Tikhiy wrote:
Hi folks,
Quite a while ago I noticed that our ioctl handlers get the ioctl
command via u_long, but ether_ioctl()'s command argument is int.
This disarray dates back to 1998, when ioctl functions started to
take u_long as the command, but ether_ioctl() was never fixed.
Hi,
Frank Behrens wrote:
If we have no possibility to mark the interface as UP for the non-root process the
net.link.tap.user_open=1 is useless, because we can not transmit any packets. With the
patch the interface goes UP only, when the administrator allowed non-root user access.
The
Aniruddha Bohra wrote:
Hi,
The ifnet manpage contains entries for the following routines which do
not exist in the ifnet struct.
committed, thanks!
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To
Gleb Smirnoff wrote:
AFAIK, the problem needs a more generic approach. I see two approaches.
1) Introduce RTM_CHANGEADD, a command that will forcibly add route,
deleting all conflicting ones. Use this command in in_addprefix().
2) In rt_flags field we still have several extra bits. We can use
Gleb Smirnoff wrote:
I was afraid that this would raise an argument on multipath routing. Let's
temporary do not speak about multipath but just decide what is the correct
way to remove conflicting routes when we are assigning an IP prefix to a
local interface?
My suggestion is to take the
Eygene Ryabinkin wrote:
I tried to understand this, because Bruce already gave me a patch,
but I am a bit stupid: I do not see how M_PROMISC that is cleared
unconditionally before BRIDGE_INPUT will help us to identify the
right interface. As I see now, the BRIDGE_INPUT is called once from
Rashid N. Achilov wrote:
TightVNC or TridiaVNC. But encryption and file transmission will not available
with these VNC's and UltraVNC at another end
JFYI:
I have heard corporate IT people who mostly work with Windows discuss
UltraVNC. I don't see a port for it. It is on SourceForge so
Hi,
Eygene Ryabinkin wrote:
Speaking about vlan problems: the original problem is to do something
with VLAN interfaces only because they are sharing the MAC of their
physical parent. The problem itself is not VLAN-specific -- if there
will be two physical interfaces with the same MACs and they
Eygene Ryabinkin wrote:
This is a different point. The bridge wants to know about bridge
members MACs just because it should catch the packets that are
destined to the bridge members. It is the only way for an L2 thing
that is operating in the promiscious mode.
Correct.
For our case (when
Yar Tikhiy wrote:
Guys, excuse me, but I still fail to see how the case of VLANs'
sharing a single MAC differs from the case of several physical
interfaces with the same MAC from the POV of a bridge. A bridge
can have no own MAC addresses at all, it plays with foreign MAC
addresses only.
Frank Behrens wrote:
How does tun(4) handle this? tun(4) is also set to down, when closed. It is not set to up, when
ist is opened, but when an address is assigned by the user process. This is fine, because it
needs always an ip address. tap(4) as layer 2 tunnel device does not need an ip
Alexandru Arion wrote:
Thanks for both suggestions. Since I'll support version 5.4 and up, this
leaves me to using the workaround implied by calling accept and checking
the returned value, for now.
Erm. It looks like it's implemented in 5.4 as well, although you might
have mentioned in your
Vlad GALU wrote:
Erm. It looks like it's implemented in 5.4 as well, although you might
have mentioned in your original mail you were working with a legacy
version of FreeBSD. :^)
http://fxr.watson.org/fxr/ident?v=RELENG54i=SO_ACCEPTCONN
Manpage diff attached.
Mailman ate your homework.
Bruce M. Simpson wrote:
Manpage diff attached.
Mailman ate your homework. :/
My bad. Committed.
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Alexandru Arion wrote:
Tried it on fresh install of 5.4: compiled the source locally, run, got
error Protocol not available. Same code works on Linux.
By replacing SO_ACCEPTCONN with SO_REUSEADDR, or any other option that
appears in the manual page for 5.4, the program works correctly.
Bruce,
Bruce M. Simpson wrote:
I have just committed a change in bms_netdev which enforces strict
and better defined semantics for the IP_SENDSRCADDR option in
udp_output().
I have just committed this change in -CURRENT.
After testing it with 'ipbroadcast', it looks good apart from sockets
which
Bruce M. Simpson wrote:
Dealing with dhclient is a separate issue -- here, something like
IP_SENDIF needs to be introduced, as we are truly in an 'ip
unnumbered' situation -- ie the ifnet MAY not yet have been assigned
an IPv4 address at all, and IP_SENDSRCADDR implies that you are source
Alexandru Arion wrote:
Is there an equivalent in FreeBSD to the SO_ACCEPTCONN option for
getsockopt(), available in Linux? It doesn't actually has to be an
option for getsockopt(), just a way to determine if a socket has been
marked to accept connections with listen().
SO_ACCEPTCONN appears
Yar Tikhiy wrote:
My proposed check for IFF_DRV_RUNNING is by no means a priority
task. I can add it by myself after you finish your great current
project regarding ether_input() and friends.
Just committed in p4:
//depot/user/bms/netdev/sys/net/if_ethersubr.c#6 -
Eygene Ryabinkin wrote:
I am awfully sorry, but you're seem to be mistaken:
Thanks for clarifying this. That'll be because I didn't read if_bridge
that far. ;^) In my original message I was just looking at if_ethersubr.c.
I need to make sure any changes which are made to if_bridge to deal
Julian Elischer wrote:
When we added netgraph we split both the input and output parts
so that they would provide 'natural' entrypoints for a bridge.
Consider where a bridge wants to put packets.
In bms_netdev, bridge_input() is entered directly from ether_input(). It
may potentially re-enter,
Eygene Ryabinkin wrote:
Will try to understand if it will cure my problem, thanks!
Attaching my patch, just in case if freebsd gnats will be down ;))
Thanks for this. It looks like Andrew may be in a better position to say
if this fix should go in or not.
It is possible that if bridge
Hi,
Thanks for your reply.
Yar Tikhiy wrote:
My concern is that, with possible callers of ether_input() being
not really *from* but *on behalf* of the interface, e.g., in Netgraph,
IFF_DRV_RUNNING can be a way for the interface driver to tell us:
I'm not ready yet, so don't believe anyone who
Hi,
Eygene Ryabinkin wrote:
Sure, I can test it, but then I need to know what problems are cured
by your patch, or I just should watch if it will not break something.
My concern is that I want to make sure that all these changes to the
ether_input path work OK together.
The M_PROMISC
Synopsis: [rpc] rpc.statd(8) conflict with cups over tcp and udp ports 631
Responsible-Changed-From-To: bms-freebsd-net
Responsible-Changed-By: bms
Responsible-Changed-When: Sun Mar 4 15:03:40 UTC 2007
Responsible-Changed-Why:
Someone else with Copious Free Time can do this -- not a priority for
Synopsis: [rpc.lockd] rpc.lockd conflict with cups over udp ports 631
Responsible-Changed-From-To: bms-freebsd-net
Responsible-Changed-By: bms
Responsible-Changed-When: Sun Mar 4 15:04:14 UTC 2007
Responsible-Changed-Why:
Someone else with Copious Free Time can do this -- not a priority for me.
Hello,
Thanks to andre making a start on this, I have managed to get the
IP_SENDIF option implemented today in p4 bms_netdev. Here's a patch
against -CURRENT:
http://people.freebsd.org/~bms/dump/sendif-20070304.diff
For those who are new to this work:
IP_SENDIF is broadly an analogue of
Yar Tikhiy wrote:
We shouldn't cache route pointers anywhere anymore. It has been completely
removed from the PCBs and things like gif and others.
Sounds like a good way to go, too! :-) Thanks!
gre(4) does very funky things with the route it caches to the tunnel
endpoint. Someone(tm)
Hi,
I haven't seen your patch, can you point me at it off-list? Thanks.
Eygene Ryabinkin wrote:
I traced the current if_bridge.c behaviour to the NetBSD's if_bridge.c
1.9. This was the first version in that the firewall hooks were
introduced. And the assumtion that the MAC identifies the
Yar Tikhiy wrote:
Now I see your point, thanks! Well, at least in theory, the driver
shouldn't call ether_input() if the interface isn't running. OTOH,
the interface shouldn't be getting traffic if it's !UP. However,
I suspect that not all drivers handle IFF_UP fully or even can do
it at all
Yar Tikhiy wrote:
In fact, there two independent flags indicating interface's readiness:
IFF_UP and IFF_DRV_RUNNING. The former is controlled by the admin
and the latter, by the driver. E.g., an interface can be UP but
not really ready to operate due to h/w reasons, or vice versa.
Perhaps we
Hello all,
I would like to announce an updated version of the 802.1p input patch,
available at:
http://people.freebsd.org/~bms/dump/latest-8021p.diff
I have cut down the original scope of the patch. I previously ran into
problems when I tried to move VLAN tag input and output processing
During testing of M_PROMISC I noticed a couple of issues with our CARP.
1. carp doesn't seem to maintain input/output statistics on its ifnet.
2. carp doesn't seem to detect that the underlying route to the subnet
its address is exposed on changed to another interface.
Are these conditions
Bruce M Simpson wrote:
Much network code needs to know if the mbuf it is looking at is using
a cluster. I propose putting M_HASCL() in sys/mbuf.h. I realise this
is a style change, however, it seems to be a very common idiom.
I sent this, then I looked at NetBSD, having caught a glimpse
Bruce M Simpson wrote:
Hello,
In preparation for tightening up our handling of INADDR_BROADCAST
sends, I ran some brief tests today on the network stack with the
attached test code.
I found some inconsistencies when run against 6.2-RELEASE;
1. IP_ONESBCAST breaks if SO_DONTROUTE
Andre Oppermann wrote:
I have some WIP here too. I'll send it to you later this afternoon.
Thanks, I look forward to seeing it, re Issue #2 IP_SENDSRCADDR.
Dealing with dhclient is a separate issue -- here, something like
IP_SENDIF needs to be introduced, as we are truly in an 'ip
Anton Yuzhaninov wrote:
RE It works, but only if you use send() instead of write().
RE Alternatively, you can control the behavior on a per
RE message basis, by passing the MSG_NOSIGNAL in the flags
RE argument to the send() call (without having to set a
RE socket option).
Thanks, with send()
Anton Yuzhaninov wrote:
Thanks, with send() it works fine.
I think it should be documented in setsockopt(2).
Try this patch. The comment doesn't reflect what the code does. SIGPIPE
may actually be getting queued twice in your case. It is most likely
that the process's main thread wasn't
Anton Yuzhaninov wrote:
Works for me.
Committed, thanks for finding this bug.
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
N.J. Mann wrote:
Could this be why mail from cron doesn't work for me in 6.2? I got as
far as finding that cron receives a SIGPIPE while sending the mail
message to sendmail, but never worked out why. I ended up hacking cron
to ignore SIGPIPE and then ENOTIME to investigate further.
LI Xin wrote:
Hi,
If no one objects this change, I will commit it?
No objection here.
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Much network code needs to know if the mbuf it is looking at is using a
cluster. I propose putting M_HASCL() in sys/mbuf.h. I realise this is a
style change, however, it seems to be a very common idiom.
Places this macro is currently defined and used directly:
netinet/ip_mroute.c
Luigi Rizzo wrote:
partly off topic, but maybe someone migth find this interesting
given that the device can do vlan tag insertion/removal,
so it can be used to provide additional fan-in/fan-out
to freebsd-based routers in not too high-speed networks.
Were you trying to perform the same evil
[EMAIL PROTECTED] wrote:
George, maybe there should be a separate category in GNATS also, for
network issues?
Instead of being in kern you mean? I have thought that before but I
don't control GNATS and we'd have to review a lot of bugs.
I have noticed there has been a gradual effort
Hi,
Please try the attached patch which should hopefully fix this issue
(untested).
Regards,
BMS
? .swp
Index: if_pfsync.c
===
RCS file: /home/ncvs/src/sys/contrib/pf/net/if_pfsync.c,v
retrieving revision 1.32
diff -u -p
Synopsis: [netisr] suggestion to fix suboptimal network polling
State-Changed-From-To: feedback-open
State-Changed-By: bms
State-Changed-When: Sun Feb 25 16:18:13 UTC 2007
State-Changed-Why:
Back to the net pool
Responsible-Changed-From-To: bms-net
Responsible-Changed-By: bms
Whups. That needs 'int s' or the spl calls removed.
I am under the weather today (dry flu type virus)...
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
I have now added a regression test for this bug in HEAD, under
src/tools/regression/ethernet/ethermulti.
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL
http://wiki.freebsd.org/NetworkRfcCompliance
Please begin wiki-whacking!
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Luigi Rizzo wrote:
On Wed, Feb 21, 2007 at 02:50:27PM +, Bruce M Simpson wrote:
http://wiki.freebsd.org/NetworkRfcCompliance
before it is too late to change, maybe it is the case to
spell RFC as all capital letters ?
It would surely be better named NetworkStandardsCompliance
satimis wrote:
Hi folks,
FreeBSD-6.2-amd64
...
The onboard NIC seems not detected.
In the absence of required information, I speculate your machine has
msk(4) or another recent chipset which may be supported in
FreeBSD-CURRENT but not FreeBSD-STABLE.
Please post the full output of
Anyone out there running IS-IS on a FreeBSD machine, please contact me.
It's my understanding that IS-IS requires link-layer multicast support.
Therefore I would like to hear from anyone who is running an
implementation of it on FreeBSD successfully. I want to make sure it
continues to
Here is a better patch for the netstat output. I haven't had time to
look at the kernel yet.
If this patch is good for you I'll commit it on -CURRENT. It cleans up
the group membership output significantly and displays the Link-layer
information separately.
If anyone 'out there' has been
Jouke Witteveen wrote:
So my apologies for suggesting it doesn't work at all; it seems that
the application I'm trying to get to work (wpa_supplicant for wired
interfaces) just doesn't _send_ its packets the right way.
That's a big relief! I added an item to the Wiki for someone to write a
Does anyone have any good suggestions for a book which discusses OSPF v3
architecture?
I have read the original John Moy book 'OSPF: Anatomy of an Internet
routing protocol' but would very much like to know of there is a good
text out there which discusses OSPF in the wider context of IPv6
Yar Tikhiy wrote:
Do you have any architectural reservations about nested VLANs in
the main network stack? Presently, a one-line patch can allow a
vlan(4) to attach to another vlan(4), but I haven't heard about the
behaviour of the resulting setup yet.
After looking around it seems there is
Pyun YongHyeon wrote:
Further testing with drivers is needed (I can't be 100% sure it fails
with msk(4) because something strange is happening when vlan tagging is
turned off). Perhaps Pyun knows?
I guess I've not merged local changes before committing to HEAD.
How about attached
Hi,
I have tested my 802.1p input patch with vlans configured. So far so good.
It is now available from:
http://people.FreeBSD.org/~bms/dump/latest-8021p.diff
This updated patch moves the 802.1q encapsulation into if_ethersubr.c,
allowing
M_VLANTAG to be passed up and down the stack for
Andrea Venturoli wrote:
Today it suddenly dropped to a bare few b/s. I checked the ISP line by
attaching another machine in place of this and it could do full 1Mb/s,
so this box was the problem.
After a simple reboot it started working as good as always.
Now the question is: in case this
[EMAIL PROTECTED] wrote:
Hi all
situation: got freebsd box working as NAT for my local network. In kernel
config there is an option PIM.
FYI, PIM is now the default in -CURRENT; the option has been removed.
You should be able to load multicast routing with PIM as a loadable
kernel module
Gary Corcoran wrote:
Since those 'classes' haven't meant anything for many years, and
interpreting
them as 'special' is just plain wrong in almost all cases these days,
I think
the change is the right thing to do.
I've had +3.
Any objections? If I hear none I will make this change in
Hi,
Here is the first patch to bring in 802.1p Packet Priority to FreeBSD;
this is to support Differentiated Services and Quality-of-Service. This
builds on the M_VLANTAG support introduced by Andre last September.
This first stage enables FreeBSD to pass packets for 802.1q with VLAN 0
to
This updated patch moves VLAN tag decapsulation into if_ethersubr.c and
always uses M_VLANTAG, which is also passed to the upper layer.
Tests with ping:
fxp (no VLAN_HWTAGGING support) OK
msk (VLAN_HWTAGGING enabled) OK
msk (VLAN_HWTAGGING disanabled) FAIL
I am concerned that
Hi,
Thunderbird keeps crashing whenever I draft these messages, which is
frustrating.
Can we discuss this change? I would like to get it in as we get the
following wins:
1. Potentially cleaner code in ether_demux()/ether_input()
2. Ways of detecting and preventing L2/L3 forwarding loops
3.
Hi,
This should do what it says on the tin...
Regards,
BMS
Make IPv6 multicast forwarding dynamically loadable into a GENERIC kernel.
Index: conf/files
===
RCS file: /home/ncvs/src/sys/conf/files,v
retrieving revision 1.1175
diff
Hi,
This is a POLA violating 'let's move with the times' patch that gets rid
of the special treatment of classful IPv4 network prefixes in 'netstat
-rn' output. Comments please!
Rgards,
BMS
Index: route.c
===
RCS file:
Joel Dahl wrote:
How about moving stuff from the (outdated) dingo[*] project page to this
wiki page instead?
[*] http://www.freebsd.org/projects/dingo/
That's what he did. I feel a twinge of responsibility for this, and the
stupid name. I have just totally steamrollered in and edited
Synopsis: [netgraph] [patch] ng_ksocket fails to clear multicast flag on mbuf
before passing to stack
Responsible-Changed-From-To: freebsd-net-bms
Responsible-Changed-By: bms
Responsible-Changed-When: Fri Feb 9 02:39:10 UTC 2007
Responsible-Changed-Why:
I'll take this
This change has now been committed on -CURRENT (reviewed by bz@) so it
is now settling in.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
I count no objections and +1 in favour from Andre.
To maintain POLA, I will decapitate (Argh, pun) it from HEAD with no MFC
to begin with.
Arguments in favour:
* mrouted was removed from the base system.
* PIM does not use MROUTING's IPIP tunnels, and PIM is regarded as the
standard these
This has now been applied to -CURRENT after testing by a 3rd party.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Hi,
If any of you out there have network interfaces which have broken
ALLMULTI handling (i.e. they can't handle multicast routing), I would
love to hear from you.
Regards,
BMS
___
freebsd-net@freebsd.org mailing list
Jouke Witteveen wrote:
Hello all,
I'm in need of some information on how to utilize SIOCADDMULTI. It is
supposed to be demonstrated by the mtest [1] program, but that doesn't
do anything (on an SIOCDELMULTI rn it appears nothing was added:
ENOENT), At least not for the values I tested,
How would you all feel about removing the old encapsulation methods from
IPv4 multicast routing as OpenBSD has done?
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ip_mroute.c.diff?r1=1.42r2=1.43
The last time I deployed any such infrastructure, I had to use gif(4);
in a NATted world,
Hi,
I just saw this PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/100080
This patch appears to fix the problem. Any obvious glaring errors?
Testers please?
Regards,
BMS
Index: if_tun.c
===
RCS file:
201 - 300 of 559 matches
Mail list logo
