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 destinatio
ke 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 Fa
TW, I am aware that some drivers
export a
few counters via sysctl interface, but what I am talking about is a
standardized set
of counters available for _all_ Ethernet devices).
--
Best regards
Hooman Fazaeli
___
freebsd-net@freebsd.org mailing list
h
.unipi.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 unsubscr
karounds:
https://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
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
unscaled window size 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
h of my public servers. That seems to work fine, but I 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
ing 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 &
r.
___
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
___
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
ul value ?
___
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@f
-adrian
On 31 October 2014 08:00, 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:
This simple program listens for UDP datagrams on a net
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.
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 ?
> >
8.x and older
versions) but
there seems 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
___
freebs
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_usrre
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 of
ntrol.
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 reg
No. Anyway, 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 "freeb
_
freebsd-a...@freebsd.org mailing list
http://lists.freebsd.org/mailman/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 li
onf
net.graph.maxalloc=262140 # /boot.loader.conf
2. Remove FLOWTABLE kernel option.
It would also help if you put your kernel and core dump somewhere for download
so we can have a closer look at panic trace.
--
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"
rienced similar problems (one case was 82574 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 d
reside, please let me know.
Thanks
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
___
f
/s with 1514, so maybe you just need a new calculator?
>
> BC
> ___
>
AsBarney pointed outalready, your numbers are reasonable. You have almost
saturated
the link with 1514 byte packets.In the case of 64 byte packets, you do not
achieve li
tween drivers. Somewhere like the Ethernet layer is a much better choice
to watch
load of packets and drop them to prevent them to eat all the cores.
Furthermore, ignoring
the fact that pf is not optimized for multi-processors and blaming drivers for
c/sys/dev/e1000/if_em.c#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... if
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: e
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: e
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 pr
On 8/11/2012 2:17 PM, Karl Pielorz wrote:
--On 11 August 2012 12:36 +0430 Hooman Fazaeli wrote:
"
NameMtu Network Address Ipkts Ierrs Idrop
Opkts Oerrs Coll em01500 00:25:90:31:82:46 355482
10612864185945 0 291109 3032246910270 1516123455135 &quo
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:
net.inet.ip.fw.enable=
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 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 7.
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
sorry! I forgot to cleanup the the last message ... here is t
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 local_
On 11/8/2011 10:23 PM, Jason Wolfe wrote:
On Tue, Nov 8, 2011 at 10:21 AM, Hooman Fazaeli 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 interrupt h
On 11/8/2011 11:00 PM, Adrian Chadd wrote:
On 8 November 2011 09:21, Hooman Fazaeli 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 during a temporary link
On 11/7/2011 9:24 PM, Jason Wolfe wrote:
On Mon, Oct 31, 2011 at 1:13 AM, Hooman Fazaeli 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, drops are
incr
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
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
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 th
On 10/30/2011 6:03 PM, Ryan Stone wrote:
On Sun, Oct 30, 2011 at 4:57 AM, Hooman Fazaeli 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 time, callin
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
The following reply was made to PR kern/162028; it has been noted by GNATS.
From: Hooman Fazaeli
To: Sergey Kandaurov
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
On 10/29/2011 4:28 PM, Sergey
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 r...@epia
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 case
g -tso -wol
options=88
It's always TX, but these servers push ~12x what they receive, so I'm
guessing it could happen to either buffer given the right traffic patterns.
While looking through commits I also found a patch to add a couple sysctls
for em, which I'm adding - http://fres
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 pr
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 @@
a
AM, Hooman Fazaeli 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 does not expos
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 Sunda
if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD)
igb_txeof(txr);
is this intentional or mistake?
On 7/6/2011 2:58 PM, Mike Tancsa wrote:
On 7/6/2011 4:29 AM, Hooman Fazaeli wrote:
Can you pls. share the patch for freebsd 7?
Its in the tree.
http://www.freebsd.org/cg
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 as
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
60 matches
Mail list logo
