On Fri, 14 Jun 2024 at 11:13, Rodney W. Grimes
wrote:
>
> That section is about how the router responds to an ICMP redirect
> set to IT, not one that is going THROUGH it.
Sorry I wasn't explicit, in all cases I'm talking about ICMP REDIRECTs
destined for the machine (as a host or as a router). Th
On Fri, 14 Jun 2024 at 09:57, Rodney W. Grimes
wrote:
>
> I am not sure that it would "hang" the port, but by ignoring the
> rediect your going to place additional burden on the router that
> is trying to redirect you as all packets would have to be forwarded
> by that router. I suppose it could
On Fri, 14 Jun 2024 at 09:52, Rodney W. Grimes
wrote:
> >
> > I would argue that having IP forwarding enabled (i.e.
> > net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a
> > router, and ICMP REDIRECT messages are already dropped in kernel in
> > that case.
>
> Yet another mistake b
On Wed, 12 Jun 2024 at 18:05, Chris wrote:
>
> As Rodeney already effectively explains; dropping packets makes routing,
> and discovery exceedingly difficult. Which is NOT what the average user
> wants,
This is on end hosts only, not routers (which already drop ICMP REDIRECT).
> or expects. I us
> > > Discarding ICMP redirects on a internet host is non-conformant with
> > > STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts.
> >
> > In that case our default of "auto" is non-conformant if you have a
> > routing daemon.
>
> NO, because then your not subject to rfc-1122 as y
On Thu, 13 Jun 2024 at 09:39, Rodney W. Grimes
wrote:
>
> Discarding ICMP redirects on a internet host is non-conformant with
> STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts.
In that case our default of "auto" is non-conformant if you have a
routing daemon.
On Sun, 7 Aug 2022 at 01:32, Ben Woods wrote:
>
> Hi freebsd-net,
>
> I would like to propose dhcpcd is imported into FreeBSD base.
I've started to revisit this during the Kitchener-Waterloo Hackathon.
I've discussed briefly with Ben in private mail.
For context, have a look at the previous thre
On Tue, 7 May 2024 at 14:35, Marek Zarychta
wrote:
>
> But what about IPv6 ? We have "net.inet6.icmp6.rediraccept" knob which
> defaults to 1. Can ICMPv6 redirects be fixed along with the change
> proposed for the legacy IP protocol?
It may make sense to apply the same default change for IPv6, bu
I propose that we start dropping inbound ICMP REDIRECTs by default, by
setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and
changing the associated rc.conf machinery). I've opened a Phabricator
review at https://reviews.freebsd.org/D45102.
ICMP REDIRECTs served a useful purpose in e
On Mon, 15 Apr 2024 at 16:49, Lexi Winter wrote:
>
> currently FreeBSD ships routed(8) and route6d(8) which implement the RIP
> resp. RIPng routing protocols.
> ...
> i'd like to submit a patch to remove both of these daemons from src. if
> there's some concern that people still want to use the B
emaste removed a subscriber: freebsd-net-list.
CHANGES SINCE LAST ACTION
https://reviews.freebsd.org/D33717/new/
REVISION DETAIL
https://reviews.freebsd.org/D33717
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: emaste, melifaro, imp, hrs
Cc: brooks, fre
emaste added a subscriber: brooks.
CHANGES SINCE LAST ACTION
https://reviews.freebsd.org/D33717/new/
REVISION DETAIL
https://reviews.freebsd.org/D33717
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: emaste, melifaro, imp, hrs
Cc: brooks, freebsd-net-lis
emaste added a comment.
As @melifaro pointed out to prompt this change hp was passed to three
getaddr() calls in newroute(), and was not otherwise used, and getaddr() does
not use the passed-in value.
CHANGES SINCE LAST ACTION
https://reviews.freebsd.org/D33717/new/
REVISION DETAIL
http
emaste updated this revision to Diff 100973.
emaste added a comment.
remove now-unused variable
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D33717?vs=100815&id=100973
CHANGES SINCE LAST ACTION
https://reviews.freebsd.org/D33717/new/
REVISION DETAIL
https://reviews.freebsd.org
emaste added reviewers: imp, hrs.
CHANGES SINCE LAST ACTION
https://reviews.freebsd.org/D33717/new/
REVISION DETAIL
https://reviews.freebsd.org/D33717
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: emaste, melifaro, imp, hrs
Cc: freebsd-net-list
emaste removed reviewers: imp, hrs.
CHANGES SINCE LAST ACTION
https://reviews.freebsd.org/D33717/new/
REVISION DETAIL
https://reviews.freebsd.org/D33717
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: emaste, melifaro, imp, hrs
Cc: freebsd-net-list
emaste updated this revision to Diff 100815.
emaste added reviewers: melifaro, imp, hrs.
emaste added a subscriber: freebsd-net-list.
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D33717?vs=100814&id=100815
CHANGES SINCE LAST ACTION
https://reviews.freebsd.org/D33717/new/
REVISION DE
emaste added a subscriber: emaste.
REVISION DETAIL
https://reviews.freebsd.org/D1986
To: rpokala-panasas.com, rstone
Cc: emaste, ae, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscr
emaste added a subscriber: emaste.
REVISION DETAIL
https://reviews.freebsd.org/D1869
To: rstone, jfvogel
Cc: emaste, pjd, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send a
emaste added a subscriber: emaste.
REVISION DETAIL
https://reviews.freebsd.org/D1881
To: rstone, jfvogel
Cc: emaste, pjd, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send a
emaste added a subscriber: emaste.
REVISION DETAIL
https://reviews.freebsd.org/D1805
To: davide, kmacy, np, lstewart, rrs, rwatson
Cc: emaste, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
T
emaste added inline comments.
INLINE COMMENTS
kern/kern_timeout.c:1159 Yeah, something like @imp's suggestion makes it more
clear to me.
REVISION DETAIL
https://reviews.freebsd.org/D1711
To: rrs, gnn, rwatson, sbruno, lstewart, jhb, kostikbel, hselasky, adrian, imp
Cc: jhb, kostikbel, emast
emaste added a comment.
For future diffs, please generate with full context, e.g. -U99
INLINE COMMENTS
sys/kern/kern_timeout.c:789 added EOL whitespace?
sys/kern/kern_timeout.c:1067-1069 I'm a bit confused by this sentence.
REVISION DETAIL
https://reviews.freebsd.org/D1711
To: rrs, gn
emaste added a subscriber: emaste.
REVISION DETAIL
https://reviews.freebsd.org/D1711
To: rrs, gnn, rwatson, adrian, sbruno, lstewart, hselasky, imp
Cc: emaste, delphij, neel, erj, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freeb
emaste added a subscriber: emaste.
REVISION DETAIL
https://reviews.freebsd.org/D1309
To: rodrigc, glebius, trociny, zec, np, melifaro, hrs, wollman, bryanv, rpaulo,
adrian, bz, gnn, hiren, rwatson
Cc: emaste, freebsd-virtualization, freebsd-pf, freebsd-net
_
On 24 April 2013 14:57, Adrian Chadd wrote:
> Is this an issue on -7 and -6?
I believe so, and it should get merged there as well.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any ma
On 1 March 2013 10:53, Andrey V. Elsukov wrote:
> On 01.03.2013 01:06, Ed Maste wrote:
>> On 28 February 2013 14:10, Ed Maste wrote:
>>> The attached patch keeps the fwd_tag
>>> around until finished with pcb lookup.
>>
>> There's a small bug in tha
On 28 February 2013 14:10, Ed Maste wrote:
> The attached patch keeps the fwd_tag
> around until finished with pcb lookup.
There's a small bug in that patch - a corrected version, which handles
a NULL return from m_tag_find, can be found at:
http://people.freebsd.org/~ema
SVN rev 244157 introduced a fix for a crash in tcp_input() which would
occur in the case of a packet with a PACKET_TAG_IPFORWARD m_tag arriving
for a flow in TIMEWAIT. Such packets resulted in a goto findpcb an a
double free of the m_tag.
Unfortunately the fix causes the fwd_tag to be lost for an
On 1 February 2013 16:21, Kevin Day wrote:
> We've got a large cluster of HTTP servers, each server handling
> >10,000req/sec. Occasionally, and during periods of heavy load, we'd get
> complaints from some users that downloads were working but going EXTREMELY
> slowly. After a whole lot of deb
The following reply was made to PR kern/138620; it has been noted by GNATS.
From: Ed Maste
To: ,
Cc:
Subject: kern/138620 [patch] Sysctl for direct BPF writes to lagg child ports
Date: Tue, 1 May 2012 13:08:01 -0400
--jRHKVT23PllUwdXP
Content-Type: text/plain; charset="us-ascii"
On Wed, Apr 18, 2012 at 12:53:43PM +1200, Andrew Thompson wrote:
> What we also need is a event trigger for
> various pseudo interfaces when the mac or primary interface changes,
> this would allow arp/nd6 to rebroadcast.
Yes, we're working something like this specifically for lagg but it
should
When a new lagg(4) interface is created the link layer address from the
first port in the group is assigned to the lagg and to all other lagg
port members. This means the address assigned to the lagg is different
if specified as, for example, "laggport em0 laggport em1" vs
"laggport em1 laggport e
dation instead to help support the FreeBSD
project in general.
Regards,
Ed Maste
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Thu, Jan 05, 2012 at 08:18:39PM -0500, J David wrote:
> To help understand what's going on and test some of this stuff, I
> hacked up a TCP-MD5-aware echo server and tried various things.
Hi J David,
Thank you very much for this extensive testing and analysis. Would you
care to post your bas
On Tue, Jan 03, 2012 at 09:07:56AM +0200, Nikolay Denev wrote:
> Since I've had similar problem with Quagga after updating to 8.2-STABLE I'd
> suggest
> you to try setting "net.inet.tcp.signature_verify_input=0" and see if that
> would help.
>
> Here is another thread about the similar (if not
On Sat, Oct 30, 2010 at 12:32:19PM +0100, Paul Thornton wrote:
> I've been doing testing with FreeBSD 8 and em interfaces recently, and
> my experience agrees with Chuck's statement - that polling makes things
> worse when you use new (anything in the last 2 or 3 years) hardware with
> good qualit
On Wed, Oct 13, 2010 at 01:04:54PM +0200, Attilio Rao wrote:
> 2010/10/9 Robert Watson :
> > (1) Did you consider using tftp as the network dump protocol, rather than a
> > custom protocol? ??It's also a simple UDP-based, ACKed file transfer
> > protocol, with the advantage that it's widely suppo
On Sat, Oct 09, 2010 at 02:15:39AM +0100, Robert Watson wrote:
> Network dumps would be a great addition to the FreeBSD debugging suite!
> [...]
It seems that at EuroBSDCon there was a discussion of Contiki[1] and
the uIPv6 stack[2] that it contains, and I think something like this
could be a gre
On Mon, Sep 21, 2009 at 01:43:33PM +0100, Andrew Brampton wrote:
> I've been reading the FreeBSD source code to understand how mbufs are
> reference counted. However, there are a few bits of code that I'm
> wondering if they would fail under the exactly right timing. Take for
> example in uipc_mbu
The following reply was made to PR kern/122780; it has been noted by GNATS.
From: Ed Maste
To: bug-follo...@freebsd.org, p...@gtcomm.net
Cc:
Subject: Re: kern/122780: [lagg] tcpdump on lagg interface during high pps
wedges netcode
Date: Mon, 17 Aug 2009 16:14:13 -0400
Can you retest on
On Fri, Apr 24, 2009 at 08:03:52AM -0700, Barney Cordoba wrote:
> Actually, the "advantage of using interrupts" is to have a per
> NIC control without having all of the extra code to implement
> polling. Using variable interrupt moderation is much more desirable
> and efficient, so polling is only
On Fri, Mar 27, 2009 at 11:05:00AM +, Andrew Brampton wrote:
> 2009/3/27 Luigi Rizzo :
> > The load of polling is pretty low (within 1% or so) even with
> > polling. The advantage of having interrupts is faster response
> > to incoming traffic, not CPU load.
>
> oh, I was under the impression
On Tue, Mar 25, 2008 at 04:00:33PM -0400, Ed Maste wrote:
> GENERIC CURRENT as of this morning.
>
> panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @
> /d2/emaste/HEAD/src/sys/netinet6/ip6_output.c:719
> ...
> panic() at panic+0x176
> _mtx_lock_sleep
On Thu, Oct 04, 2007 at 12:02:56PM -0700, Michael DeMan wrote:
> Also, we've noticed at least on FBSD 6.x that there seem to be very
> few advantages in using polling on network interfaces. We still run
> it, so that we have responsive SSH/BGP/OSPF processes on the
> machines, but my testin
It turns out an application at work is passing an IP address to inet_pton
that is formatted slightly strangely; it ends up being something of the form
1.002.3.4. In 4.x inet_pton reports this as valid and returns 1.2.3.4. (I
also checked that it's just ignoring the leading zeros, not parsing the
ags & M_EXT) == 0)
+ nsize = MHLEN;
}
n->m_len = 0;
--
Ed Maste, Sandvine Incorporated
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To u
that includes the flag, and make bpf_tap call it (for any third
party drivers using bpf_tap)?
--
Ed Maste
Sandvine Incorporated
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Mon, Aug 08, 2005 at 10:34:53PM +0100, Robert Watson wrote:
> Could you add a hard-coded entry to WITNESS to place the udpinp lock
> before the in_multi_mtx in the lock order, and let me know which path
> resulted in the opposite order from this one?
I hard-coded the correct order, but am now
We build one of our netgraph modules with -W, which causes GCC
to emit "warning: `inline' is not at beginning of declaration" for
netgraph.h. It's pretty trivial, but the attached patch cleans this
up so it's consistent across all of the functions in netgraph.
(685a003b,804003b,9fbf003b,821c400,f6) at 0xa06c75b3 = syscall+0x25b
Xint0x80_syscall() at 0xa06b4ccf = Xint0x80_syscall+0x1f
--- syscall (4, FreeBSD ELF32, write), eip = 0x681e31af, esp = 0x9f9ff9fc, ebp
= 0x9f9ffa18 ---
--
Ed Maste, Sandvine Incorporated
.
I haven't yet looked over the whole patch to understand the
specifics. I'll post again once I do if I have any ideas.
--
Ed Maste, Sandvine Incorporated.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
e problem but have had no success yet.
--
Ed Maste, Sandvine Incorporated
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ts (in_multihead)
on 5.x, and it turns out in_addmulti still has splnet() "protecting" the
list.
I'm not sure how many of the splnet()s are actually false positives
(i.e. no longer relevant, locked in another way, etc.) but they're
probably all good indicators of places th
>From Bruce's patch:
+ if (d->bd_tstamp == BPF_TSTAMP_MICROTIME)
+ microtime(&hp->bh_tstamp);
+ else if (d->bd_tstamp == BPF_TSTAMP_GETMICROTIME)
+ getmicrotime(&hp->bh_tstamp);
Perhaps set the timestamp to zero in the else
would.
One way to allow the user to control this behaviour on a per-
application basis would be to have libpcap check an env var in
order to decide if the ioctl should be set.
Ed Maste
Sandvine Inc.
___
[EMAIL PROTECTED] mailing list
http://lists.freebs
>Well, I guess the spl() fix is probably going to be the quickest here
>then, please send it to me once you've pounded on it, Ed.
So my spl() fix seems to eliminate the problem for me but while I'm looking
at this stuff I want to make sure there aren't any related cases left in.
My current patch i
Mike "Silby" Silbersack wrote:
>Well, as ui_ref is the best bet, redoing your tests with it expanded to
>ui_int is where we need to start before looking further. :)
>
>I believe that a uidinfo->ui_ref over/underflow could cause random memory
>corruption, so maybe the panic you're seeing comes abou
58 matches
Mail list logo
