netif userland API

Hi! Assume we run some FreeBSD-based broadband remote access server for PPPoE (net/mpd5 for example). The server has hundreds or thousands vlan interfaces and even more ngXXX interfaces, one per user PPPoE session. The server software may need to enable its PPPoE service for all newly created

Re:  netif userland API

28.10.2023 23:21, Roy Marples wrote: > What you would do is open a route socket, then call getifaddrs and then > listen on the route socket for new interfaces. > > Then you can maintain a list of current vlans and take action accordingly. I'd like to be able to make a couple of system calls onl

Re:  netif userland API

28.10.2023 23:43, Roy Marples wrote: > Using netlink rather than route on a modern FreeBSD kernel may allow you do > do the same thing > but install a kernel filter on the socket just to receive interface changes. > > That should match your requirements. This scales bad still. More new vlans un

Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling?

12.04.2013 05:31, Karl Denninger пишет: > Is there a "cookbook" for setting this up? There are examples for > setting up a tunnel between two fixed-address networks (e.g. a remote > LAN that needs to be "integrated" with a central LAN over IPSec but I > can't find anything addressing the other sit

lagg+vlan+igb kernel bug

ig shows single MAC address for lagg1 and both its ports. Eugene Grosbein ___ 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"

Re: lagg+vlan+igb kernel bug

On 29.04.2013 16:24, Eugene Grosbein wrote: > Hi! > > Today I discovered really subtle bug in connection of lagg(4), vlan(4) and > igb(4) drivers. > > Here is what I have in /etc/rc.conf: > > cloned_interfaces="lagg0 lagg1" > ifconfig_lagg1="

Re: High CPU interrupt load on intel I350T4 with igb on 8.3

problem. Network device driver is not guilty here, that's just pf's contention running in igb's context. Eugene Grosbein ___ 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"

Re: High CPU interrupt load on intel I350T4 with igb on 8.3

On 09.05.2013 23:25, Barney Cordoba wrote: >> Network device driver is not guilty here, that's just pf's >> contention >> running in igb's context. >> >> Eugene Grosbein > > They're both at play. Single threadedness aggravates subsystem

Re: High CPU interrupt load on intel I350T4 with igb on 8.3

change in the igb code. The same problem will occur for other NIC drivers too - if several NICs were combined within one lagg(4). So, driver is not guilty and solution would be same - eliminate bottleneck and you will be fine and capable to spread the load on several CPU cores. Therefore, I don&#

Re: "no buffer space available" problem

On 10.05.2013 20:07, M. V. wrote: > hi, > > I have a FreeBSD 8.2 server with some em & igb interfaces. (em driver version > is 7.3.2 & igb driver version is 2.3.1) > It doesn't have a full-load traffic on it (maximum 50-100Mbps per-interface > on 1Gbps interface). but occasionally one of its int

Re: MPD5 - Can't establish VPN connection from windows to FreeBSD MPD5 Server

On 10.05.2013 23:02, jbiskofski wrote: > Hey Everyone, > > I just cant get this to work. I would appreciate any suggestions. It seems GRE protocol is blocked in the direction from mpd5 server to client. You should blame your provider. Or change VPN type from PPtP to L2TP that uses UDP only, not

Re: High CPU interrupt load on intel I350T4 with igb on 8.3

ility. I, as system administrator, expect from a driver to spit packets as fast as possible. I can employ some packet buffering system if I need it or use ng_car or dummynet or something to deal with bottlenecks. Or not to deal with them for purpose. NIC driver cannot know my needs. Eugene Grosbein ___ 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"

Re: High CPU interrupt load on intel I350T4 with igb on 8.3

On 14.05.2013 08:08, Barney Cordoba wrote: > The defaults are broken. Finally we managed to get to the point. Hallelujah! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "f

Re: how to completely makes an interface down?

On 26.01.2013 14:15, h bagade wrote: > I've tried the command on freebsd 8.2 with em card but doesn't work as you > mentioned. > I need such an operation to disable the connection and yes, not the led but > the link establishment itself. Is there a way to have this option on em and > igb drivers o

Re: ipfw and tablearg formatting

On 03.06.2013 18:43, Andreas Nilsson wrote: > Hello, > > Still trying out the tablearg functionality of ipfw and found the following: > > 1) > # ipfw table 100 add 192.168.0.0/24 10.0.0.1 > # ipfw table 100 list > 192.168.0.0/24 167772161 > > I guess it is correct, but not user friendly. Can't t

em(4) & DEFAULT_ITR

ot; than as 'usec/4' unit timeouts, please :-) Eugene Grosbein ___ 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"

Re: hw.igb.num_queues default

hw.igb.num_queues that may not deliver optimal > performance, but at least works out of the box? Or, better, make nmbclusters auto-tuning smarter, if any. I mean, use more nmbclusters for machines with large amounts of memory. Eugene Grosbein ___ fre

Re: DNAT in freebsd

On 29.06.2013 13:50, Sami Halabi wrote: > I think I was misunderstood... > Here is the situation i want to handle: > My box is a router that handles several /24 behind. > One of my links (em0) is connected to a private network 192.168.0.1 is me, > my neighbour is 192.168.0.2. > I want to make that

Re: DNAT in freebsd

quot;reverse" and pass your packets through both instances. Eugene Grosbein ___ 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"

Re: DNAT in freebsd

On 01.07.2013 14:30, Sami Halabi wrote: > Hi, > > I've tried the following: > > em1 - ip 10.0.1.1/24 > em2 - ip 11.0.3.1/24 > route add 11.0.4.0/24 11.0.3.2 > > ipfw flush > ipfw add 1000 nat 1 all from 10.0.1.2 to 10.0.1.1 > ipfw ad

Re: DNAT in freebsd

On 01.07.2013 17:05, Sami Halabi wrote: > Hi, > forgot to mention that but this sysctl is already set to 0. > i see in the logs packets pass 1000 rule. Use rules like 'ipfw add 1500 count log ip from any to any' to check intermediate results of translation. ___

Re: DNAT in freebsd

On 06.07.2013 14:47, Sami Halabi wrote: > Hi, > Any hope? Have you used intedmediate "ipfw count log" rules between "ipfw nat" rules I recommended? If yes, why have not you show that logs yet? Include tcpdump output from external and internal interfaces too. _

Re: FreeBSD router problems

On 14.07.2013 23:14, Barney Cordoba wrote: > So why not get a real 10gb/s card? RJ45 10gig is here, > and it works a lot better than LAGG. > > If you want to get more than 1Gb/s on a single connection, > you'd need to use roundrobin, which will alternate packets > without concern for ordering. Pu

Re: FreeBSD router problems

On 15.07.2013 22:04, Barney Cordoba wrote: > Also, IP fragmentation and TCP segments are not the same thing. TCP > segments regularly will come in out of order, NFS is too stupid to do > things correctly; IP fragmentation should not be done unless necessary > to accommodate a smaller mtu. The PR

Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type

The following reply was made to PR kern/172113; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Jack Vogel , George Neville-Neil , John Baldwin Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid

Re: UDP transmit and no flowid

dresses and TCP/UDP/SCTP ports to feed jenkins_hashword() and to fill m->m_pkthdr.flowid. Eugene Grosbein. ___ 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"

Re: UDP transmit and no flowid

On 05.03.2014 04:11, Adrian Chadd wrote: > Hi, > > On 4 March 2014 04:14, Eugene Grosbein wrote: >> On 04.03.2014 08:17, Adrian Chadd wrote: >> >>> I'll try this out in the next week or two once I've sorted out my >>> employment situation and I

icmp_error() fails to clear "fragmented" flag

>ip_off = 0; icmp_reflect(m); freeit: (I've discovered this while debugging real-world issue concerning problems with UDP fragmented traffic while using L2TP tunnel.) Please review/commit. Eugene Grosbein ___ freebsd-net@freebsd.org mai

Re: icmp_error() fails to clear "fragmented" flag

On 31.03.2014 01:00, Adrian Chadd wrote: > Can you file a PR with exactly this? :-P Done: http://www.freebsd.org/cgi/query-pr.cgi?pr=188092 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, se

Re: IPFW and VLANs

On 06.04.2014 09:26, Brett Glass wrote: > I added a few more rules, with "recv" and "xmit" options, and > checked the counts again after zeroing them and letting the router > run for a bit: > > 1 20591 8769298 count ip from any to any layer2 via re0_1 > 2 18715 8725085 count ip from a

Re: More on odd IPFW behavior

On 06.04.2014 11:27, Brett Glass wrote: > A bit more investigation of IPFW's behavior on VLAN interfaces has > revealed some even stranger stuff. Consider the tallies on the > following firewall rules: > > # ipfw show | head > 1 65071 36685513 count ip from any to any layer2 via re0 >

quagga does not add interface route to the kernel

and quagga-0.99.20 from ports. Eugene Grosbein ___ 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"

Re: natd slow, eats up an entire CPU...

ours, Do not use natd, use ipfw nat instead - it uses the same libalias but completely in kernel and avoids gigantic natd overhead. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscri

Re: natd slow, eats up an entire CPU...

s > being a problem with FreeBSD-7.x -- are there some known regressions in > natd from 8.x? I do not know since there is no reason in using natd with 8.2-STABLE where it supports nearly all natd's features including multiple NAT instances and shared

Re: "ifconfig media off"?

Channels in LACP mode. As I do not want to abide huge LACP timeouts when one of lagg ports should be brought down, I've patched em/igb drivers to bring link down with "ifconfig down" command: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2010-12/msg00058.html http://unix.derkeile

Re: Intel 82550 Pro/100 Ethernet and TSO troubles

"ifconfig fxp0 -tso" seemed to solve everything. > > > Don't know if it's a bug in the card, in the driver or what... > Maybe it shouldn't be enabled by default? Do you use NAT? man ipfw clearly states: ipfw nat is not compatible

Re: Can we do perform a C style file Read/Write from within a ARP module

27.12.2011 20:11, per...@pluto.rain.com пишет: > Jason Hellenthal wrote: >> >> See siftr(4). This module writes to a file. > > Is siftr(4) new since 8.1? > > $ man siftr > No manual entry for siftr > $ cd /usr/ports > $ ls -d */*siftr* > ls: */*siftr*: No such file or directory HISTOR

Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node

ph.maxdgram, net.graph.recvspace to 8M or higher with sysctl command, until this ngctl error disappears. Eugene Grosbein ___ 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"

Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node

available > Jan 5 16:10:11 mpd2 mpd: PPTP: NgMkSockNode: No buffer space available You should bot increase these setting without increase of kern.ipc.maxsockbuf. First greatly increase kern.ipc.maxsockbuf (I use 80M for it) and only then increase net.graph.recvspace and net.graph.ma

Re: ng_mppc_decompress: too many (4094) packets dropped, disabling node

t description but they are mostly have no documentation other than kernel sources. Eugene Grosbein ___ 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"

Re: allowing gif thru ipfw

-nnvvs0 host $he_tun and not tcp and not udp and not icmp Perhaps, you gif is encrypted with ipsec? That changes ip protocol numbers. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To

Re: allowing gif thru ipfw

mp -i em_vlan5 -nnvvs0 host $he_tun and not tcp and not udp and not icmp" ? I do not use IPv6 over IPv4 tunnels and not sure. Perhaps, that is IPIP protocol (number 94 decimal)? Eugene Grosbein ___ 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"

Re: kern/161899: [route] ntpd(8): Repeating RTM_MISS packets causing high CPU load for ntpd

removed from GENERIC for such misbehaviours. That had fixed same problem for me. Eugene Grosbein ___ 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"

Re: kern/161899: [route] ntpd(8): Repeating RTM_MISS packets causing high CPU load for ntpd

The following reply was made to PR kern/161899; it has been noted by GNATS. From: Eugene Grosbein To: Steven Hartland Cc: freebsd-net@freebsd.org, bug-follo...@freebsd.org Subject: Re: kern/161899: [route] ntpd(8): Repeating RTM_MISS packets causing high CPU load for ntpd Date: Wed, 08 Feb

Re: kern/162558: [dummynet] [panic] seldom dummynet panics

The following reply was made to PR kern/162558; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org Cc: Subject: Re: kern/162558: [dummynet] [panic] seldom dummynet panics Date: Wed, 15 Feb 2012 19:25:43 +0700 Hi! The source of this problem seems to be famous

netisr+lagg+fragments=80% packet loss

versized pings go through this BRAS just fine, no packet loss at all. Eugene Grosbein ___ 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"

Re: netisr+lagg+fragments=80% packet loss

25.02.2012 00:14, Eugene Grosbein пишет: > Hi! > > I've found that my PPPoE BRAS server gives 80% packet loss > for fragmented pings against itself while no packet loss for transit > fragmented pings same time. > The problem vanishes if I do ONE of following: > > 1)

Re: netisr+lagg+fragments=80% packet loss

25.02.2012 02:00, Andrew Thompson пишет: > 2012/2/25 Eugene Grosbein : >> 25.02.2012 00:14, Eugene Grosbein пишет: >>> This problem occurs only when net.isr.direct=0/net.isr.direct_force=0. >>> And only when lagg1 has both ports up and running. And when I use oversized

Re: netisr+lagg+fragments=80% packet loss

25.02.2012 19:17, Eugene Grosbein пишет: > 25.02.2012 02:00, Andrew Thompson пишет: >> 2012/2/25 Eugene Grosbein : >>> 25.02.2012 00:14, Eugene Grosbein пишет: >>>> This problem occurs only when net.isr.direct=0/net.isr.direct_force=0. >>>> And only whe

suboptimal bge(4) BCM5704 performance in RELENG_8

bles/sysctls like em/igb have. Should I try to play with constants in the code and if so, what are limits of this chip? Or it will never be capable of utilizing full gigabit speed? Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists

Re: suboptimal bge(4) BCM5704 performance in RELENG_8

08.03.2012 03:29, YongHyeon PYUN пишет: > On Tue, Mar 06, 2012 at 07:54:02PM +0700, Eugene Grosbein wrote: >> Hi! >> >> Yesterday I've updated old HP ProLiant DL360 G4p to 8.3-PRELELEASE/amd64 >> running busy icecast2 server in hope it can saturate 1G bge(4) l

Re: suboptimal bge(4) BCM5704 performance in RELENG_8

>> dev.bge.0.stats.DmaReadHighPriQueueFull: 0 >> dev.bge.0.stats.SendDataCompQueueFull: 0 >> dev.bge.0.stats.RingSetSendProdIndex: 2832885493 >> dev.bge.0.stats.RingStatusUpdate: 80835 >> dev.bge.0.stats.Interrupts: 80835 >> dev.bge.0.stats.AvoidedInterrupts:

Re: suboptimal bge(4) BCM5704 performance in RELENG_8

t: 0 >> dev.bge.0.stats.rx.ifHCInOctets: 491268800 >> dev.bge.0.stats.rx.Fragments: 234 >> dev.bge.0.stats.rx.UnicastPkts: 1977202324 >> dev.bge.0.stats.rx.MulticastPkts: 0 >> dev.bge.0.stats.rx.FCSErrors: 341 > ^ > You have multiple FC

Re: suboptimal bge(4) BCM5704 performance in RELENG_8

s > statistics counter? The patch also will show more information like > whether the controller runs in PCI mode or not as well as showing > frequency of PCI clock speed. I've applied the patch. Now dmesg shows: bge0: mem 0xfdf7-0xfdf7 irq 25 at device 2.0 on pci2 bge0: CHIP ID 0x2100; ASIC REV 0x02; CHIP REV 0x21; PCI-X 66 MHz I'll watch on Ierrs counter. Eugene Grosbein ___ 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"

Re: suboptimal bge(4) BCM5704 performance in RELENG_8

09.03.2012 02:06, YongHyeon PYUN пишет: > On Wed, Mar 07, 2012 at 11:42:09PM +0700, Eugene Grosbein wrote: >> 08.03.2012 10:43, YongHyeon PYUN пишет: >> >>>>> Show me the output of "sysctl dev.bge.0.stats". >>>> >>>> # sysctl d

Re: suboptimal bge(4) BCM5704 performance in RELENG_8

cost of small extra delays. For TCP, drops are much worse than delays. Delays may be compensated with increased TCP windows and for icecast2 audio over tcp with some extra buffering at clients side. Drops make TCP flow control think the channel is overloaded when it's not. And ma

Re: Multiqueue support, igb

t queue is used ~~ 10x more often than the > others. Is this a problem? It seems you have lots of non-TCP and non-UDP traffic like PPPoE or GRE. igb(4) uses Microsoft Receive Side Scaling, so it cannot compute a hash for such ethernet frames and they all go to queue zero. That is u

Re: Use of network_interfaces in rc.conf

t; > Does the above mean following? > > ifconfig_em0="AUTO" > ifconfig_iwn0="AUTO" > ifconfig_fwp0="AUTO" > ifconfig_wlan0="AUTO" No. network_interfaces is basically historic rudiment used in 2.2.x FreeBSD version and alike. In general, you should

Re: Use of network_interfaces in rc.conf

cify boottime configuration (that survives reboots) > for an interface in rc.conf is: > ifconfig_em0="dhcp" ? Yes, thats what man rc.conf says. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinf

Re: fsck problem FreeBSD 8.3

10.04.2012 01:36, Коньков Евгений пишет: > Hi. > > Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY, CANNOT RUN FAST > FSCK > Apr 9 19:51:58 fsck: > Apr 9 19:51:58 fsck: > Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY; RUN fsck > MANUALLY. > Apr 9 19:51:58 fsck: /dev/

Re: fsck problem FreeBSD 8.3

not mean the error really exists. Do NOT run fsck on mounted file system, period. > In any case I have run fsck on this FS when it was dismounted. > There is no any errors. So, you need not bother, your file system has been already fixed. > I think here is only one problem. problem to

82576EB IPSec offload and igb(4)

Hi! What is current status of IPSec offload support for Intel 82576EB Gigabit Ethernet controller in igb(4) driver? Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any

I350 support not documented

Hi! It seems, I350 adapters are supported with igb(4) driver in 9.0-RELEASE out-of-the-box. However, not Hardware Release Notes nor igb(4) manual page have a word about that. Why? Isn't the driver ready for I350? Eugene Grosbein ___ freebs

Re: if_em and large mtu bug?

ors I confirm this with FreeBSD 8.2-STABLE/amd64, em(4) 7.3.2, Intel PRO/1000 EB. There is a workaround, though: ifconfig em0 -rxcsum -txcsum mtu 9000 work from the beginning. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.

Re: if_ipsec

el, > but the later is invisible from the OS, IIRC. Basically, he wants tunnel mode to create full-blown network interface without overhead for extra gre/gif packet header. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.

ip_output: NAT then IPSEC

Hi! How do I make FreeBSD 8-based router/NAT/security gateway first perform NAT for outgoing packets then apply IPSEC transport mode for plain TCP traffic? Presently, locally originated packets are encrypted just fine but routed and NAT-ed packet go out unencrypted. I use ipfw nat. Eugene

Re: ip_output: NAT then IPSEC

15.06.2012 03:21, Michael Sierchio пишет: > On Thu, Jun 14, 2012 at 9:42 AM, Eugene Grosbein wrote: > >> How do I make FreeBSD 8-based router/NAT/security gateway >> first perform NAT for outgoing packets then apply IPSEC transport mode >> for plain TCP traffic? >

Re: mpd5/Netgraph issues after upgrading to 7.4

more: does your box has PS/2 keyboard or USB? It matters too. For systems having USB keyboard there is another patch needed to obtain crashdumps (by Andriy Gapon): http://www.kuzbass.ru/freebsd/patches/stop_scheduler_on_panic.usb.diff Eugene Grosbein ___

Re: mpd5/Netgraph issues after upgrading to 7.4

15.06.2012 18:50, Eugene Grosbein пишет: >> unfortunately, one of my mpd5 PPPoE access servers started panicing every few >> hours. >> >> I'm running recent 8.3-STABLE (as of 23th May) with WITNESS, INVARIANTS and >> DEBUG_MEMGUARD compiled. Unfortunately,

Re: mpd5/Netgraph issues after upgrading to 7.4

17.06.2012 01:13, Arnaud Lacombe пишет: > Hi, > > On Fri, Jun 15, 2012 at 7:50 AM, Eugene Grosbein wrote: >> 15.06.2012 18:33, Przemyslaw Frasunek пишет: >>> Dear All, >>> >>> unfortunately, one of my mpd5 PPPoE access servers started panicing every >

bsnmp and HOST-RESOURCES-MIB

- 1.3.6.1.2.1.25.3.3.1.2 And without "-n" flag, please :-) I'd like it to resolve OIDs to their names. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "

Re: lagg speed trouble

conf: net.link.ifqmaxlen=10240 Reboot is required. Eugene Grosbein ___ 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"

Re: mpd5/Netgraph issues after upgrading to 7.4

d2d at ifioctl+0xccd > #9 0x803b6842 at kern_ioctl+0x92 > #10 0x803b6aa0 at ioctl+0xf0 > #11 0x80502ab2 at amd64_syscall+0x302 > #12 0x804ea8cc at Xfast_syscall+0xfc > Uptime: 17d7h18m38s Did you set net.isr.direct=0 (and/or direct_force)?

ip_reass() fails to reassemble fragmented out-of-order traffic

shows them at receiving gif interface, and only them. Note, there is no such problem for ICMP fragmented packets in this setup, IPIP fragments are affected only. Please help. Eugene Grosbein. ___ freebsd-net@freebsd.org mailing list http://lists.f

Re: ip_reass() fails to reassemble fragmented out-of-order traffic

09.07.2012 16:49, Eugene Grosbein пишет: > Hi! > > For long time I suffer from RELENG_8's inability to reassemble several types > of incoming fragmented packets when they arrive of-of-order. > > For example: my gif(4) interface has MTU=1500, so it gets fragmented &g

Re: mpd5/Netgraph issues after upgrading to 7.4

ping locks. It seems, Przemyslaw Frasunek uses proxyarp? I have no such problems but I do not use proxyarp. Could you get rid of it, Przemyslaw? Eugene Grosbein ___ 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"

Re: ip_reass() fails to reassemble fragmented out-of-order traffic

passed ipencap packets without ipfw nat processing and the problem has disappeared. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-n

Re: mpd5/Netgraph issues after upgrading to 7.4

16.07.2012 07:13, Bjoern A. Zeeb пишет: > > On 15. Jul 2012, at 20:54 , Mike Tancsa wrote: > >> On 7/10/2012 2:24 AM, Przemyslaw Frasunek wrote: It seems, Przemyslaw Frasunek uses proxyarp? I have no such problems but I do not use proxyarp. Could you get rid of it, Przemyslaw? >>>

Re: FreeBSD 10G forwarding performance @Intel

m practical point of view, I'like to state that most of us do NOT need scientifically exact ipfw counters values when pushing hardware to its maximum. Personaly, I'd like to have tunable that gives me another 15% of speed at cost of bad ipfw counters I

Re: kern/120304: [netgraph] [patch] netgraph source assumes 32-bit timeval on AMD64

Hi! This is still the problem for 9.1-PRERELEASE: ng_source is unusable for 64bit systems. The patch really helps and fixes the problem for 64bit (and breaks for 32bit :-) Perhaps, it may be improved with some #ifdef's Eugene Grosbein ___ freebs

Re: kern/120304: [netgraph] [patch] netgraph source assumes 32-bit timeval on AMD64

The following reply was made to PR kern/120304; it has been noted by GNATS. From: Eugene Grosbein To: bug-follo...@freebsd.org, "n...@freebsd.org" Cc: Subject: Re: kern/120304: [netgraph] [patch] netgraph source assumes 32-bit timeval on AMD64 Date: Tue, 07 Aug 2012 19:38:08

Send traffic to itself using real NIC

that shows me 10% packet loss (using netstat -I to see how many packets got through). I would really like using normal TCP/UDP/ICMP streams in addition of ng_source tests. Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/m

Re: Send traffic to itself using real NIC

me, I'll try to think up some kind of NETGRAPH mesh. Eugene Grosbein ___ 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"

Re: Send traffic to itself using real NIC

07.08.2012 23:32, Marko Zec пишет: > On Tuesday 07 August 2012 18:20:28 Eugene Grosbein wrote: >> On Tue, Aug 07, 2012 at 04:33:11PM +0200, Marko Zec wrote: >>> There's no need to use epair at all here. Just create a vnet jail, and >>> assign one of

Re: Send traffic to itself using real NIC

09.08.2012 11:54, Bjoern A. Zeeb пишет: >> Modern jails are cool but their manual page is not ;-) > > Depends, / is not a fairly complete file system install of FreeBSD in > your world view? ;-) [ which is what no path argument implies ] First I thought "no path argument" emplies some kind of "

Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5

w). I ran tests with same custom kernel, loading/unloading old/new drivers as modules without reboot. Schedules is default SCHED_ULE. Another note: I run mpd/PPPoE/ng0 over vr1 and http transfer were through ng0. Eugene Grosbein ___ freebsd-net@freebs

vr(4) troubles for AMD Geode CS5536 chipset

In previous letter I've described my attempts to try vr(4) from HEAD. Now I'd like to explain why I've tried it. The problem is that stock vr(4) from 8.3-STABLE/i386 has serious issues for my system. I have home router with two vr interfaces, vr0 is for LAN (IPoE) and vr1 is for WAN (PPPoE/mpd).

Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5

31.08.2012 12:19, Eugene Grosbein пишет: > With HEAD driver, for same test LA pikes to 8 and higher and it takes up to > 10 seconds > for userland applications like shell or screen(1) to respond to physical > console events: > > last pid: 1335; load averages: 8.27, 4.05,

Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5

31.08.2012 13:54, Adrian Chadd пишет: > Just as a data point - disable preemption and try again? I'll try this evening. > And run 4BSD + no preemption, try again? With ULE old driver runs with low LA and userland is just fine. Shouldn't new driver behave nice with ULE too? Anyway, I'll try and

Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5

hat too in short time. Eugene Grosbein ___ 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"

Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5

31.08.2012 22:54, Eugene Grosbein пишет: > I've rebuilt by kernel with SCHED_ULE and excluded PREEMPTION. > Stock driver works without changes in behaviour and driver from HEAD > now works very similar to old one: LA is not higher than 2 and > userland is pretty responsive. Als

Re: vr(4) troubles for AMD Geode CS5536 chipset

X underrun > None. I've read its source and learned it prints its debug to the kernel dmesg buffer with sysctl dev.vr.1.stats=1 and done that before, during and after noted failure - all counters are zero except of good frames conters (in/out). Eugene Grosbein __

Re: vr(4) troubles for AMD Geode CS5536 chipset

for newest driver? That helped me a lot - performance of new driver returned to the level of old one. Eugene Grosbein ___ 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"

Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5

05.09.2012 14:08, Adrian Chadd пишет: > I'm so sorry for dropping off the radar here. > > Can you please compile your kernel with KTR enabled so we can capture > some schedgraph traces? Yes, I can and will. What should I do besides of rebuilding the kernel with KTR and PREEMPTION? __

Re: vr(4) troubles for AMD Geode CS5536 chipset

's the case, we need to figure out why both you and i see that.. Eugene Grosbein ___ 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"

Re: vr(4) troubles for AMD Geode CS5536 chipset

07.09.2012 00:00, Adrian Chadd пишет: > On 5 September 2012 00:25, Eugene Grosbein wrote: >> 05.09.2012 14:03, Adrian Chadd пишет: >>> wait. >>> >>> Did you say that removing preemption from your kernel fixed your >>> performance issue

Re: kern/171520: [alc] alc network driver + tso + vlan does not work.

egmentation offloading (TSO). Thus, to reliably nat your net- work traffic, please disable TSO on your NICs using ifconfig(8). Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubs

Re: kern/171520: [alc] alc network driver + tso + vlan does not work.

fw nat is based on. So, the warning applies to mpd's internal NAT too. I guess this should be a culprit. Can you exclude NAT to perform "clean" experiment? Does the issue disappear when you do? Eugene Grosbein ___ freebsd-net@freebsd.

Re: kern/171520: [alc] alc network driver + tso + vlan does not work.

22.10.2012 11:09, Nikolay Nevzorov пишет: > Any traffic throuhg NAT does not cause problems. And any routed traffic so on. > > Problem only with traffic that generated on host with alc0, because host > generate packets much more bigger than MTU (about 2300 bytes per packet with > MTU 1500), a se

Re: Default ephemeral port range

bug in connect()? Please read ip(4) manual page on IP_PORTRANGE. You can choose one of three ranges for your socket (default range, low and high). Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net

  1   2   3   4   5   6   7   8   >