On 2017-03-13 11:01, Andrey V. Elsukov wrote:
On 12.03.2017 00:23, Hooman Fazaeli wrote:
Hi,
As you know the ipsec/setkey provide limited syntax to define security
policies: only a single subnet/host, protocol number and optional port
may be used to specify traffic's source and destination.
I
it is used with dummeynet. Something like:
ipfw add 100 ipsec 2 tcp from to
80,443,110,139
What do you think? Are you interested in such a feature?
Is it worth the effort? What are the implementation challenges?
--
Best regards
Hooman Fazaeli
i.it/%7Eluigi/papers/20120601-dxr.pdf>)
I apologize if the question is not much relevant to your work.
--
Best regards
Hooman Fazaeli
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscrib
://lists.freebsd.org/pipermail/freebsd-bugs/2014-June/056548.html
https://lists.freebsd.org/pipermail/freebsd-bugs/2014-June/056549.html
https://lists.freebsd.org/pipermail/freebsd-net/2014-June/038954.html
--
Best regards
Hooman Fazaeli
___
freebsd-net
On 2016-03-07 4:26 PM, Hooman Fazaeli wrote:
Hi,
In our network, Windows clients connect to internet via our custom developed
transparent
tcp proxy (running on 7.3). Things work fine, except that _sometimes_ downloads
from the
some windows clients become very slow. To debug the problem, we
e sent in a previous ACK.
Now, setting 'net.inet.tcp.syncookies' to zero obviously seems to fix the
problem
and the download speed becomes as expected.
Is this bad interaction between window scaling and syn cookies
a known problem? Why it happens? Has it been fixed in later freebsd version?
Thanks in a
wonder if
there's something I might be doing wrong?
If I didn't include enough info, fire away. Thanks!
Can you post the output of the following commands (on freebsd router):
# ifconfig
# ifconfig bridgeX addr
# arp -na
# netstat -nr -f inet
# sysctl net.inet.ip
--
Best regards
Hooman Fazaeli
meaning of USED/FREE and
current/cache values? Is there any relationship between them?
--
Best regards
Hooman Fazaeli
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to &
fixed? Is there any known problem related to window
scaling in newer (8+) freebsd versions?
Thanks in advance.
--
Best regards
Hooman Fazaeli
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe
.
___
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
--
Best regards
Hooman Fazaeli
___
freebsd-net@freebsd.org
?
___
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
--
Best regards.
Hooman Fazaeli
___
freebsd-net@freebsd.org mailing list
October 2014 08:00, Hooman Fazaeli hoomanfaza...@gmail.com wrote:
On 10/31/2014 5:30 PM, Mark Felder wrote:
I'm not sure if this is what you're looking for, but perhaps the
solution is in net/samplicator ?
From the project's website:
This simple program listens for UDP datagrams on a network
On 10/31/2014 8:30 PM, Ian Smith wrote:
On Fri, 31 Oct 2014 18:30:00 +0330, Hooman Fazaeli wrote:
On 10/31/2014 5:30 PM, Mark Felder wrote:
I'm not sure if this is what you're looking for, but perhaps the
solution is in net/samplicator ?
From the project's website
On 10/31/2014 8:11 PM, Adrian Chadd wrote:
Hi,
If it's missing in 10 or later then please file a bug and I'll see
what it'll take to add another socket option to return the original
destination address+port.
Thanks,
-adrian
Thanks. I will check ASAP.
--
Best regards.
Hooman Fazaeli
.
Another soultion would be to implement IP_RECVDSTSOCKADDR option, which records
the original
destination address:port as a 'struct sockaddr_in[6]' in packet's control data.
Comments/suggestions are welcome.
--
Best regards.
Hooman Fazaeli
On 10/31/2014 2:18 PM, Andrey V. Elsukov wrote:
On 31.10.2014 12:50, Hooman Fazaeli wrote:
Hi,
I my setup, I use a fwd rule to forward all udp traffic to my local proxy:
ipfw add 10 fwd localhost,7000 udp from any to any recv em1
The proxy needs to know the original destination address
On 10/31/2014 3:38 PM, Andrey V. Elsukov wrote:
On 31.10.2014 15:04, Hooman Fazaeli wrote:
Hi,
udp_input() doesn't overwrite destination address. Probably you have NAT
that does this.
There is no NAT stuff.
I checked that on 8.4 source:
http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c?v
to be no mechanism get the _original_ destination _port_ (Apart
from this
missing mechanism, my proxy is functional and performs what it is intended to
do).
--
Best regards.
Hooman Fazaeli
___
freebsd-net@freebsd.org mailing list
http
, you can check state statistics with: pfctl -s i ; pfctl -s m
--
Best regards.
Hooman Fazaeli
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr
/listinfo/freebsd-arch
To unsubscribe, send any mail to freebsd-arch-unsubscr...@freebsd.org
Doesn't the problem applies to TCP too?
TCP may be fragmented too but is less likely because of MSS.
--
Best regards.
Hooman Fazaeli
___
freebsd-net
.
Hooman Fazaeli
___
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
with cisco 3550).
I also remember cases when auto-select worked but fixed media did not (link was
settled down to 100 or half-duplex)
I am curious as what is the exact technical reason(s) for such media problems?
Are they more hardware or driver related?
--
Best regards.
Hooman Fazaeli
Joe
___
Assign IP addresses from __different__ subnets to the four NIC ports and
re-test.
(e.g., 192.168.0.10/24, 1.10/24, 2.10/24, 3.10/24).
--
Best regards.
Hooman Fazaeli
___
freebsd-net@freebsd.org
of the congestion on the bus.Can you show us top -SI
output on the
sender machine?
--
Best regards.
Hooman Fazaeli
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd
the cores.
Furthermore, ignoring
the fact that pf is not optimized for multi-processors and blaming drivers for
not adjusting
themselves with the this pf's fault, is a bit unfair, I believe.
--
Best regards.
Hooman Fazaeli
___
freebsd-net
#rev1.21.2.23
--
Best regards.
Hooman Fazaeli
___
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
On 9/27/2012 9:38 PM, Rudy wrote:
On 09/27/2012 11:00 AM, Rudy wrote:
Rebooting and/or the settings change seems to have stopped the errors.
Here is a pretty little graph showing error rate on em1 for the past 3
days.
http://www.monkeybrains.net/images/ErrorRate-em1.png
Interesting...
On 9/24/2012 7:50 PM, Rudy (bulk) wrote:
Sometimes when I try to ping a neighbor machine (plugged directly in with no
switch involved), I get:
ping: sendto: No buffer space available
ping: sendto: No buffer space available
If I reset the interface 'ifconfig em1 down; ifconfig em1 up' the
On 9/25/2012 11:08 AM, Rudy (bulk) wrote:
On 9/24/12 11:52 PM, Hooman Fazaeli wrote:
sysctl dev.em.1
From the side having the 'No buffer space available' (FreeBSD 8.3 Sep 13 2012)
# sysctl dev.em.1
dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2
dev.em.1.%driver: em
dev.em.1
On 9/25/2012 11:08 AM, Rudy (bulk) wrote:
On 9/24/12 11:52 PM, Hooman Fazaeli wrote:
sysctl dev.em.1
From the side having the 'No buffer space available' (FreeBSD 8.3 Sep 13 2012)
# sysctl dev.em.1
dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2
dev.em.1.%driver: em
dev.em.1
On 8/11/2012 2:17 PM, Karl Pielorz wrote:
--On 11 August 2012 12:36 +0430 Hooman Fazaeli hoomanfaza...@gmail.com wrote:
NameMtu Network Address Ipkts Ierrs Idrop
Opkts Oerrs Coll em01500 Link#5 00:25:90:31:82:46 355482
10612864185945 0 291109
On 8/10/2012 11:24 PM, Karl Pielorz wrote:
Hi,
Apologies for posting to -net as well - I originally posted this to -hackers,
but was advised to re-post it here...
A FreeBSD 9.0-R amd64 box - based on a SuperMicro X8DTL-IF Rev. 2.01 w/Intel L5630
6Gb of RAM seems to have issues with it's
On 7/16/2012 10:13 PM, Alexander V. Chernikov wrote:
Old kernel from previous letters, same setup:
net.inet.ip.fw.enable=0
2.3 MPPS
net.inet.ip.fw.update_counters=0
net.inet.ip.fw.enable=1
1.93MPPS
net.inet.ip.fw.update_counters=1
1.74MPPS
Kernel with ipfw pcpu counters:
Dear Jason
With a link_irq of 4, I still guess your problem is snd_buf filling up during
a temporary link_loss (see:
http://lists.freebsd.org/pipermail/freebsd-net/2011-November/030424.html).
I use a patched version of e1000 which addresses this issue and
works good for me but it is based on
On 3/11/2012 5:31 AM, Adrian Chadd wrote:
Are you able to post the patch here?
Maybe Jack can look at what's going on and apply it to the latest
intel ethernet driver.
Adrian
Below is the patch for if_em.c (7.2.3). It simply checks driver's
queue status when the link state changes (inactive
Dear Jack
Is the problem related to link loss fixed in this version?
The problem was that if if_snd fills up during a link_active == 0
period, stack never calls em_start again, because em does not
kick off tx when link becomes active again.
On 1/29/2012 9:51 PM, Jack Vogel wrote:
No, I told
On 11/10/2011 3:39 AM, Adrian Chadd wrote:
There's no locking around the OACTIVE flag set/clear, right?
Is it possible that multiple TX threads are fiddling with OACTIVE and
then it's not being properly cleared and tx kicked?
Adrian
If we check for OACTIVE periodically (for instance, in
On 11/10/2011 3:39 AM, Adrian Chadd wrote:
There's no locking around the OACTIVE flag set/clear, right?
Is it possible that multiple TX threads are fiddling with OACTIVE and
then it's not being properly cleared and tx kicked?
Adrian
sorry! I forgot to cleanup the the last message ... here is
On 11/8/2011 11:00 PM, Adrian Chadd wrote:
On 8 November 2011 09:21, Hooman Fazaelihoomanfaza...@gmail.com wrote:
With MSIX enabled, the link task (em_handle_link) does _not_ triggers
_start when the link changes state from inactive to active (which it
should).
If if_snd quickly fills up
On 11/8/2011 10:23 PM, Jason Wolfe wrote:
On Tue, Nov 8, 2011 at 10:21 AM, Hooman Fazaeli hoomanfaza...@gmail.com
mailto:hoomanfaza...@gmail.com wrote:
I have allocated more time to the problem and guess I can explain what
your problem is.
With MSIX disabled, the driver uses fast
On 11/7/2011 9:24 PM, Jason Wolfe wrote:
On Mon, Oct 31, 2011 at 1:13 AM, Hooman Fazaeli hoomanfaza...@gmail.com
mailto:hoomanfaza...@gmail.com wrote:
Attached is a patch for if_em.c. It flushes interface queue when it is full
and link is not active. Please note that when this happens
On 10/31/2011 7:33 AM, Jason Wolfe wrote:
Thanks for looking into this. I'd be happy to test any patch thrown my way, but keep in mind my issue is only tickled when MSI-X is enabled. My interfaces aren't bouncing, though it might be
possible some unique path in the MSI-X code is causing a
On 10/31/2011 11:43 AM, Emil Muratov wrote:
You may try these settings and see if they help:
- hw.em.fc_setting=0 (in /boot/loader.conf)
- hw.em.rxd=4096 (in /boot/loader.conf)
- hw.em.txd=4096 (in /boot/loader.conf)
- Fix speed and duplex at both link sides. After doing that, confirm on the
On 10/31/2011 12:51 PM, Emil Muratov wrote:
On 31.10.2011 12:13, Hooman Fazaeli wrote:
Thanks for looking into this. I'd be happy to test any patch thrown my way, but keep in mind my issue is only tickled when MSI-X is enabled. My interfaces aren't bouncing, though it might be
possible
The following reply was made to PR kern/162028; it has been noted by GNATS.
From: Hooman Fazaeli hoomanfaza...@gmail.com
To: Sergey Kandaurov pluk...@gmail.com
Cc: bug-follo...@freebsd.org
Subject: Re: kern/162028: [ixgbe] [patch] misplaced #endif in ixgbe.c
Date: Sun, 30 Oct 2011 11:03:44 +0330
I finally managed to re-produce an affect similar to Jason's case. It
may not be the exact same issue, but it is a serious problem and must
be addressed.
1. Push out packet on em/igb with high rate.
2. Disconnect cable and wait for a few seconds. netstat -ind shows that
Drops are increasing.
On 10/30/2011 6:03 PM, Ryan Stone wrote:
On Sun, Oct 30, 2011 at 4:57 AM, Hooman Fazaelihoomanfaza...@gmail.com wrote:
IMHO, this is not a driver issue and the real fix would be to change
IFQ_HANDOFF to call if_start when the queue is full.
I'm not sure that's the right approach. 99% of the
On 10/27/2011 9:59 AM, Emil Muratov wrote:
Hi Hooman
Here is what I've got when the script triggered just in time when the interface
was locked
11.10.26-23:39:10 ... interface em0 is down...
FreeBSD ion.hotplug.ru 8.2-STABLE FreeBSD 8.2-STABLE #0: Thu Oct 20 20:20:25
MSD 2011
Hi Jason
Have you tried:
hw.em.fc_setting=0 (in loader.conf)
ifconfig emX -tso -lro -rxcsum -txcsum -vlanhwtag -wol
with MSIX and no multiqueue.
Advanced features has always been a source of problem.
It is worth a try and help to narrow down possibilities.
It would also be helpful if you
Hi,
Can yan you pls post the output of these command _when_ the problem happens?
uname -a
sysctl dev.em
netstat -ind
ifconfig
I've got almost the same problem with intel 82574L based nic. My platform is nvidia ion running Atom 1.6 and nic is an external PCI-express adapter. Unlike Jason's
A misplaced #endif in ixgbe_ioctl() causes all sorts of problems
when INET and INET6 are undefined. Pls. see the attached patch.
--- ixgbe.c.orig2011-10-17 20:37:17.0 +0330
+++ ixgbe.c 2011-10-17 20:38:40.0 +0330
@@ -898,8 +898,8 @@
AM, Hooman Fazaeli faza...@sepehrs.com
mailto:faza...@sepehrs.com wrote:
Hi Jack
The hardware is a PCIe network appliance with 3 port modules. The ports I
have
used in the test are 82574L residing on a 4 port module. Anyway, as I noted
in last mail, the stock 7.3-RELEASE driver
Hi list,
The data sheet for intel 82576 advertises IP TX/RX checksum offload
but the driver does not set CSUM_IP in ifp-if_hwassist. Does this mean that
driver (and chip) do not support IP TX checksum offload or the support for
TX is not yet included in the driver?
I have similar problems on a couple of 7.3 boxes with latest driver form
-CURRENT.
I just wanted to know if your 7 boxes work fine so I look for cause else where.
On 2/7/2011 3:23 AM, Mike Tancsa wrote:
So far so good. I would often get a hang on the level zero dumps to my
backup server
Can you pls. share the patch for freebsd 7?
On 2/7/2011 3:23 AM, Mike Tancsa wrote:
So far so good. I would often get a hang on the level zero dumps to my
backup server Sunday AM, and it made it through! So a good sign, but
not a definitive sign.
I have a PCIe em card that has this chipset
Thanks for the work.
Is source for driver patches available?
On 6/3/2011 3:01 AM, Luigi Rizzo wrote:
Hi,
we have recently worked on a project, called netmap, which lets
FreeBSD send/receive packets at line rate even at 10 Gbit/s with
very low CPU overhead: one core at 1.33 GHz does 14.88 Mpps
Any one knows if there is any near plan to develop drivers for
network cards based on broadcom NetXtereme II 57710
10 GbE controller?
---
best regards
Hooman Fazaeli
___
freebsd-net@freebsd.org mailing list
http
57 matches
Mail list logo
