Hi,
Will Andrews wrote:
Hello,
I've written a patch (against 8.0-CURRENT as of r191369) which makes
it possible to build, load, run, & unload CARP as a module, using the
GENERIC kernel. It can be obtained from:
http://firepipe.net/patches/carp-as-module-20090421.diff
There's no need to i
The following reply was made to PR kern/132722; it has been noted by GNATS.
From: Bruce M Simpson
To: John Hay
Cc: Matthias Apitz , freebsd-net@freebsd.org,
Sam Leffler ,
"Sean C. Farley" , bug-follo...@freebsd.org
Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP
John Hay wrote:
I found doing a -bgscan before it happens, make it not happen. I now
have -bgscan in my rc.conf.
That's exactly the workaround I needed. Thanks John.
As Sam points out, the root fix is probably already in HEAD; it would be
nice to find time to backport, but this works for u
bru...@freebsd.org wrote:
Synopsis: [libc] socket(2): INP_PORTHIGH and INP_ONESBCAST share same value
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: brucec
Responsible-Changed-When: Mon Mar 23 21:45:54 UTC 2009
Responsible-Changed-Why:
Over to maintainer(s).
[Repost without attachment]
OK. We've managed to reproduce this set of symptoms now in our work area.
[If anyone needs to see a pcap, please Cc: me offlist.]
Timebase: beginning of the pcap is in sync with a bringup from
single-user mode; the tcpdump runs in the background from init whilst
The following reply was made to PR kern/132722; it has been noted by GNATS.
From: Bruce M Simpson
To: Matthias Apitz
Cc: bug-follo...@freebsd.org, Sam Leffler ,
freebsd-net@freebsd.org, "Sean C. Farley"
Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP
Matthias Apitz wrote:
I went today evening with my EeePC and CURRENT on USB key
to that Greek restaurant; DHCP does not get IP in CURRENT either;
this is somehow good news, isn't it :-)
This may be orthogonal, but:
A lab colleague and I have been seeing a sporadic problem where the
ath0
Sam,
Sam Leffler wrote:
This patches avoids the crash. Not sure how ifma_protospec is
supposed to be handled so I'm not committing it.
Thanks for this.
I have a test machine ready to be prepped but it's missing a CF card (I
have none) so need to pick one up from a friend. I have a pci-cardb
Eygene Ryabinkin wrote:
...
I wanted to stress only one point: simple 'kldunload ' and
'kldload ' makes devices to flip for Yony's case. This means
that unless some PCI hotplug stuff is here (which I don't believe to be
present, because no physical cards are touched and there is actually a
small
Yony,
Bruce M. Simpson wrote:
And how come the unit number is given an arbitrary value? Is there a
good
reason for that?
...
In your case I'm not sure why your two cards would flip order. Could
it be how your BIOS and hardware set up the PCI IDSEL lines at boot?
If this is the
Yony Yossef wrote:
Thanks for the explanation.
So there's no way to determine this in advance..
I must build a script that contains my own mapping between MAC addresses and
the wanted interface names and run it after each driver load, rename the
interfaces if necessary.
It seems quite wrong,
Bruce M. Simpson wrote:
Peter Steele wrote:
...
I personally like this idea, but I'm not sure I can sell it to the
others. Are there any restrictions to these 169.254.x.y addresses?
169.254.0.0/16 must never appear outside a link -- it is strictly
scoped to that link.
P.S. I check
Peter Steele wrote:
...
I personally like this idea, but I'm not sure I can sell it to the
others. Are there any restrictions to these 169.254.x.y addresses?
169.254.0.0/16 must never appear outside a link -- it is strictly scoped
to that link.
Currently the IPv4 BSD stack has no concept
Peter Steele wrote:
The folk who point out that link-local addresses could be used, have
an
interesting suggestion which might work for you.
It's definitely interesting, but it is very likely that some of our
customers will want to be able to set their own IP ranges and not be
li
Peter Steele wrote:
...
It's really a matter of time. We didn't anticipate limited broadcast
being broken in FreeBSD and we're scrambling to come up with a solution.
To be quite frank I haven't done anything with IPv6 before so it would
be more research to get up to speed on this option. It seems
Peter Steele wrote:
..
Based on the discussion in the link above, it doesn't seem like the
problem was entirely resolved by the patches mentioned in this thread.
Has anything been done since this discussion took place. Surely there
must be a way to get limited broadcast to work under FreeBSD.
Hi,
Just skimming this I notice it uses the if_afdata[AF_INET] pointer
purely for lltbl purposes; this clashes with the IGMPv3 code drop.
Please look in the bms_netdev branch, where I introduce a 'struct
ip_ifinfo' to make more general use of that slot. IGMPv3 needs to store
per-interface st
Hi,
I am missing context of what Max's suggestion was, do you have a
reference to an old email thread?
Style bugs:
* needs style(9) and whitespace cleanup.
* C typedefs should be suffixed with _t for consistency with other
kernel typedefs.
* Function typedefs usually named like foo_func_t (s
[Resend to list for everyone]
Espartano wrote:
Actually i know how to program with C language in a basic level but i
don't know nothing about hardware or computer organization, what
topics i should study for gain knowledges about net-drivers ? or if
someone can recommend me books about this topi
Espartano wrote:
Actually i know how to program with C language in a basic level but i
don't know nothing about hardware or computer organization, what
topics i should study for gain knowledges about net-drivers ? or if
someone can recommend me books about this topic i will be very
thankful.
Julian,
Thank you (and Marko) very much for preparing this document.
The VIMAGE import has had me at something of an impasse re: the IGMPv3
branch and clearly written documentation is a big help indeed.
Julian Elischer wrote:
Well not completely, but I've had a number of questions over the
l
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
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
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 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
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
[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
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
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
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
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
[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
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
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
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
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
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
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:
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
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
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
[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
[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:
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.
..
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
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
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
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
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:
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:
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
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?
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
[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
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
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.)
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
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
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
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
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
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?
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
[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
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
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
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
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
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
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
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
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:
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:
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
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
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
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
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:
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
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
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
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.
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
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
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
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
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
[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
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
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.
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 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
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
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
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
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
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
+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
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
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
1 - 100 of 613 matches
Mail list logo
