Paul Vixie wrote:
> i've been thinking along these lines for a few years now, since my vm server
> is multi-fib.
> each interface has a fib, mostly zero. for incoming TCP SYNs, i'd like to
> carry that fib# into
> the resulting PCB so that that fib's routing table and especially its default
"Bjoern A. Zeeb" wrote:
> I wonder if anyone on FreeBSD is using FIBs to actually have multi-FIB
> forwardig but that very little touches your use case apart from the mgmt
> which again can be factored out better (or inversely, factoring out the
> forwarding).
>
> I would honestly know who and h
Mike Karels wrote:
> Here, interface-name was a placeholder for the current name of the
> interface. My newer code prints "drivername: igb1" at the end of
> the list of values for "ifconfig $interface-name" or "ifconfig -a"
> if the -D option is given. I decided that it was better to be able
>
Kristof Provost wrote:
>
> I believe a similar solution has been proposed before, and it failed to cope
> with things like epair interfaces.
>
> I’d look in the direction of just adding a field to struct ifnet with the
> original interface name (likely easily done in if_attach()), along with a n
Mike Karels wrote:
> I have a proof of concept that makes the presumed original name
> (driver name + unit number) available to ifconfig, which prints
> the string with everything else in the standard output format.
> I don't think that is the right solution, but the other details
> should be eas
Baptiste Daroussin wrote:
> No it was not sent to the whole list but only to the people whom mail server
> have bounced an incoming mail.
Apologies. I should have checked the header more closely. I've never had one
of these before, and I received one the same time as I saw the posting from
Matth
bob prohaska wrote:
> It is tempting to think USB saturation would account
> for the trouble. A tool similar to gstat, but for
> USB as a whole, would be helpful if it exists.
Would this do?
/usr/ports/sysutils/usbtop
bob prohaska wrote:
> That seems worth a try.
> The notion of an ssh escape (~. in this case) finding its way into the data
> stream is new to me.
Thinking again, that looks like corruption coming down the ssh connection.
For the ssh escape char to affect anything (note it needs to be preceeded
bob prohaska wrote:
> I can't detect any consistent pattern. For a while I thought load on the
> sshd-host end made a difference, but the latest disconnect was on an idle
> system with serial console output the only traffic on the dropped connection.
Could it be that the serial connection is se
Gleb Smirnoff wrote:
> On Thu, Jan 13, 2022 at 10:30:10AM -0800, Gleb Smirnoff wrote:
> T> Sorry, the stats I was talking about are present in CURRENT only:
Yeah, sorry, I saw your other post about that after posting mine.
> Sorry, I actually can't merge it to stable, as it changes size of tcps
Gleb Smirnoff wrote:
> modern HTTP server can be lowered 3 times more. Feel free to lower
> net.inet.tcp.msl and do your own measurements with
> 'netstat -sp tcp | grep TIME-WAIT'. I'd be glad to see your results.
Without changing net.inet.tcp.msl I get:
| 18:18 (46.0°C 1100) (2) "/tmp
"Rodney W. Grimes" wrote:
> > Note, the default FreeBSD firewall rules already have:
> >
> > ${fwcmd} add 100 pass all from any to any via lo0
> > ${fwcmd} add 200 deny all from any to 127.0.0.0/8
> > ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
>
> Which no longer work correctly
Oleksandr Kryvulia wrote:
> 04.11.21 01:01, Mike Karels пишет:
> > I have a pending change to stop using class A/B/C netmasks when setting
> > an interface address without an explicit mask, and instead to use a default
> > mask (24 bits). A question has arisen as to what the default mask should
Mike Karels wrote:
> Comments are welcome on the review. I will wait a couple of days
> for comments before proceeding. I am also interested in comments on
> whether this should be MFC'ed to 13-stable after a suitable delay.
Personally, if an MFC isn't too timeconsuming to do, and there are no
For what it's worth, as soon as you do sort out protocol 41 through
your NAT, Hurricane Electric works a charm on FreeBSD. I've been
using it for years...
Cheers, Jamie
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/f
> I would like to try BBR under FreeBSD.
>
> I'm willing to try anything experimental as well. Could someone please
> suggest what is the latest patch available for this. The last patch I came
> across is:
> https://reviews.freebsd.org/D15525
>
> Could someone please confirm if there is anything la
"Ronald F. Guilmette" wrote:
> As I have already learned, the /etc/rc.firewall script also assumes both the
> presence of, and the desirability of IPv6 support. And unless one edits that
> file manually... which I have been effectively forced to do... there is no way
> to get it to simply NOT cr
Karl Denninger wrote:
> I'm connecting to:
>
> [karl@NewFS ~]$ ping6 svn.freebsd.org
> PING6(56=40+8+8 bytes) 2600:8807:8600:7941:230:48ff:fe9f:1d6 -->
> 2610:1c1:1:606c::e6a:0
> 16 bytes from 2610:1c1:1:606c::e6a:0, icmp_seq=0 hlim=54 time=58.461 ms
> 16 bytes from 2610:1c1:1:606c::e6a:0, icmp_s
Karl Denninger wrote:
> Since I can't find evidence of a FreeBSD problem internally this is more
> of a "is anyone else seeing this on Cox?" sort of request; what I find
> especially interesting, however, is that it /always /happens when
> talking to Project machines for updates whether for packa
Victor Sudakov wrote:
> Andrey V. Elsukov wrote:
> >
> > Seems your ifconfig(8) is a bit out of day.
>
> My ifconfig(8) is from 11.2-RELEASE.
> > My manual says:
> > autoconf
> > Set the IPv6 autoconfigured address bit.
> >
> > -autoconf
> > Clear the IPv6 a
Brooks Davis wrote:
> On Fri, Oct 05, 2018 at 04:18:22PM +0100, Jamie Landeg-Jones wrote:
> > Remember, it's not simply deprecating cards less than 1Gig.
> >
> > I have a card that is 10/100 only, but works fine with the gigabit alc
> > driver:
> &
Remember, it's not simply deprecating cards less than 1Gig.
I have a card that is 10/100 only, but works fine with the gigabit alc driver:
alc0: port 0x2000-0x207f mem
0xe050-0xe053 irq 16 at device 0.0 on pci1
cheers, jamie
___
freebsd-net@f
"Ronald F. Guilmette" wrote:
> In message <201803241747.w2ohlupr069...@donotpassgo.dyslexicfish.net>,
> Jamie Landeg-Jones wrote:
>
> >Have you thought of examining the TCP timestamp field? Not necessarily
> >for accurate uptime, but a way to determine
Have you thought of examining the TCP timestamp field? Not necessarily for
accurate uptime, but a way to determine if the hosts are the same.
Or some of the other fingerprinting methods? nmap has options for uptime and
other fingerprinting : https://nmap.org/book/osdetect-usage.html
Of course,
Christopher Bailey wrote:
> I’m an undergraduate computer science student at the University of
> Alaska Fairbanks. I’m interested in unifying ping and ping6 into a
> single command, because it’s one of the suggested ideas on the wiki,
> it’s something that’s mildly irritated me in the past, and I
Thomas Steen Rasmussen wrote:
> $ sudo route delete 185.96.180.10
> route: writing to routing socket: Address already in use
> delete host 185.96.180.10 fib 0: gateway uses the same route
I think this is the cause:
https://reviews.freebsd.org/D12747
https://bugs.freebsd.org/bugzilla/show_bug.c
26 matches
Mail list logo
