From gperez at entel.upc.edu Fri May 1 03:44:31 2009 From: gperez at entel.upc.edu (=?ISO-8859-1?Q?Gustau_P=E9rez?=) Date: Fri May 1 03:44:48 2009 Subject: Signal sensitivity problem with if_rum Message-ID: <49FA2E3F.9050108@entel.upc.edu> Hi, I think this is right place to post, if it is not, please let me know. I'm experiencing problems with two different devices using if_rum. One is a Hercules Guillemot and the other is a Linksys Cisco WUSB54GC The first one is about sensitivity, which is very low: for example, I'm detecting just two or three networks around me (with windows both usb devices detect around 14 or 15 networks) and the reported signal is very low.Placing the sensor very near to my wireless network AP (which is a FreeBSD machine with atheros card placing the txpower to 20) reports a signal quality of 50% or 60%. Linux presents the same problem (my wife's laptop with ubuntu shows the same figures, more or The other one is that having such a low sensitivity makes those dongles unusable when making large transfers, mostly when using scp/sftp or sshfs (samba seems to make it work better for longer transfer, but finally the problem appears). At some given point, the dongles seem to lose contact with the AP (making ifconfig shows that wlan0 is still associated), waiting for a period of time (usually one or two minutes) the transfer continues. Probably both problems are related. In order to debug the problem I tried looking dmesg in both my AP and my laptop (no trace). Tried looking at the ssh logs (when making large transfers, no clue). In the only place I found something was in the samba logs, only saying that there was a problem with the transfer (broken pipe, the socket is closed). So : In the linux world, I found that the register which controls the sensitivity is bbp17 : http://209.85.229.132/search?q=cache:H8W6R5Ds3mYJ:forum.aircrack-ng.org/index.php%3Ftopic%3D2235.0+bbp17+ralink+linux&cd=1&hl=ca&ct=clnk&gl=es&client=firefox-a Tried looking in /usr/src/sys/dev/usb/wlan/if_rum.c, but I got lost. Tried with sysctl -a | grep rum or grep wlan0, but no MiB related to sensitivity appeared. Is there anything I can try ? How can I force bbp 17 to get 0 value ? Tried with rum_def_bbp in if_rum.c, changing 17 to 0. No luck. Regards, Gus From phk at phk.freebsd.dk Fri May 1 10:27:09 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri May 1 10:27:14 2009 Subject: SO_LINGER + shutdown(2) Message-ID: <9639.1241172701@critter.freebsd.dk> I was somewhat surprised to see that calling shutdown(SHUT_WR) on a TCP socket with SO_LINGER set {.l_onoff = 1, .l_linger = 0} does not in fact flush the send queue orderly, but immediately RST's the connection. I realize this is an issue for the Dept. of deep TCP arcanæ and not something to be changed lightly, so consider this more of an observation than bug report. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From onemda at gmail.com Fri May 1 14:20:28 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Fri May 1 14:20:35 2009 Subject: Signal sensitivity problem with if_rum In-Reply-To: <49FA2E3F.9050108@entel.upc.edu> References: <49FA2E3F.9050108@entel.upc.edu> Message-ID: <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> On 5/1/09, Gustau Perez wrote: > > Hi, > > I think this is right place to post, if it is not, please let me know. > > I'm experiencing problems with two different devices using if_rum. > One is a Hercules Guillemot and the other is a Linksys Cisco WUSB54GC > > The first one is about sensitivity, which is very low: for example, > I'm detecting just two or three networks around me (with windows both > usb devices detect around 14 or 15 networks) and the reported signal is > very low.Placing the sensor very near to my wireless network AP (which > is a FreeBSD machine with atheros card placing the txpower to 20) > reports a signal quality of 50% or 60%. > > Linux presents the same problem (my wife's laptop with ubuntu shows > the same figures, more or > > The other one is that having such a low sensitivity makes those > dongles unusable when making large transfers, mostly when using scp/sftp > or sshfs (samba seems to make it work better for longer transfer, but > finally the problem appears). At some given point, the dongles seem to > lose contact with the AP (making ifconfig shows that wlan0 is still > associated), waiting for a period of time (usually one or two minutes) > the transfer continues. Probably both problems are related. > > In order to debug the problem I tried looking dmesg in both my AP and > my laptop (no trace). Tried looking at the ssh logs (when making large > transfers, no clue). In the only place I found something was in the > samba logs, only saying that there was a problem with the transfer > (broken pipe, the socket is closed). > > So : > > In the linux world, I found that the register which controls the > sensitivity is bbp17 : > > http://209.85.229.132/search?q=cache:H8W6R5Ds3mYJ:forum.aircrack-ng.org/index.php%3Ftopic%3D2235.0+bbp17+ralink+linux&cd=1&hl=ca&ct=clnk&gl=es&client=firefox-a > > Tried looking in > /usr/src/sys/dev/usb/wlan/if_rum.c, but I got lost. Tried with sysctl -a > | grep rum or grep wlan0, but no MiB related to sensitivity appeared. > > Is there anything I can try ? How can I force bbp 17 to get 0 value ? > Tried with rum_def_bbp in if_rum.c, changing 17 to 0. No luck. There is several places where bbp17 is changed. Last time I was exploring rum I found that it lacks bbp auto tuning. [Failed to implement it, because in meantime I broke chip :)] -- Paul From bms at incunabulum.net Fri May 1 15:36:16 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri May 1 15:36:33 2009 Subject: LOR in ip6_output() and MLDv2 Message-ID: <49FB16ED.1070909@incunabulum.net> Hi all, There is a Lock Order Reversal in ip6_output(), which is triggered by the MLDv2 code. What's the best way to resolve? IF_AFDATA_LOCK could be changed to an rwlock, that might help get rid of it -- ip6_output() will take an exclusive lock by way of in6_setscope(), which is needed as ip6_output() does not accept an ifp. in6_setscope() acquires the IF_AFDATA_LOCK and the SCOPE6_LOCK. It does not write to anything. MLD tries to side-step the use of in6_setscope() with the MLD lock held, but this is not enough because ip6_output() will still need to call in6_setscope() to verify the scope ID which MLD gives to it is not bogus (even though in the KAME stack, this just amounts to an embedded ifindex). The LOR is probably benign, but it exists because the bottom half of IPv6 is taking mutex locks on ifnet's if_afdata field. It is triggered because _domifattach() is always called with the IF_AFDATA lock held, and it takes the MLI_LOCK during initialization. WITNESS sees this lock order and notes it down, it then triggers a LOR on if detach. I'd rather not introduce a netisr for an output queue, as forcing deferred dispatch (to get away from the LOR) is undesirable and could lead to further races on VIMAGE detach, for example. cheers, BMS From louie at transsys.com Fri May 1 16:51:51 2009 From: louie at transsys.com (Louis Mamakos) Date: Fri May 1 16:51:58 2009 Subject: SO_LINGER + shutdown(2) In-Reply-To: <9639.1241172701@critter.freebsd.dk> References: <9639.1241172701@critter.freebsd.dk> Message-ID: <608FDC77-03A7-47E5-B992-6B0ECC1BFACE@transsys.com> On May 1, 2009, at 6:11 AM, Poul-Henning Kamp wrote: > > I was somewhat surprised to see that calling shutdown(SHUT_WR) on > a TCP socket with SO_LINGER set {.l_onoff = 1, .l_linger = 0} does > not in fact flush the send queue orderly, but immediately RST's the > connection. > > I realize this is an issue for the Dept. of deep TCP arcan? and not > something to be changed lightly, so consider this more of an > observation than bug report. > Setting aside for the moment what applications might rely on this behavior, this seems unexpected and perhaps wrong to me. The intent of the shutdown() system call in this instance ought to be to indicate that the local end of the connection has no additional data to transmit to the remote TCP peer. But it ought to continue to allow additional data to be read from the connection. Sending a reset segment to the far end will hardly enable that behavior. The remote TCP will abandon the connection and there will be no further data forthcoming from it (aside from what might be in flight.) If the local TCP connection has already received a FIN segment from the far end and is in CLOSEWAIT state, then perhaps that's a bit of a different animal.. louie From bms at incunabulum.net Fri May 1 17:33:55 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri May 1 17:34:02 2009 Subject: Request feedback on IPv6 multicast listen on :: Message-ID: <49FB327E.3010504@incunabulum.net> During the MLDv2 refactoring, I removed some old KAME code which supports the ability to listen to *all* multicast groups. It isn't clear to me whether this code was still in use, and I couldn't find information about it in the normative RFCs (2292, 3542) for IPv6 stack implementation. This call needed super-user privileges to use, and I'm not sure if anything is actually using it. Can anyone out there with possible exposure to it clarify? I can find a way to re-introduce it if needed, but I suspect it is very old code which may not have actually been used (it dates back to the initial KAME fork). cheers, BMS From toasty at dragondata.com Fri May 1 18:06:08 2009 From: toasty at dragondata.com (Kevin Day) Date: Fri May 1 18:07:04 2009 Subject: Slow local TCP transfers on -CURRENT Message-ID: <00C19FCC-837A-44B8-A0C9-C56E3D02F8EF@dragondata.com> I've been seeing this for a few months now on -CURRENT. TCP transfers to local IP addresses (but not 127.0.0.1) are incredibly slow. Transfer from localhost: # scp "root@127.0.0.1:/boot/kernel/kernel" . kernel 100 % 11MB 11.1MB/s 00:00 Appropriately fast. Transfer from an IP on a local interface: # scp "root@216.14.96.4:/boot/kernel/kernel" . kernel 0 % 16KB 13.0KB/s 14:37 ETA The routes seem normal: # route get 127.0.0.1 route to: localhost destination: localhost interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 # route -n get 216.14.96.4 route to: 216.14.96.4 destination: 216.14.96.0 mask: 255.255.255.128 interface: nfe0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 nfe0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:c6:dd:9c inet 216.14.96.4 netmask 0xffffff80 broadcast 216.14.96.127 Takes 10-60 minutes to copy, stalling frequently during the transfer. It's not limited to just scp either, all TCP transfers seem to stall this way. I don't believe I'm doing anything unusual, has anyone seen anything like this? -- Kevin From gperez at entel.upc.edu Fri May 1 20:05:37 2009 From: gperez at entel.upc.edu (=?ISO-8859-1?Q?Gustau_P=E9rez?=) Date: Fri May 1 20:05:43 2009 Subject: Signal sensitivity problem with if_rum In-Reply-To: <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> Message-ID: <49FB55A3.605@entel.upc.edu> > There is several places where bbp17 is changed. > > Editing the code looking for calls to the function rum_bbp_write, I've been able to find where bbp17 is changed at init. Changing rum_def_bbp[3] (which is reg 17) to values quite 'big' like 0x10 or 0x14 doesn't seem to affect its behaviour. Lowering it even more (0x01for example) sometimes shows more reacheable AP's in range; but signal quality still very bad. Changing RT2573_NOISE_FLOOR doesn't make any change (in terms of signal quality, which remains the same). Any idea if is there anything to change/tune ? Regards, Gus > Last time I was exploring > rum I found that it lacks bbp auto tuning. > [Failed to implement it, because in meantime I broke chip :)] > > From barney_cordoba at yahoo.com Fri May 1 23:20:59 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Fri May 1 23:21:06 2009 Subject: Interrupts + Polling mode (similar to Linux's NAPI) In-Reply-To: Message-ID: <585693.96129.qm@web63906.mail.re1.yahoo.com> --- On Thu, 4/30/09, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: barney_cordoba@yahoo.com > Cc: "FreeBSD Net" > Date: Thursday, April 30, 2009, 11:51 AM > 2009/4/30 Barney Cordoba : > > Its one of the sad truths of FreeBSD. You'd think > with such a large number > > of commercial users you'd be able to get plenty of > funding for the things > > that really need to be done, rather then taking > whatever bread crumbs > > are thrown your way. Perhaps you need fewer bearded > academics and a few > > more suits to run the project more like a business > than an extended > > masters thesis? > > That is happening. Robert/Kris' (and others) working on > parallelising > the network stack all the way up and down. Kip has been > working on > dramatically improving TCP connection and packet forward > scalability > to support 10GE. This is in part commercially funded work. > > The problem with "commercial funding" is that for > the most part, > FreeBSD/Linux/etc "mostly work" for most use > cases. What you're not > seeing is 100% contribution back from commercial > organisations who > have extended FreeBSD (and linux for that matter) in their > environment > to fix specific performance constraints. This is finally > changing and > stuff is being pushed back into the public tree. I think its unlikely that a commercial implementation is going to be of much use generally, as with a mutex based OS you're going to have to do heavy specialization to get the results you want. For example a web server, transparent firewall and router would required very different implementations to be properly optimised. I'm going to regularly hear the open sorcerers whining about contributing, but the fact is that the work I'm doing has no place in a general purpose OS. Optimizing for a specific commercial product is going to require all kinds of fudging and gimmickry. Barney From fbi7876 at inMail24.com Fri May 1 23:47:25 2009 From: fbi7876 at inMail24.com (Robert S. Mueller) Date: Fri May 1 23:47:34 2009 Subject: Attn: Beneficiary.... Message-ID: <20090501150357.1AEE51178F2@b08.banan.cz> Anti-Terrorist and Monitory Crimes Division. Federal Bureau Of Investigation. Attn: Beneficiary, This is to Officially Inform you that it has come to our notice and we have thoroughly investigated by the help of our Intelligence Monitoring Network System that you are having a Legal Transaction with some people, it came to our notice that you are So therefore, we have contacted the Federal Ministry Of Finance on your behalf and they have brought a solution to your problem by arranging your payment in total of (US$20,000,000:00)$20 million in an ATM CARD which you will use to withdraw money in anywhere of the world. You now have the lawful right to claim your fund in the ATM CARD by contacting the ATM CARD CENTER, their email is as follow: {atmpaymentcentre12@inMail24.com}. Also, we have being informed by Mr. Robert Scheels that he gave you instructions on how to proceed and contact the ATM CARD CENTER for their requirements to procure your Approval Slip which contains details of your PERSONAL IDENTIFICATION NUMBER (PIN) which you would use in activating and operating your ATM CARD in any ATM Machine closer to you and note that to procure your Approval Slip it would cost you $550.00. Since the Federal Bureau of Investigation is involved in this transaction, all you did have to do is to be rest assured for this is 100% risk free so do contact the ATM CARD CENTRE so they could let you know on how to make payment for the procurement of your Approval Slip which is the only payment needed before the delivery of your ATM CARD is being effected. Below are the contact details of the ATM CARD CENTRE which you are to proceed and contact them for their requirements to proceed and procure your Approval Slip after making payment of $550.00 CONTACT DETAILS Name: Sandra Larry Email:{atmpaymentcentre12@inMail24.com} We do await your response so we can move on with our Investigation and make sure your ATM SWIFT CARD gets to you. Thanks and hope to read from you soon. FBI Director Robert S. Mueller Note: Do disregard any email you get from any imposter or office claiming to be in possession of your ATM CARD, you are advised only to be in contact with Mrs Sandra Larry of the ATM CARD CENTRE who is the rightful person you are suppose to deal with in regards of your ATM CARD PAYMENT and forward any email you get from imposters to this office so we could act upon and commence investigation. From onemda at gmail.com Sat May 2 00:16:15 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sat May 2 00:16:21 2009 Subject: Signal sensitivity problem with if_rum In-Reply-To: <49FB55A3.605@entel.upc.edu> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> Message-ID: <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> On 5/1/09, Gustau Perez wrote: > >> There is several places where bbp17 is changed. >> >> > > Editing the code looking for calls to the function rum_bbp_write, > I've been able to find where bbp17 is changed at init. Changing > rum_def_bbp[3] (which is reg 17) to values quite 'big' like 0x10 or 0x14 > doesn't seem to affect its behaviour. > > Lowering it even more (0x01for example) sometimes shows more > reacheable AP's in range; but signal quality still very bad. > Changing RT2573_NOISE_FLOOR doesn't make any change (in terms of signal > quality, which remains the same). > > Any idea if is there anything to change/tune ? There is not just bbp17 to tune there are probably others much more important registers. But as I already mentioned that code is completly missing. -- Paul From Jinmei_Tatuya at isc.org Sat May 2 02:00:49 2009 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Sat May 2 02:01:23 2009 Subject: Request feedback on IPv6 multicast listen on :: In-Reply-To: <49FB327E.3010504@incunabulum.net> References: <49FB327E.3010504@incunabulum.net> Message-ID: At Fri, 01 May 2009 18:33:50 +0100, Bruce Simpson wrote: > During the MLDv2 refactoring, I removed some old KAME code which > supports the ability to listen to *all* multicast groups. > It isn't clear to me whether this code was still in use, and I couldn't > find information about it in the normative RFCs (2292, 3542) for IPv6 > stack implementation. > > This call needed super-user privileges to use, and I'm not sure if > anything is actually using it. Can anyone out there with possible > exposure to it clarify? I believe you can safely remove it. The KAME repository version of that code was already deprecated long time ago. See the change for rev.1.433 at: http://orange.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ip6_output.c I also noted this strange behavior in a book about the KAME implementation: 3684: mreq = mtod(m, struct ipv6_mreq *); 3685: if (IN6_IS_ADDR_UNSPECIFIED(&mreq->ipv6mr_multiaddr)) { 3686: /* 3687: * We use the unspecified address to specify to accept 3688: * all multicast addresses. Only super user is allowed 3689: * to do this. 3690: */ 3692: if (suser(p)) 3696: { 3697: error = EACCES; 3698: break; 3699: } 3684?3699 ipv6mr_multiaddr ?eld must hold a valid IPv6 multicast address. The KAME implementation allows a privileged application to specify the IPv6 unspeci?ed address. While the intention may be to allow the socket to accept packets from any multicast address, the system does not actually behave that way. First, the IN6_LOOKUP_MULTI() macro does not have a special matching rule for the unspeci?ed address. Secondly, in order to accept any multicast addresses on an interface, it is necessary to specify the promiscuous mode for the interface?s multicast ?lter, which will not actually be done in this case. Later versions of the KAME implementation removed this code and similar code that exists for IPV6_LEAVE_GROUP. Hope this helps, --- JINMEI, Tatuya Internet Systems Consortium, Inc. From adrian at freebsd.org Sat May 2 06:32:24 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Sat May 2 06:32:31 2009 Subject: Interrupts + Polling mode (similar to Linux's NAPI) In-Reply-To: <585693.96129.qm@web63906.mail.re1.yahoo.com> References: <585693.96129.qm@web63906.mail.re1.yahoo.com> Message-ID: 2009/5/2 Barney Cordoba : > I think its unlikely that a commercial implementation is going to > be of much use generally, as with a mutex based OS you're going to > have to do heavy specialization to get the results ?you want. For > example a web server, transparent firewall and router would required > very different implementations to be properly optimised. > > I'm going to regularly hear the open sorcerers whining about > contributing, but the fact is that the work I'm doing has no place in > a general purpose OS. Optimizing for a specific commercial product is > going to require all kinds of fudging and gimmickry. Sure, but you may find that your fudging and gimmickry could be useful as a reference platform for more generic improvements. So I do encourage you (and others!) with these sorts of hackery to release your stuff for others to use and abuse. Who knows, they may get improved and included into FreeBSD at a later stage. (FWIW, companies like Ironport do just this. :) Adrian From gperez at entel.upc.edu Sat May 2 07:45:36 2009 From: gperez at entel.upc.edu (=?ISO-8859-1?Q?Gustau_P=E9rez?=) Date: Sat May 2 07:45:43 2009 Subject: Signal sensitivity problem with if_rum In-Reply-To: <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> Message-ID: <49FBF9B5.40800@entel.upc.edu> >> Any idea if is there anything to change/tune ? >> > > There is not just bbp17 to tune there are probably others much more important > registers. > > But as I already mentioned that code is completly missing. > > I was not talking about autotuning features, which are missing as you pointed. Was talking just about changing/tuning values of some registers to increase reception sensitivity. The people of linux, seem to have increased the sensitivity by modifing bbp17 and disabling autotuning. I tried with bbp17 and for the autotuning disabled, well, we already have it implemented :) (just joking) Anyway, giving that I didn't get an increase of sensitivity, I think we'll need the help of the developers. Well, this morning will try to increase sensitivity of those usb rum with a linux system, just to check what they say here : http://209.85.229.132/search?q=cache:H8W6R5Ds3mYJ:forum.aircrack-ng.org/index.php%3Ftopic%3D2235.0+bbp17+ralink+linux&cd=1&hl=ca&ct=clnk&gl=es&client=firefox-a Regards, Gus From barney_cordoba at yahoo.com Sat May 2 11:51:22 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Sat May 2 11:51:29 2009 Subject: Interrupts + Polling mode (similar to Linux's NAPI) In-Reply-To: Message-ID: <666691.64173.qm@web63901.mail.re1.yahoo.com> --- On Sat, 5/2/09, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: barney_cordoba@yahoo.com > Cc: "FreeBSD Net" > Date: Saturday, May 2, 2009, 2:32 AM > 2009/5/2 Barney Cordoba : > > > I think its unlikely that a commercial implementation > is going to > > be of much use generally, as with a mutex based OS > you're going to > > have to do heavy specialization to get the results > ?you want. For > > example a web server, transparent firewall and router > would required > > very different implementations to be properly > optimised. > > > > I'm going to regularly hear the open sorcerers > whining about > > contributing, but the fact is that the work I'm > doing has no place in > > a general purpose OS. Optimizing for a specific > commercial product is > > going to require all kinds of fudging and gimmickry. > > Sure, but you may find that your fudging and gimmickry > could be useful > as a reference platform for more generic improvements. > > So I do encourage you (and others!) with these sorts of > hackery to > release your stuff for others to use and abuse. Who knows, > they may > get improved and included into FreeBSD at a later stage. > > (FWIW, companies like Ironport do just this. :) > Companies might release bug fixes and such, but nobody is going to spend a lot of money to build a better mousetrap and then effectively give away the work to all of their competitors. BC Barney From ivoras at freebsd.org Sat May 2 12:25:45 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat May 2 12:26:18 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" Message-ID: Hi, When I upgraded my 7-STABLE virtual machine under VirtualBox to 8-CURRENT, the em driver stopped working. VirtualBox supports three different flavours of emulated em devices, all of which result in the "Invalid MAC address" error and cannot be used any more. The error was previously reported for VMWare, but since VirtualBox is as different from VMWare as it can be, the problem is most likely in the driver. I can provide more information if needed, I'll be at DevSummit with the box. From lstewart at freebsd.org Sat May 2 12:50:03 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Sat May 2 12:50:10 2009 Subject: Slow local TCP transfers on -CURRENT In-Reply-To: <00C19FCC-837A-44B8-A0C9-C56E3D02F8EF@dragondata.com> References: <00C19FCC-837A-44B8-A0C9-C56E3D02F8EF@dragondata.com> Message-ID: <49FC3984.8050609@freebsd.org> Kevin Day wrote: > > I've been seeing this for a few months now on -CURRENT. TCP transfers to > local IP addresses (but not 127.0.0.1) are incredibly slow. > > Transfer from localhost: > > # scp "root@127.0.0.1:/boot/kernel/kernel" . > kernel > 100% 11MB 11.1MB/s 00:00 > > Appropriately fast. > > > Transfer from an IP on a local interface: > > # scp "root@216.14.96.4:/boot/kernel/kernel" . > kernel > 0% 16KB 13.0KB/s 14:37 ETA > > > The routes seem normal: > > > # route get 127.0.0.1 > route to: localhost > destination: localhost > interface: lo0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 16384 1 0 > > # route -n get 216.14.96.4 > route to: 216.14.96.4 > destination: 216.14.96.0 > mask: 255.255.255.128 > interface: nfe0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0 > > > nfe0: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:30:48:c6:dd:9c > inet 216.14.96.4 netmask 0xffffff80 broadcast 216.14.96.127 > > Takes 10-60 minutes to copy, stalling frequently during the transfer. > It's not limited to just scp either, all TCP transfers seem to stall > this way. > > > > I don't believe I'm doing anything unusual, has anyone seen anything > like this? Known fallout from the ARPv2 work I believe. As a workaround until it gets fixed: route add -host (if-ip) -iface lo0 (note I haven't tested this myself) (see the Jan 2009 freebsd-net@ thread "Bacula: VERY SLOW on SAME host" for some details). Cheers, Lawrence From onemda at gmail.com Sat May 2 13:17:36 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sat May 2 13:17:42 2009 Subject: Signal sensitivity problem with if_rum In-Reply-To: <49FBF9B5.40800@entel.upc.edu> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> <49FBF9B5.40800@entel.upc.edu> Message-ID: <3a142e750905020617y40f62463ma91b46a015b2b2ab@mail.gmail.com> On 5/2/09, Gustau Perez wrote: > >>> Any idea if is there anything to change/tune ? >>> >> >> There is not just bbp17 to tune there are probably others much more >> important >> registers. >> >> But as I already mentioned that code is completly missing. >> >> > I was not talking about autotuning features, which are missing as you > pointed. Was talking > just about changing/tuning values of some registers to increase > reception sensitivity. > > The people of linux, seem to have increased the sensitivity by > modifing bbp17 and disabling > autotuning. I tried with bbp17 and for the autotuning disabled, well, we > already have it > implemented :) (just joking) Anyway, giving that I didn't get an > increase of sensitivity, I think we'll > need the help of the developers. > > Well, this morning will try to increase sensitivity of those usb rum > with a linux system, just to check > what they say here : That information is misleading, I remmember reading somewhere that linux rt73 had similar problems like rum but it got fixed, and is not present in new kernels. I think that problem originated for linux from now obsolete drivers. On what linux version and what drivers version do you experience similar problems with signal sensitivity like with rum? -- Paul From jfvogel at gmail.com Sat May 2 15:03:53 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Sat May 2 15:04:00 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" In-Reply-To: References: Message-ID: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> I'm willing to bet that its in fact the same problem that VMWare is having. Our method of getting the mac address changed, and the emulations seem to be unprepared for it. This was done for a real customer requirement to allow support of alternate mac addressing in firmware. What happens now is a warm reset of the hardware is done, followed by reading the RAR[0] register. In a real Intel NIC the mac address will be valid in that register, but in VMWare, and I'm willing to bet in VirtualBox as well, its 0. VMWare also has 3 choices of device (wow, amazing coincidence :), can you tell me when you pick e1000 what real adapter it claims to emulate? I am considering options for this problem. The one I lean toward right now is to make a "legacy" em driver, it will have support for ONLY pre-PCI Express hardware, it will be frozen as it were, the idea is that with no new work on it it will not suffer from any regression type failures. If I do this, there are some strategy issues, and its those I'm thinking about. In any case, I intend to have this problem resolved for 8's release. Stay tuned. Jack On Sat, May 2, 2009 at 5:25 AM, Ivan Voras wrote: > Hi, > > When I upgraded my 7-STABLE virtual machine under VirtualBox to 8-CURRENT, > the em driver stopped working. VirtualBox supports three different flavours > of emulated em devices, all of which result in the "Invalid MAC address" > error and cannot be used any more. > > The error was previously reported for VMWare, but since VirtualBox is as > different from VMWare as it can be, the problem is most likely in the > driver. > > I can provide more information if needed, I'll be at DevSummit with the > box. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From swun2010 at gmail.com Sat May 2 16:50:03 2009 From: swun2010 at gmail.com (Sam Wun) Date: Sat May 2 16:50:10 2009 Subject: tcp problem with freebsd 7.1? Message-ID: <736c47cb0905020928o23062742sced92fc20f351eb3@mail.gmail.com> Hi, With regarding to the following statement, is there any serious tcp problem with freebsd 7.1? "We recently found our new FreeBSD server (located in some foreign region) has poor network performance. After doing some tcpdump and iperf testing, we found that out-of-order TCP packets are not inserted into queue. This is an 100Mbps line, and TSO is disabled. " Very appreciate for any suggestion. Thanks From swun2010 at gmail.com Sat May 2 17:00:07 2009 From: swun2010 at gmail.com (Sam Wun) Date: Sat May 2 17:00:14 2009 Subject: tcp problem with freebsd 7.1? Message-ID: <736c47cb0905020928h10a956e7r3d9d7fd10bd23a1d@mail.gmail.com> Hi, With regarding to the following statement, is there any serious tcp problem with freebsd 7.1? "We recently found our new FreeBSD server (located in some foreign region) has poor network performance. After doing some tcpdump and iperf testing, we found that out-of-order TCP packets are not inserted into queue. This is an 100Mbps line, and TSO is disabled. " Very appreciate for any suggestion. Thanks From wzuber at mac.com Sat May 2 18:04:20 2009 From: wzuber at mac.com (Wes Zuber) Date: Sat May 2 18:04:27 2009 Subject: tcp problem with freebsd 7.1? In-Reply-To: <736c47cb0905020928o23062742sced92fc20f351eb3@mail.gmail.com> References: <736c47cb0905020928o23062742sced92fc20f351eb3@mail.gmail.com> Message-ID: <7AF3433E-1760-400D-BF04-1C75C838F371@mac.com> We have had some issues with NIC drivers in the past.. what Nics are you running. Specifically some Nics need to have the CRC checks disabled. This also sounds like state is not being kept on the IP Filter if you are running one. Do you have more details? --Wes On May 2, 2009, at 9:28 AM, Sam Wun wrote: > Hi, > > With regarding to the following statement, is there any serious tcp > problem with freebsd 7.1? > > "We recently found our new FreeBSD server (located in some foreign > region) has poor network performance. After doing some tcpdump and > iperf testing, we found that out-of-order TCP packets are not inserted > into queue. > > This is an 100Mbps line, and TSO is disabled. " > > Very appreciate for any suggestion. > > Thanks > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From rslaranjo at gmail.com Sat May 2 20:30:36 2009 From: rslaranjo at gmail.com (Rommel Laranjo) Date: Sat May 2 20:30:43 2009 Subject: Freebsd failed to create routing prefix Message-ID: Hello everyone, I need help. My box(Machine1) by default will perform IPv6 stateless autoconfiguration and I need to change this autoconfigured address to static manually without restarting. Here are the steps I follow but I sure I missed something cause I was unsuccessful of doing it. 1. I disabled sysctl knob to stop receiving rtadv # sysctl -w net.inet6.ip6.accept_rtadv=0 2. I then removed the autoconfigured ipv6 address from the interface # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd delete 3. I removed the default ipv6 route since I will replace with another route # route delete -inet6 default 4. I then added the autoconfigured ipv6 address back to the interface to make it static # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd prefixlen 64 up 5. I added the new default ipv6 route # route add -inet6 default 2001:db8:1234:abcd::1 At this point I pinged 2001:db8:1234:abcd:20c:27ff:fe3d:63dd from another IPv6 box (Machine2) with IPv6 address of the same prefix (2001:db8:1234:abcd:215:d3ff:fe4f:acaf) but with no success. But if I ping6 from Machine2 to my router 2001:db8:1234:abcd::1 I am successfull. I tried to check IPv6 route information from Machine1 thru netstat -rnf inet6 but have not found this entry: 2001:db8:1234:abcd::/64 link#1 UC em0 I hope someone could shed light on how to put this route into my ipv6 routing table. Is this a bug in FreeBSD not to automatically add a routing prefix after changing from IPv6 stateless autoconfiguration to static IPv6 address ? Thanks, Romskie From linimon at FreeBSD.org Sat May 2 21:41:53 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat May 2 21:42:00 2009 Subject: kern/134168: [ral] ral driver problem on RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless Message-ID: <200905022141.n42Lfr5x035284@freefall.freebsd.org> Old Synopsis: ral driver problem on RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless New Synopsis: [ral] ral driver problem on RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:41:43 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134168 From linimon at FreeBSD.org Sat May 2 21:53:54 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat May 2 21:54:00 2009 Subject: kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression] Message-ID: <200905022153.n42LrrJf048492@freefall.freebsd.org> Old Synopsis: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable New Synopsis: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:53:37 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134157 From linimon at FreeBSD.org Sat May 2 21:56:38 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat May 2 21:56:45 2009 Subject: kern/133968: [dummynet] [panic] dummynet kernel panic Message-ID: <200905022156.n42Luboo048622@freefall.freebsd.org> Old Synopsis: Dummynet kernel panic New Synopsis: [dummynet] [panic] dummynet kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:56:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133968 From linimon at FreeBSD.org Sat May 2 21:57:10 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat May 2 21:57:20 2009 Subject: kern/133969: [dummynet] [panic] Fatal trap 12: page fault while in kernel mode with dummynet Message-ID: <200905022157.n42Lv9vd048671@freefall.freebsd.org> Old Synopsis: Fatal trap 12: page fault while in kernel mode with dummynet New Synopsis: [dummynet] [panic] Fatal trap 12: page fault while in kernel mode with dummynet Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:56:48 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133969 From aman.jassal at esigetel.fr Sat May 2 23:00:00 2009 From: aman.jassal at esigetel.fr (JASSAL Aman) Date: Sat May 2 23:00:07 2009 Subject: Freebsd failed to create routing prefix In-Reply-To: References: Message-ID: <52471.86.212.66.201.1241304184.squirrel@webmail.esigetel.fr> Hello M.Laranjo The Kame stack for IPv6 should be working fine, whether you use stateless autoconfiguration or static configuration. Since you want to use static configuration, my suggestion would be to modify the /etc/rc.conf file so that your static configuration is loaded everytime at boot. That way, you don't have to suppress the autoconfigured address to reconfigure your static address afterwards. The lines you will need are : ipv6_enable="YES" ipv6_network_interface="em0" ipv6_ifconfig_em0="2001:db8:1234:abcd:20c:27ff:fe3d:63dd prefixlen 64" ipv6_defaultrouter="2001:db8:1234:abcd::1" This should work. Please try to ping6 your router to see if everything is working as it's supposed to. About your last question, I'm not 100% sure, but I don't think FreeBSD will autoconfigure a route if you just add a static ipv6 address on your interface... Unless you use a routing daemon like routed. Kind regards Aman Jassal Le Sam 2 mai 2009 21:59, Rommel Laranjo a ?crit : > Hello everyone, > > > I need help. My box(Machine1) by default will perform IPv6 stateless > autoconfiguration and I need to change this autoconfigured address to > static manually without restarting. Here are the steps I follow but I sure > I missed something cause I was > unsuccessful of doing it. > > 1. I disabled sysctl knob to stop receiving rtadv > # sysctl -w net.inet6.ip6.accept_rtadv=0 > > > 2. I then removed the autoconfigured ipv6 address from the interface > # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd delete > > > 3. I removed the default ipv6 route since I will replace with another > route # route delete -inet6 default > > > 4. I then added the autoconfigured ipv6 address back to the interface to > make it static # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd > prefixlen 64 up > > 5. I added the new default ipv6 route > # route add -inet6 default 2001:db8:1234:abcd::1 > > > At this point I pinged 2001:db8:1234:abcd:20c:27ff:fe3d:63dd from another > IPv6 box (Machine2) with IPv6 address of the same prefix > (2001:db8:1234:abcd:215:d3ff:fe4f:acaf) but with no success. But if I > ping6 from Machine2 to my router 2001:db8:1234:abcd::1 I am successfull. > > I tried to check IPv6 route information from Machine1 thru netstat -rnf > inet6 but have not found this entry: > > 2001:db8:1234:abcd::/64 link#1 UC > em0 > > I hope someone could shed light on how to put this route into my ipv6 > routing table. Is this a bug in FreeBSD not to automatically add a routing > prefix after changing from IPv6 stateless autoconfiguration to static IPv6 > address ? > > Thanks, > > > Romskie > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From ivoras at freebsd.org Sat May 2 23:15:33 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat May 2 23:15:39 2009 Subject: Regression: em driver in -CURRENT, "Invalid MAC address" In-Reply-To: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> References: <2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com> Message-ID: <9bbcef730905021615l21ef8a73hf26aca18f3230c3b@mail.gmail.com> 2009/5/2 Jack Vogel : > I'm willing to bet that its in fact the same problem that VMWare is having. > Our method of getting the mac address changed, and the emulations seem > to be unprepared for it. > > This was done for a real customer requirement to allow support of alternate > mac addressing in firmware. What happens now is a warm reset of the hardware > is done, followed by reading the RAR[0] register. In a real Intel NIC the > mac > address will be valid in that register, but in VMWare, and I'm willing to > bet in > VirtualBox as well, its 0. > > VMWare also has 3 choices of device (wow, amazing coincidence :), can > you tell me when you pick e1000 what real adapter it claims to emulate? Here's the information on all three: em0: port 0xc060-0xc067 mem 0xf0820000-0xf083ffff irq 16 at device 8.0 on pci0 em0: Invalid MAC address device_attach: em0 attach returned 5 em1: port 0xc068-0xc06f mem 0xf0840000-0xf085ffff irq 17 at device 9.0 on pci0 em1: Invalid MAC address device_attach: em1 attach returned 5 em2: port 0xc070-0xc077 mem 0xf0860000-0xf087ffff irq 18 at device 10.0 on pci0 em2: Invalid MAC address device_attach: em2 attach returned 5 em0@pci0:0:8:0: class=0x020000 card=0x001e8086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction em1@pci0:0:9:0: class=0x020000 card=0x10048086 chip=0x10048086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82543GC Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction em2@pci0:0:10:0: class=0x020000 card=0x075015ad chip=0x100f8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82545EM Gigabit Ethernet Controller (copper)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction > I am considering options for this problem. The one I lean toward right now > is to make a "legacy" em driver, it will have support for ONLY pre-PCI > Express > hardware, it will be frozen as it were, the idea is that with no new work on > it > it will not suffer from any regression type failures. If I do this, there > are some > strategy issues, and its those I'm thinking about. I think that would be a losing battle wrt future developments of both the driver and the VM environments (too fragile state; anyway, other OSes don't have the issue so why should we?). I don't really know how it works but couldn't you use the information talked about earlier (register is 0 after a warm reset) to detect the general class of the problem and if detected conditionally proceed with the old code / behaviour just for the initialization part? Another possible route is to make use of VM detection present in HEAD and just blindly use the old way if a VM environment is detected. I think this is only slightly less bad than forking the driver since new VM platforms are appearing all the time - is something like the middle option doable? From hrs at FreeBSD.org Sat May 2 23:17:02 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Sat May 2 23:17:34 2009 Subject: Freebsd failed to create routing prefix In-Reply-To: References: Message-ID: <20090503.081617.15105360.hrs@allbsd.org> Rommel Laranjo wrote in : rs> I hope someone could shed light on how to put this route into my ipv6 rs> routing table. rs> Is this a bug in FreeBSD not to automatically add a routing prefix rs> after changing from IPv6 stateless autoconfiguration to rs> static IPv6 address ? It looks odd because that link should be added automatically at 4 in your procedure regardless of whether you use the stateless autoconf. BTW, does your system have multiple NICs? -- | Hiroki SATO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090502/9586dbc8/attachment.pgp From onemda at gmail.com Sun May 3 00:30:03 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sun May 3 00:30:09 2009 Subject: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics In-Reply-To: <200807131711.m6DHB0ni082660@freefall.freebsd.org> References: <200807131711.m6DHB0ni082660@freefall.freebsd.org> Message-ID: <3a142e750905021730ha9b6771p5a0e2ef0a8d6d50e@mail.gmail.com> On 7/13/08, gavin@freebsd.org wrote: > Old Synopsis: [ndis] with wep enters kdb.enter.unknown, panics > New Synopsis: [ndis] [patch] with wep enters kdb.enter.unknown, panics > > State-Changed-From-To: feedback->open > State-Changed-By: gavin > State-Changed-When: Sun Jul 13 17:06:03 UTC 2008 > State-Changed-Why: > Over to maintainers for evaluation > > > Responsible-Changed-From-To: gavin->freebsd-net > Responsible-Changed-By: gavin > Responsible-Changed-When: Sun Jul 13 17:06:03 UTC 2008 > Responsible-Changed-Why: > Submitter reports my patch fixes things for him > > http://www.freebsd.org/cgi/query-pr.cgi?pr=125181 > As of recent CURRENT(r191746), this issue have been fixed. -- Paul From invite+ke5r5rmn at facebookmail.com Sun May 3 00:37:52 2009 From: invite+ke5r5rmn at facebookmail.com (Alex Santiago) Date: Sun May 3 00:37:58 2009 Subject: Check out my photos on Facebook Message-ID: <1740538534d76b534b558aaf95b88e0f@localhost.localdomain> Hi Freebsd-net, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Alex To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=841695471&k=32DYP2TXT5XM5CEIXFY6X3&r freebsd-net@freebsd.org was invited to join Facebook by Alex Santiago. If you do not wish to receive this type of email from Facebook in the future, please click on the link below to unsubscribe. http://www.facebook.com/o.php?k=cbecc8&u=1119946398&mid=66e0fbG42c1069eG0G8 Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301. From sam at ip6.com.au Sun May 3 04:13:54 2009 From: sam at ip6.com.au (Sam Wan) Date: Sun May 3 04:14:01 2009 Subject: How to complie keepliaved from Port. Message-ID: <24472.220.233.42.226.1241324030.squirrel@secure.ip6.com.au> Hi, Is there anyone knows how to compile keepalived from the port? Its patch only available up to version 7.0. When I followed its instruction to patch 4 files, 1 or 2 of those have been *rej*, and when I ignored and continue to build it, kernel compilation caused error. Is there a new keepalived patch for freebsd 7.1 and 7.2? Thanks From sam at ip6.com.au Sun May 3 07:49:52 2009 From: sam at ip6.com.au (Sam Wan) Date: Sun May 3 07:49:59 2009 Subject: How to complie keepliaved from Port. In-Reply-To: <24472.220.233.42.226.1241324030.squirrel@secure.ip6.com.au> References: <24472.220.233.42.226.1241324030.squirrel@secure.ip6.com.au> Message-ID: <25839.220.233.42.226.1241336988.squirrel@secure.ip6.com.au> > > Hi, > > Is there anyone knows how to compile keepalived from the port? > > Its patch only available up to version 7.0. > When I followed its instruction to patch 4 files, 1 or 2 of those have > been *rej*, and when I ignored and continue to build it, kernel > compilation caused error. > > Is there a new keepalived patch for freebsd 7.1 and 7.2? > > Thanks > > Hi, this is what I encountered during make keepalived: ASTest72RC2# make ===> Vulnerability check disabled, database not found => keepalived-FreeBSD-1.1.11.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch from http://www.cultdeadsheep.org/~clement/FreeBSD/ipvs/. keepalived-FreeBSD-1.1.11.tar.gz 100% of 208 kB 136 kBps ===> Extracting for keepalived-1.1.11_1 => MD5 Checksum OK for keepalived-FreeBSD-1.1.11.tar.gz. => SHA256 Checksum OK for keepalived-FreeBSD-1.1.11.tar.gz. ===> Patching for keepalived-1.1.11_1 ===> Applying FreeBSD patches for keepalived-1.1.11_1 ===> keepalived-1.1.11_1 depends on file: /usr/local/lib/libipvs.a - not found ===> Verifying install for /usr/local/lib/libipvs.a in /usr/ports/net/ipvs LVS on FreeBSD works only with 5.3-RELEASE and 5.4-RELEASE. However it may work on 5-STABLE. If you are running FreeBSD 5.4-STABLE, define TRY_STABLE and check if patches apply correctly to your src tree To build ipvs, I strongly encourage you to follow these instructions 1. checkout supported src tree 2. run "make patch-system" 3. configure and build your kernel. (you need support of NetFilter sockopt, add "options NF_SOCKOPT") 4. Install your freshly compiled kernel 5. install the port 6. reboot your system ===> Vulnerability check disabled, database not found => ipvs-0.4.0_2.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch from http://www.cultdeadsheep.org/~clement/FreeBSD/ipvs/. ipvs-0.4.0_2.tar.gz 100% of 74 kB 51 kBps ===> Extracting for ipvs-0.4.0_2 => MD5 Checksum OK for ipvs-0.4.0_2.tar.gz. => SHA256 Checksum OK for ipvs-0.4.0_2.tar.gz. ===> Patching for ipvs-0.4.0_2 ===> Configuring for ipvs-0.4.0_2 ===> Building for ipvs-0.4.0_2 ===> ipvs Warning: Object directory not changed from original /usr/ports/net/ipvs/work/ipvs-0.4.0_2/ipvs @ -> /usr/src/sys machine -> /usr/src/sys/i386/include cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c ip_vs_core.c cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c ip_vs_conn.c cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c ip_vs_sched.c cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c ip_vs_ctl.c ip_vs_ctl.c: In function 'do_ip_vs_set_ctl': ip_vs_ctl.c:1257: warning: implicit declaration of function 'suser' ip_vs_ctl.c:1257: warning: nested extern declaration of 'suser' ip_vs_ctl.c: At top level: ip_vs_ctl.c:1627: error: variable 'ip_vs_sockopts' has initializer but incomplete type ip_vs_ctl.c:1628: error: extra brace group at end of initializer ip_vs_ctl.c:1628: error: (near initialization for 'ip_vs_sockopts') ip_vs_ctl.c:1628: warning: excess elements in struct initializer ip_vs_ctl.c:1628: warning: (near initialization for 'ip_vs_sockopts') ip_vs_ctl.c:1628: warning: excess elements in struct initializer ip_vs_ctl.c:1628: warning: (near initialization for 'ip_vs_sockopts') ip_vs_ctl.c:1629: warning: excess elements in struct initializer ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') ip_vs_ctl.c:1629: warning: excess elements in struct initializer ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') ip_vs_ctl.c:1629: warning: excess elements in struct initializer ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') ip_vs_ctl.c:1630: warning: excess elements in struct initializer ip_vs_ctl.c:1630: warning: (near initialization for 'ip_vs_sockopts') ip_vs_ctl.c:1630: warning: excess elements in struct initializer ip_vs_ctl.c:1630: warning: (near initialization for 'ip_vs_sockopts') ip_vs_ctl.c:1631: warning: excess elements in struct initializer ip_vs_ctl.c:1631: warning: (near initialization for 'ip_vs_sockopts') ip_vs_ctl.c: In function 'ip_vs_control_init': ip_vs_ctl.c:1645: warning: implicit declaration of function 'nf_register_sockopt' ip_vs_ctl.c:1645: warning: nested extern declaration of 'nf_register_sockopt' ip_vs_ctl.c: In function 'ip_vs_control_cleanup': ip_vs_ctl.c:1675: warning: implicit declaration of function 'nf_unregister_sockopt' ip_vs_ctl.c:1675: warning: nested extern declaration of 'nf_unregister_sockopt' *** Error code 1 Stop in /usr/ports/net/ipvs/work/ipvs-0.4.0_2/ipvs. *** Error code 1 Stop in /usr/ports/net/ipvs/work/ipvs-0.4.0_2. *** Error code 1 Stop in /usr/ports/net/ipvs. *** Error code 1 Stop in /usr/ports/net/keepalived. Thanks From sam at ip6.com.au Sun May 3 09:09:47 2009 From: sam at ip6.com.au (Sam Wan) Date: Sun May 3 09:09:54 2009 Subject: How to complie keepliaved from Port. In-Reply-To: <25839.220.233.42.226.1241336988.squirrel@secure.ip6.com.au> References: <24472.220.233.42.226.1241324030.squirrel@secure.ip6.com.au> <25839.220.233.42.226.1241336988.squirrel@secure.ip6.com.au> Message-ID: <26848.220.233.42.226.1241341781.squirrel@secure.ip6.com.au> I have patched the following files, with some errors. Please provide suggestion about what I should do. Very appreciate for any suggestion. Thanks ASTest72RC2# patch -p0 < uipc_socket.c.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/kern/uipc_socket.c.orig Mon Aug 15 13:09:33 2005 |+++ sys/kern/uipc_socket.c Sun Aug 21 10:51:47 2005 -------------------------- Patching file sys/kern/uipc_socket.c using Plan A... Hunk #1 failed at 37. Hunk #2 succeeded at 1374 with fuzz 2 (offset 1309 lines). Hunk #3 succeeded at 1514 with fuzz 2 (offset -6 lines). patch: **** misordered hunks! output would be garbled ASTest72RC2# patch -p0 < ip_input.c.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/netinet/ip_input.c.orig Mon Aug 15 13:09:45 2005 |+++ sys/netinet/ip_input.c Sun Aug 21 10:49:56 2005 -------------------------- Patching file sys/netinet/ip_input.c using Plan A... Hunk #1 succeeded at 38 (offset 2 lines). Hunk #2 succeeded at 266 with fuzz 1 (offset -31 lines). done ASTest72RC2# patch -p0 < socketvar.h.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/sys/socketvar.h.orig Sat Jul 9 12:24:40 2005 |+++ sys/sys/socketvar.h Sun Aug 21 10:51:13 2005 -------------------------- Patching file sys/sys/socketvar.h using Plan A... Hunk #1 failed at 37. Hunk #2 succeeded at 367 (offset -197 lines). 1 out of 2 hunks failed--saving rejects to sys/sys/socketvar.h.rej done ASTest72RC2# patch -p0 < sys_conf_options.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/conf/options.orig Mon Aug 15 13:08:59 2005 |+++ sys/conf/options Sun Aug 21 10:52:38 2005 -------------------------- Patching file sys/conf/options using Plan A... Hunk #1 succeeded at 751 (offset 49 lines). done ASTest72RC2# patch -p0 < sys_i386_conf_GENERIC.patch sys_i386_conf_GENERIC.patch: No such file or directory. ASTest72RC2# >> >> Hi, >> >> Is there anyone knows how to compile keepalived from the port? >> >> Its patch only available up to version 7.0. >> When I followed its instruction to patch 4 files, 1 or 2 of those have >> been *rej*, and when I ignored and continue to build it, kernel >> compilation caused error. >> >> Is there a new keepalived patch for freebsd 7.1 and 7.2? >> >> Thanks >> >> > > Hi, this is what I encountered during make keepalived: > > ASTest72RC2# make > ===> Vulnerability check disabled, database not found > => keepalived-FreeBSD-1.1.11.tar.gz doesn't seem to exist in > /usr/ports/distfiles/. > => Attempting to fetch from > http://www.cultdeadsheep.org/~clement/FreeBSD/ipvs/. > keepalived-FreeBSD-1.1.11.tar.gz 100% of 208 kB 136 kBps > ===> Extracting for keepalived-1.1.11_1 > => MD5 Checksum OK for keepalived-FreeBSD-1.1.11.tar.gz. > => SHA256 Checksum OK for keepalived-FreeBSD-1.1.11.tar.gz. > ===> Patching for keepalived-1.1.11_1 > ===> Applying FreeBSD patches for keepalived-1.1.11_1 > ===> keepalived-1.1.11_1 depends on file: /usr/local/lib/libipvs.a - not > found > ===> Verifying install for /usr/local/lib/libipvs.a in > /usr/ports/net/ipvs > LVS on FreeBSD works only with 5.3-RELEASE and 5.4-RELEASE. > However it may work on 5-STABLE. If you are running FreeBSD 5.4-STABLE, > define > TRY_STABLE and check if patches apply correctly to your src tree > To build ipvs, I strongly encourage you to follow these instructions > 1. checkout supported src tree > 2. run "make patch-system" > 3. configure and build your kernel. (you need support of NetFilter > sockopt, add "options NF_SOCKOPT") > 4. Install your freshly compiled kernel > 5. install the port > 6. reboot your system > ===> Vulnerability check disabled, database not found > => ipvs-0.4.0_2.tar.gz doesn't seem to exist in /usr/ports/distfiles/. > => Attempting to fetch from > http://www.cultdeadsheep.org/~clement/FreeBSD/ipvs/. > ipvs-0.4.0_2.tar.gz 100% of 74 kB 51 kBps > ===> Extracting for ipvs-0.4.0_2 > => MD5 Checksum OK for ipvs-0.4.0_2.tar.gz. > => SHA256 Checksum OK for ipvs-0.4.0_2.tar.gz. > ===> Patching for ipvs-0.4.0_2 > ===> Configuring for ipvs-0.4.0_2 > ===> Building for ipvs-0.4.0_2 > ===> ipvs > Warning: Object directory not changed from original > /usr/ports/net/ipvs/work/ipvs-0.4.0_2/ipvs > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > ip_vs_core.c > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > ip_vs_conn.c > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > ip_vs_sched.c > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > ip_vs_ctl.c > ip_vs_ctl.c: In function 'do_ip_vs_set_ctl': > ip_vs_ctl.c:1257: warning: implicit declaration of function 'suser' > ip_vs_ctl.c:1257: warning: nested extern declaration of 'suser' > ip_vs_ctl.c: At top level: > ip_vs_ctl.c:1627: error: variable 'ip_vs_sockopts' has initializer but > incomplete type > ip_vs_ctl.c:1628: error: extra brace group at end of initializer > ip_vs_ctl.c:1628: error: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1628: warning: excess elements in struct initializer > ip_vs_ctl.c:1628: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1628: warning: excess elements in struct initializer > ip_vs_ctl.c:1628: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1629: warning: excess elements in struct initializer > ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1629: warning: excess elements in struct initializer > ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1629: warning: excess elements in struct initializer > ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1630: warning: excess elements in struct initializer > ip_vs_ctl.c:1630: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1630: warning: excess elements in struct initializer > ip_vs_ctl.c:1630: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1631: warning: excess elements in struct initializer > ip_vs_ctl.c:1631: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c: In function 'ip_vs_control_init': > ip_vs_ctl.c:1645: warning: implicit declaration of function > 'nf_register_sockopt' > ip_vs_ctl.c:1645: warning: nested extern declaration of > 'nf_register_sockopt' > ip_vs_ctl.c: In function 'ip_vs_control_cleanup': > ip_vs_ctl.c:1675: warning: implicit declaration of function > 'nf_unregister_sockopt' > ip_vs_ctl.c:1675: warning: nested extern declaration of > 'nf_unregister_sockopt' > *** Error code 1 > > Stop in /usr/ports/net/ipvs/work/ipvs-0.4.0_2/ipvs. > *** Error code 1 > > Stop in /usr/ports/net/ipvs/work/ipvs-0.4.0_2. > *** Error code 1 > > Stop in /usr/ports/net/ipvs. > *** Error code 1 > > Stop in /usr/ports/net/keepalived. > > Thanks > > > > From sam at ip6.com.au Sun May 3 09:10:40 2009 From: sam at ip6.com.au (Sam Wan) Date: Sun May 3 09:10:47 2009 Subject: How to complie keepliaved from Port. In-Reply-To: <25839.220.233.42.226.1241336988.squirrel@secure.ip6.com.au> References: <24472.220.233.42.226.1241324030.squirrel@secure.ip6.com.au> <25839.220.233.42.226.1241336988.squirrel@secure.ip6.com.au> Message-ID: <26864.220.233.42.226.1241341837.squirrel@secure.ip6.com.au> I have patched the following files, with some errors. Please provide suggestion about what I should do. Very appreciate for any suggestion. Thanks ASTest72RC2# patch -p0 < uipc_socket.c.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/kern/uipc_socket.c.orig Mon Aug 15 13:09:33 2005 |+++ sys/kern/uipc_socket.c Sun Aug 21 10:51:47 2005 -------------------------- Patching file sys/kern/uipc_socket.c using Plan A... Hunk #1 failed at 37. Hunk #2 succeeded at 1374 with fuzz 2 (offset 1309 lines). Hunk #3 succeeded at 1514 with fuzz 2 (offset -6 lines). patch: **** misordered hunks! output would be garbled ASTest72RC2# patch -p0 < ip_input.c.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/netinet/ip_input.c.orig Mon Aug 15 13:09:45 2005 |+++ sys/netinet/ip_input.c Sun Aug 21 10:49:56 2005 -------------------------- Patching file sys/netinet/ip_input.c using Plan A... Hunk #1 succeeded at 38 (offset 2 lines). Hunk #2 succeeded at 266 with fuzz 1 (offset -31 lines). done ASTest72RC2# patch -p0 < socketvar.h.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/sys/socketvar.h.orig Sat Jul 9 12:24:40 2005 |+++ sys/sys/socketvar.h Sun Aug 21 10:51:13 2005 -------------------------- Patching file sys/sys/socketvar.h using Plan A... Hunk #1 failed at 37. Hunk #2 succeeded at 367 (offset -197 lines). 1 out of 2 hunks failed--saving rejects to sys/sys/socketvar.h.rej done ASTest72RC2# patch -p0 < sys_conf_options.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/conf/options.orig Mon Aug 15 13:08:59 2005 |+++ sys/conf/options Sun Aug 21 10:52:38 2005 -------------------------- Patching file sys/conf/options using Plan A... Hunk #1 succeeded at 751 (offset 49 lines). done ASTest72RC2# patch -p0 < sys_i386_conf_GENERIC.patch sys_i386_conf_GENERIC.patch: No such file or directory. ASTest72RC2# >> >> Hi, >> >> Is there anyone knows how to compile keepalived from the port? >> >> Its patch only available up to version 7.0. >> When I followed its instruction to patch 4 files, 1 or 2 of those have >> been *rej*, and when I ignored and continue to build it, kernel >> compilation caused error. >> >> Is there a new keepalived patch for freebsd 7.1 and 7.2? >> >> Thanks >> >> > > Hi, this is what I encountered during make keepalived: > > ASTest72RC2# make > ===> Vulnerability check disabled, database not found > => keepalived-FreeBSD-1.1.11.tar.gz doesn't seem to exist in > /usr/ports/distfiles/. > => Attempting to fetch from > http://www.cultdeadsheep.org/~clement/FreeBSD/ipvs/. > keepalived-FreeBSD-1.1.11.tar.gz 100% of 208 kB 136 kBps > ===> Extracting for keepalived-1.1.11_1 > => MD5 Checksum OK for keepalived-FreeBSD-1.1.11.tar.gz. > => SHA256 Checksum OK for keepalived-FreeBSD-1.1.11.tar.gz. > ===> Patching for keepalived-1.1.11_1 > ===> Applying FreeBSD patches for keepalived-1.1.11_1 > ===> keepalived-1.1.11_1 depends on file: /usr/local/lib/libipvs.a - not > found > ===> Verifying install for /usr/local/lib/libipvs.a in > /usr/ports/net/ipvs > LVS on FreeBSD works only with 5.3-RELEASE and 5.4-RELEASE. > However it may work on 5-STABLE. If you are running FreeBSD 5.4-STABLE, > define > TRY_STABLE and check if patches apply correctly to your src tree > To build ipvs, I strongly encourage you to follow these instructions > 1. checkout supported src tree > 2. run "make patch-system" > 3. configure and build your kernel. (you need support of NetFilter > sockopt, add "options NF_SOCKOPT") > 4. Install your freshly compiled kernel > 5. install the port > 6. reboot your system > ===> Vulnerability check disabled, database not found > => ipvs-0.4.0_2.tar.gz doesn't seem to exist in /usr/ports/distfiles/. > => Attempting to fetch from > http://www.cultdeadsheep.org/~clement/FreeBSD/ipvs/. > ipvs-0.4.0_2.tar.gz 100% of 74 kB 51 kBps > ===> Extracting for ipvs-0.4.0_2 > => MD5 Checksum OK for ipvs-0.4.0_2.tar.gz. > => SHA256 Checksum OK for ipvs-0.4.0_2.tar.gz. > ===> Patching for ipvs-0.4.0_2 > ===> Configuring for ipvs-0.4.0_2 > ===> Building for ipvs-0.4.0_2 > ===> ipvs > Warning: Object directory not changed from original > /usr/ports/net/ipvs/work/ipvs-0.4.0_2/ipvs > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > ip_vs_core.c > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > ip_vs_conn.c > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > ip_vs_sched.c > cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 > -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param > inline-unit-growth=100 --param large-function-growth=1000 -fno-common > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > ip_vs_ctl.c > ip_vs_ctl.c: In function 'do_ip_vs_set_ctl': > ip_vs_ctl.c:1257: warning: implicit declaration of function 'suser' > ip_vs_ctl.c:1257: warning: nested extern declaration of 'suser' > ip_vs_ctl.c: At top level: > ip_vs_ctl.c:1627: error: variable 'ip_vs_sockopts' has initializer but > incomplete type > ip_vs_ctl.c:1628: error: extra brace group at end of initializer > ip_vs_ctl.c:1628: error: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1628: warning: excess elements in struct initializer > ip_vs_ctl.c:1628: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1628: warning: excess elements in struct initializer > ip_vs_ctl.c:1628: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1629: warning: excess elements in struct initializer > ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1629: warning: excess elements in struct initializer > ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1629: warning: excess elements in struct initializer > ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1630: warning: excess elements in struct initializer > ip_vs_ctl.c:1630: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1630: warning: excess elements in struct initializer > ip_vs_ctl.c:1630: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c:1631: warning: excess elements in struct initializer > ip_vs_ctl.c:1631: warning: (near initialization for 'ip_vs_sockopts') > ip_vs_ctl.c: In function 'ip_vs_control_init': > ip_vs_ctl.c:1645: warning: implicit declaration of function > 'nf_register_sockopt' > ip_vs_ctl.c:1645: warning: nested extern declaration of > 'nf_register_sockopt' > ip_vs_ctl.c: In function 'ip_vs_control_cleanup': > ip_vs_ctl.c:1675: warning: implicit declaration of function > 'nf_unregister_sockopt' > ip_vs_ctl.c:1675: warning: nested extern declaration of > 'nf_unregister_sockopt' > *** Error code 1 > > Stop in /usr/ports/net/ipvs/work/ipvs-0.4.0_2/ipvs. > *** Error code 1 > > Stop in /usr/ports/net/ipvs/work/ipvs-0.4.0_2. > *** Error code 1 > > Stop in /usr/ports/net/ipvs. > *** Error code 1 > > Stop in /usr/ports/net/keepalived. > > Thanks > > > > From gperez at entel.upc.edu Sun May 3 09:22:23 2009 From: gperez at entel.upc.edu (=?ISO-8859-1?Q?Gustau_P=E9rez?=) Date: Sun May 3 09:22:30 2009 Subject: Signal sensitivity problem with if_rum In-Reply-To: <3a142e750905020617y40f62463ma91b46a015b2b2ab@mail.gmail.com> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> <49FBF9B5.40800@entel.upc.edu> <3a142e750905020617y40f62463ma91b46a015b2b2ab@mail.gmail.com> Message-ID: <49FD61DD.7070903@entel.upc.edu> > That information is misleading, I remmember reading somewhere that linux rt73 > had similar problems like rum but it got fixed, and is not present in > new kernels. > I think that problem originated for linux from now obsolete drivers. > > On what linux version and what drivers version do you experience > similar problems > with signal sensitivity like with rum? > > Hi, I'm seeing this in ubuntu 9.04 (kernel 2.6.28). It shows more or less the same figures we have in FBSD. In linux, Bbp17 can be changed from userpace making iwconfig ${dev} bbp 17=0. But it automatically restores its previous value. Autotuning seems to be enable and I don't know how to disable it (the post I sent a few days ago about this is wrong or doesn't apply). Gus From sam at ip6.com.au Sun May 3 11:08:25 2009 From: sam at ip6.com.au (Sam Wan) Date: Sun May 3 11:08:33 2009 Subject: How to complie keepliaved from Port. In-Reply-To: <26864.220.233.42.226.1241341837.squirrel@secure.ip6.com.au> References: <24472.220.233.42.226.1241324030.squirrel@secure.ip6.com.au> <25839.220.233.42.226.1241336988.squirrel@secure.ip6.com.au> <26864.220.233.42.226.1241341837.squirrel@secure.ip6.com.au> Message-ID: <28239.220.233.42.226.1241348899.squirrel@secure.ip6.com.au> Hi, After switched over to FreeBSD 6.4, its compilation failed with a different error: ... linking kernel.debug ip_input.o(.text+0x200): In function `ip_init': ../../../netinet/ip_input.c:312: undefined reference to `nf_sockopt_init' *** Error code 1 ... This is what I have done before "make": ASTest64# patch -p0 < uipc_socket.c.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/kern/uipc_socket.c.orig Mon Aug 15 13:09:33 2005 |+++ sys/kern/uipc_socket.c Sun Aug 21 10:51:47 2005 -------------------------- Patching file sys/kern/uipc_socket.c using Plan A... Hunk #1 failed at 37. Hunk #2 succeeded at 966 with fuzz 2 (offset 901 lines). Hunk #3 succeeded at 638 (offset -882 lines). Hunk #4 succeeded at 2579 (offset 901 lines). Hunk #5 succeeded at 1015 (offset -870 lines). 1 out of 5 hunks failed--saving rejects to sys/kern/uipc_socket.c.rej done ASTest64# patch -p0 < ip_input.c.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/netinet/ip_input.c.orig Mon Aug 15 13:09:45 2005 |+++ sys/netinet/ip_input.c Sun Aug 21 10:49:56 2005 -------------------------- Patching file sys/netinet/ip_input.c using Plan A... Hunk #1 succeeded at 36. Hunk #2 succeeded at 308 (offset 11 lines). done ASTest64# patch -p0 < socketvar.h.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/sys/socketvar.h.orig Sat Jul 9 12:24:40 2005 |+++ sys/sys/socketvar.h Sun Aug 21 10:51:13 2005 -------------------------- Patching file sys/sys/socketvar.h using Plan A... Hunk #1 succeeded at 37. Hunk #2 succeeded at 562 (offset -2 lines). done ASTest64# patch -p0 < sys_conf_options.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- sys/conf/options.orig Tue Aug 16 01:31:55 2005 |+++ sys/conf/options Sun Aug 21 11:18:06 2005 -------------------------- Patching file sys/conf/options using Plan A... Hunk #1 succeeded at 718 (offset 17 lines). done ASTest64# Added options NF_SOCKOPT in ASTEST64 kernel config file. This file just copied from GENERIC file. then start compile: cd /usr/src/sys/arch/i386/conf; config GENERIC; cd ../compile/GENERIC; make depend; make; Your suggestion is highly appreciated. > > > I have patched the following files, with some errors. > Please provide suggestion about what I should do. > > Very appreciate for any suggestion. > > Thanks > > ASTest72RC2# patch -p0 < uipc_socket.c.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |--- sys/kern/uipc_socket.c.orig Mon Aug 15 13:09:33 2005 > |+++ sys/kern/uipc_socket.c Sun Aug 21 10:51:47 2005 > -------------------------- > Patching file sys/kern/uipc_socket.c using Plan A... > Hunk #1 failed at 37. > Hunk #2 succeeded at 1374 with fuzz 2 (offset 1309 lines). > Hunk #3 succeeded at 1514 with fuzz 2 (offset -6 lines). > patch: **** misordered hunks! output would be garbled > ASTest72RC2# patch -p0 < ip_input.c.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |--- sys/netinet/ip_input.c.orig Mon Aug 15 13:09:45 2005 > |+++ sys/netinet/ip_input.c Sun Aug 21 10:49:56 2005 > -------------------------- > Patching file sys/netinet/ip_input.c using Plan A... > Hunk #1 succeeded at 38 (offset 2 lines). > Hunk #2 succeeded at 266 with fuzz 1 (offset -31 lines). > done > ASTest72RC2# patch -p0 < socketvar.h.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |--- sys/sys/socketvar.h.orig Sat Jul 9 12:24:40 2005 > |+++ sys/sys/socketvar.h Sun Aug 21 10:51:13 2005 > -------------------------- > Patching file sys/sys/socketvar.h using Plan A... > Hunk #1 failed at 37. > Hunk #2 succeeded at 367 (offset -197 lines). > 1 out of 2 hunks failed--saving rejects to sys/sys/socketvar.h.rej > done > ASTest72RC2# patch -p0 < sys_conf_options.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |--- sys/conf/options.orig Mon Aug 15 13:08:59 2005 > |+++ sys/conf/options Sun Aug 21 10:52:38 2005 > -------------------------- > Patching file sys/conf/options using Plan A... > Hunk #1 succeeded at 751 (offset 49 lines). > done > ASTest72RC2# patch -p0 < sys_i386_conf_GENERIC.patch > sys_i386_conf_GENERIC.patch: No such file or directory. > ASTest72RC2# > >>> >>> Hi, >>> >>> Is there anyone knows how to compile keepalived from the port? >>> >>> Its patch only available up to version 7.0. >>> When I followed its instruction to patch 4 files, 1 or 2 of those have >>> been *rej*, and when I ignored and continue to build it, kernel >>> compilation caused error. >>> >>> Is there a new keepalived patch for freebsd 7.1 and 7.2? >>> >>> Thanks >>> >>> >> >> Hi, this is what I encountered during make keepalived: >> >> ASTest72RC2# make >> ===> Vulnerability check disabled, database not found >> => keepalived-FreeBSD-1.1.11.tar.gz doesn't seem to exist in >> /usr/ports/distfiles/. >> => Attempting to fetch from >> http://www.cultdeadsheep.org/~clement/FreeBSD/ipvs/. >> keepalived-FreeBSD-1.1.11.tar.gz 100% of 208 kB 136 kBps >> ===> Extracting for keepalived-1.1.11_1 >> => MD5 Checksum OK for keepalived-FreeBSD-1.1.11.tar.gz. >> => SHA256 Checksum OK for keepalived-FreeBSD-1.1.11.tar.gz. >> ===> Patching for keepalived-1.1.11_1 >> ===> Applying FreeBSD patches for keepalived-1.1.11_1 >> ===> keepalived-1.1.11_1 depends on file: /usr/local/lib/libipvs.a - >> not >> found >> ===> Verifying install for /usr/local/lib/libipvs.a in >> /usr/ports/net/ipvs >> LVS on FreeBSD works only with 5.3-RELEASE and 5.4-RELEASE. >> However it may work on 5-STABLE. If you are running FreeBSD 5.4-STABLE, >> define >> TRY_STABLE and check if patches apply correctly to your src tree >> To build ipvs, I strongly encourage you to follow these instructions >> 1. checkout supported src tree >> 2. run "make patch-system" >> 3. configure and build your kernel. (you need support of NetFilter >> sockopt, add "options NF_SOCKOPT") >> 4. Install your freshly compiled kernel >> 5. install the port >> 6. reboot your system >> ===> Vulnerability check disabled, database not found >> => ipvs-0.4.0_2.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> => Attempting to fetch from >> http://www.cultdeadsheep.org/~clement/FreeBSD/ipvs/. >> ipvs-0.4.0_2.tar.gz 100% of 74 kB 51 kBps >> ===> Extracting for ipvs-0.4.0_2 >> => MD5 Checksum OK for ipvs-0.4.0_2.tar.gz. >> => SHA256 Checksum OK for ipvs-0.4.0_2.tar.gz. >> ===> Patching for ipvs-0.4.0_2 >> ===> Configuring for ipvs-0.4.0_2 >> ===> Building for ipvs-0.4.0_2 >> ===> ipvs >> Warning: Object directory not changed from original >> /usr/ports/net/ipvs/work/ipvs-0.4.0_2/ipvs >> @ -> /usr/src/sys >> machine -> /usr/src/sys/i386/include >> cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 >> -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param >> inline-unit-growth=100 --param large-function-growth=1000 -fno-common >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx >> -mno-3dnow >> -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c >> ip_vs_core.c >> cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 >> -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param >> inline-unit-growth=100 --param large-function-growth=1000 -fno-common >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx >> -mno-3dnow >> -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c >> ip_vs_conn.c >> cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 >> -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param >> inline-unit-growth=100 --param large-function-growth=1000 -fno-common >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx >> -mno-3dnow >> -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c >> ip_vs_sched.c >> cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 >> -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param >> inline-unit-growth=100 --param large-function-growth=1000 -fno-common >> -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx >> -mno-3dnow >> -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c >> ip_vs_ctl.c >> ip_vs_ctl.c: In function 'do_ip_vs_set_ctl': >> ip_vs_ctl.c:1257: warning: implicit declaration of function 'suser' >> ip_vs_ctl.c:1257: warning: nested extern declaration of 'suser' >> ip_vs_ctl.c: At top level: >> ip_vs_ctl.c:1627: error: variable 'ip_vs_sockopts' has initializer but >> incomplete type >> ip_vs_ctl.c:1628: error: extra brace group at end of initializer >> ip_vs_ctl.c:1628: error: (near initialization for 'ip_vs_sockopts') >> ip_vs_ctl.c:1628: warning: excess elements in struct initializer >> ip_vs_ctl.c:1628: warning: (near initialization for 'ip_vs_sockopts') >> ip_vs_ctl.c:1628: warning: excess elements in struct initializer >> ip_vs_ctl.c:1628: warning: (near initialization for 'ip_vs_sockopts') >> ip_vs_ctl.c:1629: warning: excess elements in struct initializer >> ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') >> ip_vs_ctl.c:1629: warning: excess elements in struct initializer >> ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') >> ip_vs_ctl.c:1629: warning: excess elements in struct initializer >> ip_vs_ctl.c:1629: warning: (near initialization for 'ip_vs_sockopts') >> ip_vs_ctl.c:1630: warning: excess elements in struct initializer >> ip_vs_ctl.c:1630: warning: (near initialization for 'ip_vs_sockopts') >> ip_vs_ctl.c:1630: warning: excess elements in struct initializer >> ip_vs_ctl.c:1630: warning: (near initialization for 'ip_vs_sockopts') >> ip_vs_ctl.c:1631: warning: excess elements in struct initializer >> ip_vs_ctl.c:1631: warning: (near initialization for 'ip_vs_sockopts') >> ip_vs_ctl.c: In function 'ip_vs_control_init': >> ip_vs_ctl.c:1645: warning: implicit declaration of function >> 'nf_register_sockopt' >> ip_vs_ctl.c:1645: warning: nested extern declaration of >> 'nf_register_sockopt' >> ip_vs_ctl.c: In function 'ip_vs_control_cleanup': >> ip_vs_ctl.c:1675: warning: implicit declaration of function >> 'nf_unregister_sockopt' >> ip_vs_ctl.c:1675: warning: nested extern declaration of >> 'nf_unregister_sockopt' >> *** Error code 1 >> >> Stop in /usr/ports/net/ipvs/work/ipvs-0.4.0_2/ipvs. >> *** Error code 1 >> >> Stop in /usr/ports/net/ipvs/work/ipvs-0.4.0_2. >> *** Error code 1 >> >> Stop in /usr/ports/net/ipvs. >> *** Error code 1 >> >> Stop in /usr/ports/net/keepalived. >> >> Thanks >> >> >> >> > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From onemda at gmail.com Sun May 3 12:35:16 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sun May 3 12:35:22 2009 Subject: Signal sensitivity problem with if_rum In-Reply-To: <49FD61DD.7070903@entel.upc.edu> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> <49FBF9B5.40800@entel.upc.edu> <3a142e750905020617y40f62463ma91b46a015b2b2ab@mail.gmail.com> <49FD61DD.7070903@entel.upc.edu> Message-ID: <3a142e750905030535v4cfe0103r1d8a17e828f6da9b@mail.gmail.com> On 5/3/09, Gustau Perez wrote: > >> That information is misleading, I remmember reading somewhere that linux >> rt73 >> had similar problems like rum but it got fixed, and is not present in >> new kernels. >> I think that problem originated for linux from now obsolete drivers. >> >> On what linux version and what drivers version do you experience >> similar problems >> with signal sensitivity like with rum? >> >> > Hi, > > I'm seeing this in ubuntu 9.04 (kernel 2.6.28). It shows more or less > the same figures we have in FBSD. Try older versions, 8.X perhaps. Linux folks tends to break various things all the time ... > In linux, Bbp17 can be changed from userpace making iwconfig ${dev} > bbp 17=0. But it automatically restores its previous value. Autotuning > seems to be enable and I don't know how to disable it (the post I sent a > few days ago about this is wrong or doesn't apply). I dont belive that things are so much simple that changing only one bbp all the time will fix signal sensitivity. -- Paul From sam at ip6.com.au Sun May 3 12:43:29 2009 From: sam at ip6.com.au (Sam Wan) Date: Sun May 3 12:43:40 2009 Subject: Download 5.4 ISO file? Message-ID: <10229.220.233.42.226.1241354605.squirrel@secure.ip6.com.au> Hi, I want to download iso file of freebsd 5.4 release. Can anyone tell me a link? I want build a ipvs box in freebsd. Thanks From ertr1013 at student.uu.se Sun May 3 12:47:56 2009 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Sun May 3 12:48:03 2009 Subject: Download 5.4 ISO file? In-Reply-To: <10229.220.233.42.226.1241354605.squirrel@secure.ip6.com.au> References: <10229.220.233.42.226.1241354605.squirrel@secure.ip6.com.au> Message-ID: <20090503124748.GA24180@owl.midgard.homeip.net> On Sun, May 03, 2009 at 10:43:25PM +1000, Sam Wan wrote: > > Hi, > > I want to download iso file of freebsd 5.4 release. > Can anyone tell me a link? > > I want build a ipvs box in freebsd. > > Thanks > ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/ -- Erik Trulsson ertr1013@student.uu.se From Dieter.Brozio at t-online.de Sun May 3 13:05:42 2009 From: Dieter.Brozio at t-online.de (Dieter Brozio) Date: Sun May 3 13:05:48 2009 Subject: New INTEL firmware v3.1 for device iwi (IPW 2200BG) Message-ID: <49FD928D.4020504@t-online.de> Hi there, sorry for writing to the complete FBSD mailing list, but I don't know who is responsible for the WLAN iwi device firmware. To whom it may concern: INTEL released in March 2009 a new version 3.1 of its firmware version for the WLAN iwi device (Pro/Wireless 2200BG). http://ipw2200.sourceforge.net/firmware.php http://ipw2200.sourceforge.net/firmware.php?fid=8 On my 7.2.RC2 desktop PC (without WLAN) I noticed that in /usr/src/sys/contrib/dev/iwi/ipw2200_bss.fw.uu /usr/src/sys/contrib/dev/iwi/ipw2200_ibss.fw.uu /usr/src/sys/contrib/dev/iwi/ipw2200_sniffer.fw.uu is still the old v3.0 iwi firmware inside. This fw generates after some hours of operation error messages like "iwi0:scan stuck" and finally the network connection will be disconnected. I've tested fw v3.1 this week on my FBSD6.4 laptop: No problems, no "scan stuck", no side-effects. Brilliant. I think you should update FBSD 7.2 with fw v3.1 because maybe you can fix at least one of these bugs: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122597 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/123559 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/131153 I'm sorry that I'm unable to test iwi firmware v3.1 with FBSD 7.2 on my WLAN laptop, but at the moment I need the installed FBSD 6.4 on this PC. Anybody of you who can test iwi v3.1? Regards Dieter From thompsa at FreeBSD.org Sun May 3 15:57:52 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Sun May 3 15:58:00 2009 Subject: New INTEL firmware v3.1 for device iwi (IPW 2200BG) In-Reply-To: <49FD928D.4020504@t-online.de> References: <49FD928D.4020504@t-online.de> Message-ID: <20090503155746.GB11965@citylink.fud.org.nz> On Sun, May 03, 2009 at 02:48:13PM +0200, Dieter Brozio wrote: > Hi there, > > To whom it may concern: > > INTEL released in March 2009 a new version 3.1 of its firmware version for > the WLAN iwi device (Pro/Wireless 2200BG). > > http://ipw2200.sourceforge.net/firmware.php > http://ipw2200.sourceforge.net/firmware.php?fid=8 > > On my 7.2.RC2 desktop PC (without WLAN) I noticed that in > > /usr/src/sys/contrib/dev/iwi/ipw2200_bss.fw.uu > /usr/src/sys/contrib/dev/iwi/ipw2200_ibss.fw.uu > /usr/src/sys/contrib/dev/iwi/ipw2200_sniffer.fw.uu > > is still the old v3.0 iwi firmware inside. > > This fw generates after some hours of operation error messages like > "iwi0:scan stuck" and finally the network connection will be disconnected. > I've tested fw v3.1 this week on my FBSD6.4 laptop: No problems, no "scan > stuck", no side-effects. Brilliant. Great. If anyone can also confirm it works on current then I will commit. > I think you should update FBSD 7.2 with fw v3.1 because maybe you can fix > at least one of these bugs: The 7.2 images have been made so its too late, it can be merged to 7-stable and 7.3. Andrew From philipd at skysurfer.ca Sun May 3 20:50:03 2009 From: philipd at skysurfer.ca (Philip Drapeau) Date: Sun May 3 20:50:09 2009 Subject: kern/133218: [carp] [hang] use of carp(4) causes system to freeze Message-ID: <200905032050.n43Ko3fd033251@freefall.freebsd.org> The following reply was made to PR kern/133218; it has been noted by GNATS. From: "Philip Drapeau" To: , Cc: Subject: Re: kern/133218: [carp] [hang] use of carp(4) causes system to freeze Date: Sun, 3 May 2009 14:21:40 -0600 This is a multipart message in MIME format. ------=_NextPart_000_0001_01C9CBFA.7A4FEA50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good Afternoon, I have noted this bug has been sitting here in the open state for quite some time without any response. If this is due to any additional information being required from me I would be happy to provide it. ------=_NextPart_000_0001_01C9CBFA.7A4FEA50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good Afternoon,

 

I have noted this bug has been sitting here in the = open state for quite some time without any response. If this is due to any = additional information being required from me I would be happy to provide = it.

------=_NextPart_000_0001_01C9CBFA.7A4FEA50-- From rslaranjo at gmail.com Mon May 4 00:22:49 2009 From: rslaranjo at gmail.com (Rommel Laranjo) Date: Mon May 4 00:22:56 2009 Subject: Freebsd failed to create routing prefix In-Reply-To: <52471.86.212.66.201.1241304184.squirrel@webmail.esigetel.fr> References: <52471.86.212.66.201.1241304184.squirrel@webmail.esigetel.fr> Message-ID: Hello Jassal, Yes you are right, the problem will not occur if you put the ipv6 address at rc.conf and reboot. But, the problem I describe will occur only when if you change from Stateless IPv6 autoconfiguration to Static, without rebooting the machine. On Sun, May 3, 2009 at 6:43 AM, JASSAL Aman wrote: > Hello M.Laranjo > > The Kame stack for IPv6 should be working fine, whether you use stateless > autoconfiguration or static configuration. > > Since you want to use static configuration, my suggestion would be to > modify the /etc/rc.conf file so that your static configuration is loaded > everytime at boot. That way, you don't have to suppress the autoconfigured > address to reconfigure your static address afterwards. > > The lines you will need are : > > ipv6_enable="YES" > ipv6_network_interface="em0" > ipv6_ifconfig_em0="2001:db8:1234:abcd:20c:27ff:fe3d:63dd prefixlen 64" > ipv6_defaultrouter="2001:db8:1234:abcd::1" > > This should work. Please try to ping6 your router to see if everything is > working as it's supposed to. About your last question, I'm not 100% sure, > but I don't think FreeBSD will autoconfigure a route if you just add a > static ipv6 address on your interface... Unless you use a routing daemon > like routed. > > Kind regards > > > Aman Jassal > > > Le Sam 2 mai 2009 21:59, Rommel Laranjo a ?crit : >> Hello everyone, >> >> >> I need help. My box(Machine1) by default will perform IPv6 stateless >> autoconfiguration and I need to change this autoconfigured address to >> static manually without restarting. Here are the steps I follow but I sure >> I missed something cause I was >> unsuccessful of doing it. >> >> 1. I disabled sysctl knob to stop receiving rtadv >> # sysctl -w net.inet6.ip6.accept_rtadv=0 >> >> >> 2. I then removed the autoconfigured ipv6 address from the interface >> # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd delete >> >> >> 3. I removed the default ipv6 route since I will replace with another >> route # route delete -inet6 default >> >> >> 4. I then added the autoconfigured ipv6 address back to the interface to >> make it static # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd >> prefixlen 64 up >> >> 5. I added the new default ipv6 route >> # route add -inet6 default 2001:db8:1234:abcd::1 >> >> >> At this point I pinged 2001:db8:1234:abcd:20c:27ff:fe3d:63dd from another >> ?IPv6 box (Machine2) with IPv6 address of the same prefix >> (2001:db8:1234:abcd:215:d3ff:fe4f:acaf) but with no success. But if I >> ping6 from Machine2 to my router 2001:db8:1234:abcd::1 I am successfull. >> >> I tried to check IPv6 route information from Machine1 thru netstat -rnf >> inet6 but have not found this entry: >> >> 2001:db8:1234:abcd::/64 ? ? ? ? ? link#1 ? ? ? ? ? ? ? ? ? ? ? ?UC >> em0 >> >> I hope someone could shed light on how to put this route into my ipv6 >> routing table. Is this a bug in FreeBSD not to automatically add a routing >> prefix after changing from IPv6 stateless autoconfiguration to static IPv6 >> address ? >> >> Thanks, >> >> >> Romskie >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > > > From rslaranjo at gmail.com Mon May 4 00:31:23 2009 From: rslaranjo at gmail.com (Rommel Laranjo) Date: Mon May 4 00:31:30 2009 Subject: Freebsd failed to create routing prefix In-Reply-To: <20090503.081617.15105360.hrs@allbsd.org> References: <20090503.081617.15105360.hrs@allbsd.org> Message-ID: Hello Hiroki, Yes, my box has two NICs and I have these lines at my rc.conf. ipv6_enable="YES" ipv6_network_interfaces="AUTO" On Sun, May 3, 2009 at 7:16 AM, Hiroki Sato wrote: > Rommel Laranjo wrote > ?in : > > rs> I hope someone could shed light on how to put this route into my ipv6 > rs> routing table. > rs> Is this a bug in FreeBSD not to automatically add a routing prefix > rs> after changing from IPv6 stateless autoconfiguration to > rs> static IPv6 address ? > > ?It looks odd because that link should be added automatically at 4 in > ?your procedure regardless of whether you use the stateless autoconf. > ?BTW, does your system have multiple NICs? > > -- > | Hiroki SATO > From hrs at FreeBSD.org Mon May 4 01:38:52 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon May 4 01:38:58 2009 Subject: Freebsd failed to create routing prefix In-Reply-To: References: <20090503.081617.15105360.hrs@allbsd.org> Message-ID: <20090504.103743.232652487.hrs@allbsd.org> Rommel Laranjo wrote in : rs> Yes, my box has two NICs and I have these lines at my rc.conf. rs> rs> ipv6_enable="YES" rs> ipv6_network_interfaces="AUTO" Ah, from 7.1R there seems a regression of handling IPv6 link-level route on a system with multiple NICs and receiving RAs. When one NIC received an RA, another NIC's link-level route (i.e. marked as UC flag in netstat -r) is removed for some reason and it does not work even if the route is manually added after the removal (btw, you can add the route by using "route add -inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd/64 -interface em0 -cloning -nostatic"). Your procedure looks correct to me and it should work on 7.0R, but on both 7.1R and 7.2R it does not work at least. While I still have no idea about a workaround to this symptom at this moment, I think it will be fixed soon in the source tree. -- | Hiroki SATO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090504/f033de92/attachment.pgp From philipd at telus.net Mon May 4 02:40:04 2009 From: philipd at telus.net (Philip Drapeau) Date: Mon May 4 02:40:09 2009 Subject: kern/133218: [carp] [hang] use of carp(4) causes system to freeze Message-ID: <200905040240.n442e3ZB002727@freefall.freebsd.org> The following reply was made to PR kern/133218; it has been noted by GNATS. From: "Philip Drapeau" To: , Cc: Subject: Re: kern/133218: [carp] [hang] use of carp(4) causes system to freeze Date: Sun, 3 May 2009 20:09:16 -0600 I might also point out that any attempts to break into the kernel debugger at the console failed in each case where this happened. From rslaranjo at gmail.com Mon May 4 02:47:35 2009 From: rslaranjo at gmail.com (Rommel Laranjo) Date: Mon May 4 02:47:42 2009 Subject: Freebsd failed to create routing prefix In-Reply-To: <20090504.103743.232652487.hrs@allbsd.org> References: <20090503.081617.15105360.hrs@allbsd.org> <20090504.103743.232652487.hrs@allbsd.org> Message-ID: Hello Hiroki-san, The box I am using is FreeBSD 7.0-Release: # uname -a FreeBSD freebsd7.example.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 On Mon, May 4, 2009 at 9:37 AM, Hiroki Sato wrote: > Rommel Laranjo wrote > ?in : > > rs> Yes, my box has two NICs and I have these lines at my rc.conf. > rs> > rs> ipv6_enable="YES" > rs> ipv6_network_interfaces="AUTO" > > ?Ah, from 7.1R there seems a regression of handling IPv6 link-level > ?route on a system with multiple NICs and receiving RAs. ?When one NIC > ?received an RA, another NIC's link-level route (i.e. marked as UC > ?flag in netstat -r) is removed for some reason and it does not work > ?even if the route is manually added after the removal (btw, you can > ?add the route by using "route add -inet6 > ?2001:db8:1234:abcd:20c:27ff:fe3d:63dd/64 -interface em0 -cloning > ?-nostatic"). I tried this, and it add the expected route for the prefix: 2001:db8:1234:abcd::/64 link#1 UC em0 But when I pinged the router, I still got no success: # ping6 2001:db8:1234:abcd::fff2 PING6(56=40+8+8 bytes) 2001:db8:1234:abcd:20c:27ff:fe3d:63dd --> 2001:db8:1234:abcd::fff2 ping6: sendmsg: Invalid argument ping6: wrote 2001:db8:1234:abcd::fff2 16 chars, ret=-1 ping6: sendmsg: Invalid argument ping6: wrote 2001:db8:1234:abcd::fff2 16 chars, ret=-1 ^C --- 2001:db8:1234:abcd::fff2 ping6 statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss I also got this logged at the console: nd6_storelladdr: sdl_alen == 0 > > ?Your procedure looks correct to me and it should work on 7.0R, but on > ?both 7.1R and 7.2R it does not work at least. ?While I still have no > ?idea about a workaround to this symptom at this moment, I think it > ?will be fixed soon in the source tree. Thanks alot, Romskie From will at firepipe.net Mon May 4 04:03:07 2009 From: will at firepipe.net (Will Andrews) Date: Mon May 4 04:03:13 2009 Subject: CARP as a module; followup thoughts In-Reply-To: <49EF11E8.508@FreeBSD.org> References: <2aada3410904212216o128e1fdfx8c299b3531adc694@mail.gmail.com> <49EF11E8.508@FreeBSD.org> Message-ID: <2aada3410905032103g734e7025nad7f7b13137572ed@mail.gmail.com> On Wed, Apr 22, 2009 at 6:47 AM, Bruce M. Simpson wrote: > Hi, > > Will Andrews wrote: >> >> Hello, >> >> I've written a patch (against 8.0-CURRENT as of r191369) which makes >> it possible to build, load, run, & unload CARP as a module, using the >> GENERIC kernel. ?It can be obtained from: >> >> http://firepipe.net/patches/carp-as-module-20090421.diff >> > > There's no need to implement the in*_proto_register() stuff in that patch, > you should just be able to re-use the encap_attach_func() functions. Look at > how PIM is implemented in ip_mroute.c for an example. > > Other than that it looks like a good start... but would hold off on > committing as-is. the more general case of registering a MAC address on an > interface should be considered. Thank you very much for your feedback. I have implemented your suggestion as follows: http://firepipe.net/patches/carp-as-module-20090503-2.diff This version doesn't reinvent the wheel as far as registering the protocol goes. Personally, I think that notwithstanding your other objection, this should get committed, since it is a step in the right direction (perhaps minus the netinet6/in6_proto.c change that adds spacers). One step at a time! carp_encapcheck() is simplistic, but probably suffices (maybe also check to see if the vh MAC matches). This patch does work fine with my test setup, one system using GENERIC+if_carp and the other using a static build without the patch. I also found a "memory leak" in the original code, where it calls free(cif, M_IFADDR), which is wrong, it should be free(cif, M_CARP), since the original malloc uses M_CARP -- this fix is also included in the patch above. I've looked at the general case of registering a MAC address. I was going to try to include that change in this patch, but after reading the interface code for a while, I realized there isn't a general way to do that that seems settled. So it appears there needs to be a discussion on how to accomplish this. So, in struct ifnet, there is a field called if_addrhead which is a list of struct ifaddr's. This appears to be used for the general case of all addresses registered to a particular interface (AF_LINK aka lladdr's, plus AF_INET, AF_INET6, etc.). Now, we could use this with TAILQ_INSERT()'s for each virtual AF_LINK, and replace the applicable checks for "IF_LLADDR(ifp)" with a function that searches ifnet.if_addrhead for all AF_LINK entries and comparing the addresses to determine a match. Problem is, that's more O(n) than O(1), which is probably not acceptable. Perhaps a better way would be to replace ifnet.if_addrhead with a hash table for O(log n) search complexity, and possibly having separate hash tables for AF_LINK vs. other address families? Or maybe even one for each address family. That's probably overkill. There does seem to be a need to distinguish physical AF_LINKs from virtual though, since each physical interface driver uses IF_LLADDR(ifp) to refer to its physical address. Possibly ifaddr.ifa_flags could be used to make this distinction (though it seems to be used mainly for routing flags), but probably leave ifnet.if_addr as is for that purpose. Another way would be to have a separate list/hash table for virtual lladdr's (ifnet.ifvirt_lladdrhead?). I considered that but it seems better and more general to simply upgrade ifnet.if_addrhead. Regards, --Will. From gperez at entel.upc.edu Mon May 4 06:01:56 2009 From: gperez at entel.upc.edu (Gustavo Perez Querol) Date: Mon May 4 06:02:03 2009 Subject: Signal sensitivity problem with if_rum In-Reply-To: <3a142e750905030535v4cfe0103r1d8a17e828f6da9b@mail.gmail.com> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> <49FBF9B5.40800@entel.upc.edu> <3a142e750905020617y40f62463ma91b46a015b2b2ab@mail.gmail.com> <49FD61DD.7070903@entel.upc.edu> <3a142e750905030535v4cfe0103r1d8a17e828f6da9b@mail.gmail.com> Message-ID: <57348.147.83.40.234.1241416909.squirrel@webmail.entel.upc.edu> >> Hi, >> >> I'm seeing this in ubuntu 9.04 (kernel 2.6.28). It shows more or less >> the same figures we have in FBSD. > > Try older versions, 8.X perhaps. > Hi, I-m writing from a live ubuntu 8.04 right now. At work I have a Cisco Aironet 1200 (nice AP) and moving my dell latitude D630 laptop beside it shows the same figures. Signal quality of around 50 % in the best case. Here is what I get with direct view of the AP : Cell 02 - Address: 00:0E:D7:78:C3:60 ESSID:"eduroam-web" Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=50/100 Signal level=-58 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=000004116b6646b0 > Linux folks tends to break various things all the time ... Yes. That's why I don't like linux at all. > I dont belive that things are so much simple that changing only one bbp > all the time will fix signal sensitivity. > I do believe the same too. But I get lost because I'm not very used to wireless stuff. From oleg at freebsd.org Mon May 4 08:30:07 2009 From: oleg at freebsd.org (Oleg Bulyzhin) Date: Mon May 4 08:30:14 2009 Subject: kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression] Message-ID: <200905040830.n448U6uX013821@freefall.freebsd.org> The following reply was made to PR kern/134157; it has been noted by GNATS. From: Oleg Bulyzhin To: bug-followup@freebsd.org Cc: sid@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 -- oleg@rinet.ru === ================================================================ From bugmaster at FreeBSD.org Mon May 4 11:07:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 4 11:09:23 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200905041107.n44B7vav098727@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem o kern/132984 net [netgraph] swi1: net 100% cpu usage f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 298 problems total. From antonio.tommasi at unile.it Mon May 4 11:10:49 2009 From: antonio.tommasi at unile.it (Antonio Tommasi) Date: Mon May 4 11:11:34 2009 Subject: Filesystem and bigger files In-Reply-To: <57348.147.83.40.234.1241416909.squirrel@webmail.entel.upc.edu> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> <49FBF9B5.40800@entel.upc.edu> <3a142e750905020617y40f62463ma91b46a015b2b2ab@mail.gmail.com> <49FD61DD.7070903@entel.upc.edu> <3a142e750905030535v4cfe0103r1d8a17e828f6da9b@mail.gmail.com> <57348.147.83.40.234.1241416909.squirrel@webmail.entel.upc.edu> Message-ID: <49FEC893.8030305@unile.it> Hi to all, i've freebsd 7.0 in production and i've this hard-drive Filesystem Size Used Avail Capacity Mounted on /dev/aacd0s1a 64G 15G 44G 26% / In a directory (spamassassin) i've one file (auto-whitelist) with dimension 4.0 TB and one file (bayes_learn) with dimension 1.0TB How is it possible? How this file are managed? thanks Antonio From rea-fbsd at codelabs.ru Mon May 4 13:10:47 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon May 4 13:20:36 2009 Subject: Filesystem and bigger files In-Reply-To: <49FEC893.8030305@unile.it> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> <49FBF9B5.40800@entel.upc.edu> <3a142e750905020617y40f62463ma91b46a015b2b2ab@mail.gmail.com> <49FD61DD.7070903@entel.upc.edu> <3a142e750905030535v4cfe0103r1d8a17e828f6da9b@mail.gmail.com> <57348.147.83.40.234.1241416909.squirrel@webmail.entel.upc.edu> <49FEC893.8030305@unile.it> Message-ID: Antonio, good day. Mon, May 04, 2009 at 12:50:59PM +0200, Antonio Tommasi wrote: > i've freebsd 7.0 in production and i've this hard-drive > > Filesystem Size Used Avail Capacity Mounted on > /dev/aacd0s1a 64G 15G 44G 26% / > > In a directory (spamassassin) i've one file (auto-whitelist) with > dimension 4.0 TB and one file (bayes_learn) with dimension 1.0TB > > How is it possible? How this file are managed? First, this isn't a proper question for the freebsd-net mailing list, so I am redirecting it to freebsd-questions. To answer your question: most likely, your filesystem is damaged and should be fsck'ed. Reboot in a single-user mode and run 'fsck -p /dev/aacd0s1a' on your filesystem. If it will correct the things -- it's good. If not, run 'fsck /dev/aacd0s1a'. It is always good to have backups ;)) And the possible filesystem corruption is one of the reasons why people prefer multiple partitions on the system, rather then having one big and fat '/' partition. Another possibility is that these files are sparse: they have "holes" that aren't yet filled in. Tb sizes are insane, but may be you directed SA to do it. Here is the illustration of sparse file creation and its impact on the filesystem size: ----- Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad4s2f 24808094 14819988 8003460 65% /0 $ dd if=/dev/zero of=test.bin bs=1K count=1 seek=10M 1+0 records in 1+0 records out 1024 bytes transferred in 0.000049 secs (20951060 bytes/sec) $ ls -l test.bin -rw-r--r-- 1 usr usr 10737419264 4 ??? 16:54 test.bin $ df . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad4s2f 24808094 14820046 8003402 65% /0 ----- -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From sid at flytelecom.net Mon May 4 14:30:03 2009 From: sid at flytelecom.net (Andrey Golenischev) Date: Mon May 4 14:30:20 2009 Subject: kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression] Message-ID: <200905041430.n44EU3B2074229@freefall.freebsd.org> The following reply was made to PR kern/134157; it has been noted by GNATS. From: Andrey Golenischev To: Oleg Bulyzhin Cc: bug-followup@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 17:01:30 +0300 --0016364c758e62805c04691699de Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.pipe_byte_limit: 1048576 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.io_pkt_drop: 138100 net.inet.ip.dummynet.io_pkt_fast: 327270 net.inet.ip.dummynet.io_pkt: 19438906 net.inet.ip.dummynet.io_fast: 0 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: 21083 net.inet.ip.dummynet.tick_adjustment: 13986 net.inet.ip.dummynet.tick_delta_sum: 148 net.inet.ip.dummynet.tick_delta: 1 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.max_chain_len: 1024 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.search_steps: 0 net.inet.ip.dummynet.searches: 0 net.inet.ip.dummynet.extract_heap: 0 net.inet.ip.dummynet.ready_heap: 64 net.inet.ip.dummynet.curr_time: 3873537 net.inet.ip.dummynet.hash_size: 64 00010 pipe 1 ip from any to 10.3.1.6 out 00011 pipe 2 ip from 10.3.1.6 to any in 03008 pipe 3008 ip from any to any via ng4 in 03009 pipe 3009 ip from any to any via ng4 out 03020 pipe 3020 ip from any to any via ng10 in 03021 pipe 3021 ip from any to any via ng10 out 03030 pipe 3030 ip from any to any via ng15 in 03031 pipe 3031 ip from any to any via ng15 out 03032 pipe 3032 ip from any to any via ng16 in 03033 pipe 3033 ip from any to any via ng16 out 03034 pipe 3034 ip from any to any via ng17 in 03035 pipe 3035 ip from any to any via ng17 out 03036 pipe 3036 ip from any to any via ng18 in 03037 pipe 3037 ip from any to any via ng18 out 03038 pipe 3038 ip from any to any via ng19 in 03039 pipe 3039 ip from any to any via ng19 out 03040 pipe 3040 ip from any to any via ng20 in 03041 pipe 3041 ip from any to any via ng20 out 03042 pipe 3042 ip from any to any via ng21 in 03043 pipe 3043 ip from any to any via ng21 out 03044 pipe 3044 ip from any to any via ng22 in 03045 pipe 3045 ip from any to any via ng22 out 03046 pipe 3046 ip from any to any via ng23 in 03047 pipe 3047 ip from any to any via ng23 out 03048 pipe 3048 ip from any to any via ng24 in 03049 pipe 3049 ip from any to any via ng24 out 03050 pipe 3050 ip from any to any via ng25 in 03051 pipe 3051 ip from any to any via ng25 out 03052 pipe 3052 ip from any to any via ng26 in 03053 pipe 3053 ip from any to any via ng26 out 03054 pipe 3054 ip from any to any via ng27 in 03055 pipe 3055 ip from any to any via ng27 out 03056 pipe 3056 ip from any to any via ng28 in 03057 pipe 3057 ip from any to any via ng28 out 03058 pipe 3058 ip from any to any via ng29 in 03059 pipe 3059 ip from any to any via ng29 out 03060 pipe 3060 ip from any to any via ng30 in 03061 pipe 3061 ip from any to any via ng30 out 03062 pipe 3062 ip from any to any via ng31 in 03063 pipe 3063 ip from any to any via ng31 out 03064 pipe 3064 ip from any to any via ng32 in 03065 pipe 3065 ip from any to any via ng32 out 03066 pipe 3066 ip from any to any via ng33 in 03067 pipe 3067 ip from any to any via ng33 out 03068 pipe 3068 ip from any to any via ng34 in 03069 pipe 3069 ip from any to any via ng34 out 03070 pipe 3070 ip from any to any via ng35 in 03071 pipe 3071 ip from any to any via ng35 out 03072 pipe 3072 ip from any to any via ng36 in 03073 pipe 3073 ip from any to any via ng36 out 03074 pipe 3074 ip from any to any via ng37 in 03075 pipe 3075 ip from any to any via ng37 out 03078 pipe 3078 ip from any to any via ng39 in 03079 pipe 3079 ip from any to any via ng39 out 03080 pipe 3080 ip from any to any via ng40 in 03081 pipe 3081 ip from any to any via ng40 out 03082 pipe 3082 ip from any to any via ng41 in 03083 pipe 3083 ip from any to any via ng41 out 03084 pipe 3084 ip from any to any via ng42 in 03085 pipe 3085 ip from any to any via ng42 out 03086 pipe 3086 ip from any to any via ng43 in 03087 pipe 3087 ip from any to any via ng43 out 03088 pipe 3088 ip from any to any via ng44 in 03089 pipe 3089 ip from any to any via ng44 out 03090 pipe 3090 ip from any to any via ng45 in 03091 pipe 3091 ip from any to any via ng45 out 03092 pipe 3092 ip from any to any via ng46 in 03093 pipe 3093 ip from any to any via ng46 out 03094 pipe 3094 ip from any to any via ng47 in 03095 pipe 3095 ip from any to any via ng47 out 03096 pipe 3096 ip from any to any via ng48 in 03097 pipe 3097 ip from any to any via ng48 out 03098 pipe 3098 ip from any to any via ng49 in 03099 pipe 3099 ip from any to any via ng49 out 03100 pipe 3100 ip from any to any via ng50 in 03101 pipe 3101 ip from any to any via ng50 out 03102 pipe 3102 ip from any to any via ng51 in 03103 pipe 3103 ip from any to any via ng51 out 03104 pipe 3104 ip from any to any via ng52 in 03105 pipe 3105 ip from any to any via ng52 out 03106 pipe 3106 ip from any to any via ng53 in 03107 pipe 3107 ip from any to any via ng53 out 03108 pipe 3108 ip from any to any via ng54 in 03109 pipe 3109 ip from any to any via ng54 out 03110 pipe 3110 ip from any to any via ng55 in 03111 pipe 3111 ip from any to any via ng55 out 03112 pipe 3112 ip from any to any via ng56 in 03113 pipe 3113 ip from any to any via ng56 out 03114 pipe 3114 ip from any to any via ng57 in 03115 pipe 3115 ip from any to any via ng57 out 03118 pipe 3118 ip from any to any via ng59 in 03119 pipe 3119 ip from any to any via ng59 out 03120 pipe 3120 ip from any to any via ng60 in 03121 pipe 3121 ip from any to any via ng60 out 03122 pipe 3122 ip from any to any via ng61 in 03123 pipe 3123 ip from any to any via ng61 out 03124 pipe 3124 ip from any to any via ng62 in 03125 pipe 3125 ip from any to any via ng62 out 03126 pipe 3126 ip from any to any via ng63 in 03127 pipe 3127 ip from any to any via ng63 out 03128 pipe 3128 ip from any to any via ng64 in 03129 pipe 3129 ip from any to any via ng64 out 03130 pipe 3130 ip from any to any via ng65 in 03131 pipe 3131 ip from any to any via ng65 out 03134 pipe 3134 ip from any to any via ng67 in 03135 pipe 3135 ip from any to any via ng67 out 03136 pipe 3136 ip from any to any via ng68 in 03137 pipe 3137 ip from any to any via ng68 out 03138 pipe 3138 ip from any to any via ng69 in 03139 pipe 3139 ip from any to any via ng69 out 03140 pipe 3140 ip from any to any via ng70 in 03141 pipe 3141 ip from any to any via ng70 out 03142 pipe 3142 ip from any to any via ng71 in 03143 pipe 3143 ip from any to any via ng71 out 03144 pipe 3144 ip from any to any via ng72 in 03145 pipe 3145 ip from any to any via ng72 out 03146 pipe 3146 ip from any to any via ng73 in 03147 pipe 3147 ip from any to any via ng73 out 03148 pipe 3148 ip from any to any via ng74 in 03149 pipe 3149 ip from any to any via ng74 out 03150 pipe 3150 ip from any to any via ng75 in 03151 pipe 3151 ip from any to any via ng75 out 03152 pipe 3152 ip from any to any via ng76 in 03153 pipe 3153 ip from any to any via ng76 out 03154 pipe 3154 ip from any to any via ng77 in 03155 pipe 3155 ip from any to any via ng77 out 03156 pipe 3156 ip from any to any via ng78 in 03157 pipe 3157 ip from any to any via ng78 out 03158 pipe 3158 ip from any to any via ng79 in 03159 pipe 3159 ip from any to any via ng79 out 03162 pipe 3162 ip from any to any via ng81 in 03163 pipe 3163 ip from any to any via ng81 out 03600 pipe 3600 ip from any to any via ng300 in 03601 pipe 3601 ip from any to any via ng300 out 03604 pipe 3604 ip from any to any via ng302 in 03605 pipe 3605 ip from any to any via ng302 out 03606 pipe 3606 ip from any to any via ng303 in 03607 pipe 3607 ip from any to any via ng303 out 03610 pipe 3610 ip from any to any via ng305 in 03611 pipe 3611 ip from any to any via ng305 out 03612 pipe 3612 ip from any to any via ng306 in 03613 pipe 3613 ip from any to any via ng306 out 03614 pipe 3614 ip from any to any via ng307 in 03615 pipe 3615 ip from any to any via ng307 out 03628 pipe 3628 ip from any to any via ng314 in 03629 pipe 3629 ip from any to any via ng314 out 03630 pipe 3630 ip from any to any via ng315 in 03631 pipe 3631 ip from any to any via ng315 out 03632 pipe 3632 ip from any to any via ng316 in 03633 pipe 3633 ip from any to any via ng316 out 03634 pipe 3634 ip from any to any via ng317 in 03635 pipe 3635 ip from any to any via ng317 out 03636 pipe 3636 ip from any to any via ng318 in 03637 pipe 3637 ip from any to any via ng318 out 04000 pipe 4000 ip from any to any via ng500 in 04001 pipe 4001 ip from any to any via ng500 out 04002 pipe 4002 ip from any to any via ng501 in 04003 pipe 4003 ip from any to any via ng501 out 04004 pipe 4004 ip from any to any via ng502 in 04005 pipe 4005 ip from any to any via ng502 out 04006 pipe 4006 ip from any to any via ng503 in 04007 pipe 4007 ip from any to any via ng503 out 04008 pipe 4008 ip from any to any via ng504 in 04009 pipe 4009 ip from any to any via ng504 out 04010 pipe 4010 ip from any to any via ng505 in 04011 pipe 4011 ip from any to any via ng505 out 04012 pipe 4012 ip from any to any via ng506 in 04013 pipe 4013 ip from any to any via ng506 out 04014 pipe 4014 ip from any to any via ng507 in 04015 pipe 4015 ip from any to any via ng507 out 04016 pipe 4016 ip from any to any via ng508 in 04017 pipe 4017 ip from any to any via ng508 out 04018 pipe 4018 ip from any to any via ng509 in 04019 pipe 4019 ip from any to any via ng509 out 04020 pipe 4020 ip from any to any via ng510 in 04021 pipe 4021 ip from any to any via ng510 out 04022 pipe 4022 ip from any to any via ng511 in 04023 pipe 4023 ip from any to any via ng511 out 04024 pipe 4024 ip from any to any via ng512 in 04025 pipe 4025 ip from any to any via ng512 out 04026 pipe 4026 ip from any to any via ng513 in 04027 pipe 4027 ip from any to any via ng513 out 04028 pipe 4028 ip from any to any via ng514 in 04029 pipe 4029 ip from any to any via ng514 out 04400 pipe 4400 ip from any to any via ng700 in 04401 pipe 4401 ip from any to any via ng700 out 04402 pipe 4402 ip from any to any via ng701 in 04403 pipe 4403 ip from any to any via ng701 out 04404 pipe 4404 ip from any to any via ng702 in 04405 pipe 4405 ip from any to any via ng702 out 04406 pipe 4406 ip from any to any via ng703 in 04407 pipe 4407 ip from any to any via ng703 out 04408 pipe 4408 ip from any to any via ng704 in 04409 pipe 4409 ip from any to any via ng704 out 04410 pipe 4410 ip from any to any via ng705 in 04411 pipe 4411 ip from any to any via ng705 out 04600 pipe 4600 ip from any to any via ng800 in 04601 pipe 4601 ip from any to any via ng800 out 04602 pipe 4602 ip from any to any via ng801 in 04603 pipe 4603 ip from any to any via ng801 out 04604 pipe 4604 ip from any to any via ng802 in 04605 pipe 4605 ip from any to any via ng802 out 04606 pipe 4606 ip from any to any via ng803 in 04607 pipe 4607 ip from any to any via ng803 out 04608 pipe 4608 ip from any to any via ng804 in 04609 pipe 4609 ip from any to any via ng804 out 04610 pipe 4610 ip from any to any via ng805 in 04611 pipe 4611 ip from any to any via ng805 out 04612 pipe 4612 ip from any to any via ng806 in 04613 pipe 4613 ip from any to any via ng806 out 04614 pipe 4614 ip from any to any via ng807 in 04615 pipe 4615 ip from any to any via ng807 out 04616 pipe 4616 ip from any to any via ng808 in 04617 pipe 4617 ip from any to any via ng808 out 04618 pipe 4618 ip from any to any via ng809 in 04619 pipe 4619 ip from any to any via ng809 out 04620 pipe 4620 ip from any to any via ng810 in 04621 pipe 4621 ip from any to any via ng810 out 04622 pipe 4622 ip from any to any via ng811 in 04623 pipe 4623 ip from any to any via ng811 out 04624 pipe 4624 ip from any to any via ng812 in 04625 pipe 4625 ip from any to any via ng812 out 04626 pipe 4626 ip from any to any via ng813 in 04627 pipe 4627 ip from any to any via ng813 out 03161: 2.048 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail 04627: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.94.199/57696 1813 1297917 0 0 0 03628: 64.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.18/68 255.255.255.255/67 2521 325226 0 0 0 03144: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.7.25/35259 192.168.15.3/6667 5180 269334 0 0 0 03135: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 89.235.217.170/80 91.207.211.19/1156 80162 109010961 34 47155 8 04020: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.3.253/1046 91.122.4.219/443 188291 59501208 6 2937 0 03615: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 84.28.145.58/53692 10.0.97.203/4001 512 170122 0 0 0 03118: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.1.63/3296 195.170.253.18/31853 98014 94761482 5 6756 0 03101: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 194.67.52.35/80 10.0.96.101/3362 76999 33851654 0 0 0 03084: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.51/137 255.255.255.255/137 214071 10104235 0 0 0 04610: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.40/53576 192.168.1.5/53 739652 330523998 1 40 0 03060: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.157/137 255.255.255.255/137 21618 1232767 0 0 29 04606: 2.048 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail 04005: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 212.118.48.188/443 10.0.95.202/1413 12074 2183657 0 0 0 03045: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 77.120.100.50/80 10.0.97.98/63941 87652 109170411 0 0 0 04402: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.94.183/59747 60.162.216.56/10805 307600 36434569 0 0 0 03030: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.137/137 255.255.255.255/137 37952 2269182 0 0 0 03160: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.222/1041 239.255.255.250/1900 3 353 0 0 0 04626: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 169.254.221.222/137 174.133.30.162/137 1736 239785 0 0 0 03629: 64.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 212.1.105.107/0 10.0.100.18/0 2863 1668450 0 0 276 03145: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.94.161/1026 4452 1152669 0 0 0 03134: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 91.207.211.19/1156 89.235.217.170/80 42765 2429680 0 0 0 04021: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.94.13/1025 220509 234149378 45 44584 18190 03614: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 10.0.97.203/4000 79.71.101.249/443 813 70082 0 0 0 03119: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 195.170.253.18/80 10.0.99.47/3317 73231 32945401 2 1324 81 03100: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.7.122/3343 77.87.152.7/53706 104443 82970883 0 0 19 03085: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 194.67.52.35/80 10.0.100.51/4616 318435 436637048 0 0 493 04611: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 77.222.146.3/53 10.0.100.40/53576 916157 956110349 32 31221 34794 03061: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 194.67.52.35/80 10.0.95.157/1508 22714 3355506 0 0 2 04607: 2.048 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail 04004: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 10.0.95.202/1413 212.118.48.188/443 12504 584050 0 0 0 03044: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.0.101/63963 212.96.115.246/80 63891 4286942 0 0 0 04403: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 174.100.46.117/24750 10.0.94.183/59747 422594 524327547 36 42846 19464 03031: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 87.248.113.14/80 10.0.95.137/1064 49903 47094947 0 0 31 00001: 1.024 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail 03116: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.59/137 255.255.255.255/137 246 31643 0 0 0 03163: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 95.52.104.220/12268 10.0.99.111/51005 94962 115646351 18 24249 0 03630: 128.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.21/62538 224.0.0.252/5355 6185 609654 0 0 0 04625: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.97.32/63378 26461 26207214 0 0 36 03146: 64.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.131/137 255.255.255.255/137 1004 88804 0 0 0 04022: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.229/59907 224.0.0.252/5355 29899 1564786 0 0 0 03613: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.1.5/53 10.0.95.122/53807 6745 2758909 0 0 16 03103: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 91.205.206.19/51410 10.0.97.13/1100 293362 333305449 27 36960 4205 03086: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.7.135/2458 218.160.180.19/80 307236 21753758 0 0 0 04608: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.140/68 255.255.255.255/67 99719 5703556 0 0 0 03062: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.3.153/2856 87.105.184.222/443 74620 4206977 0 0 14 04007: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.96.107/61058 3456 2181918 0 0 0 03047: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.99.49/1030 6038 4316435 0 0 0 04604: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.72/49830 224.0.0.252/5355 78 11878 0 0 0 04400: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 10.0.99.160/0 192.168.1.5/0 566008 34519452 0 0 23 00002: 1.024 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail 03117: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 188.98.234.1/58185 10.0.99.59/1181 203 65199 0 0 0 03162: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.111/137 255.255.255.255/137 66614 24282436 0 0 0 03631: 128.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.100.21/56825 8900 1655969 0 0 8 04624: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.32/63378 91.205.206.19/53 22016 7483789 1 1400 0 03147: 64.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 72.14.221.99/80 10.0.100.131/3892 1907 500083 0 0 0 04023: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.99.229/57016 50204 72650659 30 4393= 7 456 03612: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.122/68 255.255.255.255/67 9401 840774 0 0 0 03102: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.13/137 255.255.255.255/137 196904 16029679 0 0 12 03087: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 72.20.5.58/80 10.0.97.56/2470 408715 465108360 46 49275 7684 04609: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.97.140/1046 111226 68734762 0 0 0 03063: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 209.85.129.102/80 10.0.96.39/2868 125501 165958671 0 0 1 04006: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.107/61058 91.205.206.19/53 3593 576429 0 0 0 03046: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.49/137 255.255.255.255/137 5707 978831 0 0 0 04605: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.95.72/52871 12 4873 0 0 0 04401: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 192.168.1.5/0 10.0.99.160/0 757375 210298025 0 0 1795 03611: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 221.1.204.243/80 10.0.99.79/1041 34394 41662588 46 6593= 5 1044 03148: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.188/137 255.255.255.255/137 8621 6018296 0 0 0 03131: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 93.184.71.27/80 10.0.94.88/3565 11093 6775973 0 0 0 03114: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.67/137 255.255.255.255/137 207018 132317142 0 0 0 04614: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 168.192.7.36/3560 89.74.9.73/443 10529 3331840 0 0 0 04016: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.94.185/2376 239.255.255.250/1900 123010 36074549 5 3100 0 03097: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 91.189.80.96/2710 10.0.97.169/1095 32783 1673544 0 0 0 04602: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.216/1044 92.112.107.205/38661 209085 179308298 0 0 60 03080: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.58/137 255.255.255.255/137 36699 2592903 0 0 0 04406: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.98/56642 239.255.255.250/3702 5097 921260 0 0 0 03056: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.94.81/137 255.255.255.255/137 3679 737163 0 0 0 03041: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.95.1/1027 13238 1335805 0 0 0 04001: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.100.35/54218 590902 773549213 28 41440 8627 03610: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.79/68 255.255.255.255/67 23222 2296047 0 0 0 03149: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 94.100.178.25/110 10.0.97.188/1766 4842 3697358 0 0 0 03130: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.94.88/137 255.255.255.255/137 10342 1105429 0 0 0 03115: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 188.16.87.85/59039 10.0.97.67/61423 218223 196119227 1 1396 12 04615: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 81.142.101.241/32693 10.0.100.170/3570 11983 7379671 0 0 25 04017: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.94.185/64211 149094 165068195 0 0 0 03096: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.169/137 255.255.255.255/137 54272 59507302 0 0 0 04603: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 92.112.107.205/38661 10.0.97.216/1044 147925 8737976 0 0 0 03081: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.99.58/1047 52588 66769217 0 0 93 04407: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.1.5/53 10.0.100.98/56311 5528 3825662 0 0 11 03057: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 80.190.154.74/80 10.0.94.81/7104 4397 3992559 0 0 0 03040: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.1/137 255.255.255.255/137 17713 1097320 0 0 0 04000: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.3.89/1451 212.40.34.149/80 358270 22623280 0 0 0 03129: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.99.118/1033 7827 8013549 0 0 371 03150: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.7/1575 239.255.255.250/1900 54861 4481144 0 0 0 03099: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 213.236.208.95/80 10.0.96.117/1136 731 263656 0 0 0 03112: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.65/137 255.255.255.255/137 11064 12934789 0 0 0 03009: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.99.136/52784 2864 1547945 0 0 0 04612: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.7.136/1031 65.55.52.148/443 23009 4110173 0 0 0 03082: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.245/4042 91.205.206.19/53 30838 2656816 0 0 0 03058: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.3.122/3454 213.196.229.88/12962 19447 3080195 0 0 0 03043: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 213.242.239.35/25121 10.0.97.8/10554 153121 18009070 0 0 0 04003: 64.000 Kbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail 04404: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.55/2049 91.205.206.19/53 4 270 0 0 0 04600: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.1.14/9744 94.100.179.197/80 39895 4776343 0 0 0 03128: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.118/1033 91.205.206.19/53 6524 677490 0 0 0 03151: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.1.3/53 10.0.95.7/1073 63501 79134462 0 0 9 03098: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 10.0.96.117/1136 213.236.208.95/80 788 139986 0 0 0 03113: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 89.188.115.202/80 10.0.95.65/3731 7111 360152 0 0 0 03008: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.136/52784 91.205.206.19/53 3541 649094 0 0 0 04613: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.99.195/63503 26198 22520467 0 0 94 03083: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.100.245/4042 29215 32894579 0 0 462 03059: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 72.14.221.103/80 10.0.96.132/3485 22047 20116818 0 0 2 03042: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.8/137 255.255.255.255/137 237648 286877975 19 22100 3 04002: 64.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 igmp 10.0.100.233/0 239.255.255.250/0 2 56 0 0 0 04405: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.95.55/2049 4 394 0 0 0 04601: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 94.100.179.197/80 10.0.100.199/9753 57248 63420309 0 0 302 04028: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.32/49646 224.0.0.252/5355 5483 344235 0 0 0 03153: 1.024 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail 03637: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 207.68.183.124/80 10.0.97.172/49158 23266 33355420 3 4440 39 03068: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.96/63293 192.168.1.3/53 4903 649933 0 0 0 03136: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.64/137 255.255.255.255/137 7704 399169 0 0 0 03127: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 91.207.4.106/80 10.0.99.200/3400 74878 6559522 0 0 0 04618: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.7.54/4656 92.237.100.124/31174 1336 168941 0 0 0 03110: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.186/68 255.255.255.255/67 254036 33466647 0 0 0 03093: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.100.60/58256 8862 2545480 0 0 0 04410: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.247/68 255.255.255.255/67 1173 267691 0 0 0 04013: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 77.37.171.86/443 10.0.96.162/3903 17249 4216575 0 0 0 03607: 1.024 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail 03053: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 10.0.100.119/0 10.0.100.119/0 8498 6791402 0 0 22 03038: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.55/137 255.255.255.255/137 25363 2011427 0 0 0 04029: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.96.32/55346 9056 12569836 45 61365 63 03152: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.94.59/137 255.255.255.255/137 24 3033 0 0 0 03636: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.172/55022 91.205.206.19/53 13201 771385 0 0 0 03069: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.1.3/53 10.0.95.96/63293 5868 4343191 0 0 140 03137: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 95.211.81.129/2106 10.0.97.64/1039 7615 1836016 0 0 0 03126: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.200/137 255.255.255.255/137 76248 10281497 0 0 0 04619: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 92.237.100.124/80 10.0.100.115/4667 1011 129754 0 0 0 03111: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 87.244.129.24/23097 10.0.96.186/4602 319846 394907876 33 43918 851 03092: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.3.115/64521 81.31.42.131/53 9356 1277032 0 0 0 04411: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.96.247/62013 1151 774200 0 0 0 04012: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.162/2522 55.52.141.173/23671 21380 3652757 0 0 0 03606: 1.024 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail 03052: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 10.0.100.119/0 10.0.100.119/0 6190 888434 0 0 0 03039: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 212.53.35.4/11024 10.0.99.55/4366 42306 54363062 0 0 69 03021: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 89.204.94.251/33225 10.0.97.209/63879 21942 12944771 0 0 143 03155: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.97.150/52174 5235 4799257 0 0 52 04616: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.7.94/1417 149.20.56.32/80 179642 75276327 4 5920 0 03138: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.207.211.16/2050 91.205.206.19/53 42 2568 0 0 0 03108: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.94.243/137 255.255.255.255/137 135607 8833682 0 0 0 03095: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.100.38/1464 7458 6478667 0 0 0 04015: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 24.60.95.205/17967 10.0.95.237/1613 50787 67125061 0 0 0 03078: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.138/137 255.255.255.255/137 90264 17269075 0 0 0 04408: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.94.10/1035 195.5.62.1/53 5808 1299286 0 0 0 03070: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.94.215/4424 239.255.255.250/1900 461364 296593091 8 3032 710 03055: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 129.215.14.66/1337 10.0.95.53/1327 29518 15040958 0 0 0 03036: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.51/68 255.255.255.255/67 531625 498693954 39 36881 11716 03605: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 192.168.1.5/0 10.0.100.137/0 4408 335920 0 0 0 03020: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 10.0.97.209/63879 89.204.94.251/33225 25239 12601570 0 0 0 03154: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.1.215/123 207.46.232.182/123 4506 749457 0 0 0 04617: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.96.125/1025 189949 174842357 22 24640 3339 03139: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 91.207.211.16/2050 25 1843 0 0 0 03109: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.1.3/53 10.0.94.243/64420 177066 215506499 0 0 127 03094: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.38/137 255.255.255.255/137 6347 1018291 0 0 0 04014: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.3.138/1602 216.188.226.88/80 41923 2811603 0 0 0 03079: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 207.46.232.182/123 10.0.99.138/123 122776 132736784 27 30916 387 04409: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 195.5.62.1/53 10.0.96.20/1036 6375 4026404 0 0 0 03071: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 79.97.185.5/51241 10.0.94.215/4429 505504 471866311 21 16332 4265 03054: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.53/137 255.255.255.255/137 26973 1461841 0 0 30 03037: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.96.51/3617 441673 243708662 0 0 0 03604: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 10.0.100.137/0 192.168.1.5/0 21470 23683560 0 0 0 03072: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.207.211.21/137 255.255.255.255/137 142 20957 0 0 0 04024: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.3.42/1047 91.10.234.83/443 353 40528 0 0 0 03633: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 85.127.231.33/3949 10.0.94.221/30229 88444 66439658 4 4480 0 03157: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 90.183.101.15/80 10.0.96.58/1963 21521 29543410 0 0 0 04622: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.101/64548 91.205.206.19/53 1812 232046 0 0 0 03140: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.11/137 255.255.255.255/137 15526 1341768 0 0 0 03123: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 192.168.1.3/53 10.0.95.177/1026 1263 177955 0 0 0 03106: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.99.82/137 255.255.255.255/137 10617 569156 0 0 0 03089: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.96.88/53236 81710 5542587 0 0 0 03064: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.66/137 255.255.255.255/137 23865 14264507 0 0 0 04009: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 212.120.229.183/52503 10.0.95.108/1799 435608 498744333 2 2960 15122 03049: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 64.12.200.89/5190 10.0.95.158/1064 125421 168876197 0 0 52 03034: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.252/68 255.255.255.255/67 428878 491880835 13 16792 2359 03073: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 91.207.204.83/0 91.207.211.21/0 138 81462 0 0 0 04025: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.100.79/1025 288 61473 0 0 0 03632: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.94.221/30229 85.127.231.33/3949 93060 52350948 0 0 0 03156: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.58/137 255.255.255.255/137 12934 596496 0 0 0 04623: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.100.101/64548 1709 728817 0 0 0 03141: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 208.43.153.2/0 10.0.96.11/0 24218 30083348 0 0 35 03122: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 192.168.3.231/1055 24.63.176.41/3175 2128 156036 0 0 0 03107: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 92.244.134.36/48944 10.0.99.82/62084 12975 1992339 0 0 0 03088: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.88/68 255.255.255.255/67 83770 4435548 0 0 116 03065: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.97.66/58153 15313 5100844 0 0 0 04008: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 10.0.95.108/1799 212.120.229.183/52503 338241 49051642 0 0 0 03048: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.158/68 255.255.255.255/67 69278 3764647 0 0 0 03035: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 62.205.236.20/13263 10.0.97.252/64601 285381 90591637 0 0 1 03017: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 99.249.82.105/80 10.0.100.211/2564 81 12108 0 0 0 04026: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 10.0.95.218/4921 153.102.113.117/19840 15007 6136216 0 0 0 03635: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 212.1.105.107/0 10.0.97.73/0 535 193208 0 0 0 03159: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 163.19.218.28/36728 10.0.97.234/49485 7088 3482791 0 0 0 03142: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.147/1099 239.255.255.250/1900 26907 2005706 0 0 0 03121: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 93.66.71.252/39894 10.0.96.5/35042 256955 274439627 6 7346 758 04620: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.51/63370 91.205.206.19/53 18985 1605280 0 0 0 03104: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 icmp 10.0.96.187/0 192.168.40.147/0 97755 4599119 0 0 0 03091: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 193.108.170.1/110 10.0.96.178/2058 13762 12454883 0 0 0 04011: 10.240 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.100.174/53562 5904 5863896 0 0 19 03074: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.44/137 255.255.255.255/137 20606 2593867 0 0 6 03066: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.213/68 255.255.255.255/67 54989 16102076 0 0 0 03051: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 91.207.211.17/1025 93 6024 0 0 0 03032: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.95.247/40298 95.57.153.37/64237 282373 174869068 2 1152 0 03601: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 74.125.87.18/80 10.0.100.134/2576 673714 636433379 19 22784 1965 03016: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.211/137 255.255.255.255/137 118 18691 0 0 0 04027: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 98.1.75.163/19248 10.0.95.218/4922 14275 10751781 0 0 0 03634: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.73/1035 239.255.255.250/1900 597 91268 0 0 0 03158: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.97.234/137 255.255.255.255/137 6922 390084 0 0 0 03143: 384.000 Kbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 81.19.70.1/80 10.0.100.147/1104 38528 43549114 20 24581 54 03120: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.5/35042 82.0.123.197/41656 169096 27322663 0 0 0 04621: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.97.51/63370 27900 23917035 0 0 36 03105: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.205.206.19/53 10.0.96.187/5136 159096 220368420 0 0 0 03090: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.96.178/68 255.255.255.255/67 12004 1747483 0 0 0 04010: 10.240 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.174/57618 224.0.0.252/5355 4810 581234 0 0 0 03075: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 131.111.33.242/63891 10.0.96.44/1079 23002 6952666 0 0 59 03067: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 74.125.77.147/80 10.0.95.213/1106 44306 28967429 0 0 39 03050: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 91.207.211.17/137 255.255.255.255/137 143 16614 0 0 0 03033: 1.024 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 tcp 91.205.206.19/61617 10.0.95.247/27881 144076 9954725 0 0 0 03600: 2.048 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp 0 udp 10.0.100.134/2572 239.255.255.250/1900 533990 377537021 2 1520 0 and so on. More online users, more ipfw rules and more pipes... On Mon, May 4, 2009 at 11:05 AM, Oleg Bulyzhin wrote: > > Please show sysctl net.inet.ip.dummynet output, your ipfw ruleset and > pipe configs. > > -- > Oleg. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru =3D=3D= =3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --=20 ---- =F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD, =E1=CE=C4=D2=C5=CA --0016364c758e62805c04691699de Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable
net.inet.ip.dummynet.debug: 0
net.inet.ip.dummynet.p= ipe_byte_limit:=20 1048576
net.inet.ip.dummynet.pipe_slot_limit:=20 100
net.inet.ip.dummynet.io_pkt_drop:=20 138100
net.inet.ip.dummynet.io_pkt_fast:=20 327270
net.inet.ip.dummynet.io_pkt: 19438906
net.inet.ip.dummynet.io_= fast:=20 0
net.inet.ip.dummynet.tick_lost: 0
net.inet.ip.dummynet.tick_diff:= =20 21083
net.inet.ip.dummynet.tick_adjustment:=20 13986
net.inet.ip.dummynet.tick_delta_sum:=20 148
net.inet.ip.dummynet.tick_delta:=20 1
net.inet.ip.dummynet.red_max_pkt_size:=20 1500
net.inet.ip.dummynet.red_avg_pkt_size:=20 512
net.inet.ip.dummynet.red_lookup_depth:=20 256
net.inet.ip.dummynet.max_chain_len: 1024
net.inet.ip.dummynet.exp= ire:=20 1
net.inet.ip.dummynet.search_steps: 0
net.inet.ip.dummynet.searches:= =20 0
net.inet.ip.dummynet.extract_heap: 0
net.inet.ip.dummynet.ready_hea= p:=20 64
net.inet.ip.dummynet.curr_time: 3873537
net.inet.ip.dummynet.hash_= size:=20 64


00010 pipe 1 ip from any to 1= 0.3.1.6 out
00011 pipe 2=20 ip from 10.3.1.6 to any in
03008 pipe 3008 ip from any to any via ng4=20 in
03009 pipe 3009 ip from any to any via ng4 out
03020 pipe 3020 ip = from=20 any to any via ng10 in
03021 pipe 3021 ip from any to any via ng10=20 out
03030 pipe 3030 ip from any to any via ng15 in
03031 pipe 3031 ip= from=20 any to any via ng15 out
03032 pipe 3032 ip from any to any via ng16=20 in
03033 pipe 3033 ip from any to any via ng16 out
03034 pipe 3034 ip= from=20 any to any via ng17 in
03035 pipe 3035 ip from any to any via ng17=20 out
03036 pipe 3036 ip from any to any via ng18 in
03037 pipe 3037 ip= from=20 any to any via ng18 out
03038 pipe 3038 ip from any to any via ng19=20 in
03039 pipe 3039 ip from any to any via ng19 out
03040 pipe 3040 ip= from=20 any to any via ng20 in
03041 pipe 3041 ip from any to any via ng20=20 out
03042 pipe 3042 ip from any to any via ng21 in
03043 pipe 3043 ip= from=20 any to any via ng21 out
03044 pipe 3044 ip from any to any via ng22=20 in
03045 pipe 3045 ip from any to any via ng22 out
03046 pipe 3046 ip= from=20 any to any via ng23 in
03047 pipe 3047 ip from any to any via ng23=20 out
03048 pipe 3048 ip from any to any via ng24 in
03049 pipe 3049 ip= from=20 any to any via ng24 out
03050 pipe 3050 ip from any to any via ng25=20 in
03051 pipe 3051 ip from any to any via ng25 out
03052 pipe 3052 ip= from=20 any to any via ng26 in
03053 pipe 3053 ip from any to any via ng26=20 out
03054 pipe 3054 ip from any to any via ng27 in
03055 pipe 3055 ip= from=20 any to any via ng27 out
03056 pipe 3056 ip from any to any via ng28=20 in
03057 pipe 3057 ip from any to any via ng28 out
03058 pipe 3058 ip= from=20 any to any via ng29 in
03059 pipe 3059 ip from any to any via ng29=20 out
03060 pipe 3060 ip from any to any via ng30 in
03061 pipe 3061 ip= from=20 any to any via ng30 out
03062 pipe 3062 ip from any to any via ng31=20 in
03063 pipe 3063 ip from any to any via ng31 out
03064 pipe 3064 ip= from=20 any to any via ng32 in
03065 pipe 3065 ip from any to any via ng32=20 out
03066 pipe 3066 ip from any to any via ng33 in
03067 pipe 3067 ip= from=20 any to any via ng33 out
03068 pipe 3068 ip from any to any via ng34=20 in
03069 pipe 3069 ip from any to any via ng34 out
03070 pipe 3070 ip= from=20 any to any via ng35 in
03071 pipe 3071 ip from any to any via ng35=20 out
03072 pipe 3072 ip from any to any via ng36 in
03073 pipe 3073 ip= from=20 any to any via ng36 out
03074 pipe 3074 ip from any to any via ng37=20 in
03075 pipe 3075 ip from any to any via ng37 out
03078 pipe 3078 ip= from=20 any to any via ng39 in
03079 pipe 3079 ip from any to any via ng39=20 out
03080 pipe 3080 ip from any to any via ng40 in
03081 pipe 3081 ip= from=20 any to any via ng40 out
03082 pipe 3082 ip from any to any via ng41=20 in
03083 pipe 3083 ip from any to any via ng41 out
03084 pipe 3084 ip= from=20 any to any via ng42 in
03085 pipe 3085 ip from any to any via ng42=20 out
03086 pipe 3086 ip from any to any via ng43 in
03087 pipe 3087 ip= from=20 any to any via ng43 out
03088 pipe 3088 ip from any to any via ng44=20 in
03089 pipe 3089 ip from any to any via ng44 out
03090 pipe 3090 ip= from=20 any to any via ng45 in
03091 pipe 3091 ip from any to any via ng45=20 out
03092 pipe 3092 ip from any to any via ng46 in
03093 pipe 3093 ip= from=20 any to any via ng46 out
03094 pipe 3094 ip from any to any via ng47=20 in
03095 pipe 3095 ip from any to any via ng47 out
03096 pipe 3096 ip= from=20 any to any via ng48 in
03097 pipe 3097 ip from any to any via ng48=20 out
03098 pipe 3098 ip from any to any via ng49 in
03099 pipe 3099 ip= from=20 any to any via ng49 out
03100 pipe 3100 ip from any to any via ng50=20 in
03101 pipe 3101 ip from any to any via ng50 out
03102 pipe 3102 ip= from=20 any to any via ng51 in
03103 pipe 3103 ip from any to any via ng51=20 out
03104 pipe 3104 ip from any to any via ng52 in
03105 pipe 3105 ip= from=20 any to any via ng52 out
03106 pipe 3106 ip from any to any via ng53=20 in
03107 pipe 3107 ip from any to any via ng53 out
03108 pipe 3108 ip= from=20 any to any via ng54 in
03109 pipe 3109 ip from any to any via ng54=20 out
03110 pipe 3110 ip from any to any via ng55 in
03111 pipe 3111 ip= from=20 any to any via ng55 out
03112 pipe 3112 ip from any to any via ng56=20 in
03113 pipe 3113 ip from any to any via ng56 out
03114 pipe 3114 ip= from=20 any to any via ng57 in
03115 pipe 3115 ip from any to any via ng57=20 out
03118 pipe 3118 ip from any to any via ng59 in
03119 pipe 3119 ip= from=20 any to any via ng59 out
03120 pipe 3120 ip from any to any via ng60=20 in
03121 pipe 3121 ip from any to any via ng60 out
03122 pipe 3122 ip= from=20 any to any via ng61 in
03123 pipe 3123 ip from any to any via ng61=20 out
03124 pipe 3124 ip from any to any via ng62 in
03125 pipe 3125 ip= from=20 any to any via ng62 out
03126 pipe 3126 ip from any to any via ng63=20 in
03127 pipe 3127 ip from any to any via ng63 out
03128 pipe 3128 ip= from=20 any to any via ng64 in
03129 pipe 3129 ip from any to any via ng64=20 out
03130 pipe 3130 ip from any to any via ng65 in
03131 pipe 3131 ip= from=20 any to any via ng65 out
03134 pipe 3134 ip from any to any via ng67=20 in
03135 pipe 3135 ip from any to any via ng67 out
03136 pipe 3136 ip= from=20 any to any via ng68 in
03137 pipe 3137 ip from any to any via ng68=20 out
03138 pipe 3138 ip from any to any via ng69 in
03139 pipe 3139 ip= from=20 any to any via ng69 out
03140 pipe 3140 ip from any to any via ng70=20 in
03141 pipe 3141 ip from any to any via ng70 out
03142 pipe 3142 ip= from=20 any to any via ng71 in
03143 pipe 3143 ip from any to any via ng71=20 out
03144 pipe 3144 ip from any to any via ng72 in
03145 pipe 3145 ip= from=20 any to any via ng72 out
03146 pipe 3146 ip from any to any via ng73=20 in
03147 pipe 3147 ip from any to any via ng73 out
03148 pipe 3148 ip= from=20 any to any via ng74 in
03149 pipe 3149 ip from any to any via ng74=20 out
03150 pipe 3150 ip from any to any via ng75 in
03151 pipe 3151 ip= from=20 any to any via ng75 out
03152 pipe 3152 ip from any to any via ng76=20 in
03153 pipe 3153 ip from any to any via ng76 out
03154 pipe 3154 ip= from=20 any to any via ng77 in
03155 pipe 3155 ip from any to any via ng77=20 out
03156 pipe 3156 ip from any to any via ng78 in
03157 pipe 3157 ip= from=20 any to any via ng78 out
03158 pipe 3158 ip from any to any via ng79=20 in
03159 pipe 3159 ip from any to any via ng79 out
03162 pipe 3162 ip= from=20 any to any via ng81 in
03163 pipe 3163 ip from any to any via ng81=20 out
03600 pipe 3600 ip from any to any via ng300 in
03601 pipe 3601 i= p=20 from any to any via ng300 out
03604 pipe 3604 ip from any to any via ng3= 02=20 in
03605 pipe 3605 ip from any to any via ng302 out
03606 pipe 3606 i= p=20 from any to any via ng303 in
03607 pipe 3607 ip from any to any via ng30= 3=20 out
03610 pipe 3610 ip from any to any via ng305 in
03611 pipe 3611 i= p=20 from any to any via ng305 out
03612 pipe 3612 ip from any to any via ng3= 06=20 in
03613 pipe 3613 ip from any to any via ng306 out
03614 pipe 3614 i= p=20 from any to any via ng307 in
03615 pipe 3615 ip from any to any via ng30= 7=20 out
03628 pipe 3628 ip from any to any via ng314 in
03629 pipe 3629 i= p=20 from any to any via ng314 out
03630 pipe 3630 ip from any to any via ng3= 15=20 in
03631 pipe 3631 ip from any to any via ng315 out
03632 pipe 3632 i= p=20 from any to any via ng316 in
03633 pipe 3633 ip from any to any via ng31= 6=20 out
03634 pipe 3634 ip from any to any via ng317 in
03635 pipe 3635 i= p=20 from any to any via ng317 out
03636 pipe 3636 ip from any to any via ng3= 18=20 in
03637 pipe 3637 ip from any to any via ng318 out
04000 pipe 4000 i= p=20 from any to any via ng500 in
04001 pipe 4001 ip from any to any via ng50= 0=20 out
04002 pipe 4002 ip from any to any via ng501 in
04003 pipe 4003 i= p=20 from any to any via ng501 out
04004 pipe 4004 ip from any to any via ng5= 02=20 in
04005 pipe 4005 ip from any to any via ng502 out
04006 pipe 4006 i= p=20 from any to any via ng503 in
04007 pipe 4007 ip from any to any via ng50= 3=20 out
04008 pipe 4008 ip from any to any via ng504 in
04009 pipe 4009 i= p=20 from any to any via ng504 out
04010 pipe 4010 ip from any to any via ng5= 05=20 in
04011 pipe 4011 ip from any to any via ng505 out
04012 pipe 4012 i= p=20 from any to any via ng506 in
04013 pipe 4013 ip from any to any via ng50= 6=20 out
04014 pipe 4014 ip from any to any via ng507 in
04015 pipe 4015 i= p=20 from any to any via ng507 out
04016 pipe 4016 ip from any to any via ng5= 08=20 in
04017 pipe 4017 ip from any to any via ng508 out
04018 pipe 4018 i= p=20 from any to any via ng509 in
04019 pipe 4019 ip from any to any via ng50= 9=20 out
04020 pipe 4020 ip from any to any via ng510 in
04021 pipe 4021 i= p=20 from any to any via ng510 out
04022 pipe 4022 ip from any to any via ng5= 11=20 in
04023 pipe 4023 ip from any to any via ng511 out
04024 pipe 4024 i= p=20 from any to any via ng512 in
04025 pipe 4025 ip from any to any via ng51= 2=20 out
04026 pipe 4026 ip from any to any via ng513 in
04027 pipe 4027 i= p=20 from any to any via ng513 out
04028 pipe 4028 ip from any to any via ng5= 14=20 in
04029 pipe 4029 ip from any to any via ng514 out
04400 pipe 4400 i= p=20 from any to any via ng700 in
04401 pipe 4401 ip from any to any via ng70= 0=20 out
04402 pipe 4402 ip from any to any via ng701 in
04403 pipe 4403 i= p=20 from any to any via ng701 out
04404 pipe 4404 ip from any to any via ng7= 02=20 in
04405 pipe 4405 ip from any to any via ng702 out
04406 pipe 4406 i= p=20 from any to any via ng703 in
04407 pipe 4407 ip from any to any via ng70= 3=20 out
04408 pipe 4408 ip from any to any via ng704 in
04409 pipe 4409 i= p=20 from any to any via ng704 out
04410 pipe 4410 ip from any to any via ng7= 05=20 in
04411 pipe 4411 ip from any to any via ng705 out
04600 pipe 4600 i= p=20 from any to any via ng800 in
04601 pipe 4601 ip from any to any via ng80= 0=20 out
04602 pipe 4602 ip from any to any via ng801 in
04603 pipe 4603 i= p=20 from any to any via ng801 out
04604 pipe 4604 ip from any to any via ng8= 02=20 in
04605 pipe 4605 ip from any to any via ng802 out
04606 pipe 4606 i= p=20 from any to any via ng803 in
04607 pipe 4607 ip from any to any via ng80= 3=20 out
04608 pipe 4608 ip from any to any via ng804 in
04609 pipe 4609 i= p=20 from any to any via ng804 out
04610 pipe 4610 ip from any to any via ng8= 05=20 in
04611 pipe 4611 ip from any to any via ng805 out
04612 pipe 4612 i= p=20 from any to any via ng806 in
04613 pipe 4613 ip from any to any via ng80= 6=20 out
04614 pipe 4614 ip from any to any via ng807 in
04615 pipe 4615 i= p=20 from any to any via ng807 out
04616 pipe 4616 ip from any to any via ng8= 08=20 in
04617 pipe 4617 ip from any to any via ng808 out
04618 pipe 4618 i= p=20 from any to any via ng809 in
04619 pipe 4619 ip from any to any via ng80= 9=20 out
04620 pipe 4620 ip from any to any via ng810 in
04621 pipe 4621 i= p=20 from any to any via ng810 out
04622 pipe 4622 ip from any to any via ng8= 11=20 in
04623 pipe 4623 ip from any to any via ng811 out
04624 pipe 4624 i= p=20 from any to any via ng812 in
04625 pipe 4625 ip from any to any via ng81= 2=20 out
04626 pipe 4626 ip from any to any via ng813 in
04627 pipe 4627 i= p=20 from any to any via ng813 out


03161:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 s= l. 0 queues (1=20 buckets) droptail
04627:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1= queues (1 buckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A 91.205.206.19/53=9A=9A= =9A=9A=9A=9A=9A 10.0.94.199/57696 = 1813=9A 1297917=9A 0=9A=9A=9A 0=9A=9A=20 0
03628:=9A 64.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets= ) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=9A=9A=20 10.0.100.18/68=9A=9A=9A 255.255.255.255/67=9A=9A=9A 2521=9A=9A 325226= =9A 0=9A=9A=9A 0=9A=9A 0
03144:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =20 192.168.7.25/35259=9A=9A=9A 192.168.15.3/6667=9A 5180=9A=9A 269334= =9A 0=9A=9A=9A 0=9A=9A 0
03135:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=20 89.235.217.170/80=9A=9A=9A=9A=9A <= a href=3D"http://91.207.211.19/1156">91.207.211.19/1156=9A 80162 109010= 961 34 47155=9A=9A=20 8
04020:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=20 192.168.3.253/1046=9A=9A=9A=9A 91.122.4.219/443=9A=9A 188291 5950120= 8=9A 6 2937=9A=9A=20 0
03615:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=9A=20 84.28.145.58/53692=9A=9A=9A=9A 10.0.97.203/4001=9A=9A 512=9A=9A 1701= 22=9A 0=9A=9A=9A 0=9A=9A 0
03118:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 192.168.1.63/3296=9A=9A 195.170.253.18/31853 98014 94761482=9A 5 = 6756=9A=9A 0
03101:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 194.67.52.35/80=9A=9A=9A=9A=9A=9A=9A= 10.0.96.101/3362=9A 76999 33851654= =9A 0=9A=9A=9A 0=9A=9A 0
03084:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.100.51/137=9A=9A 255.255.255.255/137=9A=9A 214071 10104235=9A 0= =9A=9A=9A 0=9A=9A 0
04610:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.100.40/53576=9A=9A=9A=9A 192.168.1.5/53=9A=9A=9A 739652 330523998= =9A 1=9A=9A 40=9A=9A 0
03060:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.95.157/137=9A=9A 255.255.255.255/137=9A=9A 21618=9A 1232767=9A = 0=9A=9A=9A 0=9A 29
04606:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 0 queues (1 buckets) droptail
04= 005:=9A=9A 1.024=20 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
=9A=9A= =9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=20 212.118.48.188/443=9A=9A=9A=9A=9A= =9A 10.0.95.202/1413=9A 12074=9A 21= 83657=9A 0=9A=9A=9A 0=9A=9A=20 0
03045:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=20 77.120.100.50/80=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.97.98/63941 87652 10917= 0411=9A 0=9A=9A=9A 0=9A=9A=20 0
04402:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=9A=9A=20 10.0.94.183/59747=9A=9A 60.162.216.56/10805 307600 36434569=9A 0= =9A=9A=9A 0=9A=9A 0
03030:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.95.137/137=9A=9A 255.255.255.255/137=9A=9A 37952=9A 2269182=9A = 0=9A=9A=9A 0=9A=9A 0
03160:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =20 10.0.100.222/1041=9A 239.255.255.250/1900=9A=9A=9A=9A 3=9A=9A=9A= =9A=9A 353=9A 0=9A=9A=9A 0=9A=9A 0
04626:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=20 169.254.221.222/137=9A=9A=9A 174.133.30.162/137=9A=9A 1736=9A=9A = 239785=9A 0=9A=9A=9A 0=9A=9A 0
03629:=9A=20 64.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 icmp=9A=9A=20 212.1.105.107/0=9A=9A=9A=9A=9A=9A=9A= =9A 10.0.100.18/0=9A=9A=9A=9A 2863=9A = 1668450=9A 0=9A=9A=9A 0 276
03145:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.94.161/1026=9A 4452=9A 115= 2669=9A 0=9A=9A=9A 0=9A=9A 0
03134:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 91.207.211.19/1156=9A=9A 89.235.217.170/80=9A=9A=9A 42765=9A 24296= 80=9A 0=9A=9A=9A 0=9A=9A 0
04021:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.94.13/1025=9A 220509 234= 149378 45 44584=20 18190
03614:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 b= uckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A=9A=9A=9A 10.0.97.203/4000= =9A=9A=9A 79.71.101.249/443=9A=9A= =9A 813=9A=9A=9A 70082=9A 0=9A=9A=9A 0=9A=9A=20 0
03119: 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) = droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=20 195.170.253.18/80=9A=9A=9A=9A=9A= =9A=9A=9A 10.0.99.47/3317=9A 73231 3= 2945401=9A 2 1324=9A=20 81
03100:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buck= ets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A=9A 192.168.7.122/3343= =9A=9A=9A=9A=9A 77.87.152.7/53706 = 104443 82970883=9A 0=9A=9A=9A 0=9A=20 19
03085:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buck= ets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A=9A=9A 194.67.52.35/80=9A= =9A=9A=9A=9A=9A=9A 10.0.100.51/4616= =9A 318435 436637048=9A 0=9A=9A=9A 0=20 493
04611:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buc= kets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A 77.222.146.3/53=9A= =9A=9A=9A=9A=9A=9A 10.0.100.40/53576 916157 956110349 32 31221=20 34794
03061:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 b= uckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A=9A=9A 194.67.52.35/80=9A= =9A=9A=9A=9A=9A=9A 10.0.95.157/1508= =9A 22714=9A 3355506=9A 0=9A=9A=9A 0=9A=9A=20 2
04607:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 0 queues (1 bucke= ts)=20 droptail
04004:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (= 1 buckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A=9A=9A=9A 10.0.95.202/1413= =9A=9A 212.118.48.188/443=9A=9A 1= 2504=9A=9A 584050=9A 0=9A=9A=9A 0=9A=9A=20 0
03044:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=20 192.168.0.101/63963=9A 212.96.115.246/80=9A=9A=9A 63891=9A 42869= 42=9A 0=9A=9A=9A 0=9A=9A 0
04403:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=20 174.100.46.117/24750=9A=9A=9A= =9A 10.0.94.183/59747 422594 52432= 7547 36 42846=20 19464
03031:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 b= uckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A=9A 87.248.113.14/80=9A=9A= =9A=9A=9A=9A=9A 10.0.95.137/1064=9A= 49903 47094947=9A 0=9A=9A=9A 0=9A=20 31
00001:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 0 queues (1 buck= ets)=20 droptail
03116:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (= 1 buckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A=9A 10.0.99.59/137= =9A=9A 255.255.255.255/137=9A=9A= =9A 246=9A=9A=9A 31643=9A 0=9A=9A=9A 0=9A=9A=20 0
03163:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=20 95.52.104.220/12268=9A=9A=9A=9A = 10.0.99.111/51005 94962 115646351 = 18 24249=9A=9A 0
03630:=20 128.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.100.21/62538=9A=9A=9A=9A 224.0.0.252/5355=9A 6185=9A=9A 609654= =9A 0=9A=9A=9A 0=9A=9A 0
04625:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.97.32/63378 26461 26207= 214=9A 0=9A=9A=9A 0=9A 36
03146:=9A=20 64.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =20 10.0.100.131/137=9A=9A 255.255.255.255/137=9A=9A 1004=9A=9A=9A 8880= 4=9A 0=9A=9A=9A 0=9A=9A 0
04022:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.99.229/59907=9A=9A=9A=9A 224.0.0.252/5355=9A 29899=9A 1564786=9A= 0=9A=9A=9A 0=9A=9A 0
03613:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 192.168.1.5/53=9A=9A=9A=9A=9A=9A=9A <= a href=3D"http://10.0.95.122/53807">10.0.95.122/53807 6745=9A 2758909= =9A 0=9A=9A=9A 0=9A 16
03103:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 91.205.206.19/51410=9A=9A=9A=9A= =9A 10.0.97.13/1100=9A 293362 333305= 449 27 36960=20 4205
03086:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bu= ckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A=9A 192.168.7.135/2458= =9A=9A 218.160.180.19/80=9A=9A=9A = 307236 21753758=9A 0=9A=9A=9A 0=9A=9A=20 0
04608:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=9A=9A=20 10.0.97.140/68=9A=9A=9A 255.255.255.255/67=9A=9A=9A 99719=9A 5703556= =9A 0=9A=9A=9A 0=9A=9A 0
03062:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 192.168.3.153/2856=9A=9A 87.105.184.222/443=9A=9A 74620=9A 420697= 7=9A 0=9A=9A=9A 0=9A 14
04007:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.96.107/61058 3456=9A 2181= 918=9A 0=9A=9A=9A 0=9A=9A 0
03047:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.99.49/1030=9A 6038=9A 43= 16435=9A 0=9A=9A=9A 0=9A=9A 0
04604:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.95.72/49830=9A=9A=9A=9A 224.0.0.252/5355=9A=9A=9A 78=9A=9A=9A 118= 78=9A 0=9A=9A=9A 0=9A=9A 0
04400:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 icmp=9A=9A=9A=9A= =20 10.0.99.160/0=9A=9A=9A=9A=9A=9A=9A=9A = 192.168.1.5/0=9A=9A=9A=9A 566008 34519= 452=9A 0=9A=9A=9A 0=9A 23
00002:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 0 queues (1 buckets) droptail
03= 117:=9A=9A 2.048=20 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
=9A=9A= =9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 188.98.234.1/58185=9A=9A=9A=9A=9A= 10.0.99.59/1181=9A=9A 203=9A=9A=9A = 65199=9A 0=9A=9A=9A 0=9A=9A 0
03162:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.99.111/137=9A=9A 255.255.255.255/137=9A=9A 66614 24282436=9A 0= =9A=9A=9A 0=9A=9A 0
03631:=20 128.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.100.21/56825 8900=9A 1655= 969=9A 0=9A=9A=9A 0=9A=9A 8
04624:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.97.32/63378=9A=9A 91.205.206.19/53=9A=9A=9A 22016=9A 7483789=9A 1= 1400=9A=9A 0
03147:=9A=20 64.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 72.14.221.99/80=9A=9A=9A=9A=9A=9A 10.0.100.131/3892=9A 1907=9A=9A 5000= 83=9A 0=9A=9A=9A 0=9A=9A 0
04023:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.99.229/57016 50204 726506= 59 30 43937=20 456
03612:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buc= kets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A 10.0.95.122/68=9A= =9A=9A 255.255.255.255/67=9A=9A= =9A 9401=9A=9A 840774=9A 0=9A=9A=9A 0=9A=9A=20 0
03102:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=9A=9A=9A=20 10.0.97.13/137=9A=9A 255.255.255.255/137=9A=9A 196904 16029679=9A 0= =9A=9A=9A 0=9A 12
03087:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =9A=9A=20 72.20.5.58/80=9A=9A=9A=9A=9A=9A=9A=9A = 10.0.97.56/2470=9A 408715 465108360 = 46 49275=20 7684
04609:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bu= ckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A 91.205.206.19/53=9A=9A= =9A=9A=9A=9A=9A 10.0.97.140/1046=9A= 111226 68734762=9A 0=9A=9A=9A 0=9A=9A=20 0
03063:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=20 209.85.129.102/80=9A=9A=9A=9A=9A= =9A=9A=9A 10.0.96.39/2868=9A 125501 = 165958671=9A 0=9A=9A=9A 0=9A=9A=20 1
04006:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=9A=9A=20 10.0.96.107/61058=9A=9A 91.205.206.19/53=9A=9A=9A 3593=9A=9A 576429= =9A 0=9A=9A=9A 0=9A=9A 0
03046:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.99.49/137=9A=9A 255.255.255.255/137=9A=9A 5707=9A=9A 978831=9A 0= =9A=9A=9A 0=9A=9A 0
04605:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.95.72/52871=9A=9A 12=9A= =9A=9A=9A 4873=9A 0=9A=9A=9A 0=9A=9A 0
04401:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 icmp=9A=9A=9A=9A= =20 192.168.1.5/0=9A=9A=9A=9A=9A=9A=9A=9A = 10.0.99.160/0=9A=9A=9A=9A 757375 21029= 8025=9A 0=9A=9A=9A 0 1795
03611:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 221.1.204.243/80=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.99.79/1041=9A 34394 4166= 2588 46 65935=20 1044
03148:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bu= ckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A 10.0.97.188/137= =9A=9A 255.255.255.255/137=9A=9A= 8621=9A 6018296=9A 0=9A=9A=9A 0=9A=9A=20 0
03131:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=9A=20 93.184.71.27/80=9A=9A=9A=9A=9A=9A=9A= =9A 10.0.94.88/3565=9A 11093=9A 6775= 973=9A 0=9A=9A=9A 0=9A=9A 0
03114:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.97.67/137=9A=9A 255.255.255.255/137=9A=9A 207018 132317142=9A 0= =9A=9A=9A 0=9A=9A 0
04614:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 168.192.7.36/3560=9A=9A=9A=9A=9A= =9A 89.74.9.73/443=9A=9A 10529=9A 333= 1840=9A 0=9A=9A=9A 0=9A=9A 0
04016:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.94.185/2376=9A 239.255.255.250/1900=9A 123010 36074549=9A 5 3= 100=9A=9A 0
03097:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 91.189.80.96/2710=9A=9A=9A=9A=9A <= a href=3D"http://10.0.97.169/1095">10.0.97.169/1095=9A 32783=9A 1673544= =9A 0=9A=9A=9A 0=9A=9A 0
04602:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.97.216/1044=9A=9A 92.112.107.205/38661 209085 179308298=9A 0= =9A=9A=9A 0=9A 60
03080:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.99.58/137=9A=9A 255.255.255.255/137=9A=9A 36699=9A 2592903=9A 0= =9A=9A=9A 0=9A=9A 0
04406:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.100.98/56642 239.255.255.250/3702=9A 5097=9A=9A 921260=9A 0= =9A=9A=9A 0=9A=9A 0
03056:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.94.81/137=9A=9A 255.255.255.255/137=9A=9A 3679=9A=9A 737163=9A 0= =9A=9A=9A 0=9A=9A 0
03041:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A=9A 10.0.95.1/1027=9A 13238=9A = 1335805=9A 0=9A=9A=9A 0=9A=9A 0
04001:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.100.35/54218 590902 77354= 9213 28 41440=20 8627
03610: 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucket= s)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A=9A 10.0.99.79/68=9A= =9A=9A 255.255.255.255/67=9A=9A= =9A 23222=9A 2296047=9A 0=9A=9A=9A 0=9A=9A=20 0
03149:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=20 94.100.178.25/110=9A=9A=9A=9A=9A= =9A 10.0.97.188/1766=9A 4842=9A 369= 7358=9A 0=9A=9A=9A 0=9A=9A 0
03130:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.94.88/137=9A=9A 255.255.255.255/137=9A=9A 10342=9A 1105429=9A 0= =9A=9A=9A 0=9A=9A 0
03115:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 188.16.87.85/59039=9A=9A=9A=9A=9A= 10.0.97.67/61423 218223 196119227= =9A 1 1396=9A=20 12
04615:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buck= ets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A 81.142.101.241/32693= =9A=9A=9A 10.0.100.170/3570=9A 119= 83=9A 7379671=9A 0=9A=9A=9A 0=9A=20 25
04017:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buck= ets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A 91.205.206.19/53=9A=9A= =9A=9A=9A=9A=9A 10.0.94.185/64211 = 149094 165068195=9A 0=9A=9A=9A 0=9A=9A=20 0
03096:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=9A=9A=20 10.0.97.169/137=9A=9A 255.255.255.255/137=9A=9A 54272 59507302=9A 0= =9A=9A=9A 0=9A=9A 0
04603:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=20 92.112.107.205/38661=9A=9A=9A= =9A 10.0.97.216/1044=9A 147925=9A 8= 737976=9A 0=9A=9A=9A 0=9A=9A 0
03081:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.99.58/1047=9A 52588 6676= 9217=9A 0=9A=9A=9A 0=9A 93
04407:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 192.168.1.5/53=9A=9A=9A=9A=9A=9A=9A <= a href=3D"http://10.0.100.98/56311">10.0.100.98/56311 5528=9A 3825662= =9A 0=9A=9A=9A 0=9A 11
03057:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 80.190.154.74/80=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.94.81/7104=9A 4397=9A 39= 92559=9A 0=9A=9A=9A 0=9A=9A 0
03040:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=9A=20 10.0.95.1/137=9A=9A 255.255.255.255/137=9A=9A 17713=9A 1097320=9A 0=9A= =9A=9A 0=9A=9A 0
04000:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 192.168.3.89/1451=9A=9A=9A 212.40.34.149/80=9A=9A=9A 358270 22623280= =9A 0=9A=9A=9A 0=9A=9A 0
03129:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.99.118/1033=9A 7827=9A 801= 3549=9A 0=9A=9A=9A 0 371
03150:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=9A=20 10.0.95.7/1575=9A 239.255.255.250/1900=9A 54861=9A 4481144=9A 0=9A= =9A=9A 0=9A=9A 0
03099:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=20 213.236.208.95/80=9A=9A=9A=9A=9A= =9A=9A 10.0.96.117/1136=9A=9A 731= =9A=9A 263656=9A 0=9A=9A=9A 0=9A=9A 0
03112:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.95.65/137=9A=9A 255.255.255.255/137=9A=9A 11064 12934789=9A 0=9A= =9A=9A 0=9A=9A 0
03009:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.99.136/52784 2864=9A 1547= 945=9A 0=9A=9A=9A 0=9A=9A 0
04612:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 192.168.7.136/1031=9A=9A=9A=9A 65.55.52.148/443=9A=9A 23009=9A 41101= 73=9A 0=9A=9A=9A 0=9A=9A 0
03082:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =20 10.0.100.245/4042=9A=9A=9A 91.205.206.19/53=9A=9A=9A 30838=9A 2656816= =9A 0=9A=9A=9A 0=9A=9A 0
03058:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 192.168.3.122/3454=9A=9A 213.196.229.88/12962 19447=9A 3080195= =9A 0=9A=9A=9A 0=9A=9A 0
03043:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=20 213.242.239.35/25121=9A=9A=9A= =9A=9A=9A 10.0.97.8/10554 153121 180= 09070=9A 0=9A=9A=9A 0=9A=9A=20 0
04003:=9A 64.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 0 queues (1 buckets= )=20 droptail
04404:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (= 1 buckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A=9A 10.0.95.55/2049=9A=9A=9A 91.205.206.19/53=9A=9A= =9A=9A=9A=9A 4=9A=9A=9A=9A=9A 270=9A 0=9A=9A=9A 0=9A=9A=20 0
04600:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=9A=20 192.168.1.14/9744=9A=9A 94.100.179.197/80=9A=9A=9A 39895=9A 4776343= =9A 0=9A=9A=9A 0=9A=9A 0
03128:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.99.118/1033=9A=9A=9A 91.205.206.19/53=9A=9A=9A 6524=9A=9A 67749= 0=9A 0=9A=9A=9A 0=9A=9A 0
03151:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 192.168.1.3/53=9A=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.95.7/1073=9A 63501 791344= 62=9A 0=9A=9A=9A 0=9A=9A 9
03098:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =9A=20 10.0.96.117/1136=9A=9A 213.236.208.95/80=9A=9A=9A=9A 788=9A=9A 139986= =9A 0=9A=9A=9A 0=9A=9A 0
03113:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=20 89.188.115.202/80=9A=9A=9A=9A=9A= =9A=9A=9A 10.0.95.65/3731=9A 7111=9A= =9A 360152=9A 0=9A=9A=9A 0=9A=9A 0
03008:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.99.136/52784=9A=9A 91.205.206.19/53=9A=9A=9A 3541=9A=9A 649094= =9A 0=9A=9A=9A 0=9A=9A 0
04613:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.99.195/63503 26198 225204= 67=9A 0=9A=9A=9A 0=9A 94
03083:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A = 10.0.100.245/4042=9A 29215 3289457= 9=9A 0=9A=9A=9A 0 462
03059:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 72.14.221.103/80=9A=9A=9A=9A=9A=9A= =9A 10.0.96.132/3485=9A 22047 20116= 818=9A 0=9A=9A=9A 0=9A=9A 2
03042:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=9A=20 10.0.97.8/137=9A=9A 255.255.255.255/137=9A=9A 237648 286877975 19 2210= 0=9A=9A 3
04002:=9A=20 64.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 igmp=9A=9A=9A=20 10.0.100.233/0=9A=9A=9A=9A 239.255.255.250/0=9A=9A=9A=9A=9A=9A=9A 2=9A= =9A=9A=9A=9A=9A 56=9A 0=9A=9A=9A 0=9A=9A 0
04405:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.95.55/2049=9A=9A=9A=9A 4= =9A=9A=9A=9A=9A 394=9A 0=9A=9A=9A 0=9A=9A 0
04601:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=20 94.100.179.197/80=9A=9A=9A=9A=9A= =9A 10.0.100.199/9753=9A 57248 634= 20309=9A 0=9A=9A=9A 0=20 302
04028:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buc= kets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A=9A 10.0.96.32/49646<= /a>=9A=9A=9A=9A 224.0.0.252/5355=9A= 5483=9A=9A 344235=9A 0=9A=9A=9A 0=9A=9A=20 0
03153:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 0 queues (1 bucke= ts)=20 droptail
03637:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (= 1 buckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A 207.68.183.124/80=9A=9A= =9A=9A=9A=9A=9A 10.0.97.172/49158 = 23266 33355420=9A 3 4440=9A=20 39
03068:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buck= ets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A=9A 10.0.95.96/63293<= /a>=9A=9A=9A=9A 192.168.1.3/53=9A=9A= =9A 4903=9A=9A 649933=9A 0=9A=9A=9A 0=9A=9A=20 0
03136:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=9A=9A=9A=20 10.0.97.64/137=9A=9A 255.255.255.255/137=9A=9A 7704=9A=9A 399169=9A 0= =9A=9A=9A 0=9A=9A 0
03127:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 91.207.4.106/80=9A=9A=9A=9A=9A=9A=9A= 10.0.99.200/3400=9A 74878=9A 65595= 22=9A 0=9A=9A=9A 0=9A=9A 0
04618:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 192.168.7.54/4656=9A=9A 92.237.100.124/31174 1336=9A=9A 168941=9A= 0=9A=9A=9A 0=9A=9A 0
03110:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.96.186/68=9A=9A=9A 255.255.255.255/67=9A=9A=9A 254036 33466647=9A= 0=9A=9A=9A 0=9A=9A 0
03093:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.100.60/58256 8862=9A 2545= 480=9A 0=9A=9A=9A 0=9A=9A 0
04410:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.96.247/68=9A=9A=9A 255.255.255.255/67=9A=9A=9A 1173=9A=9A 267691= =9A 0=9A=9A=9A 0=9A=9A 0
04013:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 77.37.171.86/443=9A=9A=9A=9A=9A=9A = 10.0.96.162/3903=9A 17249=9A 421657= 5=9A 0=9A=9A=9A 0=9A=9A 0
03607:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 0 queues (1 buckets) droptail
03= 053:=9A=9A 2.048=20 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
=9A=9A= =9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 icmp=9A=9A=9A=20 10.0.100.119/0=9A=9A=9A=9A=9A=9A=9A <= a href=3D"http://10.0.100.119/0">10.0.100.119/0=9A=9A=9A=9A 8498=9A 679= 1402=9A 0=9A=9A=9A 0=9A 22
03038:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.99.55/137=9A=9A 255.255.255.255/137=9A=9A 25363=9A 2011427=9A 0= =9A=9A=9A 0=9A=9A 0
04029:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.96.32/55346 9056 125698= 36 45 61365=9A 63
03152:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.94.59/137=9A=9A 255.255.255.255/137=9A=9A=9A=9A 24=9A=9A=9A=9A 3= 033=9A 0=9A=9A=9A 0=9A=9A 0
03636:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.97.172/55022=9A=9A 91.205.206.19/53=9A=9A=9A 13201=9A=9A 771385= =9A 0=9A=9A=9A 0=9A=9A 0
03069:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 192.168.1.3/53=9A=9A=9A=9A=9A=9A=9A= =9A 10.0.95.96/63293 5868=9A 434319= 1=9A 0=9A=9A=9A 0 140
03137:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 95.211.81.129/2106=9A=9A=9A=9A=9A= =9A 10.0.97.64/1039=9A 7615=9A 18360= 16=9A 0=9A=9A=9A 0=9A=9A 0
03126:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.99.200/137=9A=9A 255.255.255.255/137=9A=9A 76248 10281497=9A 0= =9A=9A=9A 0=9A=9A 0
04619:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=20 92.237.100.124/80=9A=9A=9A=9A=9A= =9A 10.0.100.115/4667=9A 1011=9A= =9A 129754=9A 0=9A=9A=9A 0=9A=9A 0
03111:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 87.244.129.24/23097=9A=9A=9A=9A = 10.0.96.186/4602=9A 319846 39490787= 6 33 43918=20 851
03092:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buc= kets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A 192.168.3.115/64521= =9A=9A=9A 81.31.42.131/53=9A=9A=9A 9= 356=9A 1277032=9A 0=9A=9A=9A 0=9A=9A=20 0
04411:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.96.247/62013 1151=9A=9A 7= 74200=9A 0=9A=9A=9A 0=9A=9A 0
04012:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.96.162/2522=9A=9A=9A 55.52.141.173/23671 21380=9A 3652757=9A= 0=9A=9A=9A 0=9A=9A 0
03606:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 0 queues (1 buckets) droptail
03= 052:=9A=9A 2.048=20 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
=9A=9A= =9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 icmp=9A=9A=9A=20 10.0.100.119/0=9A=9A=9A=9A=9A=9A=9A <= a href=3D"http://10.0.100.119/0">10.0.100.119/0=9A=9A=9A=9A 6190=9A=9A = 888434=9A 0=9A=9A=9A 0=9A=9A 0
03039:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =9A=20 212.53.35.4/11024=9A=9A=9A=9A=9A <= a href=3D"http://10.0.99.55/4366">10.0.99.55/4366=9A 42306 54363062=9A = 0=9A=9A=9A 0=9A 69
03021:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 89.204.94.251/33225=9A=9A=9A=9A = 10.0.97.209/63879 21942 12944771= =9A 0=9A=9A=9A 0 143
03155:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.97.150/52174 5235=9A 4799= 257=9A 0=9A=9A=9A 0=9A 52
04616:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 192.168.7.94/1417=9A=9A=9A=9A 149.20.56.32/80=9A=9A=9A 179642 75276327= =9A 4 5920=9A=9A 0
03138:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.207.211.16/2050=9A=9A=9A 91.205.206.19/53=9A=9A=9A=9A=9A 42=9A=9A= =9A=9A 2568=9A 0=9A=9A=9A 0=9A=9A 0
03108:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.94.243/137=9A=9A 255.255.255.255/137=9A=9A 135607=9A 8833682=9A= 0=9A=9A=9A 0=9A=9A 0
03095:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.100.38/1464=9A 7458=9A 647= 8667=9A 0=9A=9A=9A 0=9A=9A 0
04015:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 24.60.95.205/17967=9A=9A=9A=9A 10.0.95.237/1613=9A 50787 67125061=9A= 0=9A=9A=9A 0=9A=9A 0
03078:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.99.138/137=9A=9A 255.255.255.255/137=9A=9A 90264 17269075=9A 0= =9A=9A=9A 0=9A=9A 0
04408:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.94.10/1035=9A=9A=9A=9A=9A=9A 195.5.62.1/53=9A=9A=9A 5808=9A 1299286= =9A 0=9A=9A=9A 0=9A=9A 0
03070:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.94.215/4424=9A 239.255.255.250/1900=9A 461364 296593091=9A 8 = 3032 710
03055:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 129.215.14.66/1337=9A=9A=9A=9A=9A= =9A 10.0.95.53/1327=9A 29518 1504095= 8=9A 0=9A=9A=9A 0=9A=9A 0
03036:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.96.51/68=9A=9A=9A 255.255.255.255/67=9A=9A=9A 531625 498693954 39 = 36881=20 11716
03605:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 b= uckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 icmp=9A=9A=9A=9A 192.168.1.5/0=9A=9A= =9A=9A=9A=9A=9A 10.0.100.137/0=9A=9A= =9A=9A 4408=9A=9A 335920=9A 0=9A=9A=9A 0=9A=9A=20 0
03020:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=9A=9A=20 10.0.97.209/63879=9A=9A 89.204.94.251/33225 25239 12601570=9A 0=9A= =9A=9A 0=9A=9A 0
03154:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 192.168.1.215/123=9A=9A=9A 207.46.232.182/123=9A=9A 4506=9A=9A 7494= 57=9A 0=9A=9A=9A 0=9A=9A 0
04617:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.96.125/1025=9A 189949 1748= 42357 22 24640=20 3339
03139:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bu= ckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A 91.205.206.19/53=9A=9A= =9A=9A=9A 91.207.211.16/2050=9A= =9A=9A 25=9A=9A=9A=9A 1843=9A 0=9A=9A=9A 0=9A=9A=20 0
03109:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=9A=9A=20 192.168.1.3/53=9A=9A=9A=9A=9A=9A=9A <= a href=3D"http://10.0.94.243/64420">10.0.94.243/64420 177066 215506499= =9A 0=9A=9A=9A 0 127
03094:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.100.38/137=9A=9A 255.255.255.255/137=9A=9A 6347=9A 1018291=9A 0= =9A=9A=9A 0=9A=9A 0
04014:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 192.168.3.138/1602=9A=9A 216.188.226.88/80=9A=9A=9A 41923=9A 28116= 03=9A 0=9A=9A=9A 0=9A=9A 0
03079:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=20 207.46.232.182/123=9A=9A=9A=9A=9A= =9A 10.0.99.138/123=9A=9A 122776 132= 736784 27 30916=20 387
04409:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buc= kets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A=9A 195.5.62.1/53=9A= =9A=9A=9A=9A=9A=9A=9A 10.0.96.20/1036=9A 6375=9A 4026404=9A 0=9A=9A=9A 0=9A=9A=20 0
03071:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=9A=9A=20 79.97.185.5/51241=9A=9A=9A=9A 10.0.94.215/4429=9A 505504 471866311 21= 16332=20 4265
03054:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bu= ckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A=9A 10.0.95.53/137= =9A=9A 255.255.255.255/137=9A=9A= 26973=9A 1461841=9A 0=9A=9A=9A 0=9A=20 30
03037:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buck= ets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A 91.205.206.19/53=9A=9A= =9A=9A=9A=9A=9A=9A 10.0.96.51/3617= =9A 441673 243708662=9A 0=9A=9A=9A 0=9A=9A=20 0
03604:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 icmp= =9A=9A=9A=20 10.0.100.137/0=9A=9A=9A=9A=9A=9A=9A= =9A 192.168.1.5/0=9A=9A=9A=9A 21470 23= 683560=9A 0=9A=9A=9A 0=9A=9A 0
03072:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.207.211.21/137=9A=9A 255.255.255.255/137=9A=9A=9A 142=9A=9A=9A = 20957=9A 0=9A=9A=9A 0=9A=9A 0
04024:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 192.168.3.42/1047=9A=9A=9A=9A 91.10.234.83/443=9A=9A=9A 353=9A=9A=9A = 40528=9A 0=9A=9A=9A 0=9A=9A 0
03633:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 85.127.231.33/3949=9A=9A=9A=9A=9A= 10.0.94.221/30229 88444 66439658= =9A 4 4480=9A=9A 0
03157:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 90.183.101.15/80=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.96.58/1963=9A 21521 2954= 3410=9A 0=9A=9A=9A 0=9A=9A 0
04622:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =20 10.0.100.101/64548=9A=9A 91.205.206.19/53=9A=9A=9A 1812=9A=9A 23204= 6=9A 0=9A=9A=9A 0=9A=9A 0
03140:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.96.11/137=9A=9A 255.255.255.255/137=9A=9A 15526=9A 1341768=9A 0= =9A=9A=9A 0=9A=9A 0
03123:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 192.168.1.3/53=9A=9A=9A=9A=9A=9A=9A <= a href=3D"http://10.0.95.177/1026">10.0.95.177/1026=9A 1263=9A=9A 17795= 5=9A 0=9A=9A=9A 0=9A=9A 0
03106:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.99.82/137=9A=9A 255.255.255.255/137=9A=9A 10617=9A=9A 569156=9A = 0=9A=9A=9A 0=9A=9A 0
03089:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.96.88/53236 81710=9A 55= 42587=9A 0=9A=9A=9A 0=9A=9A 0
03064:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.97.66/137=9A=9A 255.255.255.255/137=9A=9A 23865 14264507=9A 0=9A= =9A=9A 0=9A=9A 0
04009:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=20 212.120.229.183/52503=9A=9A=9A= =9A 10.0.95.108/1799=9A 435608 4987= 44333=9A 2 2960=20 15122
03049:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 b= uckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A=9A=9A 64.12.200.89/5190= =9A=9A=9A=9A=9A 10.0.95.158/1064=9A= 125421 168876197=9A 0=9A=9A=9A 0=9A=20 52
03034:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buck= ets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A 10.0.97.252/68=9A= =9A=9A 255.255.255.255/67=9A=9A= =9A 428878 491880835 13 16792=20 2359
03073:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bu= ckets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 icmp=9A=9A 91.207.204.83/0=9A=9A=9A= =9A=9A=9A 91.207.211.21/0=9A=9A=9A= =9A=9A 138=9A=9A=9A 81462=9A 0=9A=9A=9A 0=9A=9A=20 0
04025: 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) = droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.100.79/1025=9A=9A 288=9A= =9A=9A 61473=9A 0=9A=9A=9A 0=9A=9A 0
03632:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.94.221/30229=9A=9A 85.127.231.33/3949=9A 93060 52350948=9A 0= =9A=9A=9A 0=9A=9A 0
03156:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.96.58/137=9A=9A 255.255.255.255/137=9A=9A 12934=9A=9A 596496=9A = 0=9A=9A=9A 0=9A=9A 0
04623:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A = 10.0.100.101/64548 1709=9A=9A 728= 817=9A 0=9A=9A=9A 0=9A=9A 0
03141:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 icmp=9A=9A=9A=20 208.43.153.2/0=9A=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.96.11/0=9A=9A=9A=9A 24218 3= 0083348=9A 0=9A=9A=9A 0=9A 35
03122:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 192.168.3.231/1055=9A=9A=9A=9A 24.63.176.41/3175=9A 2128=9A=9A 1560= 36=9A 0=9A=9A=9A 0=9A=9A 0
03107:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 92.244.134.36/48944=9A=9A=9A=9A= =9A 10.0.99.82/62084 12975=9A 19923= 39=9A 0=9A=9A=9A 0=9A=9A 0
03088:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.96.88/68=9A=9A=9A 255.255.255.255/67=9A=9A=9A 83770=9A 4435548=9A = 0=9A=9A=9A 0 116
03065:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.97.66/58153 15313=9A 51= 00844=9A 0=9A=9A=9A 0=9A=9A 0
04008:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =9A=20 10.0.95.108/1799=9A 212.120.229.183/52503 338241 49051642=9A 0=9A= =9A=9A 0=9A=9A 0
03048:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.95.158/68=9A=9A=9A 255.255.255.255/67=9A=9A=9A 69278=9A 3764647= =9A 0=9A=9A=9A 0=9A=9A 0
03035:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 62.205.236.20/13263=9A=9A=9A=9A = 10.0.97.252/64601 285381 90591637= =9A 0=9A=9A=9A 0=9A=9A 1
03017:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 99.249.82.105/80=9A=9A=9A=9A=9A=9A = 10.0.100.211/2564=9A=9A=9A 81=9A= =9A=9A 12108=9A 0=9A=9A=9A 0=9A=9A 0
04026:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =9A=20 10.0.95.218/4921=9A 153.102.113.117/19840 15007=9A 6136216=9A 0= =9A=9A=9A 0=9A=9A 0
03635:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 icmp=9A=9A=20 212.1.105.107/0=9A=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.97.73/0=9A=9A=9A=9A=9A 535= =9A=9A 193208=9A 0=9A=9A=9A 0=9A=9A 0
03159:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 163.19.218.28/36728=9A=9A=9A=9A = 10.0.97.234/49485 7088=9A 3482791= =9A 0=9A=9A=9A 0=9A=9A 0
03142:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =20 10.0.100.147/1099=9A 239.255.255.250/1900=9A 26907=9A 2005706=9A = 0=9A=9A=9A 0=9A=9A 0
03121:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =20 93.66.71.252/39894=9A=9A=9A=9A=9A= =9A 10.0.96.5/35042 256955 274439627= =9A 6 7346=20 758
04620:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buc= kets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A=9A=9A 10.0.97.51/63370<= /a>=9A=9A 91.205.206.19/53=9A=9A=9A= 18985=9A 1605280=9A 0=9A=9A=9A 0=9A=9A=20 0
03104:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 icmp= =9A=9A=9A=9A=20 10.0.96.187/0=9A=9A=9A=9A=9A 192.168.40.147/0=9A=9A=9A=9A 97755=9A 4599= 119=9A 0=9A=9A=9A 0=9A=9A 0
03091:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=20 193.108.170.1/110=9A=9A=9A=9A=9A= =9A 10.0.96.178/2058=9A 13762 12454= 883=9A 0=9A=9A=9A 0=9A=9A 0
04011:=9A=20 10.240 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A = 10.0.100.174/53562 5904=9A 586389= 6=9A 0=9A=9A=9A 0=9A 19
03074:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.96.44/137=9A=9A 255.255.255.255/137=9A=9A 20606=9A 2593867=9A 0= =9A=9A=9A 0=9A=9A 6
03066:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.95.213/68=9A=9A=9A 255.255.255.255/67=9A=9A=9A 54989 16102076=9A = 0=9A=9A=9A 0=9A=9A 0
03051:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A 91.207.211.17/1025=9A=9A=9A 93=9A=9A= =9A=9A 6024=9A 0=9A=9A=9A 0=9A=9A 0
03032:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.95.247/40298=9A=9A=9A 95.57.153.37/64237 282373 174869068=9A 2= 1152=9A=9A 0
03601:=9A=9A=20 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =20 74.125.87.18/80=9A=9A=9A=9A=9A=9A 10.0.100.134/2576=9A 673714 63643337= 9 19 22784=20 1965
03016: 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucket= s)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A=9A 10.0.100.211/137=9A= =9A 255.255.255.255/137=9A=9A=9A= 118=9A=9A=9A 18691=9A 0=9A=9A=9A 0=9A=9A=20 0
04027:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=9A=9A=20 98.1.75.163/19248=9A=9A=9A=9A 10.0.95.218/4922=9A 14275 10751781=9A 0= =9A=9A=9A 0=9A=9A 0
03634:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=20 10.0.97.73/1035=9A 239.255.255.250/1900=9A=9A 597=9A=9A=9A 91268=9A= 0=9A=9A=9A 0=9A=9A 0
03158:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=20 10.0.97.234/137=9A=9A 255.255.255.255/137=9A=9A 6922=9A=9A 390084=9A= 0=9A=9A=9A 0=9A=9A 0
03143:=20 384.000 Kbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=9A=9A= =9A=9A=20 81.19.70.1/80=9A=9A=9A=9A=9A=9A 10.0.100.147/1104=9A 38528 43549114 20 2= 4581=9A 54
03120:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =9A=9A=9A=20 10.0.96.5/35042=9A=9A=9A 82.0.123.197/41656 169096 27322663=9A 0=9A= =9A=9A 0=9A=9A 0
04621:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A=9A 10.0.97.51/63370 27900 23917= 035=9A 0=9A=9A=9A 0=9A 36
03105:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=20 91.205.206.19/53=9A=9A=9A=9A=9A=9A= =9A 10.0.96.187/5136=9A 159096 2203= 68420=9A 0=9A=9A=9A 0=9A=9A=20 0
03090:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=9A=9A=20 10.0.96.178/68=9A=9A=9A 255.255.255.255/67=9A=9A=9A 12004=9A 1747483= =9A 0=9A=9A=9A 0=9A=9A 0
04010:=9A=20 10.240 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp=9A=9A=9A=9A= =20 10.0.100.174/57618=9A=9A=9A=9A 224.0.0.252/5355=9A 4810=9A=9A 581234= =9A 0=9A=9A=9A 0=9A=9A 0
03075:=9A=9A=20 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buckets) droptail
= =9A=9A=9A mask: 0x00=20 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____= =20 ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp=9A=9A=20 131.111.33.242/63891=9A=9A=9A= =9A=9A 10.0.96.44/1079=9A 23002=9A 6= 952666=9A 0=9A=9A=9A 0=9A=20 59
03067:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buck= ets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 tcp=9A=9A=9A 74.125.77.147/80=9A=9A= =9A=9A=9A=9A=9A 10.0.95.213/1106=9A= 44306 28967429=9A 0=9A=9A=9A 0=9A=20 39
03050:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 buck= ets)=20 droptail
=9A=9A=9A mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000<= br>BKT Prot=20 ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
= =9A 0=20 udp=9A=9A=9A 91.207.211.17/137=9A= =9A 255.255.255.255/137=9A=9A=9A= 143=9A=9A=9A 16614=9A 0=9A=9A=9A 0=9A=9A=20 0
03033:=9A=9A 1.024 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 tcp= =9A=9A=9A=20 91.205.206.19/61617=9A=9A=9A=9A = 10.0.95.247/27881 144076=9A 995472= 5=9A 0=9A=9A=9A 0=9A=9A=20 0
03600:=9A=9A 2.048 Mbit/s=9A=9A=9A 0 ms=9A=9A 50 sl. 1 queues (1 bucke= ts) droptail
=9A=9A=9A=20 mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source= =20 IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
=9A 0 udp= =9A=9A=9A=9A=20 10.0.100.134/2572=9A 239.255.255.250/1900=9A 533990 377537021=9A = 2 1520=9A=9A=20 0

and so on. More online users, more ipfw rules and mor= e pipes...


On Mon, May 4, 2009 = at 11:05 AM, Oleg Bulyzhin <oleg@freebsd.org> wrote:

Please show sysctl net.inet.ip.dummynet output, your ipfw ruleset and
pipe configs.

--
Oleg.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru =3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




--
----
=F3 =D5= =D7=C1=D6=C5=CE=C9=C5=CD, =E1=CE=C4=D2=C5=CA
--0016364c758e62805c04691699de-- From oleg at FreeBSD.org Mon May 4 15:10:03 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Mon May 4 15:10:25 2009 Subject: kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression] Message-ID: <200905041510.n44FA2iU027836@freefall.freebsd.org> The following reply was made to PR kern/134157; it has been noted by GNATS. From: Oleg Bulyzhin To: Andrey Golenischev Cc: bug-followup@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 -- oleg@rinet.ru === ================================================================ From bms at incunabulum.net Mon May 4 16:04:14 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon May 4 16:04:20 2009 Subject: CARP as a module; followup thoughts In-Reply-To: <2aada3410905032103g734e7025nad7f7b13137572ed@mail.gmail.com> References: <2aada3410904212216o128e1fdfx8c299b3531adc694@mail.gmail.com> <49EF11E8.508@FreeBSD.org> <2aada3410905032103g734e7025nad7f7b13137572ed@mail.gmail.com> Message-ID: <49FF11F7.6090108@incunabulum.net> Will Andrews wrote: > Thank you very much for your feedback. I have implemented your > suggestion as follows: > > http://firepipe.net/patches/carp-as-module-20090503-2.diff > Great stuff. Overall this does make things that much cleaner. > This version doesn't reinvent the wheel as far as registering the > protocol goes. Personally, I think that notwithstanding your other > objection, this should get committed, since it is a step in the right > direction (perhaps minus the netinet6/in6_proto.c change that adds > spacers). One step at a time! > Yeah, I wouldn't worry about it too much for now. It is something which would be nice to have -- some NICs will perfect hash in hardware on more than one MAC address -- but I believe we've got other issues in this area to do with per-AF locking, which would probably be touched by exactly the issues you raise in the last part of your post... well spotted... > carp_encapcheck() is simplistic, but probably suffices (maybe also > check to see if the vh MAC matches). This patch does work fine with > my test setup, one system using GENERIC+if_carp and the other using a > static build without the patch. > I'll have to take your word for that as I'm not using CARP just at the moment. I had to touch the mcast setup for the IPv6 SSM implementation. All compiles OK, but I haven't tested the code other than loading it. Only IPv6 multicast group setup should be affected. Does your patch apply against these revisions OK? > I also found a "memory leak" in the original code, where it calls > free(cif, M_IFADDR), which is wrong, it should be free(cif, M_CARP), > since the original malloc uses M_CARP -- this fix is also included in > the patch above. > Great stuff. Can this bug fix be merged separately, i.e. before other code is committed? That way it can get merged back to -STABLE more quickly, once RELENG_7 is unfrozen. > ... > > Another way would be to have a separate list/hash table for virtual > lladdr's (ifnet.ifvirt_lladdrhead?). I considered that but it seems > better and more general to simply upgrade ifnet.if_addrhead. > It would be good to have a more general code path for stuff like this to benefit from using the perfect hash filters in modern NICs, the main thing is that everything continues to work with no regressions :-) Thanks for the effort you've put into this, it will certainly help a lot of folk to be able to ship a CARP-capable GENERIC kernel. cheers, BMS From gnn at neville-neil.com Mon May 4 16:17:30 2009 From: gnn at neville-neil.com (George Neville-Neil) Date: Mon May 4 16:17:37 2009 Subject: Slow local TCP transfers on -CURRENT In-Reply-To: <49FC3984.8050609@freebsd.org> References: <00C19FCC-837A-44B8-A0C9-C56E3D02F8EF@dragondata.com> <49FC3984.8050609@freebsd.org> Message-ID: <070BE192-6D18-4DB9-87AE-49233996CCA4@neville-neil.com> On May 2, 2009, at 08:16 , Lawrence Stewart wrote: > Kevin Day wrote: >> I've been seeing this for a few months now on -CURRENT. TCP >> transfers to local IP addresses (but not 127.0.0.1) are incredibly >> slow. >> Transfer from localhost: >> # scp "root@127.0.0.1:/boot/kernel/kernel" . >> kernel >> 100 >> % 11MB 11.1MB/s 00:00 >> Appropriately fast. >> Transfer from an IP on a local interface: >> # scp "root@216.14.96.4:/boot/kernel/kernel" . >> kernel >> 0 >> % 16KB 13.0KB/s 14:37 ETA >> The routes seem normal: >> # route get 127.0.0.1 >> route to: localhost >> destination: localhost >> interface: lo0 >> flags: >> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >> 0 0 0 0 16384 1 0 >> # route -n get 216.14.96.4 >> route to: 216.14.96.4 >> destination: 216.14.96.0 >> mask: 255.255.255.128 >> interface: nfe0 >> flags: >> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >> 0 0 0 0 1500 1 0 >> nfe0: flags=8843 metric 0 >> mtu 1500 >> >> options=19b >> ether 00:30:48:c6:dd:9c >> inet 216.14.96.4 netmask 0xffffff80 broadcast 216.14.96.127 >> Takes 10-60 minutes to copy, stalling frequently during the >> transfer. It's not limited to just scp either, all TCP transfers >> seem to stall this way. >> I don't believe I'm doing anything unusual, has anyone seen >> anything like this? > > Known fallout from the ARPv2 work I believe. As a workaround until > it gets fixed: > > route add -host (if-ip) -iface lo0 (note I haven't tested this myself) > > (see the Jan 2009 freebsd-net@ thread "Bacula: VERY SLOW on SAME > host" for some details). > Anyone know if there is a fix in the offing? Best, George From lstewart at freebsd.org Mon May 4 16:24:20 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Mon May 4 16:24:55 2009 Subject: Slow local TCP transfers on -CURRENT In-Reply-To: <070BE192-6D18-4DB9-87AE-49233996CCA4@neville-neil.com> References: <00C19FCC-837A-44B8-A0C9-C56E3D02F8EF@dragondata.com> <49FC3984.8050609@freebsd.org> <070BE192-6D18-4DB9-87AE-49233996CCA4@neville-neil.com> Message-ID: <49FF169A.9040708@freebsd.org> George Neville-Neil wrote: > > On May 2, 2009, at 08:16 , Lawrence Stewart wrote: > >> Kevin Day wrote: >>> I've been seeing this for a few months now on -CURRENT. TCP transfers >>> to local IP addresses (but not 127.0.0.1) are incredibly slow. >>> Transfer from localhost: >>> # scp "root@127.0.0.1:/boot/kernel/kernel" . >>> kernel >>> 100% 11MB 11.1MB/s 00:00 >>> Appropriately fast. >>> Transfer from an IP on a local interface: >>> # scp "root@216.14.96.4:/boot/kernel/kernel" . >>> kernel >>> 0% 16KB 13.0KB/s 14:37 ETA >>> The routes seem normal: >>> # route get 127.0.0.1 >>> route to: localhost >>> destination: localhost >>> interface: lo0 >>> flags: >>> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >>> 0 0 0 0 16384 1 0 >>> # route -n get 216.14.96.4 >>> route to: 216.14.96.4 >>> destination: 216.14.96.0 >>> mask: 255.255.255.128 >>> interface: nfe0 >>> flags: >>> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >>> 0 0 0 0 1500 1 0 >>> nfe0: flags=8843 metric 0 mtu >>> 1500 >>> >>> options=19b >>> ether 00:30:48:c6:dd:9c >>> inet 216.14.96.4 netmask 0xffffff80 broadcast 216.14.96.127 >>> Takes 10-60 minutes to copy, stalling frequently during the transfer. >>> It's not limited to just scp either, all TCP transfers seem to stall >>> this way. >>> I don't believe I'm doing anything unusual, has anyone seen anything >>> like this? >> >> Known fallout from the ARPv2 work I believe. As a workaround until it >> gets fixed: >> >> route add -host (if-ip) -iface lo0 (note I haven't tested this myself) >> >> (see the Jan 2009 freebsd-net@ thread "Bacula: VERY SLOW on SAME host" >> for some details). >> > > Anyone know if there is a fix in the offing? Qing (added to CC) is aware of the problem. Not sure how far off the fix is. Cheers, Lawrence From littlesavage at orionet.ru Mon May 4 16:30:04 2009 From: littlesavage at orionet.ru (Alexey Illarionov) Date: Mon May 4 16:30:11 2009 Subject: kern/132734: panic in net/if_mib.c Message-ID: <200905041630.n44GU3sj035710@freefall.freebsd.org> The following reply was made to PR kern/132734; it has been noted by GNATS. From: Alexey Illarionov To: Mikolaj Golub Cc: bug-followup@FreeBSD.org, Robert Watson Subject: Re: kern/132734: panic in net/if_mib.c Date: Mon, 04 May 2009 20:00:17 +0400 Hi Mikolaj Golub wrote: > So, Alexey, can you try upgrading to the latest stable/7 or releng/7.2 or > apply attached patch to see if this tweak at least eliminates the instant > panic? With this patch this panic does not repeat any more. There are some error messages in log files: snmpd: sysctl linkmib estimate (ng1): No such file or directory. But kernel does not panics. Thanks. From lastewart at swin.edu.au Mon May 4 19:50:03 2009 From: lastewart at swin.edu.au (Lawrence Stewart) Date: Mon May 4 19:50:09 2009 Subject: TCP analysis, research and debugging tools: SIFTR v1.2.1 released Message-ID: <49FF4013.9000206@swin.edu.au> Hi All, I'm very pleased to announce the release of a significantly improved version of our SIFTR (Statistical Information For TCP Research) tool for FreeBSD. It can be obtained from [1], along with other papers, patches and software useful for protocol analysis, debugging and experimental research. SIFTR is a loadable kernel module supporting FreeBSD 6.2+ that logs a range of statistics on active TCP connections to a log file. It provides the ability to make highly granular, event-driven measurements of TCP connection state. More details are available in the readme and changelog available at [1]. Work on SIFTR v1.2.0 and v1.2.1 has been sponsored by the FreeBSD Foundation [2] as part of the "Enhancing the FreeBSD TCP Implementation" project [3]. SIFTR development prior to v1.2.0 was supported in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. SIFTR's functionality will be merged into the FreeBSD base system in one of the next steps in this project, and will hopefully ship with FreeBSD 8.0. Cheers, Lawrence http://caia.swin.edu.au [1] http://caia.swin.edu.au/urp/newtcp/tools.html [2] http://www.freebsdfoundation.org/ [3] http://caia.swin.edu.au/freebsd/etcp09/ From hrs at FreeBSD.org Mon May 4 19:51:45 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon May 4 19:51:52 2009 Subject: Freebsd failed to create routing prefix In-Reply-To: References: <20090504.103743.232652487.hrs@allbsd.org> Message-ID: <20090505.045053.96672057.hrs@allbsd.org> Rommel Laranjo wrote in : rs> Hello Hiroki-san, rs> rs> The box I am using is FreeBSD 7.0-Release: rs> rs> # uname -a rs> FreeBSD freebsd7.example.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun rs> Feb 24 19:59:52 UTC 2008 rs> root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Oh, really? So maybe 7.0R has the same problem. I will try to reproduce the symptom on my box. -- | Hiroki SATO -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090504/17f16a92/attachment.pgp From andrew at modulus.org Mon May 4 20:39:37 2009 From: andrew at modulus.org (Andrew Snow) Date: Mon May 4 20:39:43 2009 Subject: Filesystem and bigger files In-Reply-To: <49FEC893.8030305@unile.it> References: <49FA2E3F.9050108@entel.upc.edu> <3a142e750905010655i5e56282eu240e13f2a03dfb02@mail.gmail.com> <49FB55A3.605@entel.upc.edu> <3a142e750905011716g39ea55f0kd081bfdd55709b37@mail.gmail.com> <49FBF9B5.40800@entel.upc.edu> <3a142e750905020617y40f62463ma91b46a015b2b2ab@mail.gmail.com> <49FD61DD.7070903@entel.upc.edu> <3a142e750905030535v4cfe0103r1d8a17e828f6da9b@mail.gmail.com> <57348.147.83.40.234.1241416909.squirrel@webmail.entel.upc.edu> <49FEC893.8030305@unile.it> Message-ID: <49FF5267.6090005@modulus.org> Antonio Tommasi wrote: > Filesystem Size Used Avail Capacity Mounted on > /dev/aacd0s1a 64G 15G 44G 26% / > In a directory (spamassassin) i've one file (auto-whitelist) with > dimension 4.0 TB and one file (bayes_learn) with dimension 1.0TB > > How is it possible? How this file are managed? Spamassassin uses sparse files. http://en.wikipedia.org/wiki/Sparse_file Try running "du" on the files instead of "ls -l". - Andrew From sid at flytelecom.net Mon May 4 21:10:04 2009 From: sid at flytelecom.net (Andrey Golenischev) Date: Mon May 4 21:10:12 2009 Subject: kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression] Message-ID: <200905042110.n44LA2KP011855@freefall.freebsd.org> The following reply was made to PR kern/134157; it has been noted by GNATS. From: Andrey Golenischev To: Oleg Bulyzhin Cc: bug-followup@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 00:02:44 +0300 --0016e6dbe6dcd8bd0d04691c7b92 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 WWVzIGknbSB1c2luZyBtcGQgKHRyaWVkIHdpdGggbXBkNCBhbmQgbXBkNS4gVHJpZWQgdGhpcyBv biBzZXZlcmFsIFBDJ3MgLQp0aGUgc2FtZSBwcm9ibGVtIDooIElmIGkgaGF2ZSAzMC01MCBvbmxp bmUgdXNlcnMgLSBpdCBpcyBvay4gMTAwKyAtIGR1bW15bmV0CjEwMCUgbG9hZHMgYW5kIHNlcnZl ciBiZWNvbWUgdW5zdGFibGUvZnJlZXppbmcuCgpuZXQuaW5ldC5pcC5mdy5vbmVfcGFzczogMQpu ZXQuaXNyLmRpcmVjdDogMQoKCk9uIE1vbiwgTWF5IDQsIDIwMDkgYXQgNjowOSBQTSwgT2xlZyBC dWx5emhpbiA8b2xlZ0BmcmVlYnNkLm9yZz4gd3JvdGU6Cgo+Cj4gRmV3IG1vcmUgcXVlc3Rpb25z Ogo+IDEpIEFyZSB5b3UgdXNpbmcgbXBkPyBEaWQgeW91IHVwZ3JhZGUgaXQgYWxvbmcgd2l0aCBz eXN0ZW0/IEhhdmUgeW91IHRyaWVkCj4gdG8gdXNlIG1wZDQ/IChpZiB5b3UgaGF2ZSBwcm9ibGVt IHdpdGggbXBkNSkKPiAyKSBwbGVhc2Ugc2hvdyBtZSB2YWx1ZXMgb2YgZm9sbG93aW5nIHN5c2N0 bDoKPiBuZXQuaW5ldC5pcC5mdy5vbmVfcGFzcwo+IG5ldC5pc3IuZGlyZWN0Cj4KPiAtLQo+IE9s ZWcuCj4KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Cj4gPT09IE9sZWcgQnVseXpoaW4gLS0gT0JVTC1SSVBOIC0tIE9CVUwt UklQRSAtLSBvbGVnQHJpbmV0LnJ1ID09PQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KPgo+CgoKLS0gCi0tLS0K8yDV18HW xc7Jxc0sIOHOxNLFygo= --0016e6dbe6dcd8bd0d04691c7b92 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Yes i'm using mpd (tried with mpd4 and mpd5. Tried this on several PC&#= 39;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


On Mon, May 4, 2009= at 6:09 PM, Oleg Bulyzhin <oleg@freebsd.org> wrote:

Few more questions:
1) Are you using mpd? Did you upgrade it along with system? Have you tried<= br> 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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru =3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




--
----
=F3= =D5=D7=C1=D6=C5=CE=C9=C5=CD, =E1=CE=C4=D2=C5=CA
--0016e6dbe6dcd8bd0d04691c7b92-- From will at firepipe.net Mon May 4 21:48:11 2009 From: will at firepipe.net (Will Andrews) Date: Mon May 4 21:48:22 2009 Subject: CARP as a module; followup thoughts In-Reply-To: <49FF11F7.6090108@incunabulum.net> References: <2aada3410904212216o128e1fdfx8c299b3531adc694@mail.gmail.com> <49EF11E8.508@FreeBSD.org> <2aada3410905032103g734e7025nad7f7b13137572ed@mail.gmail.com> <49FF11F7.6090108@incunabulum.net> Message-ID: <2aada3410905041448o18722207m9f9d124573b39d54@mail.gmail.com> On Mon, May 4, 2009 at 10:04 AM, Bruce Simpson wrote: > I'll have to take your word for that as I'm not using CARP just at the > moment. I had to touch the mcast setup for the IPv6 SSM implementation. All > compiles OK, but I haven't tested the code other than loading it. Only IPv6 > multicast group setup should be affected. > > Does your patch apply against these revisions OK? It should. I am using git to develop these patches. I just did another sync (to r191794) and the diff from svn to my local git branch is the same as the patch I posted last night, so I presume it will apply to a fresh svn checkout of -current as of that revision. > Great stuff. > Can this bug fix be merged separately, i.e. before other code is committed? > That way it can get merged back to -STABLE more quickly, once RELENG_7 is > unfrozen. Yes, I can generate a separate patch for that one. If I were able to commit it myself, I'd certainly be doing it the way you suggest. I'd also suggest a more aggressive MFC timing for the free() bug fix than for the module feature (perhaps 3 days vs. 1-2 months, as 7.2R is now out). I am going to backport this patch to RELENG_7. Because of the way it is implemented, I believe it should be safe to MFC. > It would be good to have a more general code path for stuff like this to > benefit from using the perfect hash filters in modern NICs, the main thing > is that everything continues to work with no regressions :-) > > Thanks for the effort you've put into this, it will certainly help a lot of > folk to be able to ship a CARP-capable GENERIC kernel. Indeed, regressions will be difficult to prevent. I'm planning to work on virtual lladdrs for a bit to see if I can find a suitable solution for the problem. If nothing else, I think it provides a reasonable method for getting rid of carp_forus(), and possibly for implementing carpdev. Thanks, --Will. From ol at csa.ru Mon May 4 23:05:29 2009 From: ol at csa.ru (Oleg Baranov) Date: Mon May 4 23:05:36 2009 Subject: Awful forwarding rate [7.2-Release, igb] Message-ID: <49FF706F.1050209@csa.ru> 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 sec 160 KBytes 117 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 GBytes 933 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 GBytes 930 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 0xffffff00 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 0xff000000 lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:c8:19:67 inet 192.168.111.254 netmask 0xffffff00 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 0xffffffff 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!!!! From jfvogel at gmail.com Mon May 4 23:23:42 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Mon May 4 23:23:49 2009 Subject: Awful forwarding rate [7.2-Release, igb] In-Reply-To: <49FF706F.1050209@csa.ru> References: <49FF706F.1050209@csa.ru> Message-ID: <2a41acea0905041623s1b7793d5s16c0375ce1b5e606@mail.gmail.com> Turn off LRO, its on by default, you can do it with sysctl, be sure to down and up the interface. In FreeBSD 8 this will be automagic but for 7.2 its manual. Jack On Mon, May 4, 2009 at 3:47 PM, Oleg Baranov wrote: > 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 sec 160 KBytes 117 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 GBytes 933 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 GBytes 930 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 0xffffff00 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 0xff000000 > lagg0: flags=8843 metric 0 mtu 1500 > options=19b > ether 00:30:48:c8:19:67 > inet 192.168.111.254 netmask 0xffffff00 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 0xffffffff > > > 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-unsubscribe@freebsd.org" > From oleg at FreeBSD.org Tue May 5 07:20:02 2009 From: oleg at FreeBSD.org (Oleg Bulyzhin) Date: Tue May 5 07:20:09 2009 Subject: kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression] Message-ID: <200905050720.n457K2nR042229@freefall.freebsd.org> The following reply was made to PR kern/134157; it has been noted by GNATS. From: Oleg Bulyzhin To: Andrey Golenischev Cc: bug-followup@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 -- oleg@rinet.ru === ================================================================ From bms at incunabulum.net Tue May 5 12:21:51 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue May 5 12:21:58 2009 Subject: Request feedback on IPv6 multicast listen on :: In-Reply-To: References: <49FB327E.3010504@incunabulum.net> Message-ID: <4A002F59.1000000@incunabulum.net> JINMEI Tatuya / ???? wrote: > I believe you can safely remove it. The KAME repository version of > that code was already deprecated long time ago. Thanks for clearing this up. I couldn't find anything which referenced the code, and as you pointed out its implementation was not complete, so I will leave it out. regards, BMS From qingli at speakeasy.net Tue May 5 16:01:45 2009 From: qingli at speakeasy.net (Qing Li) Date: Tue May 5 16:01:53 2009 Subject: Slow local TCP transfers on -CURRENT In-Reply-To: <49FF169A.9040708@freebsd.org> Message-ID: <20090505160145.8C8A08FC0C@mx1.freebsd.org> > > Qing (added to CC) is aware of the problem. Not sure how far > off the fix is. > I am resuming the work on it, hoping to get it verified and finalized in a day or so. Sorry about the delay. -- Qing From bob at veznat.com Tue May 5 18:40:15 2009 From: bob at veznat.com (Bob Van Zant) Date: Tue May 5 18:40:47 2009 Subject: IPv6 duplicate address detection Message-ID: I'm working on a piece of software that, among other things, allows an administrator to easily configure IPv6 interfaces on a FreeBSD host. I've run into a problem where whenever I reconfigure an interface with an IPv6 address FreeBSD marks the new address as being a duplicate. The problem is that I'm following RFC 2461 [1] in that I send an unsolicited neighbor advertisement to ff02::1 immediately after configuring the interface. This unsolicited neighbor advertisement is interpreted by FreeBSD as being a response to the neighbor solicitation it sends around the same time as part of duplicate address detection (DAD). This leads FreeBSD to think that the address is already in use, it doesn't notice that it is the one already using it. I want this to mean that there's a bug in the IPv6 implementation in that it shouldn't trigger a DAD failure if it sees an unsolicited NA from itself when sent from the same physical interface. An alternative view on this is that I shouldn't be sending out any packets, especially unsolicited NAs, using or referencing a tentative address. I'm writing to freebsd-net to ask what others think. If people agree that the address shouldn't be marked as a duplicate then I have a python script that reproduces the problem and a patch to nd6_nbr.c to attach to a problem report that I'll file. -Bob [1] RFC 2461 section 7.2.6 paragraph 1: In some cases a node may be able to determine that its link-layer address has changed (e.g., hot-swap of an interface card) and may wish to inform its neighbors of the new link-layer address quickly. From auryn at zirakzigil.org Tue May 5 22:32:18 2009 From: auryn at zirakzigil.org (Giulio Ferro) Date: Tue May 5 22:32:24 2009 Subject: Configure networking outside rc.conf Message-ID: <4A00BE6C.5030800@zirakzigil.org> I was wondering if there was a way to cleanly configure networking without using rc.conf but only ifconfig and other utilities This is what I mean: let's suppose that I have a complex network configuration to launch on my machine, for example: - many physical nics (with different speed, mtu, duplex...) - many aliases on them - many vlans - many carped interfaces - ng_fec - ... What I ask is: can I, set up networking in a way that is equivalent to creating the configuration in /etc/rc.conf and then using "/etc/rc.d/netif restart" ? I know how to set up the example configuration above, what I don't know is if I can do that cleanly, that is, cleaning the state of all interfaces, truncating vlans, etc., and then creating them again with ifconfig, ngctl, etc. Thanks in advance. From ccowart at rescomp.berkeley.edu Tue May 5 22:54:25 2009 From: ccowart at rescomp.berkeley.edu (Chris Cowart) Date: Tue May 5 22:54:32 2009 Subject: Configure networking outside rc.conf In-Reply-To: <4A00BE6C.5030800@zirakzigil.org> References: <4A00BE6C.5030800@zirakzigil.org> Message-ID: <20090505225425.GA49013@hal.rescomp.berkeley.edu> Giulio Ferro wrote: > I was wondering if there was a way to cleanly configure networking > without using rc.conf but only ifconfig and other utilities > > This is what I mean: let's suppose that I have a complex network > configuration to launch on my machine, for example: > - many physical nics (with different speed, mtu, duplex...) > - many aliases on them > - many vlans > - many carped interfaces > - ng_fec > - ... > > What I ask is: can I, set up networking in a way that is equivalent to > creating the configuration in /etc/rc.conf and then using > "/etc/rc.d/netif restart" ? > > I know how to set up the example configuration above, what I > don't know is if I can do that cleanly, that is, cleaning the state of > all interfaces, truncating vlans, etc., and then creating them again > with ifconfig, ngctl, etc. Assuming the NICs are displayed by ifconfig -a or inserted into cloned_interfaces in /etc/rc.conf, you can create the following scripts: /etc/start_if.vlan100 /etc/stop_if.vlan100 Where start_if.vlan100 is sourced by the netif start and stop_if.vlan100 is sourced by the netif stop. For example: | ccowart dev-aux etc $ cat /etc/start_if.vlan81 | ifconfig vlan81 vlan 81 vlandev em0 | ifconfig vlan81 inet 10.81.1.1/16 I don't know that two files per interface is any cleaner than a really long /etc/rc.conf (I usually prefer the latter, but I generally am not dealing with more than 20-40 lines at most). -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090505/0daa0376/attachment.pgp From remko at FreeBSD.org Wed May 6 05:04:20 2009 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Wed May 6 05:04:35 2009 Subject: kern/134251: skype-2.0.0.72 broke with recent kernel changes in 7.2: all skype-out calls disconnect after 1 minute Message-ID: <200905060504.n4654J04038396@freefall.freebsd.org> Synopsis: skype-2.0.0.72 broke with recent kernel changes in 7.2: all skype-out calls disconnect after 1 minute Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed May 6 05:04:06 UTC 2009 Responsible-Changed-Why: Seems like something networking http://www.freebsd.org/cgi/query-pr.cgi?pr=134251 From dchagin at freebsd.org Wed May 6 05:40:04 2009 From: dchagin at freebsd.org (Chagin Dmitry) Date: Wed May 6 05:40:10 2009 Subject: kern/134251: skype-2.0.0.72 broke with recent kernel changes in 7.2: all skype-out calls disconnect after 1 minute Message-ID: <200905060540.n465e4JK080154@freefall.freebsd.org> The following reply was made to PR kern/134251; it has been noted by GNATS. From: Chagin Dmitry To: Yuri Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/134251: skype-2.0.0.72 broke with recent kernel changes in 7.2: all skype-out calls disconnect after 1 minute Date: Wed, 6 May 2009 09:00:32 +0400 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 06, 2009 at 12:49:19AM +0000, Yuri wrote: >=20 > >Number: 134251 > >Category: kern > >Synopsis: skype-2.0.0.72 broke with recent kernel changes in 7.2: = all skype-out calls disconnect after 1 minute > >Confidential: no > >Severity: serious > >Priority: high > >Responsible: freebsd-bugs > >State: open > >Quarter: =20 > >Keywords: =20 > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed May 06 00:50:02 UTC 2009 > >Closed-Date: > >Last-Modified: > >Originator: Yuri > >Release: 7.2-PRERELEASE > >Organization: > n/a > >Environment: > >Description: > Looks like outgoing skype calls are broken by some kernel change between = Feb 25, 2009 and Arp 25, 2009. >=20 > Symptom is that time counter of the call counts seconds with much lower t= han 1Hz frequency and all outgoing calls disconnect after 1 minute. >=20 > On Feb 25 it was 7.1-STABLE. On Apr 25 it's 7.2-PRERELEASE. >=20 > This is a very serious usability issue and should be fixed before 7.2 is = made STABLE. >=20 > It may cause other adverse effects in other Linux apps. >=20 Try kern.hz=3D100 (in /boot/loader.conf) and report any resalts. --=20 Have fun! chd --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkoBGW8ACgkQ0t2Tb3OO/O22UQCfUXT/NePexqXzR2nGKFdV1D6x 5f0AoK+S8qNNjrIDHAyUpp9ehyqdpY57 =iJ/Z -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From swun2010 at gmail.com Wed May 6 05:47:48 2009 From: swun2010 at gmail.com (Sam Wun) Date: Wed May 6 05:47:55 2009 Subject: Installworld failed with net options are added in kernel config Message-ID: <736c47cb0905052247q238bb68en285c47d64cdaf6cf@mail.gmail.com> Hi, With 7.2, I have added the following options in the kernel config file then compiled... ################ MY STUFF ############################################# ##options IPDIVERT #divert sockets device pf #PF OpenBSD packet-filter firewall device pflog #logging support interface for PF device pfsync #synchronization interface for PF device carp #Common Address Redundancy Protocol device enc #IPSec interface (needs FAST_IPSEC) options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ALTQ_NOPCC options NETGRAPH #netgraph(4) system options NETGRAPH_ASYNC options NETGRAPH_BPF options NETGRAPH_CISCO options NETGRAPH_ECHO options NETGRAPH_ETHER options NETGRAPH_FRAME_RELAY options NETGRAPH_HOLE options NETGRAPH_IFACE options NETGRAPH_KSOCKET options NETGRAPH_LMI # MPPC compression requires proprietary files (not included) #options NETGRAPH_MPPC_COMPRESSION options NETGRAPH_MPPC_ENCRYPTION options NETGRAPH_ONE2MANY options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options NETGRAPH_RFC1490 options NETGRAPH_SOCKET options NETGRAPH_TEE options NETGRAPH_TTY options NETGRAPH_UI options NETGRAPH_VJC #stuff for squid options MSGMNB=16384 # max # of bytes in a queue options MSGMNI=128 # number of message queue identifiers options MSGSEG=4096 # number of message segments per queue options MSGSSZ=256 # size of a message segment options MSGTQL=16384 # max messages in system options SHMSEG=64 # max shared mem id's per process options SHMMNI=128 # max shared mem id's per system options SHMMAX=8388608 # max shared memory segment size (bytes) options SHMALL=8192 # max amount of shared memory (pages) #stuff for postgresql options SHMMAXPGS=131072 options SEMMNI=64 options SEMMNS=240 options SEMUME=40 options SEMMNU=120 However, when it comes to installworld, it failed with the following errors: cat /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/key_defined.3x > key_defined.3 cat /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/keybound.3x > keybound.3 cat /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/keyok.3x > keyok.3 cat /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/legacy_coding.3x > legacy_coding.3 cat /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/ncurses.3x > ncurses.3 cat /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/resizeterm.3x > resizeterm.3 cat /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/wresize.3x > wresize.3 sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/MKterminfo.sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/terminfo.head /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/Caps /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/terminfo.tail >terminfo.5 tr: not found /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/man/MKterminfo.sh: cannot open unsorted61466: No such file or directory *** Error code 2 Stop in /usr/src/lib/ncurses/ncurses. *** Error code 1 Stop in /usr/src/lib/ncurses. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 What is wrong with it? Your suggestion is highly appreciated. Thanks From dchagin at FreeBSD.org Wed May 6 05:54:35 2009 From: dchagin at FreeBSD.org (dchagin@FreeBSD.org) Date: Wed May 6 05:54:42 2009 Subject: kern/134251: skype-2.0.0.72 broke with recent kernel changes in 7.2: all skype-out calls disconnect after 1 minute Message-ID: <200905060554.n465sYV8005955@freefall.freebsd.org> Synopsis: skype-2.0.0.72 broke with recent kernel changes in 7.2: all skype-out calls disconnect after 1 minute Responsible-Changed-From-To: freebsd-net->dchagin Responsible-Changed-By: dchagin Responsible-Changed-When: Wed May 6 05:51:58 UTC 2009 Responsible-Changed-Why: Grab it, bug in Linux emulation layer. linux_times() should use kern.hz instead of own constant. I will fix this soon. http://www.freebsd.org/cgi/query-pr.cgi?pr=134251 From nrml at att.net Wed May 6 13:09:35 2009 From: nrml at att.net (Gabe) Date: Wed May 6 13:09:41 2009 Subject: IPSEC NAT traversal In-Reply-To: Message-ID: <287772.92179.qm@web83806.mail.sp1.yahoo.com> --- On Tue, 4/28/09, Scott Ullrich wrote: > From: Scott Ullrich > Subject: Re: IPSEC NAT traversal > To: "Bjoern A. Zeeb" > Cc: freebsd-net@freebsd.org, "VANHULLEBUS Yvan" > Date: Tuesday, April 28, 2009, 11:39 AM > On Tue, Apr 28, 2009 at 1:28 PM, Bjoern A. Zeeb > wrote: > > On Tue, 28 Apr 2009, Scott Ullrich wrote: > [snip] > > I have NAT-T on top of that. And I am currently doing > the whatever > > you'll call it 'final pass', will send it > back to Yvan once I am done > > with the last 2 items and last 400 lines of key.c . > After that I > > assume someone will commit it. > > As I am pretty sure you'll want to test it before > it goes into the > > tree so you'll get a copy as well; thanks for > volunteering;-p > > Hey that is great news. I will be ready to test the patch > as soon as > you are all ready. > > Thanks for the update > > Scott > _______________________________________________ So how is it coming along? Is the goal to standardize this and commit it to become a permanent part of freebsd? I've got a total of three machines with this patch and would reeeeally like it if it were. From auryn at zirakzigil.org Wed May 6 13:44:40 2009 From: auryn at zirakzigil.org (Giulio Ferro) Date: Wed May 6 13:44:47 2009 Subject: Configure networking outside rc.conf In-Reply-To: <20090505225425.GA49013@hal.rescomp.berkeley.edu> References: <4A00BE6C.5030800@zirakzigil.org> <20090505225425.GA49013@hal.rescomp.berkeley.edu> Message-ID: <4A01943F.6000400@zirakzigil.org> Chris Cowart wrote: > Assuming the NICs are displayed by ifconfig -a or inserted into > cloned_interfaces in /etc/rc.conf, you can create the following scripts: > > /etc/start_if.vlan100 > /etc/stop_if.vlan100 > > Where start_if.vlan100 is sourced by the netif start and stop_if.vlan100 > is sourced by the netif stop. > > For example: > > | ccowart dev-aux etc $ cat /etc/start_if.vlan81 > | ifconfig vlan81 vlan 81 vlandev em0 > | ifconfig vlan81 inet 10.81.1.1/16 > > I don't know that two files per interface is any cleaner than a really > long /etc/rc.conf (I usually prefer the latter, but I generally am not > dealing with more than 20-40 lines at most). > > Thanks for the reply. What should be normally put in the stop_if. file? Do the "stop" files make sense? Anyway I'll try to make it fit with what I need. From bzeeb-lists at lists.zabbadoz.net Wed May 6 14:05:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed May 6 14:05:22 2009 Subject: IPSEC NAT traversal In-Reply-To: <287772.92179.qm@web83806.mail.sp1.yahoo.com> References: <287772.92179.qm@web83806.mail.sp1.yahoo.com> Message-ID: <20090506135851.R72053@maildrop.int.zabbadoz.net> On Wed, 6 May 2009, Gabe wrote: Hi, I had been travelling yesterday, ... here is the summary for today: > So how is it coming along? It's compiling; it's on might notebook since last night as well. It hasn't crashed yet. I haven't tested IPsec yet either though;) That'll probably happen the next days. Need to build a custom ipsec-tools port first. > Is the goal to standardize this and commit it to become a permanent > part of freebsd? I've got a total of three machines with this patch > and would reeeeally like it if it were. Stadardize as in between everyone is not going to work. Different people have already adopted different APIs but trying to be as compatible with netbsd/linux sounds like a plan. OS X is different, unfortunately. Having it in FreeBSD 8.x is definitively on the schedule. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From bms at incunabulum.net Wed May 6 14:27:18 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed May 6 14:27:25 2009 Subject: IPv6 duplicate address detection In-Reply-To: References: Message-ID: <4A019E40.1030606@incunabulum.net> Bob Van Zant wrote: > I'm working on a piece of software that, among other things, allows an > administrator to easily configure IPv6 interfaces on a FreeBSD host. I've > run into a problem where whenever I reconfigure an interface with an IPv6 > address FreeBSD marks the new address as being a duplicate. > > The problem is that I'm following RFC 2461 [1] in that I send an unsolicited > neighbor advertisement to ff02::1 immediately after configuring the > interface. > How are you doing this? Do you do this from the kernel or from your own userland code? Normally the kernel does DAD for you when a new IPv6 address is configured, and you shouldn't need to do it manually. However, I would agree that there should probably be more run-time, user-space controls over how the IPv6 stack behaves. > This unsolicited neighbor advertisement is interpreted by FreeBSD as being a > response to the neighbor solicitation it sends around the same time as part > of duplicate address detection (DAD). This leads FreeBSD to think that the > address is already in use, it doesn't notice that it is the one already > using it. > It sounds like what you are trying to do is useful (a bit like gratuitous ARP) but I wonder exactly what conditions it's triggering in nd6_nbr.c which would cause it to interpret what you send in this way. One problem with trying to ape what the kernel does is in userland is that unless there's a unique ID in the datagram(s) thus sent that you can key off, it's difficult to catch it in the act and figure out what to do; there's also scheduler jitter to contend with. > I want this to mean that there's a bug in the IPv6 implementation in that it > shouldn't trigger a DAD failure if it sees an unsolicited NA from itself > when sent from the same physical interface. > This seems like a bug. Have you looked in the KAME repo to see if it got fixed there? Perhaps NetBSD have already fixed it in their import of KAME? > An alternative view on this is that I shouldn't be sending out any packets, > especially unsolicited NAs, using or referencing a tentative address. > That can be tricky to implement. There is a function in6ifa_ifpforlinklocal() which takes various flags. It is told to skip tentative addresses or duplicates by passing IN6_IFF_NOTREADY. Normally this will return the ifa pointer to the link-local address which was auto-configured on the inerface. Currently the MLDv2 code in HEAD will use the unspecified address (::) as a source address if the IFA match returned by this function is NULL, this is allowed by the MLDv2 spec. > I'm writing to freebsd-net to ask what others think. > > If people agree that the address shouldn't be marked as a duplicate then I > have a python script that reproduces the problem and a patch to nd6_nbr.c to > attach to a problem report that I'll file. > Can you try HEAD sources and disable IPv6 multicast loopback by default (net.inet6.ip6.mcast.loop, off the top of my head) ? It is possible that your ff02::1 packet is being looped back and somehow the NA/NS code is interpreting it as on-wire traffic. 7.x will loop back by default. You could even try just setting IPV6_MULTICAST_LOOP to 0 in your userland DAD code. That should help establish how the NA/NS code is seeing your locally originated control traffic... cheers, BMS From petri at helenius.fi Wed May 6 15:36:31 2009 From: petri at helenius.fi (Petri Helenius) Date: Wed May 6 15:36:38 2009 Subject: Signalling out of accept Message-ID: <4A01AE67.5090101@helenius.fi> Hi, What is the preferred way of getting out of an accept in an multithreaded application? On linux it works that the in-kernel filedescriptor is closed from the signal handler but that does not seem to do the trick in FreeBSD 7.1 or 7.2. Is using poll the only option or preferred anyway? Pete From bob at veznat.com Wed May 6 21:55:08 2009 From: bob at veznat.com (Bob Van Zant) Date: Wed May 6 21:55:22 2009 Subject: IPv6 duplicate address detection In-Reply-To: <4A019E40.1030606@incunabulum.net> Message-ID: On 5/6/09 7:27 AM, "Bruce Simpson" wrote: >> The problem is that I'm following RFC 2461 [1] in that I send an unsolicited >> neighbor advertisement to ff02::1 immediately after configuring the >> interface. >> > > How are you doing this? Do you do this from the kernel or from your own > userland code? Userland code. SOCK_RAW and IPPROTO_ICMPV6. > > Normally the kernel does DAD for you when a new IPv6 address is > configured, and you shouldn't need to do it manually. Just to be clear, I'm not trying to do DAD. You mention later that this sounds like gratuitous ARP and that's the best analogy for what I'm doing. I fire off a single packet into the wild and hope that my neighbors see my new link-layer address (we do NIC failover). > It sounds like what you are trying to do is useful (a bit like > gratuitous ARP) but I wonder exactly what conditions it's triggering in > nd6_nbr.c which would cause it to interpret what you send in this way. There's not really anything in nd6_nbr.c to prevent this behavior. I have a patch that changes this. I don't know if it's making an invalid assumption or not. In my basic tests it avoids the behavior where my IP gets marked as a duplicate but still allows DAD to work when the address really is a dup. --- nd6_nbr.c.backup Mon May 4 10:12:20 2009 +++ sys/netinet6/nd6_nbr.c Mon May 4 14:19:30 2009 @@ -618,8 +618,16 @@ lladdr = (char *)(ndopts.nd_opts_tgt_lladdr + 1); lladdrlen = ndopts.nd_opts_tgt_lladdr->nd_opt_len << 3; } + /* Is the source address of this packet one of my + * addresses on this same interface? If so this packet was sent by me + * and should not trigger a DAD failure. + */ + ifa = (struct ifaddr *)in6ifa_ifpwithaddr(ifp, &(ip6->ip6_src)); + if (ifa) + goto freeit; + > This seems like a bug. > Have you looked in the KAME repo to see if it got fixed there? > Perhaps NetBSD have already fixed it in their import of KAME? I took a look through head of the kame cvsweb sources and don't see any differences from 6.3 sources I have. They have some MIP6 code in place but that's the only difference I see. > >> An alternative view on this is that I shouldn't be sending out any packets, >> especially unsolicited NAs, using or referencing a tentative address. >> > > That can be tricky to implement. There is a function > in6ifa_ifpforlinklocal() which takes various flags. It is told to skip > tentative addresses or duplicates by passing IN6_IFF_NOTREADY. Normally > this will return the ifa pointer to the link-local address which was > auto-configured on the inerface. Being in userland I don't think I can call this. However, I discovered the SIOCGIFAFLAG_IN6 ioctl which gives me back the flags for an tuple. In this way I can poll for whether or not this IP is tentative or not. Similarly I can tell whether DAD failed. > > Can you try HEAD sources and disable IPv6 multicast loopback by default > (net.inet6.ip6.mcast.loop, off the top of my head) ? > > It is possible that your ff02::1 packet is being looped back and somehow > the NA/NS code is interpreting it as on-wire traffic. > 7.x will loop back by default. You could even try just setting > IPV6_MULTICAST_LOOP to 0 in your userland DAD code. I don't have a HEAD kernel handy. However, this socket option was a nice pointer, thank you. Setting this to 0 does prevent the behavior I was seeing. I guess this makes it extra clear that the multicast packet I'm sending is simply being looped back in. I'm guessing that the next step is for me to file a PR with this information? Or what do you suggest? -Bob From Jinmei_Tatuya at isc.org Wed May 6 22:06:50 2009 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Wed May 6 22:06:57 2009 Subject: IPv6 duplicate address detection In-Reply-To: References: Message-ID: At Tue, 05 May 2009 11:40:12 -0700, Bob Van Zant wrote: > > I'm working on a piece of software that, among other things, allows an > administrator to easily configure IPv6 interfaces on a FreeBSD host. I've > run into a problem where whenever I reconfigure an interface with an IPv6 > address FreeBSD marks the new address as being a duplicate. > > The problem is that I'm following RFC 2461 [1] in that I send an unsolicited > neighbor advertisement to ff02::1 immediately after configuring the > interface. I'm afraid we need clarification first...what do you mean by "reconfigure an interface with an IPv6 address"? Do you mean adding a new IPv6 address to an interface? If so, I'm not sure why you referred to the following part of RFC2461 (btw the RFC was updated by RFC4861): > [1] RFC 2461 section 7.2.6 paragraph 1: > > In some cases a node may be able to determine that its link-layer > address has changed (e.g., hot-swap of an interface card) and may > wish to inform its neighbors of the new link-layer address quickly. this example talks about the case where the link-layer address changes for an existing address, not where a new address is configured. Could you elaborate? --- JINMEI, Tatuya Internet Systems Consortium, Inc. From bob at veznat.com Wed May 6 22:49:52 2009 From: bob at veznat.com (Bob Van Zant) Date: Wed May 6 22:49:58 2009 Subject: IPv6 duplicate address detection In-Reply-To: Message-ID: On 5/6/09 3:06 PM, "JINMEI Tatuya / ????" wrote: > I'm afraid we need clarification first...what do you mean by > "reconfigure an interface with an IPv6 address"? Do you mean adding a > new IPv6 address to an interface? If so, I'm not sure why you > referred to the following part of RFC2461 (btw the RFC was updated by > RFC4861): We have a crude form of NIC pairing in our software. We allow someone to logically pair two interfaces together. This is implemented by `ifconfig down` both interfaces, configure them both the same, then `ifconfig up` the primary interface. We then monitor the link state of the primary interface. If the state goes to down, we `ifconfig down` the primary NIC and then `ifconfig up` the secondary NIC. This has the effect of changing the link layer address associated with a given IPv6 address. After we do this we send out the unsolicited NA to update whatever switch we're plugged into. We do this today with IPv4 and ARP and it works fine. >> [1] RFC 2461 section 7.2.6 paragraph 1: >> >> In some cases a node may be able to determine that its link-layer >> address has changed (e.g., hot-swap of an interface card) and may >> wish to inform its neighbors of the new link-layer address quickly. > > this example talks about the case where the link-layer address changes > for an existing address, not where a new address is configured. I hope the example I gave above helps to clarify that I am trying to handle a case where the link-layer address has changed. However, I'll admit that I had been planning on sending the unsolicited NA after any ifconfig commands were executed. So long as I'm not flooding the network it doesn't seem harmful and potentially seems useful to avoid a few seconds of downtime while the network figures things out. -Bob From Jinmei_Tatuya at isc.org Wed May 6 23:55:54 2009 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Wed May 6 23:56:00 2009 Subject: IPv6 duplicate address detection In-Reply-To: References: Message-ID: At Wed, 06 May 2009 15:49:45 -0700, Bob Van Zant wrote: > > I'm afraid we need clarification first...what do you mean by > > "reconfigure an interface with an IPv6 address"? Do you mean adding a > > new IPv6 address to an interface? If so, I'm not sure why you > > referred to the following part of RFC2461 (btw the RFC was updated by > > RFC4861): > We have a crude form of NIC pairing in our software. We allow someone to > logically pair two interfaces together. This is implemented by `ifconfig > down` both interfaces, configure them both the same, then `ifconfig up` the > primary interface. We then monitor the link state of the primary interface. > If the state goes to down, we `ifconfig down` the primary NIC and then > `ifconfig up` the secondary NIC. This has the effect of changing the link > layer address associated with a given IPv6 address. After we do this we send > out the unsolicited NA to update whatever switch we're plugged into. Okay, thanks for the explanation. But I still don't understand one thing: why is DAD triggered for the address on the secondary NIC? Unless someone has changed the code recently, the FreeBSD (KAME-derived) IPv6 stack shouldn't trigger DAD for an existing address simply because the interface becomes 'up' (this behavior may be debatable per se, but that's a different question). Did you perhaps make the address "tentative" by hand after configuring the address? --- JINMEI, Tatuya Internet Systems Consortium, Inc. From bob at veznat.com Thu May 7 00:18:02 2009 From: bob at veznat.com (Bob Van Zant) Date: Thu May 7 00:18:08 2009 Subject: IPv6 duplicate address detection In-Reply-To: Message-ID: I never actually tested the NIC pairing scenario and was only testing the naive "add a new IP, fire off an unsolicited NA for that IP." I did just test the NIC pairing and you are right, if the interface is down when it is configured we don't run DAD. Which does seem weird but that would be a different thread. I guess that changes my question quite a bit. If you randomly fire off an unsolicited NA right after configuring an interface should that cause a DAD failure? -Bob On 5/6/09 4:55 PM, "JINMEI Tatuya / ????" wrote: > At Wed, 06 May 2009 15:49:45 -0700, > Bob Van Zant wrote: > >>> I'm afraid we need clarification first...what do you mean by >>> "reconfigure an interface with an IPv6 address"? Do you mean adding a >>> new IPv6 address to an interface? If so, I'm not sure why you >>> referred to the following part of RFC2461 (btw the RFC was updated by >>> RFC4861): > >> We have a crude form of NIC pairing in our software. We allow someone to >> logically pair two interfaces together. This is implemented by `ifconfig >> down` both interfaces, configure them both the same, then `ifconfig up` the >> primary interface. We then monitor the link state of the primary interface. >> If the state goes to down, we `ifconfig down` the primary NIC and then >> `ifconfig up` the secondary NIC. This has the effect of changing the link >> layer address associated with a given IPv6 address. After we do this we send >> out the unsolicited NA to update whatever switch we're plugged into. > > Okay, thanks for the explanation. But I still don't understand one > thing: why is DAD triggered for the address on the secondary NIC? > Unless someone has changed the code recently, the FreeBSD > (KAME-derived) IPv6 stack shouldn't trigger DAD for an existing > address simply because the interface becomes 'up' (this behavior may > be debatable per se, but that's a different question). Did you > perhaps make the address "tentative" by hand after configuring the > address? > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. From Jinmei_Tatuya at isc.org Thu May 7 05:47:41 2009 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Thu May 7 05:47:47 2009 Subject: IPv6 duplicate address detection In-Reply-To: References: Message-ID: At Wed, 06 May 2009 17:17:52 -0700, Bob Van Zant wrote: > I guess that changes my question quite a bit. If you randomly fire off an > unsolicited NA right after configuring an interface should that cause a DAD > failure? Actually, in that case you shouldn't send out the NA in the first place because you're in the middle of DAD, trying to confirming the uniqueness of the target address. If you want to send an unsolicited NA for an address on which DAD is performed for any reason, you should wait until DAD is completed. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From bob at veznat.com Thu May 7 06:00:26 2009 From: bob at veznat.com (Bob Van Zant) Date: Thu May 7 06:00:58 2009 Subject: IPv6 duplicate address detection In-Reply-To: Message-ID: Well that goes all the way back to my first email :-) "An alternative view on this is that I shouldn't be sending out any packets, especially unsolicited NAs, using or referencing a tentative address." This makes sense. I'll stop doing bad things now :-) Thanks for your input and clearing this up for me. -Bob On 5/6/09 10:47 PM, "JINMEI Tatuya / ????" wrote: > At Wed, 06 May 2009 17:17:52 -0700, > Bob Van Zant wrote: > >> I guess that changes my question quite a bit. If you randomly fire off an >> unsolicited NA right after configuring an interface should that cause a DAD >> failure? > > Actually, in that case you shouldn't send out the NA in the first > place because you're in the middle of DAD, trying to confirming the > uniqueness of the target address. If you want to send an unsolicited > NA for an address on which DAD is performed for any reason, you should > wait until DAD is completed. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From nrml at att.net Thu May 7 08:22:12 2009 From: nrml at att.net (Gabe) Date: Thu May 7 08:22:19 2009 Subject: IPSEC NAT traversal In-Reply-To: <20090506135851.R72053@maildrop.int.zabbadoz.net> Message-ID: <481652.51363.qm@web83809.mail.sp1.yahoo.com> --- On Wed, 5/6/09, Bjoern A. Zeeb wrote: > On Wed, 6 May 2009, Gabe wrote: > > Hi, > > I had been travelling yesterday, ... here is the summary > for today: > > > So how is it coming along? > > It's compiling; it's on might notebook since last > night as well. It > hasn't crashed yet. I haven't tested IPsec yet > either though;) > That'll probably happen the next days. Need to build a > custom > ipsec-tools port first. > Ahh, please do let us know how your IPSec testing comes along when you get to it. > > Is the goal to standardize this and commit it to > become a permanent > > part of freebsd? I've got a total of three > machines with this patch > > and would reeeeally like it if it were. > > Stadardize as in between everyone is not going to work. > Different > people have already adopted different APIs but trying to be > as > compatible with netbsd/linux sounds like a plan. OS X is > different, > unfortunately. > I see. > Having it in FreeBSD 8.x is definitively on the schedule. > Awesome, looking forward to that. > /bz > > -- Bjoern A. Zeeb The greatest risk is > not taking one. Thanks for the reply! From ericx at ericx.net Thu May 7 13:35:27 2009 From: ericx at ericx.net (Eric W. Bates) Date: Thu May 7 13:35:34 2009 Subject: Configure networking outside rc.conf In-Reply-To: <4A01943F.6000400@zirakzigil.org> References: <4A00BE6C.5030800@zirakzigil.org> <20090505225425.GA49013@hal.rescomp.berkeley.edu> <4A01943F.6000400@zirakzigil.org> Message-ID: <4A02DF39.7040902@ericx.net> Giulio Ferro wrote: > Chris Cowart wrote: >> Assuming the NICs are displayed by ifconfig -a or inserted into >> cloned_interfaces in /etc/rc.conf, you can create the following scripts: >> >> /etc/start_if.vlan100 >> /etc/stop_if.vlan100 >> >> Where start_if.vlan100 is sourced by the netif start and stop_if.vlan100 >> is sourced by the netif stop. >> >> For example: >> >> | ccowart dev-aux etc $ cat /etc/start_if.vlan81 >> | ifconfig vlan81 vlan 81 vlandev em0 >> | ifconfig vlan81 inet 10.81.1.1/16 >> >> I don't know that two files per interface is any cleaner than a really >> long /etc/rc.conf (I usually prefer the latter, but I generally am not >> dealing with more than 20-40 lines at most). >> >> > Thanks for the reply. > What should be normally put in the stop_if. file? Do the "stop" > files make sense? You might, for example, have a dhcp server dedicated to that interface which you wanted to start/stop as the interface goes up/down. > Anyway I'll try to make it fit with what I need. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Eric W. Bates ericx@vineyard.net From bms at incunabulum.net Thu May 7 14:41:26 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Thu May 7 14:41:33 2009 Subject: IPv6 duplicate address detection In-Reply-To: References: Message-ID: <4A02F30F.5030704@incunabulum.net> Bob Van Zant wrote: > Well that goes all the way back to my first email :-) > > "An alternative view on this is that I shouldn't be sending out any packets, > especially unsolicited NAs, using or referencing a tentative address." > > This makes sense. I'll stop doing bad things now :-) Thanks for your input > and clearing this up for me. > OK, I'm very glad Jinmei-san has chewed over the specifics of how this might break DAD as specified. All the same, you did find a condition in the kernel where locally-originated traffic is being interpreted as being on-wire. Ok, SOCK_RAW is going to raise the bar on malefeasant use of this behaviour, but all the same, this is an input checking issue :-) It would be great if you could go ahead and raise a PR about this condition -- the MLDv2 code in HEAD will also be affected by this, as it does an IPv6 group membership check on the icmp6 input path. Strictly speaking it should come from ip6_mloopback(), but right now I can't remember if that will set any mbuf flags; I do believe it sets m->m_pkthdr.recvif to loif and that might be the only coherent way to detect the looped back traffic w/o doing an address lookup. cheers, BMS From raffaele.delorenzo at libero.it Thu May 7 20:23:01 2009 From: raffaele.delorenzo at libero.it (Raffaele De Lorenzo) Date: Thu May 7 20:23:14 2009 Subject: [ipfw patch - add ipv6 support for table mechanism] request for testing/commit Message-ID: <3233DB7C-06E8-4AFE-9704-0F900925DAE3@libero.it> Hi all, I extended the ipfw table mechanism to IPv6 protocol and now i need some people for testing and next commit it. The code is stable but you must be careful about possible ambiguous parser semantics. Now you must insert IPv6 addresses inside a table: ipfw table 1 add fe80::1 And you can create IPv6 rules about this table: ipfw add deny tcp from table6(1) to any dst-port 22 ipfw add deny icmp6 from any to table6(1) The "table6" semantic tell the difference betwen the IPv4 semantic ("table"). The following changes are made on the ipfw2 sources: KERNEL SPACE: ip_fw.h 1) Added 2 new OPCODES: O_IP6_SRC_LOOKUP, O_IP6_DST_LOOKUP 2) Added the follow fields in "ipfw_table_entry" structure: struct in6_addr addr6, mask6; uint8_t proto; ip_fw2.c -------------- next part -------------- 1) Added the follow fields in "struct table_entry" structure: struct sockaddr_in6 addr6, mask6; uint8_t proto; 2) Some changes inside the "add_table_entry" function. 3) Some changes inside the "del_table_entry" function. 4) Some changes inside the "flush_table_entry" function. 5) Some changes inside the "lookup_table" function. 6) Some changes inside the "dump_table_entry" function. 7) Added a new function named "set_proto_table". 8) Added the two new OPCODES inside the "ipfw_check()" function. 9) Added the two new OPCODES inside the "check_ipfw_struct" function. USER SPACE: ipfw2.c 1) Added some changes on "table_handler" function 2) Added some changes on "show_ipfw" function 3) Added some changes on "print_ip6" function 4) Added some changes on "fill_ip6" function 5) Added some changes on "add_dstip6" function 6) Added some changes on "add_srcip6" function 7) Added some changes on "add_src" function 8) Added some changes on "add_dst" function I updated the man pages. INSTALLATION INSTRUCTIONS: Put the "ip_fw2.c" and "ip_fw.h" files inside the "/sys/netinet/ directory" Put the "ipfw2.c" file inside the /src/sbin/ipfw/ directory Rebuild the ipfw kernel module or rebuild you kernel Rebuild the ipfw bin or the entire SBIN. The Sources was tested on FreeBSD 7.2 Release. Let me know any troubles Ciao Raffaele From sam at ip6.com.au Fri May 8 02:16:59 2009 From: sam at ip6.com.au (Sam Wan) Date: Fri May 8 02:17:05 2009 Subject: nf_sockopt_init in uipc_socket.c Message-ID: <15484.220.233.42.226.1241749008.squirrel@secure.ip6.com.au> Hi, With 7.2, is ok to add the following function to the uipc_socket.c file? void nf_sockopt_init(void) { LIST_INIT(&nf_sockopts); mtx_init(&nf_sockopt_mutex,"linux netfilter lock",NULL,MTX_DEF); } Thanks From swun2010 at gmail.com Fri May 8 12:52:44 2009 From: swun2010 at gmail.com (Sam Wun) Date: Fri May 8 12:52:51 2009 Subject: Can pfsync be used over router or WAN? Message-ID: <736c47cb0905080552r70f45368va5dfa5af24720c1c@mail.gmail.com> Hi, Have anyone tried pfsync over router or WAN? I have read setup guide of CARP+pfsync, the pfsync interface is connected through a crossover cable. Can I connect 2 pfsync interfaces through a router or WAN? Thanks From fox at verio.net Fri May 8 17:06:28 2009 From: fox at verio.net (David DeSimone) Date: Fri May 8 17:06:41 2009 Subject: Can pfsync be used over router or WAN? In-Reply-To: <736c47cb0905080552r70f45368va5dfa5af24720c1c@mail.gmail.com> References: <736c47cb0905080552r70f45368va5dfa5af24720c1c@mail.gmail.com> Message-ID: <20090508164432.GW2160@verio.net> Sam Wun wrote: > > Have anyone tried pfsync over router or WAN? > I have read setup guide of CARP+pfsync, the pfsync interface is > connected through a crossover cable. Can I connect 2 pfsync > interfaces through a router or WAN? pfsync(4) talks about this: NETWORK SYNCHRONISATION States can be synchronised between two or more firewalls using this interface, by specifying a synchronisation interface using ifconfig(8). For example, the following command sets fxp0 as the synchronisation interface: # ifconfig pfsync0 syncdev fxp0 It is important that the underlying synchronisation interface is up and has an IP address assigned. By default, state change messages are sent out on the synchronisation interface using IP multicast packets. The protocol is IP protocol 240, PFSYNC, and the multicast group used is 224.0.0.240. When a peer address is specified using the syncpeer keyword, the peer address is used as a destination for the pfsync traffic, and the traffic can then be protected using ipsec(4). In such a configuration, the syncdev should be set to the enc(4) interface, as this is where the traffic arrives when it is decapsulated, e.g.: # ifconfig pfsync0 syncpeer 10.0.0.2 syncdev enc0 It is important that the pfsync traffic be well secured as there is no authentication on the protocol and it would be trivial to spoof packets which create states, bypassing the pf ruleset. Either run the pfsync protocol on a trusted network - ideally a network dedicated to pfsync messages such as a crossover cable between two firewalls, or specify a peer address and protect the traffic with ipsec(4). For pfsync to start its operation automatically at the system boot time, pfsync_enable and pfsync_syncdev variables should be used in rc.conf(5). It is not advisable to set up pfsync with common network interface configuration variables of rc.conf(5) because pfsync must start after its syncdev, which cannot be always ensured in the latter case. Syncing over a WAN doesn't seem like it would make sense, offhand. Normally you psync between devices that will be able to provide routing for a firewalled connection. A device far across a WAN doesn't seem like it would be able to provide redundant service. But that's up to your design, I suppose. Syncing across a LAN could make sense, but you will want to take steps to secure the traffic. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From linimon at FreeBSD.org Fri May 8 18:06:11 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri May 8 18:06:22 2009 Subject: kern/134369: [route] [ip6] IPV6 in Head broken for routing table updates Message-ID: <200905081806.n48I6AgH062542@freefall.freebsd.org> Old Synopsis: IPV6 in Head broken for routing table updates New Synopsis: [route] [ip6] IPV6 in Head broken for routing table updates Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 8 18:05:39 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134369 From mbsd at pacbell.net Fri May 8 18:39:33 2009 From: mbsd at pacbell.net (=?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?=) Date: Fri May 8 18:39:42 2009 Subject: New INTEL firmware v3.1 for device iwi (IPW 2200BG) In-Reply-To: <20090503155746.GB11965@citylink.fud.org.nz> References: <49FD928D.4020504@t-online.de> <20090503155746.GB11965@citylink.fud.org.nz> Message-ID: <20090508111747.Y5904@antec.home> On Sun, 3 May 2009, Andrew Thompson wrote: > On Sun, May 03, 2009 at 02:48:13PM +0200, Dieter Brozio wrote: >> Hi there, >> >> To whom it may concern: >> >> INTEL released in March 2009 a new version 3.1 of its firmware version for >> the WLAN iwi device (Pro/Wireless 2200BG). >> >> http://ipw2200.sourceforge.net/firmware.php >> http://ipw2200.sourceforge.net/firmware.php?fid=8 >> >> On my 7.2.RC2 desktop PC (without WLAN) I noticed that in >> >> /usr/src/sys/contrib/dev/iwi/ipw2200_bss.fw.uu >> /usr/src/sys/contrib/dev/iwi/ipw2200_ibss.fw.uu >> /usr/src/sys/contrib/dev/iwi/ipw2200_sniffer.fw.uu >> >> is still the old v3.0 iwi firmware inside. >> >> This fw generates after some hours of operation error messages like >> "iwi0:scan stuck" and finally the network connection will be disconnected. >> I've tested fw v3.1 this week on my FBSD6.4 laptop: No problems, no "scan >> stuck", no side-effects. Brilliant. > > Great. If anyone can also confirm it works on current then I will > commit. I have been using the new firmware for a couple of days on current with this device: iwi0@pci0:2:1:0: class=0x028000 card=0x27218086 chip=0x42208086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'MPCI3B driverIntel PRO/Wireless 2200BG' class = network No problems observed. $.02, /Mikko From swun2010 at gmail.com Sat May 9 00:54:26 2009 From: swun2010 at gmail.com (Sam Wun) Date: Sat May 9 00:54:32 2009 Subject: Can pfsync be used over router or WAN? In-Reply-To: <20090508164432.GW2160@verio.net> References: <736c47cb0905080552r70f45368va5dfa5af24720c1c@mail.gmail.com> <20090508164432.GW2160@verio.net> Message-ID: <736c47cb0905081754s32d9414fhe89f1920c8675869@mail.gmail.com> Establish a IPSEC bewteen this 2 pfsync points is a way to go. On Sat, May 9, 2009 at 2:44 AM, David DeSimone wrote: > Sam Wun wrote: >> >> Have anyone tried pfsync over router or WAN? >> I have read setup guide of CARP+pfsync, the pfsync interface is >> connected through a crossover cable. ?Can I connect 2 pfsync >> interfaces through a router or WAN? > > pfsync(4) talks about this: > > ? ?NETWORK SYNCHRONISATION > ? ? ? ? States can be synchronised between two or more firewalls using > ? ? ? ? this interface, by specifying a synchronisation interface using > ? ? ? ? ifconfig(8). ?For example, the following command sets fxp0 as > ? ? ? ? the synchronisation interface: > > ? ? ? ? ? # ifconfig pfsync0 syncdev fxp0 > > ? ? ? ? It is important that the underlying synchronisation interface > ? ? ? ? is up and has an IP address assigned. > > ? ? ? ? By default, state change messages are sent out on the > ? ? ? ? synchronisation interface using IP multicast packets. ?The > ? ? ? ? protocol is IP protocol 240, PFSYNC, and the multicast group > ? ? ? ? used is 224.0.0.240. ?When a peer address is specified using > ? ? ? ? the syncpeer keyword, the peer address is used as a destination > ? ? ? ? for the pfsync traffic, and the traffic can then be protected > ? ? ? ? using ipsec(4). ?In such a configuration, the syncdev should > ? ? ? ? be set to the enc(4) interface, as this is where the traffic > ? ? ? ? arrives when it is decapsulated, e.g.: > > ? ? ? ? ? # ifconfig pfsync0 syncpeer 10.0.0.2 syncdev enc0 > > ? ? ? ? It is important that the pfsync traffic be well secured as > ? ? ? ? there is no authentication on the protocol and it would be > ? ? ? ? trivial to spoof packets which create states, bypassing the > ? ? ? ? pf ruleset. ?Either run the pfsync protocol on a trusted > ? ? ? ? network - ideally a network dedicated to pfsync messages such > ? ? ? ? as a crossover cable between two firewalls, or specify a peer > ? ? ? ? address and protect the traffic with ipsec(4). > > ? ? ? ? For pfsync to start its operation automatically at the system > ? ? ? ? boot time, pfsync_enable and pfsync_syncdev variables should be > ? ? ? ? used in rc.conf(5). ?It is not advisable to set up pfsync with > ? ? ? ? common network interface configuration variables of rc.conf(5) > ? ? ? ? because pfsync must start after its syncdev, which cannot be > ? ? ? ? always ensured in the latter case. > > Syncing over a WAN doesn't seem like it would make sense, offhand. > Normally you psync between devices that will be able to provide routing > for a firewalled connection. ?A device far across a WAN doesn't seem > like it would be able to provide redundant service. ?But that's up to > your design, I suppose. > > Syncing across a LAN could make sense, but you will want to take steps > to secure the traffic. > > -- > David DeSimone == Network Admin == fox@verio.net > ?"I don't like spinach, and I'm glad I don't, because if I > ? liked it I'd eat it, and I just hate it." -- Clarence Darrow > > > This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. ?Thank you. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From sam at ip6.com.au Sat May 9 01:54:58 2009 From: sam at ip6.com.au (Sam Wan) Date: Sat May 9 01:55:06 2009 Subject: CARP on FreeBSD 7,2 Message-ID: <11159.220.233.42.226.1241834088.squirrel@secure.ip6.com.au> Hi, I tried to setup CARP in FreeBSD 7.2, but seems not able to assign IP to the carp interfaces. Here is my rc.conf file: hostname="test.ip6.com.au" ifconfig_fxp0="inet 192.168.1.248 netmask 255.255.255.0" sshd_enable="YES" pf_enable="YES" pf_rules="/etc/pf.anti-spam.conf" pf_flags="" pflog_enable="YES" pflog_logfile="/var/log/pflog" pflog_program="/sbin/pflogd" pflog_flags="" pfsync_enable="NO" pfsync_syncdev="" pfsync_ifconfig="" cloned_interfaces="carp1" ifconfig_carp1="up 24.214.165.129/25 vhid 2 pass privatepassword" test:~ # ifconfig fxp0: flags=8843 metric 0 mtu 1500 options=8 ether 00:13:20:65:ad:bd inet 192.168.1.248 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 metric 0 mtu 1500 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 0xff000000 pflog0: flags=141 metric 0 mtu 33204 pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 carp1: flags=9 metric 0 mtu 1500 carp: INIT vhid 1 advbase 1 advskew 50 What have I missed? Thanks From sam at ip6.com.au Sat May 9 02:09:15 2009 From: sam at ip6.com.au (Sam Wan) Date: Sat May 9 02:09:22 2009 Subject: CARP on FreeBSD 7,2 In-Reply-To: <11159.220.233.42.226.1241834088.squirrel@secure.ip6.com.au> References: <11159.220.233.42.226.1241834088.squirrel@secure.ip6.com.au> Message-ID: <11212.220.233.42.226.1241834944.squirrel@secure.ip6.com.au> The following command also failed: test:~ # ifconfig carp1 vhid 1 pass password 192.168.2.144/24 up ifconfig: ioctl (SIOCAIFADDR): Can't assign requested address > > Hi, > > I tried to setup CARP in FreeBSD 7.2, but seems not able to assign IP to > the carp interfaces. > > Here is my rc.conf file: > > hostname="test.ip6.com.au" > ifconfig_fxp0="inet 192.168.1.248 netmask 255.255.255.0" > sshd_enable="YES" > > pf_enable="YES" > pf_rules="/etc/pf.anti-spam.conf" > pf_flags="" > pflog_enable="YES" > pflog_logfile="/var/log/pflog" > pflog_program="/sbin/pflogd" > pflog_flags="" > pfsync_enable="NO" > pfsync_syncdev="" > pfsync_ifconfig="" > > cloned_interfaces="carp1" > ifconfig_carp1="up 24.214.165.129/25 vhid 2 pass privatepassword" > > > test:~ # ifconfig > fxp0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:13:20:65:ad:bd > inet 192.168.1.248 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > plip0: flags=108810 metric 0 mtu > 1500 > 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 0xff000000 > pflog0: flags=141 metric 0 mtu 33204 > pfsync0: flags=0<> metric 0 mtu 1460 > syncpeer: 224.0.0.240 maxupd: 128 > carp1: flags=9 metric 0 mtu 1500 > carp: INIT vhid 1 advbase 1 advskew 50 > > What have I missed? > > Thanks > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From will at firepipe.net Sat May 9 02:16:31 2009 From: will at firepipe.net (Will Andrews) Date: Sat May 9 02:16:37 2009 Subject: CARP on FreeBSD 7,2 In-Reply-To: <11212.220.233.42.226.1241834944.squirrel@secure.ip6.com.au> References: <11159.220.233.42.226.1241834088.squirrel@secure.ip6.com.au> <11212.220.233.42.226.1241834944.squirrel@secure.ip6.com.au> Message-ID: <2aada3410905081916k51f75499ve867cc4be316cdcf@mail.gmail.com> On Fri, May 8, 2009 at 10:09 PM, Sam Wan wrote: > The following command also failed: > > test:~ # ifconfig carp1 vhid 1 pass password 192.168.2.144/24 up > ifconfig: ioctl (SIOCAIFADDR): Can't assign requested address > >> >> Hi, >> >> I tried to setup CARP in FreeBSD 7.2, but seems not able to assign IP to >> the carp interfaces. >> >> Here is my rc.conf file: >> >> hostname="test.ip6.com.au" >> ifconfig_fxp0="inet 192.168.1.248 ?netmask 255.255.255.0" >> sshd_enable="YES" >> >> pf_enable="YES" >> pf_rules="/etc/pf.anti-spam.conf" >> pf_flags="" >> pflog_enable="YES" >> pflog_logfile="/var/log/pflog" >> pflog_program="/sbin/pflogd" >> pflog_flags="" >> pfsync_enable="NO" >> pfsync_syncdev="" >> pfsync_ifconfig="" >> >> cloned_interfaces="carp1" >> ifconfig_carp1="up 24.214.165.129/25 vhid 2 pass privatepassword" >> >> >> test:~ # ifconfig >> fxp0: flags=8843 metric 0 mtu 1500 >> ? ? ? ? options=8 >> ? ? ? ? ether 00:13:20:65:ad:bd >> ? ? ? ? inet 192.168.1.248 netmask 0xffffff00 broadcast 192.168.1.255 >> ? ? ? ? media: Ethernet autoselect (100baseTX ) >> ? ? ? ? status: active >> plip0: flags=108810 metric 0 mtu >> 1500 >> 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 0xff000000 >> pflog0: flags=141 metric 0 mtu 33204 >> pfsync0: flags=0<> metric 0 mtu 1460 >> ? ? ? ? syncpeer: 224.0.0.240 maxupd: 128 >> carp1: flags=9 metric 0 mtu 1500 >> ? ? ? ? carp: INIT vhid 1 advbase 1 advskew 50 >> >> What have I missed? Hi, Currently, the only way to assign an IP address for CARP is to use an IP that is in the same subnet as the physical interface you intend to handle its packets. In other words, since neither 192.168.2.144/24 nor 24.215.165.129/25 are in 192.168.1.248/24, they cannot be assigned to any CARP interface. Eventually, this should be fixed by introducing carpdev, which allows explicitly associating a CARP interface with a physical interface, but it's not there yet. Regards, --Will. From sam at ip6.com.au Sat May 9 02:45:52 2009 From: sam at ip6.com.au (Sam Wan) Date: Sat May 9 02:45:59 2009 Subject: CARP loadbalance vs. IPVS loadbalance Message-ID: <11644.220.233.42.226.1241837142.squirrel@secure.ip6.com.au> Hi, Can anyone give comment and suggestion which loadbalancer is better for FreeBSD (7.2), CARP or IPVS? Thanks From bms at incunabulum.net Sat May 9 18:00:36 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Sat May 9 18:00:43 2009 Subject: Can pfsync be used over router or WAN? In-Reply-To: <736c47cb0905081754s32d9414fhe89f1920c8675869@mail.gmail.com> References: <736c47cb0905080552r70f45368va5dfa5af24720c1c@mail.gmail.com> <20090508164432.GW2160@verio.net> <736c47cb0905081754s32d9414fhe89f1920c8675869@mail.gmail.com> Message-ID: <4A05C4BA.2090506@incunabulum.net> Sam Wun wrote: > Establish a IPSEC bewteen this 2 pfsync points is a way to go. > Yup. The key observation about pfsync is that you can configure the peer(s) for synchronization in the 'syncdev' mode or the 'syncpeer' mode. Unlike CARP, pfsync(4) has no authentication built-in. With syncdev, you are telling pfsync to periodically send out state updates to a link-scope IPv4 multicast group. Obviously, this only works if all the peer(s) are on-link (i.e. the same LAN), and any Layer 2 switches in the middle are configured to forward the multicast traffic. The IGMP code will send a membership report for the 224.0.0.240 address, unless it's configured explicitly to not do so for 224.0.0.0/24 link-scope groups via sysctl, which should appease snooping switches. Note that it defaults to IGMPv3 in HEAD, it should downgrade to v2 or v1 if it sees a v2 Query. This mechanism operates wholly independently of CARP. You can IPSEC encapsulate multicast traffic, but of course that gives rise to 'interesting' key distribution problems. With syncpeer, you are telling pfsync to periodically send out state updates to a *single* peer, not a list, and all such traffic is unicasted. As far as I know, you can't specify multiple peers, so you are limited to 1 other member (unless the peer address is a CARP address, or anycasted by some other mechanism). This should work just fine with IPSEC, provided your key distribution is taken care of. If your WAN link can carry multicast traffic without additional encapsulation (most can, even if they're not link-layer multicast-capable), then using 'syncdev' should work fine, although the IGMP and MLD code in HEAD will suppress sending membership reports on interfaces without the IFF_MULTICAST flag. This doesn't disallow the stack from sending multicast traffic, though. [This should perhaps be revisited, because I can think of situations where the WAN link may not have a native link-layer multicast capability, but it's still desirable for the IGMP/MLD reports to go upstream, i.e. DSL in ATM native mode. Userland PPP via tun(4) needs to be told to enable IFF_MULTICAST with the TUNSIFMODE ioctl]. For those who are interested in experiments: pfsync(4) could in theory be enhanced to use Source-Specific Multicast (SSM) for pushing pf state to multiple border firewalls inside an AS boundary -- but it would require knowing all the addresses of the peer(s), and you'd be dependent on a multicast routing protocol like PIM at a minimum for distributing the traffic throughout your AS, as well as needing a unicast routing IGP for the traffic to pass the uRPF checks. It would be desirable to use a different address for this than 224.0.0.240. You could probably get away with Any-Source Multicast (ASM) for distributing the pfsync updates, but I'd advise against that, as ASM is a little bit harder to secure -- you don't/can't control the endpoints without explicit firewall rules, and of course that introduces recursion (you're having to firewall your firewall updates...) For kernel hacking: The KPIs involved require that kernel consumers do their own SSM housekeeping, though -- splicing of consumer layer memberships is only done for sockets, and you'd have to craft your own RB-trees, although the multicast code takes care of knitting together the right state-change reports to send upstream, doing filter matches etc -- that's a different matter. It's for this reason that SSM apps are generally best written in userland. Doing SSM in-kernel is possible, sure, but the whole point of using a socket for it is that a load of stuff gets taken care of for you, and using a socket in-kernel is still irksome. Obviously the more mechanisms you introduce to push out the updates, the wider the range of possible points of failure you introduce. pfsync is cool because it's a tightly integrated solution to a common problem in its space, but it may not be the right choice for all folks in its present state. ... By the way, does anyone out there have patches to get pfsync(4) to work over IPv6? cheers, BMS From sam at ip6.com.au Sun May 10 02:15:03 2009 From: sam at ip6.com.au (Sam Wan) Date: Sun May 10 02:15:10 2009 Subject: IPSEC_ESP and IPSEC_FILTERGIF in 7.2 kernel config file Message-ID: <26744.220.233.42.226.1241921689.squirrel@secure.ip6.com.au> I tried to build a kernel include the following options, but it failed with something like "unknown option IPSEC_ESP and IPSEC_FILTERGIF..." options IPSEC #IP security options IPSEC_ESP #IP security options IPSEC_FILTERGIF #filter ipsec packets from a tunnel #options IPSEC_NAT_T How do I enable ipsec in 7.2? do I have to rebuild the kernel with the IPSEC options built-in? and which options are supported at the moment? Thanks From mike at sentex.net Sun May 10 02:59:48 2009 From: mike at sentex.net (Mike Tancsa) Date: Sun May 10 02:59:55 2009 Subject: IPSEC_ESP and IPSEC_FILTERGIF in 7.2 kernel config file In-Reply-To: <26744.220.233.42.226.1241921689.squirrel@secure.ip6.com.au > References: <26744.220.233.42.226.1241921689.squirrel@secure.ip6.com.au> Message-ID: <200905100234.n4A2Y3RT009883@lava.sentex.ca> At 10:14 PM 5/9/2009, Sam Wan wrote: >How do I enable ipsec in 7.2? do I have to rebuild the kernel with the >IPSEC options built-in? and which options are supported at the moment? On 7.x, you need to rebuild your kernel with options IPSEC device crypto and optionally options IPSEC_FILTERTUNNEL If you add IPSEC_FILTERTUNNEL, you might as well add device enc ---Mike ---Mike From sam at ip6.com.au Sun May 10 04:52:38 2009 From: sam at ip6.com.au (Sam Wan) Date: Sun May 10 04:52:44 2009 Subject: kernel hang when reboot with loaded ip_vs_rr.ko Message-ID: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> I built ip_vs_rr.ko in 7.2 Release. There is no problem when loaded ipvs.ko. After I loaded ip_vs_rr.ko, and reboot the system, the entire system is hang. Here is a list of the ip_vs moudles have built: modules # ls -l total 118 drwxr-xr-x 2 root wheel 512 May 8 15:20 ./ drwxr-xr-x 8 root wheel 512 May 9 21:22 ../ -r-xr-xr-x 1 root wheel 5366 May 8 15:20 ip_vs_dh.ko* -r-xr-xr-x 1 root wheel 8249 May 8 15:20 ip_vs_lblc.ko* -r-xr-xr-x 1 root wheel 9783 May 8 15:20 ip_vs_lblcr.ko* -r-xr-xr-x 1 root wheel 4560 May 8 15:20 ip_vs_lc.ko* -r-xr-xr-x 1 root wheel 4592 May 8 15:20 ip_vs_nq.ko* -r-xr-xr-x 1 root wheel 4838 May 8 15:20 ip_vs_rr.ko* -r-xr-xr-x 1 root wheel 4574 May 8 15:20 ip_vs_sed.ko* -r-xr-xr-x 1 root wheel 5366 May 8 15:20 ip_vs_sh.ko* -r-xr-xr-x 1 root wheel 4574 May 8 15:20 ip_vs_wlc.ko* -r-xr-xr-x 1 root wheel 5634 May 8 15:20 ip_vs_wrr.ko* -r-xr-xr-x 1 root wheel 43081 May 8 15:20 ipvs.ko* -rw-r--r-- 1 root wheel 360 May 8 15:20 linker.hints What is the problem? Important is how to get more information about this kernel module is hang? Your suggestion is highly appreciated. Thanks From swun2010 at gmail.com Sun May 10 06:58:34 2009 From: swun2010 at gmail.com (Sam Wun) Date: Sun May 10 06:58:41 2009 Subject: kernel hang when reboot with loaded ip_vs_rr.ko In-Reply-To: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> Message-ID: <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> It is IPVS patch, for FreeBSD. I am in Melbourne Australia. Can you send me email regarding about how to fix this issue? BTW, if I kldunload ip_vs_rr before reboot/shutdown, the system will execute the reboot / shutdown normally. When I executed reboot/shutdown with the ip_vs_rr still loaded in the kernel, the system hangs after the console printed the message "...vnode...." Here are the modules loaded: # kldstat Id Refs Address Size Name 1 5 0xc0400000 a434d8 kernel 2 1 0xc0e44000 6a45c acpi.ko 3 1 0xc469d000 2000 ip_vs_rr.ko 4 1 0xc469f000 b000 ipvs.ko # shutdown -h now ..... Syncing disks, vnodes remaining... 1 1 0 0 done All buffers synced. IPVS: ipvs unloaded then it hangs forever. Another problem is I can't put ipvs_vs_rr_load="yes" in the /boot/loader.conf file. The system will hang when it tried to boot the kernel with this ko loaded. Thanks On Sun, May 10, 2009 at 2:52 PM, Sam Wan wrote: > I built ip_vs_rr.ko in 7.2 Release. > There is no problem when loaded ipvs.ko. > After I loaded ip_vs_rr.ko, and reboot the system, the entire system is hang. > Here is a list of the ip_vs moudles have built: > > modules # ls -l > total 118 > drwxr-xr-x ?2 root ?wheel ? ?512 May ?8 15:20 ./ > drwxr-xr-x ?8 root ?wheel ? ?512 May ?9 21:22 ../ > -r-xr-xr-x ?1 root ?wheel ? 5366 May ?8 15:20 ip_vs_dh.ko* > -r-xr-xr-x ?1 root ?wheel ? 8249 May ?8 15:20 ip_vs_lblc.ko* > -r-xr-xr-x ?1 root ?wheel ? 9783 May ?8 15:20 ip_vs_lblcr.ko* > -r-xr-xr-x ?1 root ?wheel ? 4560 May ?8 15:20 ip_vs_lc.ko* > -r-xr-xr-x ?1 root ?wheel ? 4592 May ?8 15:20 ip_vs_nq.ko* > -r-xr-xr-x ?1 root ?wheel ? 4838 May ?8 15:20 ip_vs_rr.ko* > -r-xr-xr-x ?1 root ?wheel ? 4574 May ?8 15:20 ip_vs_sed.ko* > -r-xr-xr-x ?1 root ?wheel ? 5366 May ?8 15:20 ip_vs_sh.ko* > -r-xr-xr-x ?1 root ?wheel ? 4574 May ?8 15:20 ip_vs_wlc.ko* > -r-xr-xr-x ?1 root ?wheel ? 5634 May ?8 15:20 ip_vs_wrr.ko* > -r-xr-xr-x ?1 root ?wheel ?43081 May ?8 15:20 ipvs.ko* > -rw-r--r-- ?1 root ?wheel ? ?360 May ?8 15:20 linker.hints > > What is the problem? > Important is how to get more information about this kernel module is ?hang? > > Your suggestion is highly appreciated. > > Thanks > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From swun2010 at gmail.com Sun May 10 07:25:58 2009 From: swun2010 at gmail.com (Sam Wun) Date: Sun May 10 07:26:15 2009 Subject: kernel hang when reboot with loaded ip_vs_rr.ko In-Reply-To: References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> Message-ID: <736c47cb0905100025i8bf54fev3466e49d28809197@mail.gmail.com> That patch is for 7.0-current. But I applied to 7.2 Release, and built successfully. Manually kldload and kldunload has no problem. On Sun, May 10, 2009 at 5:16 PM, Adrian Chadd wrote: > What version of FreeBSD is the IPVS patch for? > > And hi from Perth. :) What are you guys doing with FreeBSD in > particular out there? > > > > Adrian > > 2009/5/10 Sam Wun : >> It is IPVS patch, for FreeBSD. >> I am in Melbourne Australia. >> Can you send me email regarding about how to fix this issue? >> BTW, if I kldunload ip_vs_rr before reboot/shutdown, the system will >> execute the reboot / shutdown normally. >> When I executed reboot/shutdown with the ip_vs_rr still loaded in the >> kernel, the system hangs after the console printed the message >> "...vnode...." >> >> Here are the modules loaded: >> # kldstat >> Id Refs Address ? ?Size ? ? Name >> ?1 ? ?5 0xc0400000 a434d8 ? kernel >> ?2 ? ?1 0xc0e44000 6a45c ? ?acpi.ko >> ?3 ? ?1 0xc469d000 2000 ? ? ip_vs_rr.ko >> ?4 ? ?1 0xc469f000 b000 ? ? ipvs.ko >> >> ?# shutdown -h now >> ..... >> Syncing disks, vnodes remaining... 1 1 0 0 done >> All buffers synced. >> IPVS: ipvs unloaded >> >> then it hangs forever. >> >> Another problem is I can't put ipvs_vs_rr_load="yes" in the >> /boot/loader.conf file. The system will hang when it tried to boot the >> kernel with this ko loaded. >> >> Thanks >> >> >> On Sun, May 10, 2009 at 2:52 PM, Sam Wan wrote: >>> I built ip_vs_rr.ko in 7.2 Release. >>> There is no problem when loaded ipvs.ko. >>> After I loaded ip_vs_rr.ko, and reboot the system, the entire system is hang. >>> Here is a list of the ip_vs moudles have built: >>> >>> modules # ls -l >>> total 118 >>> drwxr-xr-x ?2 root ?wheel ? ?512 May ?8 15:20 ./ >>> drwxr-xr-x ?8 root ?wheel ? ?512 May ?9 21:22 ../ >>> -r-xr-xr-x ?1 root ?wheel ? 5366 May ?8 15:20 ip_vs_dh.ko* >>> -r-xr-xr-x ?1 root ?wheel ? 8249 May ?8 15:20 ip_vs_lblc.ko* >>> -r-xr-xr-x ?1 root ?wheel ? 9783 May ?8 15:20 ip_vs_lblcr.ko* >>> -r-xr-xr-x ?1 root ?wheel ? 4560 May ?8 15:20 ip_vs_lc.ko* >>> -r-xr-xr-x ?1 root ?wheel ? 4592 May ?8 15:20 ip_vs_nq.ko* >>> -r-xr-xr-x ?1 root ?wheel ? 4838 May ?8 15:20 ip_vs_rr.ko* >>> -r-xr-xr-x ?1 root ?wheel ? 4574 May ?8 15:20 ip_vs_sed.ko* >>> -r-xr-xr-x ?1 root ?wheel ? 5366 May ?8 15:20 ip_vs_sh.ko* >>> -r-xr-xr-x ?1 root ?wheel ? 4574 May ?8 15:20 ip_vs_wlc.ko* >>> -r-xr-xr-x ?1 root ?wheel ? 5634 May ?8 15:20 ip_vs_wrr.ko* >>> -r-xr-xr-x ?1 root ?wheel ?43081 May ?8 15:20 ipvs.ko* >>> -rw-r--r-- ?1 root ?wheel ? ?360 May ?8 15:20 linker.hints >>> >>> What is the problem? >>> Important is how to get more information about this kernel module is ?hang? >>> >>> Your suggestion is highly appreciated. >>> >>> Thanks >>> >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From maciej at suszko.eu Sun May 10 08:14:10 2009 From: maciej at suszko.eu (Maciej Suszko) Date: Sun May 10 08:14:18 2009 Subject: kernel hang when reboot with loaded ip_vs_rr.ko In-Reply-To: <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> Message-ID: <20090510094721.32a7f4bf@suszko.eu> Sam Wun wrote: > It is IPVS patch, for FreeBSD. > I am in Melbourne Australia. > Can you send me email regarding about how to fix this issue? > BTW, if I kldunload ip_vs_rr before reboot/shutdown, the system will > execute the reboot / shutdown normally. > When I executed reboot/shutdown with the ip_vs_rr still loaded in the > kernel, the system hangs after the console printed the message > "...vnode...." > > Here are the modules loaded: > # kldstat > Id Refs Address Size Name > 1 5 0xc0400000 a434d8 kernel > 2 1 0xc0e44000 6a45c acpi.ko > 3 1 0xc469d000 2000 ip_vs_rr.ko > 4 1 0xc469f000 b000 ipvs.ko > > # shutdown -h now > ..... > Syncing disks, vnodes remaining... 1 1 0 0 done > All buffers synced. > IPVS: ipvs unloaded > > then it hangs forever. > > Another problem is I can't put ipvs_vs_rr_load="yes" in the > /boot/loader.conf file. The system will hang when it tried to boot the > kernel with this ko loaded. Hi, Check the freebsd-clister archive - AFAIR I've tested ipvs+keepalived a time ago and the panic problem was already known. Someone even sent some rc scripts to mailing list. It was a year ago or so... -- regards, Maciej Suszko. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090510/873f9eea/signature.pgp From sam at ip6.com.au Sun May 10 10:51:38 2009 From: sam at ip6.com.au (Sam Wan) Date: Sun May 10 10:51:46 2009 Subject: kernel hang when reboot with loaded ip_vs_rr.ko In-Reply-To: <20090510094721.32a7f4bf@suszko.eu> References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> <20090510094721.32a7f4bf@suszko.eu> Message-ID: <19656.220.233.42.226.1241952684.squirrel@secure.ip6.com.au> Unfortunately, after started ip_vs_rr with this script, reboot still failed, but interestingly, system shutdown is running fine with these moduels loaded. Thanks Sam > Sam Wun wrote: >> It is IPVS patch, for FreeBSD. >> I am in Melbourne Australia. >> Can you send me email regarding about how to fix this issue? >> BTW, if I kldunload ip_vs_rr before reboot/shutdown, the system will >> execute the reboot / shutdown normally. >> When I executed reboot/shutdown with the ip_vs_rr still loaded in the >> kernel, the system hangs after the console printed the message >> "...vnode...." >> >> Here are the modules loaded: >> # kldstat >> Id Refs Address Size Name >> 1 5 0xc0400000 a434d8 kernel >> 2 1 0xc0e44000 6a45c acpi.ko >> 3 1 0xc469d000 2000 ip_vs_rr.ko >> 4 1 0xc469f000 b000 ipvs.ko >> >> # shutdown -h now >> ..... >> Syncing disks, vnodes remaining... 1 1 0 0 done >> All buffers synced. >> IPVS: ipvs unloaded >> >> then it hangs forever. >> >> Another problem is I can't put ipvs_vs_rr_load="yes" in the >> /boot/loader.conf file. The system will hang when it tried to boot the >> kernel with this ko loaded. > > Hi, > > Check the freebsd-clister archive - AFAIR I've tested ipvs+keepalived a > time ago and the panic problem was already known. Someone even sent > some rc scripts to mailing list. It was a year ago or so... > -- > regards, Maciej Suszko. > From maciej at suszko.eu Sun May 10 12:16:21 2009 From: maciej at suszko.eu (Maciej Suszko) Date: Sun May 10 12:16:28 2009 Subject: kernel hang when reboot with loaded ip_vs_rr.ko In-Reply-To: <19656.220.233.42.226.1241952684.squirrel@secure.ip6.com.au> References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> <20090510094721.32a7f4bf@suszko.eu> <19656.220.233.42.226.1241952684.squirrel@secure.ip6.com.au> Message-ID: <20090510141609.3a11b5eb@suszko.eu> "Sam Wan" wrote: > Unfortunately, after started ip_vs_rr with this script, reboot still > failed, but interestingly, system shutdown is running fine with these > moduels loaded. > > Thanks > Sam > > > Sam Wun wrote: > >> It is IPVS patch, for FreeBSD. > >> I am in Melbourne Australia. > >> Can you send me email regarding about how to fix this issue? > >> BTW, if I kldunload ip_vs_rr before reboot/shutdown, the system > >> will execute the reboot / shutdown normally. > >> When I executed reboot/shutdown with the ip_vs_rr still loaded in > >> the kernel, the system hangs after the console printed the message > >> "...vnode...." > >> > >> Here are the modules loaded: > >> # kldstat > >> Id Refs Address Size Name > >> 1 5 0xc0400000 a434d8 kernel > >> 2 1 0xc0e44000 6a45c acpi.ko > >> 3 1 0xc469d000 2000 ip_vs_rr.ko > >> 4 1 0xc469f000 b000 ipvs.ko > >> > >> # shutdown -h now > >> ..... > >> Syncing disks, vnodes remaining... 1 1 0 0 done > >> All buffers synced. > >> IPVS: ipvs unloaded > >> > >> then it hangs forever. > >> > >> Another problem is I can't put ipvs_vs_rr_load="yes" in the > >> /boot/loader.conf file. The system will hang when it tried to boot > >> the kernel with this ko loaded. > > > > Hi, > > > > Check the freebsd-clister archive - AFAIR I've tested > > ipvs+keepalived a time ago and the panic problem was already known. > > Someone even sent some rc scripts to mailing list. It was a year > > ago or so... 1) Answer below the text. 2) The 'reboot' command should be used only when you're in single mode. Use shutdown -r to clean reboot as written in reboot(8) and shutdown(8). I haven't looked at the script, but I think everything should be fine if modules are loaded on boot and unloaded before reboot (within some start/stop action). -- regards, Maciej Suszko. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090510/e4cd4965/signature.pgp From sam at ip6.com.au Sun May 10 12:21:07 2009 From: sam at ip6.com.au (Sam Wan) Date: Sun May 10 12:21:14 2009 Subject: kernel hang when reboot with loaded ip_vs_rr.ko In-Reply-To: <20090510141609.3a11b5eb@suszko.eu> References: <27634.220.233.42.226.1241931139.squirrel@secure.ip6.com.au> <736c47cb0905092358j24d4b631odf2cfd23b285fadc@mail.gmail.com> <20090510094721.32a7f4bf@suszko.eu> <19656.220.233.42.226.1241952684.squirrel@secure.ip6.com.au> <20090510141609.3a11b5eb@suszko.eu> Message-ID: <20813.220.233.42.226.1241958053.squirrel@secure.ip6.com.au> > > 1) Answer below the text. > 2) The 'reboot' command should be used only when you're in single mode. > Use shutdown -r to clean reboot as written in reboot(8) and > shutdown(8). Ok, confirmed shutdown -r works with ip_* loaded. > I haven't looked at the script, but I think everything should be fine > if modules are loaded on boot and unloaded before reboot (within some > start/stop action). > -- Now, I will give it a shot and see how it handle keeplive for two web servers. Will keep you posted. Thanks Sam > regards, Maciej Suszko. > From info at lottery.co.uk Sun May 10 15:50:26 2009 From: info at lottery.co.uk (UK NATIONAL LOTTERY) Date: Sun May 10 15:50:37 2009 Subject: National Lottery: Your Email Won Message-ID: <20090510153332.D68973C070@hm1207.locaweb.com.br> United Kingdom National Lottery 101 Bovill Road, London SE23 1EL United Kingdom File #: EGS/2251256003/02 Congratulations, we are pleased to inform you of the result of the United Kingdom National Lottery Award Winners. Your email address have been randomly selected as a winner in the ongoing United Kingdom National Lottery Online program, the draw was held on 30th April, 2009 using a computerized balloting system of selection. The United Kingdom National Lottery is aimed and focused at global development and improvement of living standard across the world. Free £77 Million Pounds won including *four* Ten Million Pounds Winners and *fourteen* Millionaires plus thousands of other cash prizes. Winner from all over the world, India, France, Singapore, USA, United Kingdom, Spain, South America, Malaysia, Indonesia, South Africa, Belgium, Denmark, Ireland and many more. We wish to express our sincere apologies for the late notification, this free award online program is been conducted bi-quarterly. United Kingdom National Lottery Free Award draw was conducted at the Europe Issuing Centre, you were selected from an exclusive list of 1,000,000,000 e-mail addresses of internet users from the following categories; consumers, professionals and corporate bodies picked by an advanced automated random computer ballot search from the internet 'NO TICKETS OR DRAFTS WERE SOLD'. Your email address attached to Security File #: EGS/2251256003/02 with Serial number No: 002839 emerged as a winner of Six Hundred Thousand Pounds (£600.000.00 GBP), therefore you are eligible to file claim for your prize as one of our lucky winners for the payout of your total sum after a thorough verification that will be conducted by our various credible financial institutions. This online program is precisely aimed at enabling all internet users across the world benefit from the United Kingdom National Lottery, your email address falls within the First Category Winner as such your file has been designated to our European Centre, where the complete verification and payout will be conducted only if there are no exceptions during the claims process, to file your claim immediately please contact our International Programs Director Anderson Spencer with the following information: 1. Name in full----------------------------------------- 2. Phone/Fax------------------------------------------- 3. Occupation------------------------------------------ TO: Contact Person: Anderson Spencer European Payment Issuing Office Tel: +447024065192 (8am - 5pm GMT) Fax: +447092894160 Email: zonal.anderson-spencer@msn.com NOTE: In order to benefit from this program, you are advised in your own best interest to file your claim not later than 7days days from the date of this notification to avoid disqualification; anybody under the age of 18 is automatically disqualified. Please include this File #: EGS/2251256003/02 in every of your correspondence with our Foreign Service Director Anderson Spencer. IMPORTANT: Solemn confidentiality should be ensured until successful remittance of your prize to you to avoid undue taking of advantage, unwarranted claim and abuse of program, any breach of confidentiality on the part of the winner will result to automatic disqualification. Sincerely Yours, Mrs. Julie Van Hans, Executive Director. United Kingdom National Lottery. From FreeBSD-gnats-submit at FreeBSD.org Sun May 10 16:40:02 2009 From: FreeBSD-gnats-submit at FreeBSD.org (FreeBSD-gnats-submit@FreeBSD.org) Date: Sun May 10 16:40:19 2009 Subject: ports/134429: Update databases/tora from 1.3.22 to 2.0.0 In-Reply-To: Your message of Sun, 10 May 2009 16:36:16 GMT <200905101636.n4AGaGTf015369@www.freebsd.org> Message-ID: <200905101640.n4AGe2qM034402@freefall.freebsd.org> Thank you very much for your problem report. It has the internal identification `ports/134429'. The individual assigned to look at your report is: freebsd-ports-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=134429 >Category: ports >Responsible: freebsd-ports-bugs >Synopsis: Update databases/tora from 1.3.22 to 2.0.0 >Arrival-Date: Sun May 10 16:40:01 UTC 2009 From gperez at entel.upc.edu Mon May 11 07:43:16 2009 From: gperez at entel.upc.edu (=?ISO-8859-1?Q?Gustau_P=E9rez?=) Date: Mon May 11 07:43:23 2009 Subject: Problem/freezes with if_bwi and firmware Message-ID: <4A07D68D.9090006@entel.upc.edu> Hi, I'm using a Broadcom BCM4312 with i386 FreeBSD-8.0 updated May 08 2009. Ports up to date. Using net/bwi-firmware-kmod. Loading first bwi_v3_ucode and then if_bwi. When starting the supplicant, it associates fine and it works for a period of time. From time to time I start to lose signal, I'm my log I can see the following message : May 11 08:42:51 gusiport kernel: bwi0: firmware rev 0x0127, patch level 0x000e May 11 08:42:51 gusiport kernel: bwi0: bwi_intr: intr PHY TX error Many of those messages per second. This is the first problem with if_bwi. It forces me to restart by hand the wlan1 device associated to bwi0. And here comes the freeze (the second problem I encountered). If I try restarting like this : /etc/rc.d/netif stop wlan1 && /etc/rc.d/netif start wlan1 it works (until the PHY TX error appears againg). If I try like : /etc/rc.d/netif restart or if I try : /etc/rc.d/netif stop bwi0 the machine freezes. If i try to kldunload the module while in use (if there's a wlan device created) the machine freezes too. It can be unloaded only if there is not any wlan associated to the bwi device. From bugmaster at FreeBSD.org Mon May 11 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 11 11:08:47 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200905111107.n4BB70MV086037@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem o kern/132984 net [netgraph] swi1: net 100% cpu usage f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 299 problems total. From adamk at voicenet.com Mon May 11 11:50:05 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Mon May 11 11:50:15 2009 Subject: kern/131153: [iwi] iwi doesn't see a wireless network Message-ID: <200905111150.n4BBo47C046870@freefall.freebsd.org> The following reply was made to PR kern/131153; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-followup@FreeBSD.org, adamk@voicenet.com Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network Date: Mon, 11 May 2009 07:36:05 -0400 Upgrading to the latest firmware from Intel (following these directions: http://forums.freebsd.org/showthread.php?t=3849 ) did not change anything. It did not, however, negatively impact anything, either. Adam From linimon at FreeBSD.org Mon May 11 16:42:49 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 11 16:43:01 2009 Subject: kern/134220: [ng_netflow] [patch]: incorrect comparison in ng_netflow_rcvmsg() Message-ID: <200905111642.n4BGgmv7054864@freefall.freebsd.org> Old Synopsis: ng_netflow(4): incorrect comparison in ng_netflow_rcvmsg() New Synopsis: [ng_netflow] [patch]: incorrect comparison in ng_netflow_rcvmsg() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 11 16:42:26 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134220 From linimon at FreeBSD.org Tue May 12 04:27:31 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue May 12 04:27:42 2009 Subject: kern/134401: [msk] [panic] Kernel Fatal trap 12: page fault while in kernel mode at boot time; if_msk eth device module Message-ID: <200905120427.n4C4RUV9096720@freefall.freebsd.org> Old Synopsis: Kernel Fatal trap 12: page fault while in kernel mode at boot time; if_msk eth device module New Synopsis: [msk] [panic] Kernel Fatal trap 12: page fault while in kernel mode at boot time; if_msk eth device module Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 12 04:27:05 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134401 From mv at thebeastie.org Tue May 12 06:18:28 2009 From: mv at thebeastie.org (Michael Vince) Date: Tue May 12 06:18:34 2009 Subject: Awful forwarding rate [7.2-Release, igb] In-Reply-To: <49FF706F.1050209@csa.ru> References: <49FF706F.1050209@csa.ru> Message-ID: <4A090FFF.3070105@thebeastie.org> Also make sure that the route for this specific test isn't going out on the Internet and coming back in at your outside link speed of around117kbits/sec? I had a similar problem once where I had 3 boxes hooked up and the speeds were blistering fast for 2 tests but the third test was horrid slow. Turns out I simply forgot to add the route so the packets jumped across the local network, instead the packets were taking a route of a pointless jump out to my first upstream provider and back again :) Mike Oleg Baranov wrote: > 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 sec 160 KBytes 117 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 GBytes 933 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 GBytes 930 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 0xffffff00 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 0xff000000 > lagg0: flags=8843 metric 0 mtu > 1500 > options=19b > ether 00:30:48:c8:19:67 > inet 192.168.111.254 netmask 0xffffff00 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 0xffffffff > > > 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-unsubscribe@freebsd.org" From jhb at FreeBSD.org Tue May 12 14:12:07 2009 From: jhb at FreeBSD.org (jhb@FreeBSD.org) Date: Tue May 12 14:12:22 2009 Subject: kern/134486: Wrong MSS in outgoing packets for non-default (1460) MSS Message-ID: <200905121412.n4CEC6jB036479@freefall.freebsd.org> Synopsis: Wrong MSS in outgoing packets for non-default (1460) MSS Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: jhb Responsible-Changed-When: Tue May 12 14:11:35 UTC 2009 Responsible-Changed-Why: This is a network stack issue, not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=134486 From linimon at FreeBSD.org Tue May 12 22:43:21 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue May 12 22:43:47 2009 Subject: kern/118238: [bce] [patch] bce driver shows "no carrier" on Intel SBXD132 blade (based on IBM HS21) Message-ID: <200905122243.n4CMhKSD027662@freefall.freebsd.org> Old Synopsis: [bce] bce driver shows "no carrier" on Intel SBXD132 blade (based on IBM HS21) New Synopsis: [bce] [patch] bce driver shows "no carrier" on Intel SBXD132 blade (based on IBM HS21) Responsible-Changed-From-To: benno->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 12 22:42:45 UTC 2009 Responsible-Changed-Why: Reassign this to freebsd-net, to try to get it some attention before 8.0. http://www.freebsd.org/cgi/query-pr.cgi?pr=118238 From mav at FreeBSD.org Wed May 13 02:28:25 2009 From: mav at FreeBSD.org (mav@FreeBSD.org) Date: Wed May 13 02:28:31 2009 Subject: kern/134220: [ng_netflow] [patch]: incorrect comparison in ng_netflow_rcvmsg() Message-ID: <200905130228.n4D2SO4a022645@freefall.freebsd.org> Synopsis: [ng_netflow] [patch]: incorrect comparison in ng_netflow_rcvmsg() State-Changed-From-To: open->patched State-Changed-By: mav State-Changed-When: Wed May 13 02:27:03 UTC 2009 State-Changed-Why: Patch committed to 8-CURRENT. http://www.freebsd.org/cgi/query-pr.cgi?pr=134220 From dfilter at FreeBSD.ORG Wed May 13 02:30:04 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed May 13 02:30:11 2009 Subject: kern/134220: commit references a PR Message-ID: <200905130230.n4D2U24R022911@freefall.freebsd.org> The following reply was made to PR kern/134220; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/134220: commit references a PR Date: Wed, 13 May 2009 02:26:48 +0000 (UTC) Author: mav Date: Wed May 13 02:26:34 2009 New Revision: 192032 URL: http://svn.freebsd.org/changeset/base/192032 Log: Fix copy-paste bug in NGM_NETFLOW_SETCONFIG argument size verification. PR: kern/134220 Submitted by: Eugene Mychlo MFC after: 1 week Modified: head/sys/netgraph/netflow/ng_netflow.c Modified: head/sys/netgraph/netflow/ng_netflow.c ============================================================================== --- head/sys/netgraph/netflow/ng_netflow.c Wed May 13 00:04:08 2009 (r192031) +++ head/sys/netgraph/netflow/ng_netflow.c Wed May 13 02:26:34 2009 (r192032) @@ -422,7 +422,7 @@ ng_netflow_rcvmsg (node_p node, item_p i { struct ng_netflow_setconfig *set; - if (msg->header.arglen != sizeof(struct ng_netflow_settimeouts)) + if (msg->header.arglen != sizeof(struct ng_netflow_setconfig)) ERROUT(EINVAL); set = (struct ng_netflow_setconfig *)msg->data; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From delphij at FreeBSD.org Wed May 13 04:51:50 2009 From: delphij at FreeBSD.org (delphij@FreeBSD.org) Date: Wed May 13 04:51:56 2009 Subject: kern/134486: [tcp] Wrong MSS in outgoing packets for non-default (1460) MSS Message-ID: <200905130451.n4D4pnOX024551@freefall.freebsd.org> Synopsis: [tcp] Wrong MSS in outgoing packets for non-default (1460) MSS State-Changed-From-To: open->closed State-Changed-By: delphij State-Changed-When: Wed May 13 04:49:34 UTC 2009 State-Changed-Why: This is known issue, a possible workaround would be to disable TSO on fxp(4). A true fix is to apply this patch: # cd /tmp # fetch -o fxp.tso.patch "http://svn.freebsd.org/viewvc/base/head/sys/dev/fxp/if_fxp.c?r1=190982&r2=188176&view=patch" # cd /usr/src/sys/dev/fxp # patch -p4 < /tmp/fxp.tso.patch Rebuild, install kernel and reboot. Responsible-Changed-From-To: freebsd-net->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Wed May 13 04:49:34 UTC 2009 Responsible-Changed-Why: Take so I can receive further information if this was wrongly closed. http://www.freebsd.org/cgi/query-pr.cgi?pr=134486 From brett at lariat.net Wed May 13 17:18:15 2009 From: brett at lariat.net (Brett Glass) Date: Wed May 13 17:18:24 2009 Subject: MAC locking and filtering in FreeBSD Message-ID: <200905131648.KAA15455@lariat.net> I need to find a way to do "MAC address locking" in FreeBSD -- that is, to ensure that only a machine with a particular MAC address can use a particular IP address. Unfortunately, it appears that rules in FreeBSD's IPFW are "stuck" on one layer: rules that look at Layer 2 information in a packet can't look at Layer 3, and vice versa. Is there a way to work around this to do MAC address locking and/or other functions that involve looking at Layer 2 and Layer 3 simultaneously? --Brett Glass From stefan.lambrev at moneybookers.com Wed May 13 18:57:09 2009 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Wed May 13 18:57:15 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905131648.KAA15455@lariat.net> References: <200905131648.KAA15455@lariat.net> Message-ID: <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> Hi, apr -S (or -s) is not helping? Have in mind that this is not a real security as it's very easy to change your MAC. On May 13, 2009, at 7:48 PM, Brett Glass wrote: > I need to find a way to do "MAC address locking" in FreeBSD -- that > is, to ensure that only a machine with a particular MAC address can > use a particular IP address. Unfortunately, it appears that rules in > FreeBSD's IPFW are "stuck" on one layer: rules that look at Layer 2 > information in a packet can't look at Layer 3, and vice versa. Is > there a way to work around this to do MAC address locking and/or > other functions that involve looking at Layer 2 and Layer 3 > simultaneously? > > --Brett Glass > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From brett at lariat.net Wed May 13 19:03:41 2009 From: brett at lariat.net (Brett Glass) Date: Wed May 13 19:03:47 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> Message-ID: <200905131903.NAA17981@lariat.net> Stefan: You are correct: This is not real security. In fact, I would argue that it's not security at all. But many businesses that have to maintain hotspots -- especially some hotel chains -- are "allergic" to any sort of serious security. This is because a small but vocal subset of their customers just want to get on the Net and complain about any sort of security. Even having to enter a password or a WEP key irks them. (I personally think that these people are ignorant fools and are setting themselves up for identity theft and worse, but that's just me. And the businesses seem more willing to allow piracy of their Wi-Fi than to irritate these boneheads.) Also, these systems have to be usable by some fairly lame devices -- e.g. an XBox -- that aren't really computers and don't have the capability to run secure protocols or even a particularly good Web browser built in. So, painful as it is, I have to help these guys implement systems which "bless" MAC addresses. The "arp -s" command can sort of lock an IP to a MAC address, but awkwardly and only for outbound packets. What I'd like is to get this into the firewall, so I can not only block spoofing but trigger a log entry when it happens. --Brett At 12:46 PM 5/13/2009, Stefan Lambrev wrote: >Hi, > >apr -S (or -s) is not helping? >Have in mind that this is not a real security as it's very easy to change your MAC. > >On May 13, 2009, at 7:48 PM, Brett Glass wrote: > >>I need to find a way to do "MAC address locking" in FreeBSD -- that is, to ensure that only a machine with a particular MAC address can use a particular IP address. Unfortunately, it appears that rules in FreeBSD's IPFW are "stuck" on one layer: rules that look at Layer 2 information in a packet can't look at Layer 3, and vice versa. Is there a way to work around this to do MAC address locking and/or other functions that involve looking at Layer 2 and Layer 3 simultaneously? >> >>--Brett Glass >> >>_______________________________________________ >>freebsd-net@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-net >>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >-- >Best Wishes, >Stefan Lambrev >ICQ# 24134177 > > > > From stefan.lambrev at moneybookers.com Wed May 13 19:14:56 2009 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Wed May 13 19:15:07 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905131903.NAA17981@lariat.net> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> Message-ID: Hi, On May 13, 2009, at 10:03 PM, Brett Glass wrote: > Stefan: > > You are correct: This is not real security. In fact, I would argue > that it's not security at all. > > But many businesses that have to maintain hotspots -- especially > some hotel chains -- are "allergic" to any sort of serious security. > This is because a small but vocal subset of their customers just > want to get on the Net and complain about any sort of security. Even > having to enter a password or a WEP key irks them. (I personally > think that these people are ignorant fools and are setting > themselves up for identity theft and worse, but that's just me. And > the businesses seem more willing to allow piracy of their Wi-Fi than > to irritate these boneheads.) Also, these systems have to be usable > by some fairly lame devices -- e.g. an XBox -- that aren't really > computers and don't have the capability to run secure protocols or > even a particularly good Web browser built in. > > So, painful as it is, I have to help these guys implement systems > which "bless" MAC addresses. The "arp -s" command can sort of lock > an IP to a MAC address, but awkwardly and only for outbound packets. > What I'd like is to get this into the firewall, so I can not only > block spoofing but trigger a log entry when it happens. I think /usr/ports/net-mgmt/arpwatch will be helpful then, though I never used in on wireless. Not that I understand how "knowing" mac address is easier for customers then wpa2 password ;) > > --Brett > > At 12:46 PM 5/13/2009, Stefan Lambrev wrote: > >> Hi, >> >> apr -S (or -s) is not helping? >> Have in mind that this is not a real security as it's very easy to >> change your MAC. >> >> On May 13, 2009, at 7:48 PM, Brett Glass wrote: >> >>> I need to find a way to do "MAC address locking" in FreeBSD -- >>> that is, to ensure that only a machine with a particular MAC >>> address can use a particular IP address. Unfortunately, it appears >>> that rules in FreeBSD's IPFW are "stuck" on one layer: rules that >>> look at Layer 2 information in a packet can't look at Layer 3, and >>> vice versa. Is there a way to work around this to do MAC address >>> locking and/or other functions that involve looking at Layer 2 and >>> Layer 3 simultaneously? >>> >>> --Brett Glass >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org >>> " >> >> -- >> Best Wishes, >> Stefan Lambrev >> ICQ# 24134177 >> >> >> >> -- Best Wishes, Stefan Lambrev ICQ# 24134177 From thompsa at FreeBSD.org Wed May 13 19:25:59 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Wed May 13 19:26:05 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905131648.KAA15455@lariat.net> References: <200905131648.KAA15455@lariat.net> Message-ID: <20090513190709.GA2871@citylink.fud.org.nz> On Wed, May 13, 2009 at 10:48:02AM -0600, Brett Glass wrote: > I need to find a way to do "MAC address locking" in FreeBSD -- that is, to > ensure that only a machine with a particular MAC address can use a > particular IP address. Unfortunately, it appears that rules in FreeBSD's > IPFW are "stuck" on one layer: rules that look at Layer 2 information in a > packet can't look at Layer 3, and vice versa. Is there a way to work around > this to do MAC address locking and/or other functions that involve looking > at Layer 2 and Layer 3 simultaneously? This has been implemented as part of Gleb Kurtsov's 2008 SoC project. http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering It has not been committed yet but I beleieve is ready to go in, you can find the code on the svn branch http://svn.freebsd.org/viewvc/base/projects/l2filter/ Andrew From brett at lariat.net Wed May 13 19:29:48 2009 From: brett at lariat.net (Brett Glass) Date: Wed May 13 19:29:55 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <20090513190709.GA2871@citylink.fud.org.nz> References: <200905131648.KAA15455@lariat.net> <20090513190709.GA2871@citylink.fud.org.nz> Message-ID: <200905131929.NAA18422@lariat.net> At 01:07 PM 5/13/2009, Andrew Thompson wrote: >This has been implemented as part of Gleb Kurtsov's 2008 SoC project. >http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering > >It has not been committed yet but I beleieve is ready to go in, you can >find the code on the svn branch >http://svn.freebsd.org/viewvc/base/projects/l2filter/ How does one generate a diff between this code and, say, 7.1-RELEASE or 7.2-RELEASE so that I can try it as a patch? The GUI doesn't seem to be capable of doing this (or it may be that I just don't see how). --Brett Glass From brett at lariat.net Wed May 13 19:52:19 2009 From: brett at lariat.net (Brett Glass) Date: Wed May 13 19:52:26 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> Message-ID: <200905131952.NAA18748@lariat.net> At 01:14 PM 5/13/2009, Stefan Lambrev wrote: >Not that I understand how "knowing" mac address is easier for >customers then wpa2 password ;) Most customers would not recognize a WPA2 password if it bit them. ;-) Also, many older operating systems and Wi-Fi cards do not support WPA at all. (For example, Windows 2000 doesn't have a WPA supplicant.) Many game machines, network appliances, and network accessories (including Wi-Fi to Ethernet bridges) don't either. If there's any authentication at all, users want it to be through their Web browsers, because very often they don't know how to interact with the network through any other program. (In fact, many refer to their browsers as "The Internet" and don't know what a browser is.) I know, I know; a lot of folks would say that anyone with this little knowledge should be kept off of the Internet for the sake of his or her safety. But if they're a paying customer at a hotel or coffeehouse there are some venues that just want to accommodate them. In fact, several hotel chains actually INSIST that there be no security on the Wi-Fi. They literally distribute documents mandating this for all of their franchisees. Shortsighted, I know, but that's the awful state of network security today. --Brett P.S. -- I have looked over that Summer of Code work, and it looks like it's applicable. The English in the docs should be cleaned up, but the code looks solid. The tough part would be linking it to dhcpd so that a rule is added when a lease is issued and removed when the lease is not renewed. From spawk at acm.poly.edu Wed May 13 20:10:08 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Wed May 13 20:10:16 2009 Subject: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Message-ID: <200905132010.n4DKA7gT095806@freefall.freebsd.org> The following reply was made to PR kern/129508; it has been noted by GNATS. From: Boris Kochergin To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Date: Wed, 13 May 2009 15:38:47 -0400 As a workaround, lowering the MTU of the 802.11 interfaces on all of the access points made the panic go away, until one of the machines that was panicking was upgraded to 7.2-RELEASE. Afterward, a panic with a different backtrace started occuring: Unread portion of the kernel message buffer: in_cksum_skip: out of data by 21295 delayed m_pullup, m->len: 22 off: 28410 p: 97 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x44032cbf fault code = supervisor read, page not present instruction pointer = 0x20:0xc05a9b54 stack pointer = 0x28:0xc1f274cc frame pointer = 0x28:0xc1f274d4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 19 (irq5: xl0) trap number = 12 panic: page fault Uptime: 7d15h55m48s Physical memory: 246 MB Dumping 58 MB: 43 27 11 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:244 244 dumptid = curthread->td_tid; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:244 #1 0xc0542599 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0542955 in panic (fmt=Could not find the frame base for "panic".) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0754ee1 in trap_fatal (frame=0xc1f2748c, eva=1141058751) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0754ad0 in trap_pfault (frame=0xc1f2748c, usermode=0, eva=1141058751) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc075439a in trap (frame=0xc1f2748c) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc073c3fb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc05a9b54 in m_tag_locate (m=0xc3004300, cookie=0, type=21, t=0x0) at /usr/src/sys/kern/uipc_mbuf2.c:391 #8 0xc043ef81 in m_tag_find (m=0xc3004300, type=21, start=0x0) at mbuf.h:957 #9 0xc043eee1 in pf_get_mtag (m=0xc3004300) at pf_mtag.h:70 #10 0xc044c44e in pf_test (dir=2, ifp=0xc20b6c00, m0=0xc1f276f0, eh=0x0, inp=0x0) at /usr/src/sys/contrib/pf/net/pf.c:6776 #11 0xc0459f3f in pf_check_out (arg=0x0, m=0xc1f276f0, ifp=0xc20b6c00, dir=2, inp=0x0) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:3687 #12 0xc061da71 in pfil_run_hooks (ph=0xc07dee60, mp=0xc1f277b4, ifp=0xc20b6c00, dir=2, inp=0x0) at /usr/src/sys/net/pfil.c:78 #13 0xc064557e in ip_output (m=0xc3004300, opt=0x0, ro=0xc21b1aa4, flags=0, imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:443 #14 0xc06359d3 in in_gif_output (ifp=0xc2103400, family=18, m=0xc3004300) at /usr/src/sys/netinet/in_gif.c:244 #15 0xc061b3cd in gif_output (ifp=0xc2103400, m=0xc238c100, dst=0xc219c560, rt=0x0) at /usr/src/sys/net/if_gif.c:455 #16 0xc061b009 in gif_start (ifp=0xc2103400) at /usr/src/sys/net/if_gif.c:351 #17 0xc0612c39 in bridge_enqueue (sc=0xc222c800, dst_ifp=0xc2103400, m=0x0) at /usr/src/sys/net/if_bridge.c:1742 #18 0xc0614d9c in bridge_broadcast (sc=0xc222c800, src_if=0xc2196000, m=0xc238c100, runfilt=1) at /usr/src/sys/net/if_bridge.c:2386 #19 0xc0613951 in bridge_forward (sc=0xc222c800, sbif=0xc22c8400, m=0xc238c100) at /usr/src/sys/net/if_bridge.c:2046 #20 0xc0613ed5 in bridge_input (ifp=0xc2196000, m=0xc3068600) at /usr/src/sys/net/if_bridge.c:2168 #21 0xc061b6da in gif_input (m=0xc3068600, af=18, ifp=0xc2196000) at /usr/src/sys/net/if_gif.c:563 #22 0xc0635d34 in in_gif_input (m=0xc3068600, off=20) at /usr/src/sys/netinet/in_gif.c:342 #23 0xc063d905 in encap4_input (m=0xc3068600, off=20) at /usr/src/sys/netinet/ip_encap.c:191 #24 0xc064190f in ip_input (m=0xc3068600) at /usr/src/sys/netinet/ip_input.c:664 #25 0xc061d61a in netisr_dispatch (num=2, m=0xc3068600) at /usr/src/sys/net/netisr.c:185 #26 0xc0619d16 in ether_demux (ifp=0xc20b6c00, m=0xc3068600) at /usr/src/sys/net/if_ethersubr.c:834 #27 0xc0619af2 in ether_input (ifp=0xc20b6c00, m=0xc3068600) at /usr/src/sys/net/if_ethersubr.c:692 #28 0xc06a1924 in xl_rxeof (sc=0xc20d7000) at /usr/src/sys/pci/if_xl.c:2022 #29 0xc06a23ce in xl_intr (arg=0xc20d7000) at /usr/src/sys/pci/if_xl.c:2257 #30 0xc0518ca0 in ithread_execute_handlers (p=0xc20aa000, ie=0xc2009900) at /usr/src/sys/kern/kern_intr.c:1088 #31 0xc0518e67 in ithread_loop (arg=0xc20d3c80) at /usr/src/sys/kern/kern_intr.c:1175 #32 0xc0516d23 in fork_exit (callout=0xc0518de0 , arg=0xc20d3c80, frame=0xc1f27d38) at /usr/src/sys/kern/kern_fork.c:810 #33 0xc073c470 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 From seth.mos at xs4all.nl Wed May 13 20:20:05 2009 From: seth.mos at xs4all.nl (Seth Mos) Date: Wed May 13 20:20:11 2009 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Message-ID: <200905132020.n4DKK4h1009869@freefall.freebsd.org> The following reply was made to PR kern/127528; it has been noted by GNATS. From: "Seth Mos" To: bug-followup@FreeBSD.org, seth.mos@xs4all.nl Cc: Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Date: Wed, 13 May 2009 21:58:40 +0200 (CEST) Hi there again, it's been a while. We are currently on a pfSense 1.2.3-RC1 release and we are now getting a host of people on the forum and in the mailing lists that are complaining about the load balancer flapping. Some debugging turned out some very weird behaviour. Every now and then, depending on the concurrenty of icmp traffic originating from the FreeBSD host, ping will miss icmp replies. Here are the steps performed to debug this issue. For example the output tcpdump -ni vlan0 -t icmp Where vlan0 is the external interface. The IP address being pinged is a local gateway connected by ethernet so there is nothing but the switch in between. http://pastebin.com/f6608c875 The ping command issued is /sbin/ping -t 4 -oqc 5 -i 0.7 213.23.199.249 This command line will ping the target and exit with a return status of 0 when it receives a reply which can be any of the 5 attempts within the maximum of 4 seconds. The output clearly shows that all attempts have unique process IDs, which is good. It also shows that all attempt have a sequence number of 0 which is the 1st attempt to ping. There is however one attempt where this is different, on attempt with pid 46060 you will see that it attempted 4 times to ping the target, it got valid responses to all 5 requests!. However, ping exited with a return status of 1 which would imply a timeout. So now it is worse then the originally reported issue we had on 7.0. We can now make the FreeBSD distributed ping fail. Specifically, it fails to see the valid replies. For your reference I also pasted the tcpdump below. I can also reproduce this exact same behaviour by using fping. So I would not consider this a bug in the ping binary itself. Since the original PR had this issue with apinger, which is different from both ping and fping I am quite confident there is a serious regression in here. # uname -a FreeBSD noord.coltex.nl 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4 #0: Tue Mar 24 01:18:19 EDT 2009 sullrich@RELENG_1_2-snapshots.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.7 i386 Kind regards, Seth Mos pfSense Developer -------------- 1. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 25068, seq 0, length 64 2. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 25068, seq 0, length 64 3. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 27372, seq 0, length 64 4. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 27372, seq 0, length 64 5. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 29676, seq 0, length 64 6. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 29676, seq 0, length 64 7. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 31468, seq 0, length 64 8. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 31468, seq 0, length 64 9. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 33772, seq 0, length 64 10. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 33772, seq 0, length 64 11. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 36076, seq 0, length 64 12. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 36076, seq 0, length 64 13. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 46060, seq 0, length 64 14. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 46060, seq 0, length 64 15. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 46060, seq 1, length 64 16. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 46060, seq 1, length 64 17. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 12525, seq 0, length 64 18. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 12525, seq 0, length 64 19. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 14829, seq 0, length 64 20. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 14829, seq 0, length 64 21. IP 213.23.199.249 > 213.23.199.250: ICMP host 192.168.120.254 unreachable - admin prohibited filter, length 60 22. IP 213.23.199.249 > 213.23.199.250: ICMP host 192.168.148.1 unreachable - admin prohibited filter, length 60 23. IP 213.23.199.249 > 213.23.199.250: ICMP host 192.168.112.1 unreachable - admin prohibited filter, length 60 24. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 46060, seq 2, length 64 25. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 46060, seq 2, length 64 26. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 17645, seq 0, length 64 27. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 17645, seq 0, length 64 28. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 46060, seq 3, length 64 29. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 46060, seq 3, length 64 30. IP 213.23.199.251 > 213.23.199.249: ICMP echo request, id 46060, seq 4, length 64 31. IP 213.23.199.249 > 213.23.199.251: ICMP echo reply, id 46060, seq 4, length 64 From cswiger at mac.com Wed May 13 21:34:45 2009 From: cswiger at mac.com (Chuck Swiger) Date: Wed May 13 21:34:52 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905131929.NAA18422@lariat.net> References: <200905131648.KAA15455@lariat.net> <20090513190709.GA2871@citylink.fud.org.nz> <200905131929.NAA18422@lariat.net> Message-ID: <96ED2A2C-0DD5-4708-ABC1-8C00849444BD@mac.com> On May 13, 2009, at 12:29 PM, Brett Glass wrote: >> It has not been committed yet but I beleieve is ready to go in, you >> can >> find the code on the svn branch >> http://svn.freebsd.org/viewvc/base/projects/l2filter/ > > How does one generate a diff between this code and, say, 7.1-RELEASE > or 7.2-RELEASE so that I can try it as a patch? The GUI doesn't seem > to be capable of doing this (or it may be that I just don't see how). Something like: svn diff http://svn.freebsd.org/base/releng/7.1 http://svn.freebsd.org/base/projects/l2filter However, while this answers your question, it's not as useful as you might hope; probably you are actually interested in the diff between when/where the branch was cut and what it currently has, as that is the patch that you'd want to try against whatever OS source code version you actually want to run. -- -Chuck From brueffer at FreeBSD.org Wed May 13 22:08:33 2009 From: brueffer at FreeBSD.org (Christian Brueffer) Date: Wed May 13 22:08:40 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905131903.NAA17981@lariat.net> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> Message-ID: <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> On Wed, May 13, 2009 at 01:03:20PM -0600, Brett Glass wrote: > Stefan: > > You are correct: This is not real security. In fact, I would argue that it's not security at all. > > But many businesses that have to maintain hotspots -- especially some hotel chains -- are "allergic" to any sort of serious security. This is because a small but vocal subset of their customers just want to get on the Net and complain about any sort of security. Even having to enter a password or a WEP key irks them. (I personally think that these people are ignorant fools and are setting themselves up for identity theft and worse, but that's just me. And the businesses seem more willing to allow piracy of their Wi-Fi than to irritate these boneheads.) Also, these systems have to be usable by some fairly lame devices -- e.g. an XBox -- that aren't really computers and don't have the capability to run secure protocols or even a particularly good Web browser built in. > > So, painful as it is, I have to help these guys implement systems which "bless" MAC addresses. The "arp -s" command can sort of lock an IP to a MAC address, but awkwardly and only for outbound packets. What I'd like is to get this into the firewall, so I can not only block spoofing but trigger a log entry when it happens. > Sounds like wlan_acl(4) may be of interest to you. - Christian -- Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090513/b2dc9642/attachment.pgp From brett at lariat.net Wed May 13 22:30:11 2009 From: brett at lariat.net (Brett Glass) Date: Wed May 13 22:30:25 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> Message-ID: <200905132230.QAA20732@lariat.net> At 03:38 PM 5/13/2009, Christian Brueffer wrote: >Sounds like wlan_acl(4) may be of interest to you. Unfortunately, wlan_acl(4) is only useful if one wants to ban users from the network, which these venues will rarely want to do except to block an abuser. Rather, they'll want the equipment to recognize MAC addresses and grant different degrees of access to them. For example, a user might be trapped in a "walled garden" until agreeing to an acceptable use policy, and then redirected -- but only once -- to a specific Web page, such as the hotel chain's reservation page. --Brett Glass From adrian at freebsd.org Thu May 14 00:44:28 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Thu May 14 00:44:34 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <96ED2A2C-0DD5-4708-ABC1-8C00849444BD@mac.com> References: <200905131648.KAA15455@lariat.net> <20090513190709.GA2871@citylink.fud.org.nz> <200905131929.NAA18422@lariat.net> <96ED2A2C-0DD5-4708-ABC1-8C00849444BD@mac.com> Message-ID: There's one big SVN commit - r186069. There's a couple of "merge from head" commits and an arpv2/routetable tidyup commit. This is all against -current though. I'm going to see how cleanly the patch applies to 7.2-release and if it works at all. Adrian From adrian at freebsd.org Thu May 14 03:17:27 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Thu May 14 03:17:33 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: References: <200905131648.KAA15455@lariat.net> <20090513190709.GA2871@citylink.fud.org.nz> <200905131929.NAA18422@lariat.net> <96ED2A2C-0DD5-4708-ABC1-8C00849444BD@mac.com> Message-ID: Brett, you can grab the specific "bulk" change to an earlier -current from here: svn diff -r 186068:186069 http://svn.freebsd.org/base/projects/l2filter > /tmp/l2filter-186069.diff There aren't any bugfix commits in that branch after that; they're all merge-from-head and arpv2/routetable work merging. Andrew, I'm taking a look at this as I have a similar interest to Brett at the moment. It may make it easier to review and commit if we broke it up into separate chunks: * separate out the changes to the ethernet/bridging layer and the new pfil hooks into a separate initial commit (and MFC); * then generate separate patches for pf/ipfw and let people test it against -current and 7.2-release (which is where I'd like the support to appear..) Thanks, Adrian 2009/5/14 Adrian Chadd : > There's one big SVN commit - r186069. > > There's a couple of "merge from head" commits and an arpv2/routetable > tidyup commit. > > This is all against -current though. I'm going to see how cleanly the > patch applies to 7.2-release and if it works at all. > > > > Adrian > From eugen at kuzbass.ru Thu May 14 03:25:15 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Thu May 14 03:25:22 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905131648.KAA15455@lariat.net> References: <200905131648.KAA15455@lariat.net> Message-ID: <20090514025957.GA45372@svzserv.kemerovo.su> On Wed, May 13, 2009 at 10:48:02AM -0600, Brett Glass wrote: > I need to find a way to do "MAC address locking" in FreeBSD -- that > is, to ensure that only a machine with a particular MAC address can > use a particular IP address. Unfortunately, it appears that rules > in FreeBSD's IPFW are "stuck" on one layer: rules that look at > Layer 2 information in a packet can't look at Layer 3, and vice > versa. Is there a way to work around this to do MAC address locking > and/or other functions that involve looking at Layer 2 and Layer 3 > simultaneously? There is no need in advanced filtering rules for that. Just use 'arp -f /path/to/IP-MAC-pairs' with 'ifconfig $iface staticarp'. We use that for years since FreeBSD 2.2.x (before 4.x that required patches). Eugene Grosbein From cmb at pfsense.org Thu May 14 03:40:03 2009 From: cmb at pfsense.org (Chris Buechler) Date: Thu May 14 03:40:10 2009 Subject: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Message-ID: <200905140340.n4E3e3Qm002796@freefall.freebsd.org> The following reply was made to PR kern/127528; it has been noted by GNATS. From: Chris Buechler To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/127528: [icmp]: icmp socket receives icmp replies not owned by the process. Date: Wed, 13 May 2009 23:08:05 -0400 A brief addition to Seth's update on this issue, which should provide adequate detail. We switched from fping to the stock FreeBSD ping, and it made the issue better, but we're still seeing problems with FreeBSD's ping. In many circumstances it never appears, in others it's very easy to replicate. There isn't any commonality between environments that can replicate it, it happens across many types of NICs, using VLANs and not, etc. We should be able to arrange access to one of the systems that can routinely replicate the problem for an interested FreeBSD developer. We're in a bit over our heads here and not sure how to troubleshoot further. thanks, Chris From freebsd-net at dino.sk Thu May 14 05:13:32 2009 From: freebsd-net at dino.sk (Milan Obuch) Date: Thu May 14 05:13:39 2009 Subject: Weird dhclient behavior after today's rebuild Message-ID: <200905140703.10473.freebsd-net@dino.sk> Hi, I did full system rebuild from freshly csup'ped sources. Everything went smooth as usual, but after reboot network card did not get configured via DHCP. There were four lines logged on console/in syslog: dhclient[822]: re0: not found dhclient[822]: exiting dhclient[823]: connection closed dhclient[823]: exiting I did some tests, disabled automatic dhclient invocation in rc.conf. Then, after connecting cable, ifconfig re0 show status active, netstat -rnf inet shows only loopback route (128.0.0.1 on lo0). Manually starting dhclient re0: ifconfig: ioctl (SIOCAIFADDR): File exists re0: not found exiting At this point, netstat -rnf inet shows additional 0.0.0.0/8 route on re0,yet there is no addres in ifconfig re0 output. Assigning IP statically works (tested only via ifconfig re0 , but setting this in rc.conf should have exastly the same effect). I found a bit strange workaround for this - first assign any IP to interface, I used 0.0.0.1/8, then launching dhclient re0 yields desired result... This problem is observed with sources 24 hours old, verified with sources 12 hours old, did not occured last time I did rebuild from sources 3 or 4 days old (not remembered exactly). Regards, Milan From qing.li at bluecoat.com Thu May 14 05:47:18 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu May 14 05:47:25 2009 Subject: Weird dhclient behavior after today's rebuild References: <200905140703.10473.freebsd-net@dino.sk> Message-ID: I have committed the patch, please update your source and give it a try. Thanks, -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Milan Obuch Sent: Wed 5/13/2009 10:03 PM To: freebsd-net@freebsd.org Subject: Weird dhclient behavior after today's rebuild Hi, I did full system rebuild from freshly csup'ped sources. Everything went smooth as usual, but after reboot network card did not get configured via DHCP. There were four lines logged on console/in syslog: dhclient[822]: re0: not found dhclient[822]: exiting dhclient[823]: connection closed dhclient[823]: exiting I did some tests, disabled automatic dhclient invocation in rc.conf. Then, after connecting cable, ifconfig re0 show status active, netstat -rnf inet shows only loopback route (128.0.0.1 on lo0). Manually starting dhclient re0: ifconfig: ioctl (SIOCAIFADDR): File exists re0: not found exiting At this point, netstat -rnf inet shows additional 0.0.0.0/8 route on re0,yet there is no addres in ifconfig re0 output. Assigning IP statically works (tested only via ifconfig re0 , but setting this in rc.conf should have exastly the same effect). I found a bit strange workaround for this - first assign any IP to interface, I used 0.0.0.1/8, then launching dhclient re0 yields desired result... This problem is observed with sources 24 hours old, verified with sources 12 hours old, did not occured last time I did rebuild from sources 3 or 4 days old (not remembered exactly). Regards, Milan _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From brett at lariat.net Thu May 14 06:41:17 2009 From: brett at lariat.net (Brett Glass) Date: Thu May 14 06:41:24 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <20090514155226.Y46325@sola.nimnet.asn.au> References: <200905131648.KAA15455@lariat.net> <20090514155226.Y46325@sola.nimnet.asn.au> Message-ID: <200905140640.AAA25118@lariat.net> At 12:17 AM 5/14/2009, Ian Smith wrote: >You can use fixed leases with MAC specified in dhcp for that, This lets you assign specific addresses to machines with specific MAC addresses. But it doesn't inhibit MAC address "cloning," and the DHCP server cannot force a machine to use a specific IP or stop it from using one that was not assigned to it. >Re ipfw(8), I'm not clear on what your problem is: the section PACKET >FLOW shows clearly how to distinguish layer 2 from layer 3 traffic. The problem is that you cannot test both the MAC address and the IP address in the same rule -- at least in the current implementation. >Your 'vice versa' here isn't correct; you can select by layer 3 criteria >on packets from ether_demux, The docs say that you can't. --Brett Glass From smithi at nimnet.asn.au Thu May 14 06:53:31 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu May 14 06:53:40 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905131648.KAA15455@lariat.net> References: <200905131648.KAA15455@lariat.net> Message-ID: <20090514155226.Y46325@sola.nimnet.asn.au> On Wed, 13 May 2009, Brett Glass wrote: > I need to find a way to do "MAC address locking" in FreeBSD -- that is, to > ensure that only a machine with a particular MAC address can use a particular > IP address. Unfortunately, it appears that rules in FreeBSD's IPFW are > "stuck" on one layer: rules that look at Layer 2 information in a packet > can't look at Layer 3, and vice versa. Is there a way to work around this to > do MAC address locking and/or other functions that involve looking at Layer 2 > and Layer 3 simultaneously? You can use fixed leases with MAC specified in dhcp for that, with or without specifying a range of addresses available to boxes with unknown MACs. An org I'm working for uses just that method to good effect. You can also specify a different (eg) router address for non-fixed leases, towards your 'captive portal' requirement for new boxes. Re ipfw(8), I'm not clear on what your problem is: the section PACKET FLOW shows clearly how to distinguish layer 2 from layer 3 traffic. Your 'vice versa' here isn't correct; you can select by layer 3 criteria on packets from ether_demux, though of course once (or if) they get to re-enter the firewall at layer 3 (from ip_input) you can't see/test MAC addresses anymore. 'simultaneously' isn't really the case then; clearly the layer 2 pass occurs first on input, and last on output. cheers, Ian From gleb.kurtsou at gmail.com Thu May 14 07:39:20 2009 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Thu May 14 07:39:27 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905131929.NAA18422@lariat.net> References: <200905131648.KAA15455@lariat.net> <20090513190709.GA2871@citylink.fud.org.nz> <200905131929.NAA18422@lariat.net> Message-ID: <20090514071442.GA6702@tops.skynet.lt> On (13/05/2009 13:29), Brett Glass wrote: > At 01:07 PM 5/13/2009, Andrew Thompson wrote: > > >This has been implemented as part of Gleb Kurtsov's 2008 SoC project. > >http://wiki.freebsd.org/GlebKurtsov/Improving_layer2_filtering > > > >It has not been committed yet but I beleieve is ready to go in, you can > >find the code on the svn branch > >http://svn.freebsd.org/viewvc/base/projects/l2filter/ > > How does one generate a diff between this code and, say, > 7.1-RELEASE or 7.2-RELEASE so that I can try it as a patch? The GUI > doesn't seem to be capable of doing this (or it may be that I just > don't see how). I'd suggest you using latest patchs from http://blogs.freebsdish.org/gleb/2009/03/24/layer2-dummynet/ projects svn repository is quiet outdated, and I was going to make patch against 7.2 on this weekend (will blog about it) > > --Brett Glass > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From stefan.lambrev at moneybookers.com Thu May 14 07:40:09 2009 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Thu May 14 07:40:16 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905132230.QAA20732@lariat.net> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> <200905132230.QAA20732@lariat.net> Message-ID: <7B486348-7484-46EC-9B60-5ED64B80D511@moneybookers.com> Hi Brett, I think what you are looking for is called captive portal. You can look at pfsense - http://doc.pfsense.org/index.php/Category:Captive_Portal which comes with such solution into it. On May 14, 2009, at 1:29 AM, Brett Glass wrote: > At 03:38 PM 5/13/2009, Christian Brueffer wrote: > >> Sounds like wlan_acl(4) may be of interest to you. > > Unfortunately, wlan_acl(4) is only useful if one wants to ban users > from the network, which these venues will rarely want to do except > to block an abuser. > > Rather, they'll want the equipment to recognize MAC addresses and > grant different degrees of access to them. For example, a user might > be trapped in a "walled garden" until agreeing to an acceptable use > policy, and then redirected -- but only once -- to a specific Web > page, such as the hotel chain's reservation page. > > --Brett Glass > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From smithi at nimnet.asn.au Thu May 14 07:51:41 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu May 14 07:51:48 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905140640.AAA25118@lariat.net> References: <200905131648.KAA15455@lariat.net> <20090514155226.Y46325@sola.nimnet.asn.au> <200905140640.AAA25118@lariat.net> Message-ID: <20090514170535.Y46325@sola.nimnet.asn.au> On Thu, 14 May 2009, Brett Glass wrote: > At 12:17 AM 5/14/2009, Ian Smith wrote: > > >You can use fixed leases with MAC specified in dhcp for that, > > This lets you assign specific addresses to machines with specific MAC > addresses. But it doesn't inhibit MAC address "cloning," and the DHCP > server cannot force a machine to use a specific IP or stop it from > using one that was not assigned to it. You can have it only issue a lease for a given IP to a machine with the correct MAC, and issue no leases to any other machines; at least, that works for us. Of course that can't prevent someone who a) knows the IP address to MAC mapping, and b) can spoof the MAC address. I don't know what could prevent that, but it's hardly the common scenario. Then have ipfw refuse traffic from addresses other than those allowed. > >Re ipfw(8), I'm not clear on what your problem is: the section PACKET > >FLOW shows clearly how to distinguish layer 2 from layer 3 traffic. > > The problem is that you cannot test both the MAC address and the IP > address in the same rule -- at least in the current implementation. Assuming you have net.link.ether.ipfw=1 to get layer 2 packets, and are separating your layer 2 packets for testing as shown under PACKET FLOW, can you show us the rule to do just that, that isn't working right? > >Your 'vice versa' here isn't correct; you can select by layer 3 criteria > >on packets from ether_demux, > > The docs say that you can't. Please point out where ipfw(8) says that? cheers, Ian From freebsd-net at dino.sk Thu May 14 10:29:56 2009 From: freebsd-net at dino.sk (Milan Obuch) Date: Thu May 14 10:30:03 2009 Subject: Weird dhclient behavior after today's rebuild In-Reply-To: References: <200905140703.10473.freebsd-net@dino.sk> Message-ID: <200905141229.34731.freebsd-net@dino.sk> On Thursday 14 May 2009 07:32:22 Li, Qing wrote: > I have committed the patch, please update your source and > give it a try. > > Thanks, > > -- Qing > After fresh csup and rebuild it works again. I suppose your fix wents into sys/netinet/in.c, as I did not see anything else network related in csup's output... Thanks for quick fix. Milan > -----Original Message----- > From: owner-freebsd-net@freebsd.org on behalf of Milan Obuch > Sent: Wed 5/13/2009 10:03 PM > To: freebsd-net@freebsd.org > Subject: Weird dhclient behavior after today's rebuild > > Hi, > > I did full system rebuild from freshly csup'ped sources. Everything went > smooth as usual, but after reboot network card did not get configured via > DHCP. There were four lines logged on console/in syslog: > > dhclient[822]: re0: not found > dhclient[822]: exiting > dhclient[823]: connection closed > dhclient[823]: exiting > > I did some tests, disabled automatic dhclient invocation in rc.conf. > > Then, after connecting cable, ifconfig re0 show status active, netstat -rnf > inet shows only loopback route (128.0.0.1 on lo0). Manually starting > dhclient re0: > > ifconfig: ioctl (SIOCAIFADDR): File exists > re0: not found > exiting > [ snip ] From sepron at gmail.com Thu May 14 15:20:05 2009 From: sepron at gmail.com (Sergey Pronin) Date: Thu May 14 15:20:11 2009 Subject: kern/132984: [netgraph] swi1: net 100% cpu usage Message-ID: <200905141520.n4EFK4Rb088995@freefall.freebsd.org> The following reply was made to PR kern/132984; it has been noted by GNATS. From: Sergey Pronin To: bug-followup@FreeBSD.org, vlad@prokk.net Cc: Subject: Re: kern/132984: [netgraph] swi1: net 100% cpu usage Date: Thu, 14 May 2009 18:39:35 +0400 --000e0cd311a2045e870469e04ca6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This bug is still urgent for me. Was it solved? --000e0cd311a2045e870469e04ca6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This bug is still urgent for me. Was it solved?
--000e0cd311a2045e870469e04ca6-- From sson at freebsd.org Thu May 14 18:40:04 2009 From: sson at freebsd.org (Stacey Son) Date: Thu May 14 18:40:14 2009 Subject: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) Message-ID: <200905141840.n4EIe3E3060812@freefall.freebsd.org> The following reply was made to PR kern/134079; it has been noted by GNATS. From: Stacey Son To: bug-followup@freebsd.org, g.zhengming@gmail.com Cc: Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) Date: Thu, 14 May 2009 13:18:35 -0500 I have the same, exact problem with FreeBSD-Current running on VMWare Fusion (64-bit, 2 virtual procs, 4096MB Memory allocation, Mac Pro host). Running 7.2 on this same configuration there is no problem with the e1000 (if_em) driver. Upgrading to -current I get the following error (in dmesg): em0: Invalid MAC address device_attach:em0 attach returned 5 My work around is to edit the "vmx" config file on the host for the virtual image and change: ethernet0.virtualDev="e1000" to: ethernet0.virtualDev="vlance" so the virtual machine emulates an AMD Lance instead. -stacey. From oberman at es.net Thu May 14 21:42:38 2009 From: oberman at es.net (Kevin Oberman) Date: Thu May 14 21:42:45 2009 Subject: IPv6 fragmentation weirdness Message-ID: <20090514214235.B09701CC12@ptavv.es.net> I have recently noticed problems with data transfers via IPv6. Attempt to fetch files from dome sites was hanging as soon as the data started to flow. Felt like an MTU issue, so I tried sending various sizes of ICMP echo (ping) packets and discovered that I could not send a packet of over 1280 bytes. (ping6 -s 1232) If I disabled kernel fragmentation (-m), I could use packets up to the MTU of my interface (1500 bytes). The path is entirely native IPv6. No tunnels. All should allow full 1500 byte packets. I then captured the ICMP and discovered that the kernel was fragmenting all of them! Worse, the fragment was sent out before the ICMP! What the heck is going on! Thread synchronization? When I captured the packets (via tcpdump -s0 -w file host ftp.funet.fi), the first things captured is an IPv6 fragment of 72 bytes. 3 microseconds later, I get the ICMP6 packet of 1294 bytes. This pattern is consistent over repeated packets. This was with -s 1234 for a total ICMPv6 size of 1282. First, why is the kernel fragmenting this at all as it fits in the interface MTU? Second, why the heck is the fragment going out first? This should be OK, but I suspect many firewalls (which are often not happy with fragments) are not likely to pass a fragment which precedes the initial frame. Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is something in the path that is blocking my traffic, so others may not see this, but I think the root issues is the kernel fragmenting packets way below MTU size. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From sthaug at nethelp.no Thu May 14 22:09:05 2009 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Thu May 14 22:09:12 2009 Subject: IPv6 fragmentation weirdness In-Reply-To: <20090514214235.B09701CC12@ptavv.es.net> References: <20090514214235.B09701CC12@ptavv.es.net> Message-ID: <20090515.000902.74658525.sthaug@nethelp.no> > First, why is the kernel fragmenting this at all as it fits in the > interface MTU? Good question, I definitely disagree with this behavior and would say that it breaks POLA. But it's documented (see the ping6 -m option). > Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is > something in the path that is blocking my traffic, so others may not see > this, but I think the root issues is the kernel fragmenting packets way > below MTU size. I just picked up a copy of the 7.2 bootonly ISO image using IPv6. Slow but usable. My path (from Oslo, Norway) is: sthaug@lab1% traceroute6 ftp.funet.fi traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:8c0:8b00:1::2, 64 hops max, 12 byte packets 1 ge-0-0-9-515.br1.fn3.no.catchbone.net 0.254 ms 4.917 ms 0.203 ms 2 c10G-ge-5-1-0.cr2.osls.no.catchbone.net 0.485 ms 0.408 ms 0.399 ms 3 c10G-xe-4-1-0.br1.osls.no.catchbone.net 0.364 ms 0.351 ms 0.361 ms 4 2001:2000:3083:6::1 9.006 ms 8.848 ms 8.966 ms 5 s-ipv6-b1-link.ipv6.telia.net 19.481 ms 19.590 ms 19.412 ms 6 2001:2000:3080:d::2 110.907 ms 109.056 ms 119.495 ms 7 helsinki0-rtr.funet.fi 116.305 ms 123.534 ms 119.472 ms 8 csc0-x0000-helsinki0.ipv6.funet.fi 118.873 ms 117.439 ms 116.054 ms 9 ftp.funet.fi 115.777 ms 116.087 ms 117.735 ms Note that the IPv6 transit from Telia is tunnelled, and the RTT is awful compared to IPv4 (IPv4 RTT to ftp.funet.fi from the same box is around 17 ms). Steinar Haug, Nethelp consulting, sthaug@nethelp.no From oberman at es.net Thu May 14 22:29:33 2009 From: oberman at es.net (Kevin Oberman) Date: Thu May 14 22:29:41 2009 Subject: IPv6 fragmentation weirdness In-Reply-To: Your message of "Fri, 15 May 2009 00:09:02 +0200." <20090515.000902.74658525.sthaug@nethelp.no> Message-ID: <20090514222930.D71611CC0B@ptavv.es.net> > Date: Fri, 15 May 2009 00:09:02 +0200 (CEST) > From: sthaug@nethelp.no > > > First, why is the kernel fragmenting this at all as it fits in the > > interface MTU? > > Good question, I definitely disagree with this behavior and would say > that it breaks POLA. But it's documented (see the ping6 -m option). > > > Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is > > something in the path that is blocking my traffic, so others may not see > > this, but I think the root issues is the kernel fragmenting packets way > > below MTU size. > > I just picked up a copy of the 7.2 bootonly ISO image using IPv6. Slow > but usable. My path (from Oslo, Norway) is: > > sthaug@lab1% traceroute6 ftp.funet.fi > traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:8c0:8b00:1::2, 64 hops max, 12 byte packets > 1 ge-0-0-9-515.br1.fn3.no.catchbone.net 0.254 ms 4.917 ms 0.203 ms > 2 c10G-ge-5-1-0.cr2.osls.no.catchbone.net 0.485 ms 0.408 ms 0.399 ms > 3 c10G-xe-4-1-0.br1.osls.no.catchbone.net 0.364 ms 0.351 ms 0.361 ms > 4 2001:2000:3083:6::1 9.006 ms 8.848 ms 8.966 ms > 5 s-ipv6-b1-link.ipv6.telia.net 19.481 ms 19.590 ms 19.412 ms > 6 2001:2000:3080:d::2 110.907 ms 109.056 ms 119.495 ms > 7 helsinki0-rtr.funet.fi 116.305 ms 123.534 ms 119.472 ms > 8 csc0-x0000-helsinki0.ipv6.funet.fi 118.873 ms 117.439 ms 116.054 ms > 9 ftp.funet.fi 115.777 ms 116.087 ms 117.735 ms > > Note that the IPv6 transit from Telia is tunnelled, and the RTT is awful > compared to IPv4 (IPv4 RTT to ftp.funet.fi from the same box is around > 17 ms). > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > Thanks, Steinar. I just re-read the man page and I had misunderstood what it was saying. That still leave me baffled as to what is happening. My path is, as would be expected, very different. traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:400:0:40::200:101, 64 hops max, 12 byte packets 1 esnet.rt1.ams.nl.geant2.net (2001:798:29:10aa::9) 83.998 ms 115.099 ms 85.969 ms 2 so-7-0-0.rt2.cop.dk.geant2.net (2001:798:cc:1501:2201::1) 101.692 ms 96.955 ms 96.868 ms 3 nordunet-gw.rt2.cop.dk.geant2.net (2001:798:15:10aa::2) 179.931 ms 205.407 ms 195.268 ms 4 dk-uni.nordu.net (2001:948:0:f055::2) 210.468 ms se-fre.nordu.net (2001:948:0:f03f::1) 187.479 ms dk-uni.nordu.net (2001:948:0:f055::2) 190.578 ms 5 se-tug.nordu.net (2001:948:0:f049::2) 188.170 ms 213.538 ms se-tug.nordu.net (2001:948:0:f056::1) 183.273 ms 6 helsinki0-rtr.funet.fi (2001:948:0:f035::2) 188.114 ms 189.214 ms 192.192 ms 7 csc0-x0000-helsinki0.ipv6.funet.fi (2001:708:0:f000::1:2) 186.166 ms 190.181 ms 186.669 ms 8 ftp.funet.fi (2001:708:10:9::20:1) 186.251 ms 198.591 ms 205.987 ms This is exactly the same as my IPv4 path. Something along this path is silently refusing to pass a packet at the start of the transfer and that screams MTU. If I ping from a Juniper router, I can get 1482 byte packets through, so I suspect that there is a tunnel somewhere. But FreeBSD boxes die at the lower limit. Does the kernel fragmentation only affect ICMP or are TCP packet also fragmented at 1280 bytes? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From bzeeb-lists at lists.zabbadoz.net Thu May 14 22:35:10 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu May 14 22:35:17 2009 Subject: IPv6 fragmentation weirdness In-Reply-To: <20090514222930.D71611CC0B@ptavv.es.net> References: <20090514222930.D71611CC0B@ptavv.es.net> Message-ID: <20090514223413.F72053@maildrop.int.zabbadoz.net> On Thu, 14 May 2009, Kevin Oberman wrote: Hi, >> Date: Fri, 15 May 2009 00:09:02 +0200 (CEST) >> From: sthaug@nethelp.no >> >>> First, why is the kernel fragmenting this at all as it fits in the >>> interface MTU? >> >> Good question, I definitely disagree with this behavior and would say >> that it breaks POLA. But it's documented (see the ping6 -m option). >> >>> Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is >>> something in the path that is blocking my traffic, so others may not see >>> this, but I think the root issues is the kernel fragmenting packets way >>> below MTU size. >> >> I just picked up a copy of the 7.2 bootonly ISO image using IPv6. Slow >> but usable. My path (from Oslo, Norway) is: >> >> sthaug@lab1% traceroute6 ftp.funet.fi >> traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:8c0:8b00:1::2, 64 hops max, 12 byte packets >> 1 ge-0-0-9-515.br1.fn3.no.catchbone.net 0.254 ms 4.917 ms 0.203 ms >> 2 c10G-ge-5-1-0.cr2.osls.no.catchbone.net 0.485 ms 0.408 ms 0.399 ms >> 3 c10G-xe-4-1-0.br1.osls.no.catchbone.net 0.364 ms 0.351 ms 0.361 ms >> 4 2001:2000:3083:6::1 9.006 ms 8.848 ms 8.966 ms >> 5 s-ipv6-b1-link.ipv6.telia.net 19.481 ms 19.590 ms 19.412 ms >> 6 2001:2000:3080:d::2 110.907 ms 109.056 ms 119.495 ms >> 7 helsinki0-rtr.funet.fi 116.305 ms 123.534 ms 119.472 ms >> 8 csc0-x0000-helsinki0.ipv6.funet.fi 118.873 ms 117.439 ms 116.054 ms >> 9 ftp.funet.fi 115.777 ms 116.087 ms 117.735 ms >> >> Note that the IPv6 transit from Telia is tunnelled, and the RTT is awful >> compared to IPv4 (IPv4 RTT to ftp.funet.fi from the same box is around >> 17 ms). >> >> Steinar Haug, Nethelp consulting, sthaug@nethelp.no >> > > Thanks, Steinar. > > I just re-read the man page and I had misunderstood what it was > saying. That still leave me baffled as to what is happening. > > My path is, as would be expected, very different. > traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:400:0:40::200:101, 64 hops max, 12 byte packets > 1 esnet.rt1.ams.nl.geant2.net (2001:798:29:10aa::9) 83.998 ms 115.099 ms 85.969 ms > 2 so-7-0-0.rt2.cop.dk.geant2.net (2001:798:cc:1501:2201::1) 101.692 ms 96.955 ms 96.868 ms > 3 nordunet-gw.rt2.cop.dk.geant2.net (2001:798:15:10aa::2) 179.931 ms 205.407 ms 195.268 ms > 4 dk-uni.nordu.net (2001:948:0:f055::2) 210.468 ms se-fre.nordu.net (2001:948:0:f03f::1) 187.479 ms dk-uni.nordu.net (2001:948:0:f055::2) 190.578 ms > 5 se-tug.nordu.net (2001:948:0:f049::2) 188.170 ms 213.538 ms se-tug.nordu.net (2001:948:0:f056::1) 183.273 ms > 6 helsinki0-rtr.funet.fi (2001:948:0:f035::2) 188.114 ms 189.214 ms 192.192 ms > 7 csc0-x0000-helsinki0.ipv6.funet.fi (2001:708:0:f000::1:2) 186.166 ms 190.181 ms 186.669 ms > 8 ftp.funet.fi (2001:708:10:9::20:1) 186.251 ms 198.591 ms 205.987 ms > > This is exactly the same as my IPv4 path. Something along this path is > silently refusing to pass a packet at the start of the transfer and that > screams MTU. > > If I ping from a Juniper router, I can get 1482 byte packets through, so > I suspect that there is a tunnel somewhere. But FreeBSD boxes die at the > lower limit. > > Does the kernel fragmentation only affect ICMP or are TCP packet also > fragmented at 1280 bytes? WRT to TCP you may also want to check the hostcache: sysctl net.inet.tcp.hostcache.list -- Bjoern A. Zeeb The greatest risk is not taking one. From linimon at FreeBSD.org Thu May 14 23:05:52 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu May 14 23:06:04 2009 Subject: kern/134531: [route] [panic] kernel crash related to routes/zebra Message-ID: <200905142305.n4EN5pAE023396@freefall.freebsd.org> Old Synopsis: kernel crash related to routes/zebra New Synopsis: [route] [panic] kernel crash related to routes/zebra Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 14 23:05:22 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134531 From steve at ibctech.ca Fri May 15 12:38:50 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri May 15 12:38:57 2009 Subject: IPv6 fragmentation weirdness In-Reply-To: <20090514214235.B09701CC12@ptavv.es.net> References: <20090514214235.B09701CC12@ptavv.es.net> Message-ID: <4A0D6253.7080509@ibctech.ca> Kevin Oberman wrote: > Second, why the heck is the fragment going out first? This should be OK, > but I suspect many firewalls (which are often not happy with fragments) > are not likely to pass a fragment which precedes the initial frame. I'll try to find some time today to see if I can replicate this issue. I've never noticed it, mind you, I haven't been looking. > Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is > something in the path that is blocking my traffic, so others may not see > this, but I think the root issues is the kernel fragmenting packets way > below MTU size. 7.2-RELEASE .iso @ ~14 Mbps from Ontario, Canada: %traceroute6 ftp.funet.fi traceroute6 to ftp.funet.fi (2001:708:10:9::20:1) from 2001:4978:1:600::2, 64 hops max, 12 byte packets 1 unassigned.v6.your.org 18.742 ms 18.863 ms 18.967 ms 2 ge2-47-107.ar1.ord1.us.nlayer.net 19.951 ms 19.985 ms 19.966 ms 3 xe-1-3-0.cr1.ord1.us.nlayer.net 51.970 ms 70.543 ms 51.435 ms 4 xe-4-1-0.cr1.nyc2.us.nlayer.net 87.404 ms 65.532 ms 63.924 ms 5 xe-1-0-0.cr1.lhr1.uk.nlayer.net 135.912 ms 134.998 ms 134.890 ms 6 2001:2000:3081:9::1 149.455 ms 150.032 ms 149.364 ms 7 s-ipv6-b1-link.ipv6.telia.net 149.408 ms 149.922 ms 148.395 ms 8 ldn-ipv6-b1-link.ipv6.telia.net 150.385 ms 148.909 ms 152.906 ms 9 2001:2000:3080:d::2 225.358 ms 220.996 ms 217.359 ms 10 helsinki0-rtr.funet.fi 225.881 ms 234.301 ms 248.352 ms 11 csc0-x0000-helsinki0.ipv6.funet.fi 226.369 ms 226.393 ms 228.843 ms 12 ftp.funet.fi 225.370 ms 226.904 ms 229.846 ms Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090515/489b2f1f/smime.bin From dfilter at FreeBSD.ORG Fri May 15 14:00:08 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Fri May 15 14:00:20 2009 Subject: kern/130628: commit references a PR Message-ID: <200905151400.n4FE08VE042002@freefall.freebsd.org> The following reply was made to PR kern/130628; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/130628: commit references a PR Date: Fri, 15 May 2009 13:59:01 +0000 (UTC) Author: dfr Date: Fri May 15 13:58:45 2009 New Revision: 192142 URL: http://svn.freebsd.org/changeset/base/192142 Log: Back port a change to the locking model used to manage active transports from FreeBSD-current to avoid a deadlock. PR: 130628 Modified: stable/7/sys/rpc/svc.c stable/7/sys/rpc/svc.h stable/7/sys/rpc/svc_dg.c stable/7/sys/rpc/svc_vc.c Modified: stable/7/sys/rpc/svc.c ============================================================================== --- stable/7/sys/rpc/svc.c Fri May 15 13:26:54 2009 (r192141) +++ stable/7/sys/rpc/svc.c Fri May 15 13:58:45 2009 (r192142) @@ -178,18 +178,23 @@ xprt_active(SVCXPRT *xprt) } void -xprt_inactive(SVCXPRT *xprt) +xprt_inactive_locked(SVCXPRT *xprt) { SVCPOOL *pool = xprt->xp_pool; - mtx_lock(&pool->sp_lock); - if (xprt->xp_active) { TAILQ_REMOVE(&pool->sp_active, xprt, xp_alink); xprt->xp_active = FALSE; } - wakeup(&pool->sp_active); +} +void +xprt_inactive(SVCXPRT *xprt) +{ + SVCPOOL *pool = xprt->xp_pool; + + mtx_lock(&pool->sp_lock); + xprt_inactive_locked(xprt); mtx_unlock(&pool->sp_lock); } Modified: stable/7/sys/rpc/svc.h ============================================================================== --- stable/7/sys/rpc/svc.h Fri May 15 13:26:54 2009 (r192141) +++ stable/7/sys/rpc/svc.h Fri May 15 13:58:45 2009 (r192142) @@ -47,6 +47,7 @@ #include #include #include +#include #endif /* @@ -128,7 +129,7 @@ struct __rpc_svcpool; */ typedef struct __rpc_svcxprt { #ifdef _KERNEL - struct mtx xp_lock; + struct sx xp_lock; struct __rpc_svcpool *xp_pool; /* owning pool (see below) */ TAILQ_ENTRY(__rpc_svcxprt) xp_link; TAILQ_ENTRY(__rpc_svcxprt) xp_alink; @@ -332,6 +333,7 @@ __END_DECLS __BEGIN_DECLS extern void xprt_active(SVCXPRT *); extern void xprt_inactive(SVCXPRT *); +extern void xprt_inactive_locked(SVCXPRT *); __END_DECLS #endif Modified: stable/7/sys/rpc/svc_dg.c ============================================================================== --- stable/7/sys/rpc/svc_dg.c Fri May 15 13:26:54 2009 (r192141) +++ stable/7/sys/rpc/svc_dg.c Fri May 15 13:58:45 2009 (r192142) @@ -53,6 +53,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -118,7 +119,7 @@ svc_dg_create(SVCPOOL *pool, struct sock xprt = mem_alloc(sizeof (SVCXPRT)); memset(xprt, 0, sizeof (SVCXPRT)); - mtx_init(&xprt->xp_lock, "xprt->xp_lock", NULL, MTX_DEF); + sx_init(&xprt->xp_lock, "xprt->xp_lock"); xprt->xp_pool = pool; xprt->xp_socket = so; xprt->xp_p1 = NULL; @@ -161,6 +162,9 @@ static enum xprt_stat svc_dg_stat(SVCXPRT *xprt) { + if (soreadable(xprt->xp_socket)) + return (XPRT_MOREREQS); + return (XPRT_IDLE); } @@ -173,22 +177,17 @@ svc_dg_recv(SVCXPRT *xprt, struct rpc_ms int error, rcvflag; /* + * Serialise access to the socket. + */ + sx_xlock(&xprt->xp_lock); + + /* * The socket upcall calls xprt_active() which will eventually * cause the server to call us here. We attempt to read a * packet from the socket and process it. If the read fails, * we have drained all pending requests so we call * xprt_inactive(). - * - * The lock protects us in the case where a new packet arrives - * on the socket after our call to soreceive fails with - * EWOULDBLOCK - the call to xprt_active() in the upcall will - * happen only after our call to xprt_inactive() which ensures - * that we will remain active. It might be possible to use - * SOCKBUF_LOCK for this - its not clear to me what locks are - * held during the upcall. */ - mtx_lock(&xprt->xp_lock); - uio.uio_resid = 1000000000; uio.uio_td = curthread; mreq = NULL; @@ -196,8 +195,19 @@ svc_dg_recv(SVCXPRT *xprt, struct rpc_ms error = soreceive(xprt->xp_socket, &raddr, &uio, &mreq, NULL, &rcvflag); if (error == EWOULDBLOCK) { - xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + /* + * We must re-test for readability after taking the + * lock to protect us in the case where a new packet + * arrives on the socket after our call to soreceive + * fails with EWOULDBLOCK. The pool lock protects us + * from racing the upcall after our soreadable() call + * returns false. + */ + mtx_lock(&xprt->xp_pool->sp_lock); + if (!soreadable(xprt->xp_socket)) + xprt_inactive_locked(xprt); + mtx_unlock(&xprt->xp_pool->sp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -208,11 +218,11 @@ svc_dg_recv(SVCXPRT *xprt, struct rpc_ms xprt->xp_socket->so_rcv.sb_flags &= ~SB_UPCALL; SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv); xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); KASSERT(raddr->sa_len < xprt->xp_rtaddr.maxlen, ("Unexpected remote address length")); @@ -301,7 +311,7 @@ svc_dg_destroy(SVCXPRT *xprt) xprt_unregister(xprt); - mtx_destroy(&xprt->xp_lock); + sx_destroy(&xprt->xp_lock); if (xprt->xp_socket) (void)soclose(xprt->xp_socket); @@ -328,7 +338,5 @@ svc_dg_soupcall(struct socket *so, void { SVCXPRT *xprt = (SVCXPRT *) arg; - mtx_lock(&xprt->xp_lock); xprt_active(xprt); - mtx_unlock(&xprt->xp_lock); } Modified: stable/7/sys/rpc/svc_vc.c ============================================================================== --- stable/7/sys/rpc/svc_vc.c Fri May 15 13:26:54 2009 (r192141) +++ stable/7/sys/rpc/svc_vc.c Fri May 15 13:58:45 2009 (r192142) @@ -54,6 +54,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -142,7 +143,7 @@ svc_vc_create(SVCPOOL *pool, struct sock } xprt = mem_alloc(sizeof(SVCXPRT)); - mtx_init(&xprt->xp_lock, "xprt->xp_lock", NULL, MTX_DEF); + sx_init(&xprt->xp_lock, "xprt->xp_lock"); xprt->xp_pool = pool; xprt->xp_socket = so; xprt->xp_p1 = NULL; @@ -219,7 +220,7 @@ svc_vc_create_conn(SVCPOOL *pool, struct cd->strm_stat = XPRT_IDLE; xprt = mem_alloc(sizeof(SVCXPRT)); - mtx_init(&xprt->xp_lock, "xprt->xp_lock", NULL, MTX_DEF); + sx_init(&xprt->xp_lock, "xprt->xp_lock"); xprt->xp_pool = pool; xprt->xp_socket = so; xprt->xp_p1 = cd; @@ -255,9 +256,9 @@ svc_vc_create_conn(SVCPOOL *pool, struct * Throw the transport into the active list in case it already * has some data buffered. */ - mtx_lock(&xprt->xp_lock); + sx_xlock(&xprt->xp_lock); xprt_active(xprt); - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (xprt); cleanup_svc_vc_create: @@ -347,22 +348,27 @@ svc_vc_rendezvous_recv(SVCXPRT *xprt, st * connection from the socket and turn it into a new * transport. If the accept fails, we have drained all pending * connections so we call xprt_inactive(). - * - * The lock protects us in the case where a new connection arrives - * on the socket after our call to accept fails with - * EWOULDBLOCK - the call to xprt_active() in the upcall will - * happen only after our call to xprt_inactive() which ensures - * that we will remain active. It might be possible to use - * SOCKBUF_LOCK for this - its not clear to me what locks are - * held during the upcall. */ - mtx_lock(&xprt->xp_lock); + sx_xlock(&xprt->xp_lock); error = svc_vc_accept(xprt->xp_socket, &so); if (error == EWOULDBLOCK) { - xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + /* + * We must re-test for new connections after taking + * the lock to protect us in the case where a new + * connection arrives after our call to accept fails + * with EWOULDBLOCK. The pool lock protects us from + * racing the upcall after our TAILQ_EMPTY() call + * returns false. + */ + ACCEPT_LOCK(); + mtx_lock(&xprt->xp_pool->sp_lock); + if (TAILQ_EMPTY(&xprt->xp_socket->so_comp)) + xprt_inactive_locked(xprt); + mtx_unlock(&xprt->xp_pool->sp_lock); + ACCEPT_UNLOCK(); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -373,11 +379,11 @@ svc_vc_rendezvous_recv(SVCXPRT *xprt, st xprt->xp_socket->so_rcv.sb_flags &= ~SB_UPCALL; SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv); xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); sa = 0; error = soaccept(so, &sa); @@ -422,7 +428,7 @@ svc_vc_destroy_common(SVCXPRT *xprt) xprt_unregister(xprt); - mtx_destroy(&xprt->xp_lock); + sx_destroy(&xprt->xp_lock); if (xprt->xp_socket) (void)soclose(xprt->xp_socket); @@ -483,21 +489,29 @@ svc_vc_stat(SVCXPRT *xprt) /* * Return XPRT_MOREREQS if we have buffered data and we are - * mid-record or if we have enough data for a record marker. + * mid-record or if we have enough data for a record + * marker. Since this is only a hint, we read mpending and + * resid outside the lock. We do need to take the lock if we + * have to traverse the mbuf chain. */ if (cd->mpending) { if (cd->resid) return (XPRT_MOREREQS); n = 0; + sx_xlock(&xprt->xp_lock); m = cd->mpending; while (m && n < sizeof(uint32_t)) { n += m->m_len; m = m->m_next; } + sx_xunlock(&xprt->xp_lock); if (n >= sizeof(uint32_t)) return (XPRT_MOREREQS); } + if (soreadable(xprt->xp_socket)) + return (XPRT_MOREREQS); + return (XPRT_IDLE); } @@ -509,6 +523,12 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms struct mbuf *m; int error, rcvflag; + /* + * Serialise access to the socket and our own record parsing + * state. + */ + sx_xlock(&xprt->xp_lock); + for (;;) { /* * If we have an mbuf chain in cd->mpending, try to parse a @@ -584,6 +604,7 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms */ xdrmbuf_create(&xprt->xp_xdrreq, cd->mreq, XDR_DECODE); cd->mreq = NULL; + sx_xunlock(&xprt->xp_lock); if (! xdr_callmsg(&xprt->xp_xdrreq, msg)) { XDR_DESTROY(&xprt->xp_xdrreq); return (FALSE); @@ -602,17 +623,7 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms * the result in cd->mpending. If the read fails, * we have drained both cd->mpending and the socket so * we can call xprt_inactive(). - * - * The lock protects us in the case where a new packet arrives - * on the socket after our call to soreceive fails with - * EWOULDBLOCK - the call to xprt_active() in the upcall will - * happen only after our call to xprt_inactive() which ensures - * that we will remain active. It might be possible to use - * SOCKBUF_LOCK for this - its not clear to me what locks are - * held during the upcall. */ - mtx_lock(&xprt->xp_lock); - uio.uio_resid = 1000000000; uio.uio_td = curthread; m = NULL; @@ -621,8 +632,20 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms &rcvflag); if (error == EWOULDBLOCK) { - xprt_inactive(xprt); - mtx_unlock(&xprt->xp_lock); + /* + * We must re-test for readability after + * taking the lock to protect us in the case + * where a new packet arrives on the socket + * after our call to soreceive fails with + * EWOULDBLOCK. The pool lock protects us from + * racing the upcall after our soreadable() + * call returns false. + */ + mtx_lock(&xprt->xp_pool->sp_lock); + if (!soreadable(xprt->xp_socket)) + xprt_inactive_locked(xprt); + mtx_unlock(&xprt->xp_pool->sp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -634,7 +657,7 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv); xprt_inactive(xprt); cd->strm_stat = XPRT_DIED; - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -642,8 +665,9 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms /* * EOF - the other end has closed the socket. */ + xprt_inactive(xprt); cd->strm_stat = XPRT_DIED; - mtx_unlock(&xprt->xp_lock); + sx_xunlock(&xprt->xp_lock); return (FALSE); } @@ -651,8 +675,6 @@ svc_vc_recv(SVCXPRT *xprt, struct rpc_ms m_last(cd->mpending)->m_next = m; else cd->mpending = m; - - mtx_unlock(&xprt->xp_lock); } } @@ -739,9 +761,7 @@ svc_vc_soupcall(struct socket *so, void { SVCXPRT *xprt = (SVCXPRT *) arg; - mtx_lock(&xprt->xp_lock); xprt_active(xprt); - mtx_unlock(&xprt->xp_lock); } #if 0 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From steve at ibctech.ca Fri May 15 16:57:34 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri May 15 16:57:41 2009 Subject: IPv6 fragmentation weirdness In-Reply-To: <4A0D6253.7080509@ibctech.ca> References: <20090514214235.B09701CC12@ptavv.es.net> <4A0D6253.7080509@ibctech.ca> Message-ID: <4A0D9EF7.3030101@ibctech.ca> Steve Bertrand wrote: > Kevin Oberman wrote: > >> Second, why the heck is the fragment going out first? This should be OK, >> but I suspect many firewalls (which are often not happy with fragments) >> are not likely to pass a fragment which precedes the initial frame. > > I'll try to find some time today to see if I can replicate this issue. > I've never noticed it, mind you, I haven't been looking. > >> Can anyone fetch anything from ftp.funet.fi via IPv6? I suspect it is >> something in the path that is blocking my traffic, so others may not see >> this, but I think the root issues is the kernel fragmenting packets way >> below MTU size. > > 7.2-RELEASE .iso @ ~14 Mbps from Ontario, Canada: ...doh! Given that fetch does v4, that 14Mb translates into ~500Kb when using v6 ;) Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090515/fd2068b1/smime.bin From linimon at FreeBSD.org Fri May 15 17:21:18 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri May 15 17:21:24 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Message-ID: <200905151721.n4FHLH9R018132@freefall.freebsd.org> Old Synopsis: 7.2 with mpd5.3 hanging up - ng_pptp problem New Synopsis: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 15 17:20:25 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134557 From brett at lariat.net Sat May 16 03:34:29 2009 From: brett at lariat.net (Brett Glass) Date: Sat May 16 03:34:36 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <7B486348-7484-46EC-9B60-5ED64B80D511@moneybookers.com> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> <200905132230.QAA20732@lariat.net> <7B486348-7484-46EC-9B60-5ED64B80D511@moneybookers.com> Message-ID: <200905160334.VAA04831@lariat.net> Unfortunately, the pfsense captive portal lacks many of the features that we need and has also had problems in some of our tests. We need the ability to "roll our own" rather than a canned solution, which is why we'd like to make sure that we can implement this via IPFW. --Brett At 01:39 AM 5/14/2009, Stefan Lambrev wrote: >Hi Brett, > >I think what you are looking for is called captive portal. >You can look at pfsense - >http://doc.pfsense.org/index.php/Category:Captive_Portal >which comes with such solution into it. From eri at freebsd.org Sat May 16 07:58:56 2009 From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Sat May 16 07:59:03 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <200905160334.VAA04831@lariat.net> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> <200905132230.QAA20732@lariat.net> <7B486348-7484-46EC-9B60-5ED64B80D511@moneybookers.com> <200905160334.VAA04831@lariat.net> Message-ID: <9a542da30905160026n780b03f4xc34ef0e39cc8b529@mail.gmail.com> What kind of features? Just out of curiosity, cause i made some fixes to it and am curious what can be added more!? On Sat, May 16, 2009 at 5:11 AM, Brett Glass wrote: > Unfortunately, the pfsense captive portal lacks many of the features that we > need and has also had problems in some of our tests. We need the ability to > "roll our own" rather than a canned solution, which is why we'd like to make > sure that we can implement this via IPFW. > > --Brett > > At 01:39 AM 5/14/2009, Stefan Lambrev wrote: > >> Hi Brett, >> >> I think what you are looking for is called captive portal. >> You can look at pfsense - >> http://doc.pfsense.org/index.php/Category:Captive_Portal >> which comes with such solution into it. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From brett at lariat.net Sat May 16 19:00:56 2009 From: brett at lariat.net (Brett Glass) Date: Sat May 16 19:01:02 2009 Subject: MAC locking and filtering in FreeBSD In-Reply-To: <9a542da30905160026n780b03f4xc34ef0e39cc8b529@mail.gmail.co m> References: <200905131648.KAA15455@lariat.net> <5AFBEB69-C59A-4F61-96BE-11E30872A428@moneybookers.com> <200905131903.NAA17981@lariat.net> <20090513213829.GA1248@haakonia.hitnet.RWTH-Aachen.DE> <200905132230.QAA20732@lariat.net> <7B486348-7484-46EC-9B60-5ED64B80D511@moneybookers.com> <200905160334.VAA04831@lariat.net> <9a542da30905160026n780b03f4xc34ef0e39cc8b529@mail.gmail.com> Message-ID: <200905161900.NAA16685@lariat.net> Among other things, more control -- including an easy way to cut off bandwidth hogs and abusers -- and a walled garden that is better able to hijack browsers (the one in pfsense often fails). We actually have quite a few things we'd like to implement. More offlist if you'd like. --Brett Glass At 01:26 AM 5/16/2009, Ermal Lu?i wrote: >What kind of features? >Just out of curiosity, cause i made some fixes to it and am curious >what can be added more!? From irix at ukr.net Sun May 17 01:07:08 2009 From: irix at ukr.net (irix) Date: Sun May 17 01:07:14 2009 Subject: altq Message-ID: <224894604.20090517035115@ukr.net> Hello Freebsd-pf, Sorry for my english. OpenBSD team is abandon the altq project. Maybe FreeBSD team does not come as OpenBSD team. In Kernel is present "options ALTQ_CDNR # Traffic conditioner", that is may be used for simple ingress traffic shaping (like dummynet). Maybe you may add this function to pfctl to make use it. Maybe after this OpenBSD team is backport this function to base. Also lacking in pf/altq dynamic queues like in dummynet with dst-masks (src-masks)(ipfw pipe 10 config mask dst-ip 0x000000ff bw 1024bit/s queue; ipfw add pipe 10 tcp from any to 1.1.1.0/24 via fxp0), when with one rule may create many dynamic queues for per ip shaping from subnet. This maybe useful for many people, because pf is most popular firewall. Thank you. -- Best regards, irix mailto:irix@ukr.net From swun2010 at gmail.com Sun May 17 01:57:35 2009 From: swun2010 at gmail.com (Sam Wun) Date: Sun May 17 01:57:41 2009 Subject: net.ipv4.ip_nonlocal_bind for FreeBSD 7.2? Message-ID: <736c47cb0905161857m220450b7uad5c7cf70ff58a48@mail.gmail.com> Hi, With regarding to net.ipv4.ip_nonlocal_bind for FreeBSD 7.2, Is there any equivalent parameters I I have to tune or has it been *built-in* to the freebsd 7.2 kernel? Thanks From bra at fsn.hu Sun May 17 18:46:29 2009 From: bra at fsn.hu (Attila Nagy) Date: Sun May 17 18:46:43 2009 Subject: Routing related crash in -CURRENT, introduced between 5th May and yesterday Message-ID: <4A1057D2.5090800@fsn.hu> Hello, Somewhere between 5th May and yesterday there was a (routing related?) change, which causes this machine crash at boot: http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859077575768514 http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859069031814370 The machine itself is an HP DL380G4 with bge interfaces and netbooted via PXE. A build, compiled on 5th May works fine, but this (compiled today, but with a yesterday build this is also the same) isn't. 7-STABLE also works fine on these kind of machines and this setup. Another interesting thing is while 7-STABLE (and from 5.x to 7-STABLE as of the start of May (that's the latest build we use, if there were bge related changes MFC-ed since that, I don't know)) can boot on this kind of machines with the default hw.bge.allow_asf=1, -CURRENT can't. It stops right after recognizing disk devices, even with verbose boot. That is the point, where DHCP (still netbooting) kicks in... I think these kind of machines are not rare (I admit that not everybody uses netbooting with them, but -CURRENT freezes even when installing from CD, when the installer tries to configure the interfaces), so it would be good to correct (and not MFC what is on HEAD until that) this regression. If I can do any debugging or give more information, please let me know! Thanks, From bra at fsn.hu Sun May 17 19:03:21 2009 From: bra at fsn.hu (Attila Nagy) Date: Sun May 17 19:03:27 2009 Subject: Routing related crash in -CURRENT, introduced between 5th May and yesterday In-Reply-To: <4A1057D2.5090800@fsn.hu> References: <4A1057D2.5090800@fsn.hu> Message-ID: <4A105F75.1000904@fsn.hu> Attila Nagy wrote: > Hello, > > Somewhere between 5th May and yesterday there was a (routing related?) > change, which causes this machine crash at boot: > http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859077575768514 > > http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859069031814370 > > > The machine itself is an HP DL380G4 with bge interfaces and netbooted > via PXE. > > A build, compiled on 5th May works fine, but this (compiled today, but > with a yesterday build this is also the same) isn't. > > 7-STABLE also works fine on these kind of machines and this setup. > > Another interesting thing is while 7-STABLE (and from 5.x to 7-STABLE > as of the start of May (that's the latest build we use, if there were > bge related changes MFC-ed since that, I don't know)) can boot on this > kind of machines with the default hw.bge.allow_asf=1, -CURRENT can't. > It stops right after recognizing disk devices, even with verbose boot. > That is the point, where DHCP (still netbooting) kicks in... > > I think these kind of machines are not rare (I admit that not > everybody uses netbooting with them, but -CURRENT freezes even when > installing from CD, when the installer tries to configure the > interfaces), so it would be good to correct (and not MFC what is on > HEAD until that) this regression. > > If I can do any debugging or give more information, please let me know! I've found this: http://lists.freebsd.org/pipermail/svn-src-all/2009-May/008730.html which seems to be the place where the kernel dies according to the bt. I hope qingli will take care of it. And for the bge stuff, I've just noticed that allow_asf is off in 7-STABLE, so it's probably not a regression in code, but in behaviour. (which can be more easily fixed, but I don't know whether it worths to be on) From bzeeb-lists at lists.zabbadoz.net Sun May 17 19:14:18 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun May 17 19:14:27 2009 Subject: Routing related crash in -CURRENT, introduced between 5th May and yesterday In-Reply-To: <4A1057D2.5090800@fsn.hu> References: <4A1057D2.5090800@fsn.hu> Message-ID: <20090517185206.S72053@maildrop.int.zabbadoz.net> On Sun, 17 May 2009, Attila Nagy wrote: Hi, > Somewhere between 5th May and yesterday there was a (routing related?) > change, which causes this machine crash at boot: > http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859077575768514 > http://picasaweb.google.com/nagy.attila/20090517Fbsd8Crash#5336859069031814370 > > The machine itself is an HP DL380G4 with bge interfaces and netbooted via > PXE. > > A build, compiled on 5th May works fine, but this (compiled today, but with a > yesterday build this is also the same) isn't. This one is known. People are working on it. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From freebsd at chrisbuechler.com Sun May 17 20:25:40 2009 From: freebsd at chrisbuechler.com (Chris Buechler) Date: Sun May 17 20:25:48 2009 Subject: multi-homed systems stop answering ARP on local addresses w/ifconfig aliases Message-ID: <4A106EB1.1070709@chrisbuechler.com> There seems to be a regression between 6.x and 7.0 and 7.1 related to ifconfig aliases on multi-homed hosts. Not sure on anything newer than 7.1 (this is pfSense, we're just starting to test 7.2 builds). For periods of time, the system will stop answering ARP on some of its own addresses and hence anything on that network completely stops functioning. The same setup worked fine on 6.2. The particular system illustrated here is a router on part of an ISP's network. IPs are all public, in the info provided here they've been replaced with 10. IPs. The subnets on the inside interfaces are routed to the outside interface. When this problem occurs, the IPs assigned locally on the system will still respond from the Internet, but the system itself loses all connectivity with that subnet and nothing on that subnet can communicate with the host due to the lack of ARP. That makes some sense, I presume when routing to a locally assigned address via another interface, the system doesn't need ARP on the address to respond. But while it still responds from the Internet, even the host itself can't initiate a ping to that IP. It behaves the same whether pf is enabled or disabled. I see two similar issues in the past, one with a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=121437&cat= that's exactly the same issue, it's not limited to VLANs, any multi-homed host is affected. And another: http://thread.gmane.org/gmane.os.freebsd.stable/57125 fxp0 is the outside interface. It doesn't make any difference whether the ifconfig aliases are on the em0 or fxp1 interfaces, they both behave the same if they have any ifconfig aliases assigned. # ifconfig fxp0: flags=8843 metric 0 mtu 1500 options=8 ether 00:90:27:86:8b:9d inet6 fe80::290:27ff:fe86:8b9d%fxp0 prefixlen 64 scopeid 0x1 inet 10.11.185.146 netmask 0xfffffff8 broadcast 10.11.185.151 media: Ethernet 100baseTX status: active em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:43:2c:62:03 inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 inet6 fe80::211:43ff:fe2c:6203%em0 prefixlen 64 scopeid 0x2 inet 10.13.40.1 netmask 0xffffff00 broadcast 10.13.40.255 inet 10.13.41.1 netmask 0xffffff00 broadcast 10.13.41.255 inet 10.13.42.1 netmask 0xffffff00 broadcast 10.13.42.255 inet 10.13.43.1 netmask 0xffffff00 broadcast 10.13.43.255 inet 10.13.44.1 netmask 0xffffff00 broadcast 10.13.44.255 inet 10.13.45.1 netmask 0xffffff00 broadcast 10.13.45.255 inet 10.13.46.1 netmask 0xffffff00 broadcast 10.13.46.255 inet 10.13.47.1 netmask 0xffffff00 broadcast 10.13.47.255 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8843 metric 0 mtu 1500 options=8 ether 00:d0:b7:5d:25:9f inet 10.1.242.1 netmask 0xffffff00 broadcast 10.1.242.255 inet6 fe80::2d0:b7ff:fe5d:259f%fxp1 prefixlen 64 scopeid 0x3 inet 10.1.243.1 netmask 0xffffff00 broadcast 10.1.243.255 media: Ethernet autoselect (100baseTX ) status: active When the problem is occurring, you can't even ping the affected locally assigned addresses from the box itself: # ping 10.10.0.1 PING 10.10.0.1 (10.10.0.1): 56 data bytes ping: sendto: Network is unreachable ping: sendto: Network is unreachable ping: sendto: Network is unreachable And when trying to ping something on one of the affected attached subnets, you get: # ping 10.10.0.30 PING 10.10.0.30 (10.10.0.30): 56 data bytes ping: sendto: Invalid argument ping: sendto: Invalid argument In the logs, you get a flood of these messages: May 14 02:55:12 kernel: arpresolve: can't allocate route for 10.10.0.1 May 14 02:55:12 kernel: arplookup 10.10.0.1 failed: host is not on local network May 14 02:55:12 kernel: arpresolve: can't allocate route for 10.10.0.1 May 14 02:55:12 kernel: arplookup 10.10.0.1 failed: host is not on local network It happens both with the primary IP assigned to the interface, and the aliases assigned, but not all at once. Some of the addresses will continue to work when others are failing. Somehow it thinks IPs that are locally assigned are not on a local network... after a couple minutes, it just starts working again without making any changes or even touching the system. If I can provide any additional information, please let me know. thanks, Chris From killing at multiplay.co.uk Sun May 17 20:46:32 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Sun May 17 20:46:40 2009 Subject: multi-homed systems stop answering ARP on local addresses w/ifconfig aliases References: <4A106EB1.1070709@chrisbuechler.com> Message-ID: Silly question but something else on the network isn't doing a arp spoof attack is it? Regards Steve ----- Original Message ----- From: "Chris Buechler" To: Sent: Sunday, May 17, 2009 9:08 PM Subject: multi-homed systems stop answering ARP on local addresses w/ifconfig aliases > There seems to be a regression between 6.x and 7.0 and 7.1 related to > ifconfig aliases on multi-homed hosts. Not sure on anything newer than > 7.1 (this is pfSense, we're just starting to test 7.2 builds). For > periods of time, the system will stop answering ARP on some of its own > addresses and hence anything on that network completely stops > functioning. The same setup worked fine on 6.2. > > The particular system illustrated here is a router on part of an ISP's > network. IPs are all public, in the info provided here they've been > replaced with 10. IPs. The subnets on the inside interfaces are routed > to the outside interface. When this problem occurs, the IPs assigned > locally on the system will still respond from the Internet, but the > system itself loses all connectivity with that subnet and nothing on > that subnet can communicate with the host due to the lack of ARP. That > makes some sense, I presume when routing to a locally assigned address > via another interface, the system doesn't need ARP on the address to > respond. But while it still responds from the Internet, even the host > itself can't initiate a ping to that IP. It behaves the same whether pf > is enabled or disabled. > > I see two similar issues in the past, one with a PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=121437&cat= > that's exactly the same issue, it's not limited to VLANs, any > multi-homed host is affected. > > And another: > http://thread.gmane.org/gmane.os.freebsd.stable/57125 > > fxp0 is the outside interface. It doesn't make any difference whether > the ifconfig aliases are on the em0 or fxp1 interfaces, they both behave > the same if they have any ifconfig aliases assigned. > > # ifconfig > fxp0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:90:27:86:8b:9d > inet6 fe80::290:27ff:fe86:8b9d%fxp0 prefixlen 64 scopeid 0x1 > inet 10.11.185.146 netmask 0xfffffff8 broadcast 10.11.185.151 > media: Ethernet 100baseTX > status: active > em0: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:11:43:2c:62:03 > inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 > inet6 fe80::211:43ff:fe2c:6203%em0 prefixlen 64 scopeid 0x2 > inet 10.13.40.1 netmask 0xffffff00 broadcast 10.13.40.255 > inet 10.13.41.1 netmask 0xffffff00 broadcast 10.13.41.255 > inet 10.13.42.1 netmask 0xffffff00 broadcast 10.13.42.255 > inet 10.13.43.1 netmask 0xffffff00 broadcast 10.13.43.255 > inet 10.13.44.1 netmask 0xffffff00 broadcast 10.13.44.255 > inet 10.13.45.1 netmask 0xffffff00 broadcast 10.13.45.255 > inet 10.13.46.1 netmask 0xffffff00 broadcast 10.13.46.255 > inet 10.13.47.1 netmask 0xffffff00 broadcast 10.13.47.255 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:d0:b7:5d:25:9f > inet 10.1.242.1 netmask 0xffffff00 broadcast 10.1.242.255 > inet6 fe80::2d0:b7ff:fe5d:259f%fxp1 prefixlen 64 scopeid 0x3 > inet 10.1.243.1 netmask 0xffffff00 broadcast 10.1.243.255 > media: Ethernet autoselect (100baseTX ) > status: active > > > > When the problem is occurring, you can't even ping the affected locally > assigned addresses from the box itself: > # ping 10.10.0.1 > PING 10.10.0.1 (10.10.0.1): 56 data bytes > ping: sendto: Network is unreachable > ping: sendto: Network is unreachable > ping: sendto: Network is unreachable > > And when trying to ping something on one of the affected attached > subnets, you get: > # ping 10.10.0.30 > PING 10.10.0.30 (10.10.0.30): 56 data bytes > ping: sendto: Invalid argument > ping: sendto: Invalid argument > > > In the logs, you get a flood of these messages: > May 14 02:55:12 kernel: arpresolve: can't allocate route for 10.10.0.1 > May 14 02:55:12 kernel: arplookup 10.10.0.1 failed: host is not on > local network > May 14 02:55:12 kernel: arpresolve: can't allocate route for 10.10.0.1 > May 14 02:55:12 kernel: arplookup 10.10.0.1 failed: host is not on > local network > > > It happens both with the primary IP assigned to the interface, and the > aliases assigned, but not all at once. Some of the addresses will > continue to work when others are failing. Somehow it thinks IPs that are > locally assigned are not on a local network... after a couple minutes, > it just starts working again without making any changes or even touching > the system. > > If I can provide any additional information, please let me know. > > thanks, > Chris > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From cbuechler at gmail.com Sun May 17 21:04:02 2009 From: cbuechler at gmail.com (Chris Buechler) Date: Sun May 17 21:04:09 2009 Subject: multi-homed systems stop answering ARP on local addresses w/ifconfig aliases In-Reply-To: References: <4A106EB1.1070709@chrisbuechler.com> Message-ID: On Sun, May 17, 2009 at 4:35 PM, Steven Hartland wrote: > Silly question but something else on the network isn't doing a arp spoof > attack is it? > No, there isn't any ARP at all on that address on the network when this is a problem, verified with tcpdump. That also shouldn't impact the system's ability to talk to its own IPs. thanks for the response though! > ----- Original Message ----- From: "Chris Buechler" > > To: > Sent: Sunday, May 17, 2009 9:08 PM > Subject: multi-homed systems stop answering ARP on local addresses > w/ifconfig aliases > > >> There seems to be a regression between 6.x and 7.0 and 7.1 related to >> ifconfig aliases on multi-homed hosts. Not sure on anything newer than 7.1 >> (this is pfSense, we're just starting to test 7.2 builds). For periods of >> time, the system will stop answering ARP on some of its own addresses and >> hence anything on that network completely stops functioning. The same setup >> worked fine on 6.2. >> >> The particular system illustrated here is a router on part of an ISP's >> network. IPs are all public, in the info provided here they've been replaced >> with 10. IPs. The subnets on the inside interfaces are routed to the outside >> interface. When this problem occurs, the IPs assigned locally on the system >> will still respond from the Internet, but the system itself loses all >> connectivity with that subnet and nothing on that subnet can communicate >> with the host due to the lack of ARP. That makes some sense, I presume when >> routing to a locally assigned address via another interface, the system >> doesn't need ARP on the address to respond. But while it still responds from >> the Internet, even the host itself can't initiate a ping to that IP. It >> behaves the same whether pf is enabled or disabled. >> >> I see two similar issues in the past, one with a PR: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=121437&cat= >> that's exactly the same issue, it's not limited to VLANs, any multi-homed >> host is affected. >> >> And another: >> http://thread.gmane.org/gmane.os.freebsd.stable/57125 >> >> fxp0 is the outside interface. It doesn't make any difference whether the >> ifconfig aliases are on the em0 or fxp1 interfaces, they both behave the >> same if they have any ifconfig aliases assigned. >> >> # ifconfig >> fxp0: flags=8843 metric 0 mtu 1500 >> ? ? ? options=8 >> ? ? ? ether 00:90:27:86:8b:9d >> ? ? ? inet6 fe80::290:27ff:fe86:8b9d%fxp0 prefixlen 64 scopeid 0x1 >> ? ? ? inet 10.11.185.146 netmask 0xfffffff8 broadcast 10.11.185.151 >> ? ? ? media: Ethernet 100baseTX >> ? ? ? status: active >> em0: flags=8843 metric 0 mtu 1500 >> ? ? ? options=9b >> ? ? ? ether 00:11:43:2c:62:03 >> ? ? ? inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 >> ? ? ? inet6 fe80::211:43ff:fe2c:6203%em0 prefixlen 64 scopeid 0x2 >> ? ? ? inet 10.13.40.1 netmask 0xffffff00 broadcast 10.13.40.255 >> ? ? ? inet 10.13.41.1 netmask 0xffffff00 broadcast 10.13.41.255 >> ? ? ? inet 10.13.42.1 netmask 0xffffff00 broadcast 10.13.42.255 >> ? ? ? inet 10.13.43.1 netmask 0xffffff00 broadcast 10.13.43.255 >> ? ? ? inet 10.13.44.1 netmask 0xffffff00 broadcast 10.13.44.255 >> ? ? ? inet 10.13.45.1 netmask 0xffffff00 broadcast 10.13.45.255 >> ? ? ? inet 10.13.46.1 netmask 0xffffff00 broadcast 10.13.46.255 >> ? ? ? inet 10.13.47.1 netmask 0xffffff00 broadcast 10.13.47.255 >> ? ? ? media: Ethernet autoselect (100baseTX ) >> ? ? ? status: active >> fxp1: flags=8843 metric 0 mtu 1500 >> ? ? ? options=8 >> ? ? ? ether 00:d0:b7:5d:25:9f >> ? ? ? inet 10.1.242.1 netmask 0xffffff00 broadcast 10.1.242.255 >> ? ? ? inet6 fe80::2d0:b7ff:fe5d:259f%fxp1 prefixlen 64 scopeid 0x3 >> ? ? ? inet 10.1.243.1 netmask 0xffffff00 broadcast 10.1.243.255 >> ? ? ? media: Ethernet autoselect (100baseTX ) >> ? ? ? status: active >> >> >> >> When the problem is occurring, you can't even ping the affected locally >> assigned addresses from the box itself: >> # ping 10.10.0.1 >> PING 10.10.0.1 (10.10.0.1): 56 data bytes >> ping: sendto: Network is unreachable >> ping: sendto: Network is unreachable >> ping: sendto: Network is unreachable >> >> And when trying to ping something on one of the affected attached subnets, >> you get: >> # ping 10.10.0.30 >> PING 10.10.0.30 (10.10.0.30): 56 data bytes >> ping: sendto: Invalid argument >> ping: sendto: Invalid argument >> >> >> In the logs, you get a flood of these messages: >> May 14 02:55:12 ? ?kernel: arpresolve: can't allocate route for 10.10.0.1 >> May 14 02:55:12 ? ?kernel: arplookup 10.10.0.1 failed: host is not on >> local network >> May 14 02:55:12 ? ?kernel: arpresolve: can't allocate route for 10.10.0.1 >> May 14 02:55:12 ? ?kernel: arplookup 10.10.0.1 failed: host is not on >> local network >> >> >> It happens both with the primary IP assigned to the interface, and the >> aliases assigned, but not all at once. Some of the addresses will continue >> to work when others are failing. Somehow it thinks IPs that are locally >> assigned are not on a local network... after a couple minutes, it just >> starts working again without making any changes or even touching the system. >> >> If I can provide any additional information, please let me know. >> >> thanks, >> Chris >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > From irix at ukr.net Sun May 17 23:48:44 2009 From: irix at ukr.net (irix) Date: Sun May 17 23:48:50 2009 Subject: altq Message-ID: <609243039.20090518024926@ukr.net> Hello , First of all,person who is responsible for this answer for my question about dynamics queues and finely complete to merge cdnr into pf, that altq nothing else, and complete does not this function. You need and you do. We are not interested in this. But altq is not complete solution. From altqd make any abnormality. The idea of merging with pf excellent, but the realization of an unfinished, even at 30%. Removed 70% of traffic disciplince's (like blue, JoBBs), did not finish cdnr, nothing new added. How can this be called complete project? In DfBSD in altq add fairq, is one new option in altq for last six years. No development, the project is dead. I can understand, when project is complete, more it did not need to add. But altq in pf have almost nothing. And developers say it does not concern us. So I wrote up in maillist freebsd, as in most advanced bsd system. Developers who think for a few years in advance. > On Sat, May 16, 2009 21:45, irix wrote: > Hello Freebsd-pf, > > Sorry for my english. > > OpenBSD team is abandon the altq project. > >I just got curious about this: where you heard that OpenBSD is abandoning >altq ? > >thanks, > >matheus > >-- >We will call you cygnus, >The God of balance you shall be > >A: Because it messes up the order in which people normally read text. >Q: Why is top-posting such a bad thing? > >http://en.wikipedia.org/wiki/Posting_style -- Best regards, irix mailto:irix@ukr.net From nvass9573 at gmx.com Mon May 18 08:44:59 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Mon May 18 08:45:06 2009 Subject: arp fails to clear mapping for deleted network Message-ID: <4A111FDC.5030400@gmx.com> Hello, It seems that: 1) if I assign an IP address to an interface 2) get an arp mapping via this interface 3) remove the IP address from the interface arp fails to remove this arp entry when arp -d is used > lab# ifconfig rl0 192.168.254.30 > lab# ping 192.168.254.254 > PING 192.168.254.254 (192.168.254.254): 56 data bytes > 64 bytes from 192.168.254.254: icmp_seq=0 ttl=64 time=0.427 ms > 64 bytes from 192.168.254.254: icmp_seq=1 ttl=64 time=0.434 ms > 64 bytes from 192.168.254.254: icmp_seq=2 ttl=64 time=0.442 ms > 64 bytes from 192.168.254.254: icmp_seq=3 ttl=64 time=0.467 ms > 64 bytes from 192.168.254.254: icmp_seq=4 ttl=64 time=0.445 ms > ^C > --- 192.168.254.254 ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.427/0.443/0.467/0.014 ms > lab# arp 192.168.254.254 > ? (192.168.254.254) at 00:18:d1:e4:ee:29 on rl0 [ethernet] > lab# ifconfig rl0 delete > lab# arp 192.168.254.254 > ? (192.168.254.254) at 00:18:d1:e4:ee:29 on rl0 [ethernet] > lab# arp -d 192.168.254.254 > arp: writing to routing socket: No such process > arp: 192.168.254.254: No such process > lab# arp 192.168.254.254 > ? (192.168.254.254) at 00:18:d1:e4:ee:29 on rl0 [ethernet] > lab# This is from a few days old -current. I just noticed this somehow strange behavior, but I don't really know if it's old or new. Nikos From qing.li at bluecoat.com Mon May 18 08:51:14 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Mon May 18 08:51:21 2009 Subject: arp fails to clear mapping for deleted network References: <4A111FDC.5030400@gmx.com> Message-ID: Hmm... that's odd. This was an issue but I fixed this bug months ago. Let me see if I can recreate what you've described with the latest -current and get back to you later today. -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Nikos Vassiliadis Sent: Mon 5/18/2009 1:44 AM To: freebsd-net@freebsd.org Subject: arp fails to clear mapping for deleted network Hello, It seems that: 1) if I assign an IP address to an interface 2) get an arp mapping via this interface 3) remove the IP address from the interface arp fails to remove this arp entry when arp -d is used > lab# ifconfig rl0 192.168.254.30 > lab# ping 192.168.254.254 > PING 192.168.254.254 (192.168.254.254): 56 data bytes > 64 bytes from 192.168.254.254: icmp_seq=0 ttl=64 time=0.427 ms > 64 bytes from 192.168.254.254: icmp_seq=1 ttl=64 time=0.434 ms > 64 bytes from 192.168.254.254: icmp_seq=2 ttl=64 time=0.442 ms > 64 bytes from 192.168.254.254: icmp_seq=3 ttl=64 time=0.467 ms > 64 bytes from 192.168.254.254: icmp_seq=4 ttl=64 time=0.445 ms > ^C > --- 192.168.254.254 ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.427/0.443/0.467/0.014 ms > lab# arp 192.168.254.254 > ? (192.168.254.254) at 00:18:d1:e4:ee:29 on rl0 [ethernet] > lab# ifconfig rl0 delete > lab# arp 192.168.254.254 > ? (192.168.254.254) at 00:18:d1:e4:ee:29 on rl0 [ethernet] > lab# arp -d 192.168.254.254 > arp: writing to routing socket: No such process > arp: 192.168.254.254: No such process > lab# arp 192.168.254.254 > ? (192.168.254.254) at 00:18:d1:e4:ee:29 on rl0 [ethernet] > lab# This is from a few days old -current. I just noticed this somehow strange behavior, but I don't really know if it's old or new. Nikos _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From sebastian.mellmann at net.t-labs.tu-berlin.de Mon May 18 09:26:11 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Mon May 18 09:26:18 2009 Subject: Not able to set 'bridge' mode Message-ID: <1242637365.31782.4.camel@python.net.t-labs.tu-berlin.de> Hello everyone! I'm trying to set up a FreeBSD 7.2 machine with ipfw dummynet working as a bridge. I've tried this tutorial: http://www.scalabledesign.com/articles/dummynet.html But it seems that the 'BRIDGE' option for the kernel is deprecated (see http://lists.freebsd.org/pipermail/freebsd-questions/2008-May/175704.html) So my kernel config now looks like this: device if_bridge options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT options DUMMYNET options HZ=1000 I've compiled the kernel successfully, but I'm not able to set any bridge options. I've tried to enable bridge mode in ipfw with: sysctl net.link.ether.bridge_ipfw=1 and got sysctl: unknown oid 'net.link.ether.bridge_ipfw' Am I missing something? Regards, Sebastian From virgos83 at yahoo.com Mon May 18 09:33:33 2009 From: virgos83 at yahoo.com (srinidhi gopal) Date: Mon May 18 09:33:40 2009 Subject: Route entry not updated - ICMPv6 Redirect Message-ID: <77376.38545.qm@web95207.mail.in2.yahoo.com> Hi, I have query regarding the behavior of FreeBSD machine upon receiving ICMPv6 Redirect msg. I am using FreeBSD 7 as Host and Linux as Router. The Router send a ICMPv6 Redirect msg, but the BSD Host doesn't update the routing table. I have verified all the sysctl values related to redirect : net.inet.ip.redirect: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet6.ip6.redirect: 1 Kindly help me in resolving this issue. Thanks in advance. Regards, Srinidhi Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel.yahoo.com/ From rea-fbsd at codelabs.ru Mon May 18 09:38:24 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon May 18 09:38:33 2009 Subject: Not able to set 'bridge' mode In-Reply-To: <1242637365.31782.4.camel@python.net.t-labs.tu-berlin.de> References: <1242637365.31782.4.camel@python.net.t-labs.tu-berlin.de> Message-ID: Sebastian, good day. Mon, May 18, 2009 at 11:02:45AM +0200, Sebastian Mellmann wrote: > I'm trying to set up a FreeBSD 7.2 machine with ipfw dummynet working as > a bridge. > > I've tried this tutorial: > > http://www.scalabledesign.com/articles/dummynet.html > > But it seems that the 'BRIDGE' option for the kernel is deprecated (see > http://lists.freebsd.org/pipermail/freebsd-questions/2008-May/175704.html) Yeah, BRIDGE is obsoleted now. > So my kernel config now looks like this: > > device if_bridge > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT > options DUMMYNET > options HZ=1000 > > I've compiled the kernel successfully, but I'm not able to set any > bridge options. > > I've tried to enable bridge mode in ipfw with: > > sysctl net.link.ether.bridge_ipfw=1 > > and got > > sysctl: unknown oid 'net.link.ether.bridge_ipfw' > > Am I missing something? Yeah, seems like you hadn't yet read "man if_bridge" -- it has the collection of relevant sysctl variables in section "PACKET FILTERING". Moreover, man page has instructions on how to get bridge interfaces up and running. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From pluknet at gmail.com Mon May 18 09:38:33 2009 From: pluknet at gmail.com (pluknet) Date: Mon May 18 09:38:39 2009 Subject: Not able to set 'bridge' mode In-Reply-To: <1242637365.31782.4.camel@python.net.t-labs.tu-berlin.de> References: <1242637365.31782.4.camel@python.net.t-labs.tu-berlin.de> Message-ID: 2009/5/18 Sebastian Mellmann : > Hello everyone! > > I'm trying to set up a FreeBSD 7.2 machine with ipfw dummynet working as > a bridge. > > I've tried this tutorial: > > http://www.scalabledesign.com/articles/dummynet.html > > But it seems that the 'BRIDGE' option for the kernel is deprecated (see > http://lists.freebsd.org/pipermail/freebsd-questions/2008-May/175704.html) > bridge(4) was superseded by if_bridge(4) since 6.x (in 6 it was for transitional period). Check up man if_bridge. There are sysctl:s described. > So my kernel config now looks like this: > > device ? ? ? ? ?if_bridge > options ? ? ? ? IPFIREWALL > options ? ? ? ? IPFIREWALL_VERBOSE > options ? ? ? ? IPFIREWALL_VERBOSE_LIMIT > options ? ? ? ? DUMMYNET > options ? ? ? ? HZ=1000 > > I've compiled the kernel successfully, but I'm not able to set any > bridge options. > > I've tried to enable bridge mode in ipfw with: > > sysctl net.link.ether.bridge_ipfw=1 It should be now sysctl net.link.bridge.ipfw apparently. -- wbr, pluknet From bugmaster at FreeBSD.org Mon May 18 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 18 11:08:55 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200905181106.n4IB6uuL075736@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/134557 net [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up p kern/134220 net [ng_netflow] [patch]: incorrect comparison in ng_netfl o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem o kern/132984 net [netgraph] swi1: net 100% cpu usage f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 304 problems total. From sebastian.mellmann at net.t-labs.tu-berlin.de Mon May 18 12:04:57 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Mon May 18 12:05:04 2009 Subject: ipfw firewall_type 'OPEN' Message-ID: <1242648290.31782.9.camel@python.net.t-labs.tu-berlin.de> Hi everyone! I've set the following parameters in rc.conf: gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" firewall_logging="YES" When I took a look at the ruleset I see: 00010 allow ip from any to any via lo0 65000 allow ip from any to any 65535 deny ip from any to any The problem is, if I execute my own ipfw script and flush the rules via 'ipfw -q -f flush' and 'ipfw -q -f pipe flush' I'm loosing my ssh connection to that machine. Is there any chance to remove the rule 65535 or change it to allow instead of deny? I've got another FreeBSD machine here (7.0) where the default setting is '65535 allow ip from any to any', when using firwall_type OPEN. Both rc.conf files are the same! Regards, Sebastian From marius at nuenneri.ch Mon May 18 12:45:23 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Mon May 18 12:45:30 2009 Subject: ipfw firewall_type 'OPEN' In-Reply-To: <1242648290.31782.9.camel@python.net.t-labs.tu-berlin.de> References: <1242648290.31782.9.camel@python.net.t-labs.tu-berlin.de> Message-ID: On Mon, May 18, 2009 at 14:04, Sebastian Mellmann wrote: > Hi everyone! > > I've set the following parameters in rc.conf: > > gateway_enable="YES" > firewall_enable="YES" > firewall_type="OPEN" > firewall_logging="YES" > > When I took a look at the ruleset I see: > > 00010 allow ip from any to any via lo0 > 65000 allow ip from any to any > 65535 deny ip from any to any > > > The problem is, if I execute my own ipfw script and flush the rules via > 'ipfw -q -f flush' > and > 'ipfw -q -f pipe flush' > I'm loosing my ssh connection to that machine. > Is there any chance to remove the rule 65535 or change it to allow > instead of deny? > > I've got another FreeBSD machine here (7.0) where the default setting is > '65535 allow ip from any to any', when using firwall_type OPEN. > Both rc.conf files are the same! > There is a kernel option to do, see ipfw(4). From rea-fbsd at codelabs.ru Mon May 18 13:15:17 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Mon May 18 13:15:24 2009 Subject: ipfw firewall_type 'OPEN' In-Reply-To: <1242648290.31782.9.camel@python.net.t-labs.tu-berlin.de> References: <1242648290.31782.9.camel@python.net.t-labs.tu-berlin.de> Message-ID: Sebastian, Mon, May 18, 2009 at 02:04:50PM +0200, Sebastian Mellmann wrote: > 00010 allow ip from any to any via lo0 > 65000 allow ip from any to any > 65535 deny ip from any to any > > > The problem is, if I execute my own ipfw script and flush the rules via > 'ipfw -q -f flush' > and > 'ipfw -q -f pipe flush' > I'm loosing my ssh connection to that machine. > Is there any chance to remove the rule 65535 or change it to allow > instead of deny? Yes, insert ----- options IPFIREWALL_DEFAULT_TO_ACCEPT ----- to your kernel configuration, rebuild, install and use new kernel. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From linimon at FreeBSD.org Mon May 18 23:12:26 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 18 23:12:38 2009 Subject: kern/134658: [bce] bce driver fails on PowerEdge m610 blade. Message-ID: <200905182312.n4INCP2t080394@freefall.freebsd.org> Old Synopsis: bce driver fails on PowerEdge m610 blade. New Synopsis: [bce] bce driver fails on PowerEdge m610 blade. Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 18 23:11:45 UTC 2009 Responsible-Changed-Why: Take a guess that this is not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=134658 From sergei.cherveni at gmail.com Tue May 19 06:30:06 2009 From: sergei.cherveni at gmail.com (Sergei Cherveni) Date: Tue May 19 06:30:13 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Message-ID: <200905190630.n4J6U51W065407@freefall.freebsd.org> The following reply was made to PR kern/134557; it has been noted by GNATS. From: Sergei Cherveni To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Date: Tue, 19 May 2009 08:53:53 +0300 FreeBSD 7.1-R does not hang with pptp-clients connected to server via pppoe link. From swun2010 at gmail.com Tue May 19 10:27:03 2009 From: swun2010 at gmail.com (Sam Wun) Date: Tue May 19 10:27:10 2009 Subject: tcp/udp base Heartbeat for http loadbalancer? Message-ID: <736c47cb0905190327n75507247r497ea8f284297659@mail.gmail.com> Hi, Is there any tcp/udp base heartbeat for http loadbalancer for FreeBSD 7? Thanks From mav at FreeBSD.org Tue May 19 20:20:07 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue May 19 20:20:13 2009 Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Message-ID: <200905192020.n4JKK6UI023382@freefall.freebsd.org> The following reply was made to PR kern/134557; it has been noted by GNATS. From: Alexander Motin To: bug-followup@FreeBSD.org, sergei.cherveni@gmail.com Cc: Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem Date: Tue, 19 May 2009 23:16:13 +0300 Are you sure, that you haven't made routing or some other kind traffic loop in kernel? There was added some protection against it recently, but may be you have found some new way to do it? It was quite popular. -- Alexander Motin From zachary.loafman at isilon.com Tue May 19 21:26:11 2009 From: zachary.loafman at isilon.com (Zachary Loafman) Date: Tue May 19 21:26:17 2009 Subject: [PATCH] SYN issue Message-ID: <20090519211346.GC675@isilon.com> net@ - A short patch attached that requires 3 paragraphs of explanation. We found an issue in TCP when the a client connects to our server, establishes a connection, reboots and chooses the same source port to re-establish the connection. This isn't hard from other vendors' clients. On Solaris, the same NFS mount order at boot time will frequently result in source port re-use for the NFS connections. In this case, the customer was seeing mounts hang until the keepalive on our side would kick the established connection. The problem in the code is probably best explained using the patch itself: --- Index: sys/netinet/tcp_input.c =================================================================== --- sys/netinet/tcp_input.c (revision xxxx) +++ sys/netinet/tcp_input.c (working copy) @@ -1818,7 +1818,11 @@ tcp_do_segment(struct mbuf *m, struct tc todrop = tp->rcv_nxt - th->th_seq; if (todrop > 0) { - if (thflags & TH_SYN) { + /* + * If this is a duplicate SYN for our current connection, + * advance over it and pretend and it's not a SYN. + */ + if (thflags & TH_SYN && th->th_seq == tp->irs) { thflags &= ~TH_SYN; th->th_seq++; if (th->th_urp > 1) --- The problem is that when our TCP stack gets a SYN packet for a connection that's already in ESTABLISHED state, it runs through the above code. The above code is basically noticing that the packet is coming in left of the receive window and then saying "Ah, a SYN! This must be a duplicate SYN for our existing connect." After that, it just turns off SYN and treats it as a normal packet (after advancing past the SYN seq number). The code is broken, though: the only condition under which this is a duplicate SYN is if the th_seq matches the irs, the initial receive sequence. After correcting the above, any SYN that doesn't exactly match the initial sequence number results in a RST|ACK response and the ESTABLISHED connection being dropped. Before this change, this is also what happened if a SYN arrived within or past the window, so I'm basically making the before-window behavior match the other behavior. I tested this using telnet to establish a TCP connection and raw packet injection to throw SYNs at it. Comments? -- Zach Loafman | Staff Engineer | Isilon Systems -------------- next part -------------- A non-text attachment was scrubbed... Name: syn.patch Type: text/x-diff Size: 484 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090519/6f5126d8/syn.bin From qing.li at bluecoat.com Wed May 20 01:10:16 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Wed May 20 01:10:22 2009 Subject: arp fails to clear mapping for deleted network In-Reply-To: <4A111FDC.5030400@gmx.com> References: <4A111FDC.5030400@gmx.com> Message-ID: Please apply the patch at "http://people.freebsd.org/~qingli/patch" and that should fix your problem. I found another issue while testing the patch. I am working on it and hope to have a fix soon. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Nikos Vassiliadis > Sent: Monday, May 18, 2009 1:44 AM > To: freebsd-net@freebsd.org > Subject: arp fails to clear mapping for deleted network > > Hello, > > It seems that: > 1) if I assign an IP address to an interface > 2) get an arp mapping via this interface > 3) remove the IP address from the interface > > arp fails to remove this arp entry when > arp -d is used > > > lab# ifconfig rl0 192.168.254.30 > > lab# ping 192.168.254.254 > > PING 192.168.254.254 (192.168.254.254): 56 data bytes > > 64 bytes from 192.168.254.254: icmp_seq=0 ttl=64 time=0.427 ms > > 64 bytes from 192.168.254.254: icmp_seq=1 ttl=64 time=0.434 ms > > 64 bytes from 192.168.254.254: icmp_seq=2 ttl=64 time=0.442 ms > > 64 bytes from 192.168.254.254: icmp_seq=3 ttl=64 time=0.467 ms > > 64 bytes from 192.168.254.254: icmp_seq=4 ttl=64 time=0.445 ms > > ^C > > --- 192.168.254.254 ping statistics --- > > 5 packets transmitted, 5 packets received, 0.0% packet loss > > round-trip min/avg/max/stddev = 0.427/0.443/0.467/0.014 ms > > lab# arp 192.168.254.254 > > ? (192.168.254.254) at 00:18:d1:e4:ee:29 on rl0 [ethernet] > > lab# ifconfig rl0 delete > > lab# arp 192.168.254.254 > > ? (192.168.254.254) at 00:18:d1:e4:ee:29 on rl0 [ethernet] > > lab# arp -d 192.168.254.254 > > arp: writing to routing socket: No such process > > arp: 192.168.254.254: No such process > > lab# arp 192.168.254.254 > > ? (192.168.254.254) at 00:18:d1:e4:ee:29 on rl0 [ethernet] > > lab# > > This is from a few days old -current. I just noticed > this somehow strange behavior, but I don't really know > if it's old or new. > > Nikos > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From dfilter at FreeBSD.ORG Wed May 20 02:50:05 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Wed May 20 02:50:11 2009 Subject: kern/134220: commit references a PR Message-ID: <200905200250.n4K2o5rA048125@freefall.freebsd.org> The following reply was made to PR kern/134220; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/134220: commit references a PR Date: Wed, 20 May 2009 02:49:09 +0000 (UTC) Author: mav Date: Wed May 20 02:48:53 2009 New Revision: 192415 URL: http://svn.freebsd.org/changeset/base/192415 Log: MFC rev. 192032 Fix copy-paste bug in NGM_NETFLOW_SETCONFIG argument size verification. PR: kern/134220 Submitted by: Eugene Mychlo Modified: stable/7/sys/ (props changed) stable/7/sys/contrib/pf/ (props changed) stable/7/sys/dev/ath/ath_hal/ (props changed) stable/7/sys/dev/cxgb/ (props changed) stable/7/sys/netgraph/netflow/ng_netflow.c Modified: stable/7/sys/netgraph/netflow/ng_netflow.c ============================================================================== --- stable/7/sys/netgraph/netflow/ng_netflow.c Wed May 20 02:24:09 2009 (r192414) +++ stable/7/sys/netgraph/netflow/ng_netflow.c Wed May 20 02:48:53 2009 (r192415) @@ -422,7 +422,7 @@ ng_netflow_rcvmsg (node_p node, item_p i { struct ng_netflow_setconfig *set; - if (msg->header.arglen != sizeof(struct ng_netflow_settimeouts)) + if (msg->header.arglen != sizeof(struct ng_netflow_setconfig)) ERROUT(EINVAL); set = (struct ng_netflow_setconfig *)msg->data; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From mav at FreeBSD.org Wed May 20 02:57:06 2009 From: mav at FreeBSD.org (mav@FreeBSD.org) Date: Wed May 20 02:57:13 2009 Subject: kern/134220: [ng_netflow] [patch]: incorrect comparison in ng_netflow_rcvmsg() Message-ID: <200905200257.n4K2v5bc060932@freefall.freebsd.org> Synopsis: [ng_netflow] [patch]: incorrect comparison in ng_netflow_rcvmsg() State-Changed-From-To: patched->closed State-Changed-By: mav State-Changed-When: Wed May 20 02:56:31 UTC 2009 State-Changed-Why: Patch merged to 7-STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=134220 From nvass9573 at gmx.com Wed May 20 12:23:49 2009 From: nvass9573 at gmx.com (Nikos Vassiliadis) Date: Wed May 20 12:23:56 2009 Subject: arp fails to clear mapping for deleted network In-Reply-To: References: <4A111FDC.5030400@gmx.com> Message-ID: <4A13F63D.5000800@gmx.com> Li, Qing wrote: > Please apply the patch at "http://people.freebsd.org/~qingli/patch" and > that should fix your problem. Yes, your patch fixes the problem. > I found another issue while testing the patch. I am working on it and > hope to have a fix soon. While you're at it and if it's not too much to ask, could you also check proxy-arp? For example: arp -s 192.168.254.250 auto pub > 15:16:56.497270 08:00:27:49:d9:5e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.254.250 tell 192.168.254.250, length 28 But, when a request for 192.168.254.250 comes in, it doesn't reply > 15:17:04.902291 00:18:d1:e4:ee:29 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.254.250 tell 192.168.254.254, length 46 Thanks, Nikos From qing.li at bluecoat.com Wed May 20 16:52:01 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Wed May 20 16:52:08 2009 Subject: arp fails to clear mapping for deleted network In-Reply-To: <4A13F63D.5000800@gmx.com> References: <4A111FDC.5030400@gmx.com> <4A13F63D.5000800@gmx.com> Message-ID: > > Yes, your patch fixes the problem. > Okay, I will commit the patch. > > While you're at it and if it's not too much to ask, could you > also check proxy-arp? > Could you please email me your netstat output, privately ? Thanks, -- Qing > For example: > arp -s 192.168.254.250 auto pub > > 15:16:56.497270 08:00:27:49:d9:5e > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 42: Request who-has 192.168.254.250 tell > 192.168.254.250, length 28 > But, when a request for 192.168.254.250 comes in, it doesn't > reply > > 15:17:04.902291 00:18:d1:e4:ee:29 > ff:ff:ff:ff:ff:ff, ethertype ARP > (0x0806), length 60: Request who-has 192.168.254.250 tell > 192.168.254.254, length 46 > > Thanks, Nikos From ajadav at gmail.com Wed May 20 19:55:38 2009 From: ajadav at gmail.com (Asheesh Jadav) Date: Wed May 20 19:55:44 2009 Subject: Deleting a TAP interface Message-ID: Hi, I'm able to create the TAP interface, lets say with name 'test', and bring it up, but when I try deleting it using ioctl(fd, TUNSETPERSIST, 0) I can see that on my system I still have an interafce with name eth0 (the original name was test). How can I completely delete the interface that I created and restore the system to the state it was before I created the TAP interface? Thanks. From bms at incunabulum.net Wed May 20 23:37:06 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed May 20 23:37:13 2009 Subject: Deleting a TAP interface In-Reply-To: References: Message-ID: <4A14941F.3090402@incunabulum.net> Asheesh Jadav wrote: > Hi, > > I'm able to create the TAP interface, lets say with name 'test', and bring > it up, but when I try deleting it using > > ioctl(fd, TUNSETPERSIST, 0) > It sounds from your interface name as though you are using a Linux system, and I can't find this ioctl documented anywhere on FreeBSD: %%% tack:/usr/src/sys/net % grep -Hr TUNSETPERSIST . Exit 1 tack:/usr/src/sys/compat % grep -Hr TUNSETPERSIST . Exit 1 %%% Perhaps try a Linux development forum who will be better able to assist you? In FreeBSD, tap/tun interfaces are cloners, and can be created/destroyed using the usual cloneable interface mechanisms. thanks, BMS From davidch at broadcom.com Thu May 21 01:00:11 2009 From: davidch at broadcom.com (David Christensen) Date: Thu May 21 01:00:17 2009 Subject: kern/134658: [bce] bce driver fails on PowerEdge m610 blade. Message-ID: <200905210100.n4L10A1E098372@freefall.freebsd.org> The following reply was made to PR kern/134658; it has been noted by GNATS. From: "David Christensen" To: "bug-followup@FreeBSD.org" , "harald_jensas@dell.com" Cc: Subject: Re: kern/134658: [bce] bce driver fails on PowerEdge m610 blade. Date: Wed, 20 May 2009 17:38:48 -0700 This is the expected behavior as the mii(4) SerDes support=20 for the 5709 was removed from immediately prior to the 7.2=20 release. The PHY's ID is not present in miidevs.c. Dave= From gnn at neville-neil.com Thu May 21 14:51:17 2009 From: gnn at neville-neil.com (George Neville-Neil) Date: Thu May 21 14:51:23 2009 Subject: [PATCH] SYN issue In-Reply-To: <20090519211346.GC675@isilon.com> References: <20090519211346.GC675@isilon.com> Message-ID: <43B043BD-4D7B-414B-91AB-3C8DBA0EC078@neville-neil.com> On May 19, 2009, at 17:13 , Zachary Loafman wrote: > net@ - > > A short patch attached that requires 3 paragraphs of explanation. > > We found an issue in TCP when the a client connects to our server, > establishes a connection, reboots and chooses the same source port to > re-establish the connection. This isn't hard from other vendors' > clients. On Solaris, the same NFS mount order at boot time will > frequently result in source port re-use for the NFS connections. In > this case, the customer was seeing mounts hang until the keepalive on > our side would kick the established connection. > > The problem in the code is probably best explained using the patch > itself: > > --- > Index: sys/netinet/tcp_input.c > =================================================================== > --- sys/netinet/tcp_input.c (revision xxxx) > +++ sys/netinet/tcp_input.c (working copy) > @@ -1818,7 +1818,11 @@ tcp_do_segment(struct mbuf *m, struct tc > > todrop = tp->rcv_nxt - th->th_seq; > if (todrop > 0) { > - if (thflags & TH_SYN) { > + /* > + * If this is a duplicate SYN for our current > connection, > + * advance over it and pretend and it's not a SYN. > + */ > + if (thflags & TH_SYN && th->th_seq == tp->irs) { > thflags &= ~TH_SYN; > th->th_seq++; > if (th->th_urp > 1) > --- > > The problem is that when our TCP stack gets a SYN packet for a > connection that's already in ESTABLISHED state, it runs through the > above code. The above code is basically noticing that the packet is > coming in left of the receive window and then saying "Ah, a SYN! This > must be a duplicate SYN for our existing connect." After that, it just > turns off SYN and treats it as a normal packet (after advancing past > the SYN seq number). The code is broken, though: the only condition > under which this is a duplicate SYN is if the th_seq matches the irs, > the initial receive sequence. > > After correcting the above, any SYN that doesn't exactly match the > initial sequence number results in a RST|ACK response and the > ESTABLISHED connection being dropped. Before this change, this is also > what happened if a SYN arrived within or past the window, so I'm > basically making the before-window behavior match the other > behavior. I tested this using telnet to establish a TCP connection and > raw packet injection to throw SYNs at it. > > Comments? > Yes, nice catch. Best, George From fox at verio.net Thu May 21 17:37:29 2009 From: fox at verio.net (David DeSimone) Date: Thu May 21 17:37:35 2009 Subject: [PATCH] SYN issue In-Reply-To: <20090519211346.GC675@isilon.com> References: <20090519211346.GC675@isilon.com> Message-ID: <20090521173725.GB3992@verio.net> Zachary Loafman wrote: > > After correcting the above, any SYN that doesn't exactly match > the initial sequence number results in a RST|ACK response and the > ESTABLISHED connection being dropped. Maybe I am jumping to conclusions here, but does this mean that someone can spoof a SYN from your IP and source port and force your connection to be torn down? -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From rpaulo at freebsd.org Fri May 22 00:08:05 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Fri May 22 00:08:37 2009 Subject: [PATCH] SYN issue In-Reply-To: <20090521173725.GB3992@verio.net> References: <20090519211346.GC675@isilon.com> <20090521173725.GB3992@verio.net> Message-ID: <7B86B602-BE19-4AD7-9B70-CCC3BFC933A8@freebsd.org> On 21 May 2009, at 18:37, David DeSimone wrote: > Zachary Loafman wrote: >> >> After correcting the above, any SYN that doesn't exactly match >> the initial sequence number results in a RST|ACK response and the >> ESTABLISHED connection being dropped. > > Maybe I am jumping to conclusions here, but does this mean that > someone > can spoof a SYN from your IP and source port and force your connection > to be torn down? I don't think so. First of all the seq must be on the left of the recv window, and second, we already do this for the right of the recv window. I believe this is how the standard defined it to be. -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090522/17e0013d/PGP.pgp From gavin at FreeBSD.org Fri May 22 20:41:26 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Fri May 22 20:41:33 2009 Subject: amd64/134788: [bce] failure to set ip address in amd64 if_bce.c, i386 seems OK Message-ID: <200905222041.n4MKfQii049397@freefall.freebsd.org> Old Synopsis: failure to set ip address in amd64 if_bce.c, i386 seems OK New Synopsis: [bce] failure to set ip address in amd64 if_bce.c, i386 seems OK Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Fri May 22 20:40:10 UTC 2009 Responsible-Changed-Why: I'm guessing this is a bug in bce(4) rather than in the amd-specific code http://www.freebsd.org/cgi/query-pr.cgi?pr=134788 From bzeeb-lists at lists.zabbadoz.net Fri May 22 23:20:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri May 22 23:20:13 2009 Subject: Routing related crash in -CURRENT, introduced between 5th May and yesterday In-Reply-To: <4A1057D2.5090800@fsn.hu> References: <4A1057D2.5090800@fsn.hu> Message-ID: <20090522231449.K72053@maildrop.int.zabbadoz.net> On Sun, 17 May 2009, Attila Nagy wrote: Hi, > Somewhere between 5th May and yesterday there was a (routing related?) > change, which causes this machine crash at boot: SVN r192612 [1] ishould fix the problems. Let us know if it does not. /bz [1] http://svn.freebsd.org/viewvc/base?view=revision&revision=192612 -- Bjoern A. Zeeb The greatest risk is not taking one. From rpaulo at FreeBSD.org Sun May 24 11:51:28 2009 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Sun May 24 11:52:00 2009 Subject: Wireless mesh networking Message-ID: Hi, If anyone is interested in testing out wireless mesh networking under FreeBSD, the project has now reached a point where you can transfer packets between mesh nodes. I try to keep the branch in sync with head (sometimes more than) weekly. The branch is located at the FreeBSD svn repo and everyone can fetch it: $ svn co http://svn.freebsd.org/viewvc/base/projects/mesh11s/ To actually try out mesh networking you need ath(4) because ral(4) has problems right now. After building and installing a new world and kernel, you need to do this: # ifconfig wlan0 create wlandev ath0 wlanmode mesh channel 1 meshid mymesh # ifconfig wlan0 inet w.x.y.z/q up Channel discovery for mesh networks is not yet implemented, hence you need to manually specify the channel on which the mesh is running (all nodes must be on the same channel and same meshid, just like regular AP operation). If you can't ping other mesh node, try putting one ath(4) interface in promisc mode (I'm still investigating this problem). This project is being sponsored by The FreeBSD Foundation (http://www.freebsdfoundation.org/). Thanks, -- Rui Paulo From ivo.vachkov at gmail.com Mon May 25 08:36:37 2009 From: ivo.vachkov at gmail.com (Ivo Vachkov) Date: Mon May 25 08:36:43 2009 Subject: Wireless mesh networking In-Reply-To: References: Message-ID: Hello, Great project! But could you please elaborate on technologies being used in it? Thank you very much in advance. On Sun, May 24, 2009 at 2:51 PM, Rui Paulo wrote: > Hi, > If anyone is interested in testing out wireless mesh networking under > FreeBSD, the project has now reached a point where you can transfer > packets between mesh nodes. > I try to keep the branch in sync with head (sometimes more than) > weekly. The branch is located at the FreeBSD svn repo and everyone can > fetch it: > > $ svn co http://svn.freebsd.org/viewvc/base/projects/mesh11s/ > > To actually try out mesh networking you need ath(4) because ral(4) has > problems right now. > > After building and installing a new world and kernel, you need to do this: > # ifconfig wlan0 create wlandev ath0 wlanmode mesh channel 1 meshid mymesh > # ifconfig wlan0 inet w.x.y.z/q up > > Channel discovery for mesh networks is not yet implemented, hence you > need to manually specify the channel on which the mesh is running (all > nodes must be on the same channel and same meshid, just like regular > AP operation). > > If you can't ping other mesh node, try putting one ath(4) interface in > promisc mode (I'm still investigating this problem). > > This project is being sponsored by The FreeBSD Foundation > (http://www.freebsdfoundation.org/). > > Thanks, > -- > Rui Paulo > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From rpaulo at freebsd.org Mon May 25 10:34:03 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Mon May 25 10:34:36 2009 Subject: Wireless mesh networking In-Reply-To: References: Message-ID: <6EAE19E7-DE10-48E4-869C-241776FC89EE@freebsd.org> Hi, On 25 May 2009, at 09:07, Ivo Vachkov wrote: > Hello, > > Great project! But could you please elaborate on technologies being > used in it? Here's some background: http://en.wikipedia.org/wiki/IEEE_802.11s http://en.wikipedia.org/wiki/Wireless_mesh_network http://www.cs.wustl.edu/~jain/cse574-06/ftp/j_jmesh/sld015.htm Regards, -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090525/b927a1d9/PGP.pgp From bugmaster at FreeBSD.org Mon May 25 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 25 11:08:57 2009 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200905251106.n4PB6vJF092893@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o amd64/134788 net [bce] failure to set ip address in amd64 if_bce.c, i38 o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134557 net [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem o kern/132984 net [netgraph] swi1: net 100% cpu usage f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132715 net [lagg] [panic] Panic when creating vlan's on lagg inte o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132625 net [iwn] iwn drivers don't support setting country o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87194 net [fxp] fxp(4) promiscuous mode seems to corrupt hw-csum s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 305 problems total. From linimon at FreeBSD.org Mon May 25 13:26:43 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon May 25 13:26:50 2009 Subject: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib Message-ID: <200905251326.n4PDQglK003602@freefall.freebsd.org> Synopsis: [route] [fib] Route messages sent to all socket listeners regardless of setfib Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 25 13:26:31 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134931 From swun2010 at gmail.com Mon May 25 14:16:57 2009 From: swun2010 at gmail.com (Sam Wun) Date: Mon May 25 14:17:03 2009 Subject: Can't start mysql in jail Message-ID: <736c47cb0905250716y6208e10ax3a6e325c1c96dfd1@mail.gmail.com> Hi, This seems a common question, but it is a bit different. Production OS: FreeBSD 6.2 Source OS: FreeBSD 7.2 I created a jailed mysql 5.1 in my source OS FreeBSD 7.2, and then tar it up and scp into a production OS FreeBSD 6.2. After setup a jail in 6.2 for the jailed mysql, I tried to start up mysql server, but it failed with very lilttle error message. The error log just said, " 090525 20:18:26 mysqld_safe Starting mysqld daemon with databases from /usr/local/var/db/mysql 090525 20:18:26 mysqld_safe mysqld from pid file /usr/local/var/db/mysql/wp1.xxx.au.pid ended .. " What is the problem with Freebsd 6.2 running 7.2 jailed files? Is there anyone to fix this problem? Your help is very appreciated. Thanks From wangfangcs at gmail.com Mon May 25 16:19:30 2009 From: wangfangcs at gmail.com (Fang Wang) Date: Mon May 25 16:19:39 2009 Subject: Problems in implementation TCP UTO described in RFC 5482 Message-ID: Hi! RFC 5482 specifies a new TCP option -- the TCP User Timeout Option (UTO) -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the connection to adapt its user timeout accordingly. That means the user timeout which is fixed currently can be changed. For more details about UTO, please read RFC 5482. The current user timeout is fact controled by retransmission times and intervals in TCP stack, that's 1+2+4+8+16+32+64+64+64+64+64+64+64=511 seconds and 12 retransmissions in total. After the last retransmission, it waits for another 64 seconds. Assume that a program set a 150 seconds user timeout, and of course we use exponential backoff, so first six intervals is 1,2,4,8,16,32,64 seconds and the last interval is 23 seconds. Here is the problem, after the last retransmission, we only waits for 23 seconds, that's not exponential backoff. And what if the last interval is 1 second, that means the last retransmission is useless. One alternative solution is reduce a retransmission and adjust the former intervals, for example 1,2,4,8,16,32,65. Or just leave it alone. But I think there may be some better ideas. Regards, Fang Wang From 000.fbsd at quip.cz Mon May 25 17:27:49 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Mon May 25 17:27:56 2009 Subject: Can't start mysql in jail In-Reply-To: <736c47cb0905250716y6208e10ax3a6e325c1c96dfd1@mail.gmail.com> References: <736c47cb0905250716y6208e10ax3a6e325c1c96dfd1@mail.gmail.com> Message-ID: <4A1AD154.9070102@quip.cz> Sam Wun wrote: > Hi, > > This seems a common question, but it is a bit different. > Production OS: FreeBSD 6.2 > Source OS: FreeBSD 7.2 > > I created a jailed mysql 5.1 in my source OS FreeBSD 7.2, and then tar > it up and scp into a production OS FreeBSD 6.2. > After setup a jail in 6.2 for the jailed mysql, I tried to start up > mysql server, but it failed with very lilttle error message. > The error log just said, > " > 090525 20:18:26 mysqld_safe Starting mysqld daemon with databases from > /usr/local/var/db/mysql > 090525 20:18:26 mysqld_safe mysqld from pid file > /usr/local/var/db/mysql/wp1.xxx.au.pid ended > .. > " > > What is the problem with Freebsd 6.2 running 7.2 jailed files? > Is there anyone to fix this problem? It is problem with versions of linked libraries" on FreeBSD 7.2 ~/> ldd /usr/local/libexec/mysqld /usr/local/libexec/mysqld: librt.so.1 => /usr/lib/librt.so.1 (0x800ad0000) libz.so.4 => /lib/libz.so.4 (0x800bd5000) libwrap.so.5 => /usr/lib/libwrap.so.5 (0x800ce9000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x800df2000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x800f0b000) libm.so.5 => /lib/libm.so.5 (0x801117000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801231000) libthr.so.3 => /lib/libthr.so.3 (0x80133e000) libc.so.7 => /lib/libc.so.7 (0x801454000) on FreeBSD 6.3 ~/> ldd /usr/local/libexec/mysqld /usr/local/libexec/mysqld: libz.so.3 => /lib/libz.so.3 (0x28478000) libwrap.so.4 => /usr/lib/libwrap.so.4 (0x28489000) libcrypt.so.3 => /lib/libcrypt.so.3 (0x28490000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x284a8000) libm.so.4 => /lib/libm.so.4 (0x28573000) libpthread.so.2 => /usr/lib/libthr.so.2 (0x28589000) libc.so.6 => /lib/libc.so.6 (0x2859b000) As you can see, there is different libc.so version, different threading library, etc. So you can't run MySQL daemon build on different major version OS. Miroslav Lachman From to.my.trociny at gmail.com Mon May 25 19:29:30 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Mon May 25 19:29:37 2009 Subject: panic with ng_ipfw+ng_car and net.inet.ip.fw.one_pass=0 Message-ID: <864ov9htgq.fsf@kopusha.onet> Hi, Some times ago it has been posted to fido7.ru.unix.bsd about panics when using ipfw + ng_ipfw + ng_car. http://groups.google.com/group/fido7.ru.unix.bsd/browse_thread/thread/5907d1ba4e76675d For those who haven't learnt Russian yet ;-) here are some details. Max Irgiznov reported that when ng_ipf+ng_car construction was used and net.inet.ip.fw.one_pass=0 was set, the system reliably panicked on ipfw rules reload if there was some traffic through ng_car. The problem here is in the following. When the packet is returning back from ng_car queue to ipfw_chk and one_pass is turned off the next rule is being tried. But if the rules were reloaded while the packet was sitting in ng_car, the next rule pointer might be dangling and the kernel will panic. (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e1f7e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e2252 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0495eb7 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:446 #4 0xc04968bc in db_command (last_cmdp=0xc0c97514, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413 #5 0xc04969ca in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 #6 0xc04981bd in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:228 #7 0xc080ec76 in kdb_trap (type=12, code=0, tf=0xe6945774) at /usr/src/sys/kern/subr_kdb.c:524 #8 0xc0ad9e4f in trap_fatal (frame=0xe6945774, eva=3735929068) at /usr/src/sys/i386/i386/trap.c:930 #9 0xc0ada790 in trap (frame=0xe6945774) at /usr/src/sys/i386/i386/trap.c:320 #10 0xc0abeaab in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #11 0xc903328c in ipfw_chk (args=0xe6945acc) at /usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2516 #12 0xc90373f7 in ipfw_check_in (arg=0x0, m0=0xe6945bd0, ifp=0xc41f9000, dir=1, inp=0x0) at /usr/src/sys/modules/ipfw/../../netinet/ip_fw_pfil.c:125 #13 0xc088d6e8 in pfil_run_hooks (ph=0xc0d1f620, mp=0xe6945c24, ifp=0xc41f9000, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:78 #14 0xc08c766d in ip_input (m=0xc409ad00) at /usr/src/sys/netinet/ip_input.c:416 #15 0xc9011c39 in ng_ipfw_rcvdata (hook=0xc61a1780, item=0xc8fe5090) at /usr/src/sys/modules/netgraph/ipfw/../../../netgraph/ng_ipfw.c:250 #16 0xc68b80af in ng_apply_item (node=0xc7054c00, item=0xc8fe5090, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2336 #17 0xc68b939f in ngthread (arg=0x0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3304 #18 0xc07be4c8 in fork_exit (callout=0xc68b91f0 , arg=0x0, frame=0xe6945d38) at /usr/src/sys/kern/kern_fork.c:810 #19 0xc0abeb20 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 (kgdb) frame 11 #11 0xc903328c in ipfw_chk (args=0xe6945acc) at /usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2516 warning: Source file is more recent than executable. 2516 if (set_disable & (1 << f->set) ) (kgdb) list 2511 ipfw_insn *cmd; 2512 uint32_t tablearg = 0; 2513 int l, cmdlen, skip_or; /* skip rest of OR block */ 2514 2515 again: 2516 if (set_disable & (1 << f->set) ) 2517 continue; 2518 2519 skip_or = 0; 2520 for (l = f->cmd_len, cmd = f->cmd ; l > 0 ; (kgdb) p f $1 = (struct ip_fw *) 0xdeadc0de (kgdb) DUMMYNET does not have such problems as ip_dn_ruledel_ptr(rule) is called when the rule is removed in reap_rules(). The first thought was to do the same here i.e. to broadcast "remove the rule" message to netgraph nodes, but glancing through the netgraph man I haven't figured out how it could be done if it is possible at all. So the other solution is to have some counter that increases every time when any rules are removed. When the packet is directed by ipfw to netgraph subsystem, the current value of the counter is stored in mtag. When the packet is coming back the current value of the counter is compared with one from the mtag and if they differ the packet is dropped. Just to prove the concept I have modified ip_fw2.c for 7.2-STABLE accordingly and it works for me. The patch is attached. I would like to hear other people opinion, first of all if the proposed idea is good enough or there might be other better solutions for the problem (e.g. "remove the rule" broadcasting is possible). But also if somebody have any remarks about the patch itself I would happy to see them. E.g. I have added the counter just as static variable but as for me struct ip_fw_chain could be better place for this. Also is there any need to mark the tag with MTAG_PERSISTENT bit? -- Mikolaj Golub -------------- next part -------------- A non-text attachment was scrubbed... Name: ip_fw2.c.patch Type: text/x-diff Size: 1952 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090525/46293d3b/ip_fw2.c.bin From Jinmei_Tatuya at isc.org Mon May 25 23:24:04 2009 From: Jinmei_Tatuya at isc.org (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Mon May 25 23:24:11 2009 Subject: IPv6 fragmentation weirdness In-Reply-To: <20090514214235.B09701CC12@ptavv.es.net> References: <20090514214235.B09701CC12@ptavv.es.net> Message-ID: At Thu, 14 May 2009 14:42:35 -0700, "Kevin Oberman" wrote: > I then captured the ICMP and discovered that the kernel was fragmenting > all of them! Worse, the fragment was sent out before the ICMP! What the > heck is going on! Thread synchronization? > > When I captured the packets (via tcpdump -s0 -w file host ftp.funet.fi), the > first things captured is an IPv6 fragment of 72 bytes. 3 microseconds > later, I get the ICMP6 packet of 1294 bytes. This pattern is consistent > over repeated packets. This was with -s 1234 for a total ICMPv6 size of > 1282. > > First, why is the kernel fragmenting this at all as it fits in the > interface MTU? Do you mean why ping6 has the kernel fragment echo requests at 1280 bytes by default (i.e., when invoked without -m)? If so, that's because if a large echo request triggers path MTU discovery, some initial requests won't be replied (recall that IPv6 routers never fragment packets by themselves; they always drop too-large packet with returning an ICMPv6 error). > Second, why the heck is the fragment going out first? This should be OK, > but I suspect many firewalls (which are often not happy with fragments) > are not likely to pass a fragment which precedes the initial frame. Do you mean, for example, the kernel sends out a fragment with a non-0 offset before the 0-offset one? I can't believe this. If I tried % ping6 -s 1300 www.isc.org from a FreeBSD 6.3 host, I saw this: 08:22:04.821171 IP6 2001:200:0:8002:203:47ff:fea5:3085 > 2001:4f8:0:2::d: frag (0|1232) ICMP6, echo request, seq 0, length 1232 08:22:04.821181 IP6 2001:200:0:8002:203:47ff:fea5:3085 > 2001:4f8:0:2::d: frag (1232|76) (captured on the sending host). --- JINMEI, Tatuya Internet Systems Consortium, Inc. From alfred at freebsd.org Tue May 26 02:53:15 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue May 26 02:53:21 2009 Subject: Can't start mysql in jail In-Reply-To: <4A1AD154.9070102@quip.cz> References: <736c47cb0905250716y6208e10ax3a6e325c1c96dfd1@mail.gmail.com> <4A1AD154.9070102@quip.cz> Message-ID: <20090526023618.GF67847@elvis.mu.org> * Miroslav Lachman <000.fbsd@quip.cz> [090525 10:27] wrote: > Sam Wun wrote: > >Hi, > > > >This seems a common question, but it is a bit different. > >Production OS: FreeBSD 6.2 > >Source OS: FreeBSD 7.2 > > > >I created a jailed mysql 5.1 in my source OS FreeBSD 7.2, and then tar > > As you can see, there is different libc.so version, different threading > library, etc. > > So you can't run MySQL daemon build on different major version OS. You should be able to provided that you install the compat libraries. You may also need to use the libmap.conf facility to fixup threading library to point to libthr but I am unsure. -Alfred From smithi at nimnet.asn.au Tue May 26 10:06:28 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue May 26 10:06:36 2009 Subject: Wireless mesh networking In-Reply-To: References: Message-ID: <20090526192342.P55023@sola.nimnet.asn.au> On Sun, 24 May 2009, Rui Paulo wrote: > Hi, > If anyone is interested in testing out wireless mesh networking under > FreeBSD, the project has now reached a point where you can transfer > packets between mesh nodes. Always a good point to celebrate :) > I try to keep the branch in sync with head (sometimes more than) > weekly. The branch is located at the FreeBSD svn repo and everyone can > fetch it: > > $ svn co http://svn.freebsd.org/viewvc/base/projects/mesh11s/ Not that I could run it now or even soon, but I'm interested in having a look at the code, mostly to try figuring out the scope of what layers this is working at, and noting that this is my first ever attempted use of svn (and if it matters, on a 5.5-S box): sola% mkdir 802.11s sola% cd 802.11s/ sola% svn co http://svn.freebsd.org/viewvc/base/projects/mesh11s/ svn: PROPFIND request failed on '/viewvc/base/projects/mesh11s' svn: PROPFIND of '/viewvc/base/projects/mesh11s': 301 Moved (http://svn.freebsd.org) Where to from here? Might there be an old-fashioned tarball? > To actually try out mesh networking you need ath(4) because ral(4) has > problems right now. > > After building and installing a new world and kernel, you need to do this: > # ifconfig wlan0 create wlandev ath0 wlanmode mesh channel 1 meshid mymesh > # ifconfig wlan0 inet w.x.y.z/q up > > Channel discovery for mesh networks is not yet implemented, hence you > need to manually specify the channel on which the mesh is running (all > nodes must be on the same channel and same meshid, just like regular > AP operation). Not more like regular ad-hoc operation? Pardon my ignorance. I've followed your later wikipedia links and many others from there, but still haven't got much of an overview. I'm a little familiar with how OLSR works, and got some meaty clues reading about the OLPC XO-1 use of their subset of 11s, but that's it so far. cheers, Ian > If you can't ping other mesh node, try putting one ath(4) interface in > promisc mode (I'm still investigating this problem). > > This project is being sponsored by The FreeBSD Foundation > (http://www.freebsdfoundation.org/). > > Thanks, > -- > Rui Paulo From adamk at voicenet.com Tue May 26 12:00:05 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Tue May 26 12:00:12 2009 Subject: kern/131153: [iwi] iwi doesn't see a wireless network Message-ID: <200905261200.n4QC04MU024592@freefall.freebsd.org> The following reply was made to PR kern/131153; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-followup@FreeBSD.org, adamk@voicenet.com Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network Date: Tue, 26 May 2009 07:58:33 -0400 Since I finally had the chance to try -CURRENT, without my development work on this laptop, I decided to give it a shot this past weekend. I am now running: FreeBSD scroll.ashke.com 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Sat May 23 23:11:53 EDT 2009 root@scroll.ashke.com:/usr/obj/usr/src/sys/GENERIC i386 Unfortunately, this has made no difference. I have tried with both iwi and ath. They were both cloned to wlan0 (at different times, obviously). wpa_supplicant still does not see this network. I ran 'wpa_supplicant -Dbsd -iwlan0 -c/etc/wpa_supplicant.conf -dd' each for each driver. With iwi: ioctl[SIOCS80211, op 26, arg 0x0]: Operation not supported Initializing interface 'wlan0' conf '/etc/wpa_supplicant.conf' driver 'bsd' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' Line: 2 - start of a new network block scan_ssid=0 (0x0) ssid - hexdump_ascii(len=15): 4d 63 6b 65 6c 6c 61 32 38 30 46 72 6f 6e 74 Mckella280Front key_mgmt: 0x2 pairwise: 0x8 PSK (ASCII passphrase) - hexdump_ascii(len=10): [REMOVED] PSK (from passphrase) - hexdump(len=32): [REMOVED] Line 8: removed CCMP from group cipher list since it was not allowed for pairwise cipher Line: 10 - start of a new network block ssid - hexdump_ascii(len=5): 61 73 68 6b 65 ashke key_mgmt: 0x4 wep_key0 - hexdump(len=13): [REMOVED] wep_tx_keyidx=0 (0x0) Line: 19 - start of a new network block key_mgmt: 0x4 Priority group 0 id=0 ssid='Mckella280Front' id=1 ssid='ashke' id=2 ssid='' Initializing interface (2) 'wlan0' Own MAC address: 00:13:ce:a8:10:ea wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 RSN: flushing PMKID list in the driver Setting scan request: 0 sec 100000 usec EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED Added interface wlan0 State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (0 BSSes) Scan results: 0 Cached scan results are empty - not posting Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) EAPOL: disable timer tick Received 0 bytes of scan results (0 BSSes) Scan results: 0 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 5 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (0 BSSes) Scan results: 0 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 5 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (0 BSSes) Scan results: 0 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 5 sec 0 usec Starting AP scan (broadcast SSID) CTRL-EVENT-TERMINATING - signal 2 received Removing interface wlan0 State: SCANNING -> DISCONNECTED No keys have been configured - skip key clearing EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 wpa_driver_bsd_set_wpa: enabled=0 wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=0 Failed to disable WPA in the driver. wpa_driver_bsd_set_drop_unencrypted: enabled=0 wpa_driver_bsd_set_countermeasures: enabled=0 No keys have been configured - skip key clearing Cancelling scan request Cancelling authentication timeout wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=0 ELOOP: remaining socket: sock=4 eloop_data=0x34006140 user_data=0x3400e040 handler=0x8069f50 And with ath: ioctl[SIOCS80211, op 26, arg 0x0]: Operation not supported Initializing interface 'wlan0' conf '/etc/wpa_supplicant.conf' driver 'bsd' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' Line: 2 - start of a new network block scan_ssid=0 (0x0) ssid - hexdump_ascii(len=15): 4d 63 6b 65 6c 6c 61 32 38 30 46 72 6f 6e 74 Mckella280Front key_mgmt: 0x2 pairwise: 0x8 PSK (ASCII passphrase) - hexdump_ascii(len=10): [REMOVED] PSK (from passphrase) - hexdump(len=32): [REMOVED] Line 8: removed CCMP from group cipher list since it was not allowed for pairwise cipher Line: 10 - start of a new network block ssid - hexdump_ascii(len=5): 61 73 68 6b 65 ashke key_mgmt: 0x4 wep_key0 - hexdump(len=13): [REMOVED] wep_tx_keyidx=0 (0x0) Line: 19 - start of a new network block key_mgmt: 0x4 Priority group 0 id=0 ssid='Mckella280Front' id=1 ssid='ashke' id=2 ssid='' Initializing interface (2) 'wlan0' Own MAC address: 00:12:17:63:2d:a9 wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 RSN: flushing PMKID list in the driver Setting scan request: 0 sec 100000 usec EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED Added interface wlan0 State: DISCONNECTED -> SCANNING Starting AP scan (broadcast SSID) Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (0 BSSes) Scan results: 0 Cached scan results are empty - not posting Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) EAPOL: disable timer tick Received 0 bytes of scan results (0 BSSes) Scan results: 0 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 5 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (0 BSSes) Scan results: 0 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 5 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (0 BSSes) Scan results: 0 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 5 sec 0 usec CTRL-EVENT-TERMINATING - signal 2 received Removing interface wlan0 State: SCANNING -> DISCONNECTED No keys have been configured - skip key clearing EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 wpa_driver_bsd_set_wpa: enabled=0 wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=0 Failed to disable WPA in the driver. wpa_driver_bsd_set_drop_unencrypted: enabled=0 wpa_driver_bsd_set_countermeasures: enabled=0 No keys have been configured - skip key clearing Cancelling scan request Cancelling authentication timeout wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=0 ELOOP: remaining socket: sock=4 eloop_data=0x34006140 user_data=0x3400e040 handler=0x8069f50 Is there anything else I can test? From bms at incunabulum.net Tue May 26 12:40:30 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue May 26 12:40:38 2009 Subject: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib In-Reply-To: <200905251326.n4PDQglK003602@freefall.freebsd.org> References: <200905251326.n4PDQglK003602@freefall.freebsd.org> Message-ID: <4A1BE33B.7010106@incunabulum.net> linimon@FreeBSD.org wrote: > Synopsis: [route] [fib] Route messages sent to all socket listeners regardless of setfib > That might actually be a feature, however, the "API contract" with the multiple routing table support might not have covered this, so it might be "undefined behaviour". From freebsd-net at blacquiere.nl Tue May 26 12:46:01 2009 From: freebsd-net at blacquiere.nl (Robert Blacquiere) Date: Tue May 26 12:46:08 2009 Subject: Using multiple routing tables and rc.conf Message-ID: <20090526120709.GI17104@macmini.blacquiere.nl> Hi, I'me testing a network setup using multiple routing tables. I want to use this to setup different gateways. Some basic design is this: The system has two different uplinks (fast and slow for backup). And somewhere on the internet a colo with a full internet address range. I have setup the system with 2 giftunnels and use ospf over these for the internet range. This seems to be working. I want this to be configured with settings in rc.conf but failed to find the magic to do things like: setfib 0 ifconfig gif0 create 172.16.0.1 172.16.0.2 netmask 255.255.255.255 tunnel $extern_fast $colo I know setfib is not needed for the default routing table. setfib 1 ifconfig gif1 create 172.16.0.3 172.16.0.4 netmask 255.255.255.255 tunnel $extern_slow $colo and the routes: route add default $gateway_fast setfib 1 route add default $gateway_slow and use a third routing table for the ospf routing and pf to route traffic using the ospf announced routes. How would this be fitted in the rc.conf? for normal giftunnels i would use some thing like: gif_interfaces="gif0 gif1" gifconfig_gif0="$extern_fast $colo" ifconfig_gif0="inet 172.16.0.1 172.16.0.2 netmask 255.255.255.255" gifconfig_gif1="$extern_slow $colo" ifconfig_gif1="inet 172.16.0.3 172.16.0.4 netmask 255.255.255.255" But this won't include the setfib. For jails there is a setfib command using jail__fib. I would like some thing like that also for routes, interfaces and deamons to start. I know i could set these things in a rc.local but would rather use rc.conf for configuration. Did any of you guys done something like this? Regards Robert From bms at incunabulum.net Tue May 26 13:01:20 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue May 26 13:01:26 2009 Subject: Dialer for UMTS/3G modems Message-ID: <4A1BE819.6060909@incunabulum.net> Hi, Does anyone have a UMTS/3G dialer for FreeBSD which: a) works, and b) preferably has a GUI? Perhaps mpd has grown hooks for this sort of thing? thanks, BMS From swun2010 at gmail.com Tue May 26 13:10:38 2009 From: swun2010 at gmail.com (Sam Wun) Date: Tue May 26 13:10:45 2009 Subject: how to remove jid? Message-ID: <736c47cb0905260610y2d80f247w737962e3df5abadd@mail.gmail.com> Hi, Running FreeBSD 6.2, with jail, I hage the following jids shown in the jls command: # jls JID IP Address Hostname Path 10 125.255.1.6 wp.ipx.com.au /usr/jails/wp 8 125.255.1.6 wp /usr/jails/wp 7 125.255.1.6 wp /usr/jails/wp 1 125.255.1.6 wp1.ipx.com.au /usr/jails/wp1 There is only wp.ipx.com.au valid in the list, others are not exists. How to remove JID 8,7, and 1? Thanks From 000.fbsd at quip.cz Tue May 26 13:37:41 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue May 26 13:37:49 2009 Subject: how to remove jid? In-Reply-To: <736c47cb0905260610y2d80f247w737962e3df5abadd@mail.gmail.com> References: <736c47cb0905260610y2d80f247w737962e3df5abadd@mail.gmail.com> Message-ID: <4A1BF0A0.8090100@quip.cz> Sam Wun wrote: > Hi, > > Running FreeBSD 6.2, with jail, > I hage the following jids shown in the jls command: > > # jls > JID IP Address Hostname Path > 10 125.255.1.6 wp.ipx.com.au /usr/jails/wp > 8 125.255.1.6 wp /usr/jails/wp > 7 125.255.1.6 wp /usr/jails/wp > 1 125.255.1.6 wp1.ipx.com.au /usr/jails/wp1 > > There is only wp.ipx.com.au valid in the list, others are not exists. > How to remove JID 8,7, and 1? It is better to ask jail related questions in freebsd-jail@ mailinglist... I think you have no chance to remove those JIDs. 6.2 is "too old", 7.2 has newer code for jails and does not show zomie jails (by default). In case of 6.2, you can wait, until all network sockets are closed (if stale jails are caused by net connections) or you need to reboot whole host machine in other case. Miroslav Lachman From eri at freebsd.org Tue May 26 13:59:08 2009 From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Tue May 26 13:59:15 2009 Subject: Dialer for UMTS/3G modems In-Reply-To: <4A1BE819.6060909@incunabulum.net> References: <4A1BE819.6060909@incunabulum.net> Message-ID: <9a542da30905260631m795beeecu9da795b4f235e31c@mail.gmail.com> On Tue, May 26, 2009 at 3:01 PM, Bruce Simpson wrote: > Hi, > > Does anyone have a UMTS/3G dialer for FreeBSD which: > a) works, and > b) preferably has a GUI? pfSense has something in its non-stable version though not much testing has gone cause of drivers and availability of hardware. > > Perhaps mpd has grown hooks for this sort of thing? MPD has the hooks but you have to tweak the initialization. Take a look at mpd.script > > thanks, > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From adamk at voicenet.com Tue May 26 14:42:44 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Tue May 26 14:43:16 2009 Subject: kernel crashes with ndis & -CURRENT Message-ID: <20090526102901.6bf50586@voicenet.com> In an attempt to get the native drivers working on a particular wireless network at work I updated to -CURRENT to see if I'd have any more luck ( http://www.freebsd.org/cgi/query-pr.cgi?pr=131153&cat= ). Unfortunately, that didn't work out so I was decided to revert to the ndis drivers. I created a new module using the same sys and inf file that mostly worked on -STABLE (with frequent UP and DOWN messages, but better than nothing). Unfortunately, now I get a complete kernel panic. Please let me know if this is a better question for freebsd-current. Here's the backtrace: [ root@scroll - /var/crash ]: kgdb /boot/kernel/kernel vmcore.3 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: no radiotap setup cpuid = 0 KDB: enter: panic Uptime: 19s Physical memory: 1511 MB Dumping 86 MB: 71 55 39 23 7 Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done. done. Loaded symbols for /boot/kernel/aio.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/modules/w29n51_sys.ko...done. Loaded symbols for /boot/modules/w29n51_sys.ko Reading symbols from /boot/kernel/if_ndis.ko...Reading symbols from /boot/kernel/if_ndis.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_ndis.ko Reading symbols from /boot/kernel/ndis.ko...Reading symbols from /boot/kernel/ndis.ko.symbols...done. done. Loaded symbols for /boot/kernel/ndis.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc085ddce in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc085e0a2 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc093bca2 in ieee80211_radiotap_vattach (vap=0x0) at /usr/src/sys/net80211/ieee80211_radiotap.c:105 #4 0xc0915d4d in ieee80211_vap_setup (ic=0xc5ea1000, vap=0xc5938000, name=0xc0be3e47 "wlan", unit=0, opmode=1, flags=Variable "flags" is not available. ) at /usr/src/sys/net80211/ieee80211.c:468 #5 0xc58a987c in ndis_vap_create (ic=0xc5ea1000, name=0xc0be3e47 "wlan", unit=0, opmode=1, flags=0, bssid=0xe7553b14 "", mac=0xc52ac49d "") at /usr/src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:992 #6 0xc0920824 in wlan_clone_create (ifc=0xc0d24900, unit=0, params=0x8064f60
) at /usr/src/sys/net80211/ieee80211_freebsd.c:140 #7 0xc0904bd7 in ifc_simple_create (ifc=0xc0d24900, name=0xc5e9f440 "wlan0", len=16, params=0x8064f60
) at /usr/src/sys/net/if_clone.c:582 #8 0xc0904521 in if_clone_createif (ifc=0xc0d24900, name=0xc5e9f440 "wlan0", len=16, params=0x8064f60
) at /usr/src/sys/net/if_clone.c:193 #9 0xc090478c in if_clone_create (name=0xc5e9f440 "wlan0", len=16, params=0x8064f60
) at /usr/src/sys/net/if_clone.c:178 #10 0xc0904087 in ifioctl (so=0xc5596948, cmd=3223349628, data=0xc5e9f440 "wlan0", td=0xc51f1000) at /usr/src/sys/net/if.c:2291 #11 0xc08a6377 in soo_ioctl (fp=0xc51a5690, cmd=3223349628, data=0xc5e9f440, active_cred=0xc4d41500, td=0xc51f1000) at /usr/src/sys/kern/sys_socket.c:205 #12 0xc08a0ced in kern_ioctl (td=0xc51f1000, fd=3, com=3223349628, data=0xc5e9f440 "wlan0") at file.h:262 #13 0xc08a0e74 in ioctl (td=0xc51f1000, uap=0xe7553cf8) at /usr/src/sys/kern/sys_generic.c:677 #14 0xc0b66153 in syscall (frame=0xe7553d38) at /usr/src/sys/i386/i386/trap.c:1073 #15 0xc0b493c0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #16 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit From onemda at gmail.com Tue May 26 14:49:07 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Tue May 26 14:49:13 2009 Subject: kernel crashes with ndis & -CURRENT In-Reply-To: <20090526102901.6bf50586@voicenet.com> References: <20090526102901.6bf50586@voicenet.com> Message-ID: <3a142e750905260749r5e78536cwe14fb17c3939e72@mail.gmail.com> On 5/26/09, Adam K Kirchhoff wrote: > > In an attempt to get the native drivers working on a particular > wireless network at work I updated to -CURRENT to see if I'd have any > more luck ( http://www.freebsd.org/cgi/query-pr.cgi?pr=131153&cat= ). > > Unfortunately, that didn't work out so I was decided to revert to the > ndis drivers. I created a new module using the same sys and inf file > that mostly worked on -STABLE (with frequent UP and DOWN messages, but > better than nothing). Unfortunately, now I get a complete kernel panic. > > Please let me know if this is a better question for freebsd-current. > Here's the backtrace: Please update your kernel after r192765, this issue have been already fixed on CURRENT. -- Paul From linimon at lonesome.com Tue May 26 14:50:03 2009 From: linimon at lonesome.com (Mark Linimon) Date: Tue May 26 14:50:10 2009 Subject: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib Message-ID: <200905261450.n4QEo2Zs053560@freefall.freebsd.org> The following reply was made to PR kern/134931; it has been noted by GNATS. From: Mark Linimon To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib Date: Tue, 26 May 2009 09:43:41 -0500 ----- Forwarded message from Bruce Simpson ----- From: Bruce Simpson To: linimon@FreeBSD.org CC: freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib linimon@FreeBSD.org wrote: > Synopsis: [route] [fib] Route messages sent to all socket listeners regardless of setfib > That might actually be a feature, however, the "API contract" with the multiple routing table support might not have covered this, so it might be "undefined behaviour". ----- End forwarded message ----- From sullrich at gmail.com Tue May 26 16:54:51 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Tue May 26 16:55:00 2009 Subject: Dialer for UMTS/3G modems In-Reply-To: <9a542da30905260631m795beeecu9da795b4f235e31c@mail.gmail.com> References: <4A1BE819.6060909@incunabulum.net> <9a542da30905260631m795beeecu9da795b4f235e31c@mail.gmail.com> Message-ID: On Tue, May 26, 2009 at 9:31 AM, Ermal Lu?i wrote: >> Perhaps mpd has grown hooks for this sort of thing? > MPD has the hooks but you have to tweak the initialization. Take a > look at mpd.script Yes, it appears MPD should work. I have been trying to get MPD5 to work with my 3G cards on 8 but it cannot communicate with the driver and issue at commands where ppp does. MPD basically reports that the modem did not respond but ppp works great. Here's my configs (ppp works, mpd should work but not sure why it cannot communicate): http://cvs.pfsense.com/~sullrich/ppp.conf http://cvs.pfsense.com/~sullrich/mpd.conf Scott From biancalana at gmail.com Tue May 26 19:13:49 2009 From: biancalana at gmail.com (Alexandre Biancalana) Date: Tue May 26 19:13:56 2009 Subject: Multiple ftp servers behind pf with carp multi-ip Message-ID: <8e10486b0905261102y4fe7ccebya01221ecf09db36d@mail.gmail.com> Hi list, I have two firewall with 7.2-STABLE, PF and Carp for failover. The machine have one physical interface dedicated to two internet links (from different providers) and using two vlans on top of this physical interface. Each vlan have one real ip address and a carp interface with multiple real ip addresses for each vlan. I have three ftp servers with invalid ip addresses behind the firewall that need to be accessible from internet. Then I configured ftp-proxy in the following way: ftp-proxy -a -b -p21 -R When ftp_external_ip is an ip associated to the carp interface, the ftp connection is unstable, some times the connection is opened, some times the connection is broken in the middle of list command or before enter the password. If I start the ftp-proxy command using as ftp_external_ip the ip associated with the vlan interface everything works great. This machines are in production, so I'm building a lab with virtual machines to do some experiments and try to reproduce this. Did someone had seen something like this before ? I can provide any additional information needed for help troubleshooting. Best Regards, Alexandre From brooks at freebsd.org Tue May 26 20:11:49 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue May 26 20:11:56 2009 Subject: Wireless mesh networking In-Reply-To: <20090526192342.P55023@sola.nimnet.asn.au> References: <20090526192342.P55023@sola.nimnet.asn.au> Message-ID: <20090526201153.GB41682@lor.one-eyed-alien.net> On Tue, May 26, 2009 at 08:06:25PM +1000, Ian Smith wrote: > On Sun, 24 May 2009, Rui Paulo wrote: > > Hi, > > If anyone is interested in testing out wireless mesh networking under > > FreeBSD, the project has now reached a point where you can transfer > > packets between mesh nodes. > > Always a good point to celebrate :) > > > I try to keep the branch in sync with head (sometimes more than) > > weekly. The branch is located at the FreeBSD svn repo and everyone can > > fetch it: > > > > $ svn co http://svn.freebsd.org/viewvc/base/projects/mesh11s/ > > Not that I could run it now or even soon, but I'm interested in having a > look at the code, mostly to try figuring out the scope of what layers > this is working at, and noting that this is my first ever attempted use > of svn (and if it matters, on a 5.5-S box): > > sola% mkdir 802.11s > sola% cd 802.11s/ > sola% svn co http://svn.freebsd.org/viewvc/base/projects/mesh11s/ > svn: PROPFIND request failed on '/viewvc/base/projects/mesh11s' > svn: PROPFIND of '/viewvc/base/projects/mesh11s': 301 Moved (http://svn.freebsd.org) > > Where to from here? Might there be an old-fashioned tarball? Remove the "viewvc/" portion of the URL and it will work. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090526/b2934e6e/attachment.pgp From rpaulo at freebsd.org Tue May 26 21:01:30 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Tue May 26 21:02:02 2009 Subject: Wireless mesh networking In-Reply-To: <20090526192342.P55023@sola.nimnet.asn.au> References: <20090526192342.P55023@sola.nimnet.asn.au> Message-ID: <0B02BE09-36C5-4899-8DEC-1C78A269A04B@freebsd.org> On 26 May 2009, at 11:06, Ian Smith wrote: > On Sun, 24 May 2009, Rui Paulo wrote: >> Hi, >> If anyone is interested in testing out wireless mesh networking under >> FreeBSD, the project has now reached a point where you can transfer >> packets between mesh nodes. > > Always a good point to celebrate :) > >> I try to keep the branch in sync with head (sometimes more than) >> weekly. The branch is located at the FreeBSD svn repo and everyone >> can >> fetch it: >> >> $ svn co http://svn.freebsd.org/viewvc/base/projects/mesh11s/ > > Not that I could run it now or even soon, but I'm interested in > having a > look at the code, mostly to try figuring out the scope of what layers > this is working at, and noting that this is my first ever attempted > use > of svn (and if it matters, on a 5.5-S box): > > sola% mkdir 802.11s > sola% cd 802.11s/ > sola% svn co http://svn.freebsd.org/viewvc/base/projects/mesh11s/ > svn: PROPFIND request failed on '/viewvc/base/projects/mesh11s' > svn: PROPFIND of '/viewvc/base/projects/mesh11s': 301 Moved (http://svn.freebsd.org > ) > > Where to from here? Might there be an old-fashioned tarball? Sorry, what Brooks said. > >> To actually try out mesh networking you need ath(4) because ral(4) >> has >> problems right now. >> >> After building and installing a new world and kernel, you need to >> do this: >> # ifconfig wlan0 create wlandev ath0 wlanmode mesh channel 1 meshid >> mymesh >> # ifconfig wlan0 inet w.x.y.z/q up >> >> Channel discovery for mesh networks is not yet implemented, hence you >> need to manually specify the channel on which the mesh is running >> (all >> nodes must be on the same channel and same meshid, just like regular >> AP operation). > > Not more like regular ad-hoc operation? Yes, it's more like ad-hoc, but I was just illustrating a point for those that are more familiar with hostap networks having several nodes. > Pardon my ignorance. I've followed your later wikipedia links and > many > others from there, but still haven't got much of an overview. I'm a > little familiar with how OLSR works, and got some meaty clues reading > about the OLPC XO-1 use of their subset of 11s, but that's it so far. Well, you can try google for more information. The links I emailed were accessible to almost everyone. If you have a PowerPoint file reader, you will find much more information related to 802.11s on the web. Regards, -- Rui Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090526/e7ea3fec/PGP.pgp From smithi at nimnet.asn.au Wed May 27 02:08:52 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed May 27 02:08:59 2009 Subject: Wireless mesh networking In-Reply-To: <20090526201153.GB41682@lor.one-eyed-alien.net> References: <20090526192342.P55023@sola.nimnet.asn.au> <20090526201153.GB41682@lor.one-eyed-alien.net> Message-ID: <20090527115956.J55023@sola.nimnet.asn.au> On Tue, 26 May 2009, Brooks Davis wrote: > On Tue, May 26, 2009 at 08:06:25PM +1000, Ian Smith wrote: > > On Sun, 24 May 2009, Rui Paulo wrote: > > > Hi, > > > If anyone is interested in testing out wireless mesh networking under > > > FreeBSD, the project has now reached a point where you can transfer > > > packets between mesh nodes. > > > > Always a good point to celebrate :) > > > > > I try to keep the branch in sync with head (sometimes more than) > > > weekly. The branch is located at the FreeBSD svn repo and everyone can > > > fetch it: > > > > > > $ svn co http://svn.freebsd.org/viewvc/base/projects/mesh11s/ > > > > Not that I could run it now or even soon, but I'm interested in having a > > look at the code, mostly to try figuring out the scope of what layers > > this is working at, and noting that this is my first ever attempted use > > of svn (and if it matters, on a 5.5-S box): > > > > sola% mkdir 802.11s > > sola% cd 802.11s/ > > sola% svn co http://svn.freebsd.org/viewvc/base/projects/mesh11s/ > > svn: PROPFIND request failed on '/viewvc/base/projects/mesh11s' > > svn: PROPFIND of '/viewvc/base/projects/mesh11s': 301 Moved (http://svn.freebsd.org) > > > > Where to from here? Might there be an old-fashioned tarball? > > Remove the "viewvc/" portion of the URL and it will work. Indeed it does. I hadn't twigged that I'd be fetching an entire branch off head to peek at this code, though .. ah well, good target practice! Thanks Brooks, cheers, Ian From s.svirid at sibset-team.ru Wed May 27 05:50:03 2009 From: s.svirid at sibset-team.ru (Stanislav A Svirid) Date: Wed May 27 05:50:10 2009 Subject: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib Message-ID: <200905270550.n4R5o2Lr034413@freefall.freebsd.org> The following reply was made to PR kern/134931; it has been noted by GNATS. From: Stanislav A Svirid To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib Date: Wed, 27 May 2009 12:28:58 +0700 Bruce Simpson wrote: >> Synopsis: [route] [fib] Route messages sent to all socket listeners regardless of setfib >> > > That might actually be a feature, however, the "API contract" with the > multiple routing table support might not have covered this, so it might be > "undefined behaviour". So, how routing daemon can decide in what FIB route is changed? Or it can't now? -- Stanislav Svirid > Siberian Networks, Novosibirsk, Russia > SAS-RIPE, 3909675@ICQ From julian at elischer.org Wed May 27 05:58:38 2009 From: julian at elischer.org (Julian Elischer) Date: Wed May 27 05:58:50 2009 Subject: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib In-Reply-To: <200905270550.n4R5o2Lr034413@freefall.freebsd.org> References: <200905270550.n4R5o2Lr034413@freefall.freebsd.org> Message-ID: <4A1CD68B.5070508@elischer.org> Stanislav A Svirid wrote: > The following reply was made to PR kern/134931; it has been noted by GNATS. > > From: Stanislav A Svirid > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket > listeners regardless of setfib > Date: Wed, 27 May 2009 12:28:58 +0700 > > Bruce Simpson wrote: > >> Synopsis: [route] [fib] Route messages sent to all socket listeners regardless of setfib > >> > > > > That might actually be a feature, however, the "API contract" with the > > multiple routing table support might not have covered this, so it might be > > "undefined behaviour". > > So, how routing daemon can decide in what FIB route is changed? > Or it can't now? I believe there is a field that has been used for this purpose in OpenBSD, but is otherwise deprecated. anyone woth ore knowledge of teh protocls is invited to let us know what was used. Alternatively I was considering filtering packets to a routing socket to only allow packets relevant to that fib to be sent up. but I don't know much about the routing socket protcol. > > -- > Stanislav Svirid > > Siberian Networks, Novosibirsk, Russia > > SAS-RIPE, 3909675@ICQ > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From bms at incunabulum.net Wed May 27 13:51:50 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed May 27 13:52:11 2009 Subject: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib In-Reply-To: <4A1CD68B.5070508@elischer.org> References: <200905270550.n4R5o2Lr034413@freefall.freebsd.org> <4A1CD68B.5070508@elischer.org> Message-ID: <4A1D4571.1050500@incunabulum.net> Julian Elischer wrote: > Stanislav A Svirid wrote: >> >> So, how routing daemon can decide in what FIB route is changed? >> Or it can't now? > > I believe there is a field that has been used for this purpose in > OpenBSD, but is otherwise deprecated. anyone woth ore knowledge of > teh protocls is invited to let us know what was used. > > Alternatively I was considering filtering packets to a routing > socket to only allow packets relevant to that fib to be sent up. > but I don't know much about the routing socket protcol. Some of PF_ROUTE is pretty obscure. Netmasks, for example, are not encoded in a particularly intuitive or well documented way. It is a somewhat tightly packed encoding. Some would argue we shouldn't go the way Linux did -- i.e. implement a full-blown TLV protocol, some would argue it's the way to deal with situations like this. One thing that stands out about PF_ROUTE is that it is treated as a broadcast domain for all raw PF_ROUTE sockets. If those general semantics need to be changed then the implications of that change need to be considered very carefully. I'm not sure if the submitter is proposing that we change that -- it could break a lot of applications which depend on the routing socket, but clearly another field would be needed to indicate which FIB a route socket message relates to. A kludge/workaround which avoids reimplementing the PF_ROUTE layer would be to add a socket option and flag to the pcb for PF_ROUTE which indicates if the consumer is FIB aware, and default to off. From tedm at ipinc.net Thu May 28 01:30:10 2009 From: tedm at ipinc.net (tedm@ipinc.net) Date: Thu May 28 01:30:17 2009 Subject: kern/125195: [fxp] fxp(4) driver failed to initialize device Intel 82801DB Message-ID: <200905280130.n4S1U9Vd089493@freefall.freebsd.org> The following reply was made to PR kern/125195; it has been noted by GNATS. From: tedm@ipinc.net To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/125195: [fxp] fxp(4) driver failed to initialize device Intel 82801DB Date: Wed, 27 May 2009 17:52:17 -0700 (PDT) I have the same problem with a system I built with 2 Intel Pro/100 cards in it, intending to use it as a router. One card works, the other issues the fxp0: MII without any PHY! error message. Here is the output of pciconf: fxp0@pci0:9:0: class=0x020000 card=0x00018086 chip=0x12298086 rev=0x02 hdr=0x00 fxp1@pci0:11:0: class=0x020000 card=0x00000000 chip=0x12298086 rev=0x01 hdr=0x00 Physically, the cards look the same. Ted From swun2010 at gmail.com Thu May 28 03:51:29 2009 From: swun2010 at gmail.com (Sam Wun) Date: Thu May 28 03:51:36 2009 Subject: no network after upgraded from 6.2 to 7.2 Message-ID: <736c47cb0905272051p5afdb6a8u52033ca82ce65b01@mail.gmail.com> Hi, I don't know what is going on now. After upgraded from 6.2 to 7.2, I can't ping on host like www.yahoo.com pinging an external router (my isp router ip address) is fine. Can anyone help? Thanks From auryn at zirakzigil.org Thu May 28 12:14:26 2009 From: auryn at zirakzigil.org (Giulio Ferro) Date: Thu May 28 12:14:33 2009 Subject: NIC teaming with VLANs does't work Message-ID: <4A1E801C.2090803@zirakzigil.org> Freebsd 7.2 amd64 recently updated. I want to aggregate the two nics on my server (em0 and em1) in a single fec interface (so if one nick / switch is down, the other takes over). On this interface I want to build vlans. Here is the networking section of my /etc/rc.conf: ------------------------------------------------------------------------------ fec_interfaces="fec0" fecconfig_fec0="em0 em1" ifconfig_fec0="inet 192.168.28.24 netmask 255.255.255.0" cloned_interfaces="vlan30 vlan40 vlan50" ifconfig_vlan30="inet 192.168.30.10 netmask 255.255.255 vlan 30 vlandev fec0" ifconfig_vlan30_alias0="inet 192.168.30.11 netmask 255.255.255.255" ifconfig_vlan30_alias1="inet 192.168.30.12 netmask 255.255.255.255" ifconfig_vlan30_alias2="inet 192.168.30.13 netmask 255.255.255.255" ifconfig_vlan40="inet 192.168.40.10 netmask 255.255.255.0 vlan 40 vlandev fec0" ifconfig_vlan50="inet 192.168.50.10 netmask 255.255.255.0 vlan 50 vlandev fec0" ------------------------------------------------------------------------------ When I launch this configuration the vlans are created correctly and I see them as active. But when I try to ping other hosts in those vlans, the connection doesn't succeed. This is what happens in details: 1) The box is able to arp-request the IPs of other hosts on the chosen vlan (es. vlan40) 2) The IP packets from other hosts show up correctly on vlan40 (seen with tcpdump) 3) The box doesn't seem to be able to send IP packets to other hosts, even though I can see them leaving from vlan40 on my host (with tcpdump) I've tried with bce nics with the same result. Any help is appreciated. I'm available for tests, patches, and so on... From mike at sentex.net Thu May 28 12:20:43 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu May 28 12:20:49 2009 Subject: no network after upgraded from 6.2 to 7.2 In-Reply-To: <736c47cb0905272051p5afdb6a8u52033ca82ce65b01@mail.gmail.co m> References: <736c47cb0905272051p5afdb6a8u52033ca82ce65b01@mail.gmail.com> Message-ID: <200905281219.n4SCJ5M2054205@lava.sentex.ca> At 11:51 PM 5/27/2009, Sam Wun wrote: >Hi, > >I don't know what is going on now. >After upgraded from 6.2 to 7.2, I can't ping on host like www.yahoo.com >pinging an external router (my isp router ip address) is fine. More details... e.g. output of ifconfig -a, netstat -nr... Do you have any firewalls enabled/loaded etc...ppp ? ethernet ? etc.... ---Mike >Can anyone help? >Thanks >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From vince at unsane.co.uk Thu May 28 12:39:54 2009 From: vince at unsane.co.uk (Vincent Hoffman) Date: Thu May 28 12:40:00 2009 Subject: NIC teaming with VLANs does't work In-Reply-To: <4A1E801C.2090803@zirakzigil.org> References: <4A1E801C.2090803@zirakzigil.org> Message-ID: <4A1E8612.9000802@unsane.co.uk> On 28/5/09 13:14, Giulio Ferro wrote: > Freebsd 7.2 amd64 recently updated. > > I want to aggregate the two nics on my server (em0 and em1) in a single > fec interface (so if one nick / switch is down, the other takes over). > On this interface I want to build vlans. > > Here is the networking section of my /etc/rc.conf: > > ------------------------------------------------------------------------------ > > fec_interfaces="fec0" > fecconfig_fec0="em0 em1" > ifconfig_fec0="inet 192.168.28.24 netmask 255.255.255.0" > > cloned_interfaces="vlan30 vlan40 vlan50" > ifconfig_vlan30="inet 192.168.30.10 netmask 255.255.255 vlan 30 > vlandev fec0" > ifconfig_vlan30_alias0="inet 192.168.30.11 netmask 255.255.255.255" > ifconfig_vlan30_alias1="inet 192.168.30.12 netmask 255.255.255.255" > ifconfig_vlan30_alias2="inet 192.168.30.13 netmask 255.255.255.255" > ifconfig_vlan40="inet 192.168.40.10 netmask 255.255.255.0 vlan 40 > vlandev fec0" > ifconfig_vlan50="inet 192.168.50.10 netmask 255.255.255.0 vlan 50 > vlandev fec0" > > ------------------------------------------------------------------------------ > > > When I launch this configuration the vlans are created correctly and I > see them as active. > But when I try to ping other hosts in those vlans, the connection > doesn't succeed. > > This is what happens in details: > 1) The box is able to arp-request the IPs of other hosts on the > chosen vlan (es. vlan40) > 2) The IP packets from other hosts show up correctly on vlan40 (seen > with tcpdump) > 3) The box doesn't seem to be able to send IP packets to other hosts, > even though I can > see them leaving from vlan40 on my host (with tcpdump) > > I've tried with bce nics with the same result. > > Any help is appreciated. I'm available for tests, patches, and so on... Possibly try lagg(4) instead? this supports fec and lacp. Vince > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From kalinoj1 at iem.pw.edu.pl Thu May 28 19:20:19 2009 From: kalinoj1 at iem.pw.edu.pl (Jedrzej Kalinowski) Date: Thu May 28 19:20:26 2009 Subject: Bridging and stp question Message-ID: <4A1EE0F5.1070909@iem.pw.edu.pl> Hello, I'm using a bridge to connect tap devices used by qemu emulator to an outside world. I run into a bit of problem however, because if I feed qemu virtual machine with two tap interfaces - I need to turn on stp on them when adding to a bridge to prevent a loop . This is probably due to improper qemu behaviour as I suppose, because I does not happen when I run two qemu machines with each of them getting one tap device. As we know from 'man ifconfig' the default behaviour for the interface added to a bridge is to add it with stp protocol disabled and I have to specify stp explicitly. My question is: Is there any way to configure the bridge to add stp protocol to any added (via ifconfig bridgeX addm ifX) member interface - so to change the default behaviour? Or specifying it explicitly is unavoidable? Best regards. -- Jedrzej Kalinowski From pluknet at gmail.com Thu May 28 20:28:22 2009 From: pluknet at gmail.com (pluknet) Date: Thu May 28 20:28:38 2009 Subject: Bridging and stp question In-Reply-To: <4A1EE0F5.1070909@iem.pw.edu.pl> References: <4A1EE0F5.1070909@iem.pw.edu.pl> Message-ID: 2009/5/28 Jedrzej Kalinowski : > Hello, > > I'm using a bridge to connect tap devices used by qemu emulator to an > outside world. > > I run into a bit of problem however, because if I feed qemu virtual > machine with two tap interfaces - I need to turn on stp on them when > adding to a bridge to prevent a loop . > > This is probably due to improper qemu behaviour as I suppose, because I > does not happen when I run two qemu machines with each of them getting > one tap device. > > As we know from 'man ifconfig' the default behaviour for the interface > added to a bridge is to add it with stp protocol disabled and I have to > specify stp explicitly. > > My question is: > > Is there any way to configure the bridge to add stp protocol to any > added (via ifconfig bridgeX addm ifX) member interface - so to change > the default behaviour? Or specifying it explicitly is unavoidable? > Let me clarify some. Did I understand you correctly that `ifconfig bridge0 addm ifX stp ifX` doesn't fit you needs? -- wbr, pluknet From kalinoj1 at iem.pw.edu.pl Thu May 28 20:38:43 2009 From: kalinoj1 at iem.pw.edu.pl (Jedrzej Kalinowski) Date: Thu May 28 20:38:49 2009 Subject: Bridging and stp question In-Reply-To: References: <4A1EE0F5.1070909@iem.pw.edu.pl> Message-ID: <4A1EF6FB.7080306@iem.pw.edu.pl> pluknet pisze: > 2009/5/28 Jedrzej Kalinowski : >> Hello, >> >> I'm using a bridge to connect tap devices used by qemu emulator to an >> outside world. >> >> I run into a bit of problem however, because if I feed qemu virtual >> machine with two tap interfaces - I need to turn on stp on them when >> adding to a bridge to prevent a loop . >> >> This is probably due to improper qemu behaviour as I suppose, because I >> does not happen when I run two qemu machines with each of them getting >> one tap device. >> >> As we know from 'man ifconfig' the default behaviour for the interface >> added to a bridge is to add it with stp protocol disabled and I have to >> specify stp explicitly. >> >> My question is: >> >> Is there any way to configure the bridge to add stp protocol to any >> added (via ifconfig bridgeX addm ifX) member interface - so to change >> the default behaviour? Or specifying it explicitly is unavoidable? >> > > Let me clarify some. Did I understand you correctly > that `ifconfig bridge0 addm ifX stp ifX` doesn't fit you needs? > Well, it works fine. It just would be more comfortable for me to do just: ifconfig bridge0 addm ifX and have bridge0 configured to add stp proto to each member interface as a default action. It would allow me to configure spanning tree on specific bridge globally, with no need to do it for each member interface. -- J?drzej Kalinowski From smallpox at gmail.com Fri May 29 00:35:42 2009 From: smallpox at gmail.com (smallpox) Date: Fri May 29 00:35:49 2009 Subject: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ? Message-ID: <4A1F2706.2080304@gmail.com> hey guys, i've read http://www.nabble.com/bsnmpd---64bits-counters-problem-td21037241.html and even though my problem doesn't have to do with laggproto/lacp, i'm hoping somebody could help me here.. i've honestly not tested 32bit, it seems fine, i'm using net-snmp for that but unfortunately the gigE switch only does 32bit counters and im stuck having to run a snmpd on my friends server. i'm getting really weird numbers... the interface is bce. bce0@pci0:3:0:0: class=0x020000 card=0x7038103c chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = '5708C Broadcom NetXtreme II Gigabit Ethernet Adapter' class = network subclass = ethernet bce0: flags=8843 metric 0 mtu 1500 options=1bb capabilities=1bb ether 00:23:7d:1f:1f:1f inet 10.83.1.148 netmask 0xffffff00 broadcast 10.83.1.255 media: Ethernet 1000baseTX status: active supported media: media autoselect media 1000baseTX mediaopt full-duplex media 1000baseTX media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP media none Max Average Current In 108.5 Mb/s (11.4%) 43.1 Mb/s (4.5%) 84.5 Mb/s (8.9%) Out 108.9 Mb/s (11.4%) 46.3 Mb/s (4.9%) 87.8 Mb/s (9.2%) In 728.4 Mb/s (76.4%) 82.4 Mb/s (8.6%) 84.4 Mb/s (8.9%) Out 630.8 Mb/s (66.1%) 71.9 Mb/s (7.5%) 87.8 Mb/s (9.2%) IF-MIB::ifHCInOctets.1 /15 sec: 242834334 IF-MIB::ifHCOutOctets.1 /15 sec: 234746163 IF-MIB::ifHCInOctets.1 /15 sec: 229173016 IF-MIB::ifHCOutOctets.1 /15 sec: 222515212 IF-MIB::ifHCInOctets.1 /15 sec: 317855088 IF-MIB::ifHCOutOctets.1 /15 sec: 228409807 IF-MIB::ifHCInOctets.1 /15 sec: 448979834 IF-MIB::ifHCOutOctets.1 /15 sec: 224671964 IF-MIB::ifHCInOctets.1 /15 sec: 245111558 IF-MIB::ifHCOutOctets.1 /15 sec: 240012214 IF-MIB::ifHCInOctets.1 /15 sec: 231863544 IF-MIB::ifHCOutOctets.1 /15 sec: 230419072 IF-MIB::ifHCInOctets.1 /15 sec: 225722738 IF-MIB::ifHCOutOctets.1 /15 sec: 228135152 IF-MIB::ifHCInOctets.1 /15 sec: 210319060 IF-MIB::ifHCOutOctets.1 /15 sec: 204326504 IF-MIB::ifHCInOctets.1 /15 sec: 206058382 IF-MIB::ifHCOutOctets.1 /15 sec: 201568575 IF-MIB::ifHCInOctets.1 /15 sec: 196742834 IF-MIB::ifHCOutOctets.1 /15 sec: 195121176 IF-MIB::ifHCInOctets.1 /15 sec: 209255410 IF-MIB::ifHCOutOctets.1 /15 sec: 208419793 now with bsnmd.. [root@main ~]# snmpdelta -c 322dd3 -v 2c -Cp 15 localhost IF-MIB::ifHCInOctets.1 IF-MIB::ifHCOutOctets.1 IF-MIB::ifHCInOctets.1 /15 sec: 139879092 IF-MIB::ifHCOutOctets.1 /15 sec: 141232448 IF-MIB::ifHCInOctets.1 /15 sec: 162440628 IF-MIB::ifHCOutOctets.1 /15 sec: 164098946 IF-MIB::ifHCInOctets.1 /15 sec: 160335614 IF-MIB::ifHCOutOctets.1 /15 sec: 156979676 ^C and so on, the numbers are off, this is the current mrtg that's not wrapping because the bandwidth has died down right now (netgear 32bit counters) In 109.3 Mb/s (11.5%) 30.0 Mb/s (3.1%) 82.0 Mb/s (8.6%) Out 73.4 Mb/s (7.7%) 4432.1 kb/s (0.5%) 3894.4 kb/s (0.4%) it's current is 82 megs and 4megs.. but as you could see above, those numbers are proposterous! [root@main ~]# snmpwalk -v 2c -c mycom localhost if IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifIndex.2 = INTEGER: 2 IF-MIB::ifIndex.3 = INTEGER: 3 IF-MIB::ifIndex.4 = INTEGER: 4 IF-MIB::ifIndex.5 = INTEGER: 5 IF-MIB::ifDescr.1 = STRING: bce0 IF-MIB::ifDescr.2 = STRING: bce1 IF-MIB::ifDescr.3 = STRING: pfsync0 IF-MIB::ifDescr.4 = STRING: pflog0 IF-MIB::ifDescr.5 = STRING: lo0 IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6) IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6) IF-MIB::ifType.3 = INTEGER: 247 IF-MIB::ifType.4 = INTEGER: 246 IF-MIB::ifType.5 = INTEGER: softwareLoopback(24) IF-MIB::ifMtu.1 = INTEGER: 1500 IF-MIB::ifMtu.2 = INTEGER: 1500 IF-MIB::ifMtu.3 = INTEGER: 1460 IF-MIB::ifMtu.4 = INTEGER: 33204 IF-MIB::ifMtu.5 = INTEGER: 16384 IF-MIB::ifSpeed.1 = Gauge32: 1000000000 IF-MIB::ifSpeed.2 = Gauge32: 0 IF-MIB::ifSpeed.3 = Gauge32: 0 IF-MIB::ifSpeed.4 = Gauge32: 0 IF-MIB::ifSpeed.5 = Gauge32: 0 IF-MIB::ifPhysAddress.1 = STRING: 0:23 IF-MIB::ifPhysAddress.2 = STRING: 0:23 IF-MIB::ifPhysAddress.3 = STRING: IF-MIB::ifPhysAddress.4 = STRING: IF-MIB::ifPhysAddress.5 = STRING: IF-MIB::ifAdminStatus.1 = INTEGER: up(1) IF-MIB::ifAdminStatus.2 = INTEGER: down(2) IF-MIB::ifAdminStatus.3 = INTEGER: down(2) IF-MIB::ifAdminStatus.4 = INTEGER: down(2) IF-MIB::ifAdminStatus.5 = INTEGER: up(1) IF-MIB::ifOperStatus.1 = INTEGER: up(1) IF-MIB::ifOperStatus.2 = INTEGER: down(2) IF-MIB::ifOperStatus.3 = INTEGER: down(2) IF-MIB::ifOperStatus.4 = INTEGER: down(2) IF-MIB::ifOperStatus.5 = INTEGER: up(1) IF-MIB::ifLastChange.1 = Timeticks: (0) 0:00:00.00 IF-MIB::ifLastChange.2 = Timeticks: (0) 0:00:00.00 IF-MIB::ifLastChange.3 = Timeticks: (0) 0:00:00.00 IF-MIB::ifLastChange.4 = Timeticks: (0) 0:00:00.00 IF-MIB::ifLastChange.5 = Timeticks: (0) 0:00:00.00 IF-MIB::ifInOctets.1 = Counter32: 1925880302 IF-MIB::ifInOctets.2 = Counter32: 0 IF-MIB::ifInOctets.3 = Counter32: 0 IF-MIB::ifInOctets.4 = Counter32: 0 IF-MIB::ifInOctets.5 = Counter32: 70588046 IF-MIB::ifInUcastPkts.1 = Counter32: 596514880 IF-MIB::ifInUcastPkts.2 = Counter32: 0 IF-MIB::ifInUcastPkts.3 = Counter32: 0 IF-MIB::ifInUcastPkts.4 = Counter32: 0 IF-MIB::ifInUcastPkts.5 = Counter32: 825258 IF-MIB::ifInNUcastPkts.1 = Counter32: 134523 IF-MIB::ifInNUcastPkts.2 = Counter32: 0 IF-MIB::ifInNUcastPkts.3 = Counter32: 0 IF-MIB::ifInNUcastPkts.4 = Counter32: 0 IF-MIB::ifInNUcastPkts.5 = Counter32: 0 IF-MIB::ifInDiscards.1 = Counter32: 0 IF-MIB::ifInDiscards.2 = Counter32: 0 IF-MIB::ifInDiscards.3 = Counter32: 0 IF-MIB::ifInDiscards.4 = Counter32: 0 IF-MIB::ifInDiscards.5 = Counter32: 0 IF-MIB::ifInErrors.1 = Counter32: 1905064 IF-MIB::ifInErrors.2 = Counter32: 0 IF-MIB::ifInErrors.3 = Counter32: 0 IF-MIB::ifInErrors.4 = Counter32: 0 IF-MIB::ifInErrors.5 = Counter32: 0 IF-MIB::ifInUnknownProtos.1 = Counter32: 0 IF-MIB::ifInUnknownProtos.2 = Counter32: 0 IF-MIB::ifInUnknownProtos.3 = Counter32: 0 IF-MIB::ifInUnknownProtos.4 = Counter32: 0 IF-MIB::ifInUnknownProtos.5 = Counter32: 0 IF-MIB::ifOutOctets.1 = Counter32: 2010402928 IF-MIB::ifOutOctets.2 = Counter32: 0 IF-MIB::ifOutOctets.3 = Counter32: 0 IF-MIB::ifOutOctets.4 = Counter32: 0 IF-MIB::ifOutOctets.5 = Counter32: 70587030 IF-MIB::ifOutUcastPkts.1 = Counter32: 409476782 IF-MIB::ifOutUcastPkts.2 = Counter32: 0 IF-MIB::ifOutUcastPkts.3 = Counter32: 0 IF-MIB::ifOutUcastPkts.4 = Counter32: 0 IF-MIB::ifOutUcastPkts.5 = Counter32: 825236 IF-MIB::ifOutNUcastPkts.1 = Counter32: 0 IF-MIB::ifOutNUcastPkts.2 = Counter32: 0 IF-MIB::ifOutNUcastPkts.3 = Counter32: 0 IF-MIB::ifOutNUcastPkts.4 = Counter32: 0 IF-MIB::ifOutNUcastPkts.5 = Counter32: 0 IF-MIB::ifOutDiscards.1 = Counter32: 50443 IF-MIB::ifOutDiscards.2 = Counter32: 0 IF-MIB::ifOutDiscards.3 = Counter32: 0 IF-MIB::ifOutDiscards.4 = Counter32: 0 IF-MIB::ifOutDiscards.5 = Counter32: 0 IF-MIB::ifOutErrors.1 = Counter32: 0 IF-MIB::ifOutErrors.2 = Counter32: 0 IF-MIB::ifOutErrors.3 = Counter32: 0 IF-MIB::ifOutErrors.4 = Counter32: 0 IF-MIB::ifOutErrors.5 = Counter32: 0 IF-MIB::ifOutQLen.1 = Gauge32: 0 IF-MIB::ifOutQLen.2 = Gauge32: 0 IF-MIB::ifOutQLen.3 = Gauge32: 0 IF-MIB::ifOutQLen.4 = Gauge32: 0 IF-MIB::ifOutQLen.5 = Gauge32: 0 IF-MIB::ifSpecific.1 = OID: SNMPv2-SMI::zeroDotZero IF-MIB::ifSpecific.2 = OID: SNMPv2-SMI::zeroDotZero IF-MIB::ifSpecific.3 = OID: SNMPv2-SMI::zeroDotZero IF-MIB::ifSpecific.4 = OID: SNMPv2-SMI::zeroDotZero IF-MIB::ifSpecific.5 = OID: SNMPv2-SMI::zeroDotZero ^not sure why Counter64 isn't there. [root@main ~]# snmpwalk -v 2c -c mycom localhost ifHCOutOctets IF-MIB::ifHCOutOctets.1 = Counter64: 24987772822 [root@main ~]# snmpwalk -v 2c -c mycom localhost ifHCInOctets IF-MIB::ifHCInOctets.1 = Counter64: 24913302044 [root@main ~]# in comparison to an intel em.. 32bit, it's linked at a gigabit though.. but no heavy traffic there. --BEGIN WORKING IF-MIB::ifInOctets.1 /15 sec: 1932426 IF-MIB::ifOutOctets.1 /15 sec: 24270520 IF-MIB::ifInOctets.1 /15 sec: 2199107 IF-MIB::ifOutOctets.1 /15 sec: 28672350 IF-MIB::ifInOctets.1 /15 sec: 2049073 IF-MIB::ifOutOctets.1 /15 sec: 22716321 IF-MIB::ifInOctets.1 /15 sec: 2036279 IF-MIB::ifOutOctets.1 /15 sec: 24361972 IF-MIB::ifInOctets.1 /15 sec: 2571021 IF-MIB::ifOutOctets.1 /15 sec: 32539047 IF-MIB::ifInOctets.1 /15 sec: 2416155 IF-MIB::ifOutOctets.1 /15 sec: 30571680 IF-MIB::ifInOctets.1 /15 sec: 2583795 IF-MIB::ifOutOctets.1 /15 sec: 35712392 IF-MIB::ifInOctets.1 /15 sec: 2665891 IF-MIB::ifOutOctets.1 /15 sec: 34761228 IF-MIB::ifInOctets.1 /15 sec: 2249559 IF-MIB::ifOutOctets.1 /15 sec: 27438273 --END WORKING i've tried to give as much as info as i possibly could, i'd appreciate any help here. From sebastian.mellmann at net.t-labs.tu-berlin.de Fri May 29 08:37:49 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Fri May 29 08:37:56 2009 Subject: ipfw dummynet queue size limitations Message-ID: Hi everyone! I've already asked this one the ipfw list, but maybe someone here got a hint for me. I'm trying to configure the queue size in ipfw dummynet larger then 100 slots, but I can't do so since ipfw always tells me that the maximum is 100. Is there any chance to increase the queue size? I could only find a thread [1] from 2006 about this. Thanks a lot for any hints or help! Regards, Sebastian [1] http://freebsd.monkey.org/freebsd-ipfw/200610/msg00018.html From sebastian.mellmann at net.t-labs.tu-berlin.de Fri May 29 09:52:18 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Fri May 29 09:52:31 2009 Subject: pktgen udp doesn't work over freebsd gateway Message-ID: Hello everyone! I'm using 'pktgen' [1] under linux to generate packets. My topology looks like this: (linux-box #1) <---> (em0 - freebsd-gateway - em1) <---> (linux-box #2) I want to send packets from linux-box #1 to linux-box #2 over the free-bsd gateway. The problem is that I can see the packets on em0, but not on em1. I assume there's a configuration missing on the BSD machine, because it seems it just drops the packets hence doesn't forward them to linux-box #2. rc.conf: gateway_enable="YES" keymap="german.iso" sshd_enable="YES" firewall_enable="YES" firewall_type="OPEN" firewall_logging="YES" Default option for ipfw is to accept packets. tcpdump em0: 11:42:36.334798 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length 18 11:42:36.334802 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length 18 11:42:36.334805 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length 18 11:42:36.334807 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length 18 11:42:36.334810 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length 18 11:42:36.334813 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length 18 11:42:36.334816 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length 18 11:42:36.334819 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length 18 11:42:36.334821 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length 18 11:42:36.334824 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length 18 tcpdump em1: nothing. Is there any sysctl variable that needs to be set? Connectivity between the boxes is definately working (tested with ping, iperf etc.). Regards, Sebastian [1] http://www.linuxfoundation.org/en/Net:Pktgen From bms at incunabulum.net Fri May 29 10:51:46 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri May 29 10:51:54 2009 Subject: Bridging and stp question In-Reply-To: <4A1EF6FB.7080306@iem.pw.edu.pl> References: <4A1EE0F5.1070909@iem.pw.edu.pl> <4A1EF6FB.7080306@iem.pw.edu.pl> Message-ID: <4A1FBE3E.9080203@incunabulum.net> Jedrzej Kalinowski wrote: > pluknet pisze: > >> 2009/5/28 Jedrzej Kalinowski : >> >>> Is there any way to configure the bridge to add stp protocol to any >>> added (via ifconfig bridgeX addm ifX) member interface - so to change >>> the default behaviour? Or specifying it explicitly is unavoidable? >>> >>> >> Let me clarify some. Did I understand you correctly >> that `ifconfig bridge0 addm ifX stp ifX` doesn't fit you needs? >> >> > > Well, it works fine. > > It just would be more comfortable for me to do just: > ifconfig bridge0 addm ifX > > and have bridge0 configured to add stp proto to each member interface as > a default action. > > It would allow me to configure spanning tree on specific bridge > globally, with no need to do it for each member interface. > Can't you just put this command in a qemu-ifup script? If not, can you clarify why it does not work for you? thanks, BMS From hartmut.brandt at dlr.de Fri May 29 12:43:42 2009 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Fri May 29 12:43:54 2009 Subject: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ? In-Reply-To: <4A1F2706.2080304@gmail.com> References: <4A1F2706.2080304@gmail.com> Message-ID: <20090529142757.X22933@beagle.kn.op.dlr.de> On Thu, 28 May 2009, smallpox wrote: s>hey guys, i've read s> [SNIP] s> s>in comparison to an intel em.. 32bit, it's linked at a gigabit though.. but no s>heavy traffic there. s> s>--BEGIN WORKING s>IF-MIB::ifInOctets.1 /15 sec: 1932426 s>IF-MIB::ifOutOctets.1 /15 sec: 24270520 s>IF-MIB::ifInOctets.1 /15 sec: 2199107 s>IF-MIB::ifOutOctets.1 /15 sec: 28672350 s>IF-MIB::ifInOctets.1 /15 sec: 2049073 s>IF-MIB::ifOutOctets.1 /15 sec: 22716321 s>IF-MIB::ifInOctets.1 /15 sec: 2036279 s>IF-MIB::ifOutOctets.1 /15 sec: 24361972 s>IF-MIB::ifInOctets.1 /15 sec: 2571021 s>IF-MIB::ifOutOctets.1 /15 sec: 32539047 s>IF-MIB::ifInOctets.1 /15 sec: 2416155 s>IF-MIB::ifOutOctets.1 /15 sec: 30571680 s>IF-MIB::ifInOctets.1 /15 sec: 2583795 s>IF-MIB::ifOutOctets.1 /15 sec: 35712392 s>IF-MIB::ifInOctets.1 /15 sec: 2665891 s>IF-MIB::ifOutOctets.1 /15 sec: 34761228 s>IF-MIB::ifInOctets.1 /15 sec: 2249559 s>IF-MIB::ifOutOctets.1 /15 sec: 27438273 s> s>--END WORKING Do I get it wrong or do the 32-bit counters also go up and down? Given that bsnmpd just retrieves the values from the kernel and sends them over SNMP without looking at the values (for the 32-bit counters) this looks rather like a problem in the kernel/driver. Do these drivers perhaps use multiple threads for receiving? harti From vivek at khera.org Fri May 29 14:00:13 2009 From: vivek at khera.org (Vick Khera) Date: Fri May 29 14:00:29 2009 Subject: bin/131365: route(8): route add changes interpretation of network specification [regression] Message-ID: <200905291400.n4TE0BXs033420@freefall.freebsd.org> The following reply was made to PR bin/131365; it has been noted by GNATS. From: Vick Khera To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/131365: route(8): route add changes interpretation of network specification [regression] Date: Fri, 29 May 2009 09:57:13 -0400 I'm not really following the discussion here so much, but in FreeBSD 7.2, it still sets the routes incorrectly from my perspective. I have in my rc.conf the following: route_vpn1="-net 192.168 192.168.100.202" and it results in the following route (from netstat -rn) Destination Gateway Flags Refs Use Netif Expire 192.168.0.0/24 192.168.100.202 UGS 0 0 em1 whereas in 7.0 and prior, it resulted in a /16 route as I expected, and as I understand it should be from the man page. The man page explicitly states: "-net 128.32 is interpreted as 128.32.0.0" so the man page and the behavior are seemingly inconsistent (still). From smallpox at gmail.com Fri May 29 14:27:23 2009 From: smallpox at gmail.com (smallpox) Date: Fri May 29 14:27:30 2009 Subject: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ? In-Reply-To: <20090529142757.X22933@beagle.kn.op.dlr.de> References: <4A1F2706.2080304@gmail.com> <20090529142757.X22933@beagle.kn.op.dlr.de> Message-ID: <4A1FF0B1.8040209@gmail.com> well, from what im told by snmp people, it's what's happening at that time, so up and down is normal... but not at the rate that the non-working one is going. and this one's upload and download are spread out normallly, 24 mbit out, 2mbit in... current figures on the messed up system: [07:25:32 5/29] IF-MIB::ifInOctets.1 /1 sec: 238914024 [07:25:32 5/29] IF-MIB::ifOutOctets.1 /1 sec: 223977573 [07:25:47 5/29] IF-MIB::ifInOctets.1 /1 sec: 235054494 [07:25:47 5/29] IF-MIB::ifOutOctets.1 /1 sec: 222830449 one of the differences between bsnmpd and net-snmpd is net-snmpd updates every 15 sec, anyway. see how the in/out are so close? that's totally off. the driver in question is bce... im not sure thanks Harti Brandt wrote: > On Thu, 28 May 2009, smallpox wrote: > > s>hey guys, i've read > s> > > [SNIP] > > s> > s>in comparison to an intel em.. 32bit, it's linked at a gigabit though.. but no > s>heavy traffic there. > s> > s>--BEGIN WORKING > s>IF-MIB::ifInOctets.1 /15 sec: 1932426 > s>IF-MIB::ifOutOctets.1 /15 sec: 24270520 > s>IF-MIB::ifInOctets.1 /15 sec: 2199107 > s>IF-MIB::ifOutOctets.1 /15 sec: 28672350 > s>IF-MIB::ifInOctets.1 /15 sec: 2049073 > s>IF-MIB::ifOutOctets.1 /15 sec: 22716321 > s>IF-MIB::ifInOctets.1 /15 sec: 2036279 > s>IF-MIB::ifOutOctets.1 /15 sec: 24361972 > s>IF-MIB::ifInOctets.1 /15 sec: 2571021 > s>IF-MIB::ifOutOctets.1 /15 sec: 32539047 > s>IF-MIB::ifInOctets.1 /15 sec: 2416155 > s>IF-MIB::ifOutOctets.1 /15 sec: 30571680 > s>IF-MIB::ifInOctets.1 /15 sec: 2583795 > s>IF-MIB::ifOutOctets.1 /15 sec: 35712392 > s>IF-MIB::ifInOctets.1 /15 sec: 2665891 > s>IF-MIB::ifOutOctets.1 /15 sec: 34761228 > s>IF-MIB::ifInOctets.1 /15 sec: 2249559 > s>IF-MIB::ifOutOctets.1 /15 sec: 27438273 > s> > s>--END WORKING > > Do I get it wrong or do the 32-bit counters also go up and down? Given > that bsnmpd just retrieves the values from the kernel and sends them over > SNMP without looking at the values (for the 32-bit counters) this looks > rather like a problem in the kernel/driver. Do these drivers perhaps use > multiple threads for receiving? > > harti > > From hartmut.brandt at dlr.de Fri May 29 15:24:15 2009 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Fri May 29 15:24:22 2009 Subject: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ? In-Reply-To: <4A1FF0B1.8040209@gmail.com> References: <4A1F2706.2080304@gmail.com> <20090529142757.X22933@beagle.kn.op.dlr.de> <4A1FF0B1.8040209@gmail.com> Message-ID: <20090529165809.O23256@beagle.kn.op.dlr.de> On Fri, 29 May 2009, smallpox wrote: s>well, from what im told by snmp people, it's what's happening at that time, so s>up and down is normal... but not at the rate that the non-working one is s>going. and this one's upload and download are spread out normallly, 24 mbit s>out, 2mbit in... s> s>current figures on the messed up system: s> s>[07:25:32 5/29] IF-MIB::ifInOctets.1 /1 sec: 238914024 s>[07:25:32 5/29] IF-MIB::ifOutOctets.1 /1 sec: 223977573 s>[07:25:47 5/29] IF-MIB::ifInOctets.1 /1 sec: 235054494 s>[07:25:47 5/29] IF-MIB::ifOutOctets.1 /1 sec: 222830449 s> s>one of the differences between bsnmpd and net-snmpd is net-snmpd updates every s>15 sec, anyway. see how the in/out are so close? that's totally off. s> s>the driver in question is bce... im not sure Hmm. Why would these numbers go up and down? As I understand it they should go up and wrap at either 32-bit or 64-bit. There are only two cases when they go down: a wrap or a discontinuity, which would be recorded in ifCounterDiscontinuityTime. Just to check: could you please disable TSO on the interface and look what it does? harti s>Harti Brandt wrote: s>> On Thu, 28 May 2009, smallpox wrote: s>> s>> s>hey guys, i've read s>> s> s>> s>> [SNIP] s>> s>> s> s>> s>in comparison to an intel em.. 32bit, it's linked at a gigabit though.. s>> but no s>> s>heavy traffic there. s>> s> s>> s>--BEGIN WORKING s>> s>IF-MIB::ifInOctets.1 /15 sec: 1932426 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24270520 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2199107 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 28672350 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2049073 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 22716321 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2036279 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24361972 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2571021 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 32539047 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2416155 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 30571680 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2583795 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 35712392 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2665891 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 34761228 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2249559 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 27438273 s>> s> s>> s>--END WORKING s>> s>> Do I get it wrong or do the 32-bit counters also go up and down? Given that s>> bsnmpd just retrieves the values from the kernel and sends them over SNMP s>> without looking at the values (for the 32-bit counters) this looks rather s>> like a problem in the kernel/driver. Do these drivers perhaps use multiple s>> threads for receiving? s>> s>> harti s>> s>> s> s> From barney_cordoba at yahoo.com Fri May 29 15:52:57 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Fri May 29 15:53:03 2009 Subject: ipfw dummynet queue size limitations Message-ID: <130182.52355.qm@web63908.mail.re1.yahoo.com> --- On Fri, 5/29/09, Sebastian Mellmann wrote: > From: Sebastian Mellmann > Subject: ipfw dummynet queue size limitations > To: freebsd-net@freebsd.org > Date: Friday, May 29, 2009, 4:37 AM > Hi everyone! > > I've already asked this one the ipfw list, but maybe > someone here got a > hint for me. > I'm trying to configure the queue size in ipfw dummynet > larger then 100 > slots, but I can't do so since ipfw always tells me that > the maximum is > 100. > Is there any chance to increase the queue size? > I could only find a thread [1] from 2006 about this. > > Thanks a lot for any hints or help! > > > Regards, > Sebastian It looks to be hard-coded, so I'd suggest changing it to a variable or macro. There's only about 10 instances so its not much work. Barney From sebastian.mellmann at net.t-labs.tu-berlin.de Fri May 29 16:24:34 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Fri May 29 16:24:41 2009 Subject: ipfw dummynet queue size limitations In-Reply-To: <130182.52355.qm@web63908.mail.re1.yahoo.com> References: <130182.52355.qm@web63908.mail.re1.yahoo.com> Message-ID: <1243614268.28837.8.camel@kingsnake.net.t-labs.tu-berlin.de> On Fri, 2009-05-29 at 08:52 -0700, Barney Cordoba wrote: > > > --- On Fri, 5/29/09, Sebastian Mellmann wrote: > > > From: Sebastian Mellmann > > Subject: ipfw dummynet queue size limitations > > To: freebsd-net@freebsd.org > > Date: Friday, May 29, 2009, 4:37 AM > > Hi everyone! > > > > I've already asked this one the ipfw list, but maybe > > someone here got a > > hint for me. > > I'm trying to configure the queue size in ipfw dummynet > > larger then 100 > > slots, but I can't do so since ipfw always tells me that > > the maximum is > > 100. > > Is there any chance to increase the queue size? > > I could only find a thread [1] from 2006 about this. > > > > Thanks a lot for any hints or help! > > > > > > Regards, > > Sebastian > > It looks to be hard-coded, so I'd suggest changing it to a variable or > macro. There's only about 10 instances so its not much work. > So I need to change ip_dummynet.c and ip_fw2.c? Cheers, Sebastian > Barney > > > From smallpox at gmail.com Fri May 29 17:24:54 2009 From: smallpox at gmail.com (smallpox) Date: Fri May 29 17:25:00 2009 Subject: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ? In-Reply-To: <20090529165809.O23256@beagle.kn.op.dlr.de> References: <4A1F2706.2080304@gmail.com> <20090529142757.X22933@beagle.kn.op.dlr.de> <4A1FF0B1.8040209@gmail.com> <20090529165809.O23256@beagle.kn.op.dlr.de> Message-ID: <4A201A4D.1000301@gmail.com> me: is it supposed to be sequential ? me: from low to high ? netsnmpguy: no, it's the difference between on poll period to the next he did admit that he doesn't monitor high speed networks so he can't be too sure. ifconfig bce0 -tso bce0: flags=8843 metric 0 mtu 1500 options=bb [10:13:21 5/29] IF-MIB::ifInOctets.1 /1 sec: 157715996 [10:13:21 5/29] IF-MIB::ifOutOctets.1 /1 sec: 161365331 [10:13:36 5/29] IF-MIB::ifInOctets.1 /1 sec: 181177076 [10:13:36 5/29] IF-MIB::ifOutOctets.1 /1 sec: 172743760 [10:13:51 5/29] IF-MIB::ifInOctets.1 /1 sec: 173974646 [10:13:51 5/29] IF-MIB::ifOutOctets.1 /1 sec: 179701472 and [10:21:06 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 189562690 [10:21:06 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 193086153 [10:21:21 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 162102286 [10:21:21 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 174412564 [10:21:36 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 163761580 [10:21:36 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 178587294 then i kill snmpd and launch bsnmpd.. and i know it's growing but probably just like everything else, it's not going to be at 90mbit already. [10:21:52 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 824582 [10:21:52 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 726172 [10:21:52 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 810400 [10:21:52 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 714542 [10:21:53 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8073610 [10:21:53 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 8263915 [10:21:54 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8950868 [10:21:54 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10064090 [10:21:55 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8734086 [10:21:55 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9477418 [10:21:56 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8764476 [10:21:56 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9738831 [10:21:57 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 9398614 [10:21:57 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9894332 [10:21:58 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 9497888 [10:21:58 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10337890 [10:21:59 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10057064 [10:21:59 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10657596 [10:22:00 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10379198 [10:22:00 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 11772401 [10:22:01 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10863412 [10:22:01 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 12284506 [10:22:02 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10204962 [10:22:02 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10745774 bsnmpd does it every second. also, as far as this " options=bb" jumbo is disabled on the switch. in comparison to another gigabit, (em0) on that switch. options=9b they're both at MTU 1500 though. thanks Harti Brandt wrote: > On Fri, 29 May 2009, smallpox wrote: > > s>well, from what im told by snmp people, it's what's happening at that time, so > s>up and down is normal... but not at the rate that the non-working one is > s>going. and this one's upload and download are spread out normallly, 24 mbit > s>out, 2mbit in... > s> > s>current figures on the messed up system: > s> > s>[07:25:32 5/29] IF-MIB::ifInOctets.1 /1 sec: 238914024 > s>[07:25:32 5/29] IF-MIB::ifOutOctets.1 /1 sec: 223977573 > s>[07:25:47 5/29] IF-MIB::ifInOctets.1 /1 sec: 235054494 > s>[07:25:47 5/29] IF-MIB::ifOutOctets.1 /1 sec: 222830449 > s> > s>one of the differences between bsnmpd and net-snmpd is net-snmpd updates every > s>15 sec, anyway. see how the in/out are so close? that's totally off. > s> > s>the driver in question is bce... im not sure > > Hmm. Why would these numbers go up and down? As I understand it they > should go up and wrap at either 32-bit or 64-bit. There are only two cases > when they go down: a wrap or a discontinuity, which would be recorded in > ifCounterDiscontinuityTime. > > Just to check: could you please disable TSO on the interface and look what > it does? > > harti > > s>Harti Brandt wrote: > s>> On Thu, 28 May 2009, smallpox wrote: > s>> > s>> s>hey guys, i've read > s>> s> > s>> > s>> [SNIP] > s>> > s>> s> > s>> s>in comparison to an intel em.. 32bit, it's linked at a gigabit though.. > s>> but no > s>> s>heavy traffic there. > s>> s> > s>> s>--BEGIN WORKING > s>> s>IF-MIB::ifInOctets.1 /15 sec: 1932426 > s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24270520 > s>> s>IF-MIB::ifInOctets.1 /15 sec: 2199107 > s>> s>IF-MIB::ifOutOctets.1 /15 sec: 28672350 > s>> s>IF-MIB::ifInOctets.1 /15 sec: 2049073 > s>> s>IF-MIB::ifOutOctets.1 /15 sec: 22716321 > s>> s>IF-MIB::ifInOctets.1 /15 sec: 2036279 > s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24361972 > s>> s>IF-MIB::ifInOctets.1 /15 sec: 2571021 > s>> s>IF-MIB::ifOutOctets.1 /15 sec: 32539047 > s>> s>IF-MIB::ifInOctets.1 /15 sec: 2416155 > s>> s>IF-MIB::ifOutOctets.1 /15 sec: 30571680 > s>> s>IF-MIB::ifInOctets.1 /15 sec: 2583795 > s>> s>IF-MIB::ifOutOctets.1 /15 sec: 35712392 > s>> s>IF-MIB::ifInOctets.1 /15 sec: 2665891 > s>> s>IF-MIB::ifOutOctets.1 /15 sec: 34761228 > s>> s>IF-MIB::ifInOctets.1 /15 sec: 2249559 > s>> s>IF-MIB::ifOutOctets.1 /15 sec: 27438273 > s>> s> > s>> s>--END WORKING > s>> > s>> Do I get it wrong or do the 32-bit counters also go up and down? Given that > s>> bsnmpd just retrieves the values from the kernel and sends them over SNMP > s>> without looking at the values (for the 32-bit counters) this looks rather > s>> like a problem in the kernel/driver. Do these drivers perhaps use multiple > s>> threads for receiving? > s>> > s>> harti > s>> > s>> > s> > s> > > From hartmut.brandt at dlr.de Fri May 29 18:56:33 2009 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Fri May 29 18:56:39 2009 Subject: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ? In-Reply-To: <4A201A4D.1000301@gmail.com> References: <4A1F2706.2080304@gmail.com> <20090529142757.X22933@beagle.kn.op.dlr.de> <4A1FF0B1.8040209@gmail.com> <20090529165809.O23256@beagle.kn.op.dlr.de> <4A201A4D.1000301@gmail.com> Message-ID: <20090529204903.E23335@beagle.kn.op.dlr.de> On Fri, 29 May 2009, smallpox wrote: s>me: is it supposed to be sequential ? s>me: from low to high ? s>netsnmpguy: no, it's the difference between on poll period to the next The value of ifOutOctets is not the difference between poll periods but it is just the polled value of the octets that are sent. If you make sure that your poll period is short enough (bsnmpd tries to make this sure for the 64-bit counters by adjusting its own poll interval to the speed of the fastest network). Of course it will wrap, but that's the only time it can go down (except for discontinuities which happen if you restart the daemon or the OS). So if you have, for example, a gigabit interface, the output octet counter wraps at minimum every 35 seconds. If you poll every second you should see the counter going down not more than every 35 polls. So what are the values you are printing below? The differences between two polls or the poll values? harti s> s>he did admit that he doesn't monitor high speed networks so he can't be too s>sure. s> s>ifconfig bce0 -tso s> s>bce0: flags=8843 metric 0 mtu 1500 s> options=bb s> s> s> s>[10:13:21 5/29] IF-MIB::ifInOctets.1 /1 sec: 157715996 s>[10:13:21 5/29] IF-MIB::ifOutOctets.1 /1 sec: 161365331 s>[10:13:36 5/29] IF-MIB::ifInOctets.1 /1 sec: 181177076 s>[10:13:36 5/29] IF-MIB::ifOutOctets.1 /1 sec: 172743760 s>[10:13:51 5/29] IF-MIB::ifInOctets.1 /1 sec: 173974646 s>[10:13:51 5/29] IF-MIB::ifOutOctets.1 /1 sec: 179701472 s> s>and s> s>[10:21:06 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 189562690 s>[10:21:06 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 193086153 s>[10:21:21 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 162102286 s>[10:21:21 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 174412564 s>[10:21:36 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 163761580 s>[10:21:36 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 178587294 s> s>then i kill snmpd and launch bsnmpd.. and i know it's growing but probably s>just like everything else, it's not going to be at 90mbit already. s> s>[10:21:52 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 824582 s>[10:21:52 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 726172 s>[10:21:52 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 810400 s>[10:21:52 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 714542 s>[10:21:53 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8073610 s>[10:21:53 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 8263915 s>[10:21:54 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8950868 s>[10:21:54 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10064090 s>[10:21:55 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8734086 s>[10:21:55 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9477418 s>[10:21:56 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8764476 s>[10:21:56 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9738831 s>[10:21:57 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 9398614 s>[10:21:57 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9894332 s>[10:21:58 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 9497888 s>[10:21:58 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10337890 s>[10:21:59 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10057064 s>[10:21:59 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10657596 s>[10:22:00 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10379198 s>[10:22:00 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 11772401 s>[10:22:01 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10863412 s>[10:22:01 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 12284506 s>[10:22:02 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10204962 s>[10:22:02 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10745774 s> s> s>bsnmpd does it every second. s> s>also, as far as this " s>options=bb" s> s>jumbo is disabled on the switch. s> s>in comparison to another gigabit, (em0) on that switch. s>options=9b s> s>they're both at MTU 1500 though. s> s>thanks s> s>Harti Brandt wrote: s>> On Fri, 29 May 2009, smallpox wrote: s>> s>> s>well, from what im told by snmp people, it's what's happening at that s>> time, so s>> s>up and down is normal... but not at the rate that the non-working one is s>> s>going. and this one's upload and download are spread out normallly, 24 s>> mbit s>> s>out, 2mbit in... s>> s> s>> s>current figures on the messed up system: s>> s> s>> s>[07:25:32 5/29] IF-MIB::ifInOctets.1 /1 sec: 238914024 s>> s>[07:25:32 5/29] IF-MIB::ifOutOctets.1 /1 sec: 223977573 s>> s>[07:25:47 5/29] IF-MIB::ifInOctets.1 /1 sec: 235054494 s>> s>[07:25:47 5/29] IF-MIB::ifOutOctets.1 /1 sec: 222830449 s>> s> s>> s>one of the differences between bsnmpd and net-snmpd is net-snmpd updates s>> every s>> s>15 sec, anyway. see how the in/out are so close? that's totally off. s>> s> s>> s>the driver in question is bce... im not sure s>> s>> Hmm. Why would these numbers go up and down? As I understand it they should s>> go up and wrap at either 32-bit or 64-bit. There are only two cases when s>> they go down: a wrap or a discontinuity, which would be recorded in s>> ifCounterDiscontinuityTime. s>> s>> Just to check: could you please disable TSO on the interface and look what s>> it does? s>> s>> harti s>> s>> s>Harti Brandt wrote: s>> s>> On Thu, 28 May 2009, smallpox wrote: s>> s>> s>> s>hey guys, i've read s>> s>> s> s>> s>> s>> [SNIP] s>> s>> s>> s> s>> s>> s>in comparison to an intel em.. 32bit, it's linked at a gigabit s>> though.. s>> s>> but no s>> s>> s>heavy traffic there. s>> s>> s> s>> s>> s>--BEGIN WORKING s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 1932426 s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24270520 s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2199107 s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 28672350 s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2049073 s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 22716321 s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2036279 s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24361972 s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2571021 s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 32539047 s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2416155 s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 30571680 s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2583795 s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 35712392 s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2665891 s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 34761228 s>> s>> s>IF-MIB::ifInOctets.1 /15 sec: 2249559 s>> s>> s>IF-MIB::ifOutOctets.1 /15 sec: 27438273 s>> s>> s> s>> s>> s>--END WORKING s>> s>> s>> Do I get it wrong or do the 32-bit counters also go up and down? s>> Given that s>> s>> bsnmpd just retrieves the values from the kernel and sends them over s>> SNMP s>> s>> without looking at the values (for the 32-bit counters) this looks s>> rather s>> s>> like a problem in the kernel/driver. Do these drivers perhaps use s>> multiple s>> s>> threads for receiving? s>> s>> s>> harti s>> s>> s>> s> s>> s> s>> s>> s> s> From jd at ods.org Fri May 29 19:29:41 2009 From: jd at ods.org (Jason DiCioccio) Date: Fri May 29 19:30:14 2009 Subject: pktgen udp doesn't work over freebsd gateway In-Reply-To: References: Message-ID: Is 192.168.7.1 the freebsd gateway? Because that would explain it. You need to send to the linux box's IP On 2009-05-29, Sebastian Mellmann wrote: > Hello everyone! > > I'm using 'pktgen' [1] under linux to generate packets. > > > My topology looks like this: > > (linux-box #1) <---> (em0 - freebsd-gateway - em1) <---> (linux-box #2) > > I want to send packets from linux-box #1 to linux-box #2 over the free-bsd > gateway. > The problem is that I can see the packets on em0, but not on em1. > I assume there's a configuration missing on the BSD machine, because it > seems it just drops the packets hence doesn't forward them to linux-box > #2. > > rc.conf: > gateway_enable="YES" > keymap="german.iso" > sshd_enable="YES" > firewall_enable="YES" > firewall_type="OPEN" > firewall_logging="YES" > > Default option for ipfw is to accept packets. > > tcpdump em0: > 11:42:36.334798 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto > UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length > 18 > 11:42:36.334802 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto > UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length > 18 > 11:42:36.334805 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto > UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length > 18 > 11:42:36.334807 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto > UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length > 18 > 11:42:36.334810 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto > UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length > 18 > 11:42:36.334813 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto > UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length > 18 > 11:42:36.334816 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto > UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length > 18 > 11:42:36.334819 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto > UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length > 18 > 11:42:36.334821 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto > UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length > 18 > 11:42:36.334824 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto > UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length > 18 > > tcpdump em1: > nothing. > > > Is there any sysctl variable that needs to be set? > > Connectivity between the boxes is definately working (tested with ping, > iperf etc.). > > > Regards, > Sebastian > > [1] http://www.linuxfoundation.org/en/Net:Pktgen > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Sent from my mobile device From sebastian.mellmann at net.t-labs.tu-berlin.de Fri May 29 19:44:07 2009 From: sebastian.mellmann at net.t-labs.tu-berlin.de (Sebastian Mellmann) Date: Fri May 29 19:44:15 2009 Subject: pktgen udp doesn't work over freebsd gateway In-Reply-To: References: Message-ID: <4A203B08.7010807@net.t-labs.tu-berlin.de> > Is 192.168.7.1 the freebsd gateway? Because that would explain it. > You need to send to the linux box's IP > > No, 192.168.7.1 is the linux box. Cheers, Sebastian > On 2009-05-29, Sebastian Mellmann > wrote: > >> Hello everyone! >> >> I'm using 'pktgen' [1] under linux to generate packets. >> >> >> My topology looks like this: >> >> (linux-box #1) <---> (em0 - freebsd-gateway - em1) <---> (linux-box #2) >> >> I want to send packets from linux-box #1 to linux-box #2 over the free-bsd >> gateway. >> The problem is that I can see the packets on em0, but not on em1. >> I assume there's a configuration missing on the BSD machine, because it >> seems it just drops the packets hence doesn't forward them to linux-box >> #2. >> >> rc.conf: >> gateway_enable="YES" >> keymap="german.iso" >> sshd_enable="YES" >> firewall_enable="YES" >> firewall_type="OPEN" >> firewall_logging="YES" >> >> Default option for ipfw is to accept packets. >> >> tcpdump em0: >> 11:42:36.334798 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto >> UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length >> 18 >> 11:42:36.334802 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto >> UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length >> 18 >> 11:42:36.334805 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto >> UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length >> 18 >> 11:42:36.334807 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto >> UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length >> 18 >> 11:42:36.334810 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto >> UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length >> 18 >> 11:42:36.334813 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto >> UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length >> 18 >> 11:42:36.334816 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto >> UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length >> 18 >> 11:42:36.334819 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto >> UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length >> 18 >> 11:42:36.334821 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto >> UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length >> 18 >> 11:42:36.334824 IP (tos 0x0, ttl 32, id 129, offset 0, flags [none], proto >> UDP (17), length 46) 192.168.5.1.9 > 192.168.7.1.9: [no cksum] UDP, length >> 18 >> >> tcpdump em1: >> nothing. >> >> >> Is there any sysctl variable that needs to be set? >> >> Connectivity between the boxes is definately working (tested with ping, >> iperf etc.). >> >> >> Regards, >> Sebastian >> >> [1] http://www.linuxfoundation.org/en/Net:Pktgen >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > > From atkin901 at yahoo.com Fri May 29 20:29:54 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Fri May 29 20:30:01 2009 Subject: pktgen udp doesn't work over freebsd gateway References: Message-ID: Sebastian Mellmann wrote: > Hello everyone! > > I'm using 'pktgen' [1] under linux to generate packets. > > My topology looks like this: > > (linux-box #1) <---> (em0 - freebsd-gateway - em1) <---> (linux-box #2) > > I want to send packets from linux-box #1 to linux-box #2 over the free-bsd > gateway. > The problem is that I can see the packets on em0, but not on em1. > I assume there's a configuration missing on the BSD machine, because it > seems it just drops the packets hence doesn't forward them to linux-box > #2. > > rc.conf: > gateway_enable="YES" > keymap="german.iso" > sshd_enable="YES" > firewall_enable="YES" > firewall_type="OPEN" > firewall_logging="YES" > > Default option for ipfw is to accept packets. >Connectivity between the boxes is definately working (tested with ping, >iperf etc.). Which connectivity is this? Through the freebsd box? If you can ping and get a reply through the box then there's something definitely up with the packets you are generating. I can see one problem with the packet trace you sent is the IP id is not changing. I don't use ipfw, but perhaps it cares about the udp checksum. Are you capturing all the packets? Is the freebsd box returning a icmp- error for your destination/packets? Try without the firewall and see if it works. -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From auryn at zirakzigil.org Fri May 29 21:48:02 2009 From: auryn at zirakzigil.org (Giulio Ferro) Date: Fri May 29 21:48:08 2009 Subject: NAT-T on current 8 Message-ID: <4A205679.5030406@zirakzigil.org> Hi everybody. As far as I know the natt patch hasn't been included in the source tree yet. This fact notwithstanding, is there a patch I can download and apply manually? I need it rather badly... Thanks. From sullrich at gmail.com Fri May 29 21:57:07 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Fri May 29 21:57:13 2009 Subject: NAT-T on current 8 In-Reply-To: <4A205679.5030406@zirakzigil.org> References: <4A205679.5030406@zirakzigil.org> Message-ID: On Fri, May 29, 2009 at 5:41 PM, Giulio Ferro wrote: > As far as I know the natt patch hasn't been included in the source tree yet. > This fact notwithstanding, is there a patch I can download and apply > manually? I need it rather badly... There sure is. bz@ sent this over for testing and we are using it in pfSense.. Works great! http://people.freebsd.org/~bz/20090523-04-natt.diff ... Please do follow up with feedback after you deploy. You will most likely also want the latest ipsec-tools cvs port + a few patches that we are also testing in pfSense... works great! http://cvs.pfsense.com/~sullrich/ipsec-tools-devel.zip ... This is a port file of a recent ipsec-tools cvs checkout + a few patches provided by vanhu@, extract to /usr/ports/security/ and make install. The NATT patch is slated to hit the FreeBSD tree soon so please do report back your findings. Thanks, Scott From auryn at zirakzigil.org Fri May 29 22:02:50 2009 From: auryn at zirakzigil.org (Giulio Ferro) Date: Fri May 29 22:03:21 2009 Subject: NIC teaming with VLANs does't work In-Reply-To: <4A1E8612.9000802@unsane.co.uk> References: <4A1E801C.2090803@zirakzigil.org> <4A1E8612.9000802@unsane.co.uk> Message-ID: <4A2054F1.8070406@zirakzigil.org> Vincent Hoffman wrote: > Possibly try lagg(4) instead? this supports fec and lacp. > > Thanks, I'll try as soon as I'm able... From linimon at FreeBSD.org Sat May 30 01:03:49 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat May 30 01:04:00 2009 Subject: kern/135067: [patch][fib] Incorrect KASSERTs in sys/net/route.c Message-ID: <200905300103.n4U13mko040190@freefall.freebsd.org> Synopsis: [patch][fib] Incorrect KASSERTs in sys/net/route.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 30 01:03:40 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135067 From julian at elischer.org Sat May 30 02:20:05 2009 From: julian at elischer.org (Julian Elischer) Date: Sat May 30 02:20:11 2009 Subject: kern/135067: [patch] [fib] Incorrect KASSERTs in sys/net/route.c Message-ID: <200905300220.n4U2K4Nn092970@freefall.freebsd.org> The following reply was made to PR kern/135067; it has been noted by GNATS. From: Julian Elischer To: bug-followup@FreeBSD.org, mjguzik@gmail.com Cc: Subject: Re: kern/135067: [patch] [fib] Incorrect KASSERTs in sys/net/route.c Date: Fri, 29 May 2009 18:58:48 -0700 if you have 16 fibs then valid values are 0,1,2,.....14,15 if fibnum == rt_numfibs then that is an error. thus in setfib... if uap->numfbs is 16 OR GREATER it is and EINVAL and the kasserts in route.c need to check that fibnum is LESS THAN rt_numfibs. so this looks correct to me.. what makes you think there is an error? From mjguzik at gmail.com Sat May 30 08:50:03 2009 From: mjguzik at gmail.com (Mateusz Guzik) Date: Sat May 30 08:50:11 2009 Subject: kern/135067: [patch] [fib] Incorrect KASSERTs in sys/net/route.c Message-ID: <200905300850.n4U8o3mq024703@freefall.freebsd.org> The following reply was made to PR kern/135067; it has been noted by GNATS. From: Mateusz Guzik To: Julian Elischer Cc: bug-followup@freebsd.org Subject: Re: kern/135067: [patch] [fib] Incorrect KASSERTs in sys/net/route.c Date: Sat, 30 May 2009 10:42:25 +0200 On Sat, May 30, 2009 at 3:58 AM, Julian Elischer wrot= e: > if you have 16 fibs then valid values are 0,1,2,.....14,15 > > if fibnum =3D=3D rt_numfibs then that is an error. > > thus in setfib... if uap->numfbs is 16 OR GREATER =A0it is and EINVAL > > and the kasserts in route.c need to check that fibnum is =A0LESS THAN > rt_numfibs. > That's correct. > > what makes you think there is an error? > I somehow misread that KASSERT as triggered only when fibnum > rt_numfibs. I guess it was too late at night. :) Sorry for the noise. -- Mateusz Guzik From kalinoj1 at iem.pw.edu.pl Sat May 30 11:09:48 2009 From: kalinoj1 at iem.pw.edu.pl (Jedrzej Kalinowski) Date: Sat May 30 11:09:55 2009 Subject: Bridging and stp question In-Reply-To: <4A1FBE3E.9080203@incunabulum.net> References: <4A1EE0F5.1070909@iem.pw.edu.pl> <4A1EF6FB.7080306@iem.pw.edu.pl> <4A1FBE3E.9080203@incunabulum.net> Message-ID: <4A2114BD.2050809@iem.pw.edu.pl> Bruce Simpson pisze: > Jedrzej Kalinowski wrote: >> pluknet pisze: >> >>> 2009/5/28 Jedrzej Kalinowski : >>> >>>> Is there any way to configure the bridge to add stp protocol to any >>>> added (via ifconfig bridgeX addm ifX) member interface - so to change >>>> the default behaviour? Or specifying it explicitly is unavoidable? >>>> >>>> >>> Let me clarify some. Did I understand you correctly >>> that `ifconfig bridge0 addm ifX stp ifX` doesn't fit you needs? >>> >>> >> >> Well, it works fine. >> >> It just would be more comfortable for me to do just: >> ifconfig bridge0 addm ifX >> >> and have bridge0 configured to add stp proto to each member interface as >> a default action. >> >> It would allow me to configure spanning tree on specific bridge >> globally, with no need to do it for each member interface. >> > > Can't you just put this command in a qemu-ifup script? > If not, can you clarify why it does not work for you? > > thanks, > BMS > Yes, I can - I do it already. I was just wondering if it was possible to change default behavior, if not it is not an issue/bug with if_bridge. I can use it and it works just fine. It's just about convenience. Thanks -- J?drzej Kalinowski From onemda at gmail.com Sat May 30 13:23:46 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sat May 30 13:23:52 2009 Subject: Problem/freezes with if_bwi and firmware In-Reply-To: <4A07D68D.9090006@entel.upc.edu> References: <4A07D68D.9090006@entel.upc.edu> Message-ID: <3a142e750905300623i2aac1414u9396e07b278157bd@mail.gmail.com> On 5/11/09, Gustau Perez wrote: > > Hi, > > I'm using a Broadcom BCM4312 with i386 FreeBSD-8.0 updated May 08 > 2009. Ports up to date. Using net/bwi-firmware-kmod. Loading > first bwi_v3_ucode and then if_bwi. > > When starting the supplicant, it associates fine and it works for a > period of time. From time to time I start to lose signal, I'm my log I > can see the following message : > > May 11 08:42:51 gusiport kernel: bwi0: firmware rev 0x0127, > patch level 0x000e > May 11 08:42:51 gusiport kernel: bwi0: bwi_intr: intr PHY TX > error > > Many of those messages per second. This is the first problem with > if_bwi. It forces me to restart by hand the wlan1 device associated to > bwi0. And here comes the freeze (the second problem I encountered). If I > try restarting like this : > > /etc/rc.d/netif stop wlan1 && /etc/rc.d/netif start wlan1 > > it works (until the PHY TX error appears againg). If I try like : > > /etc/rc.d/netif restart > > or if I try : > > /etc/rc.d/netif stop bwi0 > > the machine freezes. If i try to kldunload the module while in use > (if there's a wlan device created) the machine freezes too. It can be > unloaded only if there is not any wlan associated to the bwi device. Is this mini-pci card? (pciconf -lv) -- Paul From linimon at FreeBSD.org Sun May 31 04:18:24 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun May 31 04:18:36 2009 Subject: kern/135091: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE Message-ID: <200905310418.n4V4INQa023371@freefall.freebsd.org> Synopsis: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun May 31 04:18:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135091 From smallpox at gmail.com Sun May 31 05:00:07 2009 From: smallpox at gmail.com (smallpox) Date: Sun May 31 05:00:13 2009 Subject: kern/135091: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE Message-ID: <200905310500.n4V506Qi053262@freefall.freebsd.org> The following reply was made to PR kern/135091; it has been noted by GNATS. From: smallpox To: bug-followup@FreeBSD.org, hunreal@gmail.com, Harti Brandt Cc: Subject: Re: kern/135091: [bce] if_bce inbound traffic bytes counter is incorrect in 7.2-RELEASE Date: Sat, 30 May 2009 21:27:01 -0700 i actually complained about this a few days ago and harti was helping me.. http://lists.freebsd.org/pipermail/freebsd-net/2009-May/022131.html hunreal, can you verify any packet loss? i'm having 0.5% to 2% i just got the identical system up at the office, it's running 7.1-stable.. numbers look good but it was on 100mbit, i ran there to put it on gigabit. thanks. From bzeeb-lists at lists.zabbadoz.net Sun May 31 13:50:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun May 31 13:50:15 2009 Subject: NAT-T on current 8 In-Reply-To: References: <4A205679.5030406@zirakzigil.org> Message-ID: <20090531134541.H3234@maildrop.int.zabbadoz.net> On Fri, 29 May 2009, Scott Ullrich wrote: Hi Giulio, > On Fri, May 29, 2009 at 5:41 PM, Giulio Ferro wrote: >> As far as I know the natt patch hasn't been included in the source tree yet. >> This fact notwithstanding, is there a patch I can download and apply >> manually? I need it rather badly... > > There sure is. bz@ sent this over for testing and we are using it in > pfSense.. Works great! > > http://people.freebsd.org/~bz/20090523-04-natt.diff ... Please do > follow up with feedback after you deploy. > > You will most likely also want the latest ipsec-tools cvs port + a few > patches that we are also testing in pfSense... works great! > > http://cvs.pfsense.com/~sullrich/ipsec-tools-devel.zip ... This is a > port file of a recent ipsec-tools cvs checkout + a few patches > provided by vanhu@, extract to /usr/ports/security/ and make install. > > The NATT patch is slated to hit the FreeBSD tree soon so please do > report back your findings. Yes, in case you find any positiv or negative things we'd be happy to hear back from you - or anyone else who's going to give it a try. /bz -- Bjoern A. Zeeb The greatest risk is not taking one.