> On Nov 9, 2022, at 14:32, Patrick M. Hausen wrote:
>
>> Am 08.11.2022 um 06:38 schrieb Chris Ross :
>> I have a newer Freebsd 12.3 system with lagg across two 1gbe interfaces.
>> There are a collection of vlan interfaces on the lagg.
>>
>> I would _expect_ to be able to get 2gbps, or just
Hi all,
> Am 08.11.2022 um 06:38 schrieb Chris Ross :
> I have a newer Freebsd 12.3 system with lagg across two 1gbe interfaces.
> There are a collection of vlan interfaces on the lagg.
>
> I would _expect_ to be able to get 2gbps, or just shy thereof.
You are aware that LAGG/LACP will give yo
On Tue, Nov 08, 2022 at 12:38:54AM -0500, Chris Ross wrote:
> Tl;dr; I have two FreeBSD systems attached to a Cisco switch, there should be
> multi-gigabit connectivity, but only seeing 1Gpbs. Each system is trunked,
> vlan interfaces on the underlying interface.
I can add another data point:
Tl;dr; I have two FreeBSD systems attached to a Cisco switch, there should be
multi-gigabit connectivity, but only seeing 1Gpbs. Each system is trunked,
vlan interfaces on the underlying interface.
I have an older Freebsd 11.x system with a 10gbe interface, There are a
collection of vlan inter
I need to forward incoming TCP connections made to my host 192.168.5.3
on the port 3100 to the IP address 10.0.0.101 port 3000 connected
through another interface.
These rules work when connection is made from a remote host:
ipfw -q nat 19001 config redirect_port tcp 10.0.0.101:3000 192.168.5
I created a new patch on reviews.freebsd.org
https://reviews.freebsd.org/D17411
I need to wait for mentor's approval before writing to re@
Thanks,
Vincenzo
Il giorno gio 4 ott 2018 alle ore 17:25 Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> ha scritto:
> > Hi Rodney,
> > Sure. Is
> Hi Rodney,
> Sure. Is there a specific procedure for this, or should I just send the
> .diff to r...@freebsd.org?
Yes, there is a procedure:
https://wiki.freebsd.org/Releng/ChangeRequestGuidelines
the specific details for when the release is ^head is
towards the bottom.
Thanks again,
>
> Th
Hi Rodney,
Sure. Is there a specific procedure for this, or should I just send the
.diff to r...@freebsd.org?
Thanks,
Vincenzo
Il giorno gio 4 ott 2018 alle ore 17:03 Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> ha scritto:
> > Hi,
> > I fixed this upstream in this commit
> >
> h
> Hi,
> I fixed this upstream in this commit
> https://github.com/luigirizzo/netmap/commit/282f404ccb4fc777056a591127060e29657c9ab7
> I will apply the change into FreeBSD as soon as HEAD thaws.
This appears to be a man page change only,
please do submit that to r...@freebsd.org to be
committed n
Hi,
I fixed this upstream in this commit
https://github.com/luigirizzo/netmap/commit/282f404ccb4fc777056a591127060e29657c9ab7
I will apply the change into FreeBSD as soon as HEAD thaws.
Cheers,
Vincenzo
Il giorno gio 4 ott 2018 alle ore 00:36 K. Macy ha
scritto:
> On Fri, Aug 31, 2018 at 6:
On Fri, Aug 31, 2018 at 6:50 PM John-Mark Gurney wrote:
>
> First, does vale work for anyone? At least one of the documented
> commands in vale(4) does not work.
>
The documentation with respect to naming is wrong. I didn't have a bit
when I was using it so never got around to fixing it.
> Afte
Il giorno gio 6 set 2018 alle ore 08:35 Marko Zec ha scritto:
> On Wed, 5 Sep 2018 17:42:06 -0700
> John-Mark Gurney wrote:
>
> > Marko Zec wrote this message on Wed, Sep 05, 2018 at 12:47 +0200:
> > > On Wed, 5 Sep 2018 12:36:38 +0200
> > > Vincenzo Maffione wrote:
> > >
> > > > Hi Marko,
> >
On Wed, 5 Sep 2018 17:42:06 -0700
John-Mark Gurney wrote:
> Marko Zec wrote this message on Wed, Sep 05, 2018 at 12:47 +0200:
> > On Wed, 5 Sep 2018 12:36:38 +0200
> > Vincenzo Maffione wrote:
> >
> > > Hi Marko,
> > > Thanks a lot for identifying the problem.
> > > If I understand correctl
Marko Zec wrote this message on Wed, Sep 05, 2018 at 12:47 +0200:
> On Wed, 5 Sep 2018 12:36:38 +0200
> Vincenzo Maffione wrote:
>
> > Hi Marko,
> > Thanks a lot for identifying the problem.
> > If I understand correctly, simply adding -D VIMAGE here
> > https://github.com/luigirizzo/netmap/blo
On Wed, 5 Sep 2018 12:36:38 +0200
Vincenzo Maffione wrote:
> Hi Marko,
> Thanks a lot for identifying the problem.
> If I understand correctly, simply adding -D VIMAGE here
> https://github.com/luigirizzo/netmap/blob/master/sys/modules/netmap/Makefile#L11
> would at least mitigate the issue.
>
Hi Marko,
Thanks a lot for identifying the problem.
If I understand correctly, simply adding -D VIMAGE here
https://github.com/luigirizzo/netmap/blob/master/sys/modules/netmap/Makefile#L11
would at least mitigate the issue.
If you think I'm right I'll just add it.
Thanks,
Vincenzo
Il giorno m
On Tue, 4 Sep 2018 20:18:29 +0200
Vincenzo Maffione wrote:
> Hi,
> I don't think the panic depends on the architecture. Also, it does
> not depend on using emulated mode or not.
> We have seen this happening on x86_64 on FreeBSD 12 head.
>
> As John-Mark says, kdloading netmap.ko is not enough
Hi,
I don't think the panic depends on the architecture. Also, it does not
depend on using emulated mode or not.
We have seen this happening on x86_64 on FreeBSD 12 head.
As John-Mark says, kdloading netmap.ko is not enough. You need to open a
netmap port corresponding
to any network interface,
Marko Zec wrote this message on Tue, Sep 04, 2018 at 16:43 +0200:
> On Sat, 1 Sep 2018 14:11:23 -0700
> John-Mark Gurney wrote:
> > Vincenzo Maffione wrote this message on Sat, Sep 01, 2018 at 22:25
> > +0200:
> ...
> > > On x86_64 netmap is not built as a module, so everything works
> > > fine. I
On Sat, 1 Sep 2018 14:11:23 -0700
John-Mark Gurney wrote:
> Vincenzo Maffione wrote this message on Sat, Sep 01, 2018 at 22:25
> +0200:
...
> > On x86_64 netmap is not built as a module, so everything works
> > fine. I don't see any reason why it should be a module in aarch64.
>
> Well, sys/mod
Il giorno sab 1 set 2018 alle ore 23:11 John-Mark Gurney
ha scritto:
> Vincenzo Maffione wrote this message on Sat, Sep 01, 2018 at 22:25 +0200:
> > Il giorno sab 1 set 2018 alle ore 03:50 John-Mark Gurney <
> j...@funkthat.com>
> > ha scritto:
> >
> > > First, does vale work for anyone? At leas
Vincenzo Maffione wrote this message on Sat, Sep 01, 2018 at 22:25 +0200:
> Il giorno sab 1 set 2018 alle ore 03:50 John-Mark Gurney
> ha scritto:
>
> > First, does vale work for anyone? At least one of the documented
> > commands in vale(4) does not work.
> >
> > After manually building the net
Il giorno sab 1 set 2018 alle ore 03:50 John-Mark Gurney
ha scritto:
> First, does vale work for anyone? At least one of the documented
> commands in vale(4) does not work.
>
> After manually building the netmap module and loading it:
> # tcpdump -ni vale-a:1
> 313.748851 nm_open [947] invalid b
First, does vale work for anyone? At least one of the documented
commands in vale(4) does not work.
After manually building the netmap module and loading it:
# tcpdump -ni vale-a:1
313.748851 nm_open [947] invalid bridge name vale-a:1
tcpdump: netmap open: cannot access vale-a:1: Invalid argument
On 04/03/18 12:54, Andrey V. Elsukov wrote:
On 03.04.2018 13:45, Andrey V. Elsukov wrote:
Can anybody give any hint about the above behaviours or point me to good
documentation? The man pages is very brief on this, unfortunately.
Hi,
ipfw uses M_SKIP_FIREWALL flag for self-generated packets.
--- Original Message ---
From: "Andrea Venturoli"
Date: 7 April 2018, 17:19:00
> On 04/03/18 12:54, Andrey V. Elsukov wrote:
> > On 03.04.2018 13:45, Andrey V. Elsukov wrote:
> >>> Can anybody give any hint about the above behaviours or point me to good
> >>> documentation? The man pages
On 04/03/18 12:54, Andrey V. Elsukov wrote:
On 03.04.2018 13:45, Andrey V. Elsukov wrote:
Can anybody give any hint about the above behaviours or point me to good
documentation? The man pages is very brief on this, unfortunately.
Hi,
Thanks for your answer.
ipfw uses M_SKIP_FIREWALL flag
05.04.2018 16:53, Julian Elischer wrote:
> why not just use the ng-pppoe node? :-)
Well, I do not need full-blown pppoe session nor interface configuration,
only send thousands oe broadcasts then collect all replies, period.
Low-overhead solution is preferred.
___
On 22/3/18 3:08 am, Eugene Grosbein wrote:
22.03.2018 1:08, Ronald F. Guilmette wrote:
OK, so, if I have understood all that has been said in this thread so
far, then I would assert that, from the perspective of a simple-minded
and naive end user (e.g. me), the assertion that I originally quote
On 03.04.2018 13:45, Andrey V. Elsukov wrote:
>> Can anybody give any hint about the above behaviours or point me to good
>> documentation? The man pages is very brief on this, unfortunately.
>
> Hi,
>
> ipfw uses M_SKIP_FIREWALL flag for self-generated packets. Thus
> keep-alive packets are sent
On 03.04.2018 13:15, Andrea Venturoli wrote:
> Test 3: let's introduce NAT
>
>> ipfw add 99 skipto 1 tcp from any to external-host http setup
>> keep-state
>
> (skipto 1 is used to allow nat rules).
> With the same external host as before, now the rule times out!
>
> Test 5: fwd to a ja
Hello.
I'm trying to find out how dyn_keepalive works.
From ipfw(8):
net.inet.ip.fw.dyn_keepalive: 1
Enables generation of keepalive packets for keep-state rules on
TCP sessions. A keepalive is generated to both sides of the con-
nection every 5 seco
On 2018-Mar-21 13:50:26 -0700, "Ronald F. Guilmette"
wrote:
>
>In message <5ab2c0b1.3020...@grosbein.net>,
>Eugene Grosbein wrote:
>
>>It does not mean you need to stick with raw sockets API.
>>libpcap can be used too, as I've shown in previous letter.
>
>Thank you. If zmap ends up not suiting
In message <5ab2c0b1.3020...@grosbein.net>,
Eugene Grosbein wrote:
>It does not mean you need to stick with raw sockets API.
>libpcap can be used too, as I've shown in previous letter.
Thank you. If zmap ends up not suiting my needs, I will
definitely look into libpcap.
_
22.03.2018 3:03, Ronald F. Guilmette wrote:
>> Why should you concentrate on RAW sockets?
>
> Well, for reasons that are completely legitimate, and that I'll
> explain in detail, if anyone is seriously interested, I'd like
> to check each IPv4 address within a set of about 90 or so
> modest sized
In message <5ab2ad9f.6040...@grosbein.net>,
Eugene Grosbein wrote:
>Why should you concentrate on RAW sockets?
Well, for reasons that are completely legitimate, and that I'll
explain in detail, if anyone is seriously interested, I'd like
to check each IPv4 address within a set of about 90 or s
22.03.2018 1:08, Ronald F. Guilmette wrote:
> OK, so, if I have understood all that has been said in this thread so
> far, then I would assert that, from the perspective of a simple-minded
> and naive end user (e.g. me), the assertion that I originally quoted
> -is- in fact correct, i.e. one -cann
22.03.2018 0:38, Ronald F. Guilmette пишет:
>
> In message <5ab1a9c5.9050...@grosbein.net>,
> Eugene Grosbein wrote:
>
>> 21.03.2018 3:09, Ronald F. Guilmette wrote:
>>>
>>> https://stackoverflow.com/questions/7048448/raw-sockets-on-bsd-operating-
In message <5ab23fb9.7050...@grosbein.net>,
Eugene Grosbein wrote:
>On 21.03.2018 10:55, Matt Joras wrote:
>> Saying "Not for FreeBSD" is needlessly confusing and not accurate. In
>> the common parlance "raw sockets" does not refer to libdnet, which is
>> not a part of the FreeBSD base system.
In message <5ab1a9c5.9050...@grosbein.net>,
Eugene Grosbein wrote:
>21.03.2018 3:09, Ronald F. Guilmette wrote:
>>
>> https://stackoverflow.com/questions/7048448/raw-sockets-on-bsd-operating-systems
>> "Using raw sockets isn't hard but it's no
;m going to be doing some stuff with raw sockets pretty soon, and
>>>> while scrounging around, looking for some nice coding examples, I
>>>> found the following very curious comment on one particular message
>>>> board:
>>>>
>>>>
>>>&g
r message
>>>>> board:
>>>>>
>>>>>
>>>>> https://stackoverflow.com/questions/7048448/raw-sockets-on-bsd-operating-systems
>>>>>
>>>>> "Using raw sockets isn't hard but it's not entir
ing some stuff with raw sockets pretty soon, and
>>>> while scrounging around, looking for some nice coding examples, I
>>>> found the following very curious comment on one particular message
>>>> board:
>>>>
>>>>
>>>> htt
round, looking for some nice coding examples, I
>>> found the following very curious comment on one particular message
>>> board:
>>>
>>>
>>> https://stackoverflow.com/questions/7048448/raw-sockets-on-bsd-operating-systems
>>>
>>> &qu
llowing very curious comment on one particular message
>> board:
>>
>>
>> https://stackoverflow.com/questions/7048448/raw-sockets-on-bsd-operating-systems
>>
>> "Using raw sockets isn't hard but it's not entirely portable. For
>>
https://stackoverflow.com/questions/7048448/raw-sockets-on-bsd-operating-systems
>
> "Using raw sockets isn't hard but it's not entirely portable. For
> instance, both in BSD and in Linux you can send whatever you want,
> but in BSD you can't rec
I'm going to be doing some stuff with raw sockets pretty soon, and
while scrounging around, looking for some nice coding examples, I
found the following very curious comment on one particular message
board:
https://stackoverflow.com/questions/7048448/raw-sockets-on-bsd-operating-sy
AFAIK, No.
-Meny
-Original Message-
From: freebsd-commits-tracker
Sent: Tuesday, January 23, 2018 12:11 AM
To: Meny Yossefi ; Slava Shwartsman ;
Hans Petter Selasky ; Konstantin Belousov
Subject: FW: Questions on OFED in FreeBSD
From
Hi Meny,
Does OFED in FreeBSD currently support NvMe over Fabrics ?
Thanks
David S.
-Original Message-
From: Meny Yossefi [mailto:me...@mellanox.com]
Sent: Tuesday, January 16, 2018 5:27 AM
To: Somayajulu, David ; freebsd-net@FreeBSD.org
Subject: RE: Questions on OFED in FreeBSD
Hi
v3.10 if I'm not
mistaken.
Last big update in FreeBSD12 was based on Linux v4.9.
Hopefully we can MFC it completely to FreeBSD11-STABLE.
Last but not least - Yes, HEAD supports RoCEv2.
Meny
Hi Meny,
Thanks a lot for the reply and the information.
I have couple of additional questions.
Hi Meny,
Thanks a lot for the reply and the information.
I have couple of additional questions.
> 4. Am I correct that the OFED version on FreeBSD 11 is 1.5.3 ?
>[MY] No. We did an upgrade in FreeBSD11 a while back. If I'm not mistaken,
>FreeBSD11's OFED is currently based
Hi David,
Answers embedded below.
-Meny
-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On
Behalf Of Somayajulu, David
Sent: Tuesday, January 09, 2018 8:08 PM
To: freebsd-net@freebsd.org
Subject: Questions on OFED in FreeBSD
Hi,
1. Is
Hi,
1. Is RoCE v2 supported of FreeBSD 11 release or 11_stable ?
2. How does one figure out the OFED version in a FreeBSD kernel?
3. Since OFED on HEAD is synced to Linux 4.9 in kernel.org, I presume that
it is OFED version 4.8. Am I correct ?
4. Am I correct that the OFED version on
I wish FreeBSD would adopt the dhcpcd daemon from the NetBSD project
(2-clause BSD license) as a standard DHCP client for IPv4 and IPv6,
as some other OSes have done by now. It is currently available in
FreeBSD ports as net/dhcpcd.
Among other features it supports RFC 7217, i.e. stable privacy ad
On 2017/06/02 12:30, Gary Palmer wrote:
>> Assuming that you always get the same /64 assigned to your gateway, then
>> the address SLAAC assigns to your server will be constant so long as
>> you're on the same hardware, since the SLAAC address is generated from
>> the network prefix and the MAC add
On Fri, Jun 02, 2017 at 09:56:28AM +0100, Matthew Seaman wrote:
> On 06/02/17 02:49, Karl Denninger wrote:
> > Is there a dynamic DNS update method associated with Ipv6's address
> > assignment system? Since the assignment is "stateless" it obviously
> > (and does, in my experience!) move. I can
On 06/02/17 02:49, Karl Denninger wrote:
> Is there a dynamic DNS update method associated with Ipv6's address
> assignment system? Since the assignment is "stateless" it obviously
> (and does, in my experience!) move. I can deal with it via a couple of
> shell scripts, and there are only a coupl
On jeu. 1 juin 20:49:29 2017, Karl Denninger wrote:
> Is there a dynamic DNS update method associated with Ipv6's address
> assignment system? Since the assignment is "stateless" it obviously
> (and does, in my experience!) move. I can deal with it via a couple of
> shell scripts, and there are
Perusing through the various documentation I've not yet found an answer
to this, and figure someone might know where to point me before I start
banging code beyond a shell script or three.
Assuming we have a "dual stack" system on the Internet; the provider is
willing to allocate us anywhere from
On 03/08/17 18:03, Freddie Cash wrote:
It's listed in the EXAMPLES section of the ipfw(8) man page.
ipfw nat show config <-- view config for all nat instances
ipfw nat 123 show config <-- view config for nat 123
ipfw nat 111-999 show<-- view logs for nat 111-999
Oops!!!
Been working
On Wed, Mar 8, 2017 at 7:52 AM, Andrea Venturoli wrote:
> Hello.
>
> I'm using "ipfw nat" on several 10.3 boxes, but I have some questions.
>
> Let's start with a simple one: how do I list configured NATs and their
> details?
> I know I can configure a
On Wed, 8 Mar 2017 16:52:36 +0100, Andrea Venturoli wrote:
Just on one point:
> Second question:
> _ if I issue "ipfw nat 2 config if re0", I'll see the output "ipfw nat 2
> config if re0";
> _ if I issue "ipfw nat 2 config ip 192.168.0.1", I'll see the output "ipfw
> nat 2 config ip 192.168
Hello.
I'm using "ipfw nat" on several 10.3 boxes, but I have some questions.
Let's start with a simple one: how do I list configured NATs and their
details?
I know I can configure a NAT with "ipfw nat 1 config ...", but how do I
show what I did?
Second qu
Somayajulu wrote:
> >> > Hi All,
> >> > I have a couple of questions on iflib :
> >> >
> >> > 1. Are there plans to incorporate iflib into CURRENT. If yes, will
> >> > it make it into FreeBSD11 release ?
> >>
> >> Ye
On Wed, May 11, 2016 at 7:56 AM, Chris H wrote:
> On Tue, 10 May 2016 10:25:24 -0700 hiren panchasara
> wrote
>
>> + Kip, Scott.
>>
>> On 05/10/16 at 04:46P, David Somayajulu wrote:
>> > Hi All,
>> > I have a couple of questions on iflib :
>> &
On Tue, 10 May 2016 10:25:24 -0700 hiren panchasara
wrote
> + Kip, Scott.
>
> On 05/10/16 at 04:46P, David Somayajulu wrote:
> > Hi All,
> > I have a couple of questions on iflib :
> >
> > 1. Are there plans to incorporate iflib into CURRENT. If yes, w
; Sent: Tuesday, May 10, 2016 12:31 PM
> To: hiren panchasara
> Cc: freebsd-net@freebsd.org; sco...@freebsd.org; freebsd-driv...@freebsd.org;
> David Somayajulu
> Subject: Re: Questions on iflib
>
> I'm waiting on erj to commit his ixl update. It will go in immediately
&g
panchasara
Cc: freebsd-net@freebsd.org; sco...@freebsd.org; freebsd-driv...@freebsd.org;
David Somayajulu
Subject: Re: Questions on iflib
I'm waiting on erj to commit his ixl update. It will go in immediately
following that with an ixgbe and ixl driver. It would have also included a bxe
driver, bu
rrors. It may just be the "ET game" of ethernet cards, meriting a similar
fate.
Cheers.
-M
On Tuesday, May 10, 2016, hiren panchasara
wrote:
> + Kip, Scott.
>
> On 05/10/16 at 04:46P, David Somayajulu wrote:
> > Hi All,
> > I have a couple of questions on iflib :
+ Kip, Scott.
On 05/10/16 at 04:46P, David Somayajulu wrote:
> Hi All,
> I have a couple of questions on iflib :
>
> 1. Are there plans to incorporate iflib into CURRENT. If yes, will it
> make it into FreeBSD11 release ?
Yes. The library itself (without any drivers) is
Hi All,
I have a couple of questions on iflib :
1. Are there plans to incorporate iflib into CURRENT. If yes, will it
make it into FreeBSD11 release ?
2. Where can I get the latest patch of iflib for FreeBSD_CURRENT ?
Thanks
David S (davi...@freebsd.org
Hello,
I'm not very familiar with FreeBSD network subsystem and I'm trying to
import a new version of xen-netfront from Linux to FreeBSD. So far so
good, most stuff is pretty similar and I think I've _mostly_ figured it
out by myself. I have however a couple of questions regard
On 1 Sep, Don Lewis wrote:
> Bufferbloat on my DSL link to the outside world has been bugging me
> lately. I was considering adding an OpenWrt box between my DSL modem
> and my FreeBSD firewall in order to get CoDel, when I discovered that
> CoDel had been quietly added to FreeBSD 11. Unfortunat
Bufferbloat on my DSL link to the outside world has been bugging me
lately. I was considering adding an OpenWrt box between my DSL modem
and my FreeBSD firewall in order to get CoDel, when I discovered that
CoDel had been quietly added to FreeBSD 11. Unfortunately the
documentation is severely la
On 24 Aug, Hiroki Sato wrote:
> Don Lewis wrote
> in <201508240052.t7o0qsff002...@gw.catspoiler.org>:
>
> tr> > A TCP setup packet coming from a host on the internal LAN to the NAPT
> tr> > router falls into the last deny-all rule because it does not match if
> tr> > you added "out via ${oif
Don Lewis wrote
in <201508240052.t7o0qsff002...@gw.catspoiler.org>:
tr> > A TCP setup packet coming from a host on the internal LAN to the NAPT
tr> > router falls into the last deny-all rule because it does not match if
tr> > you added "out via ${oif}" to that rule. Does the following
tr> >
On 23 Aug, Hiroki Sato wrote:
> Don Lewis wrote
> in <201508222103.t7ml3gax000...@gw.catspoiler.org>:
>
> tr> The example /etc/rc.firewall has provisions to use either in-kernel NAT
> tr> or natd for the open and client firewall types, but the simple filewall
> tr> type only has code for natd.
On 23 Aug, Ian Smith wrote:
> On Sun, 23 Aug 2015 08:44:53 +0900, Hiroki Sato wrote:
> > Don Lewis wrote
> > in <201508222103.t7ml3gax000...@gw.catspoiler.org>:
> >
> > tr> The example /etc/rc.firewall has provisions to use either in-kernel NAT
> > tr> or natd for the open and client firew
On Sat, Aug 22, 2015 at 8:00 PM, Ian Smith wrote:
> On Sun, 23 Aug 2015 08:44:53 +0900, Hiroki Sato wrote:
> > Don Lewis wrote
> > in <201508222103.t7ml3gax000...@gw.catspoiler.org>:
> >
> > tr> The example /etc/rc.firewall has provisions to use either in-kernel
> NAT
> > tr> or natd for
On Sun, 23 Aug 2015 08:44:53 +0900, Hiroki Sato wrote:
> Don Lewis wrote
> in <201508222103.t7ml3gax000...@gw.catspoiler.org>:
>
> tr> The example /etc/rc.firewall has provisions to use either in-kernel NAT
> tr> or natd for the open and client firewall types, but the simple filewall
> tr
Don Lewis wrote
in <201508222103.t7ml3gax000...@gw.catspoiler.org>:
tr> The example /etc/rc.firewall has provisions to use either in-kernel NAT
tr> or natd for the open and client firewall types, but the simple filewall
tr> type only has code for natd. Is there any reason that in-kernel NAT
tr
The example /etc/rc.firewall has provisions to use either in-kernel NAT
or natd for the open and client firewall types, but the simple filewall
type only has code for natd. Is there any reason that in-kernel NAT
could not be used with the simple firewall type?
After allowing connections to select
switches.
>
> We are going to:
>
> 1- Define two vlan interfaces for vlan id X.
>one with em0 as parent and the other on top of em1.
> 2- Create a bridge interface.
> 3- Add the two vlan interfaces as members of the bridge.
> 4- Repeat 1-3 for every vlan id used in the
.
one with em0 as parent and the other on top of em1.
2- Create a bridge interface.
3- Add the two vlan interfaces as members of the bridge.
4- Repeat 1-3 for every vlan id used in the network.
2 questions:
1- Is not there a simpler method which does not involve creating so
many vlans
On 25.06.2015 19:18, Emeric POUPON wrote:
> Ok thanks, I understand this case.
> But the problem is that we perform a lot of unnecessary mforward calls from
> ip_input.
>
> The mrt route cache lookup is performed thanks to the src/dst addresse couple.
> The interface of the cached route does not
prevents "infinite" loops.
Is that really how it is meant to be done?
Emeric
- Mail original -
De: "Andrey V. Elsukov"
À: "Emeric POUPON" , freebsd-net@freebsd.org
Envoyé: Jeudi 25 Juin 2015 07:48:44
Objet: Re: Multicast routing questions
On 24.06.2015 18
On 24.06.2015 18:13, Emeric POUPON wrote:
> Hi,
>
> Actually, I don't really understand why imo.imo_multicast_loop is set
> to 1 in send_packet, ip_mroute.c
>
> It seems we don't need to loop the packet once it is mrouted?
I think this can be used for the case, when on the router some app has
b
necessary.
Emeric
- Mail original -
De: "Emeric POUPON"
À: freebsd-net@freebsd.org
Envoyé: Mercredi 24 Juin 2015 10:22:45
Objet: Multicast routing questions
Hello,
I'm testing multicast routing on FreeBSD 9.3 and I have a question:
In packet reception, it seems the pack
Hello,
I'm testing multicast routing on FreeBSD 9.3 and I have a question:
In packet reception, it seems the packet is received locally as many times the
packet is rerouted + 1:
ip_input -> ip_mforward -> ip_output (as many times there are dst interfaces in
the route cache entry) -> ip_mloopbac
Ok for the function.
Please find the review here: https://reviews.freebsd.org/D2141
Regards,
Emeric
- Mail original -
De: "Hans Petter Selasky"
À: "Emeric POUPON" , "Adrian Chadd"
Cc: "freebsd-net"
Envoyé: Mercredi 25 Mars 2015 14:41:46
Objet
Hans Petter Selasky wrote this message on Fri, Mar 20, 2015 at 19:56 +0100:
> On 03/20/15 19:02, Adrian Chadd wrote:
> > On 20 March 2015 at 10:58, Hans Petter Selasky wrote:
> >> On 03/20/15 14:31, Emeric POUPON wrote:
> >>>
> >>> - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not us
On Wed, 25 Mar 2015, Hans Petter Selasky wrote:
On 03/24/15 10:26, Emeric POUPON wrote:
Please find attached a proposal using atomic_fetchadd.
...
I think however we should define the code like a function, because the
htons() might be a macro, referring the input argument multiple times ...
On 03/24/15 10:26, Emeric POUPON wrote:
Hello,
Please find attached a proposal using atomic_fetchadd.
Best Regards,
Emeric
Hi,
Your proposal using atomic_fetchadd() looks fine to me.
I think however we should define the code like a function, because the
htons() might be a macro, referring
Hello,
Please find attached a proposal using atomic_fetchadd.
Best Regards,
Emeric
- Mail original -
De: "Adrian Chadd"
À: "Hans Petter Selasky"
Cc: "Emeric POUPON" , "freebsd-net"
Envoyé: Vendredi 20 Mars 2015 20:04:44
Objet: Re: Fragment qu
On 20 March 2015 at 11:56, Hans Petter Selasky wrote:
> On 03/20/15 19:02, Adrian Chadd wrote:
>>
>> On 20 March 2015 at 10:58, Hans Petter Selasky wrote:
>>>
>>> On 03/20/15 14:31, Emeric POUPON wrote:
- in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use
random
On 03/20/15 19:02, Adrian Chadd wrote:
On 20 March 2015 at 10:58, Hans Petter Selasky wrote:
On 03/20/15 14:31, Emeric POUPON wrote:
- in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use
randomized id.
In multi core systems, we may emit successive packets with the same id.
On 20 March 2015 at 10:58, Hans Petter Selasky wrote:
> On 03/20/15 14:31, Emeric POUPON wrote:
>>
>> - in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use
>> randomized id.
>
>> In multi core systems, we may emit successive packets with the same id.
>
> Will using a mutex or an atom
On 03/20/15 14:31, Emeric POUPON wrote:
- in the ip_newid macro, we do "htons(V_ip_id++))" if we do not use randomized
id.
> In multi core systems, we may emit successive packets with the same id.
Will using a mutex or an atomic macro fix this issue when incrementing
the V_ip_id ?
--HPS
___
On 03/20/15 14:31, Emeric POUPON wrote:
Hello,
Yes indeed, it has already been fixed!
However, the second point seems to be still here...
Regards,
Emeric
Can you suggest a patch for the second issue?
--HPS
___
freebsd-net@freebsd.org mailing lis
Hello,
Yes indeed, it has already been fixed!
However, the second point seems to be still here...
Regards,
Emeric
- Mail original -
De: "Hans Petter Selasky"
À: "Emeric POUPON" , "freebsd-net"
Envoyé: Jeudi 19 Mars 2015 13:54:33
Objet: Re: Fragmen
1 - 100 of 297 matches
Mail list logo
