https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #20 from Craig Rodrigues ---
Sorry for the late feedback. I can confirm that you fixed the problem.
This was a very weird and convoluted corner case. Thank you so
much for digging into this and fixing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
Michael Tuexen tue...@freebsd.org changed:
What|Removed |Added
Status|In Progress |Closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #19 from commit-h...@freebsd.org ---
A commit references this bug:
Author: tuexen
Date: Sat Jun 20 08:25:31 UTC 2015
New revision: 284633
URL: https://svnweb.freebsd.org/changeset/base/284633
Log:
MFC r284515:
Add FIB
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #18 from Michael Tuexen tue...@freebsd.org ---
(In reply to Craig Rodrigues from comment #17)
Ahh. Thanks for the hint. Will do.
Best regards
Michael
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #16 from Michael Tuexen tue...@freebsd.org ---
(In reply to Alan Somers from comment #15)
Yes, you can failover from one ISP to another. Currently this is done by having
corresponding entries in a single routing table for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #14 from Michael Tuexen tue...@freebsd.org ---
(In reply to Alan Somers from comment #13)
I think interfaces can assign fibs to packets, it is a field in the mbuf packet
header. It makes sense to use this information in case you
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #15 from Alan Somers asom...@freebsd.org ---
(In reply to Michael Tuexen from comment #14)
You're right about the interface FIB. It will take incoming packets with a
certain FIB. But it's not completely general; it's possible
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #13 from Alan Somers asom...@freebsd.org ---
FIBs are used to have different routing policies for different kinds of
traffic. In general, you can't correctly learn which fib you ought to use
based on any feature of a received
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #12 from Michael Tuexen tue...@freebsd.org ---
Hi Craig,
I'm in the process of understanding how fibs work and thinking about how they
should work for SCTP. So one possibility is that a socket uses a fib. So all
paths of an
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #11 from Michael Tuexen tue...@freebsd.org ---
Yes, I do. Using net.add_addr_allfibs=0, I get routing tables like you have.
However, I had to call setfib() before socket() in your examples. With that I
can reproduce the problem.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #5 from Michael Tuexen tue...@freebsd.org ---
Hi Craig,
when setting up two VMs as suggested, they can just reach each other.
Even ping 172.8.1.4 works, I don't need setfib 2 ping 172.8.1.4.
What config do I need to test the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #7 from Michael Tuexen tue...@freebsd.org ---
Here is what I do and what happens to the routing table. As you see, a route
gets added to fib 0. Is this expected? Intended?
ifconfig em0
em0:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #6 from Craig Rodrigues rodr...@freebsd.org ---
You need to set up a default IP address and routing table
on em0 that is *not* a 172 address.
That way, if you do:
netstat -r
you will see the default routing table,
and if you
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #10 from Craig Rodrigues rodr...@freebsd.org ---
(In reply to Michael Tuexen from comment #8)
Are you good to go with having an environment to repro the problem?
My routing table looks like this
FIB 0
=
netstat -nr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
Michael Tuexen tue...@freebsd.org changed:
What|Removed |Added
Status|New |In Progress
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #8 from Michael Tuexen tue...@freebsd.org ---
OK, I need
sysctl -w net.add_addr_allfibs=0
to reproduce your problem.
Best regards
Michael
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
Alan Somers asom...@freebsd.org changed:
What|Removed |Added
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #4 from Michael Tuexen tue...@freebsd.org ---
Hi Craig,
thank you very much for reporting the issue and providing steps to reproduce
the problem. I'll look into it.
Best regards
Michael
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
Craig Rodrigues rodr...@freebsd.org changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #3 from Craig Rodrigues rodr...@freebsd.org ---
In sys/netinet/sctp_os_bsd.h ,
the SCTP_RTALLOC macro calls the rtalloc_ign() function which ignores fibs.
It should probably be changed to call rtalloc_ign_fib()
In addition,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #1 from Craig Rodrigues rodr...@freebsd.org ---
Created attachment 157024
-- https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157024action=edit
server.c
--
You are receiving this mail because:
You are on the CC list for
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #2 from Craig Rodrigues rodr...@freebsd.org ---
Created attachment 157025
-- https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157025action=edit
client.c
--
You are receiving this mail because:
You are on the CC list for
22 matches
Mail list logo