On 04/07/2017 03:40, Takahiro Kurosawa wrote:
What if you change the line:
pass in inet proto tcp to port { ssh }
to:
pass in inet proto tcp to port { ssh } no state
close, but I had to use the "no state" on the "pass out" rules as well.
Now it looks like that:
-
Marek Zarychta wrote:
> pass in quick on $ext_if_1 \
> [...]
> pass in quick on $ext_if_2 reply-to ($ext_if_2 $ip_gw_2) \
> [...]
> pass in quick on $ext_if_1 \
> [...]
> pass in quick on $ext_if_2 \
that's what I meant in my opening post - you have to create a rule for
every possible gate
I wrote:
> If I try
>
> ping -S 8.0.0.1 8.8.8.8
>
> or
>
> ping -S 9.0.0.1 8.8.8.8
>
> I always see packets only going out on the default gateway's interface.
sorry, my fault. After issuing a "pfctl -F all", these ICMP packets are
now going through the designated interface.
The pr
Slawa Olhovchenkov wrote:
> I.e. you can't build rules based on "replays", only on "origins",
> source IP address generated packes (as you ipfw fwd rules).
okay, let's ditch the word "reply". I meant it so that these packets are
generated by a software due to incoming packets.
If I try
p
Hi,
we have two internet lines here.
Following situation (IP addresses changed) on my server:
iface "wan1" = 8.0.0.1/24 - GW1 8.0.0.254 (internet line 1)
iface "wan2" = 9.0.0.1/24 - GW2 9.0.0.254 (internet line 2)
Now I'd like it so that every packet that comes in on interface "
I wrote:
> [...] Sometimes I get a kernel panic (s. attached screenshot).
attachment has been stripped. If you need the screenshot or crash dumps, please
let me know then I think about a way to provide them.
As these are VMs you should be able to reconstruct the behaviour as well...
Regards,
N
Hi Nigel,
Nigel Williams wrote:
> A new mptcp v0.5 patch is available at
> http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html.
thanks for the new patch. I've tried your provided VirtualBox VM "FB11-test1".
Unfortunately, standard TCP-connections aren't working. For instance, after I
execute:
Hi,
Yonghyeon PYUN wrote:
> Default interrupt moderation policy is targeted to reduce latency
> so it will generate up to 10k interrupts/sec under high network
> load. If you want to reduce number of interrupts/sec, tune
> interrupt moderation sysctl variables mentioned in alc(4).
Tried several
Hi,
Yonghyeon PYUN wrote:
>> Then I've connected a network cable and rebooted. I've got a link and
>> performed an "iperf" test. The results are really good: around 930 Mbit/s
>> TX and 840 Mbit/s RX. CPU load during that test: "70.75% kernel{alc0
>> taskq}".
>
> Hmm, the RX performance number lo
Hi Yonghyeon,
Yonghyeon PYUN wrote:
> I've added support for QAC AR816x/AR817x ethernet controllers. It
> passed my limited testing and I need more testers. You can find
> patches from the following URLs. [...]
My NIC (System: "Dell Inc. Vostro 3460"):
--
Hi Gulyaev,
Gulyaev Ghosh wrote:
> Since I ask on the FreeBSD forums, there is a proposition to check
> alx-freebsd and have initialized interface.
>
> So if someone have similar hardware, you can got your experience with
> that project and share info.
I've got an onboard "AR8161 Gigabit Ethernet
Hi Nigel,
Nigel Williams wrote:
>> Do you want any crash dumps? If yes, where do you want them to be
>> uploaded?
>
> Yes, that would be helpful (I'll send you a link to a drop box). If you
> were able to email me the core text files that might also help.
Thanks for the link. I've sent you two c
Hi Nigel,
Nigel Williams wrote:
> A new v0.4 patch is available at [1]. [...]
Thanks a lot for publishing the latest patch. Already tried it on two phyiscal
machines with directly connected NICs.
"iperf" looks nice:
===
Hi,
are there any news regarding MPTCP? Last public patch is from April last
year:
http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html
Is there a newer patch for a more recent CURRENT/STABLE available?
Thanks and regards,
Nils
___
freebsd-net
14 matches
Mail list logo
