Re: netgraph ability
[ Redirected to -net ] On Thu, Apr 22, 2004 at 05:50:57PM -0700, David Yeske wrote: I'm in a situation where I need to emulate multiple ethernet devices with different mac addresses. I have gotten far enough to have this. I ran ngctl and then ran mkpeer . eiface hook ether I then ran ifconfig ngeth0 link '00:bd:03:11:21:11' ifconfig ngeth0 192.168.20.5 ifconfig sis0 192.168.23.45 So basically I want to be able to ping / connect to 192.168.20.5 from another box on the 192.168.23.0/24 network, and have it see the mac address that I have set rather than the mac address of my sis0 device. I know I can do this with vmware, but I am trying to avoid that. Anyone know if this is possible? Is there a way to do this with the tap device and or arpd? Using Netgraph, you can emulate any number of Ethernet interfaces on one physical interface. Here's my recipe for you: 1. Load the ng_ether(4) module. 2. Create the required number of ng_eiface(4) nodes. 3. Connect lower and upper of sis0: and all ngethX: ng_ether(4) nodes to one ng_bridge(4). 4. Make sure to ngctl msg if: setautosrc 0 to all ng_ether(4) nodes. 5. Optionally set net.link.ether.inet.log_arp_wrong_iface=0. Here's my test (I've omitted obvious configuration steps): # ifconfig dc0 ether dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=48VLAN_MTU,POLLING ether 00:10:a4:c0:c0:45 # ifconfig ngeth0 ngeth0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether 00:00:00:01:02:03 # ngctl show bridge: Name: bridge Type: bridge ID: 000b Num hooks: 4 Local hook Peer name Peer typePeer ID Peer hook -- - ---- - link4 ngeth0 ether0007lower link3 ngeth0 ether0007upper link2 dc0 ether0002lower link1 dc0 ether0002upper # ifconfig ngeth0 1.2.3.4 # tcpdump -lenx -i dc0 ether host 0:0:0:1:2:3 tcpdump: listening on dc0 20:29:05.571179 0:0:0:1:2:3 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 1.2.3.4 tell 1.2.3.4 0001 0800 0604 0001 0001 0203 0102 0304 0102 0304 Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
RE: how to flush out cache.?
Julian Elischer wrote: Other than reading a few GB of data, is there a way to flush out the cache copy of a file I've written? I don't know how this will fit into your application, but unmounting and remounting the filesystem is a way that springs to mind. Perhaps not as isloated as you'd like, but still ... Regards, Jan Mikkelsen [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad news for bsdtar..
* Alexey Dokuchaev [EMAIL PROTECTED] [040424 03:14] wrote: On Sat, Apr 24, 2004 at 01:59:13AM -0700, Alfred Perlstein wrote: Have you guys thought of using aio or at least another process to parallelize IO? (One to read files, and one to write out the archive) Actually with our kernel threads in 5 you could just use those to speed IO. IMHO, still non-blocking/async IO would be faster, and more probably portable, unless I'm utterly wrong, of course. 8-) Threads are pretty portable these days, obviously making it a compile time option could work, but then again performance would be nice and it is _our_ tar. ;) Also, unless you mean 'aio' or 'another process' by non-blocking/async IO then I'm pretty sure you are wrong, as there is no other way to do this, disk based files do not really support SIGIO (async IO) or non-blocking IO (NBIO). -- - Alfred Perlstein - Research Engineering Development Inc. - email: [EMAIL PROTECTED] cell: 408-480-4684 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bad news for bsdtar..
Alfred Perlstein wrote: Threads are pretty portable these days, obviously making it a compile time option could work, but then again performance would be nice and it is _our_ tar. ;) Also, unless you mean 'aio' or 'another process' by non-blocking/async IO then I'm pretty sure you are wrong, as there is no other way to do this, disk based files do not really support SIGIO (async IO) or non-blocking IO (NBIO). I think it is much more important that libarchive be clean, reliabable, and maintainable than squeeze out the last bit of performance. That better serves the goal of libarchive being embedded in everything (tar, pax, cpio, pkg_*, etc). Tim has done a great job with this so far. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FAST_IPSEC bug fix
Hi list,
this is a month-old mail about the lack of a FAST_IPSEC feature compared
to legacy IPSEC. Including a working patch. I haven't seen this being
committed, or is it? Please also MFC to STABLE.
Regards,
Helge
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Mike Tancsa
Sent: Tuesday, 30. March 2004 19:14
To: [EMAIL PROTECTED]
Subject: FAST_IPSEC bug fix
Well, its not totally a bug, but missing functionality that
looks like is
there but is not and is pretty important to keep lossy links
functioning
with IPSEC. My colleague [EMAIL PROTECTED] created the patch
below that
implements net.key.prefered_oldsa when using FAST_IPSEC. The
discussion
has come up before about this, but no action. I know
[EMAIL PROTECTED] is
really busy and cannot help. Is there anyone out there who
could review and
commit the patch below ? It works against RELENG_4
I have bcc'd the last 2 committers to touch the code in the
hopes that they
might have the time and inclination to review / commit ?
*** /usr/src/sys/netipsec/key.c Mon Mar 29 20:11:44 2004
--- ./key.c Tue Mar 30 12:00:31 2004
***
*** 133,138
--- 133,139
#endif
static LIST_HEAD(_spacqtree, secspacq) spacqtree; /*
SP acquiring
list */
+ #if 0
/* search order for SAs */
static u_int saorder_state_valid[] = {
SADB_SASTATE_DYING, SADB_SASTATE_MATURE,
***
*** 141,146
--- 142,154
* for outbound processing. For inbound, This is
not important.
*/
};
+ #endif
+ static const u_int saorder_state_valid_prefer_old[] = {
+ SADB_SASTATE_DYING, SADB_SASTATE_MATURE,
+ };
+ static const u_int saorder_state_valid_prefer_new[] = {
+ SADB_SASTATE_MATURE, SADB_SASTATE_DYING,
+ };
static u_int saorder_state_alive[] = {
/* except DEAD */
SADB_SASTATE_MATURE, SADB_SASTATE_DYING, SADB_SASTATE_LARVAL
***
*** 816,821
--- 824,831
struct secashead *sah;
struct secasvar *sav;
u_int stateidx, state;
+ const u_int *saorder_state_valid;
+ int arraysize;
LIST_FOREACH(sah, sahtree, chain) {
if (sah-state == SADB_SASTATE_DEAD)
***
*** 828,836
found:
/* search valid state */
for (stateidx = 0;
!stateidx _ARRAYLEN(saorder_state_valid);
stateidx++) {
state = saorder_state_valid[stateidx];
--- 838,853
found:
+ if (key_prefered_oldsa) {
+ saorder_state_valid = saorder_state_valid_prefer_old;
+ arraysize = _ARRAYLEN(saorder_state_valid_prefer_old);
+ } else {
+ saorder_state_valid = saorder_state_valid_prefer_new;
+ arraysize = _ARRAYLEN(saorder_state_valid_prefer_new);
+ }
/* search valid state */
for (stateidx = 0;
!stateidx arraysize;
stateidx++) {
state = saorder_state_valid[stateidx];
***
*** 997,1008
--- 1014,1034
struct secasvar *sav;
u_int stateidx, state;
int s;
+ const u_int *saorder_state_valid;
+ int arraysize;
KASSERT(dst != NULL, (key_allocsa: null dst address));
KEYDEBUG(KEYDEBUG_IPSEC_STAMP,
printf(DP key_allocsa from %s:%u\n, where, tag));
+ if (key_prefered_oldsa) {
+ saorder_state_valid = saorder_state_valid_prefer_old;
+ arraysize = _ARRAYLEN(saorder_state_valid_prefer_old);
+ } else {
+ saorder_state_valid = saorder_state_valid_prefer_new;
+ arraysize = _ARRAYLEN(saorder_state_valid_prefer_new);
+ }
/*
* searching SAD.
* XXX: to be checked internal IP header somewhere.
Also when
***
*** 1013,1019
LIST_FOREACH(sah, sahtree, chain) {
/* search valid state */
for (stateidx = 0;
!stateidx _ARRAYLEN(saorder_state_valid);
stateidx++) {
state = saorder_state_valid[stateidx];
LIST_FOREACH(sav,
sah-savtree[state], chain) {
--- 1039,1045
LIST_FOREACH(sah, sahtree, chain) {
/* search valid state */
for (stateidx = 0;
!stateidx arraysize;
stateidx++) {
state = saorder_state_valid[stateidx];
LIST_FOREACH(sav,
sah-savtree[state], chain) {
Mike Tancsa,tel
+1 519 651 3400
Sentex Communications, [EMAIL PROTECTED]
device pooling and high interrupts
Hello, I am runnign freebsd 5.2.1 on 386 arch with two rl lan cards. My mainboard is on VIA KT 266A with AMD athlon 1.1. I read man polling and i have HZ=1000. My problem is that when i set up sysctl variable kern.polling.enable=1 my interrupts greatly increase. When my system is idle and indicate 0-1% interrupts with out polling. and when i turn on polling interrupts goes up to about 20% on idle system. Is it normal ? I never before use polling and i dont know that i have something bad in my system ? Can somebody explain me this ? thx -- Best Regards: GiZmen UNIX is user-friendly; it's just picky about its friends UNIX is simple; it just takes a genius to understand its simplicity ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device pooling and high interrupts
On Sat, 24 Apr 2004, GiZmen wrote: G I am runnign freebsd 5.2.1 on 386 arch with two rl lan cards. My mainboard G is on VIA KT 266A with AMD athlon 1.1. G I read man polling and i have HZ=1000. My problem is that when i set up G sysctl variable kern.polling.enable=1 my interrupts greatly increase. G When my system is idle and indicate 0-1% interrupts with out polling. G and when i turn on polling interrupts goes up to about 20% on idle system. G Is it normal ? I never before use polling and i dont know that i have G something bad in my system ? G G Can somebody explain me this ? It seems pretty normal under such low load. polling is worth turning on when you have interrupt load spikes more than, say, 40-50% (e.g. highly saturated 100Mbps router with more than two interfaces and/or VLANs) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device pooling and high interrupts
On Sat, 24 Apr 2004, GiZmen wrote: Hello, I am runnign freebsd 5.2.1 on 386 arch with two rl lan cards. My mainboard is on VIA KT 266A with AMD athlon 1.1. I read man polling and i have HZ=1000. My problem is that when i set up sysctl variable kern.polling.enable=1 my interrupts greatly increase. When my system is idle and indicate 0-1% interrupts with out polling. and when i turn on polling interrupts goes up to about 20% on idle system. Is it normal ? I never before use polling and i dont know that i have something bad in my system ? Can somebody explain me this ? thx -- Best Regards: GiZmen Ruslan can probably jump in and give you a better explanation than I can, but I'll try to provide a quick answer. In short, the rl cards + driver are not well suited to polling and will not work well with it enabled. Support for polling on rl may in fact be removed as a result of this. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD's malloc problem ?
* Anton Alin-Adrian [EMAIL PROTECTED] [2004-04-24 21:27 +0300]: tmp = (char *) malloc(strlen(s)); // line 68 Hmm, you need strlen(s)+1 bytes to store the string -- don't forget the trailing null byte. Nicolas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD's malloc problem ?
Nicolas Rachinsky wrote: * Anton Alin-Adrian [EMAIL PROTECTED] [2004-04-24 21:27 +0300]: tmp = (char *) malloc(strlen(s)); // line 68 Hmm, you need strlen(s)+1 bytes to store the string -- don't forget the trailing null byte. Nicolas And let there be light... DANG.. well it almost blinded me. I was confusing with char[16], which has the +1 byte for the null terminating, but the malloc(16) hasn't... Probably doesn't crash on Linux because the malloced space is not adjacent. Thanks for the candle. Appologises to everyone. -- Alin-Adrian Anton Reversed Hell Networks GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD's malloc problem ?
And let there be light... DANG.. well it almost blinded me. I was confusing with char[16], which has the +1 byte for the null terminating, but the malloc(16) hasn't... No, that's still not quite it... char[16] allocates exactly 16 characters. Period. There's no extra space on the end for the terminating nul. If you try to put a sixteen character string into this array, the terminating nul will slop over onto whatever follows this array in memory. malloc(16) is essentially the same. The difference is that there might not be something right there to be clobbered. malloc tends to round up the number of bytes to something convenient. It's easier to manage a pool of things that are all the same size than a zillion different sizes. 16 is pretty small -- the linux malloc might round everything smaller than 20 bytes or 24 bytes (why 20 or 24? That's another story...) to 20 or 24 bytes bytes just to make its life easier. Therefore it's giving you four extra bytes and the nul can clobber them without causing you to notice the bug. -Dan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD's malloc problem ?
Daniel Ellard wrote: And let there be light... DANG.. well it almost blinded me. I was confusing with char[16], which has the +1 byte for the null terminating, but the malloc(16) hasn't... No, that's still not quite it... char[16] allocates exactly 16 characters. Period. There's no extra space on the end for the terminating nul. If you try to put a sixteen character string into this array, the terminating nul will slop over onto whatever follows this array in memory. malloc(16) is essentially the same. The difference is that there might not be something right there to be clobbered. malloc tends to round up the number of bytes to something convenient. It's easier to manage a pool of things that are all the same size than a zillion different sizes. 16 is pretty small -- the linux malloc might round everything smaller than 20 bytes or 24 bytes (why 20 or 24? That's another story...) to 20 or 24 bytes bytes just to make its life easier. Therefore it's giving you four extra bytes and the nul can clobber them without causing you to notice the bug. -Dan Yes. Thanks ;). -- Alin-Adrian Anton Reversed Hell Networks GPG keyID 0x1E2FFF2E (2963 0C11 1AF1 96F6 0030 6EE9 D323 639D 1E2F FF2E) gpg --keyserver pgp.mit.edu --recv-keys 1E2FFF2E ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FAST_IPSEC bug fix
From: Sam Leffler [mailto:[EMAIL PROTECTED] On Apr 24, 2004, at 11:24 AM, Mike Tancsa wrote: At 12:56 PM 24/04/2004, Sam Leffler wrote: On Apr 24, 2004, at 9:03 AM, Oldach, Helge wrote: Hi list, this is a month-old mail about the lack of a FAST_IPSEC feature compared to legacy IPSEC. Including a working patch. I haven't seen this being committed, or is it? Please also MFC to STABLE. The fix was not quite right for -current (where it needs to go in first). I sent out the attached patch for testing but received no feedback. Until I can get it tested and committed to -current it won't be MFC'd. We dont run -current here, so I dont have anything to test it on. Also, due to the bugs in the driver with HiFn 7955, we have had to abandon FAST_IPSEC :( Running FAST IPSEC w/o h/w crypto is still faster than KAME IPsec. See the results in my BSDCon paper. Yes, but still the net.key.preferred_oldsa issue hits, which is what this thread is about. FAST_IPSEC is great, but unfortuantely useless for me without this... Sorry for beating this topic again. Unfortunately, like Mike, I don't have a -current system around. Maybe someone with a -current box can test? Helge ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
