e Closed -->
Initial
May 16 14:48:29 net5501 mpd: [L-1] Link: SHUTDOWN event
May 16 14:48:29 net5501 mpd: [L-1] Link: Shutdown
--
Crist J. Clark | cjcl...@alum.mit.edu
___
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"
ADDR_SCOPE_NODELOCAL0x01
#define __IPV6_ADDR_SCOPE_INTFACELOCAL 0x01
#define __IPV6_ADDR_SCOPE_LINKLOCAL0x02
+#define __IPV6_ADDR_SCOPE_ADMINLOCAL 0x04
#define __IPV6_ADDR_SCOPE_SITELOCAL0x05
#define __IPV6_ADDR_SCOPE_ORGLOCAL 0x08/* just used in this file */
#define __IPV6_ADDR_SCOPE_GLOBAL
;
The replacement does not yet exist.
> On Jan 5, 2008, at 3:52 AM, Michael Tuexen wrote:
>
> >Dear all,
> >
> >aren't site-local IPv6 addresses depreceated (RFC 3879)? So shouldn't
> >the site-local stuff be removed?
> >
> >Best regards
> &g
hould work fine in CURRENT.
Suggestions, comments, or criticisms, public or private, are welcome.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PR
eate policy" on the
fly. What happens is that when the SA gets stale, but before it expires,
racoon(8) creates a new SA. But since there is an existing entry in the
SPD, a new one is cannot made. When the old SA times out, the its
accompanying SPD entry is killed, le
(that is
not a totally idle threat either), are we going to see in-kernel
support for that anytime soon? Or is this code out there and
I just haven't seen it?
--
Crist J. Clark | [EMAIL PROTECTED]
___
freebsd-net@freebsd.org ma
have any suggestions or things to look for?
--
Crist J. Clark | [EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
(4)
node for this unless its really simple)?
(BTW, support for PPP-layer echoes seems to be required by
RFC1661. Anyone know to what extent real-world PPP implementations
really handle them correctly?)
--
Crist J. Clark | [EMAIL PROTECTED]
On Thu, Apr 28, 2005 at 08:38:01AM +1000, Neo-Vortex wrote:
>
>
> On Wed, 27 Apr 2005, Crist J. Clark wrote:
>
> > All I want to do is send an echo-request and listen for the
> > echo-reply at the PPP layer. Note that I am talking about
> > pings _at the link layer
_flags = TH_SYN;
@@ -1335,7 +1341,8 @@
struct tcphdr *const tcp = (struct tcphdr *) data;
return (ntohs(tcp->th_sport) == ident
- && ntohs(tcp->th_dport) == port + seq);
+ && ntohs(tcp->th_dport) == port + (fixedPort ? 0 : seq))
+
arbitrary Ethernet source addresses are not compati-
ble with bridging."
And I have not been able to figure out if the rl(4) device satisfies
those conditions. I should note that rl(4) was not on the list of
working cards prior to the change in the manpage.
Maybe someone who knows more ab
device (dc0). At least both the sender and receiver report
the same, correct thing from tcpdump(8).
Not quite sure what to check next.
--
Crist J. Clark [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
e ? and how to fix it ?
Clean things up before you build,
# rm -rf /usr/obj/usr/src/sys/PROTON
--
Crist J. Clark [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
flushed the SAD entries does
> have new ones. However the other side of the tunnel is still using
> the old one for its tunnel to me. I would guess that that SAD would be replaced
> as well?
Why would it? The two simplex channels of a IPsec "connection" really
have very little to
On Wed, Oct 03, 2001 at 10:57:01PM +0200, Guido van Rooij wrote:
> On Wed, Oct 03, 2001 at 01:22:35PM -0700, Crist J. Clark wrote:
> > On Wed, Oct 03, 2001 at 01:00:15PM +0200, Guido van Rooij wrote:
> > > I am using Ipsec in tunnel mode. Everything works okay. Then I decide
>
domain is
generally a Bad Thing.
However, there are some reasons why some people may still need to do
this(most don't). Use the net.link.ether.inet.log_arp_wrong_iface
sysctl(8) knob.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAI
default gateways.
FreeBSD is not actually compliant on this issue.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
his
already. That is, natd(8) passes through anything it does not modify
untouched. It does not drop (any normal) packets.
But if you are still having problems, you will need to be more
specific about your natd(8) configuration, your ipfw(8) rules, your
network topology, and wha
On Thu, Nov 08, 2001 at 01:39:41PM -0800, Michael Loftis wrote:
> "Crist J. Clark" wrote:
> > On Thu, Nov 08, 2001 at 05:33:39AM -0800, Michael Loftis wrote:
> > > I'm running natd and I need to change it's behaviour slightly. it seems
> > > that if
DNS. Your machine is timing out making DNS queries.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsub
if the,
100 pass all from any to any via lo0
Rule is present unless something is broken.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: sen
On Fri, Nov 09, 2001 at 02:17:47AM -0800, Luigi Rizzo wrote:
> On Thu, Nov 08, 2001 at 03:38:11PM -0800, Archie Cobbs wrote:
> > Crist J. Clark writes:
> > > The issue may be that you wish to make a decision on the packet in
> > > later rules. For example, someone migh
y log ip from any to any
Which seems a bit unweildy. Each single 'pass' or 'deny' rule from the
first example has become several rules. Then again, I may be
overlooking a much easier way to write these.
--
Crist J. Clark | [EMAIL PROTECTED]
return a 1). That is, inet_pton(3) only
understands dotted quads. The comments in src/lib/libc/net/inet_pton.c
clearly show this is the intended behavior. But is that what we want?
--
Crist J. Clark [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with &q
s dotted quads.
+Each
+.Dq part
+may only contain numeric characters and is always interpreted as a
+decimal value.
+.Pp
+The
.Fn inet_aton
and
.Fn inet_ntoa
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://peop
ion use a.b.c.d or
a.b.c.e as the source address? It is ambiguous and can make problems.
In your case, the addresses lie on different networks. Each address
should have the netmask of the network it is on. Note that you do not
have the above problem in this case.
--
Crist J. Clark
machine will of
course reply using the IP address the connection came in on. And a
program can always request to use a specific address if it wants to.
I am not sure where you see a problem.
--
Crist J. Clark | [EMAIL PROTECTED]
| [
f 0x has to be specified.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-ne
ssue. The selection of a
route for a packet has _nothing_ to do with the source address, only
the destination. How a packet finds its way to 192.168.0.20 is the
same no matter what the source address is. 192.168.0.20 is local to
the interface A, so it is sent dire
On Tue, Oct 09, 2001 at 02:20:02AM -0700, Crist J. Clark wrote:
[snip]
> On the wire and the packets never get routed to the "real" 172.16.0.1.
> Trying to figure out if,
>
>a) This is the expected behavior, but is poorly documented, or
>b) Something is br
rking layer to deal with this (potentially
> introducing some latency) as opposed to letting the application ?
I think Mike probably meant the transport layer, not application,
since he was talking about TCP. The transport layer is the right place
to do this.
--
Crist J. Clark
On Fri, Oct 12, 2001 at 03:31:42PM -0700, Crist J. Clark wrote:
> On Fri, Oct 12, 2001 at 12:13:59PM -0400, Mike Tancsa wrote:
> > At 06:16 PM 10/11/01 -0700, Archie Cobbs wrote:
> >
> > >If the forwarding path is maxed out, then it is the application layer's
&g
of --
Try,
map xl0 172.27.0.0/23 -> x.x.x.x/32 proxy port ftp ftp/tcp
map xl0 172.27.0.0/23 -> x.x.x.x/32 portmap tcp/udp auto
map xl0 172.27.0.0/23 -> x.x.x.x/32
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED
implemented NOARP but in the different way.
See PR 31873.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "
for security, you need to have static tables on _both_
machines or a man-in-the-middle attack is still possible. (And in any
case, MAC addresses are trivial to spoof.)
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://pe
ce we never ARP for any other addresses, the
packets are blocked before we ARP for them, we never get other entries
in the ARP table.
At least I think this should do what you want. I still am not quite
sure what a "one-way ARP" is supposed to gain.
--
"It's always
gets hurt. Then it's hilarious."
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
3) The BSD laptop gets the packet and sends back a response,
192.168.0.3 -> 192.168.0.1 SYN-ACK
4) The Win2k machine receives the packet, but since it hasn't tried
to initiate a connection to 192.168.0.3,
192.168.0.1 -> 192.168.0.3 RST
See
ured your problem was, but I never got around to
asking for you to check it.
'fwd' rules _deliberately_ do not actually modify any data in the
packet. You are looking for something more like NAT. natd(8) may be
overkill for your needs. There are other, more lightweight TCP
forwarders in t
ORT?
Sure. Why are you using ipf(8) (well, I guess ipnat(8) actually) to
forward connections to the jail? Why don't you give the jail the IP
address that people are trying to connect to? This makes the NAT games
unecessary.
--
"It's always funny until someone gets hurt. Then it&
e packets to 127.0.0.1, the local
machine, it is not an issue. The packets will be "accepted" by the
system. (But that doesn't mean the application will behave well.)
--
"It's always funny until someone gets hurt. Then it's hilarious."
Crist J. C
l poster was doing?
--
"It's always funny until someone gets hurt. Then it's hilarious."
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
o do a similar thing
> on FreeBSD.
# ifconfig fxp0 inet 10.1.1.1 alias
--
"It's always funny until someone gets hurt. Then it's hilarious."
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.
sctl net.inet.ip.fw.enable net.inet.ipf.fr_running
And see the full output of,
$ netstat -s -p udp
$ netstat -an -p udp
$ host testhost# your DNS test here
$ netstat -s -p udp
$ netstat -an -p udp
--
"It's always funny unt
that broadcasts originate on 10.1.5.0/24, but nothing
> appears on the other nets.
>
> Suggestions where to look?
Uh, nowhere? That is the required behavior. 255.255.255.255 is the
_local_ broadcast address. It never crosses a router.
--
"It
EWALL_FORWARD has nothing to do with NAT.
> Are there some things to take care of, when using FIREWALL_FORWARD ?
Yes, but nothing to do with NAT.
> Does the logic for firewall rules change, or could I still use the
> templates in /etc/rc.firewall ???
For wha
On Mon, Jan 14, 2002 at 09:40:23AM +0100, Andreas Klemm wrote:
> On Sun, Jan 13, 2002 at 11:25:41PM -0800, Crist J . Clark wrote:
> > On Sun, Jan 13, 2002 at 11:56:36AM +0100, Andreas Klemm wrote:
> > > I found a document describing a firewall design only using natd
>
eed to run a BOOTP or DHCP service to do the forwarding. See
bootpgw(8) which is in the base system or dhcrelay(8) is part of the
DHCPD port.
--
"It's always funny until someone gets hurt. Then it's hilarious."
Crist J. Clark
The other sysctl(8) you may be interested in is,
net.inet.ip.redirect
Which controls whether a router sends redirects.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
; net.inet.icmp.log_redirect: 1 -> Logging ICMP Redirect
>
> Problem Cases:
>
> BSDHost/WinHost and Router
>
> The Router send a ICMP Redirect, but not only once, every time a icmp packet
> is recived. The BSDHost doesn't add the routing table.
Run,
# tcpdum
t; fxp0: flags=8843 mtu 1500
> inet 172.16.1.12 netmask 0x broadcast 172.16.255.255
> inet 172.16.1.11 netmask 0x broadcast 172.16.255.255
> inet 172.16.1.254 netmask 0x broadcast 172.16.255.255
> inet 172.16.1.10 netmask 0x
2.24.0.100: icmp: echo request
> 10:57:59.848683 172.16.224.24 > 172.24.0.100: icmp: echo request
> 10:57:59.848707 172.16.1.12 > 172.16.224.24: icmp: redirect 172.24.0.100 to
> host
> 172.16.1.252
You still didn't provide the info for the BSDHost. My best guess is
that
3600
> > or
> > ipfw add ... keepstate setup timeout-syn 50
> >
> > Perhaps I can do this stuff if there are no objections ?
I've got CURRENT patches to do this at the site in the .sig. My STABLE
ones bitrotted (the CURRENT ones might be pass
tion: is there a way to modify ipnat
> rules without breaking existing connections?
With ipnat(1)? Yes.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscri
25428, len 1500) (ttl 253, id
>2491, len 56)
> ^^
> Router say to server that he must to decrease packet size
Is "router" the same IP address that "server" has as the route to
"client?" That is, there aren't any aliases on "router's"
t, but ICMP _is_ also part of IP in the sense that any
compliant IP implementation must understand ICMP.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscri
.2 from finding its way out through the default
route. I would naively expect to get "host is down" when I ping
127.0.0.2. Something is broken now. Like someone else in the thread
already mentioned, there is probably some really complicated history
behind how this has come to be, but
rule for _2200._
8) SYN-ACK goes through rules on way out and again matches 2200.
Notice, the returning packets never hit the dynamic rule from 2400.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
urrent/freebsd-net
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ybe taking two or three packets from the DIVERT buffer per kernel
> loop.
>
> (i'm not an expert at this by ny means - so useful help would be great!)
Look in sys/netinet. ip_divert.c, ip_input.c, and ip_output.c are good
starts.
--
Crist J. Clark
their machine in an unconventional
> way, why automatically assume they are doing something wrong?
>
> My vote is to not have any special cases in the kernel for 127/8...
> rc.conf, rc.network, rc.firewall, et. al. is fine, but nothing
> in the kernel.
You definately
On Mon, Feb 18, 2002 at 08:43:45PM -0800, Archie Cobbs wrote:
> Crist J. Clark writes:
> > No, RFC1122 is a set of requirements for hosts implementing _the
> > Internet protocol._
>
> OK...
>
> > > By your argument, the kernel should also block admin att
On Tue, Feb 19, 2002 at 10:25:13AM +0200, Ruslan Ermilov wrote:
> On Mon, Feb 18, 2002 at 11:35:54PM -0800, Crist J. Clark wrote:
[snip]
> > I'd personally prefer someone just fix lo0 so that,
> >
> > $ ifconfig lo0 inet 127.0.0.1
> >
> > Ac
aders.
That rule sure looks like it is explicitly passing invalid
traffic. Unless someone can enlighten my ignorance here, I'm going to
nuke that rule.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebs
ination address is
robust. I have not examined the IPv6 code in this respect.
After the fix to FreeBSD is made and other *BSD's have ample time to
responde, I do plan to send a quick note on the subject to Bugtraq.
Thanks for reading. I look forward to comments on the fix.
--
Crist J
still trying to figure out how
mutt came up with that header. Thanks.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
;.
Then I would put that under the "misconfigured" header. The machine
you are pinging from would have to be local to 192.168.4.0/24 also,
why are you routing it through 192.168.1.1? But there may be some
situations that I have not considered where one might wish to do
that
function as used in the patch you sent is different
than the current implementation. in_broadacast() currently takes an
address and an interface. If you are correct, we'd have to loop
through the interface list... which makes this uglier.
--
Crist J. Clark | [EMAIL PROTE
On Sun, Feb 24, 2002 at 10:49:21AM +0200, Ruslan Ermilov wrote:
> On Sat, Feb 23, 2002 at 03:49:55PM +0300, Maxim Konovalov wrote:
> > On 04:28-0800, Feb 23, 2002, Crist J. Clark wrote:
> >
> > > On Sat, Feb 23, 2002 at 01:50:33PM +0200, Ruslan Ermilov wrote:
> &g
On Sun, Feb 24, 2002 at 10:47:02AM +0200, Ruslan Ermilov wrote:
> On Sat, Feb 23, 2002 at 07:25:20AM -0800, Crist J. Clark wrote:
[snip]
> > If you are correct, and you can cross interfaces, this is a much
> > bigger problem. I didn't mention it in your first mail, but
tuff. Duplicating the TCP and UDP
code in both would present an opportunity for drift and be difficult
to maintain.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Un
rfaces on the same network with different IPs
> realIP1
> realIP2
You will need to run an individual instance of natd(8) for each
external physical interface.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebs
default
syslog.conf(5), those messages will be in /var/log/messages.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
wit
the input, and the same perl command gives,
...
0x94a4
0xe8f1
0x3530
Which is correct, the ones-complement of 0xcacf.
Looks like your calculations are wrong.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://
> this on a Sparc (or Alpha?) because of their endian is network byte
> order.
Well... It depends. Due to the nature of the checksum algorithm, it
really doesn't matter whether the data is in host order or network
order provided all of the data is stored consisten
ipfw: 65435 Deny ICMP:5.0 router.ip.address host.ip.adress in via xl0
Run,
# tcpdump -nvv -ixl0 'icmp'
To see what packets are generating the redirects. You may wish to
change your routing accordingly.
--
Crist J. Clark | [EMAIL PROTECTED]
om all those networks?
You can run multiple natd(8)s and control which block each one
translates with their firewall divert(4) rules.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/
On Tue, Mar 19, 2002 at 02:31:12PM +0700, Eugene Grosbein wrote:
> "Crist J. Clark" wrote:
>
> > > Suppose we have many tens of separated private networks each having its own
> > > public address and own gateway. Is is possible to configure natd to do
> >
arched the web and found that under linux there are kernel modules, like
> ip_masq_quake.
>
> How could i make it under freebsd?
If it requires an application layer proxy, and you are using ipnat(8),
you can go look for IPFilter resources like,
[EMAIL PROTECTED] If you want to change to natd(8), yo
On Tue, Mar 19, 2002 at 04:26:19PM +0700, Eugene Grosbein wrote:
> "Crist J. Clark" wrote:
>
> > > Would it be hard to implement this?
> >
> > Probably not too bad. Apparently no stampede for this functionality
> > though. There usually is not a lo
pt it gets translated to
192.0.2.12. Isn't that what you wanted?
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
p]
> Should it be done so?
No. It now correctly flags the error. Thanks for tracking down the
code that did it.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
operating system?
Are you saying when you try to add the route again,
# route add default
It doesn't actually show up in the routing table?
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cj
fciations. It does some very hackish things with BPF devices and
clobbering MAC addresses. If someone wants to do this The Right Way,
some of it definately needs to live in the kernel.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAI
are settable
> for each VRID.
IIRC, the exact MAC address of the virtual router as a function of
VRID is specified in the RFC?
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL
ould
be a really good way to try to implement it.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscri
me host.
> My wish is to implement VRRP as clean as I can but there is some
> limitations...
> Any idea to implement that correctly under FreeBSD ?
One point. I don't see any reason to maintain the separate xl[01]
interfaces with other MAC addresses in this example.
--
Crist J. Clar
ing here. I think it is a
language and terminology barrier. What is a "real alias?"
> Then, I need to write a new node called ng_alias for example and use it for
> doing this staff.
>
> But perhaps I'm wrong with that or with RFC2338. If this is the case, can
> you correct
have never seen terribly bad effects when cvsupping
> and doing other things. If there is something which goes to its
> knees, this is the disk.
On a previous Internet provider, I had silent PMTU issues somewhere
downstream. Ploss went through the roof when you got above 1
way or
another) using a 'fwd' rule. There still are some tricks to doing
this, but it's quite doable.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
t.
>
> Yeh, I thought of that. The problem is packets never leave
> anywhere since the route for the other NIC is not "OUT" any
> interface...it is the machine itself.
Then never go over a _physical_ inteface, but they _do_ cross an
int
On Sun, Apr 07, 2002 at 08:25:33PM -0500, Nick Rogness wrote:
>
> >On Sat, 6 Apr 2002, Crist J. Clark wrote:
> >> On Sat, Apr 06, 2002 at 01:57:44PM -0600, Nick Rogness wrote:
> >>
> >>> On Fri, Apr 05, 2002 at 06:48:09PM -0600 I heard the voice of
>
this? (so that conversation between hostA and
> hostB ended normally)
If hostB's stack is really broken, not sure what to do to fix it.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
to use ngctl to
> configure step by step). Has anybody a sample configuration or a example?
ipfw(8) will filter with bridge(4) just fine. I have a simple patch on
the website below to get ipf(8) to filter with bridge(4) too.
--
Crist J. Clark | [
On Fri, Apr 12, 2002 at 09:34:50AM -0700, Michael Sierchio wrote:
> Crist J. Clark wrote:
>
> > ipfw(8) will filter with bridge(4) just fine. I have a simple patch on
> > the website below to get ipf(8) to filter with bridge(4) too.
>
> Just for the sake of clarity,
s1 | | RH | | Windows3 |
> +--+ ++ +--+
>
> What I would like to be able to do is somehow send copies of
> network traffic to the RH box without having to move it
> between the FreeBSD box and the switch. Is this possible
> and if so, how would I go a
to a particular MAC
> address, regardless of the IP destination address of the packet. Once
> again, I know BPF can do this, but then I have similar concerns to the ones
> above. For example, what do I set the IP ID field to??
IP ID? Set the DF bit, then the IP ID field won't ever be
ich allows remote
> # observers to determine the rate of packet generation on the
> # machine by watching the counter.
> options RANDOM_IP_ID
...which has absolutely nothing to do with this thread.
--
Crist J. Clark | [EMAIL PROTECTED]
acket. I read that FreeBSD is not supporting directed broadcasts
> since 2.2.5. Is there any parameter for chanching this behaviour?
Looks like it was gutted earlier than that.
The code was completely removed. You would have to go back and add it
or come up with some other hac
information.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
1 - 100 of 150 matches
Mail list logo
