Re: kern/172985: [patch] [ip6] lltable leak when adding and removing IPv6 addresses

[oleg]

Synopsis: [patch] [ip6] lltable leak when adding and removing IPv6 addresses

Responsible-Changed-From-To: freebsd-net->oleg
Responsible-Changed-By: oleg
Responsible-Changed-When: Sun Apr 21 10:17:44 UTC 2013
Responsible-Changed-Why: 
grab it.

http://www.freebsd.org/cgi/query-pr.cgi?pr=172985
___
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"

tap device poor performance

[Oleg]

Hello,

I wrote a simple program to test tap device performance.
It open 2 tap devices, configure them (with aliases):

tap64: flags=8843 metric 0 mtu 1500
ether 00:13:ec:00:10:00
inet 192.168.64.1 netmask 0xff00 broadcast 192.168.64.255
inet 192.168.64.64 netmask 0x broadcast 192.168.64.64
Opened by PID 1353
tap32: flags=8843 metric 0 mtu 1500
ether 00:13:ec:00:20:00
inet 192.168.32.1 netmask 0xff00 broadcast 192.168.32.255
inet 192.168.32.32 netmask 0x broadcast 192.168.32.32
Opened by PID 1353

Then read packet from one tap device, change mask to opposite
(192.168.64.0/24 <--> 192.168.32.0/24)
in the IP headers (src_addr, dst_addr), recalculate checksum and push
to opposite tap. (tap64 <--> tap32).

How to reproduce:
run tapbridge:
#./tapbridge

Then, 2 choise:
1) with help of TTCP utilitty.

TTCP (need patched version, look ports/139112,
http://www.freebsd.org/cgi/query-pr.cgi?pr=139112)

Run ttcp in listen mode:
# ttcp -r -s -n 131000
(output skipped)

On second console run ttcp in sender mode:
# ttcp -t -s -n 131000 -S 192.168.64.64 192.168.64.32
ttcp-t: buflen=8192, nbuf=131000, align=16384/0, port=5001  tcp  ->
192.168.64.32
ttcp-t: socket
ttcp-t: connect
ttcp-t: 1073152000 bytes in 25.70 real seconds = 40778.27 KB/sec +++
ttcp-t: 131000 I/O calls, msec/call = 0.20, calls/sec = 5097.28
ttcp-t: 0.0user 4.5sys 0:25real 17% 26i+214d 494maxrss 0+2pf 493201+173csw

SPEED is appr. 40 MB/sec.

Now lets run ttcp in sender mode via lo0:

# ttcp -t -s -n 131000 192.168.64.64
ttcp-t: buflen=8192, nbuf=131000, align=16384/0, port=5001  tcp  ->
192.168.64.64
ttcp-t: socket
ttcp-t: connect
ttcp-t: 1073152000 bytes in 2.06 real seconds = 508079.09 KB/sec +++
ttcp-t: 131000 I/O calls, msec/call = 0.02, calls/sec = 63509.89
ttcp-t: 0.0user 1.3sys 0:02real 64% 21i+180d 494maxrss 0+2pf 33559+41csw

SPEED is appr. 500 MB/sec.

2) with httpd, wget
configure httpd and run it.

Download some file:
# wget --bind-address=192.168.64.64 -O /dev/null http://192.168.64.32:81/8G
--2009-09-28 18:00:45--  http://192.168.64.32:81/8G
Connecting to 192.168.64.32:81... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8589934592 (8.0G) [text/plain]
Saving to: `/dev/null'

100%[=>] 8,589,934,592 40.5M/s   in 3m 8s

2009-09-28 18:03:53 (43.6 MB/s) - `/dev/null' saved [8589934592/8589934592]

SPEED is appr. 43 MB/sec.

The test is gone on Intel Xeon 8 core machine with 16 GB of memory
running FreeBSD 7.0-RELEASE-p12 amd64.
The SAME SPEED results measuring on virtual machines
(FreeBSD 7.0 amd64, FreeBSD 7.2 amd64, FreeBSD 8.0 RC1 amd64).

So, where is bottleneck?
Also, I make a LOCK_PROFILING measure.

# sysctl debug.lock.prof.stats | grep if_tap
   maxtotal   wait_total   count   avg wait_avg
cnt_hold cnt_lock name
   252  1163161   64  317424 3 0   28
 10 /usr/src/sys/modules/if_tap/../../net/if_tap.c:681 (sleep
mutex:tap_mtx)
   109   783634  761  317426 2 0   67
 74 /usr/src/sys/modules/if_tap/../../net/if_tap.c:848 (sleep
mutex:tap_mtx)
   103   1730870 69617 2 0
10 /usr/src/sys/modules/if_tap/../../net/if_tap.c:872
(sleep mutex:tap_mtx)
   204   460785  303  190427 2 0   24
 67 /usr/src/sys/modules/if_tap/../../net/if_tap.c:865 (sleep
mutex:tap32)
81487945 0  196614 2 0
10 /usr/src/sys/modules/if_tap/../../net/if_tap.c:865
(sleep mutex:tap64)
  1 3 0  2 1 0
   00
/usr/src/sys/modules/if_tap/../../net/if_tap.c:493 (sleep
mutex:tap_mtx)
   319   471162  509  317428 1 0   34
122 /usr/src/sys/modules/if_tap/../../net/if_tap.c:653 (sleep
mutex:tap_mtx)

Seems, that this is not a locking problem...

Who can help me?

p.s. if your downloading will stuck - you need to patch your tap
device with kern/123892
(http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/123892)

p.p.s. btw on Linux similar test give me about 70 MB/sec...

Regards,
   Oleg Dolgov.
___
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/147245: [dummynet] dummynet skip traffic over configured limit with net.inet.ip.dummynet.io_fast:1

[oleg]

Synopsis: [dummynet] dummynet skip traffic over configured limit with 
net.inet.ip.dummynet.io_fast:1

Responsible-Changed-From-To: freebsd-net->oleg
Responsible-Changed-By: oleg
Responsible-Changed-When: Tue Aug 17 17:05:24 UTC 2010
Responsible-Changed-Why: 
i'll look at it.


http://www.freebsd.org/cgi/query-pr.cgi?pr=147245
___
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/122295: [bge] bge Ierr rate increase (since 6.0R) [regression]

[oleg]

Synopsis: [bge] bge Ierr rate increase (since 6.0R) [regression]

Responsible-Changed-From-To: freebsd-net->oleg
Responsible-Changed-By: oleg
Responsible-Changed-When: Mon Sep 8 17:54:39 UTC 2008
Responsible-Changed-Why: 
grab.

http://www.freebsd.org/cgi/query-pr.cgi?pr=122295
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/128401: [dummynet] [patch] dummynet does not shape traffic with fast IO enabled

[oleg]

Synopsis: [dummynet] [patch] dummynet does not shape traffic with fast IO 
enabled

Responsible-Changed-From-To: freebsd-net->oleg
Responsible-Changed-By: oleg
Responsible-Changed-When: Mon Oct 27 18:56:54 UTC 2008
Responsible-Changed-Why: 
i'll look at it.


http://www.freebsd.org/cgi/query-pr.cgi?pr=128401
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

reincarnation of bug kern/95665: [if_tun] "ping: sendto: No buffer space available"

[Oleg]

Hi All,

I can reproduce this bug easly with tap echo server (attached here), that I
was small reworked.

steps (almost same):
(All ip addresses/macs hardcoded in code).

On first machine run echo server, on second add

[EMAIL PROTECTED] route add -net 192.168.125.1/24 ip-addr-of-first-machine

and

[EMAIL PROTECTED] ping -f -n 192.168.125.2

While flood pinging, on first machine run ping for checking:

[EMAIL PROTECTED]  ping 192.168.125.2
PING 192.168.125.2 (192.168.125.2): 56 data bytes
64 bytes from 192.168.125.2 : icmp_seq=0 ttl=64 time=0.554 ms
64 bytes from 192.168.125.2: icmp_seq=1 ttl=64 time=0.180 ms
...
wait for a while
...
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available

With best regards,
Oleg Dolgov.


tun_icmp_echo_reply.c
Description: Binary data
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: reincarnation of bug kern/95665: [if_tun] "ping: sendto: No buffer space available"

[Oleg]

2007/7/27, Oleg <[EMAIL PROTECTED]>:
>
> Hi All,
>
> I can reproduce this bug easly with tap echo server (attached here), that
> I was small reworked.
>
> steps (almost same):
> (All ip addresses/macs hardcoded in code).
>
> On first machine run echo server, on second add
>
> [EMAIL PROTECTED] route add -net 192.168.125.1/24 ip-addr-of-first-machine
>
> and
>
> [EMAIL PROTECTED] ping -f -n  192.168.125.2
>
> While flood pinging, on first machine run ping for checking:
>
> [EMAIL PROTECTED]  ping 192.168.125.2
> PING 192.168.125.2 ( 192.168.125.2): 56 data bytes
> 64 bytes from 192.168.125.2 : icmp_seq=0 ttl=64 time=0.554 ms
> 64 bytes from 192.168.125.2: icmp_seq=1 ttl=64 time=0.180 ms
> ...
> wait for a while
> ...
> ping: sendto: No buffer space available
> ping: sendto: No buffer space available
> ping: sendto: No buffer space available
>
> With best regards,
> Oleg Dolgov.
>
>
I find ugly solution: if
in echo tap server we add select before read, all work perfectly!
...
while (1)
{
  if (select(tap_fd+1, &fd, NULL, NULL, NULL) == -1) {
break;
  }

  if ((ip_pkt_len = read(tap_fd, buf, sizeof(buf))) == -1) {
break;
  }

  ...
...
I don't have any ideas, why this hack fix trouble..
p.s. a few more details look here
http://lists.freebsd.org/pipermail/freebsd-net/2007-April/014064.html

p.p.s. bug reproduce on FreeBSD 6.2-RELEASE, but can't on FreeBSD
7.0-CURRENT =/
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/118128: [dummynet] Dummynet cause kernel trap or system freeze

[oleg]

Synopsis: [dummynet] Dummynet cause kernel trap or system freeze

Responsible-Changed-From-To: freebsd-net->oleg
Responsible-Changed-By: oleg
Responsible-Changed-When: Mon Nov 19 21:19:36 UTC 2007
Responsible-Changed-Why: 
grab.


http://www.freebsd.org/cgi/query-pr.cgi?pr=118128
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [bfe] [panic] Serious error: bfe failed to map RX buffer

[Oleg]

Hi, sorry for long delay, was too busy.
So, I recheck return code of bus_dmamap_load(9) and its exactly ENOMEM.
Here are fresh patch with your suggestions (diff with HEAD)

Best Regards,
  Oleg Dolgov.

2008/4/17, Pyun YongHyeon <[EMAIL PROTECTED]>:
> On Thu, Apr 17, 2008 at 12:43:53AM +0300, quad wrote:
>   > Hi,
>   >
>   >FreeBSD amd64 7.0-RELEASE, ULE, SMP.
>   >
>   >On heavy loads bfe network driver after few messages
>   >
>   >Serious error: bfe failed to map RX buffer
>   >Serious error: bfe failed to map RX buffer
>   >Serious error: bfe failed to map RX buffer
>   >...
>   >
>   >make kernel panic.
>   >
>   >Here patch.
>   >
>
>
> It would be even better if you can show me the return code of
>  bus_dmamap_load(9). If the error code is not ENOMEM it requires
>  more bus_dma(9) clean up(bfe(4) needs lots of bus_dma(9) fixing
>  and I had no time so far.)
>  Since the caller of bfe_list_newbuf() expects 0 or ENOBUFS it would
>  be even better to return ENOBUFS for failure case instead of
>  returning error code of bus_dmamap_load(9).
>
>  --
>  Regards,
>
> Pyun YongHyeon
>


if_bfe.diff
Description: Binary data
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Welcome to the "freebsd-net" mailing list (Digest mode)

[oleg]

Здравствуйте, freebsd-net-request.

Вы писали 30 травня 2006 р., 11:03:22:

> Welcome to the freebsd-net@freebsd.org mailing list!

> To post to this list, send your email to:

>   freebsd-net@freebsd.org

> General information about the mailing list is at:

>   http://lists.freebsd.org/mailman/listinfo/freebsd-net

> If you ever want to unsubscribe or change your options (eg, switch to
> or from digest mode, change your password, etc.), visit your
> subscription page at:

>  
> http://lists.freebsd.org/mailman/options/freebsd-net/oleg%40bank.lviv.ua


> You can also make such adjustments via email by sending a message to:

>   [EMAIL PROTECTED]

> with the word `help' in the subject or body (don't include the
> quotes), and you will get back a message with instructions.

> You must know your password to change your options (including changing
> the password, itself) or to unsubscribe.  It is:

>   978323!

> Normally, Mailman will remind you of your freebsd.org mailing list
> passwords once every month, although you can disable this if you
> prefer.  This reminder will also include instructions on how to
> unsubscribe or change your account options.  There is also a button on
> your options page that will email your current password to you.



-- 
С уважением,
 oleg  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: The results of your email commands

[oleg]

Здравствуйте, owner-freebsd-net.

Вы писали 31 травня 2006 р., 9:37:14:

> The results of your email command are provided below. Attached is your
> original message.


> - Unprocessed:
> Вы писали 30 травня 2006 р., 15:00:43:
> > Send freebsd-net mailing list submissions to
> > freebsd-net@freebsd.org
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > or, via email, send a message with subject or body 'help' to
> > [EMAIL PROTECTED]
> > You can reach the person managing the list at
> > [EMAIL PROTECTED]
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of freebsd-net digest..."
>     > Today's Topics:
> >1. Re: Welcome to the "freebsd-net" mailing list (Digest mode) (oleg)
> >2. Re: netgraph on disc(4) (Yann Berthier)

> - Ignored:
> >
> --

> > Message: 1
> > Date: Tue, 30 May 2006 11:17:34 +0300
> > From: oleg <[EMAIL PROTECTED]>
> > Subject: Re: Welcome to the "freebsd-net" mailing list (Digest mode)
> > To: freebsd-net@freebsd.org
> > Message-ID: <[EMAIL PROTECTED]>
> > Content-Type: text/plain; charset=Windows-1251

> > Здравствуйте, freebsd-net-request.

> > Вы писали 30 травня 2006 р., 11:03:22:

> >> Welcome to the freebsd-net@freebsd.org mailing list!

> >> To post to this list, send your email to:

> >>   freebsd-net@freebsd.org

> >> General information about the mailing list is at:

> >>   http://lists.freebsd.org/mailman/listinfo/freebsd-net

>     >> If you ever want to unsubscribe or change your options (eg, switch to
> >> or from digest mode, change your password, etc.), visit your
> >> subscription page at:

> >>  
> >>
> http://lists.freebsd.org/mailman/options/freebsd-net/oleg%40bank.lviv.ua


> >> You can also make such adjustments via email by sending a message to:

> >>   [EMAIL PROTECTED]

> >> with the word `help' in the subject or body (don't include the
> >> quotes), and you will get back a message with instructions.

> >> You must know your password to change your options (including changing
> >> the password, itself) or to unsubscribe.  It is:

> >>   978323!

> >> Normally, Mailman will remind you of your freebsd.org mailing list
> >> passwords once every month, although you can disable this if you
> >> prefer.  This reminder will also include instructions on how to
> >> unsubscribe or change your account options.  There is also a button on
> >> your options page that will email your current password to you.




> help

> -- 
> С уважением,
>  oleg  mailto:[EMAIL PROTECTED]


> - Done.




-- 
С уважением,
 oleg  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[Differential] D8637: buf_ring.h: fix memory order issues.

[oleg (Oleg Bulyzhin)]

oleg created this revision.
oleg added reviewers: kmacy, alc, kib.
oleg added a subscriber: freebsd-net-list.

REVISION SUMMARY
  Properly use acqure/release atomics.

REVISION DETAIL
  https://reviews.freebsd.org/D8637

AFFECTED FILES
  sys/sys/buf_ring.h

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: oleg, kmacy, alc, kib
Cc: freebsd-net-list
diff --git a/sys/sys/buf_ring.h b/sys/sys/buf_ring.h
--- a/sys/sys/buf_ring.h
+++ b/sys/sys/buf_ring.h
@@ -75,35 +75,29 @@
 #endif	
 	critical_enter();
 	do {
+		cons_tail = atomic_load_acq_32(&br->br_cons_tail);
 		prod_head = br->br_prod_head;
 		prod_next = (prod_head + 1) & br->br_prod_mask;
-		cons_tail = br->br_cons_tail;
 
 		if (prod_next == cons_tail) {
-			rmb();
-			if (prod_head == br->br_prod_head &&
-			cons_tail == br->br_cons_tail) {
-br->br_drops++;
-critical_exit();
-return (ENOBUFS);
-			}
-			continue;
+			br->br_drops++;
+			critical_exit();
+			return (ENOBUFS);
 		}
-	} while (!atomic_cmpset_acq_int(&br->br_prod_head, prod_head, prod_next));
+	} while (!atomic_cmpset_32(&br->br_prod_head, prod_head, prod_next));
 #ifdef DEBUG_BUFRING
 	if (br->br_ring[prod_head] != NULL)
 		panic("dangling value in enqueue");
 #endif	
 	br->br_ring[prod_head] = buf;
-
 	/*
 	 * If there are other enqueues in progress
 	 * that preceded us, we need to wait for them
 	 * to complete 
 	 */   
 	while (br->br_prod_tail != prod_head)
 		cpu_spinwait();
-	atomic_store_rel_int(&br->br_prod_tail, prod_next);
+	atomic_store_rel_32(&br->br_prod_tail, prod_next);
 	critical_exit();
 	return (0);
 }
@@ -115,19 +109,21 @@
 static __inline void *
 buf_ring_dequeue_mc(struct buf_ring *br)
 {
-	uint32_t cons_head, cons_next;
+	uint32_t cons_head, cons_next, prod_tail;
 	void *buf;
 
 	critical_enter();
 	do {
+		prod_tail = atomic_load_acq_32(&br->br_prod_tail);
 		cons_head = br->br_cons_head;
-		cons_next = (cons_head + 1) & br->br_cons_mask;
 
-		if (cons_head == br->br_prod_tail) {
+		if (cons_head == prod_tail) {
 			critical_exit();
 			return (NULL);
 		}
-	} while (!atomic_cmpset_acq_int(&br->br_cons_head, cons_head, cons_next));
+
+		cons_next = (cons_head + 1) & br->br_cons_mask;
+	} while (!atomic_cmpset_32(&br->br_cons_head, cons_head, cons_next));
 
 	buf = br->br_ring[cons_head];
 #ifdef DEBUG_BUFRING
@@ -140,10 +136,8 @@
 	 */   
 	while (br->br_cons_tail != cons_head)
 		cpu_spinwait();
-
-	atomic_store_rel_int(&br->br_cons_tail, cons_next);
+	atomic_store_rel_32(&br->br_cons_tail, cons_next);
 	critical_exit();
-
 	return (buf);
 }
 
@@ -155,62 +149,29 @@
 static __inline void *
 buf_ring_dequeue_sc(struct buf_ring *br)
 {
-	uint32_t cons_head, cons_next;
+	uint32_t cons_head, cons_next, prod_tail;
 #ifdef PREFETCH_DEFINED
 	uint32_t cons_next_next;
 #endif
-	uint32_t prod_tail;
 	void *buf;
 
-	/*
-	 * This is a workaround to allow using buf_ring on ARM and ARM64.
-	 * ARM64TODO: Fix buf_ring in a generic way.
-	 * REMARKS: It is suspected that br_cons_head does not require
-	 *   load_acq operation, but this change was extensively tested
-	 *   and confirmed it's working. To be reviewed once again in
-	 *   FreeBSD-12.
-	 *
-	 * Preventing following situation:
-
-	 * Core(0) - buf_ring_enqueue()   Core(1) - buf_ring_dequeue_sc()
-	 * -   --
-	 *
-	 *cons_head = br->br_cons_head;
-	 * atomic_cmpset_acq_32(&br->br_prod_head, ...));
-	 *buf = br->br_ring[cons_head]; >
-	 * br->br_ring[prod_head] = buf;
-	 * atomic_store_rel_32(&br->br_prod_tail, ...);
-	 *prod_tail = br->br_prod_tail;
-	 *if (cons_head == prod_tail) 
-	 *return (NULL);
-	 *`	
-	 *
-	 * <1> Load (on core 1) from br->br_ring[cons_head] can be reordered (speculative readed) by CPU.
-	 */	
-#if defined(__arm__) || defined(__aarch64__)
-	cons_head = atomic_load_acq_32(&br->br_cons_head);
-#else
-	cons_head = br->br_cons_head;
-#endif
 	prod_tail = atomic_load_acq_32(&br->br_prod_tail);
-	
-	cons_next = (cons_head + 1) & br->br_cons_mask;
-#ifdef PREFETCH_DEFINED
-	cons_next_next = (cons_head + 2) & br->br_cons_mask;
-#endif
+	cons_head = br->br_cons_head;
 	
 	if (cons_head

[Differential] D8637: buf_ring.h: fix memory order issues.

[oleg (Oleg Bulyzhin)]

oleg added a comment.


  In https://reviews.freebsd.org/D8637#180625, @alc wrote:
  
  > Have you looked at https://reviews.freebsd.org/D1945, in particular, the 
most recent postings by sbahra_repnop.org?  It's not clear to me that these 
changes will address the problem described in sbahra_repnop.org's postings.  
That said, your proposed changes do correct the most obvious remaining issues 
with the use of acquires and releases in this code.
  
  
  Yes, i've looked at https://reviews.freebsd.org/D1945 but somehow i've missed 
sbahra_repnop.org's comments. Since i was trying to fix different issue 
(https://lists.freebsd.org/pipermail/freebsd-net/2013-December/037265.html) and 
remove my own rmb() hack the problem described by sbahra_repnop.org is still 
here. I'll post updated diff tomorrow.

INLINE COMMENTS

> alc wrote in buf_ring.h:98
> You may need to use a load acquire on br_prod_tail here to establish an 
> unbroken synchronizes-with chain between the thread that enqueues an item X 
> and the thread that later dequeues it if there are other concurrent enqueues.

AFAIK 'synchronizes-with chains' are about RMW operations in between 
load_acq/store_rel sequence. Can you explain why load_acq is necessary here? I 
think producer should not care about visibility of br->br_ring[prod_head] 
stores of other producers.
Correct order of our own stores guaranteed by store_rel(&br->br_prod_tail) (and 
load_acq() in consumer).

REVISION DETAIL
  https://reviews.freebsd.org/D8637

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: oleg, kmacy, kib, alc
Cc: emaste, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D8637: buf_ring.h: fix memory order issues.

[oleg (Oleg Bulyzhin)]

oleg updated this revision to Diff 22728.
oleg added a comment.


  1. fix issues reported by sbahra_repnop.org here: 
https://reviews.freebsd.org/D1945
  2. fix synchronization chain (producer -> producer -> consumer) noted by alc.
  3. massive comments.

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D8637?vs=22507&id=22728

REVISION DETAIL
  https://reviews.freebsd.org/D8637

AFFECTED FILES
  sys/sys/buf_ring.h

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: oleg, kmacy, kib, alc
Cc: emaste, freebsd-net-list
diff --git a/sys/sys/buf_ring.h b/sys/sys/buf_ring.h
--- a/sys/sys/buf_ring.h
+++ b/sys/sys/buf_ring.h
@@ -75,35 +75,69 @@
 #endif	
 	critical_enter();
 	do {
-		prod_head = br->br_prod_head;
+		/*
+		 * load_acq(prod_head) preceding load(cons_tail) is
+		 * mandatory: cons_tail MUST be not 'older' than prod_head.
+		 * Otherwise following can happen:
+		 * a) initial state: cons_tail: 1 prod_head: 0 ring is full.
+		 * b) cpu0: reads cons_tail: 1
+		 * c) cpu1: runs consumer and sets cons_tail: 2
+		 * d) cpu1: runs producer and sets prod_head: 1
+		 *  ring is full again.
+		 * e) cpu0: reads prod_head: 1, 'ring is full' check will fail.
+		 * f) cpu0: cmpset(prod_head) will be successful.
+		 * g) ring is corrupted.
+		 */
+		prod_head = atomic_load_acq_32(&br->br_prod_head);
 		prod_next = (prod_head + 1) & br->br_prod_mask;
-		cons_tail = br->br_cons_tail;
-
-		if (prod_next == cons_tail) {
-			rmb();
-			if (prod_head == br->br_prod_head &&
-			cons_tail == br->br_cons_tail) {
-br->br_drops++;
-critical_exit();
-return (ENOBUFS);
-			}
-			continue;
+		/*
+		 * load_acq(cons_tail) is required: thus we synchronize with
+		 * consumers.
+		 */
+		cons_tail = atomic_load_acq_32(&br->br_cons_tail);
+
+		if (prod_next == cons_tail) {	/* ring is full */
+			/*
+			 * prod_head can be 'older' than cons_tail (see above),
+			 * so this can be false positive 'ring is full' error.
+			 * check it.
+			 */
+			if (prod_head != atomic_load_acq_32(&br->br_prod_head))
+continue;
+			br->br_drops++;
+			critical_exit();
+			return (ENOBUFS);
 		}
-	} while (!atomic_cmpset_acq_int(&br->br_prod_head, prod_head, prod_next));
+	} while (!atomic_cmpset_32(&br->br_prod_head, prod_head, prod_next));
 #ifdef DEBUG_BUFRING
 	if (br->br_ring[prod_head] != NULL)
 		panic("dangling value in enqueue");
 #endif	
 	br->br_ring[prod_head] = buf;
-
 	/*
-	 * If there are other enqueues in progress
-	 * that preceded us, we need to wait for them
-	 * to complete 
+	 * If there are other enqueues in progress that preceded us, we need
+	 * to wait for them to complete.
+	 * load_acq(prod_tail) is required for proper synchronization chain
+	 * among consumer and multiple producers.
+	 * Consider following scenario:
+	 * a) initial state: prod_head,prod_tail,cons_head,cons_tail are 0.
+	 *ring is empty.
+	 * b) cpu0: runs producer, grabs prod_head: 0 and sets prod_head: 1
+	 * c) cpu1: runs producer, grabs prod_head: 1 and sets prod_head: 2
+	 * d) cpu1: stores data to ring[1] and waits for prod_tail: 1
+	 * e) cpu0: stores data to ring[0], sets prod_tail: 1
+	 * f) cpu1: sees prod_tail: 1. If load(prod_tail) was done without _acq
+	 *barrier there is no guarantee that store to ring[0] is visible.
+	 * g) cpu1: executes store_rel(prod_tail: 2)
+	 * h) cpu2: runs consumer, executes load_acq(prod_tail) and sees
+	 *prod_tail: 2. acq/rel semantic in consumer/producer guarantees
+	 *consistent read from ring[1] and _does not guarantee_ consistent
+	 *read from ring[0] (if we had unordered load(prod_tail) in f).
+	 * i) cpu2: reads junk from ring[0]
 	 */   
-	while (br->br_prod_tail != prod_head)
+	while (atomic_load_acq_32(&br->br_prod_tail) != prod_head)
 		cpu_spinwait();
-	atomic_store_rel_int(&br->br_prod_tail, prod_next);
+	atomic_store_rel_32(&br->br_prod_tail, prod_next);
 	critical_exit();
 	return (0);
 }
@@ -115,19 +149,45 @@
 static __inline void *
 buf_ring_dequeue_mc(struct buf_ring *br)
 {
-	uint32_t cons_head, cons_next;
+	uint32_t cons_head, cons_next, prod_tail;
 	void *buf;
 
 	critical_enter();
 	do {
-		cons_head = br->br_cons_head;
-		cons_next = (cons_head + 1) & br->br_cons_mask;
-
-		if (cons_head == br->br_prod_tail) {
+		/*
+		 * load_acq(cons_head) preceding load(prod_tail) is
+		 * mandatory: prod_tail MUST be not 'older' than cons_head.
+		 * Otherwise following can happen:
+		 * a) initial state: prod_tail: 0 cons_head: 0 ring is empty.
+		 * b) cpu0: reads prod_tail: 0
+		 * c) cpu1: runs producer and sets prod_tail: 1
+		 * d) cpu1: runs consumer and sets cons_head: 1
+		 *  ring is empty again.
+		 * e) cpu0: reads cons_head: 1, 'ring is empty' check will fail.
+		 * f) cpu0: cmpset(cons_head) w

[Differential] D8637: buf_ring.h: fix memory order issues.

[oleg (Oleg Bulyzhin)]

oleg added a reviewer: sbahra_repnop.org.

REVISION DETAIL
  https://reviews.freebsd.org/D8637

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: oleg, kmacy, kib, alc, sbahra_repnop.org
Cc: emaste, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D1777: Associated fix for arp/nd6 timer usage.

[oleg (Oleg Bulyzhin)]

oleg added a comment.


  Please correct me if i'm wrong but there is ref leakage. In particular:
  
  "If the callout was restarted, the pending bit will be back on and"
  agree.
  
  "we just want to bail"
  no, i would say we should do LLE_REMREF(lle) first, then unlock/return
  because this one is wrong:
  
  "since the callout_reset would return 1 and our reference would have been 
remove by nd6_llinfo_settimer_locked above since canceled would have been 1."
  
  If we got callout_pending() !=0 in callout function it does mean 
callout_reset failed to stop us and callout_reset return value would be 0.
​

REVISION DETAIL
  https://reviews.freebsd.org/D1777

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: rrs, kib, jhb, imp, lstewart, gnn, sbruno, bz, adrian, rwatson
Cc: oleg, ae, bz, freebsd-net-list, emaste, hiren, julian, hselasky
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D1777: Associated fix for arp/nd6 timer usage.

[oleg (Oleg Bulyzhin)]

oleg added a comment.


  AFAIR those changes were done for _callout_stop_safe() aka 
callout_(stop|drain). 
  callout_reset_sbt_on() is not affected.

REVISION DETAIL
  https://reviews.freebsd.org/D1777

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: rrs, kib, jhb, imp, lstewart, gnn, sbruno, bz, adrian, rwatson
Cc: glebius, oleg, ae, bz, freebsd-net-list, emaste, hiren, julian, hselasky
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

FreeBSD 9 em driver high inerrupt load + network crashes

[Oleg Tarasov]

Hello,

I am currently experiencing a problem on one of my servers. Interestingly
it is the only one with such problem however it is the most loaded one.

Sometimes on this server network becomes completely unresponsitive forcing
me to attach console and reboot the system. There are no records in the
logs that could possibly point me to any direction.

However I am seing unexpected CPU interrupt load on this server:
CPU:  0.7% user,  0.0% nice,  0.2% system, 18.1% interrupt, 80.9% idle

# vmstat -i
interrupt  total   rate
irq16: em0 aac0+  8776771724  99009 <---This is
definitely a problem
irq23: ehci1  177381  2
cpu0:timer   8442700 95
irq264: em1:rx 012525811141
irq265: em1:tx 010743747121
irq266: em1:link3893  0
cpu1:timer   5513791 62
cpu2:timer   5937620 66
cpu3:timer  84101501948
Total 8904218168 100446

This server is using ipfw firewall with ipfw nat. The kernel is compiled
with IPSEC support which has 8 rules in SPD table.

The network card causing high load is em0 facing internal network. In ipfw
there are just plain allow rules on it. All nat conversions and ipsec
operations are done on another interface (em1) facing internet.

I see both em0 and aac0 sharing irq 16 so maybe it is a RAID controller
causing conflicts or whatever. Currently I can't find a solution or a
method of more in-depth diagnostics of the matter.

Please advice what can possibly cause the irq overload and how can I fight
it?

Kernel config:
=
cpu HAMMER
ident   SGP

makeoptions DEBUG=-g# Build kernel with gdb(1) debug
symbols

# IPFW

options IPFIREWALL  #firewall
options IPFIREWALL_VERBOSE  #enable logging to syslogd(8)
options IPFIREWALL_VERBOSE_LIMIT=300#limit verbosity
options IPFIREWALL_DEFAULT_TO_ACCEPT#allow everything by default
options IPFIREWALL_FORWARD  #packet destination changes
options IPFIREWALL_NAT  #ipfw kernel nat support
options IPDIVERT#divert sockets

# NAT
options LIBALIAS# libalias library, performing NAT

# IPSEC

options IPSEC
device  crypto

# Below is a common GENERIC config
=

dmesg output:
=
FreeBSD 9.1-RELEASE-p7 #2: Mon Sep 23 10:02:56 EEST 2013
**@:/usr/obj/usr/src/sys/SGP amd64
CPU: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (3392.37-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x206a7  Family = 6  Model = 2a  Stepping =
7

Features=0xbfebfbff

Features2=0x1f9ae3bf
  AMD Features=0x28100800
  AMD Features2=0x1
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8141856768 (7764 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  2
 cpu2 (AP): APIC ID:  4
 cpu3 (AP): APIC ID:  6
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
ctl: CAM Target Layer loaded
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 550
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
Event timer "HPET3" frequency 14318180 Hz quality 440
Event timer "HPET4" frequency 14318180 Hz quality 440
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  irq 16 at device 1.0 on pci0
pci1:  on pcib1
aac0:  mem 0xf780-0xf79f irq 16 at device 0.0 on
pci1
aac0: Enabling 64-bit address support
aac0: Enable Raw I/O
aac0: Enable 64-bit array
aac0: New comm. interface enabled
aac0: Adaptec 2405, aac driver 2.1.9-1
aacp0 on aac0
aacp1 on aac0
aacp2 on aac0
vgapci0:  port 0xf000-0xf03f mem
0xf740-0xf77f,0xe000-0xefff irq 16 at device 2.0 on pci0
agp0:  on vgapci0
agp0: aperture size is 256M, detected 65532k stolen memory
pci0:  at device 22.0 (no driver attached)
ehci0:  mem 0xf7e02000-0xf7e023ff irq 16
at device 26.0 on pci0
usbus0: EHCI version 1.0
usbus0 on ehci0
p

IPFW NAT instances sharing same aliasing table problem

[Oleg Tarasov]

Hi all,

I have a network with two gateways. GW1 is primary gateway and GW2 is
secondary.
I need to be able to map GW2 port to a service inside of my network. That
is done using redirect_port NAT directive but the problem is that all
computers inside the network have a default gateway pointing to GW1 so
returning packets are routed through GW1 and the goal is not achieved.

So the solution to this situation is a second NAT instance on GW2
masquarading sender IP address with the internal address of GW2.

Here is the picture.


Internet
 |
 |
 | em0 (a.b.c.d)
 GW2
 | em1 (192.168.0.2)
 |
 |
 | 192.168.0.111
Service


So basicly what comes into mind:

ipfw nat 1 config ip a.b.c.d redirect_port 192.168.0.111:80 80
ipfw nat 2 config ip 192.168.0.2

...
ipfw add 300 nat 1 all from any to any via em0
ipfw add 301 nat 2 all from any to 192.168.0.111 80 out via em1
ipfw add 302 nat 2 all from 92.168.0.111 80 to me in  via em1
...

I have given an example (which will probably not work) just to give a basic
idea of how can the goal be achieved.

But here we meet something unexpected. When the packets are passed to nat 2
they probably meet already existing entry formed by nat 1 and no actual
action is performed.
I have been struggling against a wall to make this work but could not get
it working thist way.
But one day I tried replacing nat 2 instance with natd daemon divert and
everything instantly started working.
So it seems ipfw nat instances share the same aliasing table like it should
do when using global option.

IMO this should be fixed.

P.S. Maybe I was missing some unclear option to prevent this from happening?
___
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"

Announcement: RFC5766 TURN Server / Media traffic gateway is available

[Oleg Moskalenko]

Hi All

I created a public networking project that implements RFC 5766 (and RFC 5389 
and RFC 6156). This is a NAT traversal solution for (mostly) UDP traffic. It 
can be used also as a Media traffic gateway.

Initially the code was developed for a corporate project. I obtained a legal 
permission to convert it to the public project. It has BSD license, and I use 
FreeBSD as the primary development platform. But the project compiles and runs 
well on Linux and Solaris, too. I have not tested it on MacOS, yet.

The project reached its initial goals (full implementation of aforementioned 
RFCs) and it is well tested:

http://code.google.com/p/rfc5766-turn-server/

I am working on FreeBSD port to include it into the net/ ports, if that will be 
useful for FreeBSD community.

Thanks
Oleg Moskalenko

___
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: IPSec NAT-T patch for FreeBSD 7.3

[Oleg Fedorov]

If http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff
patch is appropriate for FreeBSD 7.4-RELEASE too?
Can I use the patch with ipsec-tools 0.8?


2010/3/25 Oleg Fedorov 
>
> Many thanks!
>
> I successfully apply this patch
> http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff on
> FreeBSD 7.3-RELEASE and build custom kernel with IPSec NAT-T support. I
> use ipsec-tools 0.7.3 and it works coorectly.
>
> Thanks again.
___
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"

ifconfig alias: same subnet netmask question

[Oleg Cherevko]

Hi All,

When describing the "alias" parameter ifconfig manpage claims that "If 
the address is on the same subnet as the first network address for this 
interface, a non-conflicting netmask must be given. Usually 0x 
is most appropriate."


Taking into account that FreeBSD supports aliases from the same subnet 
with identical netmask for 6+ years now, does this statement still make 
sense? And what does this "conflicting netmask" stand for (I mean in the 
context of more or less recent FreeBSD versions, say 8.0+)?


Are there any drawbacks in setting aliases like this:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0xff00
instead of traditional:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0x
(again, for more or less recent FreeBSD versions)?

--
Olwi
___
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: ifconfig alias: same subnet netmask question

[Oleg Cherevko]

On 29.06.2011 18:10, Oleg Cherevko wrote:

Are there any drawbacks in setting aliases like this:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0xff00
instead of traditional:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0x
(again, for more or less recent FreeBSD versions)?


Sorry, the above examples should read:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0xff00 alias
and
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0x alias
of course.

--
Olwi
___
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: ifconfig alias: same subnet netmask question

[Oleg Cherevko]

Li, Qing wrote:

First of all, are you encountering any issues ?


Well, for the last 14+ years I used to setup aliases with 0x netmask and 
everything worked OK. However recently I encountered situation where 
0x-style alias triggered some unwanted network behavior.


When one sets alias like this:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0x alias
and then exports connected networks via OSPF ASE, two prefixes end up being 
exported (192.168.1.1/24 and 192.168.1.2/32).


In case of "identical netmask" setup:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0xff00 alias
only one prefix gets exported (192.168.1.1/24).

In my particular situation two exported prefixes led to wrong behavior of some 
equipment (other than FreeBSD machine in question). When I changed to "identical 
netmask" setup (one exported prefix) everything started to work flawlessly.


So far I encountered no issues with this "identical netmask" setup.
So I'd like to know why ifconfig manpage still recommends old way of setting 
aliases? Perhaps there are some pitfalls that I'm not aware of? Or manpage text 
is simply outdated?



There is an outstanding issue with the address alias and improper routing
table update that I am actively working on.

--Qing



-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Oleg Cherevko
Sent: Wednesday, June 29, 2011 8:11 AM
To: freebsd-net@freebsd.org
Subject: ifconfig alias: same subnet netmask question

Hi All,

When describing the "alias" parameter ifconfig manpage claims that "If
the address is on the same subnet as the first network address for this
interface, a non-conflicting netmask must be given. Usually 0x
is most appropriate."

Taking into account that FreeBSD supports aliases from the same subnet
with identical netmask for 6+ years now, does this statement still make
sense? And what does this "conflicting netmask" stand for (I mean in
the
context of more or less recent FreeBSD versions, say 8.0+)?

Are there any drawbacks in setting aliases like this:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0xff00
instead of traditional:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0x
(again, for more or less recent FreeBSD versions)?

--
Olwi
___
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"



--
Olwi
___
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: ifconfig alias: same subnet netmask question

[Oleg Cherevko]

Darn, I have to correct myself once again.

Oleg Cherevko wrote:

Li, Qing wrote:

First of all, are you encountering any issues ?


Well, for the last 14+ years I used to setup aliases with 0x 
netmask and everything worked OK. However recently I encountered 
situation where 0x-style alias triggered some unwanted network 
behavior.


When one sets alias like this:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0x alias
and then exports connected networks via OSPF ASE, two prefixes end up 
being exported (192.168.1.1/24 and 192.168.1.2/32).


The above two prefixes should read "(192.168.1.0/24 and 192.168.1.2/32)", of 
course.



In case of "identical netmask" setup:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0xff00 alias
only one prefix gets exported (192.168.1.1/24).


This one should read "(192.168.1.0/24)" as well.

In my particular situation two exported prefixes led to wrong behavior 
of some equipment (other than FreeBSD machine in question). When I 
changed to "identical netmask" setup (one exported prefix) everything 
started to work flawlessly.


So far I encountered no issues with this "identical netmask" setup.
So I'd like to know why ifconfig manpage still recommends old way of 
setting aliases? Perhaps there are some pitfalls that I'm not aware of? 
Or manpage text is simply outdated?



There is an outstanding issue with the address alias and improper routing
table update that I am actively working on.

--Qing



-Original Message-
From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
n...@freebsd.org] On Behalf Of Oleg Cherevko
Sent: Wednesday, June 29, 2011 8:11 AM
To: freebsd-net@freebsd.org
Subject: ifconfig alias: same subnet netmask question

Hi All,

When describing the "alias" parameter ifconfig manpage claims that "If
the address is on the same subnet as the first network address for this
interface, a non-conflicting netmask must be given. Usually 0x
is most appropriate."

Taking into account that FreeBSD supports aliases from the same subnet
with identical netmask for 6+ years now, does this statement still make
sense? And what does this "conflicting netmask" stand for (I mean in
the
context of more or less recent FreeBSD versions, say 8.0+)?

Are there any drawbacks in setting aliases like this:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0xff00
instead of traditional:
ifconfig em0 inet 192.168.1.1 netmask 0xff00
ifconfig em0 inet 192.168.1.2 netmask 0x
(again, for more or less recent FreeBSD versions)?

--
Olwi
___
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"






--
Olwi
___
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: dummynet dropping too many packets

[Oleg Bulyzhin]

On Tue, Oct 06, 2009 at 12:17:47PM +0200, Luigi Rizzo wrote:

> io_pkt_drop only reports packets dropped to errors (missing pipes,
> randomly forced packet drops which you don't use, no buffers and so on).

You are mistaken here. io_pkt_drop is total number of packets dropped by
dummynet_io().

-- 
Oleg.

====
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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: dummynet dropping too many packets

[Oleg Bulyzhin]

Please show your 'sysctl net.inet.ip' output.

-- 
Oleg.

====
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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: dummynet dropping too many packets

[Oleg Bulyzhin]

On Wed, Oct 07, 2009 at 02:23:47PM +0500, rihad wrote:

Few questions:
1) why are you not using fastforwarding?
2) search_steps/searches ratio is not that good, are you using 'buckets'
   keyword in your pipe configuration?
3) you have net.inet.ip.fw.one_pass = 0, is it intended?

-- 
Oleg.

====
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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: dummynet dropping too many packets

[Oleg Bulyzhin]

On Wed, Oct 07, 2009 at 03:16:27PM +0500, rihad wrote:
> Oleg Bulyzhin wrote:
> > On Wed, Oct 07, 2009 at 02:23:47PM +0500, rihad wrote:
> > 
> > Few questions:
> > 1) why are you not using fastforwarding?
> > 2) search_steps/searches ratio is not that good, are you using 'buckets'
> >keyword in your pipe configuration?
> > 3) you have net.inet.ip.fw.one_pass = 0, is it intended?
> > 
> 1) and 3): the box does traffic accounting and shaping, so I need 
> one_pass=0 to do both ngtee and pipes.
Still can not see any objection for not using fastforwarding, and usually
ipfw ruleset can be rearranged for using dummynet & netgraph with one_pass=1.
Could you show your 'ipfw show' output? (hide ip addresses if you wish but
keep counters please).

> 2) Hm, I'm not using "buckets", but rather 
> net.inet.ip.dummynet.hash_size. It's at default, 64. I've tried setting 
> net.inet.ip.dummynet.hash_size=65536 in sysctl.conf but somehow it was 
> still 64 after reboot, so I left it at 64. Should I make it 128? 256? 
> Does it matter that much? The load is at approx. 70-120 consumers per 
> pipe, so I thought 64 bucket size was enough.
It depends on traffic pattern, try to increase it and watch
search_steps/searches ratio (~1.001 is good enough)

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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: dummynet dropping too many packets

[Oleg Bulyzhin]

On Wed, Oct 07, 2009 at 03:52:56PM +0500, rihad wrote:

> You probably have some special sources of documentation ;-) According to 
> man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the packet 
> unless one_pass=0. Or do you mean sprinkling smart skiptos here and 
> there? ;-)

you can
1) use ng_ether & ng_netflow. (so no need in 'ngtee' rule).
2) use 'tee' rule with ng_ksocket & ng_netflow

> 
> > Could you show your 'ipfw show' output? (hide ip addresses if you wish but
> > keep counters please).
> > 

> Here it is, in its whole glory:
> 
> 00100   10434423   1484891105 allow ip from any to any via lo0
> 00200  2   14 deny ip from any to 127.0.0.0/8
> 00300  14 deny ip from 127.0.0.0/8 to any
> 01000 3300039938 327603104711 allow ip from any to any in
> 01010   26214900421138433 allow ip from me to any out
> 010205453857 46806278 allow icmp from any to any out
> 01030 3268289053 327224694165 ngtee 1 ip from any to any out
> 01040   18681181   1089636054 skipto 1100 ip from table(127) to any out 
> recv bce0 xmit bce1
> 01060  777488848  76743392754 pipe tablearg ip from any to table(0) out 
> recv bce0 xmit bce1
> 01070  776831109  76682499457 allow ip from any to table(0) out recv 
> bce0 xmit bce1
> 01100   13102697808411842 pipe tablearg ip from any to table(2) out
> 65535  662648946  66711487830 allow ip from any to any

I guess this one would be better(faster):

00050 allow ip from any to any in
00100 allow ip from any to any via lo0
01010 allow ip from me to any
01020 allow icmp from any to any
01030 ngtee 1 ip from any to any
01035 skipto 1040 ip from any to any recv bce0 xmit bce1
01036 allow ip from any to any
01040 skipto 1100 ip from table(127) to any
01060 pipe tablearg ip from any to table(0)
01070 allow ip from any to any
01100 pipe tablearg ip from any to table(2)
65535 allow ip from any to any

P.S. have you tried net.inet.ip.fastforwarding=1?

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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: dummynet dropping too many packets

[Oleg Bulyzhin]

On Wed, Oct 07, 2009 at 09:42:27PM +0500, rihad wrote:
> Julian Elischer wrote:
> > rihad wrote:
> >> Oleg Bulyzhin wrote:
> > 
> >> You probably have some special sources of documentation ;-) According 
> >> to man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the 
> >> packet unless one_pass=0. Or do you mean sprinkling smart skiptos here 
> >> and there? ;-)
> >>
> > 
> > ngtee should not have any affect on the packet.. it takes a copy..
> > 
> That's a logical conclusion, although I prefer trusting the man at hand 
> (pun intended) if I haven't tested it myself to see how it works:
> 
>   ngtee cookie
>   A copy of packet is diverted into netgraph, original packet is
>   either accepted or continues with the next rule, depending on
>   net.inet.ip.fw.one_pass sysctl variable.  See ng_ipfw(4) 
> for more
>   information on netgraph and ngtee actions.
> 
> 
> Although... I've a question to Mr. Oleg:
> 
> > 2) use 'tee' rule with ng_ksocket & ng_netflow
> 
>   tee port
>   Send a copy of packets matching this rule to the divert(4) 
> socket
>   bound to port port.  The search continues with the next rule.
> 
> how is it different from one_pass=0? Both tee and ngtee w/ one_pass=0 
> continue with the next rule.

tee & ngtee are similar with one_pass=0 and different with one_pass=1

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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: dummynet dropping too many packets

[Oleg Bulyzhin]

On Thu, Oct 08, 2009 at 09:18:23AM -0700, Julian Elischer wrote:
> that seems like a bug to me..
> neither tee should ever terminate a search.
agree. But documented bug is a feature ;) and i'm not sure if we fix this
wouldnt it break POLA?

> 
> if you want to terminate it, add a specific rule to do so.
> Unfortunately I wasn't involved in writing it.
ip_fw_pfil.c:
revision 1.17
date: 2005/02/05 12:06:33;  author: glebius;  state: Exp;  lines: +47 -0
Add a ng_ipfw node, implementing a quick and simple interface between
ipfw(4) and netgraph(4) facilities.

Reviewed by:andre, brooks, julian
   ^^

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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: dummynet dropping too many packets

[Oleg Bulyzhin]

On Fri, Oct 09, 2009 at 07:35:01PM +0500, rihad wrote:
> Oleg Bulyzhin wrote:
> > On Wed, Oct 07, 2009 at 03:52:56PM +0500, rihad wrote:
> > 
> >> You probably have some special sources of documentation ;-) According to 
> >> man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the packet 
> >> unless one_pass=0. Or do you mean sprinkling smart skiptos here and 
> >> there? ;-)
> > 
> > you can
> > 1) use ng_ether & ng_netflow. (so no need in 'ngtee' rule).
> > 2) use 'tee' rule with ng_ksocket & ng_netflow
> > 
> >>> Could you show your 'ipfw show' output? (hide ip addresses if you wish but
> >>> keep counters please).
> >>>
> > 
> >> Here it is, in its whole glory:
> >>
> >> 00100   10434423   1484891105 allow ip from any to any via lo0
> >> 00200  2   14 deny ip from any to 127.0.0.0/8
> >> 00300  14 deny ip from 127.0.0.0/8 to any
> >> 01000 3300039938 327603104711 allow ip from any to any in
> >> 01010   26214900421138433 allow ip from me to any out
> >> 010205453857 46806278 allow icmp from any to any out
> >> 01030 3268289053 327224694165 ngtee 1 ip from any to any out
> >> 01040   18681181   1089636054 skipto 1100 ip from table(127) to any out 
> >> recv bce0 xmit bce1
> >> 01060  777488848  76743392754 pipe tablearg ip from any to table(0) out 
> >> recv bce0 xmit bce1
> >> 01070  776831109  76682499457 allow ip from any to table(0) out recv 
> >> bce0 xmit bce1
> >> 01100   13102697808411842 pipe tablearg ip from any to table(2) out
> >> 65535  662648946  66711487830 allow ip from any to any
> > 
> > I guess this one would be better(faster):
> > 
> > 00050 allow ip from any to any in
> > 00100 allow ip from any to any via lo0
> > 01010 allow ip from me to any
> > 01020 allow icmp from any to any
> > 01030 ngtee 1 ip from any to any
> > 01035 skipto 1040 ip from any to any recv bce0 xmit bce1
> > 01036 allow ip from any to any
> > 01040 skipto 1100 ip from table(127) to any
> > 01060 pipe tablearg ip from any to table(0)
> > 01070 allow ip from any to any
> > 01100 pipe tablearg ip from any to table(2)
> > 65535 allow ip from any to any
> > 
> Tried it just now - no visible effect.
> 400-700 packet drops per second which is around 5-7 mbps dropped on 
> output. So I don't think getting rid of one_pass=0 would help at all.

One more idea to check:

What happens if you rearrange your rules to shape 'in' packets?
i.e. use 'in recv bce0' instead of 'out recv bce0 xmit bce1'.

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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: Connecting to a WatchGuard box

[Oleg Baranov]

Hi!

I've been working with Watchguard 8.3 & 9.0 for some time.
In general it was fine but we've suffered connection recovery problems 
after ISP blackouts from time to time.


Here is my section of racoon.conf

remote a.b.c.d
{
   exchange_mode main;

   lifetime time 8 hour ;   # sec,min,hour

   my_identifier fqdn "my.dom.ain";
   peers_identifier fqdn "watchguard.fw.dn";

   initial_contact on;

   proposal {
   encryption_algorithm 3des;
   hash_algorithm sha1;
   authentication_method pre_shared_key;
   dh_group 1;
   }
   proposal_check obey;
}


Setkey and PSK file records are standard as well as gif interfaces setup.
On Watchguard it was Branch Office Gateway and tunnel set up accordingly 
to the parameters above...




Andrea Venturoli wrote:

Hello.
A customer of mine was connecting to a remote WatchGuard box through 
their Mobile VPN client.
Now I'd like the server to take over that and le the whole network 
connect.


Did anyone ever succeded in this? Is it possible?
Should be IPSEC, but anyone has an how-to?

 bye & Thanks
av.
___
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"


___
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"

[em] vlan problem on 8.0-RELEASE

[Oleg Bulyzhin]

Creation/destroying vlans with parent em interface leads to link flap:

root# date;ifconfig vlan4000 create vlan 4000 vlandev em1 10.0.0.1/30;sleep 
5;tail -7 /var/log/kern.log
Mon Dec  7 15:18:38 MSK 2009
Dec  7 15:18:38  g kernel: vlan4000: bpf attached
Dec  7 15:18:38  g kernel: em1: Link is Down
Dec  7 15:18:38  g kernel: em1: link state changed to DOWN
Dec  7 15:18:38  g kernel: vlan4000: link state changed to DOWN
Dec  7 15:18:42  g kernel: em1: Link is up 1000 Mbps Full Duplex
Dec  7 15:18:42  g kernel: em1: link state changed to UP
Dec  7 15:18:42  g kernel: vlan4000: link state changed to UP

It's supermicro 5015B-MTB server.

e...@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086 
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) 
(82573E)'
class  = network
subclass   = ethernet
e...@pci0:15:0:0:class=0x02 card=0x109a15d9 chip=0x109a8086 
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel PRO/1000 PL Network Adaptor (82573L)'
class  = network
subclass   = ethernet

P.S. 7.2R em driver works as expected.

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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"

IPSec NAT-T patch for FreeBSD 7.3

[Oleg Fedorov]

If exist some IPSec NAT-T patch for FreeBSD 7.3?

Thanks.
___
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: IPSec NAT-T patch for FreeBSD 7.3

[Oleg Fedorov]

Many thanks!

I successfully apply this patch
http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff on
FreeBSD 7.3-RELEASE and build custom kernel with IPSec NAT-T support. I use
ipsec-tools 0.7.3 and it works coorectly.

Thanks again.

___
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"

Problem with process parallelization

[Zin';kov Oleg]

ntropy device
device  ether   # Ethernet support
device  pty # Pseudo-ttys (telnet etc)
device  vlan

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device  bpf # Berkeley packet filter

## Custom options
# NetGraph
options NETGRAPH
options NETGRAPH_ONE2MANY
options NETGRAPH_NETFLOW
options NETGRAPH_CISCO
options NETGRAPH_ETHER
options NETGRAPH_KSOCKET
options NETGRAPH_SOCKET
options NETGRAPH_TEE

options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE_LIMIT=1000
options IPFIREWALL_DEFAULT_TO_ACCEPT
options DUMMYNET
options HZ=1000
options DEVICE_POLLING
#

Interfaces:
- em0
- em1
- bge0
- bge1
- vlan (61 virtual interfaces)

#
top -S

last pid:  9673;  load averages:  1.94,  1.75,  1.57
   up 0+19:17:21
19:45:01
77 processes:  11 running, 49 sleeping, 17 waiting
CPU states:  0.0% user,  0.0% nice, 22.6% system,  0.3% interrupt, 77.0%
idle Mem: 198M Active, 410M Inact, 455M Wired, 228K Cache, 214M Buf, 2874M
Free Swap: 4096M Total, 4096M Free

  PID USERNAME  THR PRI NICE   SIZERES STATE  C   TIME   WCPU COMMAND
   11 root1 171 ki31 0K16K CPU7   7  19.0H 100.00% idle:
cpu7
   16 root1 171 ki31 0K16K CPU2   2  18.9H 100.00% idle:
cpu2
   17 root1 171 ki31 0K16K RUN1  18.8H 100.00% idle:
cpu1
   13 root1 171 ki31 0K16K CPU5   5  18.8H 100.00% idle:
cpu5
   18 root1 171 ki31 0K16K CPU0   0 916:13 100.00% idle:
cpu0
   12 root1 171 ki31 0K16K CPU6   6  18.8H 99.85% idle:
cpu6
   35 root1 -68- 0K16K CPU4   4 466:17 96.00% em1
taskq
   34 root1 -68- 0K16K CPU3   3 482:01 90.38% em0
taskq
   15 root1 171 ki31 0K16K RUN3 655:20 13.38% idle:
cpu3
   14 root1 171 ki31 0K16K RUN4 671:52  3.08% idle:
cpu4


##
19:[EMAIL PROTECTED]>netstat -w 1 -I em0
input  (em0)   output
   packets  errs  bytespackets  errs  bytes colls
 57381 0   36442155  68726 0   69126050 0
 56817 0   37480502  67656 0   66053093 0
 57847 0   39532712  68603 0   67037042 0
 56908 0   37197022  68924 0   68660108 0
 57107 0   37643382  68398 0   68113937 0
 56847 0   35944754  68394 0   67896267 0
 58754 0   39763361  68966 0   70029090 0
 58343 0   38301796  69635 0   69948678 0
^C
19:[EMAIL PROTECTED]>netstat -w 1 -I em1
input  (em1)   output
   packets  errs  bytespackets  errs  bytes colls
 67944 0   68877031  55376 0   36252905 0
 65943 0   6672  54575 0   37710643 0
 64639 0   67149621  53298 0   35423539 0
 63988 0   65035759  51787 0   35402337 0
 63849 0   65968513  50727 0   31683425 0
 64301 0   66684912  50193 0   30917339 0



###


How can we solve this problem and parallelize em1:taskq kernel processes
between all 8 processors?


-- 
ISP BGNet
288-03-53
246-68-98

Zin'kov Oleg
System administrator












-- 
ISP BGNet
288-03-53
246-68-98

Zin'kov Oleg
System administrator

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Problem with process parallelization

[Zin';kov Oleg]

  # ATA disk drives
>> options ATA_STATIC_ID   # Static device numbering
>>
>> # RAID controllers
>> device  twe # 3ware ATA RAID
>>
>> # atkbdc0 controls both the keyboard and the PS/2 mouse
>> device  atkbdc  # AT keyboard controller
>> device  atkbd   # AT keyboard
>>
>> device  vga # VGA video card driver
>>
>> device  splash  # Splash screen and screen saver support
>>
>> # syscons is the default console driver, resembling an SCO console
>> device
>> sc
>>
>> ### COM
>> device  sio
>>
>> # PCI Ethernet NICs.
>> device  em  # Intel PRO/1000 adapter Gigabit
>> Ethernet
>> Card
>>
>> # PCI Ethernet NICs that use the common MII bus controller code.
>> # NOTE: Be sure to keep the 'device miibus' line in order to use these
>> NICs! device  miibus  # MII bus support
>> device  bge # Broadcom BCM570xx Gigabit Ethernet
>> device  fxp # Intel EtherExpress PRO/100B (82557,
>> 82558)
>>
>> # Pseudo devices.
>> device  loop# Network loopback
>> device  random  # Entropy device
>> device  ether   # Ethernet support
>> device  pty # Pseudo-ttys (telnet etc)
>> device  vlan
>>
>> # The `bpf' device enables the Berkeley Packet Filter.
>> # Be aware of the administrative consequences of enabling this!
>> # Note that 'bpf' is required for DHCP.
>> device  bpf # Berkeley packet filter
>>
>> ## Custom options
>> # NetGraph
>> options NETGRAPH
>> options NETGRAPH_ONE2MANY
>> options NETGRAPH_NETFLOW
>> options NETGRAPH_CISCO
>> options NETGRAPH_ETHER
>> options NETGRAPH_KSOCKET
>> options NETGRAPH_SOCKET
>> options NETGRAPH_TEE
>>
>> options IPFIREWALL
>> options IPFIREWALL_VERBOSE
>> options IPFIREWALL_FORWARD
>> options IPFIREWALL_VERBOSE_LIMIT=1000
>> options IPFIREWALL_DEFAULT_TO_ACCEPT
>> options DUMMYNET
>> options HZ=1000
>> options DEVICE_POLLING
>> #
>>
>> Interfaces:
>> - em0
>> - em1
>> - bge0
>> - bge1
>> - vlan (61 virtual interfaces)
>>
>> #
>> top -S
>>
>> last pid:  9673;  load averages:  1.94,  1.75,  1.57
>>up 0+19:17:21
>> 19:45:01
>> 77 processes:  11 running, 49 sleeping, 17 waiting
>> CPU states:  0.0% user,  0.0% nice, 22.6% system,  0.3% interrupt, 77.0%
>> idle Mem: 198M Active, 410M Inact, 455M Wired, 228K Cache, 214M Buf,
>> 2874M
>> Free Swap: 4096M Total, 4096M Free
>>
>>   PID USERNAME  THR PRI NICE   SIZERES STATE  C   TIME   WCPU
>> COMMAND
>>11 root1 171 ki31 0K16K CPU7   7  19.0H 100.00% idle:
>> cpu7
>>16 root1 171 ki31 0K16K CPU2   2  18.9H 100.00% idle:
>> cpu2
>>17 root1 171 ki31 0K16K RUN1  18.8H 100.00% idle:
>> cpu1
>>13 root1 171 ki31 0K16K CPU5   5  18.8H 100.00% idle:
>> cpu5
>>18 root1 171 ki31 0K16K CPU0   0 916:13 100.00% idle:
>> cpu0
>>12 root1 171 ki31 0K16K CPU6   6  18.8H 99.85% idle:
>> cpu6
>>35 root1 -68- 0K16K CPU4   4 466:17 96.00% em1
>> taskq
>>34 root1 -68- 0K16K CPU3   3 482:01 90.38% em0
>> taskq
>>15 root1 171 ki31 0K16K RUN3 655:20 13.38% idle:
>> cpu3
>>14 root1 171 ki31 0K16K RUN4 671:52  3.08% idle:
>> cpu4
>>
>>
>> ##
>> 19:[EMAIL PROTECTED]>netstat -w 1 -I em0
>> input  (em0)   output
>>packets  errs  bytespackets  errs  bytes colls
>>      57381 0   36442155  68726 0   69126050 0
>>  56817 0   37480502  67656 0   66053093 0
>>  57847 0   39532712  68603 0   67037042 0
>>  56908 0   37197022  68924 0   68660108 0
>>  57107 0   37643382  68398 0   68113937 0
>> 

Re: [dummynet] Several queues connected to one pipe: "dummynet: OUCH! pipe should have been idle!"

[Oleg Bulyzhin]

On Mon, Apr 27, 2009 at 05:44:22PM +0300, Maxim Ignatenko wrote:
> 2009/4/27 Luigi Rizzo :
> > On Mon, Apr 27, 2009 at 04:51:18PM +0300, Maxim Ignatenko wrote:
> >> 2009/4/27 Luigi Rizzo :
> >> >
> >> > ok there seems to be no change related to dummynet between these
> >> > two versions so I am not sure where to look.
> >> > Could you double check what is the last working version ?
> >> >
> >>  Yes, r191201 have this problems too (it seems, i didn't updated for a
> >> long time).
> >> Now  I updated to r190864 (just before last change on ip_dummynet.c) -
> >> all works fine. Should I now check r190865?
> >
> > yes it would be great if you could identify a specific change that
> > caused the problem.
> > There is one thing particularly tricky in one of the dummynet
> > changes, because some fields changed between 32/64 bits and
> > signed/unsigned. I may have unadvertently introduced some
> > conversion bug.
> >
> 
> On r190865 problem appeared again.
> 
> > thanks a lot for the feedback
> >
> 
> You welcome :)
> 
> Thanks.
> ___
> 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"

Perhaps you stepped on this:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=879027+0+archive/2009/svn-src-all/20090419.svn-src-all

You can try to change type of dn_pipe.numbytes to int64_t (instead of dn_key).
(ip_dummynet.h:341)

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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"

kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression]

[Oleg Bulyzhin]

The following reply was made to PR kern/134157; it has been noted by GNATS.

From: Oleg Bulyzhin 
To: bug-follo...@freebsd.org
Cc: s...@ft.cv.ua
Subject: kern/134157: [dummynet] dummynet loads cpu for 100% and make a
system frozen and unstable [regression]
Date: Mon, 4 May 2009 12:05:19 +0400

 Please show sysctl net.inet.ip.dummynet output, your ipfw ruleset and
 pipe configs.
 
 -- 
 Oleg.
 
 
 === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
 
 
___
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/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression]

[Oleg Bulyzhin]

The following reply was made to PR kern/134157; it has been noted by GNATS.

From: Oleg Bulyzhin 
To: Andrey Golenischev 
Cc: bug-follo...@freebsd.org
Subject: Re: kern/134157: [dummynet] dummynet loads cpu for 100% and make a
system frozen and unstable [regression]
Date: Mon, 4 May 2009 19:09:50 +0400

 Few more questions:
 1) Are you using mpd? Did you upgrade it along with system? Have you tried
 to use mpd4? (if you have problem with mpd5)
 2) please show me values of following sysctl:
 net.inet.ip.fw.one_pass
 net.isr.direct
 
 -- 
 Oleg.
 
 
 === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
 
 
___
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"

Awful forwarding rate [7.2-Release, igb]

[Oleg Baranov]

Hello!

I have extremely low forwarding speed on 7.2-Release box with dual Intel 
82575.


Box "B" with dual 82575 nic is connected between A and C using gigabit 
swithes

A <---> B <> C


iperf run from A to C shows:

$ iperf -w 128k -c 192.168.111.3


Client connecting to 192.168.111.3, TCP port 5001
TCP window size:   129 KByte (WARNING: requested   128 KByte)

[  3] local 192.168.1.15 port 51077 connected with 192.168.111.3 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-11.2 sec160 KBytes117 Kbits/sec



the same run from A to B shows:

]$ iperf -w 128k -c 192.168.1.153

Client connecting to 192.168.1.153, TCP port 5001
TCP window size:   129 KByte (WARNING: requested   128 KByte)

[  3] local 192.168.1.15 port 60907 connected with 192.168.1.153 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes933 Mbits/sec


and from B to C shows:

$ iperf -w 128k -c 192.168.111.3

Client connecting to 192.168.111.3, TCP port 5001
TCP window size:   129 KByte (WARNING: requested   128 KByte)

[  3] local 192.168.111.254 port 64290 connected with 192.168.111.3 port 
5001

[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes930 Mbits/sec


Boxes B and C are both dual quad-core e5420 CPUs on Supermicro X7DWN+ 
motherboard.
As A I tried several machines including dual quad-core Phenom system as 
well as some portable PCs and workstations residing in the same LAN.


Here is ifconfig from B

$ ifconfig
igb0: flags=8843 metric 0 mtu 1500
   options=19b
   ether 00:30:48:c8:19:66
   inet 192.168.1.153 netmask 0xff00 broadcast 192.168.1.255
   media: Ethernet autoselect (1000baseTX )
   status: active
igb1: flags=8843 metric 0 mtu 1500
   options=19b
   ether 00:30:48:c8:19:67
   media: Ethernet autoselect (1000baseTX )
   status: active
   lagg: laggdev lagg0
lo0: flags=8049 metric 0 mtu 16384
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
   inet6 ::1 prefixlen 128
   inet 127.0.0.1 netmask 0xff00
lagg0: flags=8843 metric 0 mtu 1500
   options=19b
   ether 00:30:48:c8:19:67
   inet 192.168.111.254 netmask 0xff00 broadcast 192.168.111.255
   media: Ethernet autoselect
   status: active
   laggproto lacp
   laggport: igb1 flags=1c
gif0: flags=8051 metric 0 mtu 1280
   tunnel inet 192.168.1.153 --> 192.168.1.156
   inet 192.168.111.254 --> 192.168.112.254 netmask 0x


I tried to remove lagg & gif interfaces, boot GENERIC kernel and even 
set up same net config from LiveFS cd - nothing helps. Forwarding speed 
sometimes goes up to 1-2 Mbit/sec while local speeds are always above 
900Mbit.

System load is less 1%, logs contain nothing interesting...

Any clues and ideas would be appreciated



___
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/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression]

[Oleg Bulyzhin]

The following reply was made to PR kern/134157; it has been noted by GNATS.

From: Oleg Bulyzhin 
To: Andrey Golenischev 
Cc: bug-follo...@freebsd.org
Subject: Re: kern/134157: [dummynet] dummynet loads cpu for 100% and make a
system frozen and unstable [regression]
Date: Tue, 5 May 2009 11:19:18 +0400

 On Tue, May 05, 2009 at 12:02:44AM +0300, Andrey Golenischev wrote:
 > Yes i'm using mpd (tried with mpd4 and mpd5. Tried this on several PC's -
 > the same problem :( If i have 30-50 online users - it is ok. 100+ - dummynet
 > 100% loads and server become unstable/freezing.
 > 
 > net.inet.ip.fw.one_pass: 1
 > net.isr.direct: 1
 > 
 Could you try with net.isr.direct=0? Let me know if something will change.
 
 -- 
 Oleg.
 
 ====
 === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
 
 
___
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: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0

[Oleg Bulyzhin]

On Mon, Jun 01, 2009 at 11:12:45AM +0300, Mikolaj Golub wrote:

> It looks the problem has not drawn much attention :-).

I was on vacation so did not reply in time. 
Dummynet like solution is not enough, dummynet is affected by this problem
too.
I'll send patch to you for testing tomorrow.

-- 
Oleg.

====
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0

[Oleg Bulyzhin]

On Wed, Jun 03, 2009 at 09:03:11PM +0400, Oleg Bulyzhin wrote:
> On Mon, Jun 01, 2009 at 11:12:45AM +0300, Mikolaj Golub wrote:
> 
> > It looks the problem has not drawn much attention :-).
> 
> I was on vacation so did not reply in time. 
> Dummynet like solution is not enough, dummynet is affected by this problem
> too.
> I'll send patch to you for testing tomorrow.

Please test attached patch and let me know results.
Patch made for -current and it changes ABI, so rebuilding ipfw with new
headers required.

-- 
Oleg.

====
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


Index: sys/netinet/ip_dummynet.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.c,v
retrieving revision 1.120
diff -u -r1.120 ip_dummynet.c
--- sys/netinet/ip_dummynet.c	9 Apr 2009 12:46:00 -	1.120
+++ sys/netinet/ip_dummynet.c	4 Jun 2009 20:38:12 -
@@ -1399,6 +1399,8 @@
 	 * Build and enqueue packet + parameters.
 	 */
 	pkt->rule = fwa->rule;
+	pkt->rule_id = fwa->rule_id;
+	pkt->chain_id = fwa->chain_id;
 	pkt->dn_dir = dir;
 
 	pkt->ifp = fwa->oif;
Index: sys/netinet/ip_dummynet.h
===
RCS file: /home/ncvs/src/sys/netinet/ip_dummynet.h,v
retrieving revision 1.44
diff -u -r1.44 ip_dummynet.h
--- sys/netinet/ip_dummynet.h	4 Jun 2009 12:27:57 -	1.44
+++ sys/netinet/ip_dummynet.h	4 Jun 2009 20:38:12 -
@@ -113,6 +113,8 @@
  */
 struct dn_pkt_tag {
 struct ip_fw *rule;		/* matching rule */
+uint32_t rule_id;		/* matching rule id */
+uint32_t chain_id;		/* ruleset id */
 int dn_dir;			/* action when packet comes out. */
 #define DN_TO_IP_OUT	1
 #define DN_TO_IP_IN	2
@@ -382,16 +384,16 @@
 #define	DUMMYNET_LOADED	(ip_dn_io_ptr != NULL)
 
 /*
- * Return the IPFW rule associated with the dummynet tag; if any.
+ * Return the dummynet tag; if any.
  * Make sure that the dummynet tag is not reused by lower layers.
  */
-static __inline struct ip_fw *
-ip_dn_claim_rule(struct mbuf *m)
+static __inline struct dn_pkt_tag *
+ip_dn_claim_tag(struct mbuf *m)
 {
 	struct m_tag *mtag = m_tag_find(m, PACKET_TAG_DUMMYNET, NULL);
 	if (mtag != NULL) {
 		mtag->m_tag_id = PACKET_TAG_NONE;
-		return (((struct dn_pkt_tag *)(mtag+1))->rule);
+		return ((struct dn_pkt_tag *)(mtag + 1));
 	} else
 		return (NULL);
 }
Index: sys/netinet/ip_fw.h
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v
retrieving revision 1.127
diff -u -r1.127 ip_fw.h
--- sys/netinet/ip_fw.h	2 May 2009 08:16:26 -	1.127
+++ sys/netinet/ip_fw.h	4 Jun 2009 20:38:12 -
@@ -453,17 +453,18 @@
 	struct ip_fw	*next_rule;	/* ptr to next [skipto] rule	*/
 	/* 'next_rule' is used to pass up 'set_disable' status		*/
 
-	u_int16_t	act_ofs;	/* offset of action in 32-bit units */
-	u_int16_t	cmd_len;	/* # of 32-bit words in cmd	*/
-	u_int16_t	rulenum;	/* rule number			*/
-	u_int8_t	set;		/* rule set (0..31)		*/
+	uint16_t	act_ofs;	/* offset of action in 32-bit units */
+	uint16_t	cmd_len;	/* # of 32-bit words in cmd	*/
+	uint16_t	rulenum;	/* rule number			*/
+	uint8_t	set;		/* rule set (0..31)		*/
 #define	RESVD_SET	31	/* set for default and persistent rules */
-	u_int8_t	_pad;		/* padding			*/
+	uint8_t		_pad;		/* padding			*/
+	uint32_t	id;		/* rule id */
 
 	/* These fields are present in all rules.			*/
-	u_int64_t	pcnt;		/* Packet counter		*/
-	u_int64_t	bcnt;		/* Byte counter			*/
-	u_int32_t	timestamp;	/* tv_sec of last match		*/
+	uint64_t	pcnt;		/* Packet counter		*/
+	uint64_t	bcnt;		/* Byte counter			*/
+	uint32_t	timestamp;	/* tv_sec of last match		*/
 
 	ipfw_insn	cmd[1];		/* storage for commands		*/
 };
@@ -607,10 +608,12 @@
 	struct ifnet	*oif;		/* output interface		*/
 	struct sockaddr_in *next_hop;	/* forward address		*/
 	struct ip_fw	*rule;		/* matching rule		*/
+	uint32_t	rule_id;	/* matching rule id */
+	uint32_t	chain_id;	/* ruleset id */
 	struct ether_header *eh;	/* for bridged packets		*/
 
 	struct ipfw_flow_id f_id;	/* grabbed from IP header	*/
-	u_int32_t	cookie;		/* a cookie depending on rule action */
+	uint32_t	cookie;		/* a cookie depending on rule action */
 	struct inpcb	*inp;
 
 	struct _ip6dn_args	dummypar; /* dummynet->ip6_output */
@@ -658,6 +661,7 @@
 	LIST_HEAD(, cfg_nat) nat;   /* list of nat entries */
 	struct radix_node_head *tables[IPFW_TABLES_MAX];
 	struct rwlock	rwmtx;
+	uint32_t	id;		/* ruleset id */
 };
 
 #ifdef IPFW_INTERNAL
Index: sys/netinet/ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.223
diff -u -r1.223 ip_fw2.c
--- sys/netinet/ip_fw2.c	18 May 2009 22:34:44 -	1.223
+++ sys/ne

Re: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0

[Oleg Bulyzhin]

On Fri, Jun 05, 2009 at 04:57:52PM +0300, Mikolaj Golub wrote:

> It works for me. With the patch I has not managed to crash the system using my
> test. Some notes:
> 
> - only ng_ipfw/ng_car subsystem has been tested (not dummynet).
> - my -current box is under qemu (I don't have real server running -current to
> test this).
> 
> If you are interesting in some testing of dummynet before commiting this to
> current, let me know. I could try some tests but only the next week.

I did some testing of dummynet though extra testing would not hurt. 

-- 
Oleg.

====
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
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"

Wrong outgoing interface with multiple routing tables

[Oleg Sharoyko]

her packets at all:

r61net-fbsdhost-1, / # tcpdump -i em1 port 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes
18:01:56.665341 IP brain.cc.rsu.ru.50435 > stat.r61.net.: S 
2484180116:2484180116(0) win 65535 
18:01:56.665463 IP stat.r61.net. > brain.cc.rsu.ru.50435: S 
3905497961:3905497961(0) ack 2484180117 win 65535 
18:01:56.665798 IP brain.cc.rsu.ru.50435 > stat.r61.net.: . ack 1 win 8326 


and no packets at em0. TCP connection establishes but no data packets
come from daemon which is rather weird.

I would appreciate any help with this issue.

-- 
Oleg Sharoyko.
Software and Network Engineer
Computer Center of Rostov State University.

___
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: Wrong outgoing interface with multiple routing tables

[Oleg Sharoyko]

Julian Elischer wrote:

r61net-fbsdhost-1, / # setfib 1 /usr/sbin/sshd -o 'ListenAddress 
195.208.245.229:' -D


Are you running this from inetd?. (doesnt look like it)


No, I run this from shell merely for test purposes. First I tried to 
start sshd in a usual way in a jail, but came to this simple test example.



btw is it 1 or -1? or -F 1?
I can't remember if I supported just '1'.


According to manual page it works either way and it does indeed.


try adding a '-' on the command
and get back to me.


The same results.

--
Oleg
___
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: Wrong outgoing interface with multiple routing tables

[Oleg Sharoyko]

Julian Elischer wrote:


does it still fail if you run it in foreground mode (no daemonizing)?


Yes. I actually test sshd in foreground mode (-D tells sshd to not go 
into background). I have also checked a very simple client/server where 
server called setsockopt(SO_SETFIB, 1) and got the same results.


--
Oleg
___
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: Wrong outgoing interface with multiple routing tables

[Oleg Sharoyko]

Julian Elischer wrote:

great.. in your simple server, can you do the sockopt on the socket 
AFTER you did the listen()?

(just as a test).


Doesn't help. I have also tried to add setsockopt() after accept() (for 
a new socket) and in this case the only packet that is being sent out 
via wrong interface is the SYN+ACK from server.


I'll try to look into the kernel code tomorrow and will report any findings.

--
Oleg
___
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: Wrong outgoing interface with multiple routing tables

[Oleg Sharoyko]

On Mon, 2009-07-27 at 16:24 -0700, Julian Elischer wrote:

> > in addition to the patches already sent you might like to add the 
> > following line to netinet/tcp_input.c
> > 
> > }
> > inc.inc_fport = th->th_sport;
> > inc.inc_lport = th->th_dport;
> > inc.inc_fibnum = so->so_fibnum; <-
> > /*
> >  * Check for an existing connection attempt in syncache if
> >  * the flag is only ACK.  A successful lookup creates a new
> >  * socket appended to the listen queue in SYN_RECEIVED 
> > state.
> >  */
> 
> in fact you might try just this on its own

With this patch alone all the packets but SYN+ACK are being sent out
correctly. SYN+ACK still uses wrong interface.

ip_output() uses struct inpcb *inp argument to set fib. But when
syncache_respond() sends SYN+ACK, ip_output() is being called without
inp (from netinet/tcp_syncache.c, syncache_respond()):

 error = ip_output(m, sc->sc_ipopts, NULL, 0, NULL, NULL);

It I add
 M_SETFIB(m, sc->sc_inc.inc_fibnum);

before the call to ip_output(), then SYN+ACK goes the right way.

-- 
Oleg Sharoyko.
Software and Network Engineer
Computer Center of Rostov State University.

___
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: Wrong outgoing interface with multiple routing tables

[Oleg Sharoyko]

Julian Elischer wrote:


I'll get that checked in!


Please, also take a look at

_syncache_add() in tcp_syncache.c

There is some code which looks strange, at least at first sight. Won't 
bcopy() overwrite assigned value of sc->sc_inc.inc_fibnum ?


/* XXX-BZ this fib assignment is just useless. */
sc->sc_inc.inc_fibnum = inp->inp_inc.inc_fibnum;
bcopy(inc, &sc->sc_inc, sizeof(struct in_conninfo));

--
Oleg
___
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: Wrong outgoing interface with multiple routing tables

[Oleg Sharoyko]

Julian Elischer wrote:


ok so here's my final patch.
This is taken against -current. so it may not patch exactly cleanly.

it's not quite minimal as I'm cleaning up something too, but
could you check it works?


Works with 7.2. Thanks!


if you have ipv6 it might be nice to check that ipv6 doesn't crash
with this patch too (ipv6 doesn't support Multiple routing tables
yet).


It took me some time to setup a test IPv6 network and it also works, no 
crashes with v6 here.


--
Oleg

___
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"

What a reason to run /sbin/atmconfig diag list in /etc/network.subr?

[Oleg Ginzburg]

Getting the issue when i run a certain number of vnet-epair-jail described in 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194550 I could not 
understand why in /etc/network.subr execute atm-case from afexists() function 
and in particular, why we need to run

/sbin/atmconfig diag list 2>/dev/null 2>&1

Can someone explain what it is used for? 

-- 
TOX ID: olev...@toxme.se
(B4A584A75560D5A93DBF387FAAC56669DA18797078A46B9A9818726BEE643E52A43A6A2E3DA0)
E-mail: olev...@olevole.ru
XMPP/jabber: olev...@jabber.ru
Voice: 199.48.133.74/1001


___
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"

SIOCSVH, SIOCGVH ioctl(2) and virtio ethernet driver

[Oleg Ginzburg]

is it possible to use the carp(4) protocol with 
vtnet(4) interfaces ( which is used, for example, in bhyve(8) )
Currently, the standard carp init operation causes an SIOCGVH error:

/sbin/ifconfig vtnet0 vhid 1 advskew 100 pass pass 10.10.10.10/24 alias
ifconfig: SIOCGVH: Protocol not supported


___
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: SIOCSVH, SIOCGVH ioctl(2) and virtio ethernet driver

[Oleg Ginzburg]

On Monday 29 December 2014 14:18:01 Bryan Venteicher wrote:
> On Fri, Dec 26, 2014 at 8:09 AM, Oleg Ginzburg  wrote:
> > is it possible to use the carp(4) protocol with
> > vtnet(4) interfaces ( which is used, for example, in bhyve(8) )
> > Currently, the standard carp init operation causes an SIOCGVH error:
> > 
> > /sbin/ifconfig vtnet0 vhid 1 advskew 100 pass pass 10.10.10.10/24 alias
> > ifconfig: SIOCGVH: Protocol not supported
> 
> You probably don't have the carp(4) module loaded.

Sorry for delay.

Unfortunately the problem somewhere else. Depending on the FreeBSD revision 
there is a different behavior except usual. E.g:

a) 10.1-RELEASE and 10-STABLE:

% kldload carp
% kldstat -m carp
Id  Refs Name
4861 carp

% /sbin/ifconfig vtnet0 vhid 1 advskew 100 pass navuhodonosor 192.168.1.210/24 
state master alias
ifconfig: SIOCSVH: Invalid argument


b) On FreeBSD-current r276500M CARP IP is established for some seconds, then 
vanishes:

% /sbin/ifconfig vtnet0 vhid 1 advskew 100 pass navuhodonosor 192.168.1.210/24 
state master alias
% ifconfig vtnet0
vtnet0: flags=8943 metric 0 mtu 
1500
options=80028
ether 00:a0:98:d7:e3:65
inet 192.168.1.170 netmask 0xff00 broadcast 192.168.1.255 
inet 192.168.1.210 netmask 0xff00 broadcast 192.168.1.255 vhid 1 
nd6 options=29
media: Ethernet 10Gbase-T 
status: active
carp: BACKUP vhid 1 advbase 1 advskew 100

% ifconfig vtnet0
vtnet0: flags=8943 metric 0 mtu 
1500
options=80028
ether 00:a0:98:d7:e3:65
inet 192.168.1.170 netmask 0xff00 broadcast 192.168.1.255 
nd6 options=29
media: Ethernet 10Gbase-T 
status: active

% dmesg
...
carp_alloc_if: ifpromisc(vtnet0) failed: 45
carp: VHID 1@vtnet0: INIT -> BACKUP
carp: VHID 1@vtnet0: BACKUP -> MASTER (master down)
ifa_del_loopback_route: deletion failed: 3
ifa_del_loopback_route: deletion failed: 3


And one more dmesg from the server with more fresher revision (r280012M):

carp_alloc_if: ifpromisc(vtnet0) failed: 45
carp: 1@vtnet0: INIT -> BACKUP (initialization complete)
carp: 1@vtnet0: BACKUP -> MASTER (master timed out)



-- 
TOX ID: olev...@toxme.se
(B4A584A75560D5A93DBF387FAAC56669DA18797078A46B9A9818726BEE643E52A43A6A2E3DA0)
E-mail: olevole at olevole.ru
XMPP/jabber: olevole at jabber.ru
Voice: 199.48.133.74/1001
PGP public key: http://www.olevole.ru/olevole_pgpkey.asc
___
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: SIOCSVH, SIOCGVH ioctl(2) and virtio ethernet driver

[Oleg Ginzburg]

On Tuesday 17 March 2015 15:25:09 Gleb Smirnoff wrote:
> On Mon, Mar 16, 2015 at 02:49:58AM +0300, Oleg Ginzburg wrote:
> O> b) On FreeBSD-current r276500M CARP IP is established for some seconds, 
then  vanishes:
> In my case on r280167, all works okay, despite the carp_alloc_if warning:
> 
> #/sbin/ifconfig vtnet0 vhid 1 advskew 100 pass navuhodonosor
> 192.168.1.210/24 state master alias #dmesg | tail -n 3
> carp_alloc_if: ifpromisc(vtnet0) failed: 45
> carp: 1@vtnet0: INIT -> BACKUP (initialization complete)
> carp: 1@vtnet0: BACKUP -> MASTER (master timed out)

Yes. On FreeBSD HEAD everything is good  now (except carp_alloc_if warning 
message).  Carp removal after seconds in my case was retated toh devd 
subsystem.

___
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"

Netmap problem with e1000e driver

[Oleg Prozorov]

Hello All,
I am using Netmap technology in my program and have the problem :
when I put eth link down and then have it up netmap goes down with kernel
messages:

log from dmesg:

[ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll" option)
[ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G   O
3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1
[ 2457.286298] Hardware name: System manufacturer System Product
Name/P8H61-MX R2.0, BIOS 0803 10/26/2012
[ 2457.286300]  880198b544c4 8150ac96 880198b54400
810bd10d
[ 2457.286304]  880198b54400 002c 
810bd631
[ 2457.286307]    002c

[ 2457.286310] Call Trace:
[ 2457.286312][] ? dump_stack+0x41/0x51
[ 2457.286324]  [] ? __report_bad_irq+0x2d/0xc0
[ 2457.286328]  [] ? note_interrupt+0x241/0x290
[ 2457.286332]  [] ? handle_irq_event_percpu+0xa1/0x190
[ 2457.286336]  [] ? handle_irq_event+0x38/0x60
[ 2457.286341]  [] ? handle_edge_irq+0x85/0x150
[ 2457.286347]  [] ? handle_irq+0x1d/0x30
[ 2457.286350]  [] ? do_IRQ+0x49/0xe0
[ 2457.286355]  [] ? common_interrupt+0x6d/0x6d
[ 2457.286356][] ?
__hrtimer_start_range_ns+0x1cd/0x390
[ 2457.286364]  [] ? cpuidle_enter_state+0x52/0xc0
[ 2457.286368]  [] ? cpuidle_enter_state+0x48/0xc0
[ 2457.286372]  [] ? cpu_startup_entry+0x2f8/0x400
[ 2457.286375]  [] ? start_secondary+0x20f/0x2d0
[ 2457.286377] handlers:
[ 2457.286384] [] e1000_msix_other [e1000e]
[ 2457.286386] Disabling IRQ #44

before i have the next steps:

insmod ./netmap.ko
insmod ./e1000e/e1000e.ko

log from dmesg:

[ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[ 1645.548791] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[ 1645.549056] e1000e :02:00.0: Interrupt Throttling Rate (ints/sec)
set to dynamic conservative mode
[ 1645.549089] e1000e :02:00.0: irq 42 for MSI/MSI-X
[ 1645.549094] e1000e :02:00.0: irq 43 for MSI/MSI-X
[ 1645.549098] e1000e :02:00.0: irq 44 for MSI/MSI-X
[ 1645.704831] 635.291734 [2720] netmap_attach success for eth0
tx 1/256 rx 1/256 queues/slots
[ 1645.705079] e1000e :02:00.0 eth0: registered PHC clock
[ 1645.705083] e1000e :02:00.0 eth0: (PCI Express:2.5GT/s:Width x1)
68:05:ca:28:36:f5
[ 1645.705086] e1000e :02:00.0 eth0: Intel(R) PRO/1000 Network
Connection
[ 1645.705100] e1000e :02:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008
[ 1645.705349] e1000e :03:00.0: Interrupt Throttling Rate (ints/sec)
set to dynamic conservative mode
[ 1645.705381] e1000e :03:00.0: irq 45 for MSI/MSI-X
[ 1645.705386] e1000e :03:00.0: irq 46 for MSI/MSI-X
[ 1645.705390] e1000e :03:00.0: irq 47 for MSI/MSI-X
[ 1645.739490] systemd-udevd[2715]: renamed network interface eth0 to eth5
[ 1645.824716] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready
[ 1645.848756] 635.435799 [2720] netmap_attach success for eth0
tx 1/256 rx 1/256 queues/slots
[ 1645.848851] e1000e :03:00.0 eth0: registered PHC clock
[ 1645.848856] e1000e :03:00.0 eth0: (PCI Express:2.5GT/s:Width x1)
68:05:ca:22:19:e7
[ 1645.848859] e1000e :03:00.0 eth0: Intel(R) PRO/1000 Network
Connection
[ 1645.848875] e1000e :03:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008
[ 1645.869528] systemd-udevd[2715]: renamed network interface eth0 to eth6
[ 1645.949935] IPv6: ADDRCONF(NETDEV_UP): eth6: link is not ready
[ 1648.795532] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[ 1648.795856] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready
[ 1648.843497] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[ 1648.843820] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready
[ 1668.060841] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[ 1668.212692] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx


My program used netmap desc:
root@debian:/home/debian/Projects/bin# lsmod | grep netmap
netmap 99228  5 e1000e


Then even if it shows that link is up net map stops to work and only
rmmod/insmod and restart of the netmap can bring it back to work.

Could you please help me with it ?

Thx a lot,
Oleg.
___
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: Netmap problem with e1000e driver

[Oleg Prozorov]

Hello Stefano,
I am working on Debian 8 jessy:

kernel version: 3.16.0-4-amd64

i used netmap from link :
https://netmap.googlecode.com/archive/32e06f9d18bf82e40a7c5b6e769c0ca7607913fc.tar.gz


I did the next steps:
1) untar netmap achive
2) dowonload linux source
3) in netmap-32e06f9d18bf/LINUX directory
 3.1) ./configure  --kernel-sources=/usr/src/linux-source-3.16/
--drivers=e1000e
 3.2) make clean all
4) rmmod e1000e
5) insmod ./netmap.ko
6) insmod ./e1000e/e1000e.ko


Ethernet adapter:
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
Subsystem: Intel Corporation Gigabit CT Desktop Adapter
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at f7dc (32-bit, non-prefetchable) [size=128K]
Memory at f7d0 (32-bit, non-prefetchable) [size=512K]
I/O ports at e000 [size=32]
Memory at f7de (32-bit, non-prefetchable) [size=16K]
Expansion ROM at f7d8 [disabled] [size=256K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-28-36-f5
Kernel driver in use: e1000e

03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
Subsystem: Intel Corporation Gigabit CT Desktop Adapter
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at f7cc (32-bit, non-prefetchable) [size=128K]
Memory at f7c0 (32-bit, non-prefetchable) [size=512K]
I/O ports at d000 [size=32]
Memory at f7ce (32-bit, non-prefetchable) [size=16K]
Expansion ROM at f7c8 [disabled] [size=256K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-22-19-e7
Kernel driver in use: e1000e


My application work as netmap bridge.

rx -tx in one thread
02:00.0 -> 03:00.0

rx-tx in one thread
03:00.0 -> 02:00.0

I have attached my Netmap engine NetmapStream.cpp.

On Intel I350 T2 having Network adapter link bringing down/up ethernet
adapter has recovered successfully approx in 3-5 sec without driver crash.


Thx,
Oleg.


2015-05-28 12:54 GMT+03:00 Stefano Garzarella :

> Hi Oleg,
> I'm working on netmap with Luigi and Giuseppe (in cc).
>
> I tried to do the same steps, but I can not produce the crash.
>
> Can you you send us your kernel and netmap version?
> When you put down and up the interface, are you in tx or rx?
>
> Cheers,
> Stefano
>
> 2015-05-27 17:26 GMT+02:00 Oleg Prozorov :
>
>> Hello All,
>> I am using Netmap technology in my program and have the problem :
>> when I put eth link down and then have it up netmap goes down with kernel
>> messages:
>>
>> log from dmesg:
>>
>> [ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll"
>> option)
>> [ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G   O
>> 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1
>> [ 2457.286298] Hardware name: System manufacturer System Product
>> Name/P8H61-MX R2.0, BIOS 0803 10/26/2012
>> [ 2457.286300]  880198b544c4 8150ac96 880198b54400
>> 810bd10d
>> [ 2457.286304]  880198b54400 002c 
>> 810bd631
>> [ 2457.286307]    002c
>> 
>> [ 2457.286310] Call Trace:
>> [ 2457.286312][] ? dump_stack+0x41/0x51
>> [ 2457.286324]  [] ? __report_bad_irq+0x2d/0xc0
>> [ 2457.286328]  [] ? note_interrupt+0x241/0x290
>> [ 2457.286332]  [] ? handle_irq_event_percpu+0xa1/0x190
>> [ 2457.286336]  [] ? handle_irq_event+0x38/0x60
>> [ 2457.286341]  [] ? handle_edge_irq+0x85/0x150
>> [ 2457.286347]  [] ? handle_irq+0x1d/0x30
>> [ 2457.286350]  [] ? do_IRQ+0x49/0xe0
>> [ 2457.286355]  [] ? common_interrupt+0x6d/0x6d
>> [ 2457.286356][] ?
>> __hrtimer_start_range_ns+0x1cd/0x390
>> [ 2457.286364]  [] ? cpuidle_enter_state+0x52/0xc0
>> [ 2457.286368]  [] ? cpuidle_enter_state+0x48/0xc0
>> [ 2457.286372]  [] ? cpu_startup_entry+0x2f8/0x400
>> [ 2457.286375]  [] ? start_secondary+0x20f/0x2d0
>> [ 2457.286377] handlers:
>> [ 2457.286384] [] e1000_msix_other [e1000e]
>> [ 2457.286386] Disabling IRQ #44
>>
>> before i have the next steps:
>>
>> insmod ./netmap.ko
>> insmod ./e1000e/e1000e.ko
>>
>> log from dmesg:
>>
>> [ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
>> [ 1645.548791] e1000e: Copyright(c) 1999 - 20

Re: Netmap problem with e1000e driver

[Oleg Prozorov]

Hello Stefano,

You make my day :) It works. Greate job.

Ths a lot,
Oleg.

2015-05-28 16:26 GMT+03:00 Stefano Garzarella :

> Hi Oleg,
> can you try to apply this patch in this way:
>
> 1) untar netmap achive
> 2) dowonload linux source
> 3) in netmap-32e06f9d18bf/LINUX directory
>  3.1) ./configure  --kernel-sources=/usr/src/linux-source-3.16/
> --drivers=e1000e
>  3.2) make clean all
>
>  3.3) patch -p2 < path/to/e1000e_fix.patch
>  3.4) make
>
> 4) rmmod e1000e
> 5) insmod ./netmap.ko
> 6) insmod ./e1000e/e1000e.ko
>
> You must do make in LINUX dir before apply the patch and after that, you
> need to do again make (without clean).
>
> Tell me if it works.
>
> Thanks,
> Stefano
>
>
>
> --- netmap/LINUX/e1000e/netdev.c 2015-05-28 15:31:31.136816911 +0200
> +++ netmap/LINUX/e1000e/netdev-new.c 2015-05-28 15:33:38.503484647 +0200
> @@ -4028,6 +4028,10 @@ int e1000e_up(struct e1000_adapter *adap
>
>   netif_start_queue(adapter->netdev);
>
> +#ifdef DEV_NETMAP
> + netmap_enable_all_rings(adapter->netdev);
> +#endif /* DEV_NETMAP */
> +
>   /* fire a link change interrupt to start the watchdog */
>   if (adapter->msix_entries)
>   ew32(ICS, E1000_ICS_LSC | E1000_ICR_OTHER);
>
> 2015-05-28 14:39 GMT+02:00 Oleg Prozorov :
>
>>
>> Hello Stefano,
>> I am working on Debian 8 jessy:
>>
>> kernel version: 3.16.0-4-amd64
>>
>> i used netmap from link :
>> https://netmap.googlecode.com/archive/32e06f9d18bf82e40a7c5b6e769c0ca7607913fc.tar.gz
>>
>>
>> I did the next steps:
>> 1) untar netmap achive
>> 2) dowonload linux source
>> 3) in netmap-32e06f9d18bf/LINUX directory
>>  3.1) ./configure  --kernel-sources=/usr/src/linux-source-3.16/
>> --drivers=e1000e
>>  3.2) make clean all
>> 4) rmmod e1000e
>> 5) insmod ./netmap.ko
>> 6) insmod ./e1000e/e1000e.ko
>>
>>
>> Ethernet adapter:
>> 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
>> Connection
>> Subsystem: Intel Corporation Gigabit CT Desktop Adapter
>> Flags: bus master, fast devsel, latency 0, IRQ 16
>> Memory at f7dc (32-bit, non-prefetchable) [size=128K]
>> Memory at f7d0 (32-bit, non-prefetchable) [size=512K]
>> I/O ports at e000 [size=32]
>> Memory at f7de (32-bit, non-prefetchable) [size=16K]
>> Expansion ROM at f7d8 [disabled] [size=256K]
>> Capabilities: [c8] Power Management version 2
>> Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
>> Capabilities: [e0] Express Endpoint, MSI 00
>> Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
>> Capabilities: [100] Advanced Error Reporting
>> Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-28-36-f5
>> Kernel driver in use: e1000e
>>
>> 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
>> Connection
>> Subsystem: Intel Corporation Gigabit CT Desktop Adapter
>> Flags: bus master, fast devsel, latency 0, IRQ 17
>> Memory at f7cc (32-bit, non-prefetchable) [size=128K]
>> Memory at f7c0 (32-bit, non-prefetchable) [size=512K]
>> I/O ports at d000 [size=32]
>> Memory at f7ce (32-bit, non-prefetchable) [size=16K]
>> Expansion ROM at f7c8 [disabled] [size=256K]
>> Capabilities: [c8] Power Management version 2
>> Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
>> Capabilities: [e0] Express Endpoint, MSI 00
>> Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
>> Capabilities: [100] Advanced Error Reporting
>> Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-22-19-e7
>> Kernel driver in use: e1000e
>>
>>
>> My application work as netmap bridge.
>>
>> rx -tx in one thread
>> 02:00.0 -> 03:00.0
>>
>> rx-tx in one thread
>> 03:00.0 -> 02:00.0
>>
>> I have attached my Netmap engine NetmapStream.cpp.
>>
>> On Intel I350 T2 having Network adapter link bringing down/up ethernet
>> adapter has recovered successfully approx in 3-5 sec without driver crash.
>>
>>
>> Thx,
>> Oleg.
>>
>>
>> 2015-05-28 12:54 GMT+03:00 Stefano Garzarella <
>> stefanogarzare...@gmail.com>:
>>
>>> Hi Oleg,
>>> I'm working on netmap with Luigi and Giuseppe (in cc).
>>>
>>> I tried to do the same steps, but I can not produce the crash.
>>>
>>> Can you you send us your kernel and netmap version?
>>> When you put down and up the interface, are you in tx or rx?
>>>
>>> Cheers,
>>> Stefano
>>>
>>> 2015-05-27 17:2

full mbuf queue in tap device

[Oleg Dolgov]

In our project we use tap device to make a VPN between clients.
Server make a block read on opened and configured tap device, than send it to 
client, etc...

If I connect to server with our client and begin to download many
files from FTP throughout tunnel (300 Mb), than, after some time, tap mbuf output queue 
(ifp->if_snd) will full (ifp->if_snd.ifq_len = 49, ifp->if_snd.ifq_maxlen = 50), so,

ip_output will drop packet and return ENOBUFS.

And, even, if I will disconnect client, and just try to ping some network ip 
address,
that will go throughout tap (except tap ip addrs): no mbufs error returned.

From ddb, I see, that my server thread locked in waiting queue named "taprd".

I turn on "net.link.tap.debug" and add debug line in ether_output_frame, here 
is last line from log
(qlen is ifp->if_snd.ifq_len, where ifp is tap device):

...
qlen 0
tap0 starting
tap0 reading, minor = 0
qlen 0
tap0 starting
qlen 1
tap0 starting
qlen 2
tap0 starting
qlen 3
tap0 starting
qlen 4
tap0 starting
qlen 5
tap0 starting
qlen 6
tap0 starting
qlen 7
tap0 starting
qlen 8
tap0 starting
qlen 9
tap0 starting
qlen 10
tap0 starting
qlen 11
tap0 starting
qlen 12
tap0 starting
qlen 13
tap0 starting
qlen 14
tap0 starting
qlen 15
tap0 starting
qlen 16
tap0 starting
qlen 17
tap0 starting
qlen 18
tap0 starting
tap0 writting, minor = 0
qlen 19
tap0 starting
tap0 writting, minor = 0
tap0 writting, minor = 0
qlen 20
tap0 starting
qlen 21
tap0 starting
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
qlen 22
tap0 starting
qlen 23
tap0 starting
qlen 24
tap0 starting
qlen 25
tap0 starting
qlen 26
tap0 starting
qlen 27
tap0 starting
qlen 28
tap0 starting
qlen 29
tap0 starting
qlen 30
tap0 starting
qlen 31
tap0 starting
qlen 32
tap0 starting
qlen 33
tap0 starting
qlen 34
tap0 starting
qlen 35
tap0 starting
qlen 36
tap0 starting
qlen 37
tap0 starting
qlen 38
tap0 starting
qlen 39
tap0 starting
qlen 40
KDB: enter: beginning
tap0 starting
qlen 41
tap0 starting
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
qlen 42
tap0 starting
qlen 43
tap0 starting
qlen 44
tap0 starting
qlen 45
tap0 starting
qlen 46
tap0 starting
qlen 47
tap0 starting
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
tap0 writting, minor = 0
qlen 48
tap0 starting

As I sad early, seems, that tapifstart doesn't wakeup tapread.
I can't determine a reason of fail, because don't have experience in
the freebsd kernel development.

How and why this can happen, and how to fix?

Please, help me.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/113548: [dummynet] [patch] system hangs with dummynet queues

[Oleg Bulyzhin]

Synopsis: [dummynet] [patch] system hangs with dummynet queues

Responsible-Changed-From-To: freebsd-net->oleg
Responsible-Changed-By: oleg
Responsible-Changed-When: Fri Jun 15 17:21:30 UTC 2007
Responsible-Changed-Why: 
take over.

http://www.freebsd.org/cgi/query-pr.cgi?pr=113548
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

new mbuf flag proposal

[Oleg Bulyzhin]

Hi all.

Recently, i discovered following problem (though it was already discussed, see
http://freebsd.rambler.ru/bsdmail/freebsd-ipfw_2006/msg00491.html):
pfil handlers (like ipfw or pf) sometime need to create packets (like tcp rst
or icmp errors). In order to avoid loops M_SKIP_FIREWALL flag is used.
Unfortunately, this behaviour is not always correct.
There are configurations when you need to reinject such packets into pfil(4)
handlers (in order to translate them using NAT or apply routing policy 
or divert them somewhere, etc). In my case i had to modify kernel
in order to translate tcp keepalive packets(generated by ipfw) using pfnat.

I have a proposal how to solve this:
1) Introduce new mbuf flag, something like M_PFIL_CREATED, which should be
   used to mark packets created by pfil handler. If packet is not supposed
   to reenter pfil handlers M_SKIP_FIREWALL can be used instead.
2) When pfil handler generate packet it should be marked either with
   M_SKIP_FIREWALL or M_PFIL_CREATED. In latter case, pfil handler should add
   mbuf_tag for distinguishing source of M_PFIL_CREATED flag.

So, for packet creation code should be like this:

m->m_flags |= M_PFIL_CREATED;
mtag = m_tag_alloc(MTAG_PFIL_CREATED, PFIL_IPFW, 0, M_NOWAIT);
if (mtag) {
m_tag_prepend(m, mtag);
} else {
goto drop_pkt;
}

at the beginning of pfil handler we should have something like this:

int dont_emit_pkt = 0;

if (m->m_flags & M_PFIL_CREATED) {
dont_emit_pkt = 1;
mtag = m_tag_locate(m, MTAG_PFIL_CREATED, PFIL_IPFW, NULL);
if (mtag) { /* pkt was created by myself */
/* my own packet, handle it with care. */
goto specal_handler;
} else {/* pkt was created by other pfil(4) handler */

/* do normal processing but do not emit new packets. */
goto normal_handler;
}
}

This functionality can be archived with mbuf_tag only (without new mbuf flag),
but it would be ineffective:
calling m_tag_locate() (unsuccessful most of the time!) for every packet is
rather expensive.

What do you think about this?

-- 
Oleg.

====
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- [EMAIL PROTECTED] ===




pgpb6IJQ0mxCJ.pgp
Description: PGP signature

Re: Broadcom NetXtreme II BMC5708 no carrier

[Oleg Bulyzhin]

On Mon, Nov 26, 2007 at 02:03:38PM +0900, Pyun YongHyeon wrote:

> 
> It seems that mii_ticks is not kicked at all in auto-negotiation
> phase. From the output of forced 1000baseSX media configuration I
> guess BRGPHY_BMSR_ACOMP bit in BRGPHY_MII_BMSR is not updated on
> 5708S. Mabe davidch know better what's going on 5708S. (CCed)
> How about attached patch? I don't have the hardware so it's just a
> guess work.
> 
> -- 
> Regards,
> Pyun YongHyeon

I just want to confirm that removing mii_ticks increment was bad idea.

-- 
Oleg.

====
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- [EMAIL PROTECTED] ===


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Only last IP frag sent if ARP entry absent

[Oleg Bulyzhin]

$ sysctl net.link.ether.inet.maxhold
net.link.ether.inet.maxhold: 1
$ sysctl -d net.link.ether.inet.maxhold
net.link.ether.inet.maxhold: Number of packets to hold per ARP entry

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===




signature.asc
Description: PGP signature

ix0 (iflib) vlans @ head & 12-stable

[Oleg Bulyzhin]

While testing 12-stable i've found following:

current ixgbe driver is using iflib and has IFCAP_VLAN_HWFILTER
enabled by default.

/sys/net/iflib.c iflib_vlan_[un]register() functions have this code:

/* Re-init to load the changes */
if (if_getcapenable(ifp) & IFCAP_VLAN_HWFILTER)
iflib_if_init_locked(ctx);

Thus any vlan reconfiguration leads to link flap. This is not
how it was before iflib conversion.

I'm not sure about other vlanhwfilter aware hardware but 
intel x520-da2 cards (82599 chip) does not require re-init
after hwfilter reconfig.

Should we extend iflib framework a bit?

-- 
Oleg.



signature.asc
Description: PGP signature

Re: [Bug 236102] When create or destroy vlan, the physical interface is flapping

[Oleg Bulyzhin]

JFYI: https://lists.freebsd.org/pipermail/freebsd-net/2018-November/052184.html

-- 
Oleg.


=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: AW: axge0 and AX88179

[Oleg Lelchuk]

Yes, I am having exactly the same problem that Shteryana described. I also
got messages about wrong ip length when I started dhclient for ue0. If I
plug my device into a usb 2.0 port and enable flow control, I get
networking speeds that are around 250 Mbit/sec. If flow control is disabled
and the device is still connected to the usb 2.0 port, then I get speeds
around 200 Mbit/sec. When the device is attached to a usb 3.0 port and the
flow control is enabled, I get speeds that are around 128 Mbit/sec. The
speeds drop to something like 40 Mbit/sec when the flow control is disabled
and the device is still attached to the usb 3.0 port. But I enabled flow
control only on one machine. It was the machine to which the device was
attached to. I didn't enable flow control on the other machine on the
network, but I am sure my speeds won't get much improvement even if it's
enabled on both machines.
Since I just joined the list, let me copy and paste Shteryana's email
message that she wrote a while back:

Hi all,

I've experienced a similar problem but didn't get to analyzing it
deeper (or reporting) unfortunately ; the device is

ugen0.8:  at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=ON (124mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0300
  bDeviceClass = 0x00ff  
  bDeviceSubClass = 0x00ff
  bDeviceProtocol = 0x
  bMaxPacketSize0 = 0x0009
  idVendor = 0x0b95
  idProduct = 0x1790
  bcdDevice = 0x0100
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x0003  
  bNumConfigurations = 0x0001

what I've noticed so far -

dhclient complains about wrong ip length -

% sudo dhclient ue1
DHCPDISCOVER on ue1 to 255.255.255.255 port 67 interval 7
ifconDHCPDISCOVER on ue1 to 255.255.255.255 port 67 interval 15
ip length 328 disagrees with bytes received 332.
accepting packet with data after udp payload.
DHCPOFFER from 192.168.10.1
DHCPREQUEST on ue1 to 255.255.255.255 port 67
ip length 328 disagrees with bytes received 332.
accepting packet with data after udp payload.
DHCPACK from  192.168.10.1
bound to  192.168.10.7 -- renewal in 3600 seconds.

Running iperf3 & watching netstat -i at the same time on the interface
in question shows increasing InErrors on the interface -
NameMtu Network   Address  Ipkts Ierrs Idrop
Opkts Oerrs  Coll
...
ue11500   00:0e:c6:c6:db:ea66333   354 0
35939 0 0
ue1   - 192.168.10.0/24  192.168.10.7   66323 - -
  35927 - -

Iperf reports ~37.1 Mbits/sec on the interface.

If I attach the device on a USB2 port (or force USB2 speed on the
port) I was able to get ~ 150-200Mbits on the same system with the
same device.

This particular system has an Intel Lynx Point USB 3.0 controller

pciconf -lv | grep -A 4 xhcixhci0 at pci0
:0:20:0:
class=0x0c0330 card=0x8179103c chip=0x8c318086
rev=0x05 hdr=0x00
vendor = 'Intel Corporation'
device = '8 Series/C220 Series Chipset Family USB xHCI'
class  = serial bus
subclass   = USB

,is running FreeBSD 12.0-CURRENT #19 r315483M (M stands for a patch
similar to https://people.freebsd.org/~syrinx/freebsd_xhci-20170318-01.diff
needed to trick the controller on that particular system to actually
use USB3.0 speeds).

The same ASIX AX88179 device worked just fine reaching over 500
Mbits/sec on another system running 11.0-RELEASE-p7 with a different
USB 3 controller (will double check and report back at first
opportunity).

Hope this helps.

cheers,
Shteryana
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Fwd: AW: axge0 and AX88179

[Oleg Lelchuk]

-- Forwarded message --
From: Oleg Lelchuk 
Date: Wed, Jul 5, 2017 at 10:17 AM
Subject: Re: AW: axge0 and AX88179
To: Hans Petter Selasky 


You are addressing it to Shteryana, right?

On Wed, Jul 5, 2017 at 7:21 AM, Hans Petter Selasky  wrote:

> On 07/05/17 07:28, Oleg Lelchuk wrote:
>
>> Yes, I am having exactly the same problem that Shteryana described. I also
>> got messages about wrong ip length when I started dhclient for ue0. If I
>> plug my device into a usb 2.0 port and enable flow control, I get
>> networking speeds that are around 250 Mbit/sec. If flow control is
>> disabled
>> and the device is still connected to the usb 2.0 port, then I get speeds
>> around 200 Mbit/sec. When the device is attached to a usb 3.0 port and the
>> flow control is enabled, I get speeds that are around 128 Mbit/sec. The
>> speeds drop to something like 40 Mbit/sec when the flow control is
>> disabled
>> and the device is still attached to the usb 3.0 port. But I enabled flow
>> control only on one machine. It was the machine to which the device was
>> attached to. I didn't enable flow control on the other machine on the
>> network, but I am sure my speeds won't get much improvement even if it's
>> enabled on both machines.
>> Since I just joined the list, let me copy and paste Shteryana's email
>> message that she wrote a while back:
>>
>> Hi all,
>>
>> I've experienced a similar problem but didn't get to analyzing it
>> deeper (or reporting) unfortunately ; the device is
>>
>> ugen0.8:  at usbus0, cfg=0 md=HOST spd=SUPER
>> (5.0Gbps) pwr=ON (124mA)
>>
>>bLength = 0x0012
>>bDescriptorType = 0x0001
>>bcdUSB = 0x0300
>>bDeviceClass = 0x00ff  
>>bDeviceSubClass = 0x00ff
>>bDeviceProtocol = 0x
>>bMaxPacketSize0 = 0x0009
>>idVendor = 0x0b95
>>idProduct = 0x1790
>>bcdDevice = 0x0100
>>iManufacturer = 0x0001  
>>iProduct = 0x0002  
>>iSerialNumber = 0x0003  <C>
>>bNumConfigurations = 0x0001
>>
>> what I've noticed so far -
>>
>> dhclient complains about wrong ip length -
>>
>> % sudo dhclient ue1
>> DHCPDISCOVER on ue1 to 255.255.255.255 port 67 interval 7
>> ifconDHCPDISCOVER on ue1 to 255.255.255.255 port 67 interval 15
>> ip length 328 disagrees with bytes received 332.
>> accepting packet with data after udp payload.
>> DHCPOFFER from 192.168.10.1
>> DHCPREQUEST on ue1 to 255.255.255.255 port 67
>> ip length 328 disagrees with bytes received 332.
>> accepting packet with data after udp payload.
>> DHCPACK from  192.168.10.1
>> bound to  192.168.10.7 -- renewal in 3600 seconds.
>>
>> Running iperf3 & watching netstat -i at the same time on the interface
>> in question shows increasing InErrors on the interface -
>> NameMtu Network   Address  Ipkts Ierrs Idrop
>> Opkts Oerrs  Coll
>> ...
>> ue11500   00:0e:c6:c6:db:ea66333   354 0
>> 35939 0 0
>> ue1   - 192.168.10.0/24  192.168.10.7   66323 - -
>>35927 - -
>>
>> Iperf reports ~37.1 Mbits/sec on the interface.
>>
>> If I attach the device on a USB2 port (or force USB2 speed on the
>> port) I was able to get ~ 150-200Mbits on the same system with the
>> same device.
>>
>> This particular system has an Intel Lynx Point USB 3.0 controller
>>
>> pciconf -lv | grep -A 4 xhcixhci0 at pci0
>> <https://lists.freebsd.org/mailman/listinfo/freebsd-net>:0:20:0:
>> class=0x0c0330 card=0x8179103c chip=0x8c318086
>> rev=0x05 hdr=0x00
>>  vendor = 'Intel Corporation'
>>  device = '8 Series/C220 Series Chipset Family USB xHCI'
>>  class  = serial bus
>>  subclass   = USB
>>
>> ,is running FreeBSD 12.0-CURRENT #19 r315483M (M stands for a patch
>> similar to https://people.freebsd.org/~syrinx/freebsd_xhci-20170318-01.
>> diff
>> needed to trick the controller on that particular system to actually
>> use USB3.0 speeds).
>>
>> The same ASIX AX88179 device worked just fine reaching over 500
>> Mbits/sec on another system running 11.0-RELEASE-p7 with a different
>> USB 3 controller (will double check and report back at first
>> opportunity).
>>
>> Hope this helps.
>>
>
> Hi,
>
> Maybe you can try to use "usbdump -i usbusX -f Y -s 65536" to compare the
> USB traffic on both of these controllers in USB 3.0 mode. Make some stats
> on the transfer lengths and look for USB errors.
>
> --HPS
>
>
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

routed md5 authentication

[Oleg Sharoiko]

Hello!

I was trying to make routed (4.5 stable) and cisco 3640 (12.1(5)T) RIPv2 work
together. I discovered that MD5 authentications are not compatible. In
particular routed skips 4 bytes (family and type fields of auth data record)
of packet while computing hash for packet. This seems to be wrong according
to rfc 2082. I made a patch to fix this problem.
Could someone please revise it and commit if it's ok.

BTW: Is it correct that first RIP request is always sent without
authentication?

p.s. Please CC to my email when reply, cause I'm not on the list.

1. For include/protocols/routed.h (additional constant)

--- protocols/routed.h.org  Wed Feb 20 14:08:07 2002
+++ protocols/routed.h  Wed Feb 20 13:03:49 2002
@@ -98,7 +98,8 @@
int8_t  md5_auth_len;   /* 16 */
u_int32_t md5_seqno;/* sequence number */
u_int32_t rsvd[2];  /* must be 0 */
-#defineRIP_AUTH_MD5_LEN RIP_AUTH_PW_LEN
+#defineRIP_AUTH_HDR_LEN 4
+#defineRIP_AUTH_MD5_LEN 16
} a_md5;
} au;
 };

2. For sources of routed

diff -u routed.org/input.c routed/input.c
--- routed.org/input.c  Wed Feb 20 10:48:56 2002
+++ routed/input.c  Wed Feb 20 11:15:21 2002
@@ -967,7 +967,7 @@
 */
if (TRACEPACKETS) {
if (NA->au.a_md5.md5_auth_len
-   != RIP_AUTH_MD5_LEN)
+   != RIP_AUTH_HDR_LEN + RIP_AUTH_MD5_LEN)
msglim(use_authp, from,
   "unknown MD5 RIPv2 auth len %#x"
   " instead of %#x from %s",
@@ -989,7 +989,7 @@
}

MD5Init(&md5_ctx);
-   MD5Update(&md5_ctx, (u_char *)rip, len);
+   MD5Update(&md5_ctx, (u_char *)rip, len+RIP_AUTH_HDR_LEN);
MD5Update(&md5_ctx, ap->key, RIP_AUTH_MD5_LEN);
MD5Final(hash, &md5_ctx);
if (!memcmp(hash, na2->au.au_pw, sizeof(hash)))
--- routed.org/output.c Wed Feb 20 10:47:48 2002
+++ routed/output.c Wed Feb 20 10:50:01 2002
@@ -303,7 +303,7 @@
na2->a_type = htons(1);
na->au.a_md5.md5_pkt_len = htons(len);
MD5Init(&md5_ctx);
-   MD5Update(&md5_ctx, (u_char *)wb->buf, len);
+   MD5Update(&md5_ctx, (u_char *)wb->buf, len + RIP_AUTH_HDR_LEN);
MD5Update(&md5_ctx, ap->key, RIP_AUTH_MD5_LEN);
MD5Final(na2->au.au_pw, &md5_ctx);
wb->n++;

-- 
Oleg Sharoiko.
Software and Network Engineer
Computer Center of Rostov State University.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Patches to fix MD5 authentication in routed

[Oleg Sharoiko]

Hello!

Recently I've posted a patch on this list to fix the bug in the MD5
authentication in routed. I got no answers though :(
Wold you please be so kind as to check my patch and commit it if it's ok or
send me e-mail if this patch is wrong. The patch is attached to the message.

-- 
Oleg Sharoiko.
Software and Network Engineer
Computer Center of Rostov State University.


--- include/protocols/routed.h  Sun Sep  5 17:43:31 1999
+++ include/protocols/routed.h  Wed Feb 27 11:58:16 2002
@@ -84,6 +84,7 @@
 
 /* RIPv2 authentication */
 struct netauth {
+#define RIP_AUTH_HDR_LEN 4
u_int16_t   a_family;   /* always RIP_AF_AUTH */
u_int16_t   a_type;
 #defineRIP_AUTH_NONE   0
--- sbin/routed.org/input.c Wed Feb 20 10:48:56 2002
+++ sbin/routed/input.c Wed Feb 20 11:15:21 2002
@@ -967,7 +967,7 @@
 */
if (TRACEPACKETS) {
if (NA->au.a_md5.md5_auth_len
-   != RIP_AUTH_MD5_LEN)
+   != RIP_AUTH_HDR_LEN + RIP_AUTH_MD5_LEN)
msglim(use_authp, from,
   "unknown MD5 RIPv2 auth len %#x"
   " instead of %#x from %s",
@@ -989,7 +989,7 @@
}
 
MD5Init(&md5_ctx);
-   MD5Update(&md5_ctx, (u_char *)rip, len);
+   MD5Update(&md5_ctx, (u_char *)rip, len+RIP_AUTH_HDR_LEN);
MD5Update(&md5_ctx, ap->key, RIP_AUTH_MD5_LEN);
MD5Final(hash, &md5_ctx);
if (!memcmp(hash, na2->au.au_pw, sizeof(hash)))
--- sbin/routed.org/output.cWed Feb 20 10:47:48 2002
+++ sbin/routed/output.cWed Feb 20 10:50:01 2002
@@ -303,7 +303,7 @@
na2->a_type = htons(1);
na->au.a_md5.md5_pkt_len = htons(len);
MD5Init(&md5_ctx);
-   MD5Update(&md5_ctx, (u_char *)wb->buf, len);
+   MD5Update(&md5_ctx, (u_char *)wb->buf, len + RIP_AUTH_HDR_LEN);
MD5Update(&md5_ctx, ap->key, RIP_AUTH_MD5_LEN);
MD5Final(na2->au.au_pw, &md5_ctx);
wb->n++;

ed0: NIC memory corrupt - invalid packet length 10

[Oleg Borowkov]

Hi freebsd-net!

FreeBSD 4.4-RC and FreeBSD 4.5-STABLE
ed0 RTL8029
after tcpdump -i ed0 command
kernel log messages:
> ed0: promiscuous mode enabled
> ed0: NIC memory corrupt - invalid packet length 10
> ed0: NIC memory corrupt - invalid packet length 9
> ed0: NIC memory corrupt - invalid packet length 9
> ed0: NIC memory corrupt - invalid packet length 8
> ed0: NIC memory corrupt - invalid packet length 9
> ed0: promiscuous mode disabled
> ed0: promiscuous mode enabled  
...
What's this? and how i can fix it's?

-- 
 Oleg
 [EMAIL PROTECTED]
 icq:34687903


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: delayed ACK

[Oleg Polyakov]

--- Steve Francis <[EMAIL PROTECTED]> wrote:
> Lars Eggert wrote:
> 
> >Paul Herman wrote:
> >  
> >
> >>Not true.  Although some bugs have been fixed in 4.3, FreeBSD's
> >>delayed ACKs will still degrade your performance dramatically in
> >>some cases.
> >>
> >>
> >
> >I'm sorry, but such statements without a packet trace that exhibits the 
> >problem are just not useful.
> >
> >Lars
> >  
> >
> He's probably referring to poorly behaved windows clients, on certain 
> applications, if you leave net.inet.tcp.slowstart_flightsize at default.
> 
> Incidentally, why are not the defaults on 
> net.inet.tcp.slowstart_flightsize higher?
> RFC2414 seems to indicate it should be higher. Solaris in version 8 and 
> later default to 4 for this value.

As you may know there is RFC draft which will replace RFC2414
(draft-ietf-tsvwg-initwin-04). 
It also require to decrease cwnd in case we decreasing MSS because of
PMTU Discovery to prevent small packet bursts.

I've got patches, they are pretty trvial - somebody with commit bit has
to take a look and put them in a tree.


Oleg


__
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction

[Oleg Tarasov]

Hello,

Further analysis brought me to a conclusion that the problem is in MTU
values. Changing MTU on client machines made everything work fine -
but as I know this is not right. If packets are routed between
different MTU interfaces they have to be fragmented or something. If
fragmentation is impossible due to "dont fragment" bit set an icmp
packet "Need Fragmentation" should be sent to packet sender.

As I know web and ftp packets dont have "dont fragment" bit set so
packet fragmentation should apply normally what doesn't happen.

Reading my firewall configuration we can see that any icmp packets can
go freely through it so the reason of such malfunction is unknown to
me. Also there are rules that allow passing of fragmented packets
freely. Anyway the firewall configuration was copied from another
production system which also has different MTU's on interfaces.

Can anyone tell me what is the problem?

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction

[Oleg Tarasov]

Hello,

Gleb Smirnoff <[EMAIL PROTECTED]> wrote:


> The problem is that you've got a PPPoE link between local net and internet.

> (internet cloud, MTU 1500)-(your ISP)-[mtu 1492]-(your server)-[mtu 
> 1500]-(your
> clients).

> So, when your Windows create a new outgoing connection they set TCP MSS
> value to 1460, since they don't know about a 1492 MTU link on the way.
> And this link limits TCP MSS to 1452.

> There are numerous solutions to fix this:

> 1) ports/net/tcpmssd - a divert daemon, like natd. You need to divert
>traffic thru it, and it will alter the TCP MSS value to set limit.
> 2) ng_tcpmss(4) - a netgraph node, implementing same code in kernel.
>You usually need ng_ipfw(4) to divert traffic via ng_tcpmss(4)
> 3) Recently I have committed ng_tcpmss support into mpd, but this
>code is not yet included into any new release. If you are brave,
>you can checkout mpd from CVS and use it. It will configure ng_tcpmss
>node automatically.

I have analysed the problem further and came to a conclusion that my
ISP's server is blocking ICMP type 3 packets what leads to the
malfunction.

I have the latest version of ported mpd (3.18_3) installed and tried
to insert
 set iface enable tcpmssfix
but no positive result, but I understand that this option should help
in this situation.
 
Can you possibly tell me what am I doing wrong?
I'll say again that setting MTU on client machine to 1492 helps.
What can be the reason for tcpmssfix option not to be working? Maybe
there should be an additional kernel module loaded? I didnt find any
words mentioning usage of tcpmssfix in mpd's log file.


-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction

[Oleg Tarasov]

Hello,

Gleb Smirnoff <[EMAIL PROTECTED]> wrote:

> Unfortunately this options will not help in your situation. It affects
> only the packets received on the mpd's interface, while you need
> to alter outgoing packets.

> I have fixed this in mpd CVS, but this isn't included in any release
> yet. However, if you are experienced enough with CVS you can grab
> and compile sources yourself.

Thanks a lot, Gleb. I've downloaded mpd4 and installed it
successfully - now everything works quite fine.

Thus there were some difficulties - appearance of auth layer and
needed libpdel but as a result we have quite perfect result.

Thanks for developing my favourite ppp daemon :)

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

gif interface listener problem?

[Oleg Tarasov]

Hello,

One of my servers still runs FreeBSD 4.11. It has two internet
connections from two different providers.

First of them is used for common internet access and the second is
dedicated for a tunnel between offices.

Lets mark IPs in this way
rl0 - main interface
rl1 - tunnel interface
xxx.xxx.xxx.xxx - IP of main internet interface
XXX.XXX.XXX.XXX - IP of gateway for main interface
yyy.yyy.yyy.yyy - IP of tunnel interface
YYY.YYY.YYY.YYY - IP of gateway for tunnel interface
zzz.zzz.zzz.zzz - IP of endpoint for tunnel

I have configured policy routing using ipfw in a such way (simplifyed):

add fwd YYY.YYY.YYY.YYY all from yyy.yyy.yyy.yyy out xmit rl0
add fwd XXX.XXX.XXX.XXX all from xxx.xxx.xxx.xxx out xmit rl1
add allow ipencap from any to any via rl1
add allow all from any to any via gif0
...

gif tunnel is configured in a such way:
gif0: flags=8051 mtu 1280
tunnel inet yyy.yyy.yyy.yyy --> zzz.zzz.zzz.zzz
inet 192.168.200.1 --> 192.168.201.1 netmask 0x

The default route is to XXX.XXX.XXX.XXX
if a route
 zzz.zzz.zzz.zzz -> YYY.YYY.YYY.YYY
is manually created, everything works fine. But in this case ALL
traffic to host zzz.zzz.zzz.zzz is routed through rl1 interface and
this is unacceptable as all of rl1 bandwidth is reserved for tunneling
important interactive data.
If there is no manual route we have (dumping rl1 interface):
- all outgoing ipencap traffic goes well
- all incoming traffic comes in rl1 but is lost (gif0 interface is
empty)

It seems that gif interface listens for ipencap on the interface that
is on route to destination but not at its source (yyy.yyy.yyy.yyy in
my case).

How can I force gif to listen on correct interface? Maybe this is
corrected in later versions of FreeBSD? Should I upgrade that box?

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Policy routing and multipath routing needed (override routing table)

[Oleg Tarasov]

Hello,

Many people know how to engage policy routing using ipfw forward
function. This can be successfully used on simple routers (not NAT
gateways) and to make gateways with multiple internet connections
provide services (such as DNS, mail etc) on all interfaces.

But the difficulty comes when the box itself is the source of packets.
For example when mail server sends mail to another server. In this
case the source ip of packets is calculated using routing table based
on the destination address. These packets can't be correctly routed
using policy as in this case we should probably pass these packets
through NAT that is not always acceptable and is difficult to perform
using standart tools as forwarded packets are not injected into
firewall to be diverted through NAT.

The easiest way to show this need is a simple planning of interface
load division between internet interfaces based on services (for ex.
proxy, dns, mail, ftp etc).

In this case simple routing table can not provide what we need.

The second thing to be mentioned is known as multipath routing. It is
a special situation of policy routing but is more easy to develope. It
can solve some problems too.

I have found a mentioning of developing these functions as "planned"
by FreeBSD developers in march 2004 (http://kerneltrap.org/node/2593).

The obvious solution of this problem lies in using of Cisco router but
this is not good for medium-size business organization due to lack of
funds (you know those bosses) as thas router costs like another
routing machine ;)

It would be great to hear from core team of their plans regarding this
network stack changes.

There is another problem. In my opinion it should be great to make one
more attribute to routes in routing table indicating of their
activity/inactivity. The source of this problem is that all static
routes on reconfigured interface are deleted as ip changes. If this
reconfiguration occurs we need to recreate these routes again. It
would be great if they would persisted and for that time were
"inactive".

One of the solutions in this case would be a tool for monitoring
interface state able to activate some script on state change. This
would be great for failover for example.

Please enlight me and tell if there is any.

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Failover and load balancing using advanced NAT daemon

[Oleg Tarasov]

Hello,

I have an idea of implementation of this common task. Please tell me
if there is some alternative or use my idea to implement advanced NAT
daemon (this would be great). Maybe it would be good to upgrade
standart natd daemon.

The task:
We have several interfaces connected to internet and all having static
IPs and one (or more) interfaces to local network.
We must provide NATed internet access to local network users
load-balancing internet interfaces and providing failover. All session
have to "remember" their outgoing interface as one session will break
if packets start to come from different IPs.

A way to perform this:
- We need to monitor interface state (some simple like up/down) or more
complex like periodic gateway ping for example.
- We need to measure interface load
- We need NAT that aliases outgoing connections to one of these
interfaces
- We need to route outgoing packets based on source IP assigned by
NAT. This can be performed using ipfw forward mechanism.

First three functions would be great to be implemented inside one
daemon like standart natd. Packets should be diverted into it. This
daemon can easily perform all of the tasks listed above as all of the
packets are passed through it.

Using it in a combination with policy-routing would be a powerful
mechanism!

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Failover and load balancing using advanced NAT daemon

[Oleg Tarasov]

Hello,

Jon Simola <[EMAIL PROTECTED]> wrote:

> You may want to check out PF, the packet filter imported from OpenBSD.
> I have it running on some large routers doing NAT out multiple
> interfaces, load balancing and policy routing. Careful use of anchors
> and some scripting (or ifstated which might be in ports) can move
> traffic off failed links or respond to changing loads.

> I've done a lot with both ipfw and PF now, and I'm finding PF to be
> more flexible for my uses.

Thanks. I've looked through PF documentation and find it quite
interesting to use in this tasks. In combination with ifstated much
can be done.

I'm sorry for my incompetence in this case. I have always used ipfw
for packet processing and now find a mistake not looking through PF.
As I can now say ipfw is faster and easier to configure, but PF
contains more flexible mechanisms supporting aliasing address pools
for NAT and stateful routing.

The only visible problem I see is a lack of policy routing in FreeBSD
routing system which is used to create session listener when packets
origin is a router itself (like tunnels) and packets cant be passed
through NAT to be routed to another interface different from that in
routing table.

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Named could not listen on UDP socket: permission denied

[Oleg Tarasov]

Hello,

I run FreeBSD 6.0 and I have begun to recieve quite periodic error messages 
like these:

Jan 25 19:45:50 central named[728]: could not listen on UDP socket: permission 
denied
Jan 25 19:45:50 central named[728]: creating IPv4 interface ng0 failed; 
interface ignored

ng0 is my main internet interface and is created on early boot
(rcordered like ppp-user) by mpd. Certainly, I need DNS listening on
this interface.

The reason is that if mpd is restarted for some reason, interface ng0
is destroyed and created again while listener on this interface is
destroyed too. Named is chrooted at this time and cannot re-bind
listener on this interface. Only manual restart of named helps it bind
to this interface.

This is not deadly situation as if I manually restart mpd I will be
able to restart named too...

Running named under root user or out of chroot environment is not
quite acceptable way...

Please tell me if this problem has a solution other then above

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Duplicate SAD entries lead to ESP tunnel malfunction

[Oleg Tarasov]

kmp 172.21.0.222 [500];
}

timer
{
# These value can be changed per remote node.
counter 5;  # maximum trying count to send.
interval 20 sec;# maximum interval to resend.
persend 1;  # the number of packets per a send.

# timer for waiting to complete each phase.
phase1 30 sec;
phase2 15 sec;
}

remote 172.21.0.224
{
exchange_mode main,aggressive;
doi ipsec_doi;
situation identity_only;

my_identifier address 172.21.0.222;
peers_identifier address 172.21.0.224;

nonce_size 16;
lifetime time 86400 sec;# sec,min,hour
initial_contact on;
support_mip6 on;
proposal_check obey;# obey, strict or claim

proposal {
encryption_algorithm 3des;
hash_algorithm md5;
authentication_method pre_shared_key ;
dh_group 1 ;
}
}


remote 172.21.0.225
{
exchange_mode main,aggressive;
doi ipsec_doi;
situation identity_only;

my_identifier address 172.21.0.222;
peers_identifier address 172.21.0.225;

nonce_size 16;
lifetime time 86400 sec;# sec,min,hour
initial_contact on;
support_mip6 on;
proposal_check obey;# obey, strict or claim

proposal {
encryption_algorithm 3des;
hash_algorithm md5;
authentication_method pre_shared_key ;
dh_group 1 ;
}
}

sainfo anonymous
{
pfs_group 1;
lifetime time 28800 sec;
encryption_algorithm 3des ;
authentication_algorithm hmac_md5;
compression_algorithm deflate ;
}

==
/etc/ipsec.conf

flush;
spdflush;
spdadd 192.168.82.0/24 192.168.0.0/24 any -P out ipsec 
esp/tunnel/172.21.0.222-172.21.0.224/require;
spdadd 192.168.0.0/24 192.168.82.0/24 any -P in ipsec 
esp/tunnel/172.21.0.224-172.21.0.222/require;

spdadd 192.168.82.0/24 192.168.1.0/24 any -P out ipsec 
esp/tunnel/172.21.0.222-172.21.0.225/require;
spdadd 192.168.1.0/24 192.168.82.0/24 any -P in ipsec 
esp/tunnel/172.21.0.225-172.21.0.222/require;

==

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Duplicate SAD entries lead to ESP tunnel malfunction

[Oleg Tarasov]

Hello,

VANHULLEBUS Yvan <[EMAIL PROTECTED]> wrote:

> net.key.prefered_oldsa, or net.key.preferred_oldsa (changed since
> 4.X).

> It is 1 by default, and it should be set to 0 to help better
> interoperability with lots of peers.

This seems quite like correct solution. I analyzed behavior of the
interface and saw upcoming ping requests (obviously) AND outgoing ping
echoes, but remote host didn't get them. Obviously incoming packets
were decrypted using one of SAs (the new one) but outgoing packets
were encrypted using old SA which is not present on remote host due to
some problems (like forced reboot, connection problems etc).

Normally in this case remote host must report of unknown spi, but
rather it lacks this function or it just ignores these packets. As it
is a hardware router I am unaware of its behavior.

I will test this solution for some time but I am sure this will help.

Thanx for really great help - all these troubles are on my production
box and every minute of malfunction returns to me with #not good#
words of my boss :/

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Duplicate SAD entries lead to ESP tunnel malfunction

[Oleg Tarasov]

Hello,

Julian Elischer <[EMAIL PROTECTED]> wrote:

> let us know if that solves your problem..

> remember you don't need to reboot to set it..
> the result should be instantaneous.

net.key.preferred_oldsa=0

really helped in this situation. Both tunnels from now on work
perfectly inspite on connection problems or any other problems.

It is not clear no me why this option should ever be set to 1 as it
will certainly bring to a malfunction if any problem occurs.

I suggest to change the default value of this one to 0 in FreeBSD
distribution.


-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Policy routing and multipath routing needed (override routing table)

[Oleg Tarasov]

Hello,

Sorry for messing with things I should not as I am not a FreeBSD
developer but I think this idea can be implemented without titanic
work (I can be wrong due to lack of information about FreeBSD
developement).

Now routing is performed using lookup of destination address in the
routing table. To extend its functionality I suggest adding several
new fields like source address, source interface, source and
destination ports, protocol and priority (like metric in windows).

Priority is for identification of which rules will be tested first in
the case of multiple compliance of the packet to table entries. This
actually is a sorting field to the table marking the order of lookup.

This configuration is reversly compatible with standart FreeBSD
routing and as I think will not lead to old program malfunction. In
this case there must be a default value of "any" to all table fields
that are not supplied to "route" command.

This method will cover both policy routing and multipath routing. It
is simple but very effective. It is obviously better than Linux
multiple tables and IMHO does not lead to major network stack changes.

Please tell me if I am wrong but from a first glance (and the second
one ;) ) it seems to be very complementary to FreeBSD functionality.

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage

[Oleg Polyakov]

--- Gleb Smirnoff <[EMAIL PROTECTED]> wrote:

> On Tue, Feb 14, 2006 at 09:39:00AM +0100, Harti Brandt wrote:
> H> AN>I changed port to 163 cause I am actually using net-snmp snmpd on port
> H> AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps
> interfaces?
> H> AN>Why so?
> H> 
> H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate 
> H> divided by 10^6 (and rounded). This is the default set by ether_ifattach()
> 
> H> if the driver did not set another value. It seems that bge never sets that
> 
> H> value so you end up with the default. This looks like a bug.
> 
> Harti, we are thinking in parallel :)

Parallel, yes ;)
Here is the attached patch written just yesterday, not tested yet.

It takes care of different bge adapters - some of them Fast Ethernets.


---
Oleg

> Andres, pls try the attached patch.
> 
> -- 
> Totus tuus, Glebius.
> GLEBIUS-RIPN GLEB-RIPE
> > Index: if_bge.c
> ===
> RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
> retrieving revision 1.118
> diff -u -r1.118 if_bge.c
> --- if_bge.c  30 Jan 2006 13:45:55 -  1.118
> +++ if_bge.c  14 Feb 2006 08:43:24 -
> @@ -2192,6 +2192,7 @@
>   ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1;
>   IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen);
>   IFQ_SET_READY(&ifp->if_snd);
> + ifp->if_baudrate = IF_Gbps(1);
>   ifp->if_hwassist = BGE_CSUM_FEATURES;
>   ifp->if_capabilities = IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING |
>   IFCAP_VLAN_MTU | IFCAP_VLAN_HWCSUM;
> > ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com --- if_bge.c.orig   Tue Feb 14 00:52:58 2006
+++ if_bge.cTue Feb 14 00:54:42 2006
@@ -2183,6 +2183,12 @@
}
ifp->if_softc = sc;
if_initname(ifp, device_get_name(dev), device_get_unit(dev));
+   if ((pci_get_vendor(dev) == BCOM_VENDORID) &&
+   ((pci_get_device(dev) == BCOM_DEVICEID_BCM5901) ||
+   (pci_get_device(dev) == BCOM_DEVICEID_BCM5901A2))) {
+   ifp->if_baudrate = 1;
+   }
+   else ifp->if_baudrate = 10;
ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
ifp->if_ioctl = bge_ioctl;
ifp->if_start = bge_start;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage

[Oleg Polyakov]

--- Oleg Polyakov <[EMAIL PROTECTED]> wrote:

> --- Gleb Smirnoff <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, Feb 14, 2006 at 09:39:00AM +0100, Harti Brandt wrote:
> > H> AN>I changed port to 163 cause I am actually using net-snmp snmpd on
> port
> > H> AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps
> > interfaces?
> > H> AN>Why so?
> > H> 
> > H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate 
> > H> divided by 10^6 (and rounded). This is the default set by
> ether_ifattach()
> > 
> > H> if the driver did not set another value. It seems that bge never sets
> that
> > 
> > H> value so you end up with the default. This looks like a bug.
> > 
> > Harti, we are thinking in parallel :)
> 
> Parallel, yes ;)
> Here is the attached patch written just yesterday, not tested yet.

It has been tested:
# snmpwalk -v 1 -c pub localhost:161 | grep Speed
IF-MIB::ifSpeed.1 = Gauge32: 10
IF-MIB::ifSpeed.2 = Gauge32: 10
IF-MIB::ifSpeed.3 = Gauge32: 0
IF-MIB::ifSpeed.4 = Gauge32: 0
IF-MIB::ifHighSpeed.1 = Gauge32: 1000
IF-MIB::ifHighSpeed.2 = Gauge32: 1000
IF-MIB::ifHighSpeed.3 = Gauge32: 0
IF-MIB::ifHighSpeed.4 = Gauge32: 0

And adapters are:
# dmesg | grep bge
bge0:  mem
0xd020-0xd020 irq 18 at device 0.0 on pci4
miibus0:  on bge0
bge0: Ethernet address: 00:30:48:82:12:44
bge1:  mem
0xd030-0xd030 irq 19 at device 0.0 on pci5
miibus1:  on bge1
bge1: Ethernet address: 00:30:48:82:12:45
bge0: link state changed to UP

# ifconfig -l
bge0 bge1 plip0 lo0

> It takes care of different bge adapters - some of them Fast Ethernets.
> 
> 
> ---
> Oleg
> 
> > Andres, pls try the attached patch.
> > 
> > -- 
> > Totus tuus, Glebius.
> > GLEBIUS-RIPN GLEB-RIPE
> > > Index: if_bge.c
> > ===
> > RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
> > retrieving revision 1.118
> > diff -u -r1.118 if_bge.c
> > --- if_bge.c30 Jan 2006 13:45:55 -  1.118
> > +++ if_bge.c14 Feb 2006 08:43:24 -
> > @@ -2192,6 +2192,7 @@
> > ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1;
> > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen);
> > IFQ_SET_READY(&ifp->if_snd);
> > +   ifp->if_baudrate = IF_Gbps(1);
> > ifp->if_hwassist = BGE_CSUM_FEATURES;
> > ifp->if_capabilities = IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING |
> > IFCAP_VLAN_MTU | IFCAP_VLAN_HWCSUM;
> > > ___
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com > --- if_bge.c.orig Tue Feb 14 00:52:58 2006
> +++ if_bge.c  Tue Feb 14 00:54:42 2006
> @@ -2183,6 +2183,12 @@
>   }
>   ifp->if_softc = sc;
>   if_initname(ifp, device_get_name(dev), device_get_unit(dev));
> + if ((pci_get_vendor(dev) == BCOM_VENDORID) &&
> + ((pci_get_device(dev) == BCOM_DEVICEID_BCM5901) ||
> + (pci_get_device(dev) == BCOM_DEVICEID_BCM5901A2))) {
> + ifp->if_baudrate = 1;
> + }
> + else ifp->if_baudrate = 10;
>   ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
>   ifp->if_ioctl = bge_ioctl;
>   ifp->if_start = bge_start;
> > ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage

[Oleg Polyakov]

--- Gleb Smirnoff <[EMAIL PROTECTED]> wrote:

>   Oleg, Anders,
> 
>   can you please remove all your changes to if_bge.c and test the
> attached patch. Awaiting for feedback and thanks.

It works fine -
bge0 connected to GIGE switch, bge1 is not connected

# snmpget -c pub -v 1 localhost ifSpeed.1
IF-MIB::ifSpeed.1 = Gauge32: 10
# snmpget -c pub -v 1 localhost ifHighSpeed.1
IF-MIB::ifHighSpeed.1 = Gauge32: 1000

# ifconfig bge1 up
# ifconfig bge1 media auto
# snmpget -c pub -v 1 localhost ifSpeed.2
IF-MIB::ifSpeed.2 = Gauge32: 0
# snmpget -c pub -v 1 localhost ifHighSpeed.2
IF-MIB::ifHighSpeed.2 = Gauge32: 0

# ifconfig bge1 media 10baseT/UTP
# snmpget -c pub -v 1 localhost ifSpeed.2
IF-MIB::ifSpeed.2 = Gauge32: 1000
# snmpget -c pub -v 1 localhost ifHighSpeed.2
IF-MIB::ifHighSpeed.2 = Gauge32: 10

# ifconfig bge1 media 100baseTX
# snmpget -c pub -v 1 localhost ifSpeed.2
IF-MIB::ifSpeed.2 = Gauge32: 1
# snmpget -c pub -v 1 localhost ifHighSpeed.2
IF-MIB::ifHighSpeed.2 = Gauge32: 100

It might be not important, but if adapter is in DOWN state
snmp may show different media:

1. Adapter is Down. ifconfig shows - media: Ethernet autoselect (none)
Snmp shows ifSpeed 0.
2. # ifconfig bge1 media 100baseTX.
ifconfig shows - media: Ethernet 100baseTX (none)
Snmp still shows ifSpeed 0.
3. # ifconfig bge1 up 
ifconfig shows - media: Ethernet 100baseTX (none)
snmp shows ifSpeed 1
4. # ifconfig bge1 down
snmp still shows ifSpeed 1
after running "ifconfig bge1" snmp shows ifSpeed 0

So sometimes ifconfig helps to change baudrate
if adapter in DOWN state.

Thanks,
Oleg

> -- 
> Totus tuus, Glebius.
> GLEBIUS-RIPN GLEB-RIPE


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ifstated fails to monitor netgraph interface

[Oleg Tarasov]

Hello,

I am building a failover system. I have two Internet interfaces - one
simple Ethernet connection fxp1 and a PPPoE connection established
using mpd ng0.

I tried to use ifstated to monitor connections. For Ethernet
connection a ping test is run and for PPPoE I wanted to use built-in
test like ng0.link.up but this one always fails. As I can see ifstated
can't for some reason monitor netgraph interface's status.

It would be almost normal to use a ping test in this case, but if
ethernet interface that has a default route is working, ping test for
PPPoE router will not fail as this router will be reachable via
ethernet interface. So the ping test is not appliable here. Anyway
PPPoE has an excellent LCP mechanism to watch connectivity and it
would be great to use it in this case.

Please suggest me what can I use to solve this problem. Maybe there is
another ifstated-like daemon with maybe more advanced test capability
I can use in my situation as I have not found any acceptable.

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ifstated fails to monitor netgraph interface

[Oleg Tarasov]

Hello,

I have found a solution to see ng0 state but using external test.
Everything would be fine but there are 2 difficulties:
1) for some reason when in state "secondary" only one external test is
run (viewing logfile at debug loglevel)
2) Second (PPPoE) connection can disappear for a short period of time
destroying default route but it won't trigger state change as the
periodic test can miss this.

What can be the source of 1) ? Commenting second "if" statement in
"secondary" state makes first test run. Other way only second is run
after 1 first test execution.

My ifstated.conf
===
init-state auto
loglevel debug


pri_iface_up = '"ping -q -c 1 -t 1 111.111.111.111 > /dev/null" every 5'
sec_iface_up = '"ifconfig ng0 | grep UP > /dev/null" every 2'
#sec_iface_up = '"ping -q -c 1 -t 1 222.222.222.222 > /dev/null" every 10'
#sec_iface_up = "ng0.link.up"

state auto {
if $pri_iface_up
set-state primary
if $sec_iface_up
set-state secondary
}

state primary {
init {
run "route delete default"
run "route add default 111.111.111.111"
run "sleep 20"
}
if ! $pri_iface_up
set-state primary_failing
}

state primary_failing {
init {
run "sleep 10"
}
if $pri_iface_up
set-state primary
if ! $pri_iface_up && $sec_iface_up
set-state secondary
if ! $pri_iface_up && ! $sec_iface_up
set-state secondary
}

state secondary {
init {
run "route delete default"
run "route add default 222.222.222.222"
run "sleep 20"
}
if $pri_iface_up
set-state primary
if ! $sec_iface_up
set-state auto
}
==

Initially primary router is down

ifstated.log
==

ifstated: initial state: auto
ifstated: changing state to auto
ifstated: running ping -q -c 1 -t 1 111.111.111.111 > /dev/null
ifstated: running ifconfig ng0 | grep UP > /dev/null
ifstated: started
ifstated: changing state to secondary
ifstated: running ping -q -c 1 -t 1 111.111.111.111 > /dev/null
ifstated: running ifconfig ng0 | grep UP > /dev/null
ifstated: running route delete default
delete net default
ifstated: running route add default 222.222.222.222
add net default: gateway 222.222.222.222
ifstated: running sleep 20
ifstated: running ifconfig ng0 | grep UP > /dev/null
ifstated: running ifconfig ng0 | grep UP > /dev/null
ifstated: running ifconfig ng0 | grep UP > /dev/null
ifstated: running ifconfig ng0 | grep UP > /dev/null
ifstated: running ifconfig ng0 | grep UP > /dev/null
ifstated: running ifconfig ng0 | grep UP > /dev/null
ifstated: running ifconfig ng0 | grep UP > /dev/null
==

-- 
Best regards,
 Oleg Tarasov  mailto:[EMAIL PROTECTED]

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPMI and bge (again)

[Oleg Bulyzhin]

On Tue, Mar 28, 2006 at 11:24:06AM -0600, Stephen P. Cravey wrote:
> Does anyone have chip documentation on the broadcom BGE chips? I'm having an 
> ongoing issue with IPMI that I'd really like to get resolved. The issue seems 
> to be that during the driver start sequence, a flag is getting set in the 
> chip that's disabling the IPMI passthrough that I need in order for data 
> destined for a second mac address on the interface to recieve packets. Or, a 
> flag that this process needs isn't getting set. Not sure which, but I could 
> really use some help here. 
> 
> Or should I ask the frequent committers to the driver directly?
> 
> Thank you.
> 
> PR:
> kern/79143
> kern/88741
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Could you please test attached patch (RELENG_6 version)? It's slightly modified 
version of Doug Ambrisko
([EMAIL PROTECTED]) patch (original version didnt work for me: bcm5721 @ hp 
proliant dl145g2 server).

-- 
Oleg.



pgpxQrGfVDl8Z.pgp
Description: PGP signature

Re: IPMI and bge (again)

[Oleg Bulyzhin]

On Tue, Mar 28, 2006 at 12:38:42PM -0800, Doug Ambrisko wrote:
> Oleg Bulyzhin writes:
> | On Tue, Mar 28, 2006 at 11:24:06AM -0600, Stephen P. Cravey wrote:
> | > Does anyone have chip documentation on the broadcom BGE chips? I'm 
> having an ongoing issue with IPMI that I'd really like to get resolved. The 
> issue seems to be that during the driver start sequence, a flag is getting 
> set in the chip that's disabling the IPMI passthrough that I need in order 
> for data destined for a second mac address on the interface to recieve 
> packets. Or, a flag that this process needs isn't getting set. Not sure 
> which, but I could really use some help here. 
> | > 
> | > Or should I ask the frequent committers to the driver directly?
> | > 
> | > Thank you.
> | > 
> | > PR:
> | > kern/79143
> | > kern/88741
> | > ___
> | 
> | Could you please test attached patch (RELENG_6 version)? It's slightly 
> | modified version of Doug Ambrisko
> | ([EMAIL PROTECTED]) patch (original version didnt work for me:
> | bcm5721 @ hp proliant dl145g2 server).
> 
> I don't see it attached.  I'd like to see your changes and I'd like know
> of your plans about getting it in.
> 
> Thanks,
> 
> Doug A.

Oops... my fault. Should be attached now.

-- 
Oleg.

Index: if_bgereg.h
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v
retrieving revision 1.36.2.4
diff -u -r1.36.2.4 if_bgereg.h
--- if_bgereg.h 5 Feb 2006 18:07:15 -   1.36.2.4
+++ if_bgereg.h 28 Mar 2006 20:18:15 -
@@ -74,6 +74,11 @@
 #define BGE_SOFTWARE_GENCOMM   0x0B50
 #define BGE_SOFTWARE_GENCOMM_SIG   0x0B54
 #define BGE_SOFTWARE_GENCOMM_NICCFG0x0B58
+#define BGE_SOFTWARE_GENCOMM_FW0x0B78
+#defineBGE_FW_DRV_ALIVE0x0001
+#defineBGE_FW_PAUSE0x0002
+#define BGE_SOFTWARE_GENNCOMM_FW_LEN   0x0B7C
+#define BGE_SOFTWARE_GENNCOMM_FW_DATA  0x0B80
 #define BGE_SOFTWARE_GENCOMM_END   0x0FFF
 #define BGE_UNMAPPED   0x1000
 #define BGE_UNMAPPED_END   0x1FFF
@@ -1627,6 +1632,7 @@
 #define BGE_MODE_CTL   0x6800
 #define BGE_MISC_CFG   0x6804
 #define BGE_MISC_LOCAL_CTL 0x6808
+#define BGE_CPU_EVENT  0x6810
 #define BGE_EE_ADDR0x6838
 #define BGE_EE_DATA0x683C
 #define BGE_EE_CTL 0x6840
@@ -2009,6 +2015,7 @@
 #define BGE_HWCFG_VOLTAGE  0x0003
 #define BGE_HWCFG_PHYLED_MODE  0x000C
 #define BGE_HWCFG_MEDIA0x0030
+#define BGE_HWCFG_ASF  0x0080
 
 #define BGE_VOLTAGE_1POINT30x
 #define BGE_VOLTAGE_1POINT80x0001
@@ -2385,6 +2392,10 @@
int val;
 };
 
+#define ASF_ENABLE 1
+#define ASF_NEW_HANDSHAKE  2
+#define ASF_STACKUP4
+
 struct bge_softc {
struct ifnet*bge_ifp;   /* interface info */
device_tbge_dev;
@@ -2403,6 +2414,8 @@
u_int8_tbge_asicrev;
u_int8_tbge_chiprev;
u_int8_tbge_no_3_led;
+   u_int8_tbge_asf_mode;
+   u_int8_tbge_asf_count;
u_int8_tbge_pcie;
struct bge_ring_databge_ldata;  /* rings */
struct bge_chain_data   bge_cdata;  /* mbufs */
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.91.2.13
diff -u -r1.91.2.13 if_bge.c
--- if_bge.c4 Mar 2006 09:34:48 -   1.91.2.13
+++ if_bge.c28 Mar 2006 20:18:21 -
@@ -209,6 +209,7 @@
 static void bge_txeof  (struct bge_softc *);
 static void bge_rxeof  (struct bge_softc *);
 
+static void bge_asf_driver_up  (struct bge_softc *);
 static void bge_tick_locked(struct bge_softc *);
 static void bge_tick   (void *);
 static void bge_stats_update   (struct bge_softc *);
@@ -271,7 +272,12 @@
int count);
 #endif
 
-static void bge_reset  (struct bge_softc *);
+#define BGE_RESET_START 1
+#define BGE_RESET_STOP  2
+static void bge_sig_post_reset(struct bge_softc *, int);
+static void bge_sig_legacy(struct bge_softc *, int);
+static void bge_sig_pre_reset(struct bge_softc *, int);
+static int bge_reset   (struct bge_softc *);
 static void bge_link_upd   (struct bge_softc *);
 
 static device_method_t bge_methods[] = {
@@ -609,6 +615,18 @@
DELAY(40);
}
 
+if (sc->bge_asf_mode & ASF_ST

Re: IPMI and bge (again)

[Oleg Bulyzhin]

On Tue, Mar 28, 2006 at 02:51:48PM -0600, Stephen P. Cravey wrote:
> I don't see the patch either. Does it require pxe booting like Dougs? I 
> actually have pulled a system out of service specifically to use for testing 
> BGE patches, so it's fairly easy for me to test new versions. I eagerly await 
> a copy of your patch.
> 
> Thank you.
> 
> -Stephen

PXE boot is not required (Doug's version he gave me didnt require it either).
Actually, it's almost identical to original version - only thing has changed:
asf enable code was move past bge_reset call.

> 
> On Wed, 29 Mar 2006 00:25:25 +0400
> Oleg Bulyzhin <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, Mar 28, 2006 at 11:24:06AM -0600, Stephen P. Cravey wrote:
> > > Does anyone have chip documentation on the broadcom BGE chips? I'm having 
> > > an ongoing issue with IPMI that I'd really like to get resolved. The 
> > > issue seems to be that during the driver start sequence, a flag is 
> > > getting set in the chip that's disabling the IPMI passthrough that I need 
> > > in order for data destined for a second mac address on the interface to 
> > > recieve packets. Or, a flag that this process needs isn't getting set. 
> > > Not sure which, but I could really use some help here. 
> > > 
> > > Or should I ask the frequent committers to the driver directly?
> > > 
> > > Thank you.
> > > 
> > > PR:
> > > kern/79143
> > > kern/88741
> > > ___
> > > freebsd-net@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> > 
> > Could you please test attached patch (RELENG_6 version)? It's slightly 
> > modified version of Doug Ambrisko
> > ([EMAIL PROTECTED]) patch (original version didnt work for me: bcm5721 @ hp 
> > proliant dl145g2 server).
> > 
> > -- 
> > Oleg.
> > 
> > 

-- 
Oleg.



pgp8ZTpGscOqM.pgp
Description: PGP signature

Re: IPMI and bge (again)

[Oleg Bulyzhin]

On Tue, Mar 28, 2006 at 12:38:42PM -0800, Doug Ambrisko wrote:

> I don't see it attached.  I'd like to see your changes and I'd like know
> of your plans about getting it in.
> 
> Thanks,
> 
> Doug A.

I didnt test it under load yet (server i've used moved to production so
i have limited testing capabilites atm).
Issue to be fixed: we should not touch phy in bge_stop having asf enabled.
I think your patch is worth commiting to HEAD asap but shouldnt be MFCed
prior 6.1R. What do you think?

-- 
Oleg.



pgp2HsNiCg1sk.pgp
Description: PGP signature

Re: Watchdog timeouts and dead network on bge - 6.1-RC1

[Oleg Bulyzhin]

On Sun, Apr 23, 2006 at 02:35:24PM +0200, Lars Erik Gullerud wrote:
> We recently upgraded one of our 4.11 servers to 6.1-RC1. The server is a 
> Dell PE2650, dual Xeons, and has two onboard Broadcom BCM5701 cards, using 
> the bge driver.
> 
> Some older threads on -net and -current led me to believe that most issues 
> with bge driver in FreeBSD >4 had been sorted. However, after our upgrade, 
> we are seing errors like this:
> 
> Apr 22 18:44:01 nebula kernel: bge0: watchdog timeout -- resetting
> Apr 22 18:44:01 nebula kernel: bge0: link state changed to DOWN
> Apr 22 18:44:03 nebula kernel: bge0: link state changed to UP
> 
> ...and more importantly - when this happens, the network connection does 
> NOT in fact come back up. Logging into the box locally (or via a different 
> network interface) and manually issuing "ifconfig bge0 down ; ifconfig 
> bge0 up" DOES get the interface going again, however.
> 
> We have only seen this on very high network loads - the particular message 
> included above occured while transferring some 120GB of data from a 4.11 
> NFS-server to this 6.1-RC1 box.
> 
> Is this a known issue in bge? If so, is anyone working on it? Can we 
> provide some useful information to whoever this might be?
> 
> We have never had any issues with bge in 4.x, but we really need to get 
> this server up to 5.x/6.x at this point in time, any other suggestions on 
> knobs or workarounds that can give us bge stability?
> 
> Thanks in advance,
> 
> /leg
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Could you try attached patch? It should fix problem when link goes UP but
network is still down.

About bge resets: you should try if_bge.c rev.1.126, it may help.

P.S. anyway, please report how is it going.

-- 
Oleg.

Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.91.2.13
diff -u -r1.91.2.13 if_bge.c
--- if_bge.c4 Mar 2006 09:34:48 -   1.91.2.13
+++ if_bge.c17 Apr 2006 19:39:15 -
@@ -3308,6 +3308,14 @@

bge_ifmedia_upd(ifp);
 
+   sc->bge_link_evt++;
+#ifdef DEVICE_POLLING
+   if (!(sc->bge_ifp->if_capenable & IFCAP_POLLING))
+#endif
+   {
+   BGE_SETBIT(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_SET);
+   }
+
ifp->if_drv_flags |= IFF_DRV_RUNNING;
ifp->if_drv_flags &= ~IFF_DRV_OACTIVE;
 


pgp9UyNxmYA3a.pgp
Description: PGP signature

Re: Watchdog timeouts and dead network on bge - 6.1-RC1

[Oleg Bulyzhin]

On Tue, Apr 25, 2006 at 11:59:39AM +0200, Lars Erik Gullerud wrote:
> On Mon, 24 Apr 2006, Oleg Bulyzhin wrote:
> 
> >Could you try attached patch? It should fix problem when link goes UP but
> >network is still down.
> >
> >About bge resets: you should try if_bge.c rev.1.126, it may help.
> >
> >P.S. anyway, please report how is it going.
> 
> I'll try your patch, however as we can't reproduce this on demand (only 
> happens sometimes under heavy load) it might be a while before I can give 
> you any feedback.
> 
> Regarding trying rev.1.126 from HEAD - I looked at the source and I see 
> some other modifications in 1.126 compared to the version in RELENG_6, 
> specifically, there are a lot of replacements of IFP2ENADDR with IF_LLADR, 
> that seems to have been commited in version 1.99 by ru, and some changes 
> regarding VLAN_INPUT_TAG_NEW vs. VLAN_INPUT_TAG.
> 
> Since these changes have not been MFC'ed to RELENG_6, I gather there is a 
> reason for that - so can 1.126 be used directly on 6.1, or do I need to 
> hand-edit the other changes in 1.126 into the stock RELENG_6 if_bge.c to 
> test this version?
> 
> /leg

Sorry i was not clear enough. Talking about rev 1.126 i meant applying
diff between rev.1.125 and rev.1.126
(i've created one  - it's attached to this mail).

-- 
Oleg.
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.125
retrieving revision 1.126
diff -u -r1.125 -r1.126
--- if_bge.c17 Mar 2006 09:17:36 -  1.125
+++ if_bge.c15 Apr 2006 08:13:06 -  1.126
@@ -2788,27 +2788,23 @@
}
 #endif
 
-   bus_dmamap_sync(sc->bge_cdata.bge_status_tag,
-   sc->bge_cdata.bge_status_map, BUS_DMASYNC_POSTREAD);
+   /*
+* Do the mandatory PCI flush as well as get the link status.
+*/
+   statusword = CSR_READ_4(sc, BGE_MAC_STS) & BGE_MACSTAT_LINK_CHANGED;
 
-   statusword =
-   atomic_readandclear_32(&sc->bge_ldata.bge_status_block->bge_status);
+   /* Ack interrupt and stop others from occuring. */
+   CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1);
 
+   /* Make sure the descriptor ring indexes are coherent. */
+   bus_dmamap_sync(sc->bge_cdata.bge_status_tag,
+   sc->bge_cdata.bge_status_map, BUS_DMASYNC_POSTREAD);
bus_dmamap_sync(sc->bge_cdata.bge_status_tag,
sc->bge_cdata.bge_status_map, BUS_DMASYNC_PREREAD);
 
-#ifdef notdef
-   /* Avoid this for now -- checking this register is expensive. */
-   /* Make sure this is really our interrupt. */
-   if (!(CSR_READ_4(sc, BGE_MISC_LOCAL_CTL) & BGE_MLC_INTR_STATE))
-   return;
-#endif
-   /* Ack interrupt and stop others from occuring. */
-   CSR_WRITE_4(sc, BGE_MBX_IRQ0_LO, 1);
-
if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 &&
sc->bge_chipid != BGE_CHIPID_BCM5700_B1) ||
-   statusword & BGE_STATFLAG_LINKSTATE_CHANGED || sc->bge_link_evt)
+   statusword || sc->bge_link_evt)
bge_link_upd(sc);
 
if (ifp->if_drv_flags & IFF_DRV_RUNNING) {


pgp5BYi0U3Als.pgp
Description: PGP signature

Re: IPMI and bge (again)

[Oleg Bulyzhin]

On Wed, May 03, 2006 at 08:54:09PM -0700, Doug Ambrisko wrote:
> Robert Wojciechowski writes:
> | > Could you try this latest version.  It incorporates Oleg
> | > change sort-of.  It was a good hint.  The issue is that
> | > we can't move the detection after the "reset" dance.  Since
> | > it needs to know if ASF is active.  What we can do is just
> | > do the bge_reset, look for ASF and then do the dance.  This
> | > works really well and I makes the PHY probe work without the
> | > one remaining hack that I had left and I was able to get rid
> | > of a couple more hacks.
> | > 
> | > This applies to RELENG_6.
> | > 
> | > Please let me know how this works.  I'd like to commit
> | > this.  Please pay attention to if IPMI works before the
> | > NIC is UP/or has an IP and then when it is ifconfig down
> | > then up again.  The PHY should be detected at brgphy
> | > and not the generic one.  It should also have all of the
> | > proper speeds.  It should work with and without PXE boot.
> | > Finally non-IPMI ones should work.
> | > 
> | > So far it works on the variants I have.
> | 
> | Doug,
> | 
> | I tried your patch (as well as one from you on 1/13/2006) on FreeBSD
> | 6.1-RC2 but experienced hard lockups. It happens during startup right
> | after setting the hostname, right before it would normally bring up the
> | interface I believe.
> 
> Could you try:
>   http://www.ambrisko.com/doug/bge_ipmi_2.patch
>  
> | This is on four different servers, all Supermicro motherboards (H8DAR
> | and H8DAE) based on the Broadcom BCM5704 chip.
> | 
> | Here is the pciconf -lv:
> | 
> | [EMAIL PROTECTED]:3:0:  class=0x02 card=0x164815d9 chip=0x164814e4 
> rev=0x10
> | hdr=0x00
> | vendor   = 'Broadcom Corporation'
> | device   = 'BCM5704 NetXtreme Dual Gigabit Adapter'
> | class= network
> | subclass = ethernet
> | [EMAIL PROTECTED]:3:1:  class=0x02 card=0x164815d9 chip=0x164814e4 
> rev=0x10
> | hdr=0x00
> | vendor   = 'Broadcom Corporation'
> | device   = 'BCM5704 NetXtreme Dual Gigabit Adapter'
> | class= network
> | subclass = Ethernet
> | 
> | Any ideas? If you need any more information or have other patches I can
> | test for you, let me know!
> 
> Try this version.  If this has trouble we can try to add some debug
> stuff to it.
> 
> Thanks,
> 
> Doug A.

I've tested your new patch on hp proliant dl145g2 server with bcm5721 on board
chips:
bge1:  mem 
0xca10-0xca10 irq 19 at device 0.0 on pci3

It does work but i've found some problems:

minor ones:
1) IPMI stop working for a few seconds while ifconfig bge1 up/down or driver
initialization (perhaps this happens when bge_reset() is called) 

2) IPMI interface (bound to brgphy1) is unreachable from bge1 itself. I guess
it's due to simplex nature of bge. I'm not sure this can be fixed.

major one:
Driver is unable to detect link loss. Problematic code is in bge_tick_locked:

/* Don't mess with the PHY in IPMI/ASF mode */
if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link)))
mii_tick(mii);

what purpose of this check? mii_tick() call is necessary for updating phy's
link status.

-- 
Oleg.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bge(4) one packet wedge

[Oleg Bulyzhin]

On Wed, Aug 23, 2006 at 08:16:49PM +0400, Gleb Smirnoff wrote:
>   Colleagues,
> 
>   I've faced a problem in bge(4) when a single packet is in the RX
> ring, but it isn't noticed by the driver. A reception of a packet
> triggers interrupt and both packets are processed - an old one
> and the new one.
> 
>   To reproduce the problem you need to run netperf (from ports
> collection): netserver on another host (10.0.0.1) and netperf on
> the host, where tested bge(4) is installed - 10.0.0.2. No traffic
> except netperf's should flow through this NIC, or the problem won't
> be reproduced!
> 
>   So, I run netperf client and simultaneously tcpdump on the
> another host. After few seconds there is a wedge. The last packet
> seen on 10.0.0.1 is the packet sent by 10.0.0.1 to 10.0.0.2. However
> it isn't seen on 10.0.0.2.
> 
> Ok, let's look at the receive ring:
> 
> (kgdb) p $sc->bge_rx_saved_considx
> $14 = 51
> (kgdb) p $sc->bge_ldata.bge_status_block->bge_idx[0].bge_rx_prod_idx
> $15 = 51
> 
> Looks like there is nothing to process.
> 
> However, if I run 'ping -c 1 10.0.0.2' I will get an interrupt and read
> two packets: first the old packet, and then recently sent ping.
> 
> -- 
> Totus tuus, Glebius.
> GLEBIUS-RIPN GLEB-RIPE

What happens if you trigger other interrupt (like unplug/plug cable)?
Will you get that packet?

-- 
Oleg.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bge(4) one packet wedge

[Oleg Bulyzhin]

On Wed, Aug 23, 2006 at 10:26:48PM +0400, Oleg Bulyzhin wrote:
> On Wed, Aug 23, 2006 at 08:16:49PM +0400, Gleb Smirnoff wrote:
> >   Colleagues,
> > 
> >   I've faced a problem in bge(4) when a single packet is in the RX
> > ring, but it isn't noticed by the driver. A reception of a packet
> > triggers interrupt and both packets are processed - an old one
> > and the new one.
> > 
> >   To reproduce the problem you need to run netperf (from ports
> > collection): netserver on another host (10.0.0.1) and netperf on
> > the host, where tested bge(4) is installed - 10.0.0.2. No traffic
> > except netperf's should flow through this NIC, or the problem won't
> > be reproduced!
> > 
> >   So, I run netperf client and simultaneously tcpdump on the
> > another host. After few seconds there is a wedge. The last packet
> > seen on 10.0.0.1 is the packet sent by 10.0.0.1 to 10.0.0.2. However
> > it isn't seen on 10.0.0.2.
> > 
> > Ok, let's look at the receive ring:
> > 
> > (kgdb) p $sc->bge_rx_saved_considx
> > $14 = 51
> > (kgdb) p $sc->bge_ldata.bge_status_block->bge_idx[0].bge_rx_prod_idx
> > $15 = 51
> > 
> > Looks like there is nothing to process.
> > 
> > However, if I run 'ping -c 1 10.0.0.2' I will get an interrupt and read
> > two packets: first the old packet, and then recently sent ping.
> > 
> > -- 
> > Totus tuus, Glebius.
> > GLEBIUS-RIPN GLEB-RIPE
> 
> What happens if you trigger other interrupt (like unplug/plug cable)?
> Will you get that packet?
> 
> -- 
> Oleg.
> 
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Does polling(4) solve the issue?

-- 
Oleg.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"