>I plan to commit this patch some time this week.
>---mroute-notunnels.diff, text/x-patch follows---
Please do. Only one comment:
>@@ -859,8 +816,6 @@ X_ip_mrouter_done(void)
> /*
> * Reset de-encapsulation cache
> */
>-last_encap_src = INADDR_ANY;
>-last_encap_vif = NULL;
Hug,
If you feel like building a new kernel, I'd suggest commenting
out those lines that I quoted in in_pcb.c:
if (sin->sin_port == 0)
return (EADDRNOTAVAIL);
and see if the FreeBSD tftpd behaves the way you want after that.
I don't think that's the solution that
I'd note that RFC 768 explicitly mentions this possibility:
Source Port is an optional field, when meaningful, it indicates the port
of the sending process, and may be assumed to be the port to which a
reply should be addressed in the absence of any other information. If
not used, a value
>I think it would be a good idea if we de-orbit /usr/sbin/mrouted in
>7-CURRENT.
Do it. Maybe consider making a port if anyone cares to continue to
use it. (Gee, I suppose I could do that part ;-)
Bill
___
freebsd-net@freebsd.org mailing list
http
Robert,
The code in rev 7.1 (4.3BSD) was:
if (so->so_q == 0) {
so->so_q = so;
so->so_q0 = so;
so->so_options |= SO_ACCEPTCONN;
}
which looks like it's initializing q0 and q to be circular queues,
which has to only happen once, an
Garrett and I discussed what IFF_NOARP should mean about 4-5 years
ago; we decided that it probably menat "no ARP". We discussed
the idea of seperating it out into two flags; "Don't reply to ARP"
and "don't pay attention to ARP" but decided to wait and see what
people thought. 4-5 years is proba
I have been too busy over the last couple of weeks. I have no problem
with the multicast filtering API change actually happening, and if
someone who actually has time wants to commit it that'd be fine with me.
Bill
___
[EMAIL PROTECTED] mailing list
I think c) (perhaps combined with IP_RECVDSTADDR so that you know
whether you got a unicast or broadcast) is the correct answer.
I think binding UDP sockets to tell what interface/address was
the destination is a historical artifact.
Bill
___
[EMAIL P
The short answer is no, you can't, in_pcb turns 255.255.255.255 into
the "primary" interface's broadcast address.
I doubt this is actually useful behavior, but that's not what you
asked =)
Bill
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.
Tom,
>Currently, we use a PPP tunnel to put the PBX and Phone on subnets that
>can talk to each other. The two FBSD boxen run as the endpoints of the
>tunnel. We need to be able to seamlessly forward multicast traffic between
>the remote network and the office network.
>
>Any ideas?
mrouted shou
I have a patch, which I apparently never committed, to make libpcap
respect debug.bpf_bufsize if it's larger than 32k. I will make sure
this gets into libpcap and then a release and then FreeBSD (whew).
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the
>So, if backlog is a threshold for communicating to clients, then I
>think RST is the right choice as it communicates server state
>unambiguously.
I disagree; RST does not communicate server state unambiguously.
RST is used in response to an erroneous packet on a synchronized
connection, in resp
>We don't send a RST, we just silently drop the connection.
This is wrong too; it should silently drop the ACK and leave the
connection in the pending queue.
>However, at the point we're talking about,
>we're already past the 3-way handshake
I thought we were talking about the ACK that finishe
>I just did a quick look over the code, and it appears that the complete
>connection queue is still intact, and takes on 3/2*listen backlog as its
>length. Therefore, if sendmail is deciding to not accept() all
>connections ASAP, a backlog will build up, and RSTs will be sent to
>incoming connec
>The only difference I can see is that in ip_input(), if nipq > maxnipq,
>all of the fragments for some other packet in the current hash bucket
>get dropped (with the wonderfully descriptive comment "gak").
The best thing to do is to drop the oldest frag queue; that's obviously
non-trivial with
>Just for the heck of it, I started reading through ip_input.c to see how
>hard this would be to do. Haven't got there yet, I saw something odd:
>the variables ip_nfragpackets and nipq look *awfully* similar.
So do the commit logs for the revisions in which each was introduced.
Revision 1.65 -
Garrett and I discussed what IFF_NOARP should mean about 4-5 years
ago; we decided that it probably menat "no ARP". We discussed
the idea of seperating it out into two flags; "Don't reply to ARP"
and "don't pay attention to ARP" but decided to wait and see what
people thought. 4-5 years is prob
> The M_LEADINGSPACE macro always had the line of code that would return
>the leading space even for ext_bufs commented out, suggesting that the
>code did exist in the original implementation or was intended to.
The M_LEADINGSPACE macro was introduced in rev 7.11 of mbuf.h, in
August 1988, at t
Luigi Rizzo <[EMAIL PROTECTED]> said:
>On Tue, Oct 23, 2001 at 03:17:04PM -0400, Garrett Wollman wrote:
>> ... the whole purpose of m_pullup is to
>> *guarantee* that the data in question will never be shared.
>
>Technically, it is correct that m_pullup guarantees that the data
>in question will
Can you try telling squid to bind to the jail IP address with the
'udp_outgoing_address' option?
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
>If I remember correct VLANs are not
>even in ifTable, since they are not interfaces
Why not? My reading of RFC 2863's section 3.1 says that although
the VLAN multiplexing was not explicitly considered, it fits the
ifStack model perfectly, and satisfies the requirements for defining
a layer (n
> But the definition of threshhold TTL says that a
>incoming multicast packets will be forwarded out of an
>interface only if it has the TTL value >= threshold
>TTL of that interface. Am I right?
No. Zero is special, and means do not forward. If you have
the kernel source, check out the ip_mdq
>Why does vlans announce themselves as being 10 Mbits/s? I'm getting this
>from snmp on vlans that are attached to 100 Mbits/s cards.
Because if_vlan.c calls ether_ifattach() without setting
ifp->if_baudrate?
I think "0" would be the most accurate value to return; if you
really want to know th
This should work in -stable and -current (arp.c version 1.22.2.2 or
1.29). You could apply this diff:
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/arp/arp.c.diff?r1=1.22.2.1&r2=1.22.2.2
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of t
>We had directed-broadcast forwarding before, and it was removed.
>Perhaps someone might examine the CVS logs to see when and why.
| Revision 1.32 / Dec 20 1995 (5 years, 7 months ago) by wollman
|
| Demolish DIRECTED_BROADCAST. It was always a bad idea, and nobody uses it.
I don't feel as s
>On FreeBSD -CURRENT and -STABLE, packets to broadcast addresses are not
>forwarded.
"smurf" attacks love using broadcast forwarders.
RFC 2644 says:
> A router MAY have an option to enable receiving network-prefix-
> directed broadcasts on an interface and MAY have an option to
>
>One more thing, -CURRENT will stuff two copies of any broadcast into bpf,
>it seems.
This is because if_simloop() is broken. I proposed to un-break it
a while ago and never got any feedback.
http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=198310+201485+/usr/local/www/db/text/2001/freebsd-net/200
>@@ -964,7 +957,7 @@ sendorfree:
> /* clean ipsec history once it goes out of the node */
> ipsec_delaux(m);
> #endif
>- if (error == 0) {
>+ if (error == 0 && ia) {
> /* Record statistics for this interface address. */
>
Are the VLAN interfaces trunked on the FreeBSD side (i.e. vlanN)?
Are you getting bitten by the device driver dropping large frames
(VLAN trunks need a higher MRU/MTU, which no drivers seem to support;
see http://www.euitt.upm.es/~pjlobo/fbsdvlan.html for if_fxp patches)
If you set the MTU to 14
Dmitry,
In the future, please publish large files on a web site or something
and offer URLs instead of attaching the files to a mailing list.
I'd like to see an mrouted.cache and a netstat -g taken at the same
time; perhaps it'd be best to just attach them in email to me and leave
the list
Sorry, no, I can't answer these problems. I'm still working
on getting multicast completely working.
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Actually, I guess I *did* commit them, in -current. I will look at
merging them next week.
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
The vlan driver doesn't set up the multicast filters correctly on
the underlying interface. I've got a patch sitting in my CVS tree
that I should probably just commit...
Bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
BPF handling in if_simloop() is broken for every use except for
from looutput().
Why?
BPF write: BPF writes go through if_output, and if_simloop() is not an
if_output routine. This code should be in looutput().
BPF tap: if_simloop() prepends the header that BPF expects when it's
capturing on
I prefer Jesper's other patch (the one that goes back to
code = PRC_UNREACH_PORT). Note that the comment here:
/*
* RFC 1122, Sections 3.2.2.1 and 4.2.3.9.
* Treat subcodes 2,3 as immediate RST
*/
Perhaps the MIB has more errors than you know. If you give me a pointer
to the MIB and some samples of the numerical OIDs that you're getting I
might be able to help.
If you pick a name in that MIB and say "snmptranslate ", does it
tell you the OID associated with it? At one point you had to d
>I'm not sure when this capability appeared. There is no man page for
>pccard_ether or start_if and I totally missed it until now.
It appeared in -stable on February 4th; 4.3 will be the first release
so it's not particularly surprising that you didn't know about it.
I've been modifying /etc/pcc
Now that an ICMP port unreachable returns ENETRESET and not ECONNREFUSED,
setting the date on the command line results in a bogusly-reported error.
Before you fix the bug in date/netdate.c, it tends to report EADDRINUSE;
afterwards it tends to report ENETRESET.
Why did the handling of "udp port
38 matches
Mail list logo
