From jdp at elvis.rowan.edu Sat Nov 1 15:15:36 2008 From: jdp at elvis.rowan.edu (Joe Pellegrino) Date: Sat Nov 1 15:15:43 2008 Subject: A netgraph question. Message-ID: OK so here it goes. I actually have two seperate questions involving netgraph, I am new to this subject so please bare with me. If there is a better way to achieve these goals too, please suggest them but I think netgraph is the way to go. The first part involves allowing a userland program to communicate with a kernel module, similar to how netlink works in Linux. The second part involves intercepting network packets and possibly manipulating them before they are allowed to proceed, similar to how netfilter works. I believe I can do both of these with the netgraph (ng_socket and possibly ng_ether). I haven't looked closely at ng_ether yet so I'll focus on ng_socket. I have been able to create a ng_socket (Control and Data) using the socket call as described in "All About NetGraphs" and the man page. I've also been able to 'name' the node using bind. I was able to verify this using ngctl. I know (from the man page) I should eventually be able to send/receive using the sendto/recvfrom functions once the connection is established. But beyond this I don't know how to proceed. So the question is what are the next steps. For example: Although I see a named netgraph node there are no hooks. ng_socket says it supports an arbitrary number of hooks so how do I create the hooks? Then of course how do I connect them. Of course I realize that I proabably need to create a node on the kernel side so which type of netgraph node would be suggested? How is it created and then hooked to the ng_socket? Again I am looking to allow some IPC between a userland program and a kernel module similar to the Linux netlink. I've been through most man pages and can't seem to find a lot of good documentation or example code so I am hoping to get some pointers here. BTW If this is the wrong list please directly to the right place to ask. Thanks in advance. ---jdp From julian at elischer.org Sat Nov 1 17:35:17 2008 From: julian at elischer.org (Julian Elischer) Date: Sat Nov 1 17:35:25 2008 Subject: A netgraph question. In-Reply-To: References: Message-ID: <490CEF11.4010007@elischer.org> Joe Pellegrino wrote: > > OK so here it goes. I actually have two seperate questions involving > netgraph, I am new to this subject so please bare with me. If there is a > better way to achieve these goals too, please suggest them but I think > netgraph is the way to go. > I'll try answer your questions.. > The first part involves allowing a userland program to communicate with > a kernel module, similar to how netlink works in Linux. The second part > involves intercepting network packets and possibly manipulating them > before they are allowed to proceed, similar to how netfilter works. I > believe I can do both of these with the netgraph (ng_socket and possibly > ng_ether). I haven't looked closely at ng_ether yet so I'll focus on > ng_socket. > > I have been able to create a ng_socket (Control and Data) using the > socket call as described in "All About NetGraphs" and the man page. I've > also been able to 'name' the node using bind. I was able to verify this > using ngctl. I know (from the man page) I should eventually be able to > send/receive using the sendto/recvfrom functions once the connection is > established. But beyond this I don't know how to proceed. So the > question is what are the next steps. For example: > > Although I see a named netgraph node there are no hooks. ng_socket says > it supports an arbitrary number of hooks so how do I create the hooks? > Then of course how do I connect them. Hooks are created on demand.. you need to send a 'connect' or 'mkpeer' message to the node(s) on which you want t script level, you just use the ngctl program to do it for you. Hooks are always made in pairs. so you need two nodes to connect. The mkpeer message does this for you, and creates a new node and connects them together by two hooks of the names you specify. Have you looked at the sample netgraph scripts in /usr/share/examples/netgraph? > > Of course I realize that I proabably need to create a node on the kernel > side so which type of netgraph node would be suggested? How is it > created and then hooked to the ng_socket? for fun you could use the ng_echo node type which would send everything you want back to you.. Alternatively when you kldload the ng-ether node type, then all the ethernets will grow nodes to match them so you can connect to them directly. You could connect an ng_bpf (packet filter) node to the ng_ether node and pass specific packets only on to the socket. I'm not sure if teh bpf filter assumes it has the whole packet or just the IP packet, but assuming your interface was em0, so you could do something like: # hook the 'lower' hook of em0 to the bpf filter. ngctl mkpeer 'em0' bpf lower input #name the bpf node so we can reference it easily ngctl name em0.lower filter # connect the upper part of the filter to the ethernet # so that packets not accepted are sent on as before ngctl connect em0 filter upper nomatch # we need to connect the 'match' hook of the filter to something # that we can connect to later so use a 'tee' node as a paperweight. ngctl mkpeer filter tee match left ngctl name filter.match paperweight # now program the bpf node's 'input' hook to filter packets # as shown in the ng_bpf man page [steal code from ng_bpf man page] # program the 'match' hook with a null program to pass it's packets # (outgoing packets) straight back to 'lower' [steal code from ng_bpf man page] # now connect to the 'right' hook of the tee # to get output. nghook -a paperweight right you should now have hex encoded output of all packets you have selected by the bpf filter. the weakness of this is that I'm not sure if the ng_bpf node handles ethernet packets.. yo may need ot use some other node.. if you want to write your own node, start with the code in /usr/src/sys/netgraph/ng_sample.c to compile it, go to /usr/src/sys/modules/netgraph and copy one of the existing directories modify the makefile to reference you new file and use 'make' > > Again I am looking to allow some IPC between a userland program and a > kernel module similar to the Linux netlink. I've been through most man > pages and can't seem to find a lot of good documentation or example code > so I am hoping to get some pointers here. BTW If this is the wrong list > please directly to the right place to ask. Thanks in advance. not sure what netlink does.. (will look on google :-) > > ---jdp > _______________________________________________ > 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 brian.mcginty at gmail.com Sat Nov 1 18:13:16 2008 From: brian.mcginty at gmail.com (Brian McGinty) Date: Sat Nov 1 18:13:23 2008 Subject: ixgbe vs mxge In-Reply-To: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> Message-ID: <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> I don't know nothing about mxge so I can't comment, but I know that FreeBSD ixgbe driver is not even close to that of the Linux version. I switched to Linux just for ixgbe as our network was being standardized on 10G, and I think that's the best bet. The Linux version of the driver is actively worked on and I got a lot of help and bug fixes from the maintainers of the driver, whereas the FreeBSD driver is hopelessly neglected and broken. Brian On Tue, Oct 28, 2008 at 11:26 PM, Mihail Balikov wrote: > Hi, > > I would like to setup 10gbit bridge on FreeBSD7 , but I'm little bit > confused which vendor to choose for the NICs. > Can you send me some feed back? > > regards, > Mihail Balikov > _______________________________________________ > 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 kmacy at freebsd.org Sat Nov 1 18:18:04 2008 From: kmacy at freebsd.org (Kip Macy) Date: Sat Nov 1 18:18:35 2008 Subject: ixgbe vs mxge In-Reply-To: <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> Message-ID: <3c1674c90811011818m6a6bfeb6o1973aed13813b845@mail.gmail.com> As a point of reference for fellow readers: http://www.google.com/search?hl=en&q=brian.mcginty+freebsd&btnG=Google+Search&aq=f&oq= On Sun, Nov 2, 2008 at 12:46 AM, Brian McGinty wrote: > I don't know nothing about mxge so I can't comment, but I know that > FreeBSD ixgbe driver is not even close to that of the Linux version. I > switched to Linux just for ixgbe as our network was being standardized > on 10G, and I think that's the best bet. The Linux version of the > driver is actively worked on and I got a lot of help and bug fixes > from the maintainers of the driver, whereas the FreeBSD driver is > hopelessly neglected and broken. > > Brian > > On Tue, Oct 28, 2008 at 11:26 PM, Mihail Balikov wrote: >> Hi, >> >> I would like to setup 10gbit bridge on FreeBSD7 , but I'm little bit >> confused which vendor to choose for the NICs. >> Can you send me some feed back? >> >> regards, >> Mihail Balikov >> _______________________________________________ >> 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 jdp at elvis.rowan.edu Sat Nov 1 18:21:27 2008 From: jdp at elvis.rowan.edu (Joe Pellegrino) Date: Sat Nov 1 18:21:33 2008 Subject: A netgraph question. In-Reply-To: <490CEF11.4010007@elischer.org> References: <490CEF11.4010007@elischer.org> Message-ID: On Sat, 1 Nov 2008, Julian Elischer wrote: > I'll try answer your questions.. > > Hooks are created on demand.. > you need to send a 'connect' or 'mkpeer' message to the node(s) > on which you want t script level, you just use the ngctl program > to do it for you. > > Hooks are always made in pairs. so you need two nodes to connect. > The mkpeer message does this for you, and creates a new node and connects > them together by two hooks of the names you specify. > > Have you looked at the sample netgraph scripts in > /usr/share/examples/netgraph? > Yep, I've looked at those but if I recall they are all scripts. I am looking for some C or C++ example. Basically on the userland side I have something like: #include <..> #include int main () { int s1 = socket (PF_NETGRAPH, SOCK_DGRAM, NG_CONTROL) int s2 = socket (PF_NETGRAPH, SOCK_DGRAM, NG_DATA) bind(...); } This gives me a node with a name, set with bind, of type socket and no hooks. The kernel module I don't have any netgraph code yet but I figure it will involve a set of calls similar to the userland program. So if I want to interact with the socket the userland program created, what kind of node do I create in the module? Another ng_socket or a ng_ksocket or something different. Then how do I go about connecting the two hooks? >> Of course I realize that I proabably need to create a node on the kernel >> side so which type of netgraph node would be suggested? How is it created >> and then hooked to the ng_socket? > > for fun you could use the ng_echo node type which would send everything you > want back to you.. > > Alternatively when you kldload the ng-ether node type, then all the ethernets > will grow nodes to match them so you can connect to them directly. > > You could connect an ng_bpf (packet filter) node to the ng_ether node > and pass specific packets only on to the socket. > I'll look into this for the other half of what I am playing with. I looked at bpf by itself and it seemed to me it made a copy of the packet, with the original continuing up the stack rather than diverting the packet. But I am getting ahead of myself. I'd like to get the userland <-> module part together first. :) And all the example code are scripts. Am I missing someting? >> pages and can't seem to find a lot of good documentation or example code so >> I am hoping to get some pointers here. BTW If this is the wrong list please >> directly to the right place to ask. Thanks in advance. > > not sure what netlink does.. > (will look on google :-) > Thanks for your help, there is a reasonable entry in the wiki about it. ---jdp From julian at elischer.org Sat Nov 1 19:14:33 2008 From: julian at elischer.org (Julian Elischer) Date: Sat Nov 1 19:14:40 2008 Subject: A netgraph question. In-Reply-To: References: <490CEF11.4010007@elischer.org> Message-ID: <490D0CFB.5040102@elischer.org> Joe Pellegrino wrote: > On Sat, 1 Nov 2008, Julian Elischer wrote: > >> I'll try answer your questions.. >> >> Hooks are created on demand.. >> you need to send a 'connect' or 'mkpeer' message to the node(s) >> on which you want t script level, you just use the ngctl program >> to do it for you. >> >> Hooks are always made in pairs. so you need two nodes to connect. >> The mkpeer message does this for you, and creates a new node and >> connects them together by two hooks of the names you specify. >> >> Have you looked at the sample netgraph scripts in >> /usr/share/examples/netgraph? >> > > Yep, I've looked at those but if I recall they are all scripts. I am > looking for some C or C++ example. Basically on the userland side I have > something like: > > #include <..> > #include > > int main () { > int s1 = socket (PF_NETGRAPH, SOCK_DGRAM, NG_CONTROL) > int s2 = socket (PF_NETGRAPH, SOCK_DGRAM, NG_DATA) > bind(...); > > } > > This gives me a node with a name, set with bind, of type socket and no > hooks. > > The kernel module I don't have any netgraph code yet but I figure it > will involve a set of calls similar to the userland program. So if I > want to interact with the socket the userland program created, what kind > of node do I create in the module? Another ng_socket or a ng_ksocket or > something different. Then how do I go about connecting the two hooks? > >>> Of course I realize that I proabably need to create a node on the >>> kernel side so which type of netgraph node would be suggested? How is >>> it created and then hooked to the ng_socket? >> >> for fun you could use the ng_echo node type which would send >> everything you want back to you.. >> >> Alternatively when you kldload the ng-ether node type, then all the >> ethernets will grow nodes to match them so you can connect to them >> directly. >> >> You could connect an ng_bpf (packet filter) node to the ng_ether node >> and pass specific packets only on to the socket. >> > > I'll look into this for the other half of what I am playing with. I > looked at bpf by itself and it seemed to me it made a copy of the > packet, with the original continuing up the stack rather than diverting > the packet. But I am getting ahead of myself. I'd like to get the > userland <-> module part together first. :) And all the example code are > scripts. Am I missing someting? have you done man 3 netgraph to look at the netgraph management library? for example programs, see: /usr/src/usr.sbin/nghook /usr/src/usr.sbin/ngctl /usr/ports/net/mpd (you'll need to download the sources with "make") > >>> pages and can't seem to find a lot of good documentation or example >>> code so I am hoping to get some pointers here. BTW If this is the >>> wrong list please directly to the right place to ask. Thanks in advance. >> >> not sure what netlink does.. >> (will look on google :-) >> > > Thanks for your help, there is a reasonable entry in the wiki about it. > > ---jdp From jfvogel at gmail.com Sun Nov 2 10:34:21 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Sun Nov 2 10:34:27 2008 Subject: ixgbe vs mxge In-Reply-To: <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> Message-ID: <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> You know I generally try to maintain courtesy and civility in my dealings with the community but this really ticks me off. I have stayed out of this thread because I figured it was only fair that those with obvious bias should do so. Hopelessly neglected and broken?? ...the driver is maintained by me, and I am in the same organization as the developers of the Linux driver. If anyone has real questions about my driver and our hardware you may contact me. Jack Vogel Sr. Network Engineer Intel Lan Access Division On Sat, Nov 1, 2008 at 5:46 PM, Brian McGinty wrote: > I don't know nothing about mxge so I can't comment, but I know that > FreeBSD ixgbe driver is not even close to that of the Linux version. I > switched to Linux just for ixgbe as our network was being standardized > on 10G, and I think that's the best bet. The Linux version of the > driver is actively worked on and I got a lot of help and bug fixes > from the maintainers of the driver, whereas the FreeBSD driver is > hopelessly neglected and broken. > > Brian > > On Tue, Oct 28, 2008 at 11:26 PM, Mihail Balikov > wrote: > > Hi, > > > > I would like to setup 10gbit bridge on FreeBSD7 , but I'm little bit > > confused which vendor to choose for the NICs. > > Can you send me some feed back? > > > > regards, > > Mihail Balikov > > _______________________________________________ > > 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 karl.triebes at gmail.com Sun Nov 2 11:24:18 2008 From: karl.triebes at gmail.com (Karl Triebes) Date: Sun Nov 2 11:24:24 2008 Subject: ixgbe vs mxge In-Reply-To: <3c1674c90811011818m6a6bfeb6o1973aed13813b845@mail.gmail.com> References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> <3c1674c90811011818m6a6bfeb6o1973aed13813b845@mail.gmail.com> Message-ID: <26a198490811021053u61d5a438tb03786868580ce51@mail.gmail.com> On Sat, Nov 1, 2008 at 5:18 PM, Kip Macy wrote: > As a point of reference for fellow readers: > > http://www.google.com/search?hl=en&q=brian.mcginty+freebsd&btnG=Google+Search&aq=f&oq= And your point is? From karl.triebes at gmail.com Sun Nov 2 11:31:25 2008 From: karl.triebes at gmail.com (Karl Triebes) Date: Sun Nov 2 11:31:32 2008 Subject: ixgbe vs mxge In-Reply-To: <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> Message-ID: <26a198490811021100y247296cen92dc290a9d60ce03@mail.gmail.com> Jack, On Sun, Nov 2, 2008 at 10:34 AM, Jack Vogel wrote: > You know I generally try to maintain courtesy and civility in my > dealings with the community but this really ticks me off. > > I have stayed out of this thread because I figured it was only > fair that those with obvious bias should do so. > > Hopelessly neglected and broken?? ...the driver is maintained by > me, and I am in the same organization as the developers of the > Linux driver. If anyone has real questions about my driver and > our hardware you may contact me. I didn't mean to offend you or your work in anyway, maybe ixgbe has turned around over the past few months. This is good news and hopefully you'll see wider adoption of ixgbe. Cheers, Brian From jdp at elvis.rowan.edu Sun Nov 2 14:38:05 2008 From: jdp at elvis.rowan.edu (Joe Pellegrino) Date: Sun Nov 2 14:38:12 2008 Subject: A netgraph question. In-Reply-To: <490D0CFB.5040102@elischer.org> References: <490CEF11.4010007@elischer.org> <490D0CFB.5040102@elischer.org> Message-ID: On Sat, 1 Nov 2008, Julian Elischer wrote: > Joe Pellegrino wrote: >> On Sat, 1 Nov 2008, Julian Elischer wrote: >> > have you done man 3 netgraph to look at the netgraph management library? > Looked at that today and I might be able to get something going. I tried to use the ng_echo node in a module. The code looked something like this: #include #include #include #include #include #include #include #include extern struct ng_type typestruct; static int event_handler(struct module *module, int event, void *arg) { int e = 0; /* Error, 0 for normal return status */ switch (event) { case MOD_LOAD: uprintf("Hello Free Software Magazine Readers! \n"); ng_newtype(&typestruct); break; case MOD_UNLOAD: uprintf("Bye Bye FSM reader, be sure to check http://freesoftwar emagazine.com !\n"); break; default: e = EOPNOTSUPP; /* Error, Operation Not Supported */ break; } return(e); } /* The second argument of DECLARE_MODULE. */ static moduledata_t hello_conf = { "hello_fsm", /* module name */ event_handler, /* event handler */ NULL /* extra data */ }; DECLARE_MODULE(hello_fsm, hello_conf, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); However, trying to load this module results in: # kldload ./hello_fsm.ko kldload: can't load ./hello_fsm.ko: No such file or directory So to start, how can I use ng_echo in a module? According to the man 4 of netgraph the ng_newtype should construct a new node right? And I presume once I get that module running and an ng_echo module loaded, I'll try to communicate with it from userspace but what about the above is incorrect? Thanks. :) ---jdp > for example programs, see: > /usr/src/usr.sbin/nghook > /usr/src/usr.sbin/ngctl > /usr/ports/net/mpd (you'll need to download the sources with "make") > > From andrew at modulus.org Sun Nov 2 15:51:59 2008 From: andrew at modulus.org (Andrew Snow) Date: Sun Nov 2 15:52:06 2008 Subject: ixgbe vs mxge In-Reply-To: <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> Message-ID: <490E3900.2080508@modulus.org> Jack Vogel wrote: > Hopelessly neglected and broken?? ...the driver is maintained by > me, and I am in the same organization as the developers of the > Linux driver. Hi Jack, Of course, most people in the community use the fruit of your labours on a daily basis and are pleased with the results. I have deployed many Pro/1000 cards at home and work using the em driver with great success, and I thank you again for your efforts in improving the state of the FreeBSD driver. I am curious about the ixgbe driver as I have never had a chance to play with any 10G hardware: is it as fast and reliable as the em-based 1G solution? - Andrew From pyunyh at gmail.com Sun Nov 2 20:01:12 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Nov 2 20:01:20 2008 Subject: re weird bug In-Reply-To: <200810311029.56471.freebsd-net@dino.sk> References: <200810300829.35980.freebsd-net@dino.sk> <200810302241.01863.freebsd-net@dino.sk> <20081031011125.GC82781@cdnetworks.co.kr> <200810311029.56471.freebsd-net@dino.sk> Message-ID: <20081103035908.GC94302@cdnetworks.co.kr> On Fri, Oct 31, 2008 at 10:29:55AM +0100, Milan Obuch wrote: > On Friday 31 October 2008 02:11:25 Pyun YongHyeon wrote: > > On Thu, Oct 30, 2008 at 10:41:01PM +0100, Milan Obuch wrote: > > > On Thursday 30 October 2008 11:26:56 Pyun YongHyeon wrote: > > > > On Thu, Oct 30, 2008 at 08:29:35AM +0100, Milan Obuch wrote: > > > > > Hi, > > > > > yesterday I csup'ped my 8-current sources on my MSI Wind netbook > > > > > (again) and tried to build new kernel. There is again a problem > > > > > with re interface. It just does not work, with following > > > > > > > > > > re0: port > > > > > 0xc000-0xc0ff mem 0xffd10000-0xffd10fff,0xffd00000-0xffd0ffff irq > > > > > 16 at device 0.0 on pci1 re0: Chip rev. 0x34800000 > > > > > re0: MAC rev. 0x00200000 > > > > > re0: PHY write failed > > > > > re0: PHY write failed > > > > > re0: MII without any phy! > > > > > device_attach: re0 attach returned 6 > > > > > > > [ snip ] > > > > > > > > > That's known issue for newer RealTek PCIe controllers. Would you > > > > please try the patch at the following URL? > > > > http://people.freebsd.org/~yongari/re/re.ephy.patch.20081021 > > > > > > > > Since it's not easy to reproduce this issue please make sure to > > > > (cold and warm) reboot several times until you can put confidence > > > > in the patch. > > > > > > I tried, but no change - with patch applied re still does not work > > > unless I boot with verbose logging, no matter whether I boot cold or > > > warm. > > > > Thanks for testing. If you look into patched if_re.c you can see a > > "#if 1" in function re_ephy_config(). How about changing it to > > "#if 0" to enable more aggresive reprogramming for EPHY register? > > I tried. Again, no change - rlphy not working normally, but everything works > when booting with verbose logging. > Hmm, I have no idea how verbosed booting can hide the issue. > If there is anything else I could test, let me know. Booting with verbose > logging is acceptable for me for now, so do not feel any pressure from my > side. I just like to test when something will be available for test. > I vaguely guess hardware was not properly initialized. How about this one? http://people.freebsd.org/~yongari/re/re.phy.patch.20081103 -- Regards, Pyun YongHyeon From bugmaster at FreeBSD.org Mon Nov 3 03:06:56 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 3 03:08:28 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200811031106.mA3B6u75010976@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/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 kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? 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: 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/126984 net [carp][patch] add carp userland notifications via devc 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 f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic 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 [in] Network: 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 f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr 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/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p 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/123881 net [tcp] Turning on TCP blackholing causes slow localhost 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 o 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/123200 net [netgraph] Server failure due to netgraph mpd and dhcp 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/123066 net [ipsec] [panic] kernel trap with ipsec 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 [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/122427 net [apm] [panic] apm and mDNSResponder cause panic during 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/122068 net [ppp] ppp can not set the correct interface with pptpd 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 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 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 [panic] gnugk causes kernel panic when closing UDP soc 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 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/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented 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 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/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat 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/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 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/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 bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a 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 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 conf/102502 net [patch] ifconfig name does't rename netgraph node in n 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/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/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 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 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/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/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 FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic 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/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 187 problems total. From jjfitzgerald at gmail.com Mon Nov 3 08:19:02 2008 From: jjfitzgerald at gmail.com (John Fitzgerald) Date: Mon Nov 3 08:19:08 2008 Subject: ipf / ipnat bad nat Message-ID: <5e49673f0811030751i292a80f4pf9ed6300ec46a504@mail.gmail.com> Hey all, I manage a pretty busy website and I've been perplexed by this problem for some time. ipnat -s shows something like this: mapped in 837904779 out 1055985985 added 79997334 expired 0 no memory 0 bad nat 500334 inuse 11764 rules 5 wilds 0 What troubles me is the "bad nat" that you see there. It goes up pretty quickly (hundreds per minute), especially during high traffic times. My ipnat.rules is pretty simple: #outgoing map bce0 192.168.1.0/24 -> 0.0.0.0/32 portmap tcp/udp auto map bce0 192.168.1.0/24 -> 0.0.0.0/32 #incoming rdr bce0 0.0.0.0/0 port 80 -> 192.168.1.100 port 80 tcp age 30 rdr bce0 0.0.0.0/0 port 443 -> 192.168.1.100 port 443 tcp age 30 And my ipf.rules is simple enough: # localhost pass in quick on lo0 all pass out quick on lo0 all #internal interface pass in quick on bce3 all pass out quick on bce3 all #web traffic pass in quick on bce0 proto tcp from any to any port = 80 flags S/SA keep state pass in quick on bce0 proto tcp from any to any port = 443 flags S/SA keep state #all outgoing pass out quick proto tcp from any to any flags S/SA keep state pass out quick proto icmp from any to any keep state pass out quick proto udp from any to any keep state #block the rest block in quick on bce0 all My internal interface is bce3 and external is bce0. Any thoughts what could be causing the bad nat? Thanks -- From gnn at neville-neil.com Mon Nov 3 10:46:07 2008 From: gnn at neville-neil.com (George V. Neville-Neil) Date: Mon Nov 3 10:50:21 2008 Subject: ixgbe vs mxge In-Reply-To: <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> References: <499a3e640810282326p99e0d1eud93c7ecd310c8145@mail.gmail.com> <601bffc40811011746x5c684e3fs89e3019688a333ab@mail.gmail.com> <2a41acea0811021034x45b86de1q43ef867333dfbd20@mail.gmail.com> Message-ID: At Sun, 2 Nov 2008 10:34:18 -0800, Jack Vogel wrote: > > You know I generally try to maintain courtesy and civility in my > dealings with the community but this really ticks me off. And we appreciate both your work and your professionalism. > I have stayed out of this thread because I figured it was only > fair that those with obvious bias should do so. > > Hopelessly neglected and broken?? ...the driver is maintained by > me, and I am in the same organization as the developers of the > Linux driver. If anyone has real questions about my driver and > our hardware you may contact me. > I have every expectation that the 10G driver will be a fine piece of software, just like the igb and em before them. Best, George From freebsd-net at dino.sk Mon Nov 3 14:40:18 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Mon Nov 3 14:40:25 2008 Subject: re weird bug In-Reply-To: <20081103035908.GC94302@cdnetworks.co.kr> References: <200810300829.35980.freebsd-net@dino.sk> <200810311029.56471.freebsd-net@dino.sk> <20081103035908.GC94302@cdnetworks.co.kr> Message-ID: <200811032339.07412.freebsd-net@dino.sk> On Monday 03 November 2008 04:59:08 Pyun YongHyeon wrote: [ snip ] > I vaguely guess hardware was not properly initialized. How about > this one? > http://people.freebsd.org/~yongari/re/re.phy.patch.20081103 This bug seems again to disappear - csup two days ago, kernel built with no patches and everything works. Something like this happened already in the past. No idea whether it has something with if_re being built as module, but if it happens again, I will test this possibility, too. Regards, Milan From pyunyh at gmail.com Mon Nov 3 17:48:08 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Nov 3 17:48:15 2008 Subject: re weird bug In-Reply-To: <200811032339.07412.freebsd-net@dino.sk> References: <200810300829.35980.freebsd-net@dino.sk> <200810311029.56471.freebsd-net@dino.sk> <20081103035908.GC94302@cdnetworks.co.kr> <200811032339.07412.freebsd-net@dino.sk> Message-ID: <20081104014604.GB98154@cdnetworks.co.kr> On Mon, Nov 03, 2008 at 11:39:06PM +0100, Milan Obuch wrote: > On Monday 03 November 2008 04:59:08 Pyun YongHyeon wrote: > > [ snip ] > > > I vaguely guess hardware was not properly initialized. How about > > this one? > > http://people.freebsd.org/~yongari/re/re.phy.patch.20081103 > > This bug seems again to disappear - csup two days ago, kernel built with no > patches and everything works. Something like this happened already in the Yeah, this is one of reason that makes it hard to fix. > past. No idea whether it has something with if_re being built as module, but > if it happens again, I will test this possibility, too. > Ok. Please let me know your findings. -- Regards, Pyun YongHyeon From vova at fbsd.ru Tue Nov 4 14:26:56 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Tue Nov 4 14:27:02 2008 Subject: net/mpd, net/mpd5 do not work on 8-CURRENT Message-ID: <1225835127.3428.19.camel@localhost> Hi These ports are still using set line discipline ioctl to configure ng_tty, but it is not work any more (with new ttys). src/modem.c: if (ioctl(m->fd, TIOCSETD, &ldisc) < 0) ... mpd log: [skylink] opening link "umodem0"... [umodem0] link: OPEN event [umodem0] LCP: Open event [umodem0] LCP: state change Initial --> Starting [umodem0] LCP: LayerStart [umodem0] device: OPEN event in state DOWN [umodem0] chat script succeeded [umodem0] ioctl(TIOCSETD, 6): Inappropriate ioctl for device [umodem0] device is now in state OPENING [umodem0] device: DOWN event in state OPENING [umodem0] device is now in state DOWN [umodem0] link: DOWN event [umodem0] LCP: Down event Appropriate commit log is attached. I've seen mav@'s comment on that commit, but no further actions. Any hope to make mpd work with recent 8-CURRENT ? -- Vladimir B. Grebenschikov vova@fbsd.ru -------------- next part -------------- An embedded message was scrubbed... From: Andrew Thompson Subject: cvs commit: src/share/man/man4 ng_tty.4 src/sys/netgraph ng_tty.c ng_tty.h Date: Fri, 3 Oct 2008 05:14:54 +0000 (UTC) Size: 3843 Url: http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081104/753734f2/attachment.eml From pluknet at gmail.com Wed Nov 5 05:40:34 2008 From: pluknet at gmail.com (pluknet) Date: Wed Nov 5 05:40:40 2008 Subject: CARP performance tuning question. Message-ID: Hi. AT work we use device carp(4) under high load: The problem is that the server experiences a bad interactivity (from 70k states and very bad from 120-150k) i.e. when a network workload (and interrupts count) begin to increase. >From top(1): CPU states: 0.0% user, 0.0% nice, 0.4% system, 76.3% interrupt, 23.3% idle PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 13 root 1 -44 -163 0K 8K WAIT 407:43 57.86% swi1: net ATM pfctl -s info shows such numbers: State Table Total Rate current entries 153972 searches 6052078938 4800.8/s inserts 120373545 95.5/s removals 120219573 95.4/s It works currently under UP, but could be rebuilt to work under SMP (Xeon 5130) if that helps. Can someone give hints to decrease interrupt count and to help with the server stability at all? Thanks. -- wbr, pluknet From ivo.vachkov at gmail.com Wed Nov 5 05:50:56 2008 From: ivo.vachkov at gmail.com (Ivo Vachkov) Date: Wed Nov 5 05:51:02 2008 Subject: Probably typo in netintro(4) manpage Message-ID: Hello all, I'm using FreeBSD CURRENT (as of 04 Nov 2008) and while reading netintro(4) i found something i think is typo. Near the end of the INTERFACE section there is an example: ... /* * Structure used in SIOCAIFCONF request. */ struct ifaliasreq { char ifra_name[IFNAMSIZ]; /* if name, e.g. "en0" */ struct sockaddr ifra_addr; struct sockaddr ifra_broadaddr; struct sockaddr ifra_mask; }; ... I think the "SIOCAIFCONF" should be "SIOCAIFADDR". Reference: netintro(4), sys/sockio.h /ipv From linimon at FreeBSD.org Wed Nov 5 10:26:25 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Nov 5 10:26:31 2008 Subject: kern/128598: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() Message-ID: <200811051826.mA5IQPRF074013@freefall.freebsd.org> Old Synopsis: WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() New Synopsis: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 5 18:25:24 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128598 From linimon at FreeBSD.org Wed Nov 5 10:27:46 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Nov 5 10:27:59 2008 Subject: bin/128602: [an] wpa_supplicant(8) crashes with an(4) Message-ID: <200811051827.mA5IRkR2074094@freefall.freebsd.org> Old Synopsis: wpa_supplicant crashes with an(4) New Synopsis: [an] wpa_supplicant(8) crashes with an(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 5 18:26:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128602 From pluknet at gmail.com Wed Nov 5 10:48:10 2008 From: pluknet at gmail.com (pluknet) Date: Wed Nov 5 10:48:16 2008 Subject: kern/128598: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() In-Reply-To: <200811051826.mA5IQPRF074013@freefall.freebsd.org> References: <200811051826.mA5IQPRF074013@freefall.freebsd.org> Message-ID: 2008/11/5 : > Old Synopsis: WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() > New Synopsis: [bluetooth] WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Wed Nov 5 18:25:24 UTC 2008 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=128598 As far as I know you can safely ignore this warning. BTW it was introduced somewhere between 5.x and 6.x. -- wbr, pluknet From jasonh at borisch.com Wed Nov 5 15:06:40 2008 From: jasonh at borisch.com (Jason J. Hellenthal) Date: Wed Nov 5 15:06:48 2008 Subject: ath driver (Linksys WMP110 RangePlus) ar5416 Message-ID: <6AB9DD44-C91B-4F0D-8F5C-168C57D44911@mimectl> Anyone know if the Linksys WMP110 RangePlus support will be added to 7-stable. I would rather use a native driver for this card for more features but the ndis driver seems to be working great for a couple of weeks now with no flaw. This is what the device reports in pciconf. ndis0@pci0:1:8:0: class=0x028000 card=0x00721737 chip=0x0023168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5008 Wireless Network Adapter' I have tried the ath module and it never picked up the card and I don't have to much time to modify or look into this any more than I already have. The driver name from under windows is ar5416.sys. [from Linksys support on cd/disc] If additional information or resources is needed I will be more than willing to provide whatever needed. Thanks in advance... -- J. Hellenthal (892) Aerospace Special Operations Support Borisch Manufacturing Corporation http://www.Borisch.com/ jasonh@Borisch.com "... as we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously." -- Benjamin Franklin P Only print if necessary From jon.otterholm at ide.resurscentrum.se Thu Nov 6 01:18:29 2008 From: jon.otterholm at ide.resurscentrum.se (Jon Otterholm) Date: Thu Nov 6 01:18:36 2008 Subject: CARP and L2 src-MAC Message-ID: Hi. We have a situation where we want to use CARP in a TPSDA-network and got some problems. The master CARP router ARP response contains the correct virtual MAC but uses the physical interface MAC in L2 header. This is OK for the client but the switches in between the router and the client will not learn the virtual MAC. This will work in a ?normal? switched network but will fail in a TPSDA network where all L2 devices will not learn the virtual MAC. In this case the network is built upon Alcatel iSAM FTTU and because all CARP-messages is broadcast they will not learn the virtual MAC. Is it possible to tweak CARP to use the virtual MAC in L2 header instead of the physical interface MAC? Could this be implemented as a feature controlled by a sysctl? //Jon From peterjeremy at optushome.com.au Thu Nov 6 02:53:46 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Nov 6 02:53:52 2008 Subject: CARP performance tuning question. In-Reply-To: References: Message-ID: <20081106104307.GC51239@server.vk2pj.dyndns.org> Whilst I don't doubt that you have a problem, your comments don't correlate particularly well with the data you have provided and this makes it difficult to immediately suggest a solution. On 2008-Nov-05 16:40:32 +0300, pluknet wrote: >AT work we use device carp(4) under high load: carp(4) is solely a failover mechanism. It either generates or receives somewhat under 1pps per carp interface and the state it maintains is basically 'master' or 'backup'. I suspect the 'load' is being caused by pf(4), possibly in conjunction with pfsync(4). >The problem is that the server experiences a bad interactivity (from >70k states and very bad from 120-150k) >i.e. when a network workload (and interrupts count) begin to increase. > >>From top(1): >CPU states: 0.0% user, 0.0% nice, 0.4% system, 76.3% interrupt, 23.3% idle > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND > 13 root 1 -44 -163 0K 8K WAIT 407:43 57.86% swi1: net I agree that swi1 is using a significant amount of CPU but top is still reporting >23% idle so you shouldn't be getting poor interactive performance. >ATM pfctl -s info shows such numbers: > >State Table Total Rate > current entries 153972 > searches 6052078938 4800.8/s > inserts 120373545 95.5/s > removals 120219573 95.4/s That shows the load on pf(4) but doesn't really reflect what the system is doing as a whole. >It works currently under UP, but could be rebuilt to work under SMP >(Xeon 5130) if that helps. Unfortunately, I don't know if this will help or not because I'm not sure what bottleneck you are hitting. >Can someone give hints to decrease interrupt count and to help with >the server stability at all? Well, you haven't actually reported what the interrupt count or what instability you are seeing so this is a bit difficult. Can you please provide some more information: - output from 'uname -a' - output from 'vmstat -i; sleep 10; vmstat -i' under load - output from 'netstat -i' - 10-15 seconds of output from 'netstat -i 1' under load - What is the box doing? Is it a straight filtering router? Does it handle NAT? Is it running apps itself (eg web, ftp, mail)? - What speed are the interface(s) running at? - What instability problems are you seeing? - Please provide more details on what you mean by 'bad interactivity'. - How complex is your pf ruleset? How many rules? Anything unusual? - What scheduler are you using? - What is the full output of 'pfctl -s info'? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- 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/20081106/b6f78398/attachment.pgp From pluknet at gmail.com Thu Nov 6 04:30:51 2008 From: pluknet at gmail.com (pluknet) Date: Thu Nov 6 04:30:58 2008 Subject: CARP performance tuning question. In-Reply-To: <20081106104307.GC51239@server.vk2pj.dyndns.org> References: <20081106104307.GC51239@server.vk2pj.dyndns.org> Message-ID: 2008/11/6 Peter Jeremy : > Whilst I don't doubt that you have a problem, your comments don't > correlate particularly well with the data you have provided and > this makes it difficult to immediately suggest a solution. > > On 2008-Nov-05 16:40:32 +0300, pluknet wrote: >>AT work we use device carp(4) under high load: > > carp(4) is solely a failover mechanism. It either generates or receives > somewhat under 1pps per carp interface and the state it maintains is > basically 'master' or 'backup'. I suspect the 'load' is being caused > by pf(4), possibly in conjunction with pfsync(4). > >>The problem is that the server experiences a bad interactivity (from >>70k states and very bad from 120-150k) >>i.e. when a network workload (and interrupts count) begin to increase. >> >>>From top(1): >>CPU states: 0.0% user, 0.0% nice, 0.4% system, 76.3% interrupt, 23.3% idle >> PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND >> 13 root 1 -44 -163 0K 8K WAIT 407:43 57.86% swi1: net > > I agree that swi1 is using a significant amount of CPU but top is > still reporting >23% idle so you shouldn't be getting poor interactive > performance. > >>ATM pfctl -s info shows such numbers: >> >>State Table Total Rate >> current entries 153972 >> searches 6052078938 4800.8/s >> inserts 120373545 95.5/s >> removals 120219573 95.4/s > > That shows the load on pf(4) but doesn't really reflect what the > system is doing as a whole. > >>It works currently under UP, but could be rebuilt to work under SMP >>(Xeon 5130) if that helps. > > Unfortunately, I don't know if this will help or not because I'm not > sure what bottleneck you are hitting. > >>Can someone give hints to decrease interrupt count and to help with >>the server stability at all? > > Well, you haven't actually reported what the interrupt count or > what instability you are seeing so this is a bit difficult. > > Can you please provide some more information: > - output from 'uname -a' > - output from 'vmstat -i; sleep 10; vmstat -i' under load > - output from 'netstat -i' > - 10-15 seconds of output from 'netstat -i 1' under load > - What is the box doing? Is it a straight filtering router? Does it > handle NAT? Is it running apps itself (eg web, ftp, mail)? > - What speed are the interface(s) running at? > - What instability problems are you seeing? > - Please provide more details on what you mean by 'bad interactivity'. > - How complex is your pf ruleset? How many rules? Anything unusual? > - What scheduler are you using? > - What is the full output of 'pfctl -s info'? > Thanks for your answer and, please, ignore this premature mail. It would need a bit more analysis. -- wbr, pluknet From jon.otterholm at ide.resurscentrum.se Thu Nov 6 05:18:42 2008 From: jon.otterholm at ide.resurscentrum.se (Jon Otterholm) Date: Thu Nov 6 05:18:49 2008 Subject: CARP and L2 src-MAC In-Reply-To: <20081106104718.GD51239@server.vk2pj.dyndns.org> Message-ID: On 2008-11-06 11.47, "Peter Jeremy" wrote: > On 2008-Nov-06 10:06:21 +0100, Jon Otterholm > wrote: >> Is it possible to tweak CARP to use the virtual MAC in L2 header instead of >> the physical interface MAC? Could this be implemented as a feature >> controlled by a sysctl? > > In my testing, Max Laier's carpdep patches do this. See > http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017103.html Can we find this in HEAD? //Jon From ivo.vachkov at gmail.com Thu Nov 6 08:00:24 2008 From: ivo.vachkov at gmail.com (Ivo Vachkov) Date: Thu Nov 6 08:00:31 2008 Subject: BPF question Message-ID: Hello all, I am using simple write() calls to send packets over BPF file descriptor. The BPF file descriptor is in buffered read mode (I assume this is the default and I do not set it explicitly). From what I see my write() calls are somewhat buffered. Since timing is relatively important for my project I'd like to ask if there is a way "flush" the write buffer. Setting O_DIRECT flag on the file descriptor doesn't seem to have any effect. /ipv -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From bz at FreeBSD.org Thu Nov 6 08:15:17 2008 From: bz at FreeBSD.org (Bjoern A. Zeeb) Date: Thu Nov 6 08:15:29 2008 Subject: Kernel without INET Message-ID: <20081106153035.R16105@maildrop.int.zabbadoz.net> Hi, some might have wondered about lots of small commits I have done the last two days. I had been trying to compile a kernel without any networking a few weeks ago and that failed; I had needed to add (I think it was) INET, ether and loop. So I had been trying to get rid of that requirement the last days. As a partial victory it seems to be possible again to build a kernel without any networking now. I'll have to check with my original setup but I have a stripped down LINT file I tested with. Obviously the long term goal is to be able to build a kernel without INET support (again?). As an intermediate step that will mean without INET and INET6 and once that works and IPX only would compile *cough*, then work on a (LINT) kernel with nooption INET. It'll be a long long way to go and this is nothing to finish within a week or two. Do not think about doing a quick sweep over the rest of the tree. You would wonder what depends on INET these days. I have more patches mailed out or pending here. While we had been trying to make it possible to build without INET6 most of the time, someone doing review on my code told me that if compaining about 'kernel needs INET' I should put some code under #ifdef INET. I did. The bottom line is that I now ask you to consider this for all new code as well. I am very well aware that some code, as is, would already require a maze of #ifdefs (I have a sample of that) so we need to be careful and apply the checks sensibly. Regards, Bjoern PS: please obey Reply-To: -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From rwatson at FreeBSD.org Thu Nov 6 09:06:38 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Nov 6 09:06:45 2008 Subject: BPF question In-Reply-To: References: Message-ID: On Thu, 6 Nov 2008, Ivo Vachkov wrote: > I am using simple write() calls to send packets over BPF file descriptor. > The BPF file descriptor is in buffered read mode (I assume this is the > default and I do not set it explicitly). From what I see my write() calls > are somewhat buffered. Since timing is relatively important for my project > I'd like to ask if there is a way "flush" the write buffer. Setting O_DIRECT > flag on the file descriptor doesn't seem to have any effect. The write(2) system call does no buffering in userspace (unlike, say, fwrite(3)), and when you write to a BPF device it essentially goes straight into the network interface output queue, so there should be no need for a flush mechanism. Could you describe the buffering effect you're seeing a bit more? Robert N M Watson Computer Laboratory University of Cambridge From ivo.vachkov at gmail.com Thu Nov 6 09:54:15 2008 From: ivo.vachkov at gmail.com (Ivo Vachkov) Date: Thu Nov 6 09:54:21 2008 Subject: BPF question In-Reply-To: References: Message-ID: I use following code: /* Send Announce Packet */ int zc_freebsd_sendannounce(int fd, unsigned char *mac, int zc_addr) { unsigned char *announce = NULL; int i = 0; unsigned int packet_len = 0; struct ether_header *eth_hdr = NULL; struct ether_arp *eth_arp = NULL; if (mac == NULL || zc_addr == 0 || zc_addr == -1) return -1; packet_len = sizeof(struct ether_header) + (sizeof(struct ether_arp) >= ETHER_PAYLOAD ? sizeof(struct ether_arp) : ETHER_PAYLOAD); /* Allocate announce packet */ if ((announce = malloc(packet_len)) == NULL) return -1; memset(announce, 0, packet_len); /* Populate Announce Packet * * eth_hdr * saddr - iface mac * daddr - ff:ff:ff:ff:ff:ff * type = ETHERTYPE_ARP * * eth_arp - ARP REQUEST * sender hw addr - iface mac * sender ip addr - zc_addr * target hw addr - 00:00:00:00:00:00 * target ip addr - zc_addr */ eth_hdr = (struct ether_header *)announce; eth_arp = (struct ether_arp *)((char *)eth_hdr + sizeof(struct ether_header)); memcpy(eth_hdr->ether_dhost, eth_bcast_addr, ETHER_ADDR_LEN); memcpy(eth_hdr->ether_shost, mac, ETHER_ADDR_LEN); eth_hdr->ether_type = htons(ETHERTYPE_ARP); eth_arp->arp_hrd = htons(ARPHRD_ETHER); eth_arp->arp_pro = htons(ETHERTYPE_IP); eth_arp->arp_hln = ETHER_ADDR_LEN; eth_arp->arp_pln = IP_ADDR_LEN; eth_arp->arp_op = htons(ARPOP_REQUEST); memcpy(eth_arp->arp_sha, mac, ETHER_ADDR_LEN); memcpy(eth_arp->arp_spa, &zc_addr, IP_ADDR_LEN); memcpy(eth_arp->arp_tha, eth_null_addr, ETHER_ADDR_LEN); memcpy(eth_arp->arp_tpa, &zc_addr, IP_ADDR_LEN); /* Send packet over the wire */ if ((i = write(fd, announce, packet_len)) < 0) { free(announce); return -1; } free(announce); return 0; } and later in my code i call this function in a loop: for (i = 0; i < ANNOUNCE_NUM; i++) { printf("ANNOUNCE ...\n"); fflush(stdout); /* Get initial time */ if (clock_gettime(CLOCK_REALTIME, &ts0) < 0) { perror("clock_gettime"); return -1; } /* Send Announce Packet */ if (zc_freebsd_sendannounce(bpf_fd, mac, zc_addr) < 0) { printf("zc_freebsd_sendannounce(): error\n"); return -1; } /* Possibly check for conflicts here */ /* Get time after select() */ if (clock_gettime(CLOCK_REALTIME, &ts1) < 0) { perror("clock_gettime"); return -1; } printf("ts0.sec |%ld|, ts0.nsec |%ld|\n", ts0.tv_sec, ts0.tv_nsec); fflush(stdout); printf("ts1.sec |%ld|, ts1.nsec |%ld|\n", ts1.tv_sec, ts1.tv_nsec); fflush(stdout); /* wait ANNOUNCE_INTERVAL or the rest of it */ ts0.tv_sec = ANNOUNCE_INTERVAL - (ts1.tv_sec - ts0.tv_sec) >= 0 ? ANNOUNCE_INTERVAL - (ts1.tv_sec - ts0.tv_sec) : 0; ts0.tv_nsec = ((ANNOUNCE_INTERVAL - ts0.tv_sec) * 1000000000) - (ts1.tv_nsec - ts0.tv_nsec) >= 0 ? ((ANNOUNCE_INTERVAL - ts0.tv_sec) * 1000000000) - (ts1.tv_nsec - ts0.tv_nsec) : 0; nanosleep(&ts0, NULL); } /* ANNOUNCE_NUM for() */ >From the two printf()'s above i see the nanosleep() is effective. However, when I check the packet flow with Wireshark (on the same host where this code is running) I see the announce packets timed only miliseconds away from one another. Could this be an issue with Wireshark ?! Right now I have only one computer to work on, but i'll test the timing from another computer asap. P.S. I'm implementing part of RFC3927 (ZeroConf) as part of a bigger project On Thu, Nov 6, 2008 at 7:06 PM, Robert Watson wrote: > > On Thu, 6 Nov 2008, Ivo Vachkov wrote: > >> I am using simple write() calls to send packets over BPF file descriptor. >> The BPF file descriptor is in buffered read mode (I assume this is the >> default and I do not set it explicitly). From what I see my write() calls >> are somewhat buffered. Since timing is relatively important for my project >> I'd like to ask if there is a way "flush" the write buffer. Setting O_DIRECT >> flag on the file descriptor doesn't seem to have any effect. > > The write(2) system call does no buffering in userspace (unlike, say, > fwrite(3)), and when you write to a BPF device it essentially goes straight > into the network interface output queue, so there should be no need for a > flush mechanism. Could you describe the buffering effect you're seeing a > bit more? > > Robert N M Watson > Computer Laboratory > University of Cambridge > From rea-fbsd at codelabs.ru Thu Nov 6 10:14:05 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Nov 6 10:14:47 2008 Subject: BPF question In-Reply-To: References: Message-ID: Just a side note. Thu, Nov 06, 2008 at 07:54:13PM +0200, Ivo Vachkov wrote: > P.S. I'm implementing part of RFC3927 (ZeroConf) as part of a bigger project Had you glanced at /usr/ports/net/howl and may be /usr/ports/net/avahi? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- 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/20081106/da81eb36/attachment.pgp From ivo.vachkov at gmail.com Thu Nov 6 10:27:02 2008 From: ivo.vachkov at gmail.com (Ivo Vachkov) Date: Thu Nov 6 10:27:10 2008 Subject: BPF question In-Reply-To: References: Message-ID: I "evaluated" Avahi, but it is too big for my needs. I will check howl too. However Zeroconf seems relatively easy to implement, plus i need this module to work in cooperation with others. The License does matter too :) On Thu, Nov 6, 2008 at 8:14 PM, Eygene Ryabinkin wrote: > Just a side note. > > Thu, Nov 06, 2008 at 07:54:13PM +0200, Ivo Vachkov wrote: >> P.S. I'm implementing part of RFC3927 (ZeroConf) as part of a bigger project > > Had you glanced at /usr/ports/net/howl and may be /usr/ports/net/avahi? > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From rizzo at iet.unipi.it Thu Nov 6 11:33:54 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Nov 6 11:34:00 2008 Subject: Two copies of resolver routines in libc ? Message-ID: <20081106192103.GA46651@onelab2.iet.unipi.it> i was recently re-looking at the problem mentioned in http://lists.freebsd.org/pipermail/freebsd-hackers/2003-August/002399.html (bogus dns servers on my ISP, telecomitalia, which takes forever to resolve AAAA queries, coupled with the absence, on the FreeBSD resolver has no way to disable AAAA queries when IPV6 is compiled in, which happens with GENERIC kernels). While looking for a workaround (attached, read later), i noticed that libc has two versions of the resolver routines: one is in /usr/src/lib/libc/resolv/res_query.c the other one is embedded into /usr/src/lib/libc/net/getaddrinfo.c which includes a slightly modified version of res_nquery, res_ndots, res_nquerydomain (all parts of the routines documented in resolver(3)). If we are lucky, this is just replicated code. But i am not even sure they are the same, e.g. in the handling of options (in resolv.conf or the environment variable RES_OPTIONS). This is really annoying, because generally you don't know if an application uses getaddrinfo() or the traditional gethost*() routines (which in turn use resolver(3)), so it is hard to tell whether applications have a consistent behaviour. If someone has time, it would be worthwhile trying to merge the two versions of the code into one (and i believe we should make getaddrinfo use the standard stuff in resolv/ --- As for a fix to my problem: --- i wanted some trick to disable, in the resolver, the generation of AAAA queries. resolver(5) mentions some options that can be put in /etc/resolv.conf or in the RES_OPTIONS environment variable, to control the behaviour of the resolver. Some more options are undocumented but implemented, e.g. looking at /usr/src/lib/libc/resolv/res_init.c you find these additional options: retrans: retry: inet6 insecure1 insecure2 rotate no-check-names edns0 dname nibble: nibble2: v6revmode: The code below (which is completely trivial) add an additional option, "noaaaa", which disables the generation of AAAA requests. Just do setenv RES_OPTIONS noaaaa and you are done. I don't know of other ways to disable these requests on normal address resolutions, other than build a kernel without INET6. As you see below (and this relates to my original complaint), i had to make the modification in two places :( because things like ssh and telnet use getaddrinfo(), whereas e.g. firefox uses res_query(). I have no idea what is used by /usr/bin/host or /usr/bin/dig , because they do not seem to use any of the library routines. Any interest to have this into the system ? cheers luigi Index: net/getaddrinfo.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getaddrinfo.c,v retrieving revision 1.69.2.10 diff -u -r1.69.2.10 getaddrinfo.c --- net/getaddrinfo.c 28 Sep 2007 06:23:03 -0000 1.69.2.10 +++ net/getaddrinfo.c 6 Nov 2008 20:35:39 -0000 @@ -85,6 +85,7 @@ #include #include "res_config.h" +#include "res_private.h" #ifdef DEBUG #include @@ -2257,6 +2258,8 @@ oflags = res->_flags; + if (res->options & RES_NOAAAA && type == ns_t_aaaa) + continue; /* ignore this request */ again: hp->rcode = NOERROR; /* default */ Index: resolv/res_init.c =================================================================== RCS file: /home/ncvs/src/lib/libc/resolv/res_init.c,v retrieving revision 1.2.2.3 diff -u -r1.2.2.3 res_init.c --- resolv/res_init.c 22 Dec 2006 07:33:20 -0000 1.2.2.3 +++ resolv/res_init.c 6 Nov 2008 20:34:00 -0000 @@ -636,6 +636,8 @@ !strncmp(cp, "no-tld-query", sizeof("no-tld-query") - 1)) { statp->options |= RES_NOTLDQUERY; + } else if (!strncmp(cp, "noaaaa", sizeof("noaaaa") - 1)) { + statp->options |= RES_NOAAAA; } else if (!strncmp(cp, "inet6", sizeof("inet6") - 1)) { statp->options |= RES_USE_INET6; } else if (!strncmp(cp, "insecure1", sizeof("insecure1") - 1)) { Index: resolv/res_private.h =================================================================== RCS file: /home/ncvs/src/lib/libc/resolv/res_private.h,v retrieving revision 1.1.1.1.2.1 diff -u -r1.1.1.1.2.1 res_private.h --- resolv/res_private.h 17 Jul 2006 10:09:58 -0000 1.1.1.1.2.1 +++ resolv/res_private.h 6 Nov 2008 19:08:29 -0000 @@ -3,6 +3,9 @@ #ifndef res_private_h #define res_private_h +// additional debug flags to disable AAAA queries +#define RES_NOAAAA 0x00800000 + struct __res_state_ext { union res_sockaddr_union nsaddrs[MAXNS]; struct sort_list { Index: resolv/res_query.c =================================================================== RCS file: /home/ncvs/src/lib/libc/resolv/res_query.c,v retrieving revision 1.3.2.1 diff -u -r1.3.2.1 res_query.c --- resolv/res_query.c 17 Jul 2006 10:09:58 -0000 1.3.2.1 +++ resolv/res_query.c 6 Nov 2008 20:45:23 -0000 @@ -90,6 +90,7 @@ #include #include #include "port_after.h" +#include "res_private.h" /* Options. Leave them on. */ #define DEBUG @@ -126,10 +127,12 @@ again: hp->rcode = NOERROR; /* default */ + if (statp->options & RES_NOAAAA && type == ns_t_aaaa) { + return 0; /* ignore this request */ + } #ifdef DEBUG if (statp->options & RES_DEBUG) - printf(";; res_query(%s, %d, %d)\n", name, class, type); + printf(";; res_nquery(%s, %d, %d)\n", name, class, type); #endif n = res_nmkquery(statp, QUERY, name, class, type, NULL, 0, NULL, From peterjeremy at optushome.com.au Thu Nov 6 14:04:04 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Nov 6 14:04:11 2008 Subject: CARP and L2 src-MAC In-Reply-To: References: Message-ID: <20081106104718.GD51239@server.vk2pj.dyndns.org> On 2008-Nov-06 10:06:21 +0100, Jon Otterholm wrote: >Is it possible to tweak CARP to use the virtual MAC in L2 header instead of >the physical interface MAC? Could this be implemented as a feature >controlled by a sysctl? In my testing, Max Laier's carpdep patches do this. See http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017103.html -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- 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/20081106/dab1af09/attachment.pgp From citrin at citrin.ru Thu Nov 6 15:04:43 2008 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Thu Nov 6 15:04:57 2008 Subject: sysctl net.inet.tcp.syncache.count Message-ID: <49137561.80403@citrin.ru> % sysctl net.inet.tcp.syncache net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 1024 net.inet.tcp.syncache.count: -84 net.inet.tcp.syncache.cachelimit: 102400 net.inet.tcp.syncache.bucketlimit: 100 Why number of entries in syncache is negative? % uname -srp FreeBSD 7.1-PRERELEASE amd64 -- Anton Yuzhaninov From rwatson at FreeBSD.org Fri Nov 7 00:58:04 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Nov 7 00:58:11 2008 Subject: sysctl net.inet.tcp.syncache.count In-Reply-To: <49137561.80403@citrin.ru> References: <49137561.80403@citrin.ru> Message-ID: On Fri, 7 Nov 2008, Anton Yuzhaninov wrote: > % sysctl net.inet.tcp.syncache > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 1024 > net.inet.tcp.syncache.count: -84 > net.inet.tcp.syncache.cachelimit: 102400 > net.inet.tcp.syncache.bucketlimit: 100 > > Why number of entries in syncache is negative? The syncache entry is no longer protected by a single lock, since the locks on the syncache are now per-hash bucket, so it looks like it's been corrupted. This won't lead to other problems, as the count is updated as a statistic but never used to, for example, enforce limits. We should probably eliminate the statistic, since UMA already maintains the syncache entry count coherently as part of its own statistics, along with other useful information: robert@fledge:~> vmstat -z | head -1 ; vmstat -z | grep -i syncache ITEM SIZE LIMIT USED FREE REQUESTS FAILURES syncache: 104, 15392, 0, 222, 2638489, 0 I'm not convinced its worth adding the overhead of coherent statistics gathering for the cache entry count if we already have it elsewhere. Robert N M Watson Computer Laboratory University of Cambridge From dougb at FreeBSD.org Fri Nov 7 13:06:11 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Nov 7 13:06:18 2008 Subject: Kernel without INET In-Reply-To: <20081106153035.R16105@maildrop.int.zabbadoz.net> References: <20081106153035.R16105@maildrop.int.zabbadoz.net> Message-ID: <4914A782.6030509@FreeBSD.org> Not that I object to this at all, but out of curiosity what is the motivation? I would imagine "embedded devices that run stuff not connected to the 'net" but hoping for something more interesting/exciting. :) Doug -- This .signature sanitized for your protection From kmacy at freebsd.org Fri Nov 7 14:30:46 2008 From: kmacy at freebsd.org (Kip Macy) Date: Fri Nov 7 14:30:52 2008 Subject: small radix_mpath patch Message-ID: <3c1674c90811071430s1f07ba6cp372609809ef7f591@mail.gmail.com> Calling arpresolve on an rtentry looked up by rtalloc_mpath_fib won't work because a gratuitous clone route is created without llinfo attached. As far as I can tell, routes should only ever be cloned for initial host route creation during a resolve to store arp information. Index: sys/net/radix_mpath.c =================================================================== --- sys/net/radix_mpath.c (revision 184756) +++ sys/net/radix_mpath.c (working copy) @@ -54,7 +54,7 @@ /* * give some jitter to hash, to avoid synchronization between routers */ -static u_int32_t hashjitter; +static uint32_t hashjitter; int rn_mpath_capable(struct radix_node_head *rnh) @@ -267,7 +267,7 @@ */ if (ro->ro_rt && ro->ro_rt->rt_ifp && (ro->ro_rt->rt_flags & RTF_UP)) return; /* XXX */ - ro->ro_rt = rtalloc1_fib(&ro->ro_dst, 1, 0UL, fibnum); + ro->ro_rt = rtalloc1_fib(&ro->ro_dst, 1, RTF_CLONING, fibnum); /* if the route does not exist or it is not multipath, don't care */ if (ro->ro_rt == NULL) @@ -299,7 +299,7 @@ return; } - rtfree(ro->ro_rt); + RTFREE_LOCKED(ro->ro_rt); ro->ro_rt = (struct rtentry *)rn; RT_LOCK(ro->ro_rt); RT_ADDREF(ro->ro_rt); From ume at freebsd.org Sat Nov 8 00:40:01 2008 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Sat Nov 8 00:40:08 2008 Subject: Two copies of resolver routines in libc ? In-Reply-To: <20081106192103.GA46651@onelab2.iet.unipi.it> References: <20081106192103.GA46651@onelab2.iet.unipi.it> Message-ID: Hi, >>>>> On Thu, 6 Nov 2008 20:21:03 +0100 >>>>> Luigi Rizzo said: rizzo> While looking for a workaround (attached, read later), i noticed rizzo> that libc has two versions of the resolver routines: one is in rizzo> /usr/src/lib/libc/resolv/res_query.c rizzo> the other one is embedded into rizzo> /usr/src/lib/libc/net/getaddrinfo.c rizzo> which includes a slightly modified version of res_nquery, res_ndots, rizzo> res_nquerydomain (all parts of the routines documented in resolver(3)). Yes. rizzo> If we are lucky, this is just replicated code. No, the resolver functions in getaddrinfo.c has some addition of functionality. It was done for solving the query order problem. rizzo> But i am not even sure they are the same, e.g. in the handling of rizzo> options (in resolv.conf or the environment variable RES_OPTIONS). The basic functionality including the handling of options are same. rizzo> This is really annoying, because generally you don't know if an rizzo> application uses getaddrinfo() or the traditional gethost*() routines rizzo> (which in turn use resolver(3)), so it is hard to tell whether rizzo> applications have a consistent behaviour. You don't need to worry about it. rizzo> If someone has time, it would be worthwhile trying to merge rizzo> the two versions of the code into one (and i believe we should rizzo> make getaddrinfo use the standard stuff in resolv/ When we tried to solve the query order problem, we decided to have a modification code of the resolver into getaddrinfo.c. Because: - Hide the internal functions from outside of libc. - Don't change the resolver as possible to ease further merge from ISC BIND. Since we have the symbol versioning facility, we can hide the libc internal functions from outside of libc, these days. So, it may better to merge the two. I attached the proposed patch in this mail. Please review it. Sincerely, -------------- next part -------------- A non-text attachment was scrubbed... Name: resolver-multi.diff Type: text/x-patch Size: 19773 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081108/e78dc2a4/resolver-multi.bin -------------- next part -------------- -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From mav at FreeBSD.org Sat Nov 8 04:01:04 2008 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Nov 8 04:26:27 2008 Subject: net/mpd, net/mpd5 do not work on 8-CURRENT In-Reply-To: <1225835127.3428.19.camel@localhost> References: <1225835127.3428.19.camel@localhost> Message-ID: <4915716D.3060603@FreeBSD.org> Vladimir Grebenschikov wrote: > These ports are still using set line discipline ioctl to configure > ng_tty, but it is not work any more (with new ttys). > > Any hope to make mpd work with recent 8-CURRENT ? I have just committed some patches into 8-CURRENT and mpd5 CVS and now it works for me. But there are still some issues that must be fixed. -- Alexander Motin From rizzo at iet.unipi.it Sat Nov 8 07:05:47 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sat Nov 8 07:05:54 2008 Subject: Two copies of resolver routines in libc ? In-Reply-To: References: <20081106192103.GA46651@onelab2.iet.unipi.it> Message-ID: <20081108151023.GA72747@onelab2.iet.unipi.it> On Sat, Nov 08, 2008 at 05:39:52PM +0900, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Thu, 6 Nov 2008 20:21:03 +0100 > >>>>> Luigi Rizzo said: > > rizzo> While looking for a workaround (attached, read later), i noticed > rizzo> that libc has two versions of the resolver routines: one is in ... > rizzo> If we are lucky, this is just replicated code. > > No, the resolver functions in getaddrinfo.c has some addition of > functionality. It was done for solving the query order problem. ... > When we tried to solve the query order problem, we decided to have a > modification code of the resolver into getaddrinfo.c. Because: > > - Hide the internal functions from outside of libc. > - Don't change the resolver as possible to ease further merge from > ISC BIND. > > Since we have the symbol versioning facility, we can hide the libc > internal functions from outside of libc, these days. So, it may > better to merge the two. I attached the proposed patch in this mail. > Please review it. hi, thanks for the answer and the effort for merging back the two copies. I am looking at your proposed patch but i am not sure i understand it fully, so i would be grateful if you could explain me a few things (btw i am attaching a version of your patch constructed with 'diff -ubwp' and couple of formatting changes to remove whitespace differences; this should make the actual changes more evident): 1. i apologize for my ignorance, but i suppose there is a binding between __res_nsearchN() and res_nsearchN(), and the same for all function with and without the two leading __ . Where is this binding established, as i don't see anything in the diff that you sent. 2. res_*() now become wrappers around the newly introduced res_*N() functions. While this approach removes the duplication, it does not address the "ease further merge from ISC BIND" case, which definitely sounded as a valid concern. So i wonder, what is it that prevents you from acting the other way around, i.e. build the res_*N() around the existing res_*() functions ? This way the original ISC code would really be unmodified and perhaps the change would be even more confined. Does this constraint apply to all three functions (res_query, res_search, res_nquerydomain) or only for a subset of them ? From what i can tell, at least in res_nquery() the only significant change seems to be the following + if (n > anslen) + hp->rcode = FORMERR; /* XXX not very informative */ other than that it seems perfectly fine to implement res_nqueryN() as a wrapper around the original res_nquery(). For the other two functions and the other one (trspping TRYAGAIN) seems perfectly suitable to be implemented in 2. i don't completely understand what is the additional functionality in the resolver functions. You mention a 'query order problem' but i don't exactly understand what it is and how the functional change is implemented. thanks luigi -------------- next part -------------- A non-text attachment was scrubbed... Name: resolv-ubwp.diff Type: text/x-diff Size: 6943 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081108/30c823e9/resolv-ubwp.bin From ume at freebsd.org Sat Nov 8 08:29:25 2008 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Sat Nov 8 08:29:32 2008 Subject: Two copies of resolver routines in libc ? In-Reply-To: <20081108151023.GA72747@onelab2.iet.unipi.it> References: <20081106192103.GA46651@onelab2.iet.unipi.it> <20081108151023.GA72747@onelab2.iet.unipi.it> Message-ID: Hi, >>>>> On Sat, 8 Nov 2008 16:10:23 +0100 >>>>> Luigi Rizzo said: rizzo> thanks for the answer and the effort for merging back the two copies. rizzo> I am looking at your proposed patch but i am not sure i understand it fully, rizzo> so i would be grateful if you could explain me a few things (btw i rizzo> am attaching a version of your patch constructed with 'diff -ubwp' rizzo> and couple of formatting changes to remove whitespace differences; rizzo> this should make the actual changes more evident): Yes, I did 'diff -ubwp' to check during making this patch. :-) rizzo> 1. i apologize for my ignorance, but i suppose there is a binding rizzo> between __res_nsearchN() and res_nsearchN(), and the same rizzo> for all function with and without the two leading __ . Where rizzo> is this binding established, as i don't see anything in the rizzo> diff that you sent. The function with leading `__' is libc internal function. Since, we need to call res_searchN() from getaddrinfo.c, I couldn't make it static. So, I renamed res_searchN() to __res_nsearchN(). The rest (res_queryN() and res_nquerydomainN()) are not called from outside of res_query.c. So, I made them static without leading `__'. rizzo> 2. res_*() now become wrappers around the newly introduced res_*N() rizzo> functions. While this approach removes the duplication, it does rizzo> not address the "ease further merge from ISC BIND" case, which rizzo> definitely sounded as a valid concern. Yes, it is annoying thing. The differences in res_nsearch() and res_nquerydomain() are trivial. But, res_nquery() is bit complicate. However, the diff is trivial with `diff -bw', as you did. I think it confuses us that there are two copies of the resolver functions, too. However, I'm not sure which is better merging the two or leaving it as it is. rizzo> So i wonder, what is it that prevents you from acting the other rizzo> way around, i.e. build the res_*N() around the existing res_*() rizzo> functions ? This way the original ISC code would really be rizzo> unmodified and perhaps the change would be even more confined. Unfortunately, it is impossible. We need to have `for loop' in res_nquery() to solve the query order problem. It is the reason to have a copy in getaddrinfo.c. rizzo> Does this constraint apply to all three functions (res_query, res_search, rizzo> res_nquerydomain) or only for a subset of them ? Yes, this constraint apply to all three functions. Since, the res_nquerydomain() and res_nsearch() call res_nquery(), we need to have the modified version of them to change to call res_nqueryN(). rizzo> From what i can tell, at least in res_nquery() rizzo> the only significant change seems to be the following rizzo> + if (n > anslen) rizzo> + hp->rcode = FORMERR; /* XXX not very informative */ rizzo> other than that it seems perfectly fine to implement res_nqueryN() rizzo> as a wrapper around the original res_nquery(). It is a check for buffer overflow vulnerability. At a later time, we enlarged the buffers for answer in netdb functions. So, perhaps, this check became useless. But, I leaved it as it is for safety. rizzo> For the other two functions rizzo> and the other one (trspping TRYAGAIN) seems perfectly suitable to rizzo> be implemented in rizzo> 2. i don't completely understand what is the additional functionality rizzo> in the resolver functions. You mention a 'query order problem' rizzo> but i don't exactly understand what it is and how the functional rizzo> change is implemented. As basic use of the resolver to query AAAA RR and A RR, the query order is: 1) Call res_nquery(hostname, T_A) for A RR 2) Call res_nquery(hostname, T_AAAA) for AAAA RR With regard of domain name completion and sort_list. Imagine querying hosta with example.org and example.com in search list. The query order will be: 1) Call res_nquery(hosta, T_A) Query T_A RR for hosta 2) Call res_nquery(hosta.example.org, T_A) Query T_A RR for hosta.example.org 3) Call res_nquery(hosta.example.com, T_A) Query T_A RR for hosta.example.com 4) Call res_nquery(hosta, T_AAAA) Query AAAA RR for hosta 5) Call res_nquery(hosta.example.org, T_AAAA) Query T_AAAA RR for hosta.example.org 6) Call res_nquery(hosta.example.com, T_AAAA) Query T_AAAA RR for hosta.example.com It may cause the problem where either example.org or example.com cannot reply correctly. With the change, the query order will be: 1) Call res_nqueryN(hosta, T_A and T_AAAA) Query T_A RR for hosta Query AAAA RR for hosta Query T_A RR for hosta.example.org Query T_AAAA RR for hosta.example.org Query T_A RR for hosta.example.com Query T_AAAA RR for hosta.example.com Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From ume at freebsd.org Sat Nov 8 08:38:05 2008 From: ume at freebsd.org (Hajimu UMEMOTO) Date: Sat Nov 8 08:38:12 2008 Subject: Two copies of resolver routines in libc ? In-Reply-To: References: <20081106192103.GA46651@onelab2.iet.unipi.it> <20081108151023.GA72747@onelab2.iet.unipi.it> Message-ID: Hi, >>>>> On Sun, 09 Nov 2008 01:29:15 +0900 >>>>> Hajimu UMEMOTO said: ume> It may cause the problem where either example.org or example.com ume> cannot reply correctly. ume> With the change, the query order will be: ume> 1) Call res_nqueryN(hosta, T_A and T_AAAA) ume> Query T_A RR for hosta ume> Query AAAA RR for hosta ume> Query T_A RR for hosta.example.org ume> Query T_AAAA RR for hosta.example.org ume> Query T_A RR for hosta.example.com ume> Query T_AAAA RR for hosta.example.com Oops, it would be: 1) Call res_nqueryN(hosta, T_A and T_AAAA) Query T_A RR for hosta Query AAAA RR for hosta 2) Call res_nqueryN(hosta.example.org, T_A and T_AAAA) Query T_A RR for hosta.example.org Query T_AAAA RR for hosta.example.org 3) Call res_nqueryN(hosta.example.com, T_A and T_AAAA) Query T_A RR for hosta.example.com Query T_AAAA RR for hosta.example.com Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From linimon at FreeBSD.org Sat Nov 8 18:47:16 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Nov 8 18:47:27 2008 Subject: kern/128247: [ip6] [panic] Fatal Trap 12 in ip6_forward = Message-ID: <200811090247.mA92lFbE076009@freefall.freebsd.org> Old Synopsis: [panic] Fatal Trap 12 in ip6_forward = New Synopsis: [ip6] [panic] Fatal Trap 12 in ip6_forward = Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 9 02:45:04 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128247 From eugen at kuzbass.ru Sun Nov 9 07:05:21 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Nov 9 07:05:28 2008 Subject: new little feature for sendmail Message-ID: <20081109150515.GA61144@svzserv.kemerovo.su> Hi! Please give me advice on how to contribute new small feature to sendmail vendor code? I've discussed it in comp.mail.sendmail, it adds new flag -F to socketmap definition so ruleset may tell socketmap's permanent lookup failure (PERM) from 'not found' (NOTFOUND) error, for example: LOCAL_CONFIG Kcyrus socket -a -F -T local:/var/imap/socket/smmapd I've sent the patch and its description to sendmail-2008@ mailing list at support.sendmail.org but have not received a response. I do not even know if it has passed to the list or not, I have not found a web archive of the list. Usenet discussion of a problem and patch may be seen here: http://groups.google.com/group/comp.mail.sendmail/browse_thread/thread/d9a82dcb398019af Eugene Grosbein From bugmaster at FreeBSD.org Mon Nov 10 03:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 10 03:08:36 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200811101106.mAAB6stU049791@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 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 kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? 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: 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/126984 net [carp][patch] add carp userland notifications via devc 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 f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic 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 [in] Network: 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 f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr 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/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p 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/123881 net [tcp] Turning on TCP blackholing causes slow localhost 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 o 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/123200 net [netgraph] Server failure due to netgraph mpd and dhcp 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/123066 net [ipsec] [panic] kernel trap with ipsec 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 [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/122427 net [apm] [panic] apm and mDNSResponder cause panic during 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/122068 net [ppp] ppp can not set the correct interface with pptpd 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 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 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 [panic] gnugk causes kernel panic when closing UDP soc 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 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/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented 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 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/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat 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/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 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/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 bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a 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 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 conf/102502 net [patch] ifconfig name does't rename netgraph node in n 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/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/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 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 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/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/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 FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic 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/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 190 problems total. From scaron at umich.edu Mon Nov 10 07:17:26 2008 From: scaron at umich.edu (Sean Caron) Date: Mon Nov 10 07:17:33 2008 Subject: Occasional kernel panic + reboot on 7.0-RELEASE, sparc64, fatm card. Message-ID: <4098EE5C-1B7E-42B5-8F6C-F35DB8D4C917@umich.edu> Hi folks, I posted this originally to the Freebsd/sparc64 general mailing list and someone there suggested that I send it this way, with the following note. "This apparently is a NULL-pointer dereference (probably "m" in sbsndptr()), with the cause being in one of the stacks involved. I'd suggest to report this backtrace to the atm@ and net@ lists." Quick background - I'm using fatm on FreeBSD/sparc64 7.0-RELEASE with a FORE PCA-200E PCI ATM card (fatm). I am using the Cranor (natm) driver. It generally works well but every couple of weeks the system will kernel panic and reboot. I switched on kernel dumps on panic and here's what I got (this time): sonnet.diablonet.net> kgdb kernel.debug /var/crash/vmcore.0 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): 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 "sparc64-marcel-freebsd". Unread portion of the kernel message buffer: panic: trap: fast data access mmu miss Uptime: 16d13h9m7s Dumping 1024 MB (2 chunks) chunk at 0: 536870912 bytes | #0 0x00000000c0280cd8 in doadump () at /usr/src/sys/kern/ kern_shutdown.c:240 240 savectx(&dumppcb); (kgdb) backtrace #0 0x00000000c0280cd8 in doadump () at /usr/src/sys/kern/ kern_shutdown.c:240 #1 0x00000000c0281608 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0x00000000c0281860 in panic (fmt=0xc066c6e0 "trap: %s") at /usr/src/sys/kern/kern_shutdown.c:563 #3 0x00000000c0541de4 in trap (tf=0xe5390e50) at /usr/src/sys/sparc64/sparc64/trap.c:378 #4 0x00000000c0070fe0 in tl1_trap () #5 0x00000000c02dd1d0 in sbsndptr (sb=0xfffff800014be6f0, off=0, len=1390, moff=0xe5391064) at /usr/src/sys/kern/uipc_sockbuf.c:939 #6 0x00000000c03edac4 in tcp_output (tp=0xfffff800014be6f0) at /usr/src/sys/netinet/tcp_output.c:802 #7 0x00000000c03edac4 in tcp_output (tp=0xfffff800014fce38) at /usr/src/sys/netinet/tcp_output.c:802 #8 0x00000000c03eaf98 in tcp_do_segment (m=0xfffff8005b354000, th=0xfffff8000133283c, so=0xfffff800014be570, tp=0xfffff800014fce38, drop_hdrlen=52, tlen=0) at /usr/src/sys/netinet/tcp_input.c:2347 #9 0x00000000c03ec214 in tcp_input (m=0xfffff8005b354000, off0=Variable "off0" is not available. ) at /usr/src/sys/netinet/tcp_input.c:845 #10 0x00000000c0381128 in ip_input (m=0xfffff8005b354000) at /usr/src/sys/netinet/ip_input.c:665 #11 0x00000000c0339cd0 in netisr_dispatch (num=2, m=0xfffff8005b354000) at /usr/src/sys/net/netisr.c:185 #12 0x00000000c032a930 in atm_input (ifp=0xfffff8000103c000, ah=0xe539162c, m=0xfffff8005b354000, rxhand=0x0) at /usr/src/sys/net/ if_atmsubr.c:347 #13 0x00000000c013d410 in fatm_intr (p=0xfffff80001173c00) at /usr/src/sys/dev/fatm/if_fatm.c:1573 #14 0x00000000c02615ec in ithread_loop (arg=0xfffff800011ce760) at /usr/src/sys/kern/kern_intr.c:1036 #15 0x00000000c025dd54 in fork_exit (callout=0xc0261420 , arg=0xfffff800011ce760, frame=0xe5391880) at /usr/src/sys/kern/kern_fork.c:781 #16 0x00000000c00711d0 in fork_trampoline () #17 0x00000000c00711d0 in fork_trampoline () Previous frame identical to this frame (corrupt stack?) (kgdb) up 15 #15 0x00000000c025dd54 in fork_exit (callout=0xc0261420 , arg=0xfffff800011ce760, frame=0xe5391880) at /usr/src/sys/kern/kern_fork.c:781 781 callout(arg, frame); (kgdb) list 776 * cpu_set_fork_handler intercepts this function call to 777 * have this call a non-return function to stay in kernel mode. 778 * initproc has its own fork handler, but it does return. 779 */ 780 KASSERT(callout != NULL, ("NULL callout in fork_exit")); 781 callout(arg, frame); 782 783 /* 784 * Check if a kernel thread misbehaved and returned from its main 785 * function. (kgdb) down #14 0x00000000c02615ec in ithread_loop (arg=0xfffff800011ce760) at /usr/src/sys/kern/kern_intr.c:1036 1036 ih->ih_handler(ih->ih_argument); (kgdb) list 1031 __func__, p->p_pid, (void *)ih->ih_handler, 1032 ih->ih_argument, ih->ih_name, ih->ih_flags); 1033 1034 if (!(ih->ih_flags & IH_MPSAFE)) 1035 mtx_lock(&Giant); 1036 ih->ih_handler(ih->ih_argument); 1037 if (!(ih->ih_flags & IH_MPSAFE)) 1038 mtx_unlock(&Giant); 1039 } 1040 if (!(ie->ie_flags & IE_SOFT)) (kgdb) down #13 0x00000000c013d410 in fatm_intr (p=0xfffff80001173c00) at /usr/src/sys/dev/fatm/if_fatm.c:1573 1573 atm_input(ifp, &aph, m0, vc->rxhand); (kgdb) list 1568 ifp->if_ipackets++; 1569 1570 vc->ipackets++; 1571 vc->ibytes += m0->m_pkthdr.len; 1572 1573 atm_input(ifp, &aph, m0, vc->rxhand); 1574 } 1575 1576 H_SETSTAT(q->q.statp, FATM_STAT_FREE); 1577 H_SYNCSTAT_PREWRITE(sc, q->q.statp); (kgdb) down #12 0x00000000c032a930 in atm_input (ifp=0xfffff8000103c000, ah=0xe539162c, m=0xfffff8005b354000, rxhand=0x0) at /usr/src/sys/net/ if_atmsubr.c:347 347 netisr_dispatch(isr, m); (kgdb) list 342 else 343 m_freem(m); 344 return; 345 } 346 } 347 netisr_dispatch(isr, m); 348 } 349 350 /* 351 * Perform common duties while attaching to interface list. (kgdb) down #11 0x00000000c0339cd0 in netisr_dispatch (num=2, m=0xfffff8005b354000) at /usr/src/sys/net/netisr.c:185 185 ni->ni_handler(m); (kgdb) list 180 * the packet but now do not. Doing so here will 181 * not preserve ordering so instead we fallback to 182 * guaranteeing order only from dispatch points 183 * in the system (see above). 184 */ 185 ni->ni_handler(m); 186 } else { 187 isrstat.isrs_deferred++; 188 if (IF_HANDOFF(ni->ni_queue, m, NULL)) 189 schednetisr(num); (kgdb) down #10 0x00000000c0381128 in ip_input (m=0xfffff8005b354000) at /usr/src/sys/netinet/ip_input.c:665 665 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); (kgdb) list 660 /* 661 * Switch out to protocol's input routine. 662 */ 663 ipstat.ips_delivered++; 664 665 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen); 666 return; 667 bad: 668 m_freem(m); 669 } (kgdb) down #9 0x00000000c03ec214 in tcp_input (m=0xfffff8005b354000, off0=Variable "off0" is not available. ) at /usr/src/sys/netinet/tcp_input.c:845 845 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen); (kgdb) list 840 /* 841 * Segment belongs to a connection in SYN_SENT, ESTABLISHED or later 842 * state. tcp_do_segment() always consumes the mbuf chain, unlocks 843 * the inpcb, and unlocks pcbinfo. 844 */ 845 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen); 846 INP_INFO_UNLOCK_ASSERT(&tcbinfo); 847 return; 848 849 dropwithreset: (kgdb) down #8 0x00000000c03eaf98 in tcp_do_segment (m=0xfffff8005b354000, th=0xfffff8000133283c, so=0xfffff800014be570, tp=0xfffff800014fce38, drop_hdrlen=52, tlen=0) at /usr/src/sys/netinet/tcp_input.c:2347 2347 (void) tcp_output(tp); (kgdb) list 2342 2343 /* 2344 * Return any desired output. 2345 */ 2346 if (needoutput || (tp->t_flags & TF_ACKNOW)) 2347 (void) tcp_output(tp); 2348 2349 check_delack: 2350 KASSERT(headlocked == 0, ("%s: check_delack: head locked", 2351 __func__)); (kgdb) down #7 0x00000000c03edac4 in tcp_output (tp=0xfffff800014fce38) at /usr/src/sys/netinet/tcp_output.c:802 802 mb = sbsndptr(&so->so_snd, off, len, &moff); (kgdb) list 797 798 /* 799 * Start the m_copy functions from the closest mbuf 800 * to the offset in the socket buffer chain. 801 */ 802 mb = sbsndptr(&so->so_snd, off, len, &moff); 803 804 if (len <= MHLEN - hdrlen - max_linkhdr) { 805 m_copydata(mb, moff, (int)len, 806 mtod(m, caddr_t) + hdrlen); (kgdb) down #6 0x00000000c03edac4 in tcp_output (tp=0xfffff800014be6f0) at /usr/src/sys/netinet/tcp_output.c:802 802 mb = sbsndptr(&so->so_snd, off, len, &moff); (kgdb) list 797 798 /* 799 * Start the m_copy functions from the closest mbuf 800 * to the offset in the socket buffer chain. 801 */ 802 mb = sbsndptr(&so->so_snd, off, len, &moff); 803 804 if (len <= MHLEN - hdrlen - max_linkhdr) { 805 m_copydata(mb, moff, (int)len, 806 mtod(m, caddr_t) + hdrlen); (kgdb) down #5 0x00000000c02dd1d0 in sbsndptr (sb=0xfffff800014be6f0, off=0, len=1390, moff=0xe5391064) at /usr/src/sys/kern/uipc_sockbuf.c:939 939 off > 0 && off >= m->m_len; (kgdb) list 934 *moff = off - sb->sb_sndptroff; 935 m = ret = sb->sb_sndptr ? sb->sb_sndptr : sb->sb_mb; 936 937 /* Advance by len to be as close as possible for the next transmit. */ 938 for (off = off - sb->sb_sndptroff + len - 1; 939 off > 0 && off >= m->m_len; 940 m = m->m_next) { 941 sb->sb_sndptroff += m->m_len; 942 off -= m->m_len; 943 } (kgdb) down #4 0x00000000c0070fe0 in tl1_trap () (kgdb) list 944 sb->sb_sndptr = m; 945 946 return (ret); 947 } 948 949 /* 950 * Drop a record off the front of a sockbuf and move the next record to the 951 * front. 952 */ 953 void (kgdb) quit sonnet.diablonet.net> Please let me know if further information is required and I will furnish, no problem. Thanks, -Sean From linimon at FreeBSD.org Wed Nov 12 00:44:12 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Nov 12 00:44:18 2008 Subject: kern/128750: [ndis] BSS mode broken with ndis Message-ID: <200811120844.mAC8iCcV077300@freefall.freebsd.org> Old Synopsis: BSS mode broken with ndis New Synopsis: [ndis] BSS mode broken with ndis Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 12 08:44:00 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128750 From thompsa at FreeBSD.org Wed Nov 12 07:36:06 2008 From: thompsa at FreeBSD.org (thompsa@FreeBSD.org) Date: Wed Nov 12 07:36:12 2008 Subject: kern/128750: [ndis] BSS mode broken with ndis Message-ID: <200811121536.mACFa5Hd086473@freefall.freebsd.org> Synopsis: [ndis] BSS mode broken with ndis State-Changed-From-To: open->closed State-Changed-By: thompsa State-Changed-When: Wed Nov 12 15:35:27 UTC 2008 State-Changed-Why: Fixed in r184833, does not affect older branches. Thanks Paul! http://www.freebsd.org/cgi/query-pr.cgi?pr=128750 From sclark46 at earthlink.net Wed Nov 12 11:07:31 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Wed Nov 12 11:07:37 2008 Subject: FreeBSD 6.3 gre and traceroute Message-ID: <491B2703.4080707@earthlink.net> Hi, When I run traceroute thru a gre it doesn't seem to decrement the ttl, so I get * * * for that hop. Can this be fixed? Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From linimon at FreeBSD.org Wed Nov 12 11:23:03 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Nov 12 11:23:14 2008 Subject: kern/128790: [netinet] [patch] bug in IP_MINTTL setsockopt() implementation Message-ID: <200811121923.mACJN3ta058755@freefall.freebsd.org> Old Synopsis: [patch] bug in IP_MINTTL setsockopt() implementation New Synopsis: [netinet] [patch] bug in IP_MINTTL setsockopt() implementation Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 12 19:22:37 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128790 From julian at elischer.org Wed Nov 12 11:55:11 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Nov 12 11:55:18 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <491B2703.4080707@earthlink.net> References: <491B2703.4080707@earthlink.net> Message-ID: <491B31F7.30200@elischer.org> Stephen Clark wrote: > Hi, > > When I run traceroute thru a gre it doesn't seem to decrement the > ttl, so I get * * * for that hop. Can this be fixed? > > Thanks, > Steve you will need to define the setup and question better. TTL is controlled by the IP stack which is unaware of which interface it came in on and doesn't care which interface it goes out on. That includes GRE interfaces.. Is it freebsd at both ends? BTW * * * would come from an EXTRA decrement From sclark46 at earthlink.net Wed Nov 12 12:57:46 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Wed Nov 12 12:57:53 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <491B31F7.30200@elischer.org> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> Message-ID: <491B4345.80106@earthlink.net> Julian Elischer wrote: > Stephen Clark wrote: >> Hi, >> >> When I run traceroute thru a gre it doesn't seem to decrement the >> ttl, so I get * * * for that hop. Can this be fixed? >> >> Thanks, >> Steve > > you will need to define the setup and question better. > > TTL is controlled by the IP stack which is unaware of which interface > it came in on and doesn't care which interface it goes out on. That > includes GRE interfaces.. Is it freebsd at both ends? > > > BTW * * * would come from an EXTRA decrement > _______________________________________________ > 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 workstation 10.0.129.1<-->10.0.128.1 Freebsd FW "A" with gre over ipsec tunnel<---->FreeBSD FW "B" with gre over ipsec tunnel 192.168.3.1<---> 192.168.3.86 linux workstation $ sudo traceroute 192.168.3.86 traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms 2 * * * 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms No response from the FreeBSD "B" box. When I do a tcpdump on "B" of the gre interface I see UDP packets with a TTL of 1 but no ICMP repsonse packets being sent back. If I do the traceroute from the linux workstation 192.168.3.86 I get similar results - I don't see a response from the FreeBSD "A" box. Regards, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From julian at elischer.org Wed Nov 12 13:17:07 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Nov 12 13:17:14 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <491B4345.80106@earthlink.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> Message-ID: <491B47D2.6010804@elischer.org> Stephen Clark wrote: > Julian Elischer wrote: >> you will need to define the setup and question better. thanks.. cleaning it up a bit more... 10.0.129.1 FreeBSD workstation ^ | | ethernet | v 10.0.128.1 Freebsd FW "A" ^ | | gre / ipsec | v 192.168.3.1 FreeBSD FW "B" ^ | | ethernet | v 192.168.3.86 linux workstation > $ sudo traceroute 192.168.3.86 > traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets > 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms > 2 * * * > 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms > > No response from the FreeBSD "B" box. > > When I do a tcpdump on "B" of the gre interface I see UDP packets > with a TTL of 1 but no ICMP response packets being sent back. > > If I do the traceroute from the linux workstation 192.168.3.86 I get > similar results - I don't see a response from the FreeBSD "A" box. could you try using just GRE encasulation? (i.e. turn off IPSEC for now) I think that is much more likely to be where the problem is.. From rnoland at FreeBSD.org Wed Nov 12 13:56:56 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Nov 12 13:57:03 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <491B47D2.6010804@elischer.org> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> Message-ID: <1226525816.61187.35.camel@squirrel.corp.cox.com> On Wed, 2008-11-12 at 13:17 -0800, Julian Elischer wrote: > Stephen Clark wrote: > > Julian Elischer wrote: > > >> you will need to define the setup and question better. > > thanks.. cleaning it up a bit more... > > 10.0.129.1 FreeBSD workstation > ^ > | > | ethernet > | > v > 10.0.128.1 Freebsd FW "A" > ^ > | > | gre / ipsec > | > v > 192.168.3.1 FreeBSD FW "B" > ^ > | > | ethernet > | > v > 192.168.3.86 linux workstation How are you mapping packets onto the gre? If firewall B doesn't know how to reach the FreeBSD workstation directly, you will see the issue that you describe. Can you ping 10.0.129.1 from Firewall B? The ttl expired will be generated by Firewall B. robert. > > $ sudo traceroute 192.168.3.86 > > traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets > > 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms > > 2 * * * > > 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms > > > > No response from the FreeBSD "B" box. > > > > When I do a tcpdump on "B" of the gre interface I see UDP packets > > with a TTL of 1 but no ICMP response packets being sent back. > > > > > If I do the traceroute from the linux workstation 192.168.3.86 I get > > similar results - I don't see a response from the FreeBSD "A" box. > > could you try using just GRE encasulation? > (i.e. turn off IPSEC for now) > > I think that is much more likely to be where the problem is.. > > > _______________________________________________ > 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" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081112/58f6b8f7/attachment.pgp From rwatson at FreeBSD.org Wed Nov 12 16:16:29 2008 From: rwatson at FreeBSD.org (rwatson@FreeBSD.org) Date: Wed Nov 12 16:16:35 2008 Subject: kern/128790: [netinet] [patch] bug in IP_MINTTL setsockopt() implementation Message-ID: <200811130016.mAD0GSPw006106@freefall.freebsd.org> Synopsis: [netinet] [patch] bug in IP_MINTTL setsockopt() implementation Responsible-Changed-From-To: freebsd-net->rwatson Responsible-Changed-By: rwatson Responsible-Changed-When: Thu Nov 13 00:15:55 UTC 2008 Responsible-Changed-Why: Grab ownership of this PR, I can take a look at this. http://www.freebsd.org/cgi/query-pr.cgi?pr=128790 From linimon at FreeBSD.org Wed Nov 12 17:09:16 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Nov 12 17:09:22 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811130109.mAD19FDE043692@freefall.freebsd.org> Old Synopsis: Network packets corrupted when bge card is in 64-bit PCI slot New Synopsis: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 13 01:09:00 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128833 From sclark46 at earthlink.net Thu Nov 13 04:46:24 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu Nov 13 04:46:31 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <1226525816.61187.35.camel@squirrel.corp.cox.com> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <1226525816.61187.35.camel@squirrel.corp.cox.com> Message-ID: <491C219B.1050606@earthlink.net> Robert Noland wrote: > On Wed, 2008-11-12 at 13:17 -0800, Julian Elischer wrote: >> Stephen Clark wrote: >>> Julian Elischer wrote: >>>> you will need to define the setup and question better. >> thanks.. cleaning it up a bit more... >> >> 10.0.129.1 FreeBSD workstation >> ^ >> | >> | ethernet >> | >> v >> 10.0.128.1 Freebsd FW "A" >> ^ >> | >> | gre / ipsec >> | >> v >> 192.168.3.1 FreeBSD FW "B" >> ^ >> | >> | ethernet >> | >> v >> 192.168.3.86 linux workstation > > How are you mapping packets onto the gre? If firewall B doesn't know > how to reach the FreeBSD workstation directly, you will see the issue > that you describe. Can you ping 10.0.129.1 from Firewall B? The ttl > expired will be generated by Firewall B. ospf - I can ping 192.168.3.1 from the FreeBSD Workstation just fine in fact all the systems can ping just fine. > > robert. > >>> $ sudo traceroute 192.168.3.86 >>> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets >>> 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms >>> 2 * * * >>> 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms >>> >>> No response from the FreeBSD "B" box. >>> >>> When I do a tcpdump on "B" of the gre interface I see UDP packets >>> with a TTL of 1 but no ICMP response packets being sent back. >>> If I do the traceroute from the linux workstation 192.168.3.86 I get >>> similar results - I don't see a response from the FreeBSD "A" box. >> could you try using just GRE encasulation? >> (i.e. turn off IPSEC for now) >> >> I think that is much more likely to be where the problem is.. >> >> >> _______________________________________________ >> 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" -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From sclark46 at earthlink.net Thu Nov 13 04:48:58 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu Nov 13 04:49:04 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <491B47D2.6010804@elischer.org> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> Message-ID: <491C2235.4090509@earthlink.net> Julian Elischer wrote: > Stephen Clark wrote: >> Julian Elischer wrote: > >>> you will need to define the setup and question better. > > thanks.. cleaning it up a bit more... > > 10.0.129.1 FreeBSD workstation > ^ > | > | ethernet > | > v > 10.0.128.1 Freebsd FW "A" > ^ > | > | gre / ipsec > | > v > 192.168.3.1 FreeBSD FW "B" > ^ > | > | ethernet > | > v > 192.168.3.86 linux workstation > >> $ sudo traceroute 192.168.3.86 >> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets >> 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms >> 2 * * * >> 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms >> >> No response from the FreeBSD "B" box. >> >> When I do a tcpdump on "B" of the gre interface I see UDP packets >> with a TTL of 1 but no ICMP response packets being sent back. > >> >> If I do the traceroute from the linux workstation 192.168.3.86 I get >> similar results - I don't see a response from the FreeBSD "A" box. > > could you try using just GRE encasulation? > (i.e. turn off IPSEC for now) > > I think that is much more likely to be where the problem is.. > > I'll have to set this up to test it. What code in the FreeBSD kernel is responsible for generating the response ICMP dest unreachable message? -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From rnoland at FreeBSD.org Thu Nov 13 07:17:59 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Nov 13 07:18:06 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <491C2235.4090509@earthlink.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> Message-ID: <1226589468.1976.12.camel@wombat.2hip.net> On Thu, 2008-11-13 at 07:48 -0500, Stephen Clark wrote: > Julian Elischer wrote: > > Stephen Clark wrote: > >> Julian Elischer wrote: > > > >>> you will need to define the setup and question better. > > > > thanks.. cleaning it up a bit more... > > > > 10.0.129.1 FreeBSD workstation > > ^ > > | > > | ethernet > > | > > v > > 10.0.128.1 Freebsd FW "A" > > ^ > > | > > | gre / ipsec > > | > > v > > 192.168.3.1 FreeBSD FW "B" > > ^ > > | > > | ethernet > > | > > v > > 192.168.3.86 linux workstation > > > >> $ sudo traceroute 192.168.3.86 > >> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets > >> 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms > >> 2 * * * > >> 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms > >> > >> No response from the FreeBSD "B" box. > >> > >> When I do a tcpdump on "B" of the gre interface I see UDP packets > >> with a TTL of 1 but no ICMP response packets being sent back. > > > >> > >> If I do the traceroute from the linux workstation 192.168.3.86 I get > >> similar results - I don't see a response from the FreeBSD "A" box. > > > > could you try using just GRE encasulation? > > (i.e. turn off IPSEC for now) > > > > I think that is much more likely to be where the problem is.. > > > > > I'll have to set this up to test it. The ttl exceeded is triggered from one of two places. Either netinet/ip_fastfwd.c if fast_forwarding is enabled or in netinet/ip_input.c. Look for the code relating to IPTTLDEC. This isn't your problem though... If ttl were not being decremented, the packet would just be forwarded on to the next hop (IP_STEALTH), which would just make the firewalls invisible. The fact that you are seeing * * * indicates that you are not receiving the ttl exceeded message for the packet sent with that particular ttl. I still think that the issue you are seeing is that one way or another the generated ICMP response isn't making it back onto the tunnel. Either via security policy, firewall or routing. robert. > What code in the FreeBSD kernel is responsible for generating the response ICMP > dest unreachable message? > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081113/b6b36261/attachment.pgp From sclark46 at earthlink.net Thu Nov 13 07:59:01 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu Nov 13 07:59:07 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <1226589468.1976.12.camel@wombat.2hip.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> Message-ID: <491C4EC2.2000802@earthlink.net> Robert Noland wrote: > On Thu, 2008-11-13 at 07:48 -0500, Stephen Clark wrote: >> Julian Elischer wrote: >>> Stephen Clark wrote: >>>> Julian Elischer wrote: >>>>> you will need to define the setup and question better. >>> thanks.. cleaning it up a bit more... >>> >>> 10.0.129.1 FreeBSD workstation >>> ^ >>> | >>> | ethernet >>> | >>> v >>> 10.0.128.1 Freebsd FW "A" >>> ^ >>> | >>> | gre / ipsec >>> | >>> v >>> 192.168.3.1 FreeBSD FW "B" >>> ^ >>> | >>> | ethernet >>> | >>> v >>> 192.168.3.86 linux workstation >>> >>>> $ sudo traceroute 192.168.3.86 >>>> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte packets >>>> 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms >>>> 2 * * * >>>> 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms >>>> >>>> No response from the FreeBSD "B" box. >>>> >>>> When I do a tcpdump on "B" of the gre interface I see UDP packets >>>> with a TTL of 1 but no ICMP response packets being sent back. >>>> If I do the traceroute from the linux workstation 192.168.3.86 I get >>>> similar results - I don't see a response from the FreeBSD "A" box. >>> could you try using just GRE encasulation? >>> (i.e. turn off IPSEC for now) >>> >>> I think that is much more likely to be where the problem is.. >>> >>> >> I'll have to set this up to test it. > > The ttl exceeded is triggered from one of two places. Either > netinet/ip_fastfwd.c if fast_forwarding is enabled or in > netinet/ip_input.c. Look for the code relating to IPTTLDEC. This isn't > your problem though... If ttl were not being decremented, the packet > would just be forwarded on to the next hop (IP_STEALTH), which would > just make the firewalls invisible. The fact that you are seeing * * * > indicates that you are not receiving the ttl exceeded message for the > packet sent with that particular ttl. I still think that the issue you > are seeing is that one way or another the generated ICMP response isn't > making it back onto the tunnel. Either via security policy, firewall or > routing. Your right, when I do a tcpdump on the gre interface I see the udp packet come in with a ttl=1 but I don't see a response icmp packet. I have tested this with all the firewalls disabled to make sure the icmp packet was not being blocked. I just ran another test and did tcpdump on all the other interfaces to make sure the icmp's were not being misrouted, it seems they are not being generated for some reason. Also just using gre's without the underlying ipsec tunnels seems to work properly. > > robert. > >> What code in the FreeBSD kernel is responsible for generating the response ICMP >> dest unreachable message? >> -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From marius at alchemy.franken.de Thu Nov 13 14:30:12 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Thu Nov 13 14:30:19 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811132230.mADMUC45038539@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: bug-followup@FreeBSD.org, freebsd@amc-os.com Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Thu, 13 Nov 2008 23:14:46 +0100 Hrm, I could be that the BCM5701 data corruption bug actually is 64-bit rather than only PCI-X bus specific. Could you please give the patch at: http://people.freebsd.org/~marius/bge_5701.diff a try? From julian at elischer.org Thu Nov 13 18:18:34 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Nov 13 18:18:40 2008 Subject: rc.firewall quick change Message-ID: <491CD94F.3020207@elischer.org> At home I use the following change. basically, instead of doing 8 rules before and after the nat, use a table and to 1 rule on each side. any objections? (warning, cut-n-paste patch.. will not apply) Index: rc.firewall =================================================================== --- rc.firewall (revision 184948) +++ rc.firewall (working copy) @@ -231,19 +231,24 @@ ${fwcmd} add deny all from ${onet} to any in via ${iif} # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} + ${fwcmd} table 1 add 10.0.0.0/8 + ${fwcmd} table 1 add 172.16.0.0/12 + ${fwcmd} table 1 add 192.168.0.0/16 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} + ${fwcmd} table 1 add 0.0.0.0/8 + ${fwcmd} table 1 add 169.254.0.0/16 + ${fwcmd} table 1 add 192.0.2.0/24 + ${fwcmd} table 1 add 224.0.0.0/4 + ${fwcmd} table 1 add 240.0.0.0/4 + # Stop the above nets with the table + + ${fwcmd} add deny all from any to "table(1)" via ${oif} + + # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP @@ -260,19 +265,8 @@ esac # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} + ${fwcmd} add deny all from "table(1)" to any via ${oif} - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) - # on the outside interface - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} - # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established From smithi at nimnet.asn.au Thu Nov 13 19:11:13 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Nov 13 19:11:20 2008 Subject: Speaking of rc.firewall .. (fwd) Message-ID: <20081114134925.E70117@sola.nimnet.asn.au> ---------- Forwarded message ---------- Date: Fri, 17 Oct 2008 05:24:43 +1100 (EST) From: Ian Smith To: freebsd-ipfw@freebsd.org Subject: Re: Speaking of rc.firewall .. On Thu, 16 Oct 2008, Ian Smith wrote: > I see that both HEAD and RELENG_7 rc.firewall have been updated for in- > kernel NAT functionality, but only for the 'open' and 'client' rulesets. > > Is there any (functional) reason that the ${firewall_nat_enable} case is > not also included in the 'simple' rules, where its different placement > is determined by being preceded and anteceded by anti-spoofing rules? > > I'm also slightly bemused by the lack (still) of any rules to allow any > ICMP (especially necessary icmptypes for MTU discovery) in 'simple'? To put my patch where my mouth is, assuming that the answer to my first question is likely 'no', this is against the present RELENG_7 version. It addresses the second (ICMP) issue for 'client' and 'simple', and I see no harm in enabling outbound pings for such out-of-the-box setups? Hope this format's useful (just diff -u), and also that inline is ok. cheers, Ian --- rc.firewall.1.52.2.3 Fri Oct 17 01:34:56 2008 +++ rc.firewall Fri Oct 17 04:27:36 2008 @@ -116,15 +116,14 @@ # will then be run again on each packet after translation by natd # starting at the rule number following the divert rule. # -# For ``simple'' firewall type the divert rule should be put to a +# For ``simple'' firewall type the divert rule is included in a # different place to not interfere with address-checking rules. # -case ${firewall_type} in -[Oo][Pp][Ee][Nn]|[Cc][Ll][Ii][Ee][Nn][Tt]) +setup_nat () { case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then - ${fwcmd} add 50 divert natd ip4 from any to any via ${natd_interface} + ${fwcmd} add $1 divert natd ip4 from any to any via ${natd_interface} fi ;; esac @@ -138,11 +137,11 @@ firewall_nat_flags="if ${firewall_nat_interface} ${firewall_nat_flags}" fi ${fwcmd} nat 123 config log ${firewall_nat_flags} - ${fwcmd} add 50 nat 123 ip4 from any to any via ${firewall_nat_interface} + ${fwcmd} add $1 nat 123 ip4 from any to any via ${firewall_nat_interface} fi ;; esac -esac +} ############ # If you just configured ipfw in the kernel as a tool to solve network @@ -157,6 +156,7 @@ # case ${firewall_type} in [Oo][Pp][Ee][Nn]) + setup_nat 50 ${fwcmd} add 65000 pass all from any to any ;; @@ -172,6 +172,8 @@ # set this to your local network net="$firewall_client_net" + setup_nat 50 + # Allow any traffic to or from my own net. ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me @@ -197,6 +199,12 @@ # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + # Allow outbound pings + ${fwcmd} add pass icmp from me to any out icmptypes 8 keep-state + + # Allow essential ICMP: unreachable, source quench, TTL exceeded + ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 + # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. @@ -248,13 +256,7 @@ # translated by natd(8) would match the `deny' rule above. Similarly # an outgoing packet originated from it before being translated would # match the `deny' rule below. - case ${natd_enable} in - [Yy][Ee][Ss]) - if [ -n "${natd_interface}" ]; then - ${fwcmd} add divert natd all from any to any via ${natd_interface} - fi - ;; - esac + setup_nat # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} @@ -298,6 +300,12 @@ # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + + # Allow outbound pings from our net + ${fwcmd} add pass icmp from any to any out icmptypes 8 keep-state + + # Allow essential ICMP: unreachable, source quench, TTL exceeded + ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel From smithi at nimnet.asn.au Thu Nov 13 19:11:14 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Nov 13 19:11:31 2008 Subject: rc.firewall quick change In-Reply-To: <491CD94F.3020207@elischer.org> References: <491CD94F.3020207@elischer.org> Message-ID: <20081114133913.K70117@sola.nimnet.asn.au> On Thu, 13 Nov 2008, Julian Elischer wrote: > At home I use the following change. > > > basically, instead of doing 8 rules before and after the nat, > use a table and to 1 rule on each side. > > > any objections? Only that if people are already using tables for anything, chances are they've already used table 1 (well, it's the first one I used :) How about using table 127 for this as a rather less likely prior choice? Apart from that, this will speed up 'simple' on a path every packet takes, which has to be a good thing. While I'm at it, I'll offer my own rc.firewall patch again in the following message. Perhaps you'd care to review it in this context? cheers, Ian > (warning, cut-n-paste patch.. will not apply) > > Index: rc.firewall > =================================================================== > --- rc.firewall (revision 184948) > +++ rc.firewall (working copy) > @@ -231,19 +231,24 @@ > ${fwcmd} add deny all from ${onet} to any in via ${iif} > > # Stop RFC1918 nets on the outside interface > - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} > - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} > - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} > + ${fwcmd} table 1 add 10.0.0.0/8 > + ${fwcmd} table 1 add 172.16.0.0/12 > + ${fwcmd} table 1 add 192.168.0.0/16 > > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > RESERVED-1, > # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > E) > # on the outside interface > - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} > - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} > - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} > - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} > - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} > + ${fwcmd} table 1 add 0.0.0.0/8 > + ${fwcmd} table 1 add 169.254.0.0/16 > + ${fwcmd} table 1 add 192.0.2.0/24 > + ${fwcmd} table 1 add 224.0.0.0/4 > + ${fwcmd} table 1 add 240.0.0.0/4 > > + # Stop the above nets with the table > + > + ${fwcmd} add deny all from any to "table(1)" via ${oif} > + > + > # Network Address Translation. This rule is placed here deliberately > # so that it does not interfere with the surrounding address-checking > # rules. If for example one of your internal LAN machines had its IP > @@ -260,19 +265,8 @@ > esac > > # Stop RFC1918 nets on the outside interface > - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} > - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} > - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} > + ${fwcmd} add deny all from "table(1)" to any via ${oif} > > - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > RESERVED-1, > - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > E) > - # on the outside interface > - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} > - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} > - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} > - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} > - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} > - > # Allow TCP through if setup succeeded > ${fwcmd} add pass tcp from any to any established > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From julian at elischer.org Fri Nov 14 00:31:26 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Nov 14 00:31:47 2008 Subject: rc.firewall quick change In-Reply-To: <20081114133913.K70117@sola.nimnet.asn.au> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> Message-ID: <491D375D.1070809@elischer.org> Ian Smith wrote: > On Thu, 13 Nov 2008, Julian Elischer wrote: > > At home I use the following change. > > > > > > basically, instead of doing 8 rules before and after the nat, > > use a table and to 1 rule on each side. > > > > > > any objections? > > Only that if people are already using tables for anything, chances are > they've already used table 1 (well, it's the first one I used :) How > about using table 127 for this as a rather less likely prior choice? yes I thought of that.. in fact it should be ${BLOCKTABLE} and let the user define what he wants. (defaulting to 99 or something). Remember though that a user wouldn't be using 'simple' if he's using his own tables etc. > > Apart from that, this will speed up 'simple' on a path every packet > takes, which has to be a good thing. > > While I'm at it, I'll offer my own rc.firewall patch again in the > following message. Perhaps you'd care to review it in this context? > > cheers, Ian > > > (warning, cut-n-paste patch.. will not apply) > > > > Index: rc.firewall > > =================================================================== > > --- rc.firewall (revision 184948) > > +++ rc.firewall (working copy) > > @@ -231,19 +231,24 @@ > > ${fwcmd} add deny all from ${onet} to any in via ${iif} > > > > # Stop RFC1918 nets on the outside interface > > - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} > > - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} > > - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} > > + ${fwcmd} table 1 add 10.0.0.0/8 > > + ${fwcmd} table 1 add 172.16.0.0/12 > > + ${fwcmd} table 1 add 192.168.0.0/16 > > > > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > > RESERVED-1, > > # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > > E) > > # on the outside interface > > - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} > > - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} > > - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} > > - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} > > - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} > > + ${fwcmd} table 1 add 0.0.0.0/8 > > + ${fwcmd} table 1 add 169.254.0.0/16 > > + ${fwcmd} table 1 add 192.0.2.0/24 > > + ${fwcmd} table 1 add 224.0.0.0/4 > > + ${fwcmd} table 1 add 240.0.0.0/4 > > > > + # Stop the above nets with the table > > + > > + ${fwcmd} add deny all from any to "table(1)" via ${oif} > > + > > + > > # Network Address Translation. This rule is placed here deliberately > > # so that it does not interfere with the surrounding address-checking > > # rules. If for example one of your internal LAN machines had its IP > > @@ -260,19 +265,8 @@ > > esac > > > > # Stop RFC1918 nets on the outside interface > > - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} > > - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} > > - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} > > + ${fwcmd} add deny all from "table(1)" to any via ${oif} > > > > - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > > RESERVED-1, > > - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class > > E) > > - # on the outside interface > > - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} > > - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} > > - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} > > - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} > > - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} > > - > > # Allow TCP through if setup succeeded > > ${fwcmd} add pass tcp from any to any established > > > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From julian at elischer.org Fri Nov 14 01:10:09 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Nov 14 01:10:20 2008 Subject: rc.firewall quick change In-Reply-To: <491D375D.1070809@elischer.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> Message-ID: <491D406F.5030806@elischer.org> Julian Elischer wrote: > Ian Smith wrote: >> On Thu, 13 Nov 2008, Julian Elischer wrote: >> > At home I use the following change. >> > > > basically, instead of doing 8 rules before and after the nat, >> > use a table and to 1 rule on each side. >> > > > any objections? >> >> Only that if people are already using tables for anything, chances are >> they've already used table 1 (well, it's the first one I used :) How >> about using table 127 for this as a rather less likely prior choice? > > yes I thought of that.. > in fact it should be ${BLOCKTABLE} and let the user define what he > wants. (defaulting to 99 or something). > Remember though that a user wouldn't be using 'simple' if he's using his > own tables etc. > so here's a slightly improved diff: -------------- next part -------------- Index: rc.firewall =================================================================== --- rc.firewall (revision 184948) +++ rc.firewall (working copy) @@ -216,11 +216,13 @@ # firewall_simple_inet: Inside network address. # firewall_simple_oif: Outside network interface. # firewall_simple_onet: Outside network address. + # firewall_block_table: Table to use blocking stuff. ############ # set these to your outside interface network oif="$firewall_simple_oif" onet="$firewall_simple_onet" + tbl=${firewall_block_table:-99} # set these to your inside interface network iif="$firewall_simple_iif" @@ -231,19 +233,24 @@ ${fwcmd} add deny all from ${onet} to any in via ${iif} # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} - ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} + ${fwcmd} table ${tbl} add 10.0.0.0/8 + ${fwcmd} table ${tbl} add 172.16.0.0/12 + ${fwcmd} table ${tbl} add 192.168.0.0/16 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface - ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} - ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} - ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} - ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} - ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} + ${fwcmd} table ${tbl} add 0.0.0.0/8 + ${fwcmd} table ${tbl} add 169.254.0.0/16 + ${fwcmd} table ${tbl} add 192.0.2.0/24 + ${fwcmd} table ${tbl} add 224.0.0.0/4 + ${fwcmd} table ${tbl} add 240.0.0.0/4 + # Stop the above nets with the table + + ${fwcmd} add deny all from any to "table(${tbl})" via ${oif} + + # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP @@ -260,19 +267,8 @@ esac # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} - ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} + ${fwcmd} add deny all from "table(${tbl})" to any via ${oif} - # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, - # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) - # on the outside interface - ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} - ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} - ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} - ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} - ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} - # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established From brde at optusnet.com.au Fri Nov 14 02:38:30 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Fri Nov 14 02:38:36 2008 Subject: rc.firewall quick change In-Reply-To: <491D375D.1070809@elischer.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> Message-ID: <20081114211043.W54700@delplex.bde.org> On Fri, 14 Nov 2008, Julian Elischer wrote: > Ian Smith wrote: >> On Thu, 13 Nov 2008, Julian Elischer wrote: >> > At home I use the following change. >> > > > basically, instead of doing 8 rules before and after the nat, >> > use a table and to 1 rule on each side. >> > > > any objections? >> >> Only that if people are already using tables for anything, chances are >> they've already used table 1 (well, it's the first one I used :) How about >> using table 127 for this as a rather less likely prior choice? > > yes I thought of that.. Separate rules provide more statistics. > in fact it should be ${BLOCKTABLE} and let the user define what he wants. > (defaulting to 99 or something). I use shell variables giving lists of interfaces to be blocked so that there aren't very many rules: %%% rfc1918n=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 dmanningn=0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 ${fwcmd} add deny log all from any to ${rfc1918n} via ${oif} ${fwcmd} add deny log all from any to ${dmanningn} via ${oif} ... (divert rule) ${fwcmd} add deny log all from ${rfc1918n} to any via ${oif} ${fwcmd} add deny log all from ${dmanningn} to any via ${oif} %%% I use separate lists mainly for documentation purposes but they also provide separate statistics. > Remember though that a user wouldn't be using 'simple' if he's using his own > tables etc. Separate rules are also simplest for documentation purposes. >> Apart from that, this will speed up 'simple' on a path every packet takes, >> which has to be a good thing. Are tables faster than lists of addresses? I would expect lists to be slightly more efficient. Bruce From won.derick at yahoo.com Fri Nov 14 03:43:51 2008 From: won.derick at yahoo.com (Won De Erick) Date: Fri Nov 14 04:19:59 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage Message-ID: <305614.76266.qm@web45809.mail.sp1.yahoo.com> > ----- Original Message ---- > From: Won De Erick > To: Jeremy Chadwick > Cc: freebsd-hardware@freebsd.org > Sent: Thursday, November 13, 2008 4:07:37 PM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > Noted on this, I will update you through this thread. With FreeBSD 7.1 Beta2, here is the result: 52 root 1 -68 - 0K 16K CPU11 b 38:43 95.36% irq32: bce1 51 root 1 -68 - 0K 16K CPU10 a 25:50 85.16% irq31: bce0 There's a slight difference w/ the previous result though, but I observed that overall CPU utilization didn't change. ### Complete result: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 21 root 1 171 ki31 0K 16K CPU5 5 91:29 100.00% idle: cpu5 14 root 1 171 ki31 0K 16K CPU12 c 91:29 100.00% idle: cpu12 22 root 1 171 ki31 0K 16K CPU4 4 91:29 100.00% idle: cpu4 17 root 1 171 ki31 0K 16K CPU9 9 91:28 100.00% idle: cpu9 12 root 1 171 ki31 0K 16K CPU14 e 91:27 100.00% idle: cpu14 23 root 1 171 ki31 0K 16K CPU3 3 90:58 100.00% idle: cpu3 25 root 1 171 ki31 0K 16K CPU1 1 86:41 100.00% idle: cpu1 19 root 1 171 ki31 0K 16K CPU7 7 84:00 100.00% idle: cpu7 24 root 1 171 ki31 0K 16K CPU2 2 83:53 100.00% idle: cpu2 18 root 1 171 ki31 0K 16K CPU8 8 79:01 100.00% idle: cpu8 26 root 1 171 ki31 0K 16K RUN 0 74:18 100.00% idle: cpu0 11 root 1 171 ki31 0K 16K CPU15 0 0:00 100.00% idle: cpu15 13 root 1 171 ki31 0K 16K CPU13 0 0:00 100.00% idle: cpu13 20 root 1 171 ki31 0K 16K CPU6 6 90:18 99.27% idle: cpu6 52 root 1 -68 - 0K 16K CPU11 b 38:43 95.36% irq32: bce1 51 root 1 -68 - 0K 16K CPU10 a 25:50 85.16% irq31: bce0 16 root 1 171 ki31 0K 16K RUN a 65:39 15.97% idle: cpu10 28 root 1 -32 - 0K 16K WAIT 8 12:28 5.18% swi4: clock sio 15 root 1 171 ki31 0K 16K RUN b 52:46 3.76% idle: cpu11 45 root 1 -64 - 0K 16K WAIT 7 7:29 1.17% irq17: uhci0 47 root 1 -64 - 0K 16K WAIT 6 1:11 0.10% irq16: ciss0 Is there some ways how the intensive [network] load can be distributed among the IDLE processors? Another thing, I observed that in the above test, the net.isr is enabled by default. When I tried disabling this, # sysctl net.isr.direct=0 net.isr.direct: 1 -> 0 the result: 52 root 1 -68 - 0K 16K WAIT b 64:00 42.97% irq32: bce1 51 root 1 -68 - 0K 16K WAIT a 38:22 12.26% irq31: bce0 The CPU utilizations considerably dropped! What was changed in the fbsd7.1? How useful this net.isr is? Is this needed in an environment with heavy network traffic? Can someone explain? > However is there any possibility of the following: > > > I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, > > which means a total of four IRQs, and eventually four cores (or 4 CPUs) > > for the transactions. With this way, the IDLE processors would be utilized. > > What I mean here is, for the two interfaces: > > one IRQ for bce0 Rx > one IRQ for bce0 Tx > one IRQ for bce1 Rx > one IRQ for bce1 Tx > > > Thanks, > > Won > > > > ________________________________ > From: Jeremy Chadwick > To: Won De Erick > Cc: freebsd-hardware@freebsd.org > Sent: Thursday, November 13, 2008 3:46:02 PM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > On Wed, Nov 12, 2008 at 11:38:15PM -0800, Won De Erick wrote: > > I am conducting a CPU utilization testing with my box(HP DL 585 running FreeBSD 7.0), and come up with the results below: > > > > 52 root 1 -68 - 0K 16K CPU11 b 123:53 100.00% irq32: bce1 > > 51 root 1 -68 - 0K 16K CPU10 a 119:28 89.06% irq31: bce0 > > > > irq31 and irq32 are consuming high CPU usage, which i think the cause of hard reset. > > There was a ***major*** bce(4) cleanup that just happened. Your 7.0 box > will not have these changes. Please upgrade your box to RELENG_7 > (a.k.a. 7.1-PRERELEASE), csup'd recently (today preferably), and try > your tests again: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046482.html > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > From sclark46 at earthlink.net Fri Nov 14 04:20:02 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Fri Nov 14 04:20:09 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <491C4EC2.2000802@earthlink.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> Message-ID: <491D6CED.50006@earthlink.net> Stephen Clark wrote: > Robert Noland wrote: >> On Thu, 2008-11-13 at 07:48 -0500, Stephen Clark wrote: >>> Julian Elischer wrote: >>>> Stephen Clark wrote: >>>>> Julian Elischer wrote: >>>>>> you will need to define the setup and question better. >>>> thanks.. cleaning it up a bit more... >>>> >>>> 10.0.129.1 FreeBSD workstation >>>> ^ >>>> | >>>> | ethernet >>>> | >>>> v >>>> 10.0.128.1 Freebsd FW "A" >>>> ^ >>>> | >>>> | gre / ipsec >>>> | >>>> v >>>> 192.168.3.1 FreeBSD FW "B" >>>> ^ >>>> | >>>> | ethernet >>>> | >>>> v >>>> 192.168.3.86 linux workstation >>>> >>>>> $ sudo traceroute 192.168.3.86 >>>>> traceroute to 192.168.3.86 (192.168.3.86), 64 hops max, 40 byte >>>>> packets >>>>> 1 HQFirewallRS.com (10.0.128.1) 0.575 ms 0.423 ms 0.173 ms >>>>> 2 * * * >>>>> 3 192.168.3.86 (192.168.3.86) 47.972 ms 45.174 ms 49.968 ms >>>>> >>>>> No response from the FreeBSD "B" box. >>>>> >>>>> When I do a tcpdump on "B" of the gre interface I see UDP packets >>>>> with a TTL of 1 but no ICMP response packets being sent back. >>>>> If I do the traceroute from the linux workstation 192.168.3.86 I get >>>>> similar results - I don't see a response from the FreeBSD "A" box. >>>> could you try using just GRE encasulation? >>>> (i.e. turn off IPSEC for now) >>>> >>>> I think that is much more likely to be where the problem is.. >>>> >>>> >>> I'll have to set this up to test it. >> >> The ttl exceeded is triggered from one of two places. Either >> netinet/ip_fastfwd.c if fast_forwarding is enabled or in >> netinet/ip_input.c. Look for the code relating to IPTTLDEC. This isn't >> your problem though... If ttl were not being decremented, the packet >> would just be forwarded on to the next hop (IP_STEALTH), which would >> just make the firewalls invisible. The fact that you are seeing * * * >> indicates that you are not receiving the ttl exceeded message for the >> packet sent with that particular ttl. I still think that the issue you >> are seeing is that one way or another the generated ICMP response isn't >> making it back onto the tunnel. Either via security policy, firewall or >> routing. > Your right, when I do a tcpdump on the gre interface I see the udp > packet come > in with a ttl=1 but I don't see a response icmp packet. I have tested > this with > all the firewalls disabled to make sure the icmp packet was not being > blocked. > I just ran another test and did tcpdump on all the other interfaces to > make sure > the icmp's were not being misrouted, it seems they are not being > generated for some reason. Also just using gre's without the underlying > ipsec tunnels seems to > work properly. >> >> robert. >> >>> What code in the FreeBSD kernel is responsible for generating the >>> response ICMP dest unreachable message? >>> > > Another data point I had been using option FILTER_GIF I tried a kernel without that option and it behaved the same. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From won.derick at yahoo.com Fri Nov 14 04:58:59 2008 From: won.derick at yahoo.com (Won De Erick) Date: Fri Nov 14 05:04:57 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage References: <305614.76266.qm@web45809.mail.sp1.yahoo.com> Message-ID: <555333.76711.qm@web45806.mail.sp1.yahoo.com> > ----- Original Message ---- > From: Ivan Voras > To: freebsd-hardware@freebsd.org > Cc: freebsd-net@freebsd.org > Sent: Friday, November 14, 2008 7:49:13 PM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > Won De Erick wrote: > > > Another thing, I observed that in the above test, the net.isr is enabled by default. When I tried disabling this, > > > > # sysctl net.isr.direct=0 > > net.isr.direct: 1 -> 0 > > > > the result: > > > > 52 root 1 -68 - 0K 16K WAIT b 64:00 42.97% irq32: bce1 > > 51 root 1 -68 - 0K 16K WAIT a 38:22 12.26% irq31: bce0 > > > > The CPU utilizations considerably dropped! > > You will probably find a "swi" process that has picked up the difference > (when isr.direct is disabled, some of network protocol processing is > offloaded to a swi thread). This might help spread the load across CPU > but in my testing it didn't help real-world throughput. > You are right. I noticed the following when net.isr is diabled, lowering the idle time of cpu0. 27 root 1 -44 - 0K 16K WAIT 0 52:20 76.37% swi1: net 26 root 1 171 ki31 0K 16K CPU0 0 111:58 64.36% idle: cpu0 Another thing, Packet drops on Intel NIC ( Intel? PRO/1000 PT Dual Port Server Adapter w/ control processor 82571GB) did not occur when the net.isr was disabled, while the overall CPU utilization remains considerably low. Note: The following result was obtained during a transition from a disabled to enabled net.isr. Hence the first part packets errs bytes packets errs bytes colls drops 10844 0 15603850 7940 0 582934 0 0 11659 0 16800328 8503 0 630330 0 0 11778 0 17033560 8998 0 677934 0 0 12149 0 17592134 9504 0 728094 0 0 12551 0 18223550 9974 0 774164 0 0 13127 0 19093604 10413 0 811858 0 0 13712 0 20010140 10924 0 848014 0 0 14499 0 21153538 11407 0 878252 0 0 14818 0 21740270 11979 0 915374 0 0 15831 0 23136446 12376 0 950636 0 0 15912 0 23365454 12852 0 997242 0 0 16257 0 23848866 13282 0 1041878 0 0 16384 0 24084782 13666 0 1079790 0 0 16670 0 24508980 14078 0 1106886 0 0 17845 0 26255548 14486 0 1134700 0 0 18097 0 26705634 15064 0 1163308 0 0 18470 0 27283000 15365 0 1198828 0 0 18139 0 26842676 15596 0 1225540 0 0 18792 0 27799564 16000 0 1264568 0 0 17854 178 26454106 16521 0 1298714 0 0 16741 1542 24820298 16770 0 1343328 0 0 input (em0) output packets errs bytes packets errs bytes colls drops 15288 1667 22683486 17231 0 1422690 0 0 15539 1718 23250372 17282 0 1495058 0 0 14379 545 21541954 17364 0 1508696 0 0 14312 1733 21546776 17276 0 1503372 0 0 14269 1744 21498908 17516 0 1508294 0 0 14444 1729 21766812 17175 0 1482130 0 0 15023 1724 22643198 16987 0 1432048 0 0 15279 1703 23036294 16909 0 1395094 0 0 15325 1701 23118536 16938 0 1380268 0 0 15572 1684 23494362 16909 0 1344214 0 0 15798 1699 23845972 16857 0 1303200 0 0 16195 1683 24497790 17059 0 1291586 0 0 16431 1674 24851278 16826 0 1245320 0 0 16683 1643 25231910 16675 0 1204450 0 0 16728 1647 25302534 16672 0 1178930 0 0 16826 1649 25455662 16662 0 1178140 0 0 16760 1653 25352830 16480 0 1161086 0 0 17002 1634 25720672 16423 0 1143508 0 0 16943 1643 25629892 16642 0 1160858 0 0 16995 1644 25708823 16539 0 1153782 0 0 17026 1643 25758462 16606 0 1153342 0 0 However, network throughput didn't change in the two scenarios above. Is there anything that I can test to improve my network throughput. Thanks, Won From won.derick at yahoo.com Fri Nov 14 05:14:14 2008 From: won.derick at yahoo.com (Won De Erick) Date: Fri Nov 14 06:10:38 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage References: <305614.76266.qm@web45809.mail.sp1.yahoo.com> <555333.76711.qm@web45806.mail.sp1.yahoo.com> Message-ID: <674901.2796.qm@web45801.mail.sp1.yahoo.com> > From: Ivan Voras > To: freebsd-hardware@freebsd..org > Cc: freebsd-net@freebsd.org > Sent: Friday, November 14, 2008 8:55:13 PM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > Won De Erick wrote: > > > 17002 1634 25720672 16423 0 1143508 0 0 > > 16943 1643 25629892 16642 0 1160858 0 0 > > 16995 1644 25708823 16539 0 1153782 0 0 > > 17026 1643 25758462 16606 0 1153342 0 0 > > What do you use for generating the traffic? > I used w-get in bombarding tcp traffic w/ thousand of sessions. > > However, network throughput didn't change in the two scenarios above. > > Is there anything that I can test to improve my network throughput. > > I'm not sure but you could maybe try disabling all but one of your CPUs > and see if anything changes. It looks like you have at least 16 CPUs. On > my machine, with 8 CPUs (2xquad core) I get roughly 150,000 PPS before I > hit a similar single-CPU-bound network processing bottleneck (also with > Intel? PRO/1000 PT/Server) - which is too low for my needs so I'm > searching for a solution. In my case I don't see transmission errors. will try this. From julian at elischer.org Fri Nov 14 10:16:28 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Nov 14 10:16:48 2008 Subject: rc.firewall quick change In-Reply-To: <20081114211043.W54700@delplex.bde.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> Message-ID: <491DC07B.6070304@elischer.org> Bruce Evans wrote: > On Fri, 14 Nov 2008, Julian Elischer wrote: > >> Ian Smith wrote: >>> On Thu, 13 Nov 2008, Julian Elischer wrote: >>> > At home I use the following change. >>> > > > basically, instead of doing 8 rules before and after the nat, >>> > use a table and to 1 rule on each side. >>> > > > any objections? >>> >>> Only that if people are already using tables for anything, chances >>> are they've already used table 1 (well, it's the first one I used :) >>> How about using table 127 for this as a rather less likely prior choice? >> >> yes I thought of that.. > > Separate rules provide more statistics. true but generally people don't need to distinguish between those, and if you do then you probably want to log them. > >> in fact it should be ${BLOCKTABLE} and let the user define what he >> wants. (defaulting to 99 or something). > > I use shell variables giving lists of interfaces to be blocked so that > there aren't very many rules: > > %%% > rfc1918n=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 > dmanningn=0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 > > ${fwcmd} add deny log all from any to ${rfc1918n} via ${oif} > ${fwcmd} add deny log all from any to ${dmanningn} via ${oif} > > ... (divert rule) > > ${fwcmd} add deny log all from ${rfc1918n} to any via ${oif} > ${fwcmd} add deny log all from ${dmanningn} to any via ${oif} > %%% > > I use separate lists mainly for documentation purposes but they also > provide separate statistics. > >> Remember though that a user wouldn't be using 'simple' if he's using >> his own tables etc. > > Separate rules are also simplest for documentation purposes. > >>> Apart from that, this will speed up 'simple' on a path every packet >>> takes, which has to be a good thing. > > Are tables faster than lists of addresses? I would expect lists to be > slightly more efficient. I think the table is faster for mor ethan about 8 addresses (so we are borderline) but it's be hard to test.. You however use two rules so that would be slower. In my sites I tend to have other stuff put in those tables too > > Bruce From julian at elischer.org Fri Nov 14 10:25:37 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Nov 14 10:25:43 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <491D6CED.50006@earthlink.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> Message-ID: <491DC28E.80804@elischer.org> Stephen Clark wrote: > Stephen Clark wrote: >>>>> >>>>> 10.0.129.1 FreeBSD workstation >>>>> ^ >>>>> | >>>>> | ethernet >>>>> | >>>>> v >>>>> 10.0.128.1 Freebsd FW "A" >>>>> ^ >>>>> | >>>>> | gre / ipsec >>>>> | >>>>> v >>>>> 192.168.3.1 FreeBSD FW "B" >>>>> ^ >>>>> | >>>>> | ethernet >>>>> | >>>>> v >>>>> 192.168.3.86 linux workstation >>>>> >> Also just using gre's without the >> underlying ipsec tunnels seems to >> work properly. This is the crux of the matter. IPSEC happens INSIDE the IP stack. The IP stack is responsible for the ICMP generation so it is much more likely that there is an interaction there. Now is there an IPSEC rule to make sure that the ICMP packet can get back? It could b ehtat in teh IP stack there is some confusion as to whether the return packet should be encrypted or not and it might get dropped. the code involved is in /sys/netinet and /sys/netipsec but you'll probably regret looking in there ;-) >> >> > Another data point I had been using option FILTER_GIF I tried a kernel > without that option and it behaved the same. > > Steve > From sclark46 at earthlink.net Fri Nov 14 10:37:03 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Fri Nov 14 10:37:15 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <491DC28E.80804@elischer.org> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> Message-ID: <491DC54A.1090907@earthlink.net> Julian Elischer wrote: > Stephen Clark wrote: >> Stephen Clark wrote: > >>>>>> >>>>>> 10.0.129.1 FreeBSD workstation >>>>>> ^ >>>>>> | >>>>>> | ethernet >>>>>> | >>>>>> v >>>>>> 10.0.128.1 Freebsd FW "A" >>>>>> ^ >>>>>> | >>>>>> | gre / ipsec >>>>>> | >>>>>> v >>>>>> 192.168.3.1 FreeBSD FW "B" >>>>>> ^ >>>>>> | >>>>>> | ethernet >>>>>> | >>>>>> v >>>>>> 192.168.3.86 linux workstation >>>>>> > >>> Also just using gre's without the underlying ipsec tunnels seems to >>> work properly. > > > This is the crux of the matter. > IPSEC happens INSIDE the IP stack. The IP stack is responsible for > the ICMP generation so it is much more likely that there is an > interaction there. > > Now is there an IPSEC rule to make sure that the ICMP packet can get > back? It could b ehtat in teh IP stack there is some confusion as to > whether the return packet should be encrypted or not and it might get > dropped. > > the code involved is in /sys/netinet and /sys/netipsec but you'll > probably regret looking in there ;-) > > > >>> >>> >> Another data point I had been using option FILTER_GIF I tried a kernel >> without that option and it behaved the same. >> >> Steve >> > I agree I put a diag in ip_input.c if (ip->ip_ttl <= IPTTLDEC) { icmp_error(m, ICMP_TIMXCEED, ICMP_TIMXCEED_INTRANS, 0, 0); return; and sure enough it is calling icmp_error, but I think it can't figure out how to route the packet back. I been looking at my SPD to see if I can make some adjustment to the policy that would help. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From rnoland at FreeBSD.org Fri Nov 14 10:42:54 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Nov 14 10:43:01 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <491DC28E.80804@elischer.org> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> Message-ID: <1226688153.1719.23.camel@squirrel.corp.cox.com> On Fri, 2008-11-14 at 10:25 -0800, Julian Elischer wrote: > Stephen Clark wrote: > > Stephen Clark wrote: > > >>>>> > >>>>> 10.0.129.1 FreeBSD workstation > >>>>> ^ > >>>>> | > >>>>> | ethernet > >>>>> | > >>>>> v > >>>>> 10.0.128.1 Freebsd FW "A" > >>>>> ^ > >>>>> | > >>>>> | gre / ipsec > >>>>> | > >>>>> v > >>>>> 192.168.3.1 FreeBSD FW "B" > >>>>> ^ > >>>>> | > >>>>> | ethernet > >>>>> | > >>>>> v > >>>>> 192.168.3.86 linux workstation > >>>>> > > >> Also just using gre's without the > >> underlying ipsec tunnels seems to > >> work properly. > > > This is the crux of the matter. > IPSEC happens INSIDE the IP stack. The IP stack is responsible for > the ICMP generation so it is much more likely that there is an > interaction there. > > Now is there an IPSEC rule to make sure that the ICMP packet can get > back? It could b ehtat in teh IP stack there is some confusion as to > whether the return packet should be encrypted or not and it might get > dropped. > > the code involved is in /sys/netinet and /sys/netipsec but you'll > probably regret looking in there ;-) Right, I don't really know the IPSEC code, but I was told by someone who is familiar with it that this is a known problem and that the use of GRE is not relevant. Hopefully he will have a moment to respond to this thread with a bit more detail. robert. > > > >> > >> > > Another data point I had been using option FILTER_GIF I tried a kernel > > without that option and it behaved the same. > > > > Steve > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081114/b5b5f0f7/attachment.pgp From dougb at FreeBSD.org Fri Nov 14 12:34:10 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Nov 14 12:34:16 2008 Subject: rc.firewall quick change In-Reply-To: <491DC07B.6070304@elischer.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> <491DC07B.6070304@elischer.org> Message-ID: <491DDA7F.1040004@FreeBSD.org> Julian Elischer wrote: > I think the table is faster for mor ethan about 8 addresses (so we > are borderline) but it's be hard to test.. You however use two rules > so that would be slower. I'm not a firewall expert so I won't comment on the specifics but I do want to say that as a general rule "it works + fast/efficient" is MUCH more important for default settings than "it works really well" or "it works + more features." For better or worse we live in a world where most users don't read the manuals, and that includes the ones running "benchmarks" with default settings. OTOH I do think it would be entirely appropriate to include a "better" example commented out next to the "fast" default. I take a similar approach with the default named.conf and have had good feedback from users who appreciate pointers to more information when they actually do get curious. hth, Doug -- This .signature sanitized for your protection From julian at elischer.org Fri Nov 14 12:49:50 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Nov 14 12:49:56 2008 Subject: rc.firewall quick change In-Reply-To: <491DDA7F.1040004@FreeBSD.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> <491DC07B.6070304@elischer.org> <491DDA7F.1040004@FreeBSD.org> Message-ID: <491DE46D.8070205@elischer.org> Doug Barton wrote: > Julian Elischer wrote: >> I think the table is faster for mor ethan about 8 addresses (so we >> are borderline) but it's be hard to test.. You however use two rules >> so that would be slower. > > I'm not a firewall expert so I won't comment on the specifics but I do > want to say that as a general rule "it works + fast/efficient" is MUCH > more important for default settings than "it works really well" or "it > works + more features." For better or worse we live in a world where > most users don't read the manuals, and that includes the ones running > "benchmarks" with default settings. I think the change is better from the point of view that it is easier to read (for me) and behaves better. > > OTOH I do think it would be entirely appropriate to include a "better" > example commented out next to the "fast" default. I take a similar > approach with the default named.conf and have had good feedback from > users who appreciate pointers to more information when they actually > do get curious. > > > hth, > > Doug > From freebsd at amc-os.com Fri Nov 14 17:30:09 2008 From: freebsd at amc-os.com (=?iso-8859-1?B?QXVy6WxpZW4gTely6Q==?=) Date: Fri Nov 14 17:30:14 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811150130.mAF1U8CG072911@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: =?iso-8859-1?B?QXVy6WxpZW4gTely6Q==?= To: "Marius Strobl" , Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Sat, 15 Nov 2008 02:01:50 +0100 Hi I installed the patch there are still the same issues : 0x0060: 6965 2d68 656c 6c6d 616e 2d67 726f 7570 ie-hellman-group 0x0070: 2d65 7863 6861 6e67 2c64 6966 6669 652d -exchang,diffie- 0x0080: 2c64 6966 6669 652d 6865 6c6c 6d61 6e2d ,diffie-hellman- 0x0090: 6772 6f75 702d 6578 6368 616e 6765 2d73 group-exchange-s 0x00a0: 6861 312c 6469 6666 6965 2d68 656c 6c6d ha1,diffie-hellm 0x00b0: 616e 2d67 726f 7570 3134 2d73 6861 312c an-group14-sha1, 0x00c0: 6469 6666 6965 2d68 656c 6c6d 616e 2d67 diffie-hellman-g 0x0060: 6965 2d68 656c 6c6d 616e 2d67 726f 7570 ie-hellman-group 0x0070: 2d65 7863 6861 6e67 652d 7368 6132 3536 -exchange-sha256 0x0080: 2c64 6966 6669 652d 6865 6c6c 6d61 6e2d ,diffie-hellman- 0x0090: 6772 6f75 702d 6578 6368 616e 6765 2d73 group-exchange-s 0x00a0: 6861 312c 6469 6666 6965 2d68 656c 6c6d ha1,diffie-hellm 0x00b0: 616e 2d67 726f 7570 3134 2d73 6861 312c an-group14-sha1, 0x00c0: 6469 6666 6965 2d68 656c 6c6d 616e 2d67 diffie-hellman-g I will try to add some debug, don't hesitate to tell me if you have other ideas so i can do more tests. Thanks, Aurélien ----- Original Message ----- From: "Marius Strobl" To: ; Sent: Thursday, November 13, 2008 11:14 PM Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot > Hrm, I could be that the BCM5701 data corruption bug actually is > 64-bit rather than only PCI-X bus specific. Could you please give > the patch at: > http://people.freebsd.org/~marius/bge_5701.diff > a try? From smithi at nimnet.asn.au Fri Nov 14 21:51:58 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Nov 14 21:52:05 2008 Subject: rc.firewall quick change In-Reply-To: <491D406F.5030806@elischer.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <491D406F.5030806@elischer.org> Message-ID: <20081115024024.O70117@sola.nimnet.asn.au> On Fri, 14 Nov 2008, Julian Elischer wrote: > Julian Elischer wrote: > > Ian Smith wrote: > > > On Thu, 13 Nov 2008, Julian Elischer wrote: > > > > At home I use the following change. > > > > > > basically, instead of doing 8 rules before and after the nat, > > > > use a table and to 1 rule on each side. > > > > > > any objections? > > > > > > Only that if people are already using tables for anything, chances are > > > they've already used table 1 (well, it's the first one I used :) How > > > about using table 127 for this as a rather less likely prior choice? > > > > yes I thought of that.. > > in fact it should be ${BLOCKTABLE} and let the user define what he wants. > > (defaulting to 99 or something). I prefer binary, but whatever :) > > Remember though that a user wouldn't be using 'simple' if he's using his > > own tables etc. This is an important point. Please allow me a little pent-up critique: Originally, eg for me over 10 years ago, till recently, the only way to use the 'client' or 'simple' rulesets was to hack rc.firewall, which I did relentlessly, like many people I'm sure .. that is, we treated it more as a starter example, not something that could be used as is. More recent updates have introduced rc vars that concievably make these rulesets usable out of the box, in as much as you could tell a newbie to FreeBSD firewalls and ipfw in particular, "setup these vars for your network, select the 'client' or 'simple' ruleset as appropriate, and you have a fair chance of having a fairly functional and reasonably secure firewall to get yourself online and going until you learn a bit more". Combined with the deprecatory and in many instances just plain erroneous info in the only section of the Handbook that I've felt to try rewriting more or less from scratch - ie the ipfw part of the firewall chapter 31, which suggests some quite (to me) bizarre example rulesets after having dissed using the rc.firewall rulesets out of hand - we're not doing much good at advocating new users trying ipfw, which I think does it some injustice. Not intending here to deprecate pf or ipf in any way. Anyhow, this leaves us with two good reasons that 'client' and 'simple' sections ought to work effectively: secondly as an example illustrating good techniques - and I think your use of a table that the user can add entries to out of band for such as blackholing hosts/nets without having to reconfigure or restart the firewall IS good technique - but firstly as a basically functional and secure minimal firewall in and of itself. It's for both those reasons (and fixing an apparent oversight) that I've offered my unreviewed patch (which I'll do properly by PR if anyone says it's worth pursuing), after years of not being able to fathom supposedly usable firewall configuration for a client or small net, with or without NAT, that has never passed =ANY= ICMP traffic, not even to or from the hosts in one's own net! Am I missing something, thinking that matters, and that functioning path MTU discovery matters? > so here's a slightly improved diff: This may be a bit nitpicky, but how about keeping the firewall_simple_* varset naming consistent, maybe firewall_simple_blocktable or something? The 'workstation' vars have kinda busted that idea anyway, but still .. Also maybe rephrase mentioning the draft-manning-blah after the divert? HTH, Ian From linimon at FreeBSD.org Sat Nov 15 00:01:26 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Nov 15 00:01:32 2008 Subject: kern/128884: [msk] if_msk page fault while in kernel mode Message-ID: <200811150801.mAF81P5L006718@freefall.freebsd.org> Synopsis: [msk] if_msk page fault while in kernel mode Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 15 08:01:13 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128884 From freebsd-net at dino.sk Sat Nov 15 00:14:01 2008 From: freebsd-net at dino.sk (Milan Obuch) Date: Sat Nov 15 00:14:09 2008 Subject: re weird bug In-Reply-To: <20081104014604.GB98154@cdnetworks.co.kr> References: <200810300829.35980.freebsd-net@dino.sk> <200811032339.07412.freebsd-net@dino.sk> <20081104014604.GB98154@cdnetworks.co.kr> Message-ID: <200811150913.16407.freebsd-net@dino.sk> On Tuesday 04 November 2008 02:46:04 Pyun YongHyeon wrote: > On Mon, Nov 03, 2008 at 11:39:06PM +0100, Milan Obuch wrote: > > On Monday 03 November 2008 04:59:08 Pyun YongHyeon wrote: > > > > [ snip ] > > > > > I vaguely guess hardware was not properly initialized. How about > > > this one? > > > http://people.freebsd.org/~yongari/re/re.phy.patch.20081103 > > > > This bug seems again to disappear - csup two days ago, kernel built with > > no patches and everything works. Something like this happened already in > > the > > Yeah, this is one of reason that makes it hard to fix. > > > past. No idea whether it has something with if_re being built as module, > > but if it happens again, I will test this possibility, too. > > Ok. Please let me know your findings. Strange. This trouble occured again. Two days ago, fresh csup, rebuilt whole system, re works only when with verbose boot logging. Yesterday, fresh csup, full rebuild, re works again. There is no change in if_re.c at all - it is dated Sep 9, 2008. This is coming from somewhere else, but I have no idea how this could be debugged. One possibility is there is some weird issue with code or maybe more probably buffer placement in memory, but this is just a shot in the wild, and no idea what means could be used to trace that. It occurs to me from time to time, only with -current, everytime verbose boot logging masks the trouble, at least everytime I tried. Really weird, not predictable. And maybe only difference tracking one per one could give some clue, but this is really time consuming (apply change, rebuild kernel, reboot, test... grrr). Regards, Milan From bzeeb-lists at lists.zabbadoz.net Sat Nov 15 02:40:18 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat Nov 15 02:40:25 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <1226688153.1719.23.camel@squirrel.corp.cox.com> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> Message-ID: <20081115102746.K61259@maildrop.int.zabbadoz.net> On Fri, 14 Nov 2008, Robert Noland wrote: Hi, >>>> Also just using gre's without the >>>> underlying ipsec tunnels seems to >>>> work properly. The reason for this to my knowledge is: http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 or looking at recent freebsd code: http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 Look for M_DECRYPTED. Now what happens in your case: you receive an IPSec ESP packet, which gets decryped, that sets M_DECRYPTED on the mbuf passes through various parts, gets up to gre, gets decapsulated is an IP packet (again) gets to ip_input, TTL expired, icmp_error and it's still the same mbuf that originally got the M_DECRYPTED set. Thus the packets is just freed and you never see anything. So thinking about this has nothing to do with gre (or gif for example as well) in first place. It's arguably that passing it on to another decapsulation the flag should be cleared when entering gre() for example. The other question of course is why we do not send the icmp error back even on plain ipsec? Is it because we could possibly leak information as it's not caught by the policy sending it back? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From linimon at FreeBSD.org Sat Nov 15 03:46:39 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Nov 15 03:46:52 2008 Subject: kern/128840: [igb] page fault under load with igb/LRO Message-ID: <200811151146.mAFBkddn072928@freefall.freebsd.org> Synopsis: [igb] page fault under load with igb/LRO Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 15 11:46:24 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128840 From hartmut.brandt at dlr.de Sat Nov 15 12:22:14 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Sat Nov 15 12:22:21 2008 Subject: TCP and syncache question Message-ID: <491F2C47.4050500@dlr.de> Hi, in tcp_syncache.c:syncache_expand() there is a test that the acknowledgement number and the sequence number of an incoming ACK segment are in the expected range. If they are not, syncache_expand() returns 0 and tcp_input drops the segment and sets a reset. So far so good. But syncache_expand() also deletes the syncache entry, and so destroys the connection. I cannot see why it does it. It seems to me that such a wrong segment should be interpreted as to be from another connection and as such the segment should be ignored (but a reset sent). When the correct ACK comes, the connection could still be established. As it is now, the establishment of incoming connections can seriously be disturbed by someone sending fake ACK packets. The same test (for the ack number, not for the sequence number) is also further down in tcp_input.c:tcp_do_segment() (just after the header prediction stuff) and here the handling is correct: the goto dropwithreset just sends a reset and drops the segment but leaves the connection in the SYN-RECEIVED state. This test is probably never reached now, because of syncache_expand(), though. Maybe I fail to see something obvious, though... harti From bms at incunabulum.net Sat Nov 15 13:30:58 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Sat Nov 15 13:31:05 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot In-Reply-To: <200811132230.mADMUC45038539@freefall.freebsd.org> References: <200811132230.mADMUC45038539@freefall.freebsd.org> Message-ID: <491F3B1B.2040503@incunabulum.net> Marius Strobl wrote: > ... > Hrm, I could be that the BCM5701 data corruption bug actually is > 64-bit rather than only PCI-X bus specific. Could you please give > the patch at: > http://people.freebsd.org/~marius/bge_5701.diff > a try? > This patch looks syntactically OK, though I don't know about bge register set, perhaps it should go in to 7.1. From rpaulo at freebsd.org Sat Nov 15 14:19:58 2008 From: rpaulo at freebsd.org (Rui Paulo) Date: Sat Nov 15 14:20:49 2008 Subject: TCP and syncache question In-Reply-To: <491F2C47.4050500@dlr.de> References: <491F2C47.4050500@dlr.de> Message-ID: <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: > Hi, > > in tcp_syncache.c:syncache_expand() there is a test that the > acknowledgement number and the sequence number of an incoming ACK > segment are in the expected range. If they are not, > syncache_expand() returns 0 and tcp_input drops the segment and sets > a reset. So far so good. But syncache_expand() also deletes the > syncache entry, and so destroys the connection. I cannot see why it > does it. It seems to me that such a wrong segment should be > interpreted as to be from another connection and as such the segment > should be ignored (but a reset sent). When the correct ACK comes, > the connection could still be established. As it is now, the > establishment of incoming connections can seriously be disturbed by > someone sending fake ACK packets. > > The same test (for the ack number, not for the sequence number) is > also further down in tcp_input.c:tcp_do_segment() (just after the > header prediction stuff) and here the handling is correct: the goto > dropwithreset just sends a reset and drops the segment but leaves > the connection in the SYN-RECEIVED state. This test is probably > never reached now, because of syncache_expand(), though. > > Maybe I fail to see something obvious, though... Well, if the RST is sent, why should we keep the syncache entry? Regards, -- Rui Paulo From kayvey at gmail.com Sun Nov 16 00:50:56 2008 From: kayvey at gmail.com (Kayven Riese) Date: Sun Nov 16 00:51:03 2008 Subject: driver support for Belkin F5D7050 v 5xxx ? Message-ID: <28b9b4180811160018q2823d7fap90b546ba444f191d@mail.gmail.com> I just purchased a wireless connection device that connects to my ASUS M6800N laptop dual booting Vista and KV_BSD# uname -a FreeBSD KV_BSD 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 KV_BSD# via USB. While booting on Vista, connection was fine. I investigated my man pages for Belkin modles in the interfaces: V_BSD# man an | grep Belkin KV_BSD# man awi | grep Belkin KV_BSD# man ipw | grep Belkin KV_BSD# set -o vi KV_BSD# man iwi | grep Belkin KV_BSD# man ral | grep Belkin Belkin F5D7000 v3 RT2560 PCI Belkin F5D7010 v2 RT2560 CardBus KV_BSD# man rum | grep Belkin Belkin F5D7050 ver 3 USB Belkin F5D9050 ver 3 USB KV_BSD# man ural | grep Belkin Belkin F5D7050 v2000 USB KV_BSD# man wi | grep Belkin Belkin F5D6000 (a rebadged WL11000P) KV_BSD# man zyd | grep Belkin Belkin F5D7050 v.4000 KV_BSD# and found some websites that made me compare a serial number that I correlated to some information on the Belkin website and came to the conclusion that my device is a newer version than appears in the above list because of this information: K7SF5D7050E corresponds to version 5xxx That serial number is written on the device. There were no unfamiliar results of ifconfig: KV_BSD# ifconfig bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:11:d8:22:c9:91 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (100baseTX ) status: active fwe0: flags=8802 metric 0 mtu 1500 options=8 ether 02:e0:18:26:4c:e9 ch 1 dma -1 fwip0: flags=8802 metric 0 mtu 1500 lladdr 0.e0.18.0.3.26.4c.e9.a.2.ff.fe.0.0.0.0 plip0: flags=108810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 KV_BSD# I attempted to use the ndisgen utility with the driver disk mounted on "/mnt/drive" KV_BSD# pwd /mnt/drive KV_BSD# ls AUTORUN.INF Belkin.ico Installer.exe UserManual Acrobat Reader InstallationFiles Installer.ini KV_BSD# cd InstallationFiles KV_BSD# ls Belkin.bmp Setup.exe VistaX64 WinXP2K data1.hdr layout.bin ISSetup.dll Setup.ini VistaX86 _Setup.dll data2.cab SETUP.ISS Setup.inx WinX64 data1.cab ikernel.ex_ KV_BSD# ls WinXP2K BLKWGU.inf BLKWGU.sys blkwgu.cat twice, once using the BLKWGU.inf and BLKWGU.sys files from the WinXP2K directory and again adding the blkwgu.cat file using the menu that ndisgen gives, and both times it terminated with success: ================================================================== ------------------ Windows(r) driver converter ------------------- ================================================================== Kernel module generation The script will now try to generate the kernel driver module. This is the last step. Once this module is generated, you should be able to load it just like any other FreeBSD driver module. Press enter to compile the stub module and generate the driver module now: Generating Makefile... done. Building kernel module... done. Cleaning up... done. The file BLKWGU_sys.ko has been successfully generated. You can kldload this module to get started. Press return to exit. When I tried to use the kldload command in both cases, the system rebooted. I messed around with /boot/loader.conf, including many of the interfaces that were noted above "man if | grep Belkin," and right now this is what it looks like: KV_BSD# cat /boot/loader.conf hint.ichss.0.disabled="1" W32DRIVER_load="YES" wlan_load="YES" firmware_load="YES" if_zyd_load="YES" wlan_scan_ap_load="YES" wlan_scan_sta_load="YES" wlan_wep_load="YES" wlan_ccmp_load="YES" wlan_tkip_load="YES" I note that the device is showing up in dmesg KV_BSD# dmesg | grep Belkin ugen0: on uhub3 ugen0: on uhub3 ugen0: on uhub3 ugen0: on uhub3 KV_BSD# some other info.. KV_BSD# pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x186a1043 chip=0x33408086 rev=0x21 hdr=0x00 vendor = 'Intel Cor . . none1@pci0:0:31:6: class=0x070300 card=0x18261043 chip=0x24c68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller' class = simple comms subclass = generic modem vgapci0@pci0:1:0:0: class=0x030000 card=0x17721043 chip=0x4e501002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Mobility Radeon 9700 (M10 NP) (RV350)' class = display subclass = VGA bge0@pci0:2:0:0: class=0x020000 card=0x17351043 chip=0x169c14e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5788 Broadcom NetLink (TM) Gigabit Ethernet' class = network subclass = ethernet cbb0@pci0:2:1:0: class=0x060700 card=0x18641043 chip=0x04761180 rev=0xac hdr=0x02 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh R/RL/5C476(II)' class = bridge subclass = PCI-CardBus cbb1@pci0:2:1:1: class=0x060700 card=0x18641043 chip=0x04761180 rev=0xac hdr=0x02 vendor = 'Ricoh Company, Ltd.' device = 'unknown Ricoh R/RL/5C476(II)' class = bridge subclass = PCI-CardBus fwohci0@pci0:2:1:2: class=0x0c0010 card=0x18671043 chip=0x05521180 rev=0x04 hdr=0x00 vendor = 'Ricoh Company, Ltd.' device = 'RL5c552 IEEE-1394 Controller' class = serial bus subclass = FireWire none2@pci0:2:2:0: class=0x028000 card=0x10008086 chip=0x42238086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = '2915ABG Intel (R) PRO/Wireless 2200BG Network Connection, (R) PRO/Wireless 2915ABG Network Connection' class = network KV_BSD# usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 addr 2: low speed, power 100 mA, config 1, USB Optical Mouse(0xc019), Logitech(0x046d), rev 43.01 port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 addr 2: high speed, power 500 mA, config 1, Belkin Wireless G USB Adapter(0x705e), vendor 0x050d(0x050d), rev 2.00 port 3 powered port 4 powered port 5 powered port 6 powered KV_BSD# exit Thanks to anyone in advance who gives me the time of day. I looked at some of the archives and felt these two lists seemed appropriate. Forgive me if I misused the lists. *----------------------------------------------------------* Kayven Riese, BSCS, MS (Physiology and Biophysics) (415) 902 5513 cellular http://kayve.net Webmaster http://ChessYoga.org *----------------------------------------------------------* From onemda at gmail.com Sun Nov 16 03:58:59 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Sun Nov 16 03:59:06 2008 Subject: driver support for Belkin F5D7050 v 5xxx ? In-Reply-To: <28b9b4180811160018q2823d7fap90b546ba444f191d@mail.gmail.com> References: <28b9b4180811160018q2823d7fap90b546ba444f191d@mail.gmail.com> Message-ID: <3a142e750811160335y6867d362k93a525774bc3667@mail.gmail.com> On 11/16/08, Kayven Riese wrote: > I just purchased a wireless connection device that connects to my ASUS > M6800N laptop dual > booting Vista and > > KV_BSD# uname -a > FreeBSD KV_BSD 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 > KV_BSD# > > via USB. > > While booting on Vista, connection was fine. I investigated my man pages > for Belkin modles in > the interfaces: > V_BSD# man an | grep Belkin > KV_BSD# man awi | grep Belkin > KV_BSD# man ipw | grep Belkin > KV_BSD# set -o vi > KV_BSD# man iwi | grep Belkin > KV_BSD# man ral | grep Belkin > Belkin F5D7000 v3 RT2560 PCI > Belkin F5D7010 v2 RT2560 CardBus > KV_BSD# man rum | grep Belkin > Belkin F5D7050 ver 3 USB > Belkin F5D9050 ver 3 USB > KV_BSD# man ural | grep Belkin > Belkin F5D7050 v2000 USB > KV_BSD# man wi | grep Belkin > Belkin F5D6000 (a rebadged WL11000P) > KV_BSD# man zyd | grep Belkin > Belkin F5D7050 v.4000 > KV_BSD# > > and found some websites that made me compare a serial number that I > correlated to some > information on the Belkin website and came to the conclusion that my device > is a newer > version than appears in the above list because of this information: > > K7SF5D7050E corresponds to version 5xxx > > That serial number is written on the device. > > There were no unfamiliar results of ifconfig: > > > > KV_BSD# ifconfig > bge0: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:11:d8:22:c9:91 > inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect (100baseTX ) > status: active > fwe0: flags=8802 metric 0 mtu 1500 > options=8 > ether 02:e0:18:26:4c:e9 > ch 1 dma -1 > fwip0: flags=8802 metric 0 mtu 1500 > lladdr 0.e0.18.0.3.26.4c.e9.a.2.ff.fe.0.0.0.0 > plip0: flags=108810 metric 0 mtu > 1500 > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > KV_BSD# > > I attempted to use the ndisgen utility with the driver disk mounted on > "/mnt/drive" > Currently ndis on freebsd doesnt support usb cards at all. There is patch available for CURRENT that is considered experimental and make possible to use ndis on FreeBSD with usb cards. > KV_BSD# pwd > /mnt/drive > KV_BSD# ls > AUTORUN.INF Belkin.ico Installer.exe UserManual > Acrobat Reader InstallationFiles Installer.ini > KV_BSD# cd InstallationFiles > KV_BSD# ls > Belkin.bmp Setup.exe VistaX64 WinXP2K data1.hdr > layout.bin > ISSetup.dll Setup.ini VistaX86 _Setup.dll data2.cab > SETUP.ISS Setup.inx WinX64 data1.cab ikernel.ex_ > KV_BSD# ls WinXP2K > BLKWGU.inf BLKWGU.sys blkwgu.cat > > twice, once using the BLKWGU.inf and BLKWGU.sys files from the WinXP2K > directory and again > adding the blkwgu.cat file using the menu that ndisgen gives, and both times > it terminated > with success: > > ================================================================== > ------------------ Windows(r) driver converter ------------------- > ================================================================== > > Kernel module generation > > > The script will now try to generate the kernel driver module. > This is the last step. Once this module is generated, you should > be able to load it just like any other FreeBSD driver module. > > Press enter to compile the stub module and generate the driver > module now: > > Generating Makefile... done. > Building kernel module... done. > Cleaning up... done. > > The file BLKWGU_sys.ko has been successfully generated. > You can kldload this module to get started. > > Press return to exit. > > When I tried to use the kldload command in both cases, the system rebooted. > > I messed around with /boot/loader.conf, including many of the interfaces > that were > noted above "man if | grep Belkin," and right now this is what it looks > like: > KV_BSD# cat /boot/loader.conf > hint.ichss.0.disabled="1" > W32DRIVER_load="YES" > wlan_load="YES" > firmware_load="YES" > if_zyd_load="YES" > wlan_scan_ap_load="YES" > wlan_scan_sta_load="YES" > wlan_wep_load="YES" > wlan_ccmp_load="YES" > wlan_tkip_load="YES" > > I note that the device is showing up in dmesg > > KV_BSD# dmesg | grep Belkin > ugen0: 2.00/2.00, addr 2> on uhub3 > ugen0: 2.00/2.00, addr 2> on uhub3 > ugen0: 2.00/2.00, addr 2> on uhub3 > ugen0: 2.00/2.00, addr 2> on uhub3 > KV_BSD# > > > some other info.. > > > KV_BSD# pciconf -lv > hostb0@pci0:0:0:0: class=0x060000 card=0x186a1043 chip=0x33408086 > rev=0x21 hdr=0x00 > vendor = 'Intel Cor > . > > . > > none1@pci0:0:31:6: class=0x070300 card=0x18261043 chip=0x24c68086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem > Controller' > class = simple comms > subclass = generic modem > vgapci0@pci0:1:0:0: class=0x030000 card=0x17721043 chip=0x4e501002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Mobility Radeon 9700 (M10 NP) (RV350)' > class = display > subclass = VGA > bge0@pci0:2:0:0: class=0x020000 card=0x17351043 chip=0x169c14e4 rev=0x03 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5788 Broadcom NetLink (TM) Gigabit Ethernet' > class = network > subclass = ethernet > cbb0@pci0:2:1:0: class=0x060700 card=0x18641043 chip=0x04761180 rev=0xac > hdr=0x02 > vendor = 'Ricoh Company, Ltd.' > device = 'unknown Ricoh R/RL/5C476(II)' > class = bridge > subclass = PCI-CardBus > cbb1@pci0:2:1:1: class=0x060700 card=0x18641043 chip=0x04761180 rev=0xac > hdr=0x02 > vendor = 'Ricoh Company, Ltd.' > device = 'unknown Ricoh R/RL/5C476(II)' > class = bridge > subclass = PCI-CardBus > fwohci0@pci0:2:1:2: class=0x0c0010 card=0x18671043 chip=0x05521180 > rev=0x04 hdr=0x00 > vendor = 'Ricoh Company, Ltd.' > device = 'RL5c552 IEEE-1394 Controller' > class = serial bus > subclass = FireWire > none2@pci0:2:2:0: class=0x028000 card=0x10008086 chip=0x42238086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = '2915ABG Intel (R) PRO/Wireless 2200BG Network Connection, > (R) PRO/Wireless 2915ABG Network Connection' > class = network > KV_BSD# usbdevs -v > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), > Intel(0x0000), rev 1.00 > port 1 powered > port 2 powered > Controller /dev/usb1: > addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), > Intel(0x0000), rev 1.00 > port 1 addr 2: low speed, power 100 mA, config 1, USB Optical > Mouse(0xc019), Logitech(0x046d), rev 43.01 > port 2 powered > Controller /dev/usb2: > addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), > Intel(0x0000), rev 1.00 > port 1 powered > port 2 powered > Controller /dev/usb3: > addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), > Intel(0x0000), rev 1.00 > port 1 powered > port 2 addr 2: high speed, power 500 mA, config 1, Belkin Wireless G USB > Adapter(0x705e), vendor 0x050d(0x050d), rev 2.00 > port 3 powered > port 4 powered > port 5 powered > port 6 powered > KV_BSD# exit > > Thanks to anyone in advance who gives me the time of day. I looked at some > of the archives and felt these two > lists seemed appropriate. Forgive me if I misused the lists. > > > *----------------------------------------------------------* > Kayven Riese, BSCS, > MS (Physiology and Biophysics) > (415) 902 5513 cellular > http://kayve.net > Webmaster http://ChessYoga.org > *----------------------------------------------------------* > _______________________________________________ > freebsd-mobile@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mobile > To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org" > From yonyossef.lists at gmail.com Sun Nov 16 04:27:38 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Sun Nov 16 04:27:50 2008 Subject: HW VLAN Filtering on FreeBSD 6.3 + 7.0 In-Reply-To: <20081116121345.GA952@icarus.home.lan> References: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> <20081116121345.GA952@icarus.home.lan> Message-ID: <20def4870811160427k1a718a8es9287220c03f71f26@mail.gmail.com> > > > I would like to enable my NIC HW VLAN filtering, is there any way for > my > > driver to access the OS vlan table? (something like vlan_group_get_device > on > > linux) > > > > I understood from previous investigation that on FreeBSD 6.3 and 7.0 > there's > > no ioctl informing the driver of vlan addition/removal. Is that correct? > > Man pages to check out: vlan(4) and ifconfig(8). I'm pretty sure the > vlan tagging feature is per-driver. > Also, the vlan(4) list of supported drivers is out of date (for example, > em(4) is missing), so be sure to check the man page of your NIC driver. Sorry, i explained myself pretty bad. I'm working on an Ethernet driver for FreeBSD. The VLAN hw tagging is already working properly, but my nic is capable of holding a vlan table on hw, filtering vlans on it's own. I need to find a way to update that hw table. one way is to recieve a ioctl from the OS of it's vlan table event (add, remove). I can't find such ioctl. second is to have a direct access from the driver to the OS vlan table. I'm not familiar with the interface or if it's possible at all, and that is my actual question. Thanks Yony From koitsu at FreeBSD.org Sun Nov 16 04:29:46 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Nov 16 04:29:54 2008 Subject: HW VLAN Filtering on FreeBSD 6.3 + 7.0 In-Reply-To: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> References: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> Message-ID: <20081116121345.GA952@icarus.home.lan> On Sun, Nov 16, 2008 at 02:03:54PM +0200, Yony Yossef wrote: > I would like to enable my NIC HW VLAN filtering, is there any way for my > driver to access the OS vlan table? (something like vlan_group_get_device on > linux) > > I understood from previous investigation that on FreeBSD 6.3 and 7.0 there's > no ioctl informing the driver of vlan addition/removal. Is that correct? Man pages to check out: vlan(4) and ifconfig(8). I'm pretty sure the vlan tagging feature is per-driver. Also, the vlan(4) list of supported drivers is out of date (for example, em(4) is missing), so be sure to check the man page of your NIC driver. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From yonyossef.lists at gmail.com Sun Nov 16 04:35:38 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Sun Nov 16 04:35:44 2008 Subject: HW VLAN Filtering on FreeBSD 6.3 + 7.0 Message-ID: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> Hi All, I would like to enable my NIC HW VLAN filtering, is there any way for my driver to access the OS vlan table? (something like vlan_group_get_device on linux) I understood from previous investigation that on FreeBSD 6.3 and 7.0 there's no ioctl informing the driver of vlan addition/removal. Is that correct? Thanks, Yony From koitsu at freebsd.org Sun Nov 16 04:49:06 2008 From: koitsu at freebsd.org (Jeremy Chadwick) Date: Sun Nov 16 04:49:12 2008 Subject: HW VLAN Filtering on FreeBSD 6.3 + 7.0 In-Reply-To: <20def4870811160427k1a718a8es9287220c03f71f26@mail.gmail.com> References: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> <20081116121345.GA952@icarus.home.lan> <20def4870811160427k1a718a8es9287220c03f71f26@mail.gmail.com> Message-ID: <20081116123548.GA1531@icarus.home.lan> On Sun, Nov 16, 2008 at 02:27:36PM +0200, Yony Yossef wrote: > > > I would like to enable my NIC HW VLAN filtering, is there any way for > > my > > > driver to access the OS vlan table? (something like vlan_group_get_device > > on > > > linux) > > > > > > I understood from previous investigation that on FreeBSD 6.3 and 7.0 > > there's > > > no ioctl informing the driver of vlan addition/removal. Is that correct? > > > > Man pages to check out: vlan(4) and ifconfig(8). I'm pretty sure the > > vlan tagging feature is per-driver. > > > Also, the vlan(4) list of supported drivers is out of date (for example, > > em(4) is missing), so be sure to check the man page of your NIC driver. > > Sorry, i explained myself pretty bad. I'm working on an Ethernet driver for > FreeBSD. > The VLAN hw tagging is already working properly, but my nic is capable of > holding a vlan table on hw, filtering vlans on it's own. > I need to find a way to update that hw table. > one way is to recieve a ioctl from the OS of it's vlan table event (add, > remove). I can't find such ioctl. > second is to have a direct access from the driver to the OS vlan table. I'm > not familiar with the interface or if it's possible at all, and that is my > actual question. This question should go to freebsd-hackers. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From hartmut.brandt at dlr.de Sun Nov 16 05:02:26 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Sun Nov 16 05:02:34 2008 Subject: TCP and syncache question In-Reply-To: <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> Message-ID: <49201859.2080605@dlr.de> Rui Paulo wrote: > > On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: > >> Hi, >> >> in tcp_syncache.c:syncache_expand() there is a test that the >> acknowledgement number and the sequence number of an incoming ACK >> segment are in the expected range. If they are not, syncache_expand() >> returns 0 and tcp_input drops the segment and sets a reset. So far so >> good. But syncache_expand() also deletes the syncache entry, and so >> destroys the connection. I cannot see why it does it. It seems to me >> that such a wrong segment should be interpreted as to be from another >> connection and as such the segment should be ignored (but a reset >> sent). When the correct ACK comes, the connection could still be >> established. As it is now, the establishment of incoming connections >> can seriously be disturbed by someone sending fake ACK packets. >> >> The same test (for the ack number, not for the sequence number) is >> also further down in tcp_input.c:tcp_do_segment() (just after the >> header prediction stuff) and here the handling is correct: the goto >> dropwithreset just sends a reset and drops the segment but leaves the >> connection in the SYN-RECEIVED state. This test is probably never >> reached now, because of syncache_expand(), though. >> >> Maybe I fail to see something obvious, though... > > > Well, if the RST is sent, why should we keep the syncache entry? Because this effectively destroys the connection in SYN-RECEIVED which is wrong according to RFC793. On page 69 the handling of incoming segments for connections in SYN-RECEIVED is described: first you check the sequence number and, if it is wrong, you send an RST (unless the RST bit is set in the incoming segment), but otherwise ignore the segment. A segment with a bad sequence number in SYN-RECEIVED is either forged or from an old connection. In both cases you don't want to destroy the embryonic connection, because the correct ACK from the correct peer may still arrive. harti From marius at alchemy.franken.de Sun Nov 16 13:50:04 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Sun Nov 16 13:50:11 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811162150.mAGLo4UJ045453@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= Cc: bug-followup@FreeBSD.org Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Sun, 16 Nov 2008 22:45:33 +0100 On Sat, Nov 15, 2008 at 02:01:50AM +0100, Aurlien Mr wrote: > Hi > I installed the patch there are still the same issues : > > 0x0060: 6965 2d68 656c 6c6d 616e 2d67 726f 7570 ie-hellman-group > 0x0070: 2d65 7863 6861 6e67 2c64 6966 6669 652d -exchang,diffie- > 0x0080: 2c64 6966 6669 652d 6865 6c6c 6d61 6e2d ,diffie-hellman- > 0x0090: 6772 6f75 702d 6578 6368 616e 6765 2d73 group-exchange-s > 0x00a0: 6861 312c 6469 6666 6965 2d68 656c 6c6d ha1,diffie-hellm > 0x00b0: 616e 2d67 726f 7570 3134 2d73 6861 312c an-group14-sha1, > 0x00c0: 6469 6666 6965 2d68 656c 6c6d 616e 2d67 diffie-hellman-g > > 0x0060: 6965 2d68 656c 6c6d 616e 2d67 726f 7570 ie-hellman-group > 0x0070: 2d65 7863 6861 6e67 652d 7368 6132 3536 -exchange-sha256 > 0x0080: 2c64 6966 6669 652d 6865 6c6c 6d61 6e2d ,diffie-hellman- > 0x0090: 6772 6f75 702d 6578 6368 616e 6765 2d73 group-exchange-s > 0x00a0: 6861 312c 6469 6666 6965 2d68 656c 6c6d ha1,diffie-hellm > 0x00b0: 616e 2d67 726f 7570 3134 2d73 6861 312c an-group14-sha1, > 0x00c0: 6469 6666 6965 2d68 656c 6c6d 616e 2d67 diffie-hellman-g > > I will try to add some debug, don't hesitate to tell me if you have other > ideas so i can do more tests. Ok, thanks for testing anyway. I still think that this isn't really a driver bug though but you are hitting some hardware-related problem like f.e. a silicon bug and the question is how to work around it. Looking at the bge(4) versions of the other BSDs and the corresponding Linux and OpenSolaris drivers I can't spot a such a workaround apart from the already known PCI-X issue, unfortunately. The only other thing that comes to my mind is that you might suffer from sort of the opposite of the problem worked around by ti_64bitslot_war() (the NICs driven by ti(4) are the predecessors of those supported by bge(4)). Given that this also involves the BIOS that could then explain why you're see first person to hit this problem. Could you please instrument bge(4) to print the content of the BGE_PCI_PCISTATE register and report back which values it's initialized to depending on which type of slot the card is plugged into? Marius From glavoie at gmail.com Sun Nov 16 15:28:02 2008 From: glavoie at gmail.com (Gabriel Lavoie) Date: Sun Nov 16 15:28:09 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance Message-ID: Hello, I recently built a new system to use as a home server. This system has an Intel Pentium Dual Core E5200, 4GB RAM and an Asus P5KPL-CM motherboard which has an Atheros L1E network adapter, not yet supported on FreeBSD. For now, I use a Realtek 8139 PCI adapter that uses the rl(4) driver, but the upload performances are really poor (under 1 MB/sec). Is there any way to improve the performance with this driver? This adapter was in a Linux system with a Pentium III processor before and I could upload/download at around 10 MB/sec in my local network with no problem at all. Thanks! -- Gabriel Lavoie glavoie@gmail.com From rpaulo at freebsd.org Sun Nov 16 16:01:58 2008 From: rpaulo at freebsd.org (Rui Paulo) Date: Sun Nov 16 16:02:04 2008 Subject: TCP and syncache question In-Reply-To: <49201859.2080605@dlr.de> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> Message-ID: <27C5037E-25AB-4EA5-B4DA-445A4B4218F1@freebsd.org> On 16 Nov 2008, at 12:55, Hartmut Brandt wrote: > Rui Paulo wrote: >> >> On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: >> >>> Hi, >>> >>> in tcp_syncache.c:syncache_expand() there is a test that the >>> acknowledgement number and the sequence number of an incoming ACK >>> segment are in the expected range. If they are not, >>> syncache_expand() returns 0 and tcp_input drops the segment and >>> sets a reset. So far so good. But syncache_expand() also deletes >>> the syncache entry, and so destroys the connection. I cannot see >>> why it does it. It seems to me that such a wrong segment should be >>> interpreted as to be from another connection and as such the >>> segment should be ignored (but a reset sent). When the correct ACK >>> comes, the connection could still be established. As it is now, >>> the establishment of incoming connections can seriously be >>> disturbed by someone sending fake ACK packets. >>> >>> The same test (for the ack number, not for the sequence number) is >>> also further down in tcp_input.c:tcp_do_segment() (just after the >>> header prediction stuff) and here the handling is correct: the >>> goto dropwithreset just sends a reset and drops the segment but >>> leaves the connection in the SYN-RECEIVED state. This test is >>> probably never reached now, because of syncache_expand(), though. >>> >>> Maybe I fail to see something obvious, though... >> >> >> Well, if the RST is sent, why should we keep the syncache entry? > > Because this effectively destroys the connection in SYN-RECEIVED > which is wrong according to RFC793. On page 69 the handling of > incoming segments for connections in SYN-RECEIVED is described: > first you check the sequence number and, if it is wrong, you send an > RST (unless the RST bit is set in the incoming segment), but > otherwise ignore the segment. > > A segment with a bad sequence number in SYN-RECEIVED is either > forged or from an old connection. In both cases you don't want to > destroy the embryonic connection, because the correct ACK from the > correct peer may still arrive. That clarifies your initial email. You're probably right, I'll try to find out when the bug was introduced. Thanks, -- Rui Paulo From pyunyh at gmail.com Sun Nov 16 16:36:13 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Nov 16 16:36:26 2008 Subject: HW VLAN Filtering on FreeBSD 6.3 + 7.0 In-Reply-To: <20def4870811160427k1a718a8es9287220c03f71f26@mail.gmail.com> References: <20def4870811160403i67f9e8d6i1a52e93d1b68c5ad@mail.gmail.com> <20081116121345.GA952@icarus.home.lan> <20def4870811160427k1a718a8es9287220c03f71f26@mail.gmail.com> Message-ID: <20081117003402.GA50872@cdnetworks.co.kr> On Sun, Nov 16, 2008 at 02:27:36PM +0200, Yony Yossef wrote: > > > > > I would like to enable my NIC HW VLAN filtering, is there any way for > > my > > > driver to access the OS vlan table? (something like vlan_group_get_device > > on > > > linux) > > > > > > I understood from previous investigation that on FreeBSD 6.3 and 7.0 > > there's > > > no ioctl informing the driver of vlan addition/removal. Is that correct? > > > > Man pages to check out: vlan(4) and ifconfig(8). I'm pretty sure the > > vlan tagging feature is per-driver. > > > > Also, the vlan(4) list of supported drivers is out of date (for example, > > em(4) is missing), so be sure to check the man page of your NIC driver. > > > Sorry, i explained myself pretty bad. I'm working on an Ethernet driver for > FreeBSD. > The VLAN hw tagging is already working properly, but my nic is capable of > holding a vlan table on hw, filtering vlans on it's own. > I need to find a way to update that hw table. > one way is to recieve a ioctl from the OS of it's vlan table event (add, > remove). I can't find such ioctl. FreeBSD doesn't use ioctl to manipulate VLAN HW table. > second is to have a direct access from the driver to the OS vlan table. I'm > not familiar with the interface or if it's possible at all, and that is my > actual question. > See EVENT_HANDLER(9) and igb(4) for working example. -- Regards, Pyun YongHyeon From pyunyh at gmail.com Sun Nov 16 16:41:03 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Nov 16 16:41:09 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: References: Message-ID: <20081117003856.GB50872@cdnetworks.co.kr> On Sun, Nov 16, 2008 at 06:01:58PM -0500, Gabriel Lavoie wrote: > Hello, > I recently built a new system to use as a home server. This system has > an Intel Pentium Dual Core E5200, 4GB RAM and an Asus P5KPL-CM motherboard > which has an Atheros L1E network adapter, not yet supported on FreeBSD. For ale(4) was committed to HEAD. If you're using lastest stable/7 see the following URL. http://people.freebsd.org/~yongari/ale/README > now, I use a Realtek 8139 PCI adapter that uses the rl(4) driver, but the > upload performances are really poor (under 1 MB/sec). Is there any way to > improve the performance with this driver? This adapter was in a Linux system > with a Pentium III processor before and I could upload/download at around 10 > MB/sec in my local network with no problem at all. > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. How about rl(4) in HEAD? I guess it would build with minor modification. -- Regards, Pyun YongHyeon From glavoie at gmail.com Sun Nov 16 16:47:34 2008 From: glavoie at gmail.com (Gabriel Lavoie) Date: Sun Nov 16 16:47:41 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: <20081117003856.GB50872@cdnetworks.co.kr> References: <20081117003856.GB50872@cdnetworks.co.kr> Message-ID: I guess I'll have to try both solutions! Thanks for your help. Gabriel 2008/11/16 Pyun YongHyeon > On Sun, Nov 16, 2008 at 06:01:58PM -0500, Gabriel Lavoie wrote: > > Hello, > > I recently built a new system to use as a home server. This system > has > > an Intel Pentium Dual Core E5200, 4GB RAM and an Asus P5KPL-CM > motherboard > > which has an Atheros L1E network adapter, not yet supported on FreeBSD. > For > > ale(4) was committed to HEAD. If you're using lastest stable/7 > see the following URL. > http://people.freebsd.org/~yongari/ale/README > > > now, I use a Realtek 8139 PCI adapter that uses the rl(4) driver, but > the > > upload performances are really poor (under 1 MB/sec). Is there any way > to > > improve the performance with this driver? This adapter was in a Linux > system > > with a Pentium III processor before and I could upload/download at > around 10 > > MB/sec in my local network with no problem at all. > > > > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > How about rl(4) in HEAD? I guess it would build with minor > modification. > > -- > Regards, > Pyun YongHyeon > -- Gabriel Lavoie glavoie@gmail.com From pyunyh at gmail.com Sun Nov 16 18:32:27 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Nov 16 18:32:33 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: <957411.42240.qm@web39101.mail.mud.yahoo.com> References: <957411.42240.qm@web39101.mail.mud.yahoo.com> Message-ID: <20081117023024.GE50872@cdnetworks.co.kr> On Sun, Nov 16, 2008 at 06:26:34PM -0800, bf wrote: > > > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > > How about rl(4) in HEAD? I guess it would build with minor > > modification. > > > > -- > > Regards, > > Pyun YongHyeon > > I meant to ask about this: I think you are referring to r184240-3 committed > around Oct. 25, partly in response to PR kern/128143, right? Is there any Yes. > plan to merge these changes to RELENG_7, either before or after the > release of 7.1? > I'll MFC the change after 7.1-RELEASE. Did the change set r184240 fix your issue? -- Regards, Pyun YongHyeon From bf2006a at yahoo.com Sun Nov 16 18:53:17 2008 From: bf2006a at yahoo.com (bf) Date: Sun Nov 16 18:53:48 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance Message-ID: <957411.42240.qm@web39101.mail.mud.yahoo.com> > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > How about rl(4) in HEAD? I guess it would build with minor > modification. > > -- > Regards, > Pyun YongHyeon I meant to ask about this: I think you are referring to r184240-3 committed around Oct. 25, partly in response to PR kern/128143, right? Is there any plan to merge these changes to RELENG_7, either before or after the release of 7.1? Thanks, b. From glavoie at gmail.com Sun Nov 16 19:03:16 2008 From: glavoie at gmail.com (Gabriel Lavoie) Date: Sun Nov 16 19:03:23 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: <20081117023024.GE50872@cdnetworks.co.kr> References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> Message-ID: All right! rl(4) from HEAD solved my problem! I now get a solid 11.2 MB/sec file transfer, on both directions. I found about this problem because my Samba share was too slow. The Samba problem is solved. Thanks! 2008/11/16 Pyun YongHyeon > On Sun, Nov 16, 2008 at 06:26:34PM -0800, bf wrote: > > > > > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > > > How about rl(4) in HEAD? I guess it would build with minor > > > modification. > > > > > > -- > > > Regards, > > > Pyun YongHyeon > > > > I meant to ask about this: I think you are referring to r184240-3 > committed > > around Oct. 25, partly in response to PR kern/128143, right? Is there > any > > Yes. > > > plan to merge these changes to RELENG_7, either before or after the > > release of 7.1? > > > > I'll MFC the change after 7.1-RELEASE. > Did the change set r184240 fix your issue? > > -- > Regards, > Pyun YongHyeon > _______________________________________________ > 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" > -- Gabriel Lavoie glavoie@gmail.com From scrappy at hub.org Sun Nov 16 19:23:51 2008 From: scrappy at hub.org (Marc G. Fournier) Date: Sun Nov 16 19:23:58 2008 Subject: bridged networking disappears ... Message-ID: <4EF60FA893CC822B1EDE2FCB@ganymede.hub.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm playing with bridges right now, under FreeBSD 7.x, to connect a QEMU env to the internet ... works like a charm, except periodically the network just becomes unpingable ... I've setup a cron within the QEMU environment to ping once a minute, which seems to 'fix' it, but that sounds more a bandaid then a fix ... Is this normal (I can't see how) or am I missing something with setting up the bridge? - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkg48IACgkQ4QvfyHIvDvPR8QCfWvlQzq8R0dq/Bijr25EzZdBK ULMAoI4h+yv44mFHPN6ivMcj/xLcLDl4 =tusp -----END PGP SIGNATURE----- From pyunyh at gmail.com Sun Nov 16 19:46:31 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Nov 16 19:46:37 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> Message-ID: <20081117034428.GG50872@cdnetworks.co.kr> On Sun, Nov 16, 2008 at 10:03:15PM -0500, Gabriel Lavoie wrote: > All right! rl(4) from HEAD solved my problem! I now get a solid 11.2 MB/sec > file transfer, on both directions. I found about this problem because my > Samba share was too slow. The Samba problem is solved. > Glad to hear that. :-) > Thanks! > > 2008/11/16 Pyun YongHyeon > > > On Sun, Nov 16, 2008 at 06:26:34PM -0800, bf wrote: > > > > > > > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > > > > How about rl(4) in HEAD? I guess it would build with minor > > > > modification. > > > > > > > > -- > > > > Regards, > > > > Pyun YongHyeon > > > > > > I meant to ask about this: I think you are referring to r184240-3 > > committed > > > around Oct. 25, partly in response to PR kern/128143, right? Is there > > any > > > > Yes. > > > > > plan to merge these changes to RELENG_7, either before or after the > > > release of 7.1? > > > > > > > I'll MFC the change after 7.1-RELEASE. > > Did the change set r184240 fix your issue? > > > > -- -- Regards, Pyun YongHyeon From pyunyh at gmail.com Sun Nov 16 20:18:37 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Nov 16 20:18:44 2008 Subject: re weird bug In-Reply-To: <200811150913.16407.freebsd-net@dino.sk> References: <200810300829.35980.freebsd-net@dino.sk> <200811032339.07412.freebsd-net@dino.sk> <20081104014604.GB98154@cdnetworks.co.kr> <200811150913.16407.freebsd-net@dino.sk> Message-ID: <20081117041633.GI50872@cdnetworks.co.kr> On Sat, Nov 15, 2008 at 09:13:15AM +0100, Milan Obuch wrote: > On Tuesday 04 November 2008 02:46:04 Pyun YongHyeon wrote: > > On Mon, Nov 03, 2008 at 11:39:06PM +0100, Milan Obuch wrote: > > > On Monday 03 November 2008 04:59:08 Pyun YongHyeon wrote: > > > > > > [ snip ] > > > > > > > I vaguely guess hardware was not properly initialized. How about > > > > this one? > > > > http://people.freebsd.org/~yongari/re/re.phy.patch.20081103 > > > > > > This bug seems again to disappear - csup two days ago, kernel built with > > > no patches and everything works. Something like this happened already in > > > the > > > > Yeah, this is one of reason that makes it hard to fix. > > > > > past. No idea whether it has something with if_re being built as module, > > > but if it happens again, I will test this possibility, too. > > > > Ok. Please let me know your findings. > > Strange. This trouble occured again. Two days ago, fresh csup, rebuilt whole > system, re works only when with verbose boot logging. Yesterday, fresh csup, > full rebuild, re works again. There is no change in if_re.c at all - it is > dated Sep 9, 2008. This is coming from somewhere else, but I have no idea how > this could be debugged. One possibility is there is some weird issue with > code or maybe more probably buffer placement in memory, but this is just a > shot in the wild, and no idea what means could be used to trace that. > > It occurs to me from time to time, only with -current, everytime verbose boot > logging masks the trouble, at least everytime I tried. Really weird, not > predictable. And maybe only difference tracking one per one could give some If verbose boot always hide the issye how about adding a DELAY in re_attach()? You may add a DELAY line, say DELAY(2000), before any PHY access(around line number 1307 in if_re.c) Did it make difference? > clue, but this is really time consuming (apply change, rebuild kernel, > reboot, test... grrr). > > Regards, > Milan -- Regards, Pyun YongHyeon From weongyo.jeong at gmail.com Sun Nov 16 20:59:58 2008 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Sun Nov 16 21:00:05 2008 Subject: driver support for Belkin F5D7050 v 5xxx ? In-Reply-To: <3a142e750811160335y6867d362k93a525774bc3667@mail.gmail.com> References: <28b9b4180811160018q2823d7fap90b546ba444f191d@mail.gmail.com> <3a142e750811160335y6867d362k93a525774bc3667@mail.gmail.com> Message-ID: <20081117043650.GF61939@freebsd.weongyo.org> On Sun, Nov 16, 2008 at 12:35:23PM +0100, Paul B. Mahol wrote: > On 11/16/08, Kayven Riese wrote: > > I just purchased a wireless connection device that connects to my ASUS > > M6800N laptop dual > > booting Vista and > > > > KV_BSD# uname -a > > FreeBSD KV_BSD 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 > > KV_BSD# > > > > via USB. > > > > While booting on Vista, connection was fine. I investigated my man pages > > for Belkin modles in > > the interfaces: > > V_BSD# man an | grep Belkin > > KV_BSD# man awi | grep Belkin > > KV_BSD# man ipw | grep Belkin > > KV_BSD# set -o vi > > KV_BSD# man iwi | grep Belkin > > KV_BSD# man ral | grep Belkin > > Belkin F5D7000 v3 RT2560 PCI > > Belkin F5D7010 v2 RT2560 CardBus > > KV_BSD# man rum | grep Belkin > > Belkin F5D7050 ver 3 USB > > Belkin F5D9050 ver 3 USB > > KV_BSD# man ural | grep Belkin > > Belkin F5D7050 v2000 USB > > KV_BSD# man wi | grep Belkin > > Belkin F5D6000 (a rebadged WL11000P) > > KV_BSD# man zyd | grep Belkin > > Belkin F5D7050 v.4000 > > KV_BSD# > > > > and found some websites that made me compare a serial number that I > > correlated to some > > information on the Belkin website and came to the conclusion that my device > > is a newer > > version than appears in the above list because of this information: > > > > K7SF5D7050E corresponds to version 5xxx > > > > That serial number is written on the device. > > > > There were no unfamiliar results of ifconfig: > > > > > > > > KV_BSD# ifconfig > > bge0: flags=8843 metric 0 mtu 1500 > > options=9b > > ether 00:11:d8:22:c9:91 > > inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 > > media: Ethernet autoselect (100baseTX ) > > status: active > > fwe0: flags=8802 metric 0 mtu 1500 > > options=8 > > ether 02:e0:18:26:4c:e9 > > ch 1 dma -1 > > fwip0: flags=8802 metric 0 mtu 1500 > > lladdr 0.e0.18.0.3.26.4c.e9.a.2.ff.fe.0.0.0.0 > > plip0: flags=108810 metric 0 mtu > > 1500 > > lo0: flags=8049 metric 0 mtu 16384 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > > inet6 ::1 prefixlen 128 > > inet 127.0.0.1 netmask 0xff000000 > > KV_BSD# > > > > I attempted to use the ndisgen utility with the driver disk mounted on > > "/mnt/drive" > > > > Currently ndis on freebsd doesnt support usb cards at all. > There is patch available for CURRENT that is considered experimental and > make possible to use ndis on FreeBSD with usb cards. I'd try to commit NDIS USB support soon (maybe before releasing 8.0 :-)) if there are no objections but I don't know whether it should be based on USB1, USB2 or both. regards, Weongy Jeong From bugmaster at FreeBSD.org Mon Nov 17 03:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 17 03:08:39 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200811171106.mAHB6rZ3082597@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/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o kern/128833 net [bge] Network packets corrupted when bge card is in 64 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 kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? 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: 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/126984 net [carp][patch] add carp userland notifications via devc 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 f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic 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 [in] Network: 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 f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr 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/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p 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/123881 net [tcp] Turning on TCP blackholing causes slow localhost 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 o 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/123200 net [netgraph] Server failure due to netgraph mpd and dhcp 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/123066 net [ipsec] [panic] kernel trap with ipsec 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 [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/122427 net [apm] [panic] apm and mDNSResponder cause panic during 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/122068 net [ppp] ppp can not set the correct interface with pptpd 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 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 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 [panic] gnugk causes kernel panic when closing UDP soc 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 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/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented 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 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/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat 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/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 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/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 bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a 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 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 conf/102502 net [patch] ifconfig name does't rename netgraph node in n 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/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/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 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 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/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/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 FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic 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/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 193 problems total. From won.derick at yahoo.com Mon Nov 17 02:40:29 2008 From: won.derick at yahoo.com (Won De Erick) Date: Mon Nov 17 04:28:39 2008 Subject: does freebsd support so called Scalable I/O on intel NIC ? Message-ID: <351447.99591.qm@web45806.mail.sp1.yahoo.com> Hello, Regarding Scalable I/O on Intel NIC: Using Intel Pro NIC (82571), I've downloaded the patches found on the following link: http://people.yandex-team.ru/~wawa/ I compiled and applied w/ FreeBSD 7.1 Beta2, and made some changes on the default settings. With net.isr.direct=1, I made some changes on kthreads(default=2) for em0 and em1's rx. dev.em.0.rx_kthreads: 6 .... dev.em.1.rx_kthreads: 6 The result: last pid: 1690; load averages: 10.83, 8.92, 8.56 up 0+02:28:24 18:22:54 107 processes: 28 running, 61 sleeping, 18 waiting CPU: 0.0% user, 0.0% nice, 74.0% system, 1.7% interrupt, 24.3% idle Mem: 17M Active, 7040K Inact, 161M Wired, 76K Cache, 21M Buf, 31G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56 root 1 43 - 0K 16K CPU0 0 54:04 100.00% em1_rx_kthread_1 55 root 1 43 - 0K 16K CPU13 d 53:37 100.00% em1_rx_kthread_0 1280 root 1 43 - 0K 16K CPU3 3 52:23 100.00% em1_rx_kthread_3 1279 root 1 43 - 0K 16K CPU7 7 51:57 100.00% em1_rx_kthread_2 1347 root 1 43 - 0K 16K CPU2 2 45:51 100.00% em1_rx_kthread_5 1346 root 1 43 - 0K 16K CPU5 5 45:40 100.00% em1_rx_kthread_4 50 root 1 -68 - 0K 16K CPU12 c 24:17 100.00% em0_txcleaner 11 root 1 171 ki31 0K 16K RUN f 105:35 94.38% idle: cpu15 25 root 1 171 ki31 0K 16K CPU1 1 76:32 81.40% idle: cpu1 1282 root 1 43 - 0K 16K WAIT 6 92:14 76.07% em0_rx_kthread_2 51 root 1 43 - 0K 16K CPU9 9 95:00 75.59% em0_rx_kthread_0 1344 root 1 43 - 0K 16K CPU11 b 79:18 75.49% em0_rx_kthread_5 1343 root 1 43 - 0K 16K WAIT 8 79:12 75.39% em0_rx_kthread_4 52 root 1 43 - 0K 16K CPU14 e 95:00 74.37% em0_rx_kthread_1 1283 root 1 43 - 0K 16K CPU10 a 92:24 68.65% em0_rx_kthread_3 22 root 1 171 ki31 0K 16K CPU4 4 58:31 60.35% idle: cpu4 54 root 1 -68 - 0K 16K WAIT 4 88:44 39.06% em1_txcleaner 20 root 1 171 ki31 0K 16K RUN 6 88:32 32.67% idle: cpu6 16 root 1 171 ki31 0K 16K RUN a 85:10 31.49% idle: cpu10 17 root 1 171 ki31 0K 16K RUN 9 76:45 28.96% idle: cpu9 15 root 1 171 ki31 0K 16K RUN b 92:25 28.86% idle: cpu11 18 root 1 171 ki31 0K 16K RUN 8 91:58 28.66% idle: cpu8 12 root 1 171 ki31 0K 16K RUN e 104:36 28.08% idle: cpu14 28 root 1 -32 - 0K 16K WAIT 1 74:01 20.75% swi4: clock sio 23 root 1 171 ki31 0K 16K RUN 3 69:43 6.59% idle: cpu3 26 root 1 171 ki31 0K 16K RUN 0 72:57 3.37% idle: cpu0 13 root 1 171 ki31 0K 16K RUN d 86:15 0.00% idle: cpu13 24 root 1 171 ki31 0K 16K RUN 2 86:08 0.00% idle: cpu2 14 root 1 171 ki31 0K 16K RUN c 83:32 0.00% idle: cpu12 19 root 1 171 ki31 0K 16K RUN 7 80:47 0.00% idle: cpu7 21 root 1 171 ki31 0K 16K RUN 5 74:22 0.00% idle: cpu5 27 root 1 -44 - 0K 16K WAIT 2 3:04 0.00% swi1: net I am happy to see that the threads are distributed among the CPUs, but I observed that there were packets errors and drops on the LAN side (em1): # netstat -I em1 -w 1 -d input (em1) output packets errs bytes packets errs bytes colls drops 32494 483 23083087 15681 0 23719154 0 82 30547 330 23104447 16062 0 23077442 0 44 In addition to the above result. I noticed errors on the WAN side (em0), but without packet drops. # netstat -I em0 -w 1 -d input (em0) output packets errs bytes packets errs bytes colls drops 19889 640 24144754 21307 0 8719922 0 0 18071 2436 25966238 21088 0 8766995 0 0 Is there any tool that I can use to trace where the errors and drops are occurring or coming from [internally]? I should want to see the specific process/task/threads that is causing this. ----------------------------------------------------- Original Message from Robert Watson Date: Sun, 26 Oct 2008 13:43:01 +0000 (GMT) ________________________________ > On Fri, 24 Oct 2008, Kip Macy wrote: > > It is simply a knob to adjust on all new server network cards. You could benefit from it on a predominantly UDP workload. I believe that tcp_input is still sufficiently serialized that it would not make sense for TCP workloads. > > In principle we can benefit on the basis that we drop the global lock fairly quickly for steady-state workloads (i.e., few SYN/FIN/RST packets), but there should be lots of contention on tcbinfo. > > If anyone is interested in doing some benchmarks, I have some patches that should apply fairly easily againts 8.x or 7.x as of 7.1 to move to optimistic read-locking of the global lock for steady state packets, but once in a while we have to upgrade or drop and re-acquire to get an exclusive lock when it turns out something that looked like a steady state packet did require the global lock exclusively, such as the ACK to transitioning to or from established. > I am interested to conduct a benchmark. Currently I am using FreebSD 7.1 Beta2 running on HPDL 585 w/ 16 CPUs. I am happy if you can send me the patch to do some benchmarks. > I've not had a chance to do much benchmarking on them, and theorize that they probably help quite a lot for lots of steady-state connections, but as connection length gets shorter the optimistic assumption becomes less true and begins to hurt performance. > > The long-term plan is to move to some more agressive decomposition of the tcbinfo lock, but I've not started on that yet as I'm waiting for the rwlock changes to settle, and need to evaluate the above tcbinfo rwlock patch. > > Robert N M Watson > Computer Laboratory > University of Cambridge Thanks, Won From sclark46 at earthlink.net Mon Nov 17 06:11:27 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Mon Nov 17 06:11:32 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <20081115102746.K61259@maildrop.int.zabbadoz.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> Message-ID: <49217B8C.4020701@earthlink.net> Bjoern A. Zeeb wrote: > On Fri, 14 Nov 2008, Robert Noland wrote: > > Hi, > >>>>> Also just using gre's without the >>>>> underlying ipsec tunnels seems to >>>>> work properly. > > The reason for this to my knowledge is: > http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 > > > or looking at recent freebsd code: > http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 > Look for M_DECRYPTED. > > Now what happens in your case: > > you receive an IPSec ESP packet, which gets decryped, that sets > M_DECRYPTED on the mbuf passes through various parts, gets up to gre, > gets decapsulated is an IP packet (again) gets to ip_input, TTL > expired, icmp_error and it's still the same mbuf that originally got > the M_DECRYPTED set. Thus the packets is just freed and you never see > anything. > > So thinking about this has nothing to do with gre (or gif for example > as well) in first place. It's arguably that passing it on to another > decapsulation the flag should be cleared when entering gre() for > example. > > The other question of course is why we do not send the icmp error back > even on plain ipsec? Is it because we could possibly leak information > as it's not caught by the policy sending it back? > > /bz > Hi Bjoern, Thanks for you insight. I see in the ip_icmp.c code what you are talking about. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From andre at freebsd.org Mon Nov 17 10:37:57 2008 From: andre at freebsd.org (Andre Oppermann) Date: Mon Nov 17 10:38:54 2008 Subject: TCP and syncache question In-Reply-To: <49201859.2080605@dlr.de> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> Message-ID: <4921B3C6.5020002@freebsd.org> Hartmut Brandt wrote: > Rui Paulo wrote: >> >> On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: >> >>> Hi, >>> >>> in tcp_syncache.c:syncache_expand() there is a test that the >>> acknowledgement number and the sequence number of an incoming ACK >>> segment are in the expected range. If they are not, syncache_expand() >>> returns 0 and tcp_input drops the segment and sets a reset. So far so >>> good. But syncache_expand() also deletes the syncache entry, and so >>> destroys the connection. I cannot see why it does it. It seems to me >>> that such a wrong segment should be interpreted as to be from another >>> connection and as such the segment should be ignored (but a reset >>> sent). When the correct ACK comes, the connection could still be >>> established. As it is now, the establishment of incoming connections >>> can seriously be disturbed by someone sending fake ACK packets. >>> >>> The same test (for the ack number, not for the sequence number) is >>> also further down in tcp_input.c:tcp_do_segment() (just after the >>> header prediction stuff) and here the handling is correct: the goto >>> dropwithreset just sends a reset and drops the segment but leaves the >>> connection in the SYN-RECEIVED state. This test is probably never >>> reached now, because of syncache_expand(), though. Correct. >>> Maybe I fail to see something obvious, though... >> >> >> Well, if the RST is sent, why should we keep the syncache entry? > > Because this effectively destroys the connection in SYN-RECEIVED which > is wrong according to RFC793. On page 69 the handling of incoming > segments for connections in SYN-RECEIVED is described: first you check > the sequence number and, if it is wrong, you send an RST (unless the RST > bit is set in the incoming segment), but otherwise ignore the segment. > > A segment with a bad sequence number in SYN-RECEIVED is either forged or > from an old connection. In both cases you don't want to destroy the > embryonic connection, because the correct ACK from the correct peer may > still arrive. I see your problem. Syncookies mitigate this problem (if not disabled) as the correct ACK will pass that test later even if the syncache entry went away before (which can also happen due to a generally high SYN load). RFC793 wants us to do the following: Page 69: Send back a challenge ACK with the correct parameters to help to re-synchronize the connection when !(RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND). Page 72: Send back a RST when !(SND.UNA =< SEG.ACK =< SND.NXT). At the moment we send the RST and delete the syncache entry for both cases. However we should send the ACK in the former, the RST in the latter, and and keep the syncache entry in either case. Fixing this requires some re-shuffling of the syncache_expand(). I'll post a version later today. -- Andre From davidch at broadcom.com Mon Nov 17 11:49:48 2008 From: davidch at broadcom.com (David Christensen) Date: Mon Nov 17 11:49:53 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot In-Reply-To: <200811162150.mAGLo4UJ045453@freefall.freebsd.org> References: <200811162150.mAGLo4UJ045453@freefall.freebsd.org> Message-ID: <5D267A3F22FD854F8F48B3D2B523819339408D91A4@IRVEXCHCCR01.corp.ad.broadcom.com> > Ok, thanks for testing anyway. > I still think that this isn't really a driver bug though but > you are hitting some hardware-related problem like f.e. a > silicon bug and the question is how to work around it. There is a documented errata for the 5701 A3 where a 64bit DMA read can be terminated early by the bridge and then completed later as a 32bit access, causing corruption on the 5701. The errata states this type of behavior is rare in bridges and that the workaround is to force 32bit operation (set bit 15 of register 0x6800). It's not clear whether this errata is occurring without seeing a but trace but it certainly sounds right. The only question would be knowing "when" to force 32bit operation. Should it be done in all cases or only for this bridge? > Looking at the bge(4) versions of the other BSDs and the > corresponding Linux and OpenSolaris drivers I can't spot > a such a workaround apart from the already known PCI-X > issue, unfortunately. The only other thing that comes to > my mind is that you might suffer from sort of the opposite > of the problem worked around by ti_64bitslot_war() (the NICs > driven by ti(4) are the predecessors of those supported by > bge(4)). Given that this also involves the BIOS that could > then explain why you're see first person to hit this problem. > Could you please instrument bge(4) to print the content > of the BGE_PCI_PCISTATE register and report back which > values it's initialized to depending on which type of slot > the card is plugged into? Dave From sclark46 at earthlink.net Mon Nov 17 13:01:42 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Mon Nov 17 13:01:54 2008 Subject: FreeBSD 6.3 gre and traceroute In-Reply-To: <20081115102746.K61259@maildrop.int.zabbadoz.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> Message-ID: <4921DBB4.4060505@earthlink.net> Bjoern A. Zeeb wrote: > On Fri, 14 Nov 2008, Robert Noland wrote: > > Hi, > >>>>> Also just using gre's without the >>>>> underlying ipsec tunnels seems to >>>>> work properly. > > The reason for this to my knowledge is: > http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 > > > or looking at recent freebsd code: > http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 > Look for M_DECRYPTED. > > Now what happens in your case: > > you receive an IPSec ESP packet, which gets decryped, that sets > M_DECRYPTED on the mbuf passes through various parts, gets up to gre, > gets decapsulated is an IP packet (again) gets to ip_input, TTL > expired, icmp_error and it's still the same mbuf that originally got > the M_DECRYPTED set. Thus the packets is just freed and you never see > anything. > > So thinking about this has nothing to do with gre (or gif for example > as well) in first place. It's arguably that passing it on to another > decapsulation the flag should be cleared when entering gre() for > example. > > The other question of course is why we do not send the icmp error back > even on plain ipsec? Is it because we could possibly leak information > as it's not caught by the policy sending it back? > > /bz > Update: Adding this code in ip_icmp.c makes the traceroute work. case IPPROTO_GRE: hlen += sizeof(struct gre_h); + m->m_flags &= ~(M_DECRYPTED); Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From andre at freebsd.org Mon Nov 17 14:40:12 2008 From: andre at freebsd.org (Andre Oppermann) Date: Mon Nov 17 14:40:55 2008 Subject: TCP and syncache question In-Reply-To: <4921B3C6.5020002@freebsd.org> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> Message-ID: <4921F2CD.503@freebsd.org> Andre Oppermann wrote: > Hartmut Brandt wrote: >> Rui Paulo wrote: >>> >>> On 15 Nov 2008, at 20:08, Hartmut Brandt wrote: >>> >>>> Hi, >>>> >>>> in tcp_syncache.c:syncache_expand() there is a test that the >>>> acknowledgement number and the sequence number of an incoming ACK >>>> segment are in the expected range. If they are not, >>>> syncache_expand() returns 0 and tcp_input drops the segment and sets >>>> a reset. So far so good. But syncache_expand() also deletes the >>>> syncache entry, and so destroys the connection. I cannot see why it >>>> does it. It seems to me that such a wrong segment should be >>>> interpreted as to be from another connection and as such the segment >>>> should be ignored (but a reset sent). When the correct ACK comes, >>>> the connection could still be established. As it is now, the >>>> establishment of incoming connections can seriously be disturbed by >>>> someone sending fake ACK packets. >>>> >>>> The same test (for the ack number, not for the sequence number) is >>>> also further down in tcp_input.c:tcp_do_segment() (just after the >>>> header prediction stuff) and here the handling is correct: the goto >>>> dropwithreset just sends a reset and drops the segment but leaves >>>> the connection in the SYN-RECEIVED state. This test is probably >>>> never reached now, because of syncache_expand(), though. > > Correct. > >>>> Maybe I fail to see something obvious, though... >>> >>> >>> Well, if the RST is sent, why should we keep the syncache entry? >> >> Because this effectively destroys the connection in SYN-RECEIVED which >> is wrong according to RFC793. On page 69 the handling of incoming >> segments for connections in SYN-RECEIVED is described: first you check >> the sequence number and, if it is wrong, you send an RST (unless the >> RST bit is set in the incoming segment), but otherwise ignore the >> segment. > > >> A segment with a bad sequence number in SYN-RECEIVED is either forged >> or from an old connection. In both cases you don't want to destroy the >> embryonic connection, because the correct ACK from the correct peer >> may still arrive. > > I see your problem. Syncookies mitigate this problem (if not disabled) as > the correct ACK will pass that test later even if the syncache entry went > away before (which can also happen due to a generally high SYN load). > > RFC793 wants us to do the following: > > Page 69: Send back a challenge ACK with the correct parameters to help > to re-synchronize the connection when > !(RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND). > > Page 72: Send back a RST when !(SND.UNA =< SEG.ACK =< SND.NXT). > > At the moment we send the RST and delete the syncache entry for both cases. > However we should send the ACK in the former, the RST in the latter, and > and keep the syncache entry in either case. > > Fixing this requires some re-shuffling of the syncache_expand(). I'll > post a version later today. This is a bit more complicated because of interactions with tcp_input() where syncache_expand() is called from. The old code (as of December 2002) behaved slightly different. It would not remove the syncache entry when (SND.UNA == SEG.ACK) but send a RST. The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't done at all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) succeeded. This gave way to the "LAND" DoS attack which was mostly fixed with a test for (RCV.IRS < SEG.SEQ). See the attached patch for fixed version of syncache_expand(). This patch is untested though. My development machine is currently down. Harti, Rui and Bjoern, please have a look at the patch and review it. -- Andre -------------- next part -------------- --- tcp_input.c.1.390 Mon Nov 17 21:33:25 2008 +++ tcp_input.c.1.390.mod Mon Nov 17 21:35:22 2008 @@ -642,10 +642,13 @@ findpcb: if (!syncache_expand(&inc, &to, th, &so, m)) { /* * No syncache entry or ACK was not - * for our SYN/ACK. Send a RST. + * for our SYN/ACK. Send a RST or + * an ACK for re-synchronization. * NB: syncache did its own logging * of the failure cause. */ + if (so == 1) + goto dropunlock; rstreason = BANDLIM_RST_OPENPORT; goto dropwithreset; } --- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008 +++ tcp_syncache.c.1.160.mod Mon Nov 17 23:35:39 2008 @@ -817,59 +817,47 @@ syncache_expand(struct in_conninfo *inc, INP_INFO_WLOCK_ASSERT(&V_tcbinfo); KASSERT((th->th_flags & (TH_RST|TH_ACK|TH_SYN)) == TH_ACK, ("%s: can handle only ACK", __func__)); + *lsop = NULL; sc = syncache_lookup(inc, &sch); /* returns locked sch */ SCH_LOCK_ASSERT(sch); if (sc == NULL) { /* * There is no syncache entry, so see if this ACK is - * a returning syncookie. To do this, first: - * A. See if this socket has had a syncache entry dropped in - * the past. We don't want to accept a bogus syncookie - * if we've never received a SYN. - * B. check that the syncookie is valid. If it is, then - * cobble up a fake syncache entry, and return. + * a returning syncookie. If the syncookie is valid, + * cobble up a fake syncache entry and create a socket. + * + * NB: Syncache head is locked for the syncookie access. */ if (!tcp_syncookies) { - SCH_UNLOCK(sch); if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Spurious ACK, " "segment rejected (syncookies disabled)\n", s, __func__); - goto failed; + goto sendrst; } bzero(&scs, sizeof(scs)); sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop); - SCH_UNLOCK(sch); if (sc == NULL) { if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Segment failed " "SYNCOOKIE authentication, segment rejected " "(probably spoofed)\n", s, __func__); - goto failed; + goto sendrst; } - } else { - /* Pull out the entry to unlock the bucket row. */ - TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); - sch->sch_length--; - V_tcp_syncache.cache_count--; - SCH_UNLOCK(sch); + goto expand; /* fully validated through syncookie */ } + SCH_LOCK_ASSERT(sch); /* * Segment validation: - * ACK must match our initial sequence number + 1 (the SYN|ACK). - */ - if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { - if ((s = tcp_log_addrs(inc, th, NULL, NULL))) - log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " - "rejected\n", s, __func__, th->th_ack, sc->sc_iss); - goto failed; - } - - /* + * * The SEQ must fall in the window starting at the received * initial receive sequence number + 1 (the SYN). + * If not the segment may be from an earlier connection. We send + * an ACK to re-synchronize the connection and keep the syncache + * entry without ajusting its timers. + * See RFC793 page 69, first check sequence number [SYN_RECEIVED]. */ if ((SEQ_LEQ(th->th_seq, sc->sc_irs) || SEQ_GT(th->th_seq, sc->sc_irs + sc->sc_wnd)) && @@ -877,14 +865,41 @@ syncache_expand(struct in_conninfo *inc, if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: SEQ %u != IRS+1 %u, segment " "rejected\n", s, __func__, th->th_seq, sc->sc_irs); - goto failed; + (void) syncache_respond(sc); + *lsop = 1; /* prevent RST */ + goto sendrstkeep; } + /* + * ACK must match our initial sequence number + 1 (the SYN|ACK). + * If not the segment may be from an earlier connection. We send + * a RST but keep the syncache entry without ajusting its timers. + * See RFC793 page 72, fifth check the ACK field, [SYN_RECEIVED]. + */ + if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) + log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " + "rejected\n", s, __func__, th->th_ack, sc->sc_iss); + goto sendrstkeep; + } + + /* + * Remove the entry to unlock the bucket row. + * Tests from now on are fatal and remove the syncache entry. + */ + TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); + sch->sch_length--; + V_tcp_syncache.cache_count--; + + /* + * If timestamps were not negotiated they must not show up later. + * See RFC1312bis, section 1.3, second paragraph + */ if (!(sc->sc_flags & SCF_TIMESTAMP) && (to->to_flags & TOF_TS)) { if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Timestamp not expected, " "segment rejected\n", s, __func__); - goto failed; + goto sendrst; } /* * If timestamps were negotiated the reflected timestamp @@ -896,9 +911,11 @@ syncache_expand(struct in_conninfo *inc, log(LOG_DEBUG, "%s; %s: TSECR %u != TS %u, " "segment rejected\n", s, __func__, to->to_tsecr, sc->sc_ts); - goto failed; + goto sendrst; } +expand: + SCH_UNLOCK(sch); *lsop = syncache_socket(sc, *lsop, m); if (*lsop == NULL) @@ -906,16 +923,18 @@ syncache_expand(struct in_conninfo *inc, else V_tcpstat.tcps_sc_completed++; -/* how do we find the inp for the new socket? */ if (sc != &scs) syncache_free(sc); return (1); -failed: - if (sc != NULL && sc != &scs) + +sendrst: + if (sc != &scs) syncache_free(sc); +sendrstkeep: + SCH_LOCK_ASSERT(sch); + SCH_UNLOCK(sch); if (s != NULL) free(s, M_TCPLOG); - *lsop = NULL; return (0); } @@ -1322,6 +1341,8 @@ syncache_respond(struct syncache *sc) * * 1) path_mtu_discovery is disabled * 2) the SCF_UNREACH flag has been set + * + * XXXAO: The route lookup comment doesn't make sense. */ if (V_path_mtu_discovery && ((sc->sc_flags & SCF_UNREACH) == 0)) ip->ip_off |= IP_DF; From glavoie at gmail.com Mon Nov 17 18:56:06 2008 From: glavoie at gmail.com (Gabriel Lavoie) Date: Mon Nov 17 18:56:12 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: <20081117034428.GG50872@cdnetworks.co.kr> References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> <20081117034428.GG50872@cdnetworks.co.kr> Message-ID: Hum. I tried transfering a lot of data tonight via Samba (30GB). It seems that after some time the driver becomes again unstable and the networking performance drops really low. I could hardly SSH to this box after it happened. Gabriel 2008/11/16 Pyun YongHyeon > On Sun, Nov 16, 2008 at 10:03:15PM -0500, Gabriel Lavoie wrote: > > All right! rl(4) from HEAD solved my problem! I now get a solid 11.2 > MB/sec > > file transfer, on both directions. I found about this problem because my > > Samba share was too slow. The Samba problem is solved. > > > > Glad to hear that. :-) > > > Thanks! > > > > 2008/11/16 Pyun YongHyeon > > > > > On Sun, Nov 16, 2008 at 06:26:34PM -0800, bf wrote: > > > > > > > > > There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > > > > > How about rl(4) in HEAD? I guess it would build with minor > > > > > modification. > > > > > > > > > > -- > > > > > Regards, > > > > > Pyun YongHyeon > > > > > > > > I meant to ask about this: I think you are referring to r184240-3 > > > committed > > > > around Oct. 25, partly in response to PR kern/128143, right? Is > there > > > any > > > > > > Yes. > > > > > > > plan to merge these changes to RELENG_7, either before or after the > > > > release of 7.1? > > > > > > > > > > I'll MFC the change after 7.1-RELEASE. > > > Did the change set r184240 fix your issue? > > > > > > -- > > -- > Regards, > Pyun YongHyeon > -- Gabriel Lavoie glavoie@gmail.com From pyunyh at gmail.com Mon Nov 17 20:39:35 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Nov 17 20:39:41 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> <20081117034428.GG50872@cdnetworks.co.kr> Message-ID: <20081118043731.GD55015@cdnetworks.co.kr> On Mon, Nov 17, 2008 at 09:56:05PM -0500, Gabriel Lavoie wrote: > Hum. I tried transfering a lot of data tonight via Samba (30GB). It seems > that after some time the driver becomes again unstable and the networking > performance drops really low. I could hardly SSH to this box after it > happened. Would you show me the output of "sysctl hw.busdma" and "netstat -nd -I rl0"? Did rl(4) show some messages on your console? > > Gabriel -- Regards, Pyun YongHyeon From bzeeb-lists at lists.zabbadoz.net Tue Nov 18 03:45:09 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Nov 18 03:45:16 2008 Subject: FreeBSD 6.3 gre and tracerouteo In-Reply-To: <4921DBB4.4060505@earthlink.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> <4921DBB4.4060505@earthlink.net> Message-ID: <20081118113823.T61259@maildrop.int.zabbadoz.net> On Mon, 17 Nov 2008, Stephen Clark wrote: Hi, > Bjoern A. Zeeb wrote: >> On Fri, 14 Nov 2008, Robert Noland wrote: >> >> Hi, >> >>>>>> Also just using gre's without the >>>>>> underlying ipsec tunnels seems to >>>>>> work properly. >> >> The reason for this to my knowledge is: >> http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 >> >> or looking at recent freebsd code: >> http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 >> Look for M_DECRYPTED. >> >> Now what happens in your case: >> >> you receive an IPSec ESP packet, which gets decryped, that sets >> M_DECRYPTED on the mbuf passes through various parts, gets up to gre, >> gets decapsulated is an IP packet (again) gets to ip_input, TTL >> expired, icmp_error and it's still the same mbuf that originally got >> the M_DECRYPTED set. Thus the packets is just freed and you never see >> anything. >> >> So thinking about this has nothing to do with gre (or gif for example >> as well) in first place. It's arguably that passing it on to another >> decapsulation the flag should be cleared when entering gre() for >> example. >> >> The other question of course is why we do not send the icmp error back >> even on plain ipsec? Is it because we could possibly leak information >> as it's not caught by the policy sending it back? >> >> /bz >> > Update: > > Adding this code in ip_icmp.c makes the traceroute work. > case IPPROTO_GRE: > hlen += sizeof(struct gre_h); > > + m->m_flags &= ~(M_DECRYPTED); I have two problems with this: 1) my ip_icmp.c doesn't know anything about GRE (in HEAD or on my 6.x box) unless I need more coffee. 2) This obviously doesn't solve the problem for gif(4), ... Can you tell me which brnach you are working against (I guess it's 6.3?) and generate a proper diff? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From glavoie at gmail.com Tue Nov 18 03:56:04 2008 From: glavoie at gmail.com (Gabriel Lavoie) Date: Tue Nov 18 03:56:11 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: <20081118043731.GD55015@cdnetworks.co.kr> References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> <20081117034428.GG50872@cdnetworks.co.kr> <20081118043731.GD55015@cdnetworks.co.kr> Message-ID: I'll come back to you tonight with the output of sysctl and netstat but there was no message with dmesg. Not sure about the console because no screen is plugged in this computer. My client computer's Samba started to output a lot of timeout and read/write error with dmesg. 2008/11/17 Pyun YongHyeon > On Mon, Nov 17, 2008 at 09:56:05PM -0500, Gabriel Lavoie wrote: > > Hum. I tried transfering a lot of data tonight via Samba (30GB). It > seems > > that after some time the driver becomes again unstable and the > networking > > performance drops really low. I could hardly SSH to this box after it > > happened. > > Would you show me the output of "sysctl hw.busdma" and > "netstat -nd -I rl0"? > Did rl(4) show some messages on your console? > > > > > Gabriel > -- > Regards, > Pyun YongHyeon > -- Gabriel Lavoie glavoie@gmail.com From sclark46 at earthlink.net Tue Nov 18 05:13:16 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Tue Nov 18 05:13:24 2008 Subject: FreeBSD 6.3 gre and tracerouteo In-Reply-To: <20081118113823.T61259@maildrop.int.zabbadoz.net> References: <491B2703.4080707@earthlink.net> <491B31F7.30200@elischer.org> <491B4345.80106@earthlink.net> <491B47D2.6010804@elischer.org> <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> <4921DBB4.4060505@earthlink.net> <20081118113823.T61259@maildrop.int.zabbadoz.net> Message-ID: <4922BF6A.1000108@earthlink.net> Bjoern A. Zeeb wrote: > On Mon, 17 Nov 2008, Stephen Clark wrote: > > Hi, > >> Bjoern A. Zeeb wrote: >>> On Fri, 14 Nov 2008, Robert Noland wrote: >>> >>> Hi, >>> >>>>>>> Also just using gre's without the >>>>>>> underlying ipsec tunnels seems to >>>>>>> work properly. >>> >>> The reason for this to my knowledge is: >>> http://www.kame.net/dev/cvsweb2.cgi/kame/freebsd2/sys/netinet/ip_icmp.c#rev1.4 >>> >>> or looking at recent freebsd code: >>> http://fxr.watson.org/fxr/source/netinet/ip_icmp.c#L164 >>> Look for M_DECRYPTED. >>> >>> Now what happens in your case: >>> >>> you receive an IPSec ESP packet, which gets decryped, that sets >>> M_DECRYPTED on the mbuf passes through various parts, gets up to gre, >>> gets decapsulated is an IP packet (again) gets to ip_input, TTL >>> expired, icmp_error and it's still the same mbuf that originally got >>> the M_DECRYPTED set. Thus the packets is just freed and you never see >>> anything. >>> >>> So thinking about this has nothing to do with gre (or gif for example >>> as well) in first place. It's arguably that passing it on to another >>> decapsulation the flag should be cleared when entering gre() for >>> example. >>> >>> The other question of course is why we do not send the icmp error back >>> even on plain ipsec? Is it because we could possibly leak information >>> as it's not caught by the policy sending it back? >>> >>> /bz >>> >> Update: >> >> Adding this code in ip_icmp.c makes the traceroute work. >> case IPPROTO_GRE: >> hlen += sizeof(struct gre_h); >> >> + m->m_flags &= ~(M_DECRYPTED); > > I have two problems with this: > > 1) my ip_icmp.c doesn't know anything about GRE (in HEAD or on my 6.x > box) unless I need more coffee. > > 2) This obviously doesn't solve the problem for gif(4), ... > > > Can you tell me which brnach you are working against (I guess it's > 6.3?) and generate a proper diff? > > > /bz > Duh sorry - should have said ip_gre.c and it is 6.3-p5 *** ip_gre.c.ori Tue Nov 18 08:09:16 2008 --- ip_gre.c Tue Nov 18 08:10:27 2008 *************** *** 153,158 **** --- 153,161 ---- switch (proto) { case IPPROTO_GRE: hlen += sizeof(struct gre_h); + + m->m_flags &= ~(M_DECRYPTED); + /* process GRE flags as packet can be of variable len */ flags = ntohs(gip->gi_flags); Your right about gif(4) - probably something similar is needed. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From fox at verio.net Tue Nov 18 09:33:09 2008 From: fox at verio.net (David DeSimone) Date: Tue Nov 18 09:33:15 2008 Subject: FreeBSD 6.3 gre and tracerouteo In-Reply-To: <4922BF6A.1000108@earthlink.net> References: <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> <4921DBB4.4060505@earthlink.net> <20081118113823.T61259@maildrop.int.zabbadoz.net> <4922BF6A.1000108@earthlink.net> Message-ID: <20081118173337.GA19402@verio.net> Stephen Clark wrote: > > switch (proto) { > case IPPROTO_GRE: > hlen += sizeof(struct gre_h); > + > + m->m_flags &= ~(M_DECRYPTED); > + Are there security implications from removing this flag? -- 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 sclark46 at earthlink.net Tue Nov 18 09:49:18 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Tue Nov 18 09:49:24 2008 Subject: FreeBSD 6.3 gre and tracerouteo In-Reply-To: <20081118173337.GA19402@verio.net> References: <491C2235.4090509@earthlink.net> <1226589468.1976.12.camel@wombat.2hip.net> <491C4EC2.2000802@earthlink.net> <491D6CED.50006@earthlink.net> <491DC28E.80804@elischer.org> <1226688153.1719.23.camel@squirrel.corp.cox.com> <20081115102746.K61259@maildrop.int.zabbadoz.net> <4921DBB4.4060505@earthlink.net> <20081118113823.T61259@maildrop.int.zabbadoz.net> <4922BF6A.1000108@earthlink.net> <20081118173337.GA19402@verio.net> Message-ID: <49230017.3050409@earthlink.net> David DeSimone wrote: > Stephen Clark wrote: >> switch (proto) { >> case IPPROTO_GRE: >> hlen += sizeof(struct gre_h); >> + >> + m->m_flags &= ~(M_DECRYPTED); >> + > > Are there security implications from removing this flag? > That is a very good question. I was wondering the same thing myself. Hopefully someone with a better understanding will comment on it. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From security at jim-liesl.org Tue Nov 18 10:27:51 2008 From: security at jim-liesl.org (security) Date: Tue Nov 18 10:27:57 2008 Subject: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 Message-ID: <492302E2.4040907@jim-liesl.org> I'm building a WAN emulation box based on 7.1-beta2-ipfw and dummynet. The config is basically a router-on-a-stick. The server (FBSD rtr) has two nics which connect to two different switches, but both switch ports are in the same untagged interconnected vlan. All the other test boxes in the network are also in the same vlan, but broken into different nets. The different nets are spread across the two nics as primary and alias ip address in different nets. I've been getting "bursts" (maybe 8-20 at a time) of the discard frame messages. Mostly on bce1 but I've seen them on bce0 also. bce1 is probably the busier of the 2 currently. As a shot in the dark, I disabled polling system wide and the messages seemed to have stopped. thanks jim kernel: bce1: discard frame w/o leading ethernet header (len 4294967292 pkt len 4294967292) ipfw/dummynet/pipes are being used to rate limit traffic by src/dst ip address. The FreeBSD box uses the broadcom bcm5706s gigE interfaces. class=0x020000 card=0x310c103c chip=0x16aa14e4 rev=0x02 hdr=0x00. Based on some readings, I've got the following mods in place: i386 sources running on a 2 x dual core athalon64 cpus, 4 cores active. 8gig of mem available, but only 4 in use kernel i486 and i586 commented out nfs options commented out fbsd 4 and 5 commented out hz=1000 ipfirewall ipfirewall_default_to accept dummynet eisa commented out as well as the older nics sysctl settings kern.polling.enable=1 (setting this to 0 seems to fix the problem, but leaves the cpu's busier) kern.ipc.maxsockbuf=16777216 (not sure this helps much in the case of a rtr) net.inet.ip.forwarding=1 net.inet..tcp.sendbuf_auto=1 net.inet..tcp.sendbuf_max=16777216 net.inet..tcp.recvbuf_auto=1 net.inet..tcp.recvbuf_max=16777216 net.inet.tcp.rfc1323=1 net.link.ether.inet.log_arp_wrong_iface=0 (to suppress the arp messages) From jkim at FreeBSD.org Tue Nov 18 10:44:29 2008 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue Nov 18 10:44:35 2008 Subject: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 In-Reply-To: <492302E2.4040907@jim-liesl.org> References: <492302E2.4040907@jim-liesl.org> Message-ID: <200811181344.20092.jkim@FreeBSD.org> On Tuesday 18 November 2008 01:01 pm, security wrote: > I'm building a WAN emulation box based on 7.1-beta2-ipfw and > dummynet. The config is basically a router-on-a-stick. The server > (FBSD rtr) has two nics which connect to two different switches, > but both switch ports are in the same untagged interconnected vlan. > All the other test boxes in the network are also in the same vlan, > but broken into different nets. The different nets are spread > across the two nics as primary and alias ip address in different > nets. I've been getting "bursts" (maybe 8-20 at a time) of the > discard frame messages. Mostly on bce1 but I've seen them on bce0 > also. bce1 is probably the busier of the 2 currently. As a shot in > the dark, I disabled polling system wide and the messages seemed to > have stopped. Please try the latest driver from RELENG_7. The following commit seems interesting: http://svn.freebsd.org/viewvc/base?view=revision&revision=184826 Jung-uk Kim > thanks > jim > > > kernel: bce1: discard frame w/o leading ethernet header (len > 4294967292 pkt len 4294967292) > > ipfw/dummynet/pipes are being used to rate limit traffic by src/dst > ip address. > > The FreeBSD box uses the broadcom bcm5706s gigE interfaces. > class=0x020000 card=0x310c103c chip=0x16aa14e4 rev=0x02 hdr=0x00. > Based on some readings, I've got the following mods in place: > i386 sources running on a 2 x dual core athalon64 cpus, 4 cores > active. 8gig of mem available, but only 4 in use > kernel > i486 and i586 commented out > nfs options commented out > fbsd 4 and 5 commented out > hz=1000 > ipfirewall > ipfirewall_default_to accept > dummynet > eisa commented out as well as the older nics > > sysctl settings > kern.polling.enable=1 (setting this to 0 seems to fix the problem, > but leaves the cpu's busier) > kern.ipc.maxsockbuf=16777216 (not sure this helps much in the case > of a rtr) net.inet.ip.forwarding=1 > net.inet..tcp.sendbuf_auto=1 > net.inet..tcp.sendbuf_max=16777216 > net.inet..tcp.recvbuf_auto=1 > net.inet..tcp.recvbuf_max=16777216 > net.inet.tcp.rfc1323=1 > net.link.ether.inet.log_arp_wrong_iface=0 (to suppress the arp > messages) > > > > > _______________________________________________ > 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 security at jim-liesl.org Tue Nov 18 13:15:48 2008 From: security at jim-liesl.org (security) Date: Tue Nov 18 13:15:54 2008 Subject: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 In-Reply-To: <200811181344.20092.jkim@FreeBSD.org> References: <492302E2.4040907@jim-liesl.org> <200811181344.20092.jkim@FreeBSD.org> Message-ID: <49233081.9000900@jim-liesl.org> Jung-uk Kim wrote: > On Tuesday 18 November 2008 01:01 pm, security wrote: > >> I'm building a WAN emulation box based on 7.1-beta2-ipfw and >> dummynet. The config is basically a router-on-a-stick. The server >> (FBSD rtr) has two nics which connect to two different switches, >> but both switch ports are in the same untagged interconnected vlan. >> All the other test boxes in the network are also in the same vlan, >> but broken into different nets. The different nets are spread >> across the two nics as primary and alias ip address in different >> nets. I've been getting "bursts" (maybe 8-20 at a time) of the >> discard frame messages. Mostly on bce1 but I've seen them on bce0 >> also. bce1 is probably the busier of the 2 currently. As a shot in >> the dark, I disabled polling system wide and the messages seemed to >> have stopped. >> > > Please try the latest driver from RELENG_7. The following commit > seems interesting: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=184826 > > Jung-uk Kim > Thanks, you're right it does. I noticed he disabled polling as I had done. There are enough other interesting bits that i'll try the driver. jim From julian at ironport.com Tue Nov 18 14:22:38 2008 From: julian at ironport.com (Julian Elischer) Date: Tue Nov 18 14:22:45 2008 Subject: tokenring users? Message-ID: <49233959.9040903@ironport.com> One of the things that are making things hard for network testing is the question "what to do about tokenring support?" We seem to have a dearth of tokenring users so we are completely unable test how changes affect tokenring. If anyone here knows anyone whoul could: 1/ help support tokenring 2/ help test tokenring, could they get in touch? thanks Julian and the rest of the network cabal in the dev-summit. From glavoie at gmail.com Tue Nov 18 14:28:15 2008 From: glavoie at gmail.com (Gabriel Lavoie) Date: Tue Nov 18 14:28:22 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: <20081118043731.GD55015@cdnetworks.co.kr> References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> <20081117034428.GG50872@cdnetworks.co.kr> <20081118043731.GD55015@cdnetworks.co.kr> Message-ID: Requested commands: Before a problem happens: [root@headless ~]# sysctl hw.busdma hw.busdma.total_bpages: 8260 hw.busdma.zone0.total_bpages: 8196 hw.busdma.zone0.free_bpages: 8196 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 1 hw.busdma.zone0.boundary: 0 hw.busdma.zone1.total_bpages: 64 hw.busdma.zone1.free_bpages: 64 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 8200 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 2 hw.busdma.zone1.boundary: 65536 [root@headless ~]# netstat -nd -I rl0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop rl0 1500 00:50:fc:c6:c8:d2 64336 0 60706 0 0 0 rl0 1500 192.168.69.0/ 192.168.69.87 63398 - 59820 - - - I got a Samba copy error at this point: [root@headless /home/wildchild]# sysctl hw.busdma hw.busdma.total_bpages: 8260 hw.busdma.zone0.total_bpages: 8196 hw.busdma.zone0.free_bpages: 8196 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 1 hw.busdma.zone0.boundary: 0 hw.busdma.zone1.total_bpages: 64 hw.busdma.zone1.free_bpages: 64 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 144539 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 2 hw.busdma.zone1.boundary: 65536 [root@headless /home/wildchild]# netstat -nd -I rl0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop rl0 1500 00:50:fc:c6:c8:d2 6718354 0 4023956 0 0 0 rl0 1500 192.168.69.0/ 192.168.69.87 6717392 - 4023051 - - - Now the networking is really erratic. I have a huge slowdown with SSH and I'm unable to copy files on the computer anymore via Samba. I must reboot to get back the full performance. Gabriel 2008/11/17 Pyun YongHyeon > On Mon, Nov 17, 2008 at 09:56:05PM -0500, Gabriel Lavoie wrote: > > Hum. I tried transfering a lot of data tonight via Samba (30GB). It > seems > > that after some time the driver becomes again unstable and the > networking > > performance drops really low. I could hardly SSH to this box after it > > happened. > > Would you show me the output of "sysctl hw.busdma" and > "netstat -nd -I rl0"? > Did rl(4) show some messages on your console? > > > > > Gabriel > -- > Regards, > Pyun YongHyeon > -- Gabriel Lavoie glavoie@gmail.com From marius at alchemy.franken.de Tue Nov 18 14:50:04 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Tue Nov 18 14:50:11 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811182250.mAIMo4gb028171@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= Cc: bug-followup@FreeBSD.org Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Tue, 18 Nov 2008 23:46:21 +0100 On Mon, Nov 17, 2008 at 02:37:51AM +0100, Aurlien Mr wrote: > Hi > As first check, when device is being attached, here are the values reported > and the diff : > > in 32 bit slot : > BGE_PCI_PCISTATE = 0x96 (0x86 | BGE_PCISTATE_32BIT_BUS) > bge_flags = 0x120E (0x100E | BGE_FLAG_PCIX) > > in 64 bit slot : > BGE_PCI_PCISTATE = 0x8E (0x86 | BGE_PCISTATE_PCI_BUSSPEED) > bge_flags = 0x1A0E (0x100E | BGE_FLAG_PCIX | BGE_FLAG_64BIT) > > Seems logical so far, I'll try to look further. Apart from the problem described by davidch@ (I'm not sure you actually have a BCM5701 A3 though, at least bge(4) doesn't seem to be aware of that revision) the BGE_PCI_PCISTATE and bge_flags pairs you reported don't match though; according to BGE_PCI_PCISTATE the card isn't in a PCI-X slot in either case (BGE_PCISTATE_PCI_BUSMODE is always set, which means PCI) and AFAICT your motherboard chipset also doesn't support PCI-X. However, as you noted BGE_FLAG_PCIX is set for whatever reason in both cases, which leads to some inappropriate initialization of the controller. As a quick test could you please check whether replacing the "#if __FreeBSD_version > 602101" in the driver with an "#if 0" makes any difference to your problem? Marius From brad at comstyle.com Tue Nov 18 15:01:38 2008 From: brad at comstyle.com (Brad) Date: Tue Nov 18 15:01:44 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot In-Reply-To: <200811182250.mAIMo4gb028171@freefall.freebsd.org> References: <200811182250.mAIMo4gb028171@freefall.freebsd.org> Message-ID: <200811181801.10997.brad@comstyle.com> On Tuesday 18 November 2008 17:50:04 Marius Strobl wrote: > The following reply was made to PR kern/128833; it has been noted by GNATS. > > From: Marius Strobl > To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= > Cc: bug-followup@FreeBSD.org > Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is > in 64-bit PCI slot Date: Tue, 18 Nov 2008 23:46:21 +0100 > > On Mon, Nov 17, 2008 at 02:37:51AM +0100, Aurlien Mr wrote: > > Hi > > As first check, when device is being attached, here are the values > > reported and the diff : > > > > in 32 bit slot : > > BGE_PCI_PCISTATE = 0x96 (0x86 | BGE_PCISTATE_32BIT_BUS) > > bge_flags = 0x120E (0x100E | BGE_FLAG_PCIX) > > > > in 64 bit slot : > > BGE_PCI_PCISTATE = 0x8E (0x86 | BGE_PCISTATE_PCI_BUSSPEED) > > bge_flags = 0x1A0E (0x100E | BGE_FLAG_PCIX | BGE_FLAG_64BIT) > > > > Seems logical so far, I'll try to look further. > > Apart from the problem described by davidch@ (I'm not sure > you actually have a BCM5701 A3 though, at least bge(4) doesn't > seem to be aware of that revision) the BGE_PCI_PCISTATE and > bge_flags pairs you reported don't match though; according > to BGE_PCI_PCISTATE the card isn't in a PCI-X slot in either > case (BGE_PCISTATE_PCI_BUSMODE is always set, which means > PCI) and AFAICT your motherboard chipset also doesn't > support PCI-X. However, as you noted BGE_FLAG_PCIX is set > for whatever reason in both cases, which leads to some > inappropriate initialization of the controller. As a quick > test could you please check whether replacing the "#if > __FreeBSD_version > 602101" in the driver with an "#if 0" > makes any difference to your problem? The PCI-X check which is used for I'm guessing FreeBSD 7 and newer is wrong. Older versions get it right. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From security at jim-liesl.org Tue Nov 18 16:16:28 2008 From: security at jim-liesl.org (security) Date: Tue Nov 18 16:16:34 2008 Subject: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 In-Reply-To: <200811181344.20092.jkim@FreeBSD.org> References: <492302E2.4040907@jim-liesl.org> <200811181344.20092.jkim@FreeBSD.org> Message-ID: <49235AD3.1090702@jim-liesl.org> Jung-uk Kim wrote: > On Tuesday 18 November 2008 01:01 pm, security wrote: > >> I'm building a WAN emulation box based on 7.1-beta2-ipfw and >> dummynet. The config is basically a router-on-a-stick. The server >> (FBSD rtr) has two nics which connect to two different switches, >> but both switch ports are in the same untagged interconnected vlan. >> All the other test boxes in the network are also in the same vlan, >> but broken into different nets. The different nets are spread >> across the two nics as primary and alias ip address in different >> nets. I've been getting "bursts" (maybe 8-20 at a time) of the >> discard frame messages. Mostly on bce1 but I've seen them on bce0 >> also. bce1 is probably the busier of the 2 currently. As a shot in >> the dark, I disabled polling system wide and the messages seemed to >> have stopped. >> > > Please try the latest driver from RELENG_7. The following commit > seems interesting: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=184826 > > Jung-uk Kim > > >> thanks >> jim >> >> >> kernel: bce1: discard frame w/o leading ethernet header (len >> 4294967292 pkt len 4294967292) >> >> ipfw/dummynet/pipes are being used to rate limit traffic by src/dst >> ip address. >> >> The FreeBSD box uses the broadcom bcm5706s gigE interfaces. >> class=0x020000 card=0x310c103c chip=0x16aa14e4 rev=0x02 hdr=0x00. >> Based on some readings, I've got the following mods in place: >> i386 sources running on a 2 x dual core athalon64 cpus, 4 cores >> active. 8gig of mem available, but only 4 in use >> kernel >> i486 and i586 commented out >> nfs options commented out >> fbsd 4 and 5 commented out >> hz=1000 >> ipfirewall >> ipfirewall_default_to accept >> dummynet >> eisa commented out as well as the older nics >> >> sysctl settings >> kern.polling.enable=1 (setting this to 0 seems to fix the problem, >> but leaves the cpu's busier) >> kern.ipc.maxsockbuf=16777216 (not sure this helps much in the case >> of a rtr) net.inet.ip.forwarding=1 >> net.inet..tcp.sendbuf_auto=1 >> net.inet..tcp.sendbuf_max=16777216 >> net.inet..tcp.recvbuf_auto=1 >> net.inet..tcp.recvbuf_max=16777216 >> net.inet.tcp.rfc1323=1 >> net.link.ether.inet.log_arp_wrong_iface=0 (to suppress the arp >> messages) >> I'm running the new driver now. It's logging Ierrs on the of "netstat -I bcen -a" @ about 1-2 per second. I don't *think* it was doing that under the original driver, but I couldn't swear to it, and it would be difficult to revert right now to check. The errors seem unrelated to traffic generated by ping repeat count or payload size. Might these be the ARP on the wrong iface errors I'm suppressing ? Ping isn't complaining about any dropped packets and I'm not seeing any drops or collision stats. jim From freebsd at amc-os.com Tue Nov 18 17:30:05 2008 From: freebsd at amc-os.com (=?iso-8859-1?B?QXVy6WxpZW4gTely6Q==?=) Date: Tue Nov 18 17:30:11 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811190130.mAJ1U4Wr047440@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: =?iso-8859-1?B?QXVy6WxpZW4gTely6Q==?= To: "Marius Strobl" Cc: Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Wed, 19 Nov 2008 02:27:43 +0100 Concerning the problem described by davidch@ , my chip is reported as a B5 revision (01050000), so it might not be the case here. You're right, the M/B doesn't support PCI-X at all. As detailed on the manual, the NB chipset (AMD762) provides support for 2x66 MHz 64-bit PCI 2.2 masters, and the SB chipset (AMD768) provides a secondary PCI 2.2 bridge 33MHz. I tried the patch but it didn't solve the problem, whilst the BGE_FLAG_PCIX was no longer in the flags, which seems much more correct anyway. At the end of the initialization values are these, as planned : bge_flags = 0x0010180F (0x10100F | BGE_FLAG_64BIT) . BGE_PCI_PCISTATE is unchanged Note I forgot to mention the BGE_FLAG_RXALIGN_BUG (100000) and BGE_FLAG_TBI (1) last time, as I tested before reset of the chip where these flags are set. ----- Original Message ----- From: "Marius Strobl" To: "Aurélien Méré" Cc: Sent: Tuesday, November 18, 2008 11:46 PM Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot > On Mon, Nov 17, 2008 at 02:37:51AM +0100, Aurlien Mr wrote: >> Hi >> As first check, when device is being attached, here are the values >> reported >> and the diff : >> >> in 32 bit slot : >> BGE_PCI_PCISTATE = 0x96 (0x86 | BGE_PCISTATE_32BIT_BUS) >> bge_flags = 0x120E (0x100E | BGE_FLAG_PCIX) >> >> in 64 bit slot : >> BGE_PCI_PCISTATE = 0x8E (0x86 | BGE_PCISTATE_PCI_BUSSPEED) >> bge_flags = 0x1A0E (0x100E | BGE_FLAG_PCIX | BGE_FLAG_64BIT) >> >> Seems logical so far, I'll try to look further. > > Apart from the problem described by davidch@ (I'm not sure > you actually have a BCM5701 A3 though, at least bge(4) doesn't > seem to be aware of that revision) the BGE_PCI_PCISTATE and > bge_flags pairs you reported don't match though; according > to BGE_PCI_PCISTATE the card isn't in a PCI-X slot in either > case (BGE_PCISTATE_PCI_BUSMODE is always set, which means > PCI) and AFAICT your motherboard chipset also doesn't > support PCI-X. However, as you noted BGE_FLAG_PCIX is set > for whatever reason in both cases, which leads to some > inappropriate initialization of the controller. As a quick > test could you please check whether replacing the "#if > __FreeBSD_version > 602101" in the driver with an "#if 0" > makes any difference to your problem? > > Marius > From security at jim-liesl.org Tue Nov 18 17:39:21 2008 From: security at jim-liesl.org (security) Date: Tue Nov 18 17:39:28 2008 Subject: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 In-Reply-To: <49235AD3.1090702@jim-liesl.org> References: <492302E2.4040907@jim-liesl.org> <200811181344.20092.jkim@FreeBSD.org> <49235AD3.1090702@jim-liesl.org> Message-ID: <49236E46.7090207@jim-liesl.org> security wrote: > Jung-uk Kim wrote: > >> On Tuesday 18 November 2008 01:01 pm, security wrote: >> >> >>> I'm building a WAN emulation box based on 7.1-beta2-ipfw and >>> dummynet. The config is basically a router-on-a-stick. The server >>> (FBSD rtr) has two nics which connect to two different switches, >>> but both switch ports are in the same untagged interconnected vlan. >>> All the other test boxes in the network are also in the same vlan, >>> but broken into different nets. The different nets are spread >>> across the two nics as primary and alias ip address in different >>> nets. I've been getting "bursts" (maybe 8-20 at a time) of the >>> discard frame messages. Mostly on bce1 but I've seen them on bce0 >>> also. bce1 is probably the busier of the 2 currently. As a shot in >>> the dark, I disabled polling system wide and the messages seemed to >>> have stopped. >>> >>> >> Please try the latest driver from RELENG_7. The following commit >> seems interesting: >> >> http://svn.freebsd.org/viewvc/base?view=revision&revision=184826 >> >> Jung-uk Kim >> >> >> >>> thanks >>> jim >>> >>> >>> kernel: bce1: discard frame w/o leading ethernet header (len >>> 4294967292 pkt len 4294967292) >>> >>> ipfw/dummynet/pipes are being used to rate limit traffic by src/dst >>> ip address. >>> >>> The FreeBSD box uses the broadcom bcm5706s gigE interfaces. >>> class=0x020000 card=0x310c103c chip=0x16aa14e4 rev=0x02 hdr=0x00. >>> Based on some readings, I've got the following mods in place: >>> i386 sources running on a 2 x dual core athalon64 cpus, 4 cores >>> active. 8gig of mem available, but only 4 in use >>> kernel >>> i486 and i586 commented out >>> nfs options commented out >>> fbsd 4 and 5 commented out >>> hz=1000 >>> ipfirewall >>> ipfirewall_default_to accept >>> dummynet >>> eisa commented out as well as the older nics >>> >>> sysctl settings >>> kern.polling.enable=1 (setting this to 0 seems to fix the problem, >>> but leaves the cpu's busier) >>> kern.ipc.maxsockbuf=16777216 (not sure this helps much in the case >>> of a rtr) net.inet.ip.forwarding=1 >>> net.inet..tcp.sendbuf_auto=1 >>> net.inet..tcp.sendbuf_max=16777216 >>> net.inet..tcp.recvbuf_auto=1 >>> net.inet..tcp.recvbuf_max=16777216 >>> net.inet.tcp.rfc1323=1 >>> net.link.ether.inet.log_arp_wrong_iface=0 (to suppress the arp >>> messages) >>> >>> > I'm running the new driver now. It's logging Ierrs on the of > "netstat -I bcen -a" @ about 1-2 per second. I don't *think* it was > doing that under the original driver, but I couldn't swear to it, and it > would be difficult to revert right now to check. The errors seem > unrelated to traffic generated by ping repeat count or payload size. > Might these be the ARP on the wrong iface errors I'm suppressing ? Ping > isn't complaining about any dropped packets and I'm not seeing any drops > or collision stats. > to reply to my own post, I dumped the sysctl values for the bce devices. These errors are L2Filter drops and I suspect they're from oversize >1500 ethernet frames. Not sure whats generating them yet. jim From glavoie at gmail.com Tue Nov 18 18:09:45 2008 From: glavoie at gmail.com (Gabriel Lavoie) Date: Tue Nov 18 18:09:51 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: References: <20081117003856.GB50872@cdnetworks.co.kr> Message-ID: Hum when I do my Samba transfer, there is a lot of small files (> 50 000) and it seems at some point Samba tops at 100% CPU usage on one core. Is it possible the rl(4) driver could be influenced by high CPU load? With the ale(4) driver, there's no problem but the Samba transfer becomes really slow because of the amount of files. Gabriel 2008/11/18 Gabriel Lavoie > By the way, I'm currently trying the ale(4) driver under FreeBSD 7.0 (my > current installation). It seems to works flawlesly with excellent > performances. I'm currently doing the 30 GB transfer I'm unable to do with > the Realtek card. I'll see what happens. > > Gabriel > > 2008/11/16 Pyun YongHyeon > > On Sun, Nov 16, 2008 at 06:01:58PM -0500, Gabriel Lavoie wrote: >> > Hello, >> > I recently built a new system to use as a home server. This system >> has >> > an Intel Pentium Dual Core E5200, 4GB RAM and an Asus P5KPL-CM >> motherboard >> > which has an Atheros L1E network adapter, not yet supported on FreeBSD. >> For >> >> ale(4) was committed to HEAD. If you're using lastest stable/7 >> see the following URL. >> http://people.freebsd.org/~yongari/ale/README >> >> > now, I use a Realtek 8139 PCI adapter that uses the rl(4) driver, but >> the >> > upload performances are really poor (under 1 MB/sec). Is there any way >> to >> > improve the performance with this driver? This adapter was in a Linux >> system >> > with a Pentium III processor before and I could upload/download at >> around 10 >> > MB/sec in my local network with no problem at all. >> > >> >> There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. >> How about rl(4) in HEAD? I guess it would build with minor >> modification. >> >> -- >> Regards, >> Pyun YongHyeon >> > > > > -- > Gabriel Lavoie > glavoie@gmail.com > -- Gabriel Lavoie glavoie@gmail.com From andre at freebsd.org Wed Nov 19 01:09:18 2008 From: andre at freebsd.org (Andre Oppermann) Date: Wed Nov 19 01:09:29 2008 Subject: tokenring users? In-Reply-To: <49233959.9040903@ironport.com> References: <49233959.9040903@ironport.com> Message-ID: <4923D7C0.7050301@freebsd.org> Julian Elischer wrote: > One of the things that are making things hard for network testing is the > question > "what to do about tokenring support?" > > We seem to have a dearth of tokenring users so we are completely unable > test how changes affect tokenring. > > If anyone here knows anyone whoul could: > 1/ help support tokenring > 2/ help test tokenring, > > could they get in touch? I guess Token Ring is as dead as it gets. The last I time ran across someone using it was in 1996 or 1997. I asked our engineers here (on a customer base of about 1k SME) and got only blank stares. -- Andre From julian at ironport.com Wed Nov 19 01:52:45 2008 From: julian at ironport.com (Julian Elischer) Date: Wed Nov 19 01:52:52 2008 Subject: tokenring users? In-Reply-To: <4923D7C0.7050301@freebsd.org> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> Message-ID: <4923DB2D.2080702@ironport.com> Andre Oppermann wrote: > Julian Elischer wrote: >> One of the things that are making things hard for network testing is >> the question >> "what to do about tokenring support?" >> >> We seem to have a dearth of tokenring users so we are completely unable >> test how changes affect tokenring. >> >> If anyone here knows anyone whoul could: >> 1/ help support tokenring >> 2/ help test tokenring, >> >> could they get in touch? > > I guess Token Ring is as dead as it gets. The last I time ran across > someone using it was in 1996 or 1997. I asked our engineers here (on > a customer base of about 1k SME) and got only blank stares. > yes I think that may be the case but I saw a bug report about it a few years ago.. From bzeeb-lists at lists.zabbadoz.net Wed Nov 19 02:30:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Nov 19 02:30:15 2008 Subject: tokenring users? In-Reply-To: <4923DB2D.2080702@ironport.com> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> Message-ID: <20081119102301.R61259@maildrop.int.zabbadoz.net> On Wed, 19 Nov 2008, Julian Elischer wrote: Hi, > Andre Oppermann wrote: >> Julian Elischer wrote: >>> One of the things that are making things hard for network testing is the >>> question >>> "what to do about tokenring support?" >>> >>> We seem to have a dearth of tokenring users so we are completely unable >>> test how changes affect tokenring. >>> >>> If anyone here knows anyone whoul could: >>> 1/ help support tokenring >>> 2/ help test tokenring, >>> >>> could they get in touch? >> >> I guess Token Ring is as dead as it gets. The last I time ran across >> someone using it was in 1996 or 1997. I asked our engineers here (on >> a customer base of about 1k SME) and got only blank stares. >> > > yes I think that may be the case but I saw a bug report > about it a few years ago.. I have given away all my TR equipment a few years back, but I know people still running TR though with Cisco and non-FreeBSD-OSes though they got rid of all TR they could get rid off. So what exactly is your question in supporting and testing FreeBSD TR support? And let me ask why you are asking for TR, not FDDI or some of the other things lingering in sys/net**? /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From brueffer at FreeBSD.org Wed Nov 19 03:06:05 2008 From: brueffer at FreeBSD.org (Christian Brueffer) Date: Wed Nov 19 03:06:11 2008 Subject: tokenring users? In-Reply-To: <4923DB2D.2080702@ironport.com> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> Message-ID: <20081119103602.GA2339@haakonia.hitnet.RWTH-Aachen.DE> On Wed, Nov 19, 2008 at 01:23:57AM -0800, Julian Elischer wrote: > Andre Oppermann wrote: > >Julian Elischer wrote: > >>One of the things that are making things hard for network testing is > >>the question > >>"what to do about tokenring support?" > >> > >>We seem to have a dearth of tokenring users so we are completely unable > >>test how changes affect tokenring. > >> > >>If anyone here knows anyone whoul could: > >>1/ help support tokenring > >>2/ help test tokenring, > >> > >>could they get in touch? > > > >I guess Token Ring is as dead as it gets. The last I time ran across > >someone using it was in 1996 or 1997. I asked our engineers here (on > >a customer base of about 1k SME) and got only blank stares. > > > > yes I think that may be the case but I saw a bug report > about it a few years ago.. > The last (afaik) in-tree token-ring driver we had was oltr(4) which has been removed from HEAD not too long ago. So the questions is whether there are companies with custom drivers. - 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/20081119/9bbd529b/attachment.pgp From rrs at lakerest.net Wed Nov 19 07:00:30 2008 From: rrs at lakerest.net (Randall Stewart) Date: Wed Nov 19 07:01:02 2008 Subject: Thinking about UDP and tunneling Message-ID: Dear All: I have been contemplating UDP and tunneling. One of the things that is a nice feature in MacOS is the ability of a kernel module/extension to open a kernel level socket and have the mbuf chain that arrives for that port be passed in via a function. We use this in our MacOS version of the SCTP stack to do the UDP de-tunneling of SCTP packets. This is becoming a more and more common thing i.e. having transport protocols like SCTP and DCCP be tunneled over UDP to get by NAT's.... this actually sucks that this is necessary .. but it is what it is.... So, I am contemplating adding a similar sort of feature... basically provide an interface in UDP that a consumer (such as SCTP or DCCP) could use to "bind" a port and get UDP packets directly. What do you all think of the idea? That also reminds me.. who owns the ipfw code.. we actually have SCTP nat support that Jason But has done that we need to get in... I would be more than glad to shepherd this in if the owner of the code does not have the time... R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From max at love2party.net Wed Nov 19 07:45:29 2008 From: max at love2party.net (Max Laier) Date: Wed Nov 19 07:45:36 2008 Subject: Thinking about UDP and tunneling In-Reply-To: References: Message-ID: <200811191645.26701.max@love2party.net> On Wednesday 19 November 2008 16:00:27 Randall Stewart wrote: > Dear All: > > I have been contemplating UDP and tunneling. One of the > things that is a nice feature in MacOS is the ability of > a kernel module/extension to open a kernel level socket > and have the mbuf chain that arrives for that port be passed > in via a function. > > We use this in our MacOS version of the SCTP stack to do the > UDP de-tunneling of SCTP packets. This is becoming a more and > more common thing i.e. having transport protocols like SCTP and DCCP > be tunneled over UDP to get by NAT's.... this actually sucks that > this is necessary .. but it is what it is.... > > So, I am contemplating adding a similar sort of feature... basically > provide an interface in UDP that a consumer (such as SCTP or DCCP) could > use to "bind" a port and get UDP packets directly. > > What do you all think of the idea? What is wrong with the existing socket(9) API? > That also reminds me.. who owns the ipfw code.. we actually > have SCTP nat support that Jason But has done that we need to > get in... > > I would be more than glad to shepherd this in if the owner > of the code does not have the time... "Depends ..." ... for ipfw2 core you might be looking for luigi@, for the libalias stuff: piso@ did the kernel inclusion more or less recently ... other than that: svn log -qr HEAD:\{2006-01-01\} | grep ^r | cut -d"|" -f2 | sort | \ uniq -c | sort in sys/netinet/libalias gives a list of people who touched that code recently (for some definition of recently). I'd be happy to take a look, too ... though I might need some time for a proper review. In general, you touch it you bought it! -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From rizzo at iet.unipi.it Wed Nov 19 07:50:23 2008 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Wed Nov 19 07:50:30 2008 Subject: Thinking about UDP and tunneling In-Reply-To: References: Message-ID: <20081119153532.GB2910@onelab2.iet.unipi.it> On Wed, Nov 19, 2008 at 10:00:27AM -0500, Randall Stewart wrote: > Dear All: > > I have been contemplating UDP and tunneling. One of the > things that is a nice feature in MacOS is the ability of > a kernel module/extension to open a kernel level socket > and have the mbuf chain that arrives for that port be passed > in via a function. > > We use this in our MacOS version of the SCTP stack to do the > UDP de-tunneling of SCTP packets. This is becoming a more and > more common thing i.e. having transport protocols like SCTP and DCCP > be tunneled over UDP to get by NAT's.... this actually sucks that > this is necessary .. but it is what it is.... > > So, I am contemplating adding a similar sort of feature... basically > provide an interface in UDP that a consumer (such as SCTP or DCCP) could > use to "bind" a port and get UDP packets directly. > > What do you all think of the idea? the way (not the only one, but one way) this kind of things can be done now is have ipfw select the traffic, and pass it to one in-kernel natd instance, and after the work that Paolo Pisati did for SoC 2005 (it think) the mechanism is extensible in a relatively easy way to provide specific functions to do the mmbuf manipulation. > That also reminds me.. who owns the ipfw code.. we actually > have SCTP nat support that Jason But has done that we need to > get in... > > I would be more than glad to shepherd this in if the owner > of the code does not have the time... there isn't really a owner, over time different people including myself have worked on various aspects of the code -- if your changes affect only natd extensions then Paolo Pisati (piso@) is probably a good starting contact. You may want to have a look at the recent and not-so-recent commit history to see who did other relevant pieces of work such as dealing with locking, improving performance in SMP and so on. cheers luigi From julian at ironport.com Wed Nov 19 10:08:16 2008 From: julian at ironport.com (Julian Elischer) Date: Wed Nov 19 10:08:22 2008 Subject: tokenring users? In-Reply-To: <20081119102301.R61259@maildrop.int.zabbadoz.net> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> <20081119102301.R61259@maildrop.int.zabbadoz.net> Message-ID: <4924560D.8000101@ironport.com> Bjoern A. Zeeb wrote: > On Wed, 19 Nov 2008, Julian Elischer wrote: > > Hi, > >> Andre Oppermann wrote: >>> Julian Elischer wrote: >>>> One of the things that are making things hard for network testing >>>> is the question >>>> "what to do about tokenring support?" >>>> >>>> We seem to have a dearth of tokenring users so we are completely >>>> unable >>>> test how changes affect tokenring. >>>> >>>> If anyone here knows anyone whoul could: >>>> 1/ help support tokenring >>>> 2/ help test tokenring, >>>> >>>> could they get in touch? >>> >>> I guess Token Ring is as dead as it gets. The last I time ran across >>> someone using it was in 1996 or 1997. I asked our engineers here (on >>> a customer base of about 1k SME) and got only blank stares. >>> >> >> yes I think that may be the case but I saw a bug report >> about it a few years ago.. > > I have given away all my TR equipment a few years back, but I know people > still running TR though with Cisco and non-FreeBSD-OSes though they > got rid > of all TR they could get rid off. > > So what exactly is your question in supporting and testing FreeBSD TR > support? > > And let me ask why you are asking for TR, not FDDI or some of the > other things lingering in sys/net**? > > /bz > There are some vestiges of tokenring support in the system but since htey can't really be tested, people have been making "guessing" changes to them as things go forward. We don't know if they really work. If there are no tokenring users we might as well remove the clutter. I don't really know about FDDI support.. do we have it? From julian at ironport.com Wed Nov 19 10:09:52 2008 From: julian at ironport.com (Julian Elischer) Date: Wed Nov 19 10:09:59 2008 Subject: tokenring users? In-Reply-To: <20081119103602.GA2339@haakonia.hitnet.RWTH-Aachen.DE> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> <20081119103602.GA2339@haakonia.hitnet.RWTH-Aachen.DE> Message-ID: <4924566E.5060403@ironport.com> Christian Brueffer wrote: > On Wed, Nov 19, 2008 at 01:23:57AM -0800, Julian Elischer wrote: > >> Andre Oppermann wrote: >> >>> Julian Elischer wrote: >>> >>>> One of the things that are making things hard for network testing is >>>> the question >>>> "what to do about tokenring support?" >>>> >>>> We seem to have a dearth of tokenring users so we are completely unable >>>> test how changes affect tokenring. >>>> >>>> If anyone here knows anyone whoul could: >>>> 1/ help support tokenring >>>> 2/ help test tokenring, >>>> >>>> could they get in touch? >>>> >>> I guess Token Ring is as dead as it gets. The last I time ran across >>> someone using it was in 1996 or 1997. I asked our engineers here (on >>> a customer base of about 1k SME) and got only blank stares. >>> >>> >> yes I think that may be the case but I saw a bug report >> about it a few years ago.. >> >> > > The last (afaik) in-tree token-ring driver we had was oltr(4) which has > been removed from HEAD not too long ago. So the questions is whether > there are companies with custom drivers. > exactly.. but there could be people using (or planning to use it) in on 7.x. > - Christian > > From max at love2party.net Wed Nov 19 11:13:55 2008 From: max at love2party.net (Max Laier) Date: Wed Nov 19 11:14:02 2008 Subject: tokenring users? In-Reply-To: <4923D7C0.7050301@freebsd.org> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> Message-ID: <200811192013.53405.max@love2party.net> On Wednesday 19 November 2008 10:09:20 Andre Oppermann wrote: > Julian Elischer wrote: > > One of the things that are making things hard for network testing is the > > question > > "what to do about tokenring support?" > > > > We seem to have a dearth of tokenring users so we are completely unable > > test how changes affect tokenring. > > > > If anyone here knows anyone whoul could: > > 1/ help support tokenring > > 2/ help test tokenring, > > > > could they get in touch? > > I guess Token Ring is as dead as it gets. The last I time ran across > someone using it was in 1996 or 1997. I asked our engineers here (on > a customer base of about 1k SME) and got only blank stares. From the experience of replacing ~200 IBM token-ring terminals with ethernet PCs & terminal emulators in a hospital back in 2001 ... yeah, it's dead. Back then the rational was that it was already cheaper to buy a PC, ethernet card and do the wiring than it was to get a replacement for a broken token ring card - let alone the hub that decided to die in the midst of the end-of-year tax report season. While TR was nice back in the days of 10Mbit ethernet hub days, there is no longer a market for it, except for the aforementioned IBM terminal - where FreeBSD really doesn't play. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From julian at elischer.org Wed Nov 19 11:14:45 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Nov 19 11:15:48 2008 Subject: Thinking about UDP and tunneling In-Reply-To: References: Message-ID: <49245EE3.2000700@elischer.org> Randall Stewart wrote: > Dear All: > > I have been contemplating UDP and tunneling. One of the > things that is a nice feature in MacOS is the ability of > a kernel module/extension to open a kernel level socket > and have the mbuf chain that arrives for that port be passed > in via a function. define "kernel level" and "mbuf chain that arrives [...] passed in via a function" > > We use this in our MacOS version of the SCTP stack to do the > UDP de-tunneling of SCTP packets. This is becoming a more and > more common thing i.e. having transport protocols like SCTP and DCCP > be tunneled over UDP to get by NAT's.... this actually sucks that > this is necessary .. but it is what it is.... I do that using netgraph.. set a point ot point ng_iface and hook the other end to a netgraph ksocket which is bound/connaected where you want. "just works" > > So, I am contemplating adding a similar sort of feature... basically > provide an interface in UDP that a consumer (such as SCTP or DCCP) could > use to "bind" a port and get UDP packets directly. > > What do you all think of the idea? Well netgraph allows you to do it already > > > That also reminds me.. who owns the ipfw code.. we actually > have SCTP nat support that Jason But has done that we need to > get in... > > I would be more than glad to shepherd this in if the owner > of the code does not have the time... > > > R > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) > > _______________________________________________ > 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 julian at ironport.com Wed Nov 19 11:42:12 2008 From: julian at ironport.com (Julian Elischer) Date: Wed Nov 19 11:42:19 2008 Subject: tokenring users? In-Reply-To: <20081119123600.E30755@claw.omgcats.com> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> <20081119123600.E30755@claw.omgcats.com> Message-ID: <49246C12.8080201@ironport.com> Mike Holling wrote: >> yes I think that may be the case but I saw a bug report >> about it a few years ago.. >> > > in 2004? i was using tokenring for a project and had problems with some > cards that should have been supported (triple port card with a supported > chipset). don't need it any more though. > > - Mike > > (yay) (makes official requisition for Danish axe.) my only worry is FDDI support... 1/ do we have any 2/ if so, does it use any of the tokenring support? I don;t really know much about FDDI. Wouldn't want to remove anything still in use by something else. From rpaulo at freebsd.org Wed Nov 19 12:01:11 2008 From: rpaulo at freebsd.org (Rui Paulo) Date: Wed Nov 19 12:01:18 2008 Subject: TCP and syncache question In-Reply-To: <4921F2CD.503@freebsd.org> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> Message-ID: <403932D0-8B62-4C95-8076-A185AC1C69E7@freebsd.org> On 17 Nov 2008, at 22:40, Andre Oppermann wrote: > This is a bit more complicated because of interactions with > tcp_input() > where syncache_expand() is called from. > > The old code (as of December 2002) behaved slightly different. It > would > not remove the syncache entry when (SND.UNA == SEG.ACK) but send a > RST. > The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't > done at > all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) > succeeded. > This gave way to the "LAND" DoS attack which was mostly fixed with a > test > for (RCV.IRS < SEG.SEQ). > > See the attached patch for fixed version of syncache_expand(). This > patch > is untested though. My development machine is currently down. > Harti, Rui > and Bjoern, please have a look at the patch and review it. > > -- > Andre > > --- tcp_input.c.1.390 Mon Nov 17 21:33:25 2008 > +++ tcp_input.c.1.390.mod Mon Nov 17 21:35:22 2008 > @@ -642,10 +642,13 @@ findpcb: > if (!syncache_expand(&inc, &to, th, &so, m)) { > /* > * No syncache entry or ACK was not > - * for our SYN/ACK. Send a RST. > + * for our SYN/ACK. Send a RST or > + * an ACK for re-synchronization. > * NB: syncache did its own logging > * of the failure cause. > */ > + if (so == 1) > + goto dropunlock; > rstreason = BANDLIM_RST_OPENPORT; > goto dropwithreset; > } > --- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008 > +++ tcp_syncache.c.1.160.mod Mon Nov 17 23:35:39 2008 > @@ -817,59 +817,47 @@ syncache_expand(struct in_conninfo *inc, > INP_INFO_WLOCK_ASSERT(&V_tcbinfo); > KASSERT((th->th_flags & (TH_RST|TH_ACK|TH_SYN)) == TH_ACK, > ("%s: can handle only ACK", __func__)); > + *lsop = NULL; > > sc = syncache_lookup(inc, &sch); /* returns locked sch */ > SCH_LOCK_ASSERT(sch); > if (sc == NULL) { > /* > * There is no syncache entry, so see if this ACK is > - * a returning syncookie. To do this, first: > - * A. See if this socket has had a syncache entry dropped in > - * the past. We don't want to accept a bogus syncookie > - * if we've never received a SYN. > - * B. check that the syncookie is valid. If it is, then > - * cobble up a fake syncache entry, and return. > + * a returning syncookie. If the syncookie is valid, > + * cobble up a fake syncache entry and create a socket. > + * > + * NB: Syncache head is locked for the syncookie access. > */ > if (!tcp_syncookies) { > - SCH_UNLOCK(sch); > if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > log(LOG_DEBUG, "%s; %s: Spurious ACK, " > "segment rejected (syncookies disabled)\n", > s, __func__); > - goto failed; > + goto sendrst; > } > bzero(&scs, sizeof(scs)); > sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop); > - SCH_UNLOCK(sch); > if (sc == NULL) { > if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > log(LOG_DEBUG, "%s; %s: Segment failed " > "SYNCOOKIE authentication, segment rejected " > "(probably spoofed)\n", s, __func__); > - goto failed; > + goto sendrst; > } > - } else { > - /* Pull out the entry to unlock the bucket row. */ > - TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); > - sch->sch_length--; > - V_tcp_syncache.cache_count--; > - SCH_UNLOCK(sch); > + goto expand; /* fully validated through syncookie */ > } > + SCH_LOCK_ASSERT(sch); Why do you need this assert? > > > /* > * Segment validation: > - * ACK must match our initial sequence number + 1 (the SYN|ACK). > - */ > - if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { > - if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > - log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " > - "rejected\n", s, __func__, th->th_ack, sc->sc_iss); > - goto failed; > - } > - > - /* > + * > * The SEQ must fall in the window starting at the received > * initial receive sequence number + 1 (the SYN). > + * If not the segment may be from an earlier connection. We send > + * an ACK to re-synchronize the connection and keep the syncache > + * entry without ajusting its timers. > + * See RFC793 page 69, first check sequence number [SYN_RECEIVED]. > */ > if ((SEQ_LEQ(th->th_seq, sc->sc_irs) || > SEQ_GT(th->th_seq, sc->sc_irs + sc->sc_wnd)) && > @@ -877,14 +865,41 @@ syncache_expand(struct in_conninfo *inc, > if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > log(LOG_DEBUG, "%s; %s: SEQ %u != IRS+1 %u, segment " > "rejected\n", s, __func__, th->th_seq, sc->sc_irs); > - goto failed; > + (void) syncache_respond(sc); > + *lsop = 1; /* prevent RST */ > + goto sendrstkeep; > } > > + /* > + * ACK must match our initial sequence number + 1 (the SYN|ACK). > + * If not the segment may be from an earlier connection. We send > + * a RST but keep the syncache entry without ajusting its timers. > + * See RFC793 page 72, fifth check the ACK field, [SYN_RECEIVED]. > + */ > + if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { > + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > + log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " > + "rejected\n", s, __func__, th->th_ack, sc->sc_iss); > + goto sendrstkeep; > + } > + > + /* > + * Remove the entry to unlock the bucket row. > + * Tests from now on are fatal and remove the syncache entry. > + */ > + TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); > + sch->sch_length--; > + V_tcp_syncache.cache_count--; > + > + /* > + * If timestamps were not negotiated they must not show up later. > + * See RFC1312bis, section 1.3, second paragraph > + */ > if (!(sc->sc_flags & SCF_TIMESTAMP) && (to->to_flags & TOF_TS)) { > if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > log(LOG_DEBUG, "%s; %s: Timestamp not expected, " > "segment rejected\n", s, __func__); > - goto failed; > + goto sendrst; > } > /* > * If timestamps were negotiated the reflected timestamp > @@ -896,9 +911,11 @@ syncache_expand(struct in_conninfo *inc, > log(LOG_DEBUG, "%s; %s: TSECR %u != TS %u, " > "segment rejected\n", > s, __func__, to->to_tsecr, sc->sc_ts); > - goto failed; > + goto sendrst; > } > > +expand: > + SCH_UNLOCK(sch); > *lsop = syncache_socket(sc, *lsop, m); > > if (*lsop == NULL) > @@ -906,16 +923,18 @@ syncache_expand(struct in_conninfo *inc, > else > V_tcpstat.tcps_sc_completed++; > > -/* how do we find the inp for the new socket? */ > if (sc != &scs) > syncache_free(sc); > return (1); > -failed: > - if (sc != NULL && sc != &scs) > + > +sendrst: > + if (sc != &scs) > syncache_free(sc); > +sendrstkeep: > + SCH_LOCK_ASSERT(sch); > + SCH_UNLOCK(sch); Why do we need an assert before an unlock? > > if (s != NULL) > free(s, M_TCPLOG); > - *lsop = NULL; > return (0); > } > This was probably out of scope: > @@ -1322,6 +1341,8 @@ syncache_respond(struct syncache *sc) > * > * 1) path_mtu_discovery is disabled > * 2) the SCF_UNREACH flag has been set > + * > + * XXXAO: The route lookup comment doesn't make sense. > */ > if (V_path_mtu_discovery && ((sc->sc_flags & SCF_UNREACH) == 0)) > ip->ip_off |= IP_DF; I won't be able to test this any time soon, so I can't really comment on the rest, but it *looks* okay. Regards, -- Rui Paulo From myke at omgcats.com Wed Nov 19 12:06:00 2008 From: myke at omgcats.com (Mike Holling) Date: Wed Nov 19 12:06:07 2008 Subject: tokenring users? In-Reply-To: <4923DB2D.2080702@ironport.com> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> Message-ID: <20081119123600.E30755@claw.omgcats.com> > yes I think that may be the case but I saw a bug report > about it a few years ago.. in 2004? i was using tokenring for a project and had problems with some cards that should have been supported (triple port card with a supported chipset). don't need it any more though. - Mike From rrs at lakerest.net Wed Nov 19 12:22:40 2008 From: rrs at lakerest.net (Randall Stewart) Date: Wed Nov 19 12:22:47 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <200811191645.26701.max@love2party.net> References: <200811191645.26701.max@love2party.net> Message-ID: <9E86085F-ECAC-4C2E-ABE4-10AFB28480B3@lakerest.net> On Nov 19, 2008, at 10:45 AM, Max Laier wrote: > On Wednesday 19 November 2008 16:00:27 Randall Stewart wrote: >> Dear All: >> >> I have been contemplating UDP and tunneling. One of the >> things that is a nice feature in MacOS is the ability of >> a kernel module/extension to open a kernel level socket >> and have the mbuf chain that arrives for that port be passed >> in via a function. >> >> We use this in our MacOS version of the SCTP stack to do the >> UDP de-tunneling of SCTP packets. This is becoming a more and >> more common thing i.e. having transport protocols like SCTP and DCCP >> be tunneled over UDP to get by NAT's.... this actually sucks that >> this is necessary .. but it is what it is.... >> >> So, I am contemplating adding a similar sort of feature... basically >> provide an interface in UDP that a consumer (such as SCTP or DCCP) >> could >> use to "bind" a port and get UDP packets directly. >> >> What do you all think of the idea? > > What is wrong with the existing socket(9) API? The problem with this is many fold.. 1) This works nicely for NFS and other FS based things that it was designed for I think. 2) A transport DCCP/SCTP/Next-Tunneled-Transport would need to have a thread reading, and would then need to enable the options to get the to addresses as well.. then reconstruct an IP header. Rather ugly when all you want is the mbuf chain passed in to the transport so that it can m_adj out the udp header and then its got the full IP plus the transport.... same as if it has arrived on the wire. What a transport being tunneled really wants is an easy way to have normal ip_input call it.. but also have a way to get the mbuf chain, supply a minor routine that strips udp, and then call the same routine as ip_input... giving the same look/and/feel as if it had come in off the wire.. > > >> That also reminds me.. who owns the ipfw code.. we actually >> have SCTP nat support that Jason But has done that we need to >> get in... >> >> I would be more than glad to shepherd this in if the owner >> of the code does not have the time... > > "Depends ..." ... for ipfw2 core you might be looking for luigi@, > for the > libalias stuff: piso@ did the kernel inclusion more or less > recently ... other > than that: > > svn log -qr HEAD:\{2006-01-01\} | grep ^r | cut -d"|" -f2 | sort | \ > uniq -c | sort > > in sys/netinet/libalias gives a list of people who touched that code > recently > (for some definition of recently). > > I'd be happy to take a look, too ... though I might need some time > for a > proper review. > > In general, you touch it you bought it! I have not reviewed the code myself.. and I will download it shortly and do so.. I think this is a ipfw (not 2) thing.. but I will have to check... more eyes is a good thing though.. R > > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From rrs at lakerest.net Wed Nov 19 12:24:09 2008 From: rrs at lakerest.net (Randall Stewart) Date: Wed Nov 19 12:24:15 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <20081119153532.GB2910@onelab2.iet.unipi.it> References: <20081119153532.GB2910@onelab2.iet.unipi.it> Message-ID: On Nov 19, 2008, at 10:35 AM, Luigi Rizzo wrote: > On Wed, Nov 19, 2008 at 10:00:27AM -0500, Randall Stewart wrote: >> Dear All: >> >> I have been contemplating UDP and tunneling. One of the >> things that is a nice feature in MacOS is the ability of >> a kernel module/extension to open a kernel level socket >> and have the mbuf chain that arrives for that port be passed >> in via a function. >> >> We use this in our MacOS version of the SCTP stack to do the >> UDP de-tunneling of SCTP packets. This is becoming a more and >> more common thing i.e. having transport protocols like SCTP and DCCP >> be tunneled over UDP to get by NAT's.... this actually sucks that >> this is necessary .. but it is what it is.... >> >> So, I am contemplating adding a similar sort of feature... basically >> provide an interface in UDP that a consumer (such as SCTP or DCCP) >> could >> use to "bind" a port and get UDP packets directly. >> >> What do you all think of the idea? > > the way (not the only one, but one way) this kind of things > can be done now is have ipfw select the traffic, and pass it > to one in-kernel natd instance, and after the work that Paolo Pisati > did for SoC 2005 (it think) the mechanism is extensible in > a relatively easy way to provide specific functions to do > the mmbuf manipulation. Interesting idea, but the destination of the packets MAY NOT be the same box the fw/nat is on. So this means I now have to enable ipfw/nat on all boxes that want to have tunneling.. Not exactly very friendly... > > >> That also reminds me.. who owns the ipfw code.. we actually >> have SCTP nat support that Jason But has done that we need to >> get in... >> >> I would be more than glad to shepherd this in if the owner >> of the code does not have the time... > > there isn't really a owner, over time different people including > myself have worked > on various aspects of the code -- if your changes affect only > natd extensions then Paolo Pisati (piso@) is probably a good > starting contact. You may want to have a look at the recent > and not-so-recent commit history to see who did other relevant > pieces of work such as dealing with locking, improving performance > in SMP and so on. I think it must be Paolo.. I will give him a ping R > > > cheers > luigi > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From rrs at lakerest.net Wed Nov 19 12:30:34 2008 From: rrs at lakerest.net (Randall Stewart) Date: Wed Nov 19 12:30:51 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <49245EE3.2000700@elischer.org> References: <49245EE3.2000700@elischer.org> Message-ID: On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: > Randall Stewart wrote: >> Dear All: >> I have been contemplating UDP and tunneling. One of the >> things that is a nice feature in MacOS is the ability of >> a kernel module/extension to open a kernel level socket >> and have the mbuf chain that arrives for that port be passed >> in via a function. > > define "kernel level" and "mbuf chain that arrives [...] passed in > via a function" > > > >> We use this in our MacOS version of the SCTP stack to do the >> UDP de-tunneling of SCTP packets. This is becoming a more and >> more common thing i.e. having transport protocols like SCTP and DCCP >> be tunneled over UDP to get by NAT's.... this actually sucks that >> this is necessary .. but it is what it is.... > > I do that using netgraph.. > set a point ot point ng_iface and hook the other end to > a netgraph ksocket which is bound/connaected where you want. > > "just works" > >> So, I am contemplating adding a similar sort of feature... basically >> provide an interface in UDP that a consumer (such as SCTP or DCCP) >> could >> use to "bind" a port and get UDP packets directly. >> What do you all think of the idea? > > Well netgraph allows you to do it already Not sure what netgraph does... what is wanted is this in comes +-----+ | IP | +-----+ | UDP | +-----+ | Oth | | tra | | por | | t h | | ead | | er | | and | | dat | | a. | +-----+ Ideally it runs into UDP via ip_input() and comes down to where it would append() to the socket. What you want in this case is the whole mbuf chain to be sent to the transport_udp_input(m, offset) function This changes the above to +-----+ | IP | +-----+ | Oth | | tra | | por | | t h | | ead | | er | | and | | dat | | a. | +-----+ And sends it into the transport_input() (same one called by ip_input). This then makes a clean and easy way to have "tunneled UDP" transport protocols work in kernel. The input side looks the same. Output is pretty easy.. easy to drop a UDP header in out output... Netgraph would have to be watching every UDP packet always.. seems to me easier to bind a kernel level socket with some option to call an input function.... R > > >> That also reminds me.. who owns the ipfw code.. we actually >> have SCTP nat support that Jason But has done that we need to >> get in... >> I would be more than glad to shepherd this in if the owner >> of the code does not have the time... >> R >> ------------------------------ >> Randall Stewart >> 803-317-4952 (cell) >> 803-345-0391(direct) >> _______________________________________________ >> 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" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From julian at elischer.org Wed Nov 19 12:50:14 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Nov 19 12:50:27 2008 Subject: Thinking about UDP and tunneling In-Reply-To: References: <49245EE3.2000700@elischer.org> Message-ID: <49247BEE.4040201@elischer.org> Randall Stewart wrote: > > On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: > >> Randall Stewart wrote: >>> Dear All: >>> I have been contemplating UDP and tunneling. One of the >>> things that is a nice feature in MacOS is the ability of >>> a kernel module/extension to open a kernel level socket >>> and have the mbuf chain that arrives for that port be passed >>> in via a function. >> >> define "kernel level" and "mbuf chain that arrives [...] passed in via >> a function" >> >> >> >>> We use this in our MacOS version of the SCTP stack to do the >>> UDP de-tunneling of SCTP packets. This is becoming a more and >>> more common thing i.e. having transport protocols like SCTP and DCCP >>> be tunneled over UDP to get by NAT's.... this actually sucks that >>> this is necessary .. but it is what it is.... >> >> I do that using netgraph.. >> set a point ot point ng_iface and hook the other end to >> a netgraph ksocket which is bound/connaected where you want. >> >> "just works" >> >>> So, I am contemplating adding a similar sort of feature... basically >>> provide an interface in UDP that a consumer (such as SCTP or DCCP) could >>> use to "bind" a port and get UDP packets directly. >>> What do you all think of the idea? >> >> Well netgraph allows you to do it already > > > Not sure what netgraph does... what is wanted is this in comes > > > +-----+ > | IP | > +-----+ > | UDP | > +-----+ > | Oth | > | tra | > | por | > | t h | > | ead | > | er | > | and | > | dat | > | a. | > +-----+ Othtra port header and data.? > > > Ideally it runs into UDP via ip_input() > and comes down to where it would append() to the socket. At this point, netgraph grabs it and passes the mbufs wherever you tell it to pass them. > > What you want in this case is the whole mbuf chain to be sent > to the transport_udp_input(m, offset) function cd /sys root@trafmon1:grep transport_udp_input net*/* root@trafmon1:grep transport_udp_input net*/*/* > > This changes the above to > +-----+ > | IP | > +-----+ > | Oth | > | tra | > | por | > | t h | > | ead | > | er | > | and | > | dat | > | a. | > +-----+ where does the new IP header information come from? > > And sends it into the transport_input() (same one called by ip_input). > > This then makes a clean and easy way to have "tunneled UDP" transport > protocols > work in kernel. The input side looks the same. Output is pretty easy.. > easy to > drop a UDP header in out output... > > > Netgraph would have to be watching every UDP packet always.. just those that go to that ksocket. we hook on at the socketbuf point. > > seems to me easier to bind a kernel level socket with some option > to call an input function.... > > R > > > >> >> >>> That also reminds me.. who owns the ipfw code.. we actually >>> have SCTP nat support that Jason But has done that we need to >>> get in... >>> I would be more than glad to shepherd this in if the owner >>> of the code does not have the time... >>> R >>> ------------------------------ >>> Randall Stewart >>> 803-317-4952 (cell) >>> 803-345-0391(direct) >>> _______________________________________________ >>> 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" >> > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) From rrs at lakerest.net Wed Nov 19 13:30:31 2008 From: rrs at lakerest.net (Randall Stewart) Date: Wed Nov 19 13:30:49 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <49247BEE.4040201@elischer.org> References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> Message-ID: <905A5B58-54D2-4B79-A1B4-44C6D5136691@lakerest.net> On Nov 19, 2008, at 3:49 PM, Julian Elischer wrote: > Randall Stewart wrote: >> On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: >>> Randall Stewart wrote: >>>> Dear All: >>>> I have been contemplating UDP and tunneling. One of the >>>> things that is a nice feature in MacOS is the ability of >>>> a kernel module/extension to open a kernel level socket >>>> and have the mbuf chain that arrives for that port be passed >>>> in via a function. >>> >>> define "kernel level" and "mbuf chain that arrives [...] passed in >>> via a function" >>> >>> >>> >>>> We use this in our MacOS version of the SCTP stack to do the >>>> UDP de-tunneling of SCTP packets. This is becoming a more and >>>> more common thing i.e. having transport protocols like SCTP and >>>> DCCP >>>> be tunneled over UDP to get by NAT's.... this actually sucks that >>>> this is necessary .. but it is what it is.... >>> >>> I do that using netgraph.. >>> set a point ot point ng_iface and hook the other end to >>> a netgraph ksocket which is bound/connaected where you want. >>> >>> "just works" >>> >>>> So, I am contemplating adding a similar sort of feature... >>>> basically >>>> provide an interface in UDP that a consumer (such as SCTP or >>>> DCCP) could >>>> use to "bind" a port and get UDP packets directly. >>>> What do you all think of the idea? >>> >>> Well netgraph allows you to do it already >> Not sure what netgraph does... what is wanted is this in comes >> +-----+ >> | IP | >> +-----+ >> | UDP | >> +-----+ >> | Oth | >> | tra | >> | por | >> | t h | >> | ead | >> | er | >> | and | >> | dat | >> | a. | >> +-----+ > > > Othtra port header and data.? Of course... full transport layer header.. for sctp its port port vtag checksum first-chunk header etc.. > > > >> Ideally it runs into UDP via ip_input() >> and comes down to where it would append() to the socket. > > At this point, netgraph grabs it and passes the mbufs wherever you > tell it to pass them. Sounds interesting... two questions: 1) And how do we configure netgraph to do this? (pointers to doco's is fine) 2) Is netgraph in the GENERIC... I would like to see this work out of the box.. > > >> What you want in this case is the whole mbuf chain to be sent >> to the transport_udp_input(m, offset) function > > cd /sys > root@trafmon1:grep transport_udp_input net*/* > root@trafmon1:grep transport_udp_input net*/*/* > > > >> This changes the above to >> +-----+ >> | IP | >> +-----+ >> | Oth | >> | tra | >> | por | >> | t h | >> | ead | >> | er | >> | and | >> | dat | >> | a. | >> +-----+ > > > where does the new IP header information come from? Its not new, its the same ip header.. Its just you go into the mbuf chain and take out the udp header... > > >> And sends it into the transport_input() (same one called by >> ip_input). >> This then makes a clean and easy way to have "tunneled UDP" >> transport protocols >> work in kernel. The input side looks the same. Output is pretty >> easy.. easy to >> drop a UDP header in out output... >> Netgraph would have to be watching every UDP packet always.. > > just those that go to that ksocket. we hook on at the socketbuf > point. Hmm sounds plausible.. R > > >> seems to me easier to bind a kernel level socket with some option >> to call an input function.... >> R >>> >>> >>>> That also reminds me.. who owns the ipfw code.. we actually >>>> have SCTP nat support that Jason But has done that we need to >>>> get in... >>>> I would be more than glad to shepherd this in if the owner >>>> of the code does not have the time... >>>> R >>>> ------------------------------ >>>> Randall Stewart >>>> 803-317-4952 (cell) >>>> 803-345-0391(direct) >>>> _______________________________________________ >>>> 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 >>> " >>> >> ------------------------------ >> Randall Stewart >> 803-317-4952 (cell) >> 803-345-0391(direct) > > _______________________________________________ > 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" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From rrs at lakerest.net Wed Nov 19 13:33:18 2008 From: rrs at lakerest.net (Randall Stewart) Date: Wed Nov 19 13:33:25 2008 Subject: Thinking about UDP and tunneling In-Reply-To: References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> Message-ID: <0252A647-464E-46A7-94E9-A0639083B5AE@lakerest.net> On Nov 19, 2008, at 4:20 PM, Maksim Yevmenkin wrote: > On 11/19/08, Julian Elischer wrote: >> Randall Stewart wrote: >> >>> >>> On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: >>> >>> >>>> Randall Stewart wrote: >>>> >>>>> Dear All: >>>>> I have been contemplating UDP and tunneling. One of the >>>>> things that is a nice feature in MacOS is the ability of >>>>> a kernel module/extension to open a kernel level socket >>>>> and have the mbuf chain that arrives for that port be passed >>>>> in via a function. >>>>> >>>> >>>> define "kernel level" and "mbuf chain that arrives [...] passed >>>> in via a >> function" >>>> >>>> >>>> >>>> >>>>> We use this in our MacOS version of the SCTP stack to do the >>>>> UDP de-tunneling of SCTP packets. This is becoming a more and >>>>> more common thing i.e. having transport protocols like SCTP and >>>>> DCCP >>>>> be tunneled over UDP to get by NAT's.... this actually sucks that >>>>> this is necessary .. but it is what it is.... >>>>> >>>> >>>> I do that using netgraph.. >>>> set a point ot point ng_iface and hook the other end to >>>> a netgraph ksocket which is bound/connaected where you want. >>>> >>>> "just works" >>>> >>>> >>>>> So, I am contemplating adding a similar sort of feature... >>>>> basically >>>>> provide an interface in UDP that a consumer (such as SCTP or DCCP) >> could >>>>> use to "bind" a port and get UDP packets directly. >>>>> What do you all think of the idea? >>>>> >>>> >>>> Well netgraph allows you to do it already >>>> >>> >>> >>> Not sure what netgraph does... what is wanted is this in comes >>> >>> >>> +-----+ >>> | IP | >>> +-----+ >>> | UDP | >>> +-----+ >>> | Oth | >>> | tra | >>> | por | >>> | t h | >>> | ead | >>> | er | >>> | and | >>> | dat | >>> | a. | >>> +-----+ >>> >> >> >> Othtra port header and data.? > > i think it means: "other transport port header and data", that is take > a complete sctp/etc. datagram and stuff in inside udp datagram as > payload. > >> >>> >>> >>> Ideally it runs into UDP via ip_input() >>> and comes down to where it would append() to the socket. >>> >> >> At this point, netgraph grabs it and passes the mbufs wherever you >> tell it >> to pass them. >> >> >>> >>> What you want in this case is the whole mbuf chain to be sent >>> to the transport_udp_input(m, offset) function >>> >> >> cd /sys >> root@trafmon1:grep transport_udp_input net*/* >> root@trafmon1:grep transport_udp_input net*/*/* >> >> >> >> >>> >>> This changes the above to >>> +-----+ >>> | IP | >>> +-----+ >>> | Oth | >>> | tra | >>> | por | >>> | t h | >>> | ead | >>> | er | >>> | and | >>> | dat | >>> | a. | >>> +-----+ >>> >> >> >> where does the new IP header information come from? >> >> >>> >>> And sends it into the transport_input() (same one called by >>> ip_input). >>> >>> This then makes a clean and easy way to have "tunneled UDP" >>> transport >> protocols >>> work in kernel. The input side looks the same. Output is pretty >>> easy.. >> easy to >>> drop a UDP header in out output... >>> >>> >>> Netgraph would have to be watching every UDP packet always.. >>> >> >> just those that go to that ksocket. we hook on at the socketbuf >> point. > > that's right. basically, use ng_ksocket(4). that would be your tunnel > (outer) endpoint which you would bind to udp protocol, given address > and port. now everything that remote tunnel (outer) endpoint will send > via udp (payload) will end up in ng_ksocket(4) node and will be sent > out to ksocket's hook. you can connect whatever you want to that > hook. either move payload back into userspace, or use another ng node, > or just inject the data directly into sctp/etc. input routine. reverse > path is the same. playload comes from the hook and gets sent out via > udp Ok, let me go read the ng_ man.. I would not use the reverse path.. the ability to send encap'd udp packets is already in sctp.. after all all you are doing is dropping an extra header on it.. SCTP (and other transports) will want to control the way the IP header looks.. at least if they are multi-homed... so I don't think one would want to do output via ng.. just getting the data in is all thats missing in FreeBSD.. As long as netgraph is in generic this may work.. R > > >>> >>> seems to me easier to bind a kernel level socket with some option >>> to call an input function.... >>> >>> R >>> >>> >>> >>> >>>> >>>> >>>> >>>>> That also reminds me.. who owns the ipfw code.. we actually >>>>> have SCTP nat support that Jason But has done that we need to >>>>> get in... >>>>> I would be more than glad to shepherd this in if the owner >>>>> of the code does not have the time... >>>>> R > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From maksim.yevmenkin at gmail.com Wed Nov 19 13:40:39 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Nov 19 13:40:46 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <49247BEE.4040201@elischer.org> References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> Message-ID: On 11/19/08, Julian Elischer wrote: > Randall Stewart wrote: > > > > > On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: > > > > > > > Randall Stewart wrote: > > > > > > > Dear All: > > > > I have been contemplating UDP and tunneling. One of the > > > > things that is a nice feature in MacOS is the ability of > > > > a kernel module/extension to open a kernel level socket > > > > and have the mbuf chain that arrives for that port be passed > > > > in via a function. > > > > > > > > > > define "kernel level" and "mbuf chain that arrives [...] passed in via a > function" > > > > > > > > > > > > > > > > We use this in our MacOS version of the SCTP stack to do the > > > > UDP de-tunneling of SCTP packets. This is becoming a more and > > > > more common thing i.e. having transport protocols like SCTP and DCCP > > > > be tunneled over UDP to get by NAT's.... this actually sucks that > > > > this is necessary .. but it is what it is.... > > > > > > > > > > I do that using netgraph.. > > > set a point ot point ng_iface and hook the other end to > > > a netgraph ksocket which is bound/connaected where you want. > > > > > > "just works" > > > > > > > > > > So, I am contemplating adding a similar sort of feature... basically > > > > provide an interface in UDP that a consumer (such as SCTP or DCCP) > could > > > > use to "bind" a port and get UDP packets directly. > > > > What do you all think of the idea? > > > > > > > > > > Well netgraph allows you to do it already > > > > > > > > > Not sure what netgraph does... what is wanted is this in comes > > > > > > +-----+ > > | IP | > > +-----+ > > | UDP | > > +-----+ > > | Oth | > > | tra | > > | por | > > | t h | > > | ead | > > | er | > > | and | > > | dat | > > | a. | > > +-----+ > > > > > Othtra port header and data.? i think it means: "other transport port header and data", that is take a complete sctp/etc. datagram and stuff in inside udp datagram as payload. > > > > > > > Ideally it runs into UDP via ip_input() > > and comes down to where it would append() to the socket. > > > > At this point, netgraph grabs it and passes the mbufs wherever you tell it > to pass them. > > > > > > What you want in this case is the whole mbuf chain to be sent > > to the transport_udp_input(m, offset) function > > > > cd /sys > root@trafmon1:grep transport_udp_input net*/* > root@trafmon1:grep transport_udp_input net*/*/* > > > > > > > > This changes the above to > > +-----+ > > | IP | > > +-----+ > > | Oth | > > | tra | > > | por | > > | t h | > > | ead | > > | er | > > | and | > > | dat | > > | a. | > > +-----+ > > > > > where does the new IP header information come from? > > > > > > And sends it into the transport_input() (same one called by ip_input). > > > > This then makes a clean and easy way to have "tunneled UDP" transport > protocols > > work in kernel. The input side looks the same. Output is pretty easy.. > easy to > > drop a UDP header in out output... > > > > > > Netgraph would have to be watching every UDP packet always.. > > > > just those that go to that ksocket. we hook on at the socketbuf point. that's right. basically, use ng_ksocket(4). that would be your tunnel (outer) endpoint which you would bind to udp protocol, given address and port. now everything that remote tunnel (outer) endpoint will send via udp (payload) will end up in ng_ksocket(4) node and will be sent out to ksocket's hook. you can connect whatever you want to that hook. either move payload back into userspace, or use another ng node, or just inject the data directly into sctp/etc. input routine. reverse path is the same. playload comes from the hook and gets sent out via udp > > > > seems to me easier to bind a kernel level socket with some option > > to call an input function.... > > > > R > > > > > > > > > > > > > > > > > > > > > That also reminds me.. who owns the ipfw code.. we actually > > > > have SCTP nat support that Jason But has done that we need to > > > > get in... > > > > I would be more than glad to shepherd this in if the owner > > > > of the code does not have the time... > > > > R From marius at alchemy.franken.de Wed Nov 19 13:50:04 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Wed Nov 19 13:50:11 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811192150.mAJLo30P000510@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= Cc: bug-followup@FreeBSD.org Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Wed, 19 Nov 2008 22:42:31 +0100 On Wed, Nov 19, 2008 at 02:27:43AM +0100, Aurlien Mr wrote: > Concerning the problem described by davidch@ , my chip is reported as a B5 > revision (01050000), so it might not be the case here. > You're right, the M/B doesn't support PCI-X at all. As detailed on the > manual, the NB chipset (AMD762) provides support for 2x66 MHz 64-bit PCI > 2.2 masters, and the SB chipset (AMD768) provides a secondary PCI 2.2 > bridge 33MHz. > I tried the patch but it didn't solve the problem, whilst the BGE_FLAG_PCIX > was no longer in the flags, which seems much more correct anyway. At the > end of the initialization values are these, as planned : > > bge_flags = 0x0010180F (0x10100F | BGE_FLAG_64BIT) . > BGE_PCI_PCISTATE is unchanged > > Note I forgot to mention the BGE_FLAG_RXALIGN_BUG (100000) and BGE_FLAG_TBI > (1) last time, as I tested before reset of the chip where these flags are > set. Okay. Have you tried the workaround described by davidch@ anyway? If that also doesn't make a difference I'm unfortunately out of ideas regarding your corruption problmem. Marius From maksim.yevmenkin at gmail.com Wed Nov 19 13:51:25 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Nov 19 13:51:32 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <0252A647-464E-46A7-94E9-A0639083B5AE@lakerest.net> References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> <0252A647-464E-46A7-94E9-A0639083B5AE@lakerest.net> Message-ID: [...] > > > just those that go to that ksocket. we hook on at the socketbuf point. > > > > > > > that's right. basically, use ng_ksocket(4). that would be your tunnel > > (outer) endpoint which you would bind to udp protocol, given address > > and port. now everything that remote tunnel (outer) endpoint will send > > via udp (payload) will end up in ng_ksocket(4) node and will be sent > > out to ksocket's hook. you can connect whatever you want to that > > hook. either move payload back into userspace, or use another ng node, > > or just inject the data directly into sctp/etc. input routine. reverse > > path is the same. playload comes from the hook and gets sent out via > > udp > > > > > Ok, let me go read the ng_ man.. > > I would not use the reverse path.. the ability to send > encap'd udp packets is already in sctp.. after all all you > are doing is dropping an extra header on it.. SCTP (and other > transports) will want to control the way the IP header looks.. at > least if they are multi-homed... so I don't think one would > want to do output via ng.. just getting the data in is all > thats missing in FreeBSD.. in this case its even easier. if you do not need reverse path, then all you need to do is to write a very small ng_ node that would 1) connect to the ng_ksocket(4) node's hook; and 2) inject received data into sctp/etc. input path so, you graph would look like [ng_ksocket] <- inet/dgram/udp -> [ng_sctp_injector] you might need an injector node do decouple netgraph from the rest of the sctp/etc. stack. alternatively, you may wish to provide netgraph hooks into sctp/etc. stack. > As long as netgraph is in generic this may work.. it is generic to some degree. if inner protocol (i.e. sctp etc.) is not aware of netgraph, then you will need to write an injector node specific to each inner protocol (basically that knows how to inject data into the stack). since injector node is simple, you could teach it to deal with multiple inner transports. for example, you could have an injector node that have multiple input hooks, one for each supported inner transport, named "sctp", etc. the idea would be that everything received from "sctp" hook will be injected into sctp stack, etc. then you could have only one injector node that could deal with multiple ng_ksockets for different inner transports. thanks, max From julian at elischer.org Wed Nov 19 14:33:41 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Nov 19 14:33:47 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <905A5B58-54D2-4B79-A1B4-44C6D5136691@lakerest.net> References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> <905A5B58-54D2-4B79-A1B4-44C6D5136691@lakerest.net> Message-ID: <49249443.8050707@elischer.org> Randall Stewart wrote: > > On Nov 19, 2008, at 3:49 PM, Julian Elischer wrote: > >> Randall Stewart wrote: >>> On Nov 19, 2008, at 1:45 PM, Julian Elischer wrote: >>>> Randall Stewart wrote: >>>>> Dear All: >>>>> I have been contemplating UDP and tunneling. One of the >>>>> things that is a nice feature in MacOS is the ability of >>>>> a kernel module/extension to open a kernel level socket >>>>> and have the mbuf chain that arrives for that port be passed >>>>> in via a function. >>>> >>>> define "kernel level" and "mbuf chain that arrives [...] passed in >>>> via a function" >>>> >>>> >>>> >>>>> We use this in our MacOS version of the SCTP stack to do the >>>>> UDP de-tunneling of SCTP packets. This is becoming a more and >>>>> more common thing i.e. having transport protocols like SCTP and DCCP >>>>> be tunneled over UDP to get by NAT's.... this actually sucks that >>>>> this is necessary .. but it is what it is.... >>>> >>>> I do that using netgraph.. >>>> set a point ot point ng_iface and hook the other end to >>>> a netgraph ksocket which is bound/connaected where you want. >>>> >>>> "just works" >>>> >>>>> So, I am contemplating adding a similar sort of feature... basically >>>>> provide an interface in UDP that a consumer (such as SCTP or DCCP) >>>>> could >>>>> use to "bind" a port and get UDP packets directly. >>>>> What do you all think of the idea? >>>> >>>> Well netgraph allows you to do it already >>> Not sure what netgraph does... what is wanted is this in comes >>> +-----+ >>> | IP | >>> +-----+ >>> | UDP | >>> +-----+ >>> | Oth | >>> | tra | >>> | por | >>> | t h | >>> | ead | >>> | er | >>> | and | >>> | dat | >>> | a. | >>> +-----+ >> >> >> Othtra port header and data.? > > Of course... full transport layer header.. for sctp > its > > port port > vtag > checksum > first-chunk header > > etc.. > > >> >> >> >>> Ideally it runs into UDP via ip_input() >>> and comes down to where it would append() to the socket. >> >> At this point, netgraph grabs it and passes the mbufs wherever you >> tell it to pass them. > > Sounds interesting... two questions: > > 1) And how do we configure netgraph to do this? (pointers to doco's is > fine) > 2) Is netgraph in the GENERIC... I would like to see this work out of > the box.. yes, well I don't know what is loaded by default. > >> >> >>> What you want in this case is the whole mbuf chain to be sent >>> to the transport_udp_input(m, offset) function >> >> cd /sys >> root@trafmon1:grep transport_udp_input net*/* >> root@trafmon1:grep transport_udp_input net*/*/* >> >> >> >>> This changes the above to >>> +-----+ >>> | IP | >>> +-----+ >>> | Oth | >>> | tra | >>> | por | >>> | t h | >>> | ead | >>> | er | >>> | and | >>> | dat | >>> | a. | >>> +-----+ >> >> >> where does the new IP header information come from? > > Its not new, its the same ip header.. > > Its just you go into the mbuf chain and take out > the udp header... well you can't do that at the socket buffer becasue you've discarded the IP header. It may not even be in the mbufs you have. (though it's unlikely). After you've processed the UDP part the IP part is gone so you'd need to intercept the packet way earlier and then do your own UDP processing, (or maybe attach the IP header onto it with a tag). > > > >> >> >>> And sends it into the transport_input() (same one called by ip_input). >>> This then makes a clean and easy way to have "tunneled UDP" transport >>> protocols >>> work in kernel. The input side looks the same. Output is pretty >>> easy.. easy to >>> drop a UDP header in out output... >>> Netgraph would have to be watching every UDP packet always.. >> >> just those that go to that ksocket. we hook on at the socketbuf point. > > Hmm sounds plausible.. what you are suggesting is UDP header injection, between the existing IP header and existing SCTP header, then on reception, stripping it out. We'd have to do a bit of hacking to do that.. it's kind of 'unusual' in-kernel UDP encapsulation is easy but we don't have header injection.. I can see how one would do it but I was wrong before, you'd need to do some work. > > R > >> From andrew at modulus.org Wed Nov 19 14:39:25 2008 From: andrew at modulus.org (Andrew Snow) Date: Wed Nov 19 14:39:32 2008 Subject: Thinking about UDP and tunneling In-Reply-To: References: Message-ID: <49249506.2050706@modulus.org> The openvpn port tunnels IP over UDP very efficiently and with optional compression and encryption. - Andrew From bzeeb-lists at lists.zabbadoz.net Wed Nov 19 14:55:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Nov 19 14:55:15 2008 Subject: Thinking about UDP and tunneling In-Reply-To: References: <49245EE3.2000700@elischer.org> Message-ID: <20081119224027.U61259@maildrop.int.zabbadoz.net> On Wed, 19 Nov 2008, Randall Stewart wrote: Hi, [UDP tunneling of "foo"] I am not following this thread at all but the transport_udp_input(mbuf, offset) jumped into my eyes. > Not sure what netgraph does... what is wanted is this in comes > > +-----+ > | IP | > +-----+ > | UDP | > +-----+ ... > +-----+ > > Ideally it runs into UDP via ip_input() > and comes down to where it would append() to the socket. > > What you want in this case is the whole mbuf chain to be sent > to the transport_udp_input(m, offset) function > > This changes the above to > +-----+ > | IP | > +-----+ ... > +-----+ > > And sends it into the transport_input() (same one called by ip_input). > > This then makes a clean and easy way to have "tunneled UDP" transport > protocols > work in kernel. The input side looks the same. Output is pretty easy.. easy > to > drop a UDP header in out output... So I see things like this spring here and there and people start introducing more hacks on top of hacks on top of hacks these days to cicumvent dumb NAT setups. Right. No. So why the heck not use one of the dozend possibilities that you can find on rfc-editor.org to encapsulate whatever you want into UDP in a well defined protocol way rather than introducing yet another UDP-encap for yet another protocol? Stuffing X into UDP means having a policy to identify the next ULP possibly by port combinations, identify out of sequence data, identify randomly forged pakets insert into your stream, fragemation, \ldots \ldots \ldots possibly handshake all this first by the means of the ULP, \ldots \ldots \ldots reinventing the wheel over and over again. Ignore my 0.02CAD. /bz -- Bjoern A. Zeeb If you have a hammer, everything looks like a nail. From hartmut.brandt at dlr.de Wed Nov 19 15:05:01 2008 From: hartmut.brandt at dlr.de (Harti Brandt) Date: Wed Nov 19 15:05:09 2008 Subject: TCP and syncache question In-Reply-To: <4921F2CD.503@freebsd.org> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> Message-ID: <20081119234543.A90462@beagle.kn.op.dlr.de> Hi Andre, On Mon, 17 Nov 2008, Andre Oppermann wrote: AO>This is a bit more complicated because of interactions with tcp_input() AO>where syncache_expand() is called from. AO> AO>The old code (as of December 2002) behaved slightly different. It would AO>not remove the syncache entry when (SND.UNA == SEG.ACK) but send a RST. AO>The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't done at AO>all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) succeeded. AO>This gave way to the "LAND" DoS attack which was mostly fixed with a test AO>for (RCV.IRS < SEG.SEQ). AO> AO>See the attached patch for fixed version of syncache_expand(). This patch AO>is untested though. My development machine is currently down. Harti, Rui AO>and Bjoern, please have a look at the patch and review it. Some small problems: AO>--- tcp_input.c.1.390 Mon Nov 17 21:33:25 2008 AO>+++ tcp_input.c.1.390.mod Mon Nov 17 21:35:22 2008 AO>@@ -642,10 +642,13 @@ findpcb: AO> if (!syncache_expand(&inc, &to, th, &so, m)) { AO> /* AO> * No syncache entry or ACK was not AO>- * for our SYN/ACK. Send a RST. AO>+ * for our SYN/ACK. Send a RST or AO>+ * an ACK for re-synchronization. AO> * NB: syncache did its own logging AO> * of the failure cause. AO> */ AO>+ if (so == 1) Need a cast here: if (so == (struct socket *)1) AO>+ goto dropunlock; AO> rstreason = BANDLIM_RST_OPENPORT; AO> goto dropwithreset; AO> } AO>--- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008 AO>+++ tcp_syncache.c.1.160.mod Mon Nov 17 23:35:39 2008 AO>@@ -817,59 +817,47 @@ syncache_expand(struct in_conninfo *inc, AO> INP_INFO_WLOCK_ASSERT(&V_tcbinfo); AO> KASSERT((th->th_flags & (TH_RST|TH_ACK|TH_SYN)) == TH_ACK, AO> ("%s: can handle only ACK", __func__)); AO>+ *lsop = NULL; This leads to a panic on sonewconn. *lsop points to the listening socket when the function is entered and this socket is needed below in syncache_socket(). I just removed this line. AO> AO> sc = syncache_lookup(inc, &sch); /* returns locked sch */ AO> SCH_LOCK_ASSERT(sch); AO> if (sc == NULL) { AO> /* AO> * There is no syncache entry, so see if this ACK is AO>- * a returning syncookie. To do this, first: AO>- * A. See if this socket has had a syncache entry dropped in AO>- * the past. We don't want to accept a bogus syncookie AO>- * if we've never received a SYN. AO>- * B. check that the syncookie is valid. If it is, then AO>- * cobble up a fake syncache entry, and return. AO>+ * a returning syncookie. If the syncookie is valid, AO>+ * cobble up a fake syncache entry and create a socket. AO>+ * AO>+ * NB: Syncache head is locked for the syncookie access. AO> */ AO> if (!tcp_syncookies) { AO>- SCH_UNLOCK(sch); AO> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) AO> log(LOG_DEBUG, "%s; %s: Spurious ACK, " AO> "segment rejected (syncookies disabled)\n", AO> s, __func__); AO>- goto failed; AO>+ goto sendrst; AO> } AO> bzero(&scs, sizeof(scs)); AO> sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop); AO>- SCH_UNLOCK(sch); AO> if (sc == NULL) { AO> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) AO> log(LOG_DEBUG, "%s; %s: Segment failed " AO> "SYNCOOKIE authentication, segment rejected " AO> "(probably spoofed)\n", s, __func__); AO>- goto failed; AO>+ goto sendrst; AO> } AO>- } else { AO>- /* Pull out the entry to unlock the bucket row. */ AO>- TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); AO>- sch->sch_length--; AO>- V_tcp_syncache.cache_count--; AO>- SCH_UNLOCK(sch); AO>+ goto expand; /* fully validated through syncookie */ AO> } AO>+ SCH_LOCK_ASSERT(sch); AO> AO> /* AO> * Segment validation: AO>- * ACK must match our initial sequence number + 1 (the SYN|ACK). AO>- */ AO>- if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { AO>- if ((s = tcp_log_addrs(inc, th, NULL, NULL))) AO>- log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " AO>- "rejected\n", s, __func__, th->th_ack, sc->sc_iss); AO>- goto failed; AO>- } AO>- AO>- /* AO>+ * AO> * The SEQ must fall in the window starting at the received AO> * initial receive sequence number + 1 (the SYN). AO>+ * If not the segment may be from an earlier connection. We send AO>+ * an ACK to re-synchronize the connection and keep the syncache AO>+ * entry without ajusting its timers. AO>+ * See RFC793 page 69, first check sequence number [SYN_RECEIVED]. AO> */ AO> if ((SEQ_LEQ(th->th_seq, sc->sc_irs) || AO> SEQ_GT(th->th_seq, sc->sc_irs + sc->sc_wnd)) && AO>@@ -877,14 +865,41 @@ syncache_expand(struct in_conninfo *inc, AO> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) AO> log(LOG_DEBUG, "%s; %s: SEQ %u != IRS+1 %u, segment " AO> "rejected\n", s, __func__, th->th_seq, sc->sc_irs); AO>- goto failed; AO>+ (void) syncache_respond(sc); AO>+ *lsop = 1; /* prevent RST */ Need another cast here: *lsop = (struct socket *)1. [snip] I've re-run my test scripts and they seem to indicate, that the socket is now kept in the correct state when the incoming segment had an incorrect ack. I could no yet run the tests for an incorrect seqno, though. This is because there is an interesting problem in RFC793 (and MIL-STD-1778): the RFC states on page 36 a general rule that a 'reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection.' I would say, that a segment carrying a sequence number at irs (when without SYN) and below irs (in any case) cannot belong to the current connection - those sequence numbers just don't exist for the connection. On the other hand p.69 says that we must send an ACK. If this were an ITU-T standard, things would be clear, because the prosa description would be normative, not the algorithm. I've tried to follow the classical BSD code in Stevens and it seems that before syncaches and stuff, an ACK was sent for a bad sequence number. So I'll change my tests (probably tomorrow in the evening) and check that the patch is correct for this case too. At a first glance a nice SYN+ACK came out... harti From bms at incunabulum.net Wed Nov 19 15:56:45 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Nov 19 15:56:52 2008 Subject: tokenring users? In-Reply-To: <49246C12.8080201@ironport.com> References: <49233959.9040903@ironport.com> <4923D7C0.7050301@freebsd.org> <4923DB2D.2080702@ironport.com> <20081119123600.E30755@claw.omgcats.com> <49246C12.8080201@ironport.com> Message-ID: <4924A7B6.9080507@incunabulum.net> Julian Elischer wrote: > my only worry is FDDI support... > 1/ do we have any There's like one driver left, and I don't think it even builds. > 2/ if so, does it use any of the tokenring support? I don;t really > know much > about FDDI. Wouldn't want to remove anything still in use by something > else. > It doesn't use "canonical MAC address format", if that's what you mean. Let's just kill it and get on with our lives... From cole at opteqint.net Thu Nov 20 02:25:56 2008 From: cole at opteqint.net (Cole) Date: Thu Nov 20 02:26:02 2008 Subject: FreeBSD Bridge and ARP question/strangeness Message-ID: <002f01c94af4$ecbced90$c636c8b0$@net> Hi. I have been playing with FreeBSD bridging in 7.0-Release. And was just testing some things to see exactly how it worked and try a few things out. I know that this isn't how the bridge is meant to be setup, but now im just curious as to why the following is happening. I have a box with a few interfaces, and i had setup rl0 with an ip address and it could communicate/ping everything on the network fine, all the rest of the other interfaces are unplugged and have no ip's assigned. Now if i go ahead and create a bridge interface and then just add that single interface with the ip assigned to it to the bridge, without assigning a new ip to the bridge, i get some strange things happening. Every box on the network not running FreeBSD is still able to ping and receive a reply from the box on the ip it was using on the interface. However, no FreeBSD box is now able to ping the box at all. In the arp listing, it shows any of the FreeBSD boxes that are trying to ping it as "(incomplete)". But for every other box that isn't FreeBSD it gets a full arp listing and all those boxes are still able to communicate with the box fine. So i was just wondering if theres a reason for this, or if anyone has any idea or clues why this might be happening. If you want i can provide whatever dumps you would need or anything like that. Regards /Cole From andre at freebsd.org Thu Nov 20 02:59:22 2008 From: andre at freebsd.org (Andre Oppermann) Date: Thu Nov 20 02:59:30 2008 Subject: TCP and syncache question In-Reply-To: <403932D0-8B62-4C95-8076-A185AC1C69E7@freebsd.org> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> <403932D0-8B62-4C95-8076-A185AC1C69E7@freebsd.org> Message-ID: <4925430A.9050602@freebsd.org> Rui Paulo wrote: > On 17 Nov 2008, at 22:40, Andre Oppermann wrote: >> This is a bit more complicated because of interactions with tcp_input() >> where syncache_expand() is called from. >> >> The old code (as of December 2002) behaved slightly different. It would >> not remove the syncache entry when (SND.UNA == SEG.ACK) but send a RST. >> The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't done at >> all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) >> succeeded. >> This gave way to the "LAND" DoS attack which was mostly fixed with a test >> for (RCV.IRS < SEG.SEQ). >> >> See the attached patch for fixed version of syncache_expand(). This >> patch >> is untested though. My development machine is currently down. Harti, >> Rui >> and Bjoern, please have a look at the patch and review it. >> >> --Andre >> >> --- tcp_input.c.1.390 Mon Nov 17 21:33:25 2008 >> +++ tcp_input.c.1.390.mod Mon Nov 17 21:35:22 2008 >> @@ -642,10 +642,13 @@ findpcb: >> if (!syncache_expand(&inc, &to, th, &so, m)) { >> /* >> * No syncache entry or ACK was not >> - * for our SYN/ACK. Send a RST. >> + * for our SYN/ACK. Send a RST or >> + * an ACK for re-synchronization. >> * NB: syncache did its own logging >> * of the failure cause. >> */ >> + if (so == 1) >> + goto dropunlock; >> rstreason = BANDLIM_RST_OPENPORT; >> goto dropwithreset; >> } >> --- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008 >> +++ tcp_syncache.c.1.160.mod Mon Nov 17 23:35:39 2008 >> @@ -817,59 +817,47 @@ syncache_expand(struct in_conninfo *inc, >> INP_INFO_WLOCK_ASSERT(&V_tcbinfo); >> KASSERT((th->th_flags & (TH_RST|TH_ACK|TH_SYN)) == TH_ACK, >> ("%s: can handle only ACK", __func__)); >> + *lsop = NULL; >> >> sc = syncache_lookup(inc, &sch); /* returns locked sch */ >> SCH_LOCK_ASSERT(sch); >> if (sc == NULL) { >> /* >> * There is no syncache entry, so see if this ACK is >> - * a returning syncookie. To do this, first: >> - * A. See if this socket has had a syncache entry dropped in >> - * the past. We don't want to accept a bogus syncookie >> - * if we've never received a SYN. >> - * B. check that the syncookie is valid. If it is, then >> - * cobble up a fake syncache entry, and return. >> + * a returning syncookie. If the syncookie is valid, >> + * cobble up a fake syncache entry and create a socket. >> + * >> + * NB: Syncache head is locked for the syncookie access. >> */ >> if (!tcp_syncookies) { >> - SCH_UNLOCK(sch); >> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> log(LOG_DEBUG, "%s; %s: Spurious ACK, " >> "segment rejected (syncookies disabled)\n", >> s, __func__); >> - goto failed; >> + goto sendrst; >> } >> bzero(&scs, sizeof(scs)); >> sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop); >> - SCH_UNLOCK(sch); >> if (sc == NULL) { >> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> log(LOG_DEBUG, "%s; %s: Segment failed " >> "SYNCOOKIE authentication, segment rejected " >> "(probably spoofed)\n", s, __func__); >> - goto failed; >> + goto sendrst; >> } >> - } else { >> - /* Pull out the entry to unlock the bucket row. */ >> - TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); >> - sch->sch_length--; >> - V_tcp_syncache.cache_count--; >> - SCH_UNLOCK(sch); >> + goto expand; /* fully validated through syncookie */ >> } >> + SCH_LOCK_ASSERT(sch); > > Why do you need this assert? Removed. Was from an earlier iteration with different locking and gotos. >> /* >> * Segment validation: >> - * ACK must match our initial sequence number + 1 (the SYN|ACK). >> - */ >> - if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { >> - if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> - log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " >> - "rejected\n", s, __func__, th->th_ack, sc->sc_iss); >> - goto failed; >> - } >> - >> - /* >> + * >> * The SEQ must fall in the window starting at the received >> * initial receive sequence number + 1 (the SYN). >> + * If not the segment may be from an earlier connection. We send >> + * an ACK to re-synchronize the connection and keep the syncache >> + * entry without ajusting its timers. >> + * See RFC793 page 69, first check sequence number [SYN_RECEIVED]. >> */ >> if ((SEQ_LEQ(th->th_seq, sc->sc_irs) || >> SEQ_GT(th->th_seq, sc->sc_irs + sc->sc_wnd)) && >> @@ -877,14 +865,41 @@ syncache_expand(struct in_conninfo *inc, >> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> log(LOG_DEBUG, "%s; %s: SEQ %u != IRS+1 %u, segment " >> "rejected\n", s, __func__, th->th_seq, sc->sc_irs); >> - goto failed; >> + (void) syncache_respond(sc); >> + *lsop = 1; /* prevent RST */ >> + goto sendrstkeep; >> } >> >> + /* >> + * ACK must match our initial sequence number + 1 (the SYN|ACK). >> + * If not the segment may be from an earlier connection. We send >> + * a RST but keep the syncache entry without ajusting its timers. >> + * See RFC793 page 72, fifth check the ACK field, [SYN_RECEIVED]. >> + */ >> + if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { >> + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> + log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " >> + "rejected\n", s, __func__, th->th_ack, sc->sc_iss); >> + goto sendrstkeep; >> + } >> + >> + /* >> + * Remove the entry to unlock the bucket row. >> + * Tests from now on are fatal and remove the syncache entry. >> + */ >> + TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); >> + sch->sch_length--; >> + V_tcp_syncache.cache_count--; >> + >> + /* >> + * If timestamps were not negotiated they must not show up later. >> + * See RFC1312bis, section 1.3, second paragraph >> + */ >> if (!(sc->sc_flags & SCF_TIMESTAMP) && (to->to_flags & TOF_TS)) { >> if ((s = tcp_log_addrs(inc, th, NULL, NULL))) >> log(LOG_DEBUG, "%s; %s: Timestamp not expected, " >> "segment rejected\n", s, __func__); >> - goto failed; >> + goto sendrst; >> } >> /* >> * If timestamps were negotiated the reflected timestamp >> @@ -896,9 +911,11 @@ syncache_expand(struct in_conninfo *inc, >> log(LOG_DEBUG, "%s; %s: TSECR %u != TS %u, " >> "segment rejected\n", >> s, __func__, to->to_tsecr, sc->sc_ts); >> - goto failed; >> + goto sendrst; >> } >> >> +expand: >> + SCH_UNLOCK(sch); >> *lsop = syncache_socket(sc, *lsop, m); >> >> if (*lsop == NULL) >> @@ -906,16 +923,18 @@ syncache_expand(struct in_conninfo *inc, >> else >> V_tcpstat.tcps_sc_completed++; >> >> -/* how do we find the inp for the new socket? */ >> if (sc != &scs) >> syncache_free(sc); >> return (1); >> -failed: >> - if (sc != NULL && sc != &scs) >> + >> +sendrst: >> + if (sc != &scs) >> syncache_free(sc); >> +sendrstkeep: >> + SCH_LOCK_ASSERT(sch); >> + SCH_UNLOCK(sch); > > Why do we need an assert before an unlock? This is customary in at least the TCP code. A failed assert provides more and better diagnostics than a crash-and-burn failed unlock. >> if (s != NULL) >> free(s, M_TCPLOG); >> - *lsop = NULL; >> return (0); >> } >> > > This was probably out of scope: yep. Put it in while reading the code. >> @@ -1322,6 +1341,8 @@ syncache_respond(struct syncache *sc) >> * >> * 1) path_mtu_discovery is disabled >> * 2) the SCF_UNREACH flag has been set >> + * >> + * XXXAO: The route lookup comment doesn't make sense. >> */ >> if (V_path_mtu_discovery && ((sc->sc_flags & SCF_UNREACH) == 0)) >> ip->ip_off |= IP_DF; > > > > I won't be able to test this any time soon, so I can't really comment on > the rest, but it *looks* okay. -- Andre From ivoras at freebsd.org Thu Nov 20 03:52:41 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Nov 20 03:52:49 2008 Subject: FreeBSD Bridge and ARP question/strangeness In-Reply-To: <002f01c94af4$ecbced90$c636c8b0$@net> References: <002f01c94af4$ecbced90$c636c8b0$@net> Message-ID: Cole wrote: > Hi. > > I have been playing with FreeBSD bridging in 7.0-Release. And was just > testing some things to see exactly how it worked and try a few things out. I > know that this isn't how the bridge is meant to be setup, but now im just > curious as to why the following is happening. > > I have a box with a few interfaces, and i had setup rl0 with an ip address > and it could communicate/ping everything on the network fine, all the rest > of the other interfaces are unplugged and have no ip's assigned. Now if i go > ahead and create a bridge interface and then just add that single interface > with the ip assigned to it to the bridge, without assigning a new ip to the > bridge, i get some strange things happening. Every box on the network not > running FreeBSD is still able to ping and receive a reply from the box on > the ip it was using on the interface. However, no FreeBSD box is now able to > ping the box at all. In the arp listing, it shows any of the FreeBSD boxes > that are trying to ping it as "(incomplete)". But for every other box that > isn't FreeBSD it gets a full arp listing and all those boxes are still able > to communicate with the box fine. > > So i was just wondering if theres a reason for this, or if anyone has any > idea or clues why this might be happening. If you want i can provide > whatever dumps you would need or anything like that. Can you rule out ARP timeouts? E.g. maybe other boxes have longer ARP TTLs than FreeBSD boxes. It's happened to me once (it was a bug in the em driver). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081120/ed5b1237/signature.pgp From rea-fbsd at codelabs.ru Thu Nov 20 03:52:52 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Nov 20 03:52:59 2008 Subject: FreeBSD Bridge and ARP question/strangeness In-Reply-To: <002f01c94af4$ecbced90$c636c8b0$@net> References: <002f01c94af4$ecbced90$c636c8b0$@net> Message-ID: Cole, good day. Thu, Nov 20, 2008 at 11:46:42AM +0200, Cole wrote: > I have a box with a few interfaces, and i had setup rl0 with an ip address > and it could communicate/ping everything on the network fine, all the rest > of the other interfaces are unplugged and have no ip's assigned. Now if i go > ahead and create a bridge interface and then just add that single interface > with the ip assigned to it to the bridge, without assigning a new ip to the > bridge, i get some strange things happening. Every box on the network not > running FreeBSD is still able to ping and receive a reply from the box on > the ip it was using on the interface. However, no FreeBSD box is now able to > ping the box at all. In the arp listing, it shows any of the FreeBSD boxes > that are trying to ping it as "(incomplete)". But for every other box that > isn't FreeBSD it gets a full arp listing and all those boxes are still able > to communicate with the box fine. I think that the first thing to look at will be the tcpdump of the ARP traffic -- if your peers are seeing '(incomplete)' as the bridging host MAC, then it is good to check if ARP requests are received and are they replied to. 'tcpdump -lvvnetti rl0 arp' should produce the fine listing. And the output of 'ifconfig' and 'sysctl net.link.bridge' will be helpful too. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- 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/20081120/c3a04c88/attachment.pgp From andre at freebsd.org Thu Nov 20 04:51:38 2008 From: andre at freebsd.org (Andre Oppermann) Date: Thu Nov 20 04:51:44 2008 Subject: TCP and syncache question In-Reply-To: <20081119234543.A90462@beagle.kn.op.dlr.de> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> <20081119234543.A90462@beagle.kn.op.dlr.de> Message-ID: <49255D5B.5040303@freebsd.org> Harti Brandt wrote: > Hi Andre, > > On Mon, 17 Nov 2008, Andre Oppermann wrote: > > AO>This is a bit more complicated because of interactions with tcp_input() > AO>where syncache_expand() is called from. > AO> > AO>The old code (as of December 2002) behaved slightly different. It would > AO>not remove the syncache entry when (SND.UNA == SEG.ACK) but send a RST. > AO>The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't done at > AO>all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) succeeded. > AO>This gave way to the "LAND" DoS attack which was mostly fixed with a test > AO>for (RCV.IRS < SEG.SEQ). > AO> > AO>See the attached patch for fixed version of syncache_expand(). This patch > AO>is untested though. My development machine is currently down. Harti, Rui > AO>and Bjoern, please have a look at the patch and review it. > > Some small problems: ... > Need another cast here: *lsop = (struct socket *)1. Changed the logic to use a NULL *lsop to differentiate in tcp_input(). Much simpler. > [snip] > > I've re-run my test scripts and they seem to indicate, that the socket is > now kept in the correct state when the incoming segment had an incorrect > ack. I could no yet run the tests for an incorrect seqno, though. This is > because there is an interesting problem in RFC793 (and MIL-STD-1778): the RFC > states on page 36 a general rule that a 'reset (RST) must be sent whenever > a segment arrives which apparently is not intended for the current connection.' The full quote from page 36 is: "As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case." > I would say, that a segment carrying a sequence number at irs (when without SYN) > and below irs (in any case) cannot belong to the current connection - those > sequence numbers just don't exist for the connection. On the other hand p.69 > says that we must send an ACK. If this were an ITU-T standard, things > would be clear, because the prosa description would be normative, not the > algorithm. The more specific rule wins. Sending the "challenge" ACK is done under the assumption that the remote end will send a reset to our "challenge" ACK if such an connection doesn't exist there. > I've tried to follow the classical BSD code in Stevens and > it seems that before syncaches and stuff, an ACK was sent for a bad > sequence number. So I'll change my tests (probably tomorrow in the evening) > and check that the patch is correct for this case too. At a first glance > a nice SYN+ACK came out... An updated patch is attached. -- Andre -------------- next part -------------- --- tcp_input.c.1.390 Mon Nov 17 21:33:25 2008 +++ tcp_input.c.1.390.mod Thu Nov 20 08:25:36 2008 @@ -642,10 +642,13 @@ findpcb: if (!syncache_expand(&inc, &to, th, &so, m)) { /* * No syncache entry or ACK was not - * for our SYN/ACK. Send a RST. + * for our SYN/ACK. Send a RST or + * an ACK for re-synchronization. * NB: syncache did its own logging * of the failure cause. */ + if (so == NULL) + goto dropunlock; rstreason = BANDLIM_RST_OPENPORT; goto dropwithreset; } --- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008 +++ tcp_syncache.c.1.160.mod Thu Nov 20 12:13:26 2008 @@ -823,53 +823,39 @@ syncache_expand(struct in_conninfo *inc, if (sc == NULL) { /* * There is no syncache entry, so see if this ACK is - * a returning syncookie. To do this, first: - * A. See if this socket has had a syncache entry dropped in - * the past. We don't want to accept a bogus syncookie - * if we've never received a SYN. - * B. check that the syncookie is valid. If it is, then - * cobble up a fake syncache entry, and return. + * a returning syncookie. If the syncookie is valid, + * cobble up a fake syncache entry and create a socket. + * + * NB: Syncache head is locked for the syncookie access. */ if (!tcp_syncookies) { - SCH_UNLOCK(sch); if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Spurious ACK, " "segment rejected (syncookies disabled)\n", s, __func__); - goto failed; + goto sendrst; } bzero(&scs, sizeof(scs)); sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop); - SCH_UNLOCK(sch); if (sc == NULL) { if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Segment failed " "SYNCOOKIE authentication, segment rejected " "(probably spoofed)\n", s, __func__); - goto failed; + goto sendrst; } - } else { - /* Pull out the entry to unlock the bucket row. */ - TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); - sch->sch_length--; - V_tcp_syncache.cache_count--; - SCH_UNLOCK(sch); + goto expand; /* fully validated through syncookie */ } /* * Segment validation: - * ACK must match our initial sequence number + 1 (the SYN|ACK). - */ - if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { - if ((s = tcp_log_addrs(inc, th, NULL, NULL))) - log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " - "rejected\n", s, __func__, th->th_ack, sc->sc_iss); - goto failed; - } - - /* + * * The SEQ must fall in the window starting at the received * initial receive sequence number + 1 (the SYN). + * If not the segment may be from an earlier connection. + * We send an ACK to re-synchronize the connection and keep + * the syncache entry without ajusting its timers. + * See RFC793 page 69, first check sequence number [SYN_RECEIVED]. */ if ((SEQ_LEQ(th->th_seq, sc->sc_irs) || SEQ_GT(th->th_seq, sc->sc_irs + sc->sc_wnd)) && @@ -877,14 +863,41 @@ syncache_expand(struct in_conninfo *inc, if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: SEQ %u != IRS+1 %u, segment " "rejected\n", s, __func__, th->th_seq, sc->sc_irs); - goto failed; + (void) syncache_respond(sc); + *lsop = NULL; /* prevent RST */ + goto sendrstkeep; + } + + /* + * ACK must match our initial sequence number + 1 (the SYN|ACK). + * If not the segment may be from an earlier connection. We send + * a RST but keep the syncache entry without ajusting its timers. + * See RFC793 page 72, fifth check the ACK field, [SYN_RECEIVED]. + */ + if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) { + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) + log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment " + "rejected\n", s, __func__, th->th_ack, sc->sc_iss); + goto sendrstkeep; } + /* + * Remove the entry to unlock the bucket row. + * Tests from now on are fatal and remove the syncache entry. + */ + TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); + sch->sch_length--; + V_tcp_syncache.cache_count--; + + /* + * If timestamps were not negotiated they must not show up later. + * See RFC1312bis, section 1.3, second paragraph + */ if (!(sc->sc_flags & SCF_TIMESTAMP) && (to->to_flags & TOF_TS)) { if ((s = tcp_log_addrs(inc, th, NULL, NULL))) log(LOG_DEBUG, "%s; %s: Timestamp not expected, " "segment rejected\n", s, __func__); - goto failed; + goto sendrst; } /* * If timestamps were negotiated the reflected timestamp @@ -896,9 +909,11 @@ syncache_expand(struct in_conninfo *inc, log(LOG_DEBUG, "%s; %s: TSECR %u != TS %u, " "segment rejected\n", s, __func__, to->to_tsecr, sc->sc_ts); - goto failed; + goto sendrst; } +expand: + SCH_UNLOCK(sch); *lsop = syncache_socket(sc, *lsop, m); if (*lsop == NULL) @@ -906,16 +921,18 @@ syncache_expand(struct in_conninfo *inc, else V_tcpstat.tcps_sc_completed++; -/* how do we find the inp for the new socket? */ if (sc != &scs) syncache_free(sc); return (1); -failed: - if (sc != NULL && sc != &scs) + +sendrst: + if (sc != &scs) syncache_free(sc); +sendrstkeep: + SCH_LOCK_ASSERT(sch); + SCH_UNLOCK(sch); if (s != NULL) free(s, M_TCPLOG); - *lsop = NULL; return (0); } From dikshie at gmail.com Thu Nov 20 04:56:29 2008 From: dikshie at gmail.com (dikshie) Date: Thu Nov 20 04:56:37 2008 Subject: asm multicast ping 6.3 vs 7.1 Message-ID: <910e60e80811200428u41eef8d6sa78582889b620efb@mail.gmail.com> hi, i have strange situation here. in my 6.3 box: ------------------------------------- $ asmping ff38:20:2001:d30:: soi-mirror.unibraw.ai3.net asmping joined (S,G) = (*,ff38:20:2001:d30::4321:1234) pinging 2001:d30:111:2::4 from 2001:d30:101:1::10 unicast from 2001:d30:111:2::4, seq=1 dist=2 time=329.990 ms multicast from 2001:d30:111:2::4, seq=1 dist=2 time=334.344 ms unicast from 2001:d30:111:2::4, seq=2 dist=2 time=340.283 ms multicast from 2001:d30:111:2::4, seq=2 dist=2 time=341.357 ms unicast from 2001:d30:111:2::4, seq=3 dist=2 time=347.617 ms multicast from 2001:d30:111:2::4, seq=3 dist=2 time=347.627 ms ^C --- 2001:d30:111:2::4 statistics --- 3 packets transmitted, time 2726 ms unicast: 3 packets received, 0% packet loss rtt min/avg/max/std-dev = 329.990/339.296/347.617/7.261 ms multicast: 3 packets received, 0% packet loss since first mc packet (seq 1) recvd rtt min/avg/max/std-dev = 334.344/341.109/347.627/5.446 ms -------------------------------------- in my 7.1 box: -------------------------------------- $ asmping ff38:20:2001:d30:: soi-mirror.unibraw.ai3.net Failed to join multicast group: Protocol not available errno=42 -------------------------------------- both boxes has same ipv4 subnet and same ipv6 link. 7.1 box has options MROUTING 6.3 box does not has options MROUTING do i miss something here? best regards, -- -dikshie- From rrs at lakerest.net Thu Nov 20 05:00:17 2008 From: rrs at lakerest.net (Randall Stewart) Date: Thu Nov 20 05:00:23 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <49249443.8050707@elischer.org> References: <49245EE3.2000700@elischer.org> <49247BEE.4040201@elischer.org> <905A5B58-54D2-4B79-A1B4-44C6D5136691@lakerest.net> <49249443.8050707@elischer.org> Message-ID: <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote: >>> >> Its not new, its the same ip header.. >> Its just you go into the mbuf chain and take out >> the udp header... > > well you can't do that at the socket buffer becasue you've discarded > the IP header. It may not even be in the mbufs you have. (though it's > unlikely). After you've processed the UDP part the IP part is gone so > you'd need to intercept the packet way earlier and then do your > own UDP processing, (or maybe attach the IP header onto it with a > tag). > > One would definitely have to do some work in udp_input() not a lot from what I can tell... but it would take some work. Maybe good course is to use the socket(9) stuff, but add an option that can set a "by-pass function" if the socket is udp... right after you establish the INP the packet goes to, if the function is set, you engage the bypass... >>> >>> >>>> And sends it into the transport_input() (same one called by >>>> ip_input). >>>> This then makes a clean and easy way to have "tunneled UDP" >>>> transport protocols >>>> work in kernel. The input side looks the same. Output is pretty >>>> easy.. easy to >>>> drop a UDP header in out output... >>>> Netgraph would have to be watching every UDP packet always.. >>> >>> just those that go to that ksocket. we hook on at the socketbuf >>> point. >> Hmm sounds plausible.. > > what you are suggesting is UDP header injection, between the > existing IP header and existing SCTP header, then on reception, > stripping it out. > > > We'd have to do a bit of hacking to do that.. it's kind of 'unusual' You need to take a look at some of the activities in tsvwg and the transport area open area meeting in the IETF. Not counting Jonathan's Rosenburgs IAB presentation an IETF or two ago claiming that "all new transports must tunnel via UDP". This seems to be a more and more common theme in the IETF. Now I personally do not agree that new transports cannot be deployed without UDP tunneling.. however there will always be the need for this IMO.. since you will often have NAT's that don't know about the new transport "yet"... Jonathan (and others claims is that the "yet" is really a "never".. here I disagree). Having infrastructure so we can do UDP tunneling of a new transport easily is IMO a good idea. Netgraph, looks interesting.. but I am afraid is not in GENERIC.. so you end up with a solution that only sometimes works. What I am thinking is a clean way to have kernel sockets(9) extended a bit so that we can better support tunneling input... Let me chew on this a while and come up with a working solution ... using socket(9) as much as possible... I think a couple of tweaks will be needed.. but I think its quite feasible and will be a benefit for not just SCTP but also DCCP and some of the other transports on the horizon... R > > > in-kernel UDP encapsulation is easy but we don't have header > injection.. > > I can see how one would do it > but I was wrong before, you'd need to do some work. > >> R >>> > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From rrs at lakerest.net Thu Nov 20 05:06:47 2008 From: rrs at lakerest.net (Randall Stewart) Date: Thu Nov 20 05:06:54 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <20081119224027.U61259@maildrop.int.zabbadoz.net> References: <49245EE3.2000700@elischer.org> <20081119224027.U61259@maildrop.int.zabbadoz.net> Message-ID: <52CB7D7E-60BC-4F40-AE31-E1353B435409@lakerest.net> Bjoern: I am writing this email FROM the IETF. There are MANY drafts right now in the IETF that will SOON become RFC's on how to run transport foo over UDP. this seems to be a predominate thing now. IPv6 was not ready early thus we suffer nats.. and always will (see my previous response a few minutes ago to Julian)... If you would like I can go dig around in the drafts db and find a list for you of all the transports proposed UDP tunneling. All are pretty much the same, they reg a port.. and then just have the UDP header stripped off... I think this will become a common thing wanted I know its needed for both DCCP and SCTP now.. there are other transports coming behind that I am sure :-) R On Nov 19, 2008, at 5:50 PM, Bjoern A. Zeeb wrote: > On Wed, 19 Nov 2008, Randall Stewart wrote: > > Hi, > > [UDP tunneling of "foo"] > > I am not following this thread at all but the > transport_udp_input(mbuf, offset) > jumped into my eyes. > >> Not sure what netgraph does... what is wanted is this in comes >> >> +-----+ >> | IP | >> +-----+ >> | UDP | >> +-----+ > ... >> +-----+ >> >> Ideally it runs into UDP via ip_input() >> and comes down to where it would append() to the socket. >> >> What you want in this case is the whole mbuf chain to be sent >> to the transport_udp_input(m, offset) function >> >> This changes the above to >> +-----+ >> | IP | >> +-----+ > ... >> +-----+ >> >> And sends it into the transport_input() (same one called by >> ip_input). >> >> This then makes a clean and easy way to have "tunneled UDP" >> transport protocols >> work in kernel. The input side looks the same. Output is pretty >> easy.. easy to >> drop a UDP header in out output... > > > So I see things like this spring here and there and people start > introducing more hacks on top of hacks on top of hacks these days to > cicumvent dumb NAT setups. Right. No. > > So why the heck not use one of the dozend possibilities that you can > find on rfc-editor.org to encapsulate whatever you want into UDP in a > well defined protocol way rather than introducing yet another > UDP-encap for yet another protocol? > > Stuffing X into UDP means having a policy to identify the next ULP > possibly by port combinations, identify out of sequence data, identify > randomly forged pakets insert into your stream, fragemation, \ldots > \ldots \ldots possibly handshake all this first by the means of the > ULP, > \ldots \ldots \ldots reinventing the wheel over and over again. > > Ignore my 0.02CAD. > > /bz > > -- > Bjoern A. Zeeb > If you have a hammer, everything looks like a nail. > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From max at love2party.net Thu Nov 20 05:50:33 2008 From: max at love2party.net (Max Laier) Date: Thu Nov 20 05:50:54 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> Message-ID: <200811201450.30016.max@love2party.net> On Thursday 20 November 2008 14:00:11 Randall Stewart wrote: > On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote: > >> Its not new, its the same ip header.. > >> Its just you go into the mbuf chain and take out > >> the udp header... > > > > well you can't do that at the socket buffer becasue you've discarded > > the IP header. It may not even be in the mbufs you have. (though it's > > unlikely). After you've processed the UDP part the IP part is gone so > > you'd need to intercept the packet way earlier and then do your > > own UDP processing, (or maybe attach the IP header onto it with a > > tag). > > One would definitely have to do some work in udp_input() not a lot from > what I can tell... but it would take some work. > > Maybe good course is to use the socket(9) stuff, but add an option > that can set a "by-pass function" if the socket is udp... right > after you establish the INP the packet goes to, if the function is > set, you engage the bypass... This sounds reasonable. One would only have to replace calls to udp_append in udp_input with the by-pass function et voila. Should be clean enough. There might be some problems with holding the socket lock, though. For the record, I don't like all the UDP-tunneling madness either, but it seems that we are stuck with it ... so we should at least try to come up with a somewhat reasonable implementation for this hackery. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From cole at opteqint.net Thu Nov 20 05:54:23 2008 From: cole at opteqint.net (Cole) Date: Thu Nov 20 05:54:30 2008 Subject: FreeBSD Bridge and ARP question/strangeness In-Reply-To: References: <002f01c94af4$ecbced90$c636c8b0$@net> Message-ID: <00a901c94b17$7c81eb70$7585c250$@net> Hi. The 10.10.7.1 is the FreeBSD box with the rl0 interface that gets added to a bridge. The 10.0.0.6 box is the other FreeBSD box. If you would like the same tcpdumps for any other OS pinging this box i would be glad to supply. Heres the output from the tcpdump, this carries on as long as the ping from the freebsd box happens: 1227217832.867492 00:03:2d:0e:5b:69 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.0.0.6 tell 10.10.7.1 1227217832.867700 00:0c:f1:b6:ab:ca > 00:03:2d:0e:5b:69, ethertype ARP (0x0806), length 60: arp reply 10.0.0.6 is-at 00:0c:f1:b6:ab:ca 1227217833.868686 00:03:2d:0e:5b:69 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.0.0.6 tell 10.10.7.1 1227217833.868890 00:0c:f1:b6:ab:ca > 00:03:2d:0e:5b:69, ethertype ARP (0x0806), length 60: arp reply 10.0.0.6 is-at 00:0c:f1:b6:ab:ca 1227217834.869814 00:03:2d:0e:5b:69 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.0.0.6 tell 10.10.7.1 1227217834.869954 00:0c:f1:b6:ab:ca > 00:03:2d:0e:5b:69, ethertype ARP (0x0806), length 60: arp reply 10.0.0.6 is-at 00:0c:f1:b6:ab:ca 1227217835.871002 00:03:2d:0e:5b:69 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.0.0.6 tell 10.10.7.1 Heres the ifconfig for the box: rl0: flags=8943 metric 0 mtu 1500 options=8 ether 00:03:2d:0e:5b:69 inet 10.10.7.1 netmask 0xff000000 broadcast 10.255.255.255 media: Ethernet autoselect (100baseTX ) status: active rl1: flags=8802 metric 0 mtu 1500 options=8 ether 00:03:2d:0e:5b:68 media: Ethernet autoselect status: no carrier rl2: flags=8802 metric 0 mtu 1500 options=8 ether 00:03:2d:0e:5b:67 media: Ethernet autoselect status: no carrier rl3: flags=8843 metric 0 mtu 1500 options=8 ether 00:03:2d:0e:5b:66 media: Ethernet autoselect (none) status: no carrier pfsync0: flags=0<> metric 0 mtu 1460 syncpeer: 224.0.0.240 maxupd: 128 pflog0: flags=0<> metric 0 mtu 33204 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=8843 metric 0 mtu 1500 ether 00:03:2d:0e:5b:69 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: rl0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 200000 and the sysctl: net.link.bridge.ipfw: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 1 and heres the output from arp -na: ? (10.0.0.6) at (incomplete) on rl0 [ethernet] Regards /Cole -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Eygene Ryabinkin Sent: 20 November 2008 01:53 PM To: Cole Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD Bridge and ARP question/strangeness Cole, good day. Thu, Nov 20, 2008 at 11:46:42AM +0200, Cole wrote: > I have a box with a few interfaces, and i had setup rl0 with an ip > address and it could communicate/ping everything on the network fine, > all the rest of the other interfaces are unplugged and have no ip's > assigned. Now if i go ahead and create a bridge interface and then > just add that single interface with the ip assigned to it to the > bridge, without assigning a new ip to the bridge, i get some strange > things happening. Every box on the network not running FreeBSD is > still able to ping and receive a reply from the box on the ip it was > using on the interface. However, no FreeBSD box is now able to ping > the box at all. In the arp listing, it shows any of the FreeBSD boxes > that are trying to ping it as "(incomplete)". But for every other box > that isn't FreeBSD it gets a full arp listing and all those boxes are still able to communicate with the box fine. I think that the first thing to look at will be the tcpdump of the ARP traffic -- if your peers are seeing '(incomplete)' as the bridging host MAC, then it is good to check if ARP requests are received and are they replied to. 'tcpdump -lvvnetti rl0 arp' should produce the fine listing. And the output of 'ifconfig' and 'sysctl net.link.bridge' will be helpful too. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From bms at incunabulum.net Thu Nov 20 07:50:12 2008 From: bms at incunabulum.net (Bruce Simpson) Date: Thu Nov 20 07:50:19 2008 Subject: asm multicast ping 6.3 vs 7.1 In-Reply-To: <910e60e80811200428u41eef8d6sa78582889b620efb@mail.gmail.com> References: <910e60e80811200428u41eef8d6sa78582889b620efb@mail.gmail.com> Message-ID: <4925872E.1060401@incunabulum.net> dikshie wrote: > ... > both boxes has same ipv4 subnet and same ipv6 link. > 7.1 box has options MROUTING > 6.3 box does not has options MROUTING > Post ktrace output? Can you try building MROUTING as a module instead, load it in and see if you have the same result? From eugen at grosbein.pp.ru Thu Nov 20 08:47:56 2008 From: eugen at grosbein.pp.ru (Eugene Grosbein) Date: Thu Nov 20 08:48:03 2008 Subject: jail translates destination IP? Message-ID: <20081120161440.GA3537@grosbein.pp.ru> Hi! For some strange reason, RAW sockets (when allowed) and TCP beheave very differently in jail (7.1-PRERELEASE). In host's rc.conf: jail_enable="YES" jail_list="test" jail_devfs_enable="YES" jail_test_rootdir="/mnt/big/jail/test" jail_test_hostname="myname.ru" jail_test_ip="192.168.0.1" jail_test_interface="lo0" "/etc/rc.d/jail start" does all right and I may rlogin into jail. In host environment I run tcpdump -np -i lo0. Inside jail I ping 127.0.0.1, it succeedes and tcpdump shows that requests go from 192.168.0.1 to 127.0.0.1 really. But when I try to telnet 127.0.0.1 25 from jail, tcpdump shows that TCP SYN are sent to 192.168.0.1, so telnet fails. There is no NAT here. It it a bug? Eugene Grosbein From rrs at lakerest.net Thu Nov 20 09:37:53 2008 From: rrs at lakerest.net (Randall Stewart) Date: Thu Nov 20 09:38:00 2008 Subject: Thinking about UDP and tunneling In-Reply-To: <200811201450.30016.max@love2party.net> References: <49249443.8050707@elischer.org> <76CF7D15-251F-4E43-86BE-AD96F48AF123@lakerest.net> <200811201450.30016.max@love2party.net> Message-ID: On Nov 20, 2008, at 8:50 AM, Max Laier wrote: > On Thursday 20 November 2008 14:00:11 Randall Stewart wrote: >> On Nov 19, 2008, at 5:33 PM, Julian Elischer wrote: >>>> Its not new, its the same ip header.. >>>> Its just you go into the mbuf chain and take out >>>> the udp header... >>> >>> well you can't do that at the socket buffer becasue you've discarded >>> the IP header. It may not even be in the mbufs you have. (though >>> it's >>> unlikely). After you've processed the UDP part the IP part is gone >>> so >>> you'd need to intercept the packet way earlier and then do your >>> own UDP processing, (or maybe attach the IP header onto it with a >>> tag). >> >> One would definitely have to do some work in udp_input() not a lot >> from >> what I can tell... but it would take some work. >> >> Maybe good course is to use the socket(9) stuff, but add an option >> that can set a "by-pass function" if the socket is udp... right >> after you establish the INP the packet goes to, if the function is >> set, you engage the bypass... > > This sounds reasonable. One would only have to replace calls to > udp_append in > udp_input with the by-pass function et voila. Should be clean > enough. There > might be some problems with holding the socket lock, though. > > For the record, I don't like all the UDP-tunneling madness either, > but it > seems that we are stuck with it ... so we should at least try to > come up with > a somewhat reasonable implementation for this hackery. Max: This was along the lines of what I was thinking exactly.. one side note. I am told by my colleague in SCTP crime (Michael T?xen) that Apple has this functional by-pass interface. He has already got the UDP tunneling code working in the MAC version of our stack :-) I will start working on this when I get back from the IETF. I need to finish up the NAT support stuff (almost done) and then I will start looking at the locking issues that this may bring... R > > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From bzeeb-lists at lists.zabbadoz.net Thu Nov 20 10:42:02 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Nov 20 10:42:08 2008 Subject: jail translates destination IP? In-Reply-To: <20081120161440.GA3537@grosbein.pp.ru> References: <20081120161440.GA3537@grosbein.pp.ru> Message-ID: <20081120182035.H61259@maildrop.int.zabbadoz.net> On Thu, 20 Nov 2008, Eugene Grosbein wrote: Hi, freebsd-jail@ is a good place to ask jail questiosn as well. > For some strange reason, RAW sockets (when allowed) and TCP beheave > very differently in jail (7.1-PRERELEASE). In host's rc.conf: > > jail_enable="YES" > jail_list="test" > jail_devfs_enable="YES" > jail_test_rootdir="/mnt/big/jail/test" > jail_test_hostname="myname.ru" > jail_test_ip="192.168.0.1" > jail_test_interface="lo0" > > "/etc/rc.d/jail start" does all right and I may rlogin into jail. > > In host environment I run tcpdump -np -i lo0. > Inside jail I ping 127.0.0.1, it succeedes and tcpdump shows that requests > go from 192.168.0.1 to 127.0.0.1 really. But when I try to telnet 127.0.0.1 25 > from jail, tcpdump shows that TCP SYN are sent to 192.168.0.1, so telnet fails. > > There is no NAT here. It it a bug? What happens with TCP is the expected behaviour. I wonder more about the raw socket case and am not sure this is correct. jails try to "simulate" the non-existing loopback by re-writing the IPs to the jail-IP, which obviously has other implications. You should never be able to connect from inside the jail to the base systems 127.0.0.1 loopback IP. This is a known "feature" (limitation) of jails. Full network stack virtualization will no longer have that problem. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From linimon at FreeBSD.org Thu Nov 20 14:42:07 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Nov 20 14:42:13 2008 Subject: kern/129022: [ath] ath cannot connect using WEP Message-ID: <200811202242.mAKMg6o9064664@freefall.freebsd.org> Old Synopsis: ath cannot connect using WEP New Synopsis: [ath] ath cannot connect using WEP Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 20 22:41:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129022 From security at jim-liesl.org Thu Nov 20 19:58:18 2008 From: security at jim-liesl.org (security) Date: Thu Nov 20 19:58:25 2008 Subject: ipfw/dummynet question Message-ID: <492631D7.30909@jim-liesl.org> context is 7.1-beta2 I'm using a FreeBSD box as a router and IPFW/dummynet to simulate 3 WAN connections. The three networks are actually on the same lan, but have aliased ip's on the router's NIC (router on a stick). I've set up bi-directional pipes for each "net" that enforce various impairments. What I'm trying to do is have all traffic to or from "net-a" simulate a 30Mbit link, "net-b" a 20Mbit, and "net-c" a 10Mbit one. Traffic coming from elsewhere would not be touched until it was outbound for one of the 3 nets, and like wise, traffic coming from the 3 nets and going elsewhere would only be touched coming in. Traffic who's src and dst don't match at all would fall through. An example would be traffic from "net-a" going to "net-c" gets passed into the router like it's on a 30Mbit link, but heads out (after routing) like it's on a 10 Mbit link Question: Am I on the right path or have I made some stupid assumption(s)? I realize I have a few extra rules that could be optimized out, but this is probably good for the sake of readability. Another question, is each ip flow treated like it has it's own dedicated bw, or do all flows that match a pipe share the b/w ? thx jim (assume one_pass is set) ${fwcmd} add 10 skipto 100 ip from any to any in ${fwcmd} add 20 skipto 500 ip from any to any out ${fwcmd} add 100 pipe 1 ip from net-a to any ${fwcmd} add 200 pipe 2 ip from net-b to any ${fwcmd} add 300 pipe 3 ip from net-c to any ${fwcmd} add 400 skipto 65535 ip from any to any ${fwcmd} pipe 1 config bw 30Mbit/s ${fwcmd} pipe 2 config bw 20Mbit/s ${fwcmd} pipe 3 config bw 10Mbit/s ${fwcmd} add 500 pipe 4 ip from any to net-a ${fwcmd} add 600 pipe 5 ip from any to net-b ${fwcmd} add 700 pipe 6 ip from any to net-c ${fwcmd} pipe 4 config bw 30Mbit/s ${fwcmd} pipe 5 config bw 20Mbit/s ${fwcmd} pipe 6 config bw 10Mbit/s ${fwcmd} add 1000 skipto 65535 ip from any to any From hartmut.brandt at dlr.de Fri Nov 21 04:10:28 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Fri Nov 21 04:10:38 2008 Subject: TCP and syncache question In-Reply-To: <49255D5B.5040303@freebsd.org> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> <20081119234543.A90462@beagle.kn.op.dlr.de> <49255D5B.5040303@freebsd.org> Message-ID: <4926A520.9050400@dlr.de> Andre Oppermann wrote: > Harti Brandt wrote: >> Hi Andre, >> >> On Mon, 17 Nov 2008, Andre Oppermann wrote: >> >> AO>This is a bit more complicated because of interactions with >> tcp_input() >> AO>where syncache_expand() is called from. >> AO> >> AO>The old code (as of December 2002) behaved slightly different. It >> would >> AO>not remove the syncache entry when (SND.UNA == SEG.ACK) but send a >> RST. >> AO>The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't >> done at >> AO>all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) >> succeeded. >> AO>This gave way to the "LAND" DoS attack which was mostly fixed with >> a test >> AO>for (RCV.IRS < SEG.SEQ). >> AO> >> AO>See the attached patch for fixed version of syncache_expand(). >> This patch >> AO>is untested though. My development machine is currently down. >> Harti, Rui >> AO>and Bjoern, please have a look at the patch and review it. >> >> Some small problems: > ... >> Need another cast here: *lsop = (struct socket *)1. > > Changed the logic to use a NULL *lsop to differentiate in tcp_input(). > Much simpler Indeed. But now the code sends a SYN+ACK with seqno == iss which is contrary to p.69 which requires ACK only and seqno == snd_nxt == iss + 1 (in our case). On the other hand one could point to the example on p. 33 (fig. 9), although it is not entirely clear from the figure whether the SYN in line 2 actually moves TCP B to SYN-RECEIVED. In any case I checked both our pre-syncache code and OpenSolaris and both of them seem to send only the ACK (I did not try it, just read the code). > . > >> [snip] >> >> I've re-run my test scripts and they seem to indicate, that the >> socket is >> now kept in the correct state when the incoming segment had an incorrect >> ack. I could no yet run the tests for an incorrect seqno, though. >> This is >> because there is an interesting problem in RFC793 (and MIL-STD-1778): >> the RFC >> states on page 36 a general rule that a 'reset (RST) must be sent >> whenever >> a segment arrives which apparently is not intended for the current >> connection.' > > The full quote from page 36 is: "As a general rule, reset (RST) must > be sent > whenever a segment arrives which apparently is not intended for the > current > connection. A reset must not be sent if it is not clear that this is > the case." > >> I would say, that a segment carrying a sequence number at irs (when >> without SYN) >> and below irs (in any case) cannot belong to the current connection - >> those >> sequence numbers just don't exist for the connection. On the other >> hand p.69 >> says that we must send an ACK. If this were an ITU-T standard, things >> would be clear, because the prosa description would be normative, not >> the >> algorithm. > > The more specific rule wins. Sending the "challenge" ACK is done > under the > assumption that the remote end will send a reset to our "challenge" > ACK if > such an connection doesn't exist there. Well, at least in the last pre-syncache revision (tcp_input.c rev. 1.142) there is the sequence number check on line 1580, that was introduced in rev. 1.81 to prevent the "land" attack, that sends an RST when th_seq <= irs. Confusingly enough that test is still there (now at line 1610) but, as far as I can see never reached (because of syncache). It also is th_seq < irs now for some reasons. harti From hartmut.brandt at dlr.de Fri Nov 21 10:56:46 2008 From: hartmut.brandt at dlr.de (Hartmut Brandt) Date: Fri Nov 21 10:56:53 2008 Subject: TCP and syncache question In-Reply-To: <49255D5B.5040303@freebsd.org> References: <491F2C47.4050500@dlr.de> <0A4BB2F1-AC9F-4316-94E3-790E2D80F651@freebsd.org> <49201859.2080605@dlr.de> <4921B3C6.5020002@freebsd.org> <4921F2CD.503@freebsd.org> <20081119234543.A90462@beagle.kn.op.dlr.de> <49255D5B.5040303@freebsd.org> Message-ID: <4927045A.8020805@dlr.de> Andre Oppermann wrote: > Harti Brandt wrote: >> Hi Andre, >> >> On Mon, 17 Nov 2008, Andre Oppermann wrote: >> >> AO>This is a bit more complicated because of interactions with >> tcp_input() >> AO>where syncache_expand() is called from. >> AO> >> AO>The old code (as of December 2002) behaved slightly different. It >> would >> AO>not remove the syncache entry when (SND.UNA == SEG.ACK) but send a >> RST. >> AO>The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't >> done at >> AO>all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) >> succeeded. >> AO>This gave way to the "LAND" DoS attack which was mostly fixed with >> a test >> AO>for (RCV.IRS < SEG.SEQ). >> AO> >> AO>See the attached patch for fixed version of syncache_expand(). >> This patch >> AO>is untested though. My development machine is currently down. >> Harti, Rui >> AO>and Bjoern, please have a look at the patch and review it. >> >> Some small problems: > ... >> Need another cast here: *lsop = (struct socket *)1. > > Changed the logic to use a NULL *lsop to differentiate in tcp_input(). > Much simpler. Turns out there is a bug in the patch: after the call to syncache_lookup() at test sc == NULL is made and if sc == NULL and may goto sendrst: sendrst: if (sc != &scs) syncache_free(sc); Here syncache_free panics because of the NULL passed to it. I suppose both gotos under the if() should go to sendrstkeep instead. harti From remko at FreeBSD.org Sat Nov 22 05:31:31 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Sat Nov 22 05:31:43 2008 Subject: i386/128917: if_wpi and wpa+tkip causing kernel panic Message-ID: <200811221331.mAMDVVtU081287@freefall.freebsd.org> Synopsis: if_wpi and wpa+tkip causing kernel panic Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Nov 22 13:31:30 UTC 2008 Responsible-Changed-Why: This is a networking item http://www.freebsd.org/cgi/query-pr.cgi?pr=128917 From ticso at cicely7.cicely.de Sat Nov 22 14:42:22 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Sat Nov 22 14:42:30 2008 Subject: How to support an Ethernet PHY without ID registers? In-Reply-To: <48EBB3D6.600@incunabulum.net> References: <48EBB3D6.600@incunabulum.net> Message-ID: <20081122223046.GE40650@cicely7.cicely.de> On Tue, Oct 07, 2008 at 08:09:10PM +0100, Bruce M Simpson wrote: > Hi, > > I have been trying to get FreeBSD onto the Freecom FSG3 Storage Gateway. > It is an xScale based ARM system. > > Whilst the npe(4) driver appears to attach, the PHY does not. It is a > Realtel RTL8305SB switch chip in dual miibus mode. Unfortunately the > RTL8305SB does not have ID registers. The RTL8305SC does, but it's a > totally different chip. > > We do have a driver in the tree for the RTL8305SC, however these chips > are different enough for this to cause problems. > > Is there any way I could for example force ukphy(4) to attach? A late response... rlswitch is there for two reasons: forcing speed independed of port0 autoselect and setting VLAN (using hardcoded values though). I never worked with the SB, but read the datasheet a while back before I ordered the SC for my project. IIRC the SB has no VLAN support. Not sure about registers - maybe it really hasn't any or MDIO isn't connected with your hardware. I would suggest that you localy patch the rlswitch driver to always attach and be done with it. ukphy would try to read link parameters, which will fail and report wrong speed - MII speed of course is always 100/FDX. > Note: Because there are no ID registers, mii_phy_probe_gen() WILL NOT > work. It looks like I'd have to override this by hacking if_npe.c > itself. Can anyone clarify? This is possible as well, you can patch if_npe.c to return faked phy register values. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From linimon at FreeBSD.org Sat Nov 22 16:13:25 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Nov 22 16:13:37 2008 Subject: kern/129074: [ppp] [panic] kernel panic with pppoe_server Message-ID: <200811230013.mAN0DP7H062799@freefall.freebsd.org> Old Synopsis: kernel panic New Synopsis: [ppp] [panic] kernel panic with pppoe_server Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 23 00:12:30 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129074 From marius at alchemy.franken.de Sun Nov 23 07:40:04 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Sun Nov 23 07:40:10 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811231540.mANFe3Dt098312@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: David Christensen Cc: bug-followup@FreeBSD.org Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Sun, 23 Nov 2008 16:34:59 +0100 On Mon, Nov 17, 2008 at 11:37:19AM -0800, David Christensen wrote: > > Ok, thanks for testing anyway. > > I still think that this isn't really a driver bug though but > > you are hitting some hardware-related problem like f.e. a > > silicon bug and the question is how to work around it. > > There is a documented errata for the 5701 A3 where a 64bit DMA > read can be terminated early by the bridge and then completed > later as a 32bit access, causing corruption on the 5701. The > errata states this type of behavior is rare in bridges and that > the workaround is to force 32bit operation (set bit 15 of register > 0x6800). It's not clear whether this errata is occurring without > seeing a but trace but it certainly sounds right. The only > question would be knowing "when" to force 32bit operation. Should > it be done in all cases or only for this bridge? > David, could it be that bug doesn't only affect 5701 A3 but also B3 (i.e. chipid 0x01050000) as in this case or even all 5701 revisions? How does the problem you describe relate to the 5701 PCI-X issue, which we align the RX buffer differently for as a workaround, would that problem also be avoided by limiting 5701 to 32-bit operations? Or is the A3-errata you described an entirely different issue and limited to 5701 in a 64-bit non-PCI-X slot, or would 5701 in a PCI-X slot even require both workarounds? Marius From eitans at mellanox.co.il Sun Nov 23 09:25:12 2008 From: eitans at mellanox.co.il (Eitan Shefi) Date: Sun Nov 23 09:25:25 2008 Subject: IP fragmentation Message-ID: <5D49E7A8952DC44FB38C38FA0D758EAD0105450B@mtlexch01.mtl.com> Hi, The IP fragmentation is not like in Linux, and is not clear to me. I'm using 2 FreeBSD-6.3 hosts, connected directly. If I change the MTU of both hosts to 5000, and send "ping" with message size 4972 bytes ( 4972 = 5000 - 8(which is ICMP Header size) - 20 (which is IP Header size) ) from one host to the other, the message is passed as one packet: packet size 5000 bytes. (as expected) But if I send "ping" with message size 4973 bytes, the IP fragmentation to 2 packets is not clear to me: The first packet is with size: 4116 bytes The second packet is with size: 905 bytes I expected the first packet size to be: 4996 = 5000 - ((5000-20) Mod 8) and the second packet size to be: 25 = 5021 - 4996 What is the formula being used in FreeBSD to compute the IP fragments size? Thanks, Eitan From bzeeb-lists at lists.zabbadoz.net Sun Nov 23 09:50:13 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Nov 23 09:50:21 2008 Subject: IP fragmentation In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EAD0105450B@mtlexch01.mtl.com> References: <5D49E7A8952DC44FB38C38FA0D758EAD0105450B@mtlexch01.mtl.com> Message-ID: <20081123173627.V61259@maildrop.int.zabbadoz.net> On Sun, 23 Nov 2008, Eitan Shefi wrote: > Hi, > > The IP fragmentation is not like in Linux, and is not clear to me. > > I'm using 2 FreeBSD-6.3 hosts, connected directly. > If I change the MTU of both hosts to 5000, and send "ping" with message > size 4972 bytes ( 4972 = 5000 - 8(which is ICMP Header size) - 20 (which > is IP Header size) ) > from one host to the other, the message is passed as one packet: packet > size 5000 bytes. (as expected) > But if I send "ping" with message size 4973 bytes, the IP fragmentation > to 2 packets is not clear to me: > The first packet is with size: 4116 bytes > The second packet is with size: 905 bytes 4116 = 4096 + 20 20 usually is the size of the IP header 4096 most likely is your PAGE_SIZE I expected the first packet size to be: 4996 = 5000 - ((5000-20) Mod 8) > and the second packet size to be: 25 = 5021 - 4996 > > What is the formula being used in FreeBSD to compute the IP fragments > size? Try this here: http://fxr.watson.org/fxr/source/netinet/ip_output.c#L617 and see how 'len' gets adjusted. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From andreas.carbin at run.se Sun Nov 23 18:00:50 2008 From: andreas.carbin at run.se (Andreas Carbin) Date: Sun Nov 23 18:01:02 2008 Subject: FreeBSD 7.0 / Recv-Q full ? / win 0 ? In-Reply-To: <8072814.95851227489833192.JavaMail.root@mail03> Message-ID: <19347937.95871227490582742.JavaMail.root@mail03> Hello all, I have the following issue with my (quite newly installed) FreeBSD 7.0 machines: (I use "FreeBSD 7.0-RELEASE-p5 #0: Wed Oct 1 07:51:58 UTC 2008" on Dell PowerEdge 2970.) When I copy large files with SCP from one host to another the destination host's recieve queue seems to fill up after a random number of seconds (10 - 300) with about 89.000 bytes, and the destination host sends Window Size = 0 to the sender. This means no data is transferred and the connection has "locked up" in some way (true?). This almost always happens when I copy a file from one host to another where there is a WAN connection between them. I have checked firewall rules - these are open to almost any traffic. (I have seen it happen between two locally connected machines also.) When copying with SCP starts, it runs perfectly at about 10 megabyte/s (100Mbit/s WAN network). A 3 GB file may succeed <5%. Error occurrs in about 10 to 300 seconds - then all payload data traffic stops. The TCP connection is still open. My guess was that maybe we get errors when copying this fast "close to thoeretical limit", so I used "scp -l " where I specified as 50 and 5 Mbit/s. This reduces speed perfectly, but gives me the same errors as in full speed. I have also tried (with no good results): * net.inet.tcp.rfc1323 (on and off) * net.inet.tcp.tso (on and off) * RCXSUM and TXCSUM on and off * change from on-board bce0 / Broadcom NetXtreme II BCM5708 1000Base-T to em0 / Intel(R) PRO/1000 Network Connection Version - 6.7.3 * setting net.inet.tcp.recvbuf_max: 16777216 * setting net.inet.tcp.sendbuf_max: 16777216 One really strange thing is that I can make the copy continue (!) with full data transfer if I truss the ssh process on the destination machine. So if I truss with output to /dev/null in the background all the copy completes (!!!!). This is a tcpdump on destination host of SCP's TCP connection when no data is transferred: 15:56:17.798079 IP sender_host.51296 > destination_host.ssh: . 8:9(1) ack 1 win 33304 15:56:17.897407 IP destination_host.ssh > sender_host.51296: . ack 9 win 0 15:56:22.797808 IP sender_host.51296 > destination_host.ssh: . 9:10(1) ack 1 win 33304 15:56:22.897457 IP destination_host.ssh > sender_host.51296: . ack 10 win 0 15:56:27.797913 IP sender_host.51296 > destination_host.ssh: . 10:11(1) ack 1 win 33304 15:56:27.897508 IP destination_host.ssh > sender_host.51296: . ack 11 win 0 15:56:32.798016 IP sender_host.51296 > destination_host.ssh: . 11:12(1) ack 1 win 33304 15:56:32.897559 IP destination_host.ssh > sender_host.51296: . ack 12 win 0 15:56:37.798119 IP sender_host.51296 > destination_host.ssh: . 12:13(1) ack 1 win 33304 15:56:37.897610 IP destination_host.ssh > sender_host.51296: . ack 13 win 0 Does enyone have an idea what this might be? The error occurs when the receiving host is a FreeBSD 7.0 host (the sender can be 7.0 or 6.2 accoriding to my tests). Thank you, //Andreas ------------------------------------------------------- Andreas Carbin RUN Communications AB http://www.run.se E-mail: andreas.carbin@run.se ------------------------------------------------------- From pyunyh at gmail.com Sun Nov 23 20:23:11 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Nov 23 20:23:18 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: References: <20081117003856.GB50872@cdnetworks.co.kr> Message-ID: <20081124042101.GK78954@cdnetworks.co.kr> On Tue, Nov 18, 2008 at 09:09:44PM -0500, Gabriel Lavoie wrote: > Hum when I do my Samba transfer, there is a lot of small files (> 50 000) > and it seems at some point Samba tops at 100% CPU usage on one core. Is it > possible the rl(4) driver could be influenced by high CPU load? With the Yes, it's possible. rl(4) hardwares are notorious for its poor performance and instability under heavy load. I'm not sure the poor performance you're suffering from comes from rl(4) hardware itself or driver bug though. Note, ale(4) is not best hardware too. ale(4) hardwares still requires copy operation as rl(4) due to hardware limitation and if you're looking for better performance, replace your hardware with better controller such as em(4)/bge(4) or jme(4) which would have good performance/price ratio. > ale(4) driver, there's no problem but the Samba transfer becomes really slow > because of the amount of files. > > Gabriel > > 2008/11/18 Gabriel Lavoie > > > By the way, I'm currently trying the ale(4) driver under FreeBSD 7.0 (my > > current installation). It seems to works flawlesly with excellent > > performances. I'm currently doing the 30 GB transfer I'm unable to do with > > the Realtek card. I'll see what happens. > > > > Gabriel > > > > 2008/11/16 Pyun YongHyeon > > > > On Sun, Nov 16, 2008 at 06:01:58PM -0500, Gabriel Lavoie wrote: > >> > Hello, > >> > I recently built a new system to use as a home server. This system > >> has > >> > an Intel Pentium Dual Core E5200, 4GB RAM and an Asus P5KPL-CM > >> motherboard > >> > which has an Atheros L1E network adapter, not yet supported on FreeBSD. > >> For > >> > >> ale(4) was committed to HEAD. If you're using lastest stable/7 > >> see the following URL. > >> http://people.freebsd.org/~yongari/ale/README > >> > >> > now, I use a Realtek 8139 PCI adapter that uses the rl(4) driver, but > >> the > >> > upload performances are really poor (under 1 MB/sec). Is there any way > >> to > >> > improve the performance with this driver? This adapter was in a Linux > >> system > >> > with a Pentium III processor before and I could upload/download at > >> around 10 > >> > MB/sec in my local network with no problem at all. > >> > > >> > >> There was a bus_dma(9) bug in rl(4) and it was fixed in HEAD. > >> How about rl(4) in HEAD? I guess it would build with minor > >> modification. > >> > >> -- > >> Regards, > >> Pyun YongHyeon > >> > > > > > > > > -- > > Gabriel Lavoie > > glavoie@gmail.com > > > > > > -- > Gabriel Lavoie > glavoie@gmail.com -- Regards, Pyun YongHyeon From pyunyh at gmail.com Sun Nov 23 20:44:54 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Nov 23 20:45:03 2008 Subject: Realtek 8139 with rl(4) driver -> Poor performance In-Reply-To: References: <957411.42240.qm@web39101.mail.mud.yahoo.com> <20081117023024.GE50872@cdnetworks.co.kr> <20081117034428.GG50872@cdnetworks.co.kr> <20081118043731.GD55015@cdnetworks.co.kr> Message-ID: <20081124044242.GL78954@cdnetworks.co.kr> On Tue, Nov 18, 2008 at 05:28:13PM -0500, Gabriel Lavoie wrote: > Requested commands: > > Before a problem happens: > > [root@headless ~]# sysctl hw.busdma > hw.busdma.total_bpages: 8260 > hw.busdma.zone0.total_bpages: 8196 > hw.busdma.zone0.free_bpages: 8196 > hw.busdma.zone0.reserved_bpages: 0 > hw.busdma.zone0.active_bpages: 0 > hw.busdma.zone0.total_bounced: 0 > hw.busdma.zone0.total_deferred: 0 > hw.busdma.zone0.lowaddr: 0xffffffff > hw.busdma.zone0.alignment: 1 > hw.busdma.zone0.boundary: 0 > hw.busdma.zone1.total_bpages: 64 > hw.busdma.zone1.free_bpages: 64 > hw.busdma.zone1.reserved_bpages: 0 > hw.busdma.zone1.active_bpages: 0 > hw.busdma.zone1.total_bounced: 8200 > hw.busdma.zone1.total_deferred: 0 > hw.busdma.zone1.lowaddr: 0xffffffff > hw.busdma.zone1.alignment: 2 > hw.busdma.zone1.boundary: 65536 > > [root@headless ~]# netstat -nd -I rl0 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll Drop > rl0 1500 00:50:fc:c6:c8:d2 64336 0 60706 > 0 0 0 > rl0 1500 192.168.69.0/ 192.168.69.87 63398 - 59820 > - - - > > > I got a Samba copy error at this point: > > [root@headless /home/wildchild]# sysctl hw.busdma > hw.busdma.total_bpages: 8260 > hw.busdma.zone0.total_bpages: 8196 > hw.busdma.zone0.free_bpages: 8196 > hw.busdma.zone0.reserved_bpages: 0 > hw.busdma.zone0.active_bpages: 0 > hw.busdma.zone0.total_bounced: 0 > hw.busdma.zone0.total_deferred: 0 > hw.busdma.zone0.lowaddr: 0xffffffff > hw.busdma.zone0.alignment: 1 > hw.busdma.zone0.boundary: 0 > hw.busdma.zone1.total_bpages: 64 > hw.busdma.zone1.free_bpages: 64 > hw.busdma.zone1.reserved_bpages: 0 > hw.busdma.zone1.active_bpages: 0 > hw.busdma.zone1.total_bounced: 144539 > hw.busdma.zone1.total_deferred: 0 > hw.busdma.zone1.lowaddr: 0xffffffff > hw.busdma.zone1.alignment: 2 > hw.busdma.zone1.boundary: 65536 > [root@headless /home/wildchild]# netstat -nd -I rl0 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll Drop > rl0 1500 00:50:fc:c6:c8:d2 6718354 0 4023956 > 0 0 0 > rl0 1500 192.168.69.0/ 192.168.69.87 6717392 - 4023051 > - - - > > Now the networking is really erratic. I have a huge slowdown with SSH and > I'm unable to copy files on the computer anymore via Samba. I must reboot to > get back the full performance. > I don't see possible errors in code. Did rl(4) show some messages on your console? Since there are no errors in netstat output I have no clue yet. Does interface up/down fix the poor performance after you've seen Samba copy error? -- Regards, Pyun YongHyeon From bugmaster at FreeBSD.org Mon Nov 24 03:07:19 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 24 03:08:38 2008 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org Message-ID: <200811241107.mAOB7HiQ019976@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/129074 net [ppp] [panic] kernel panic with pppoe_server o kern/129022 net [ath] ath cannot connect using WEP 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 kern/128833 net [bge] Network packets corrupted when bge card is in 64 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 kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? 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: 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/126984 net [carp][patch] add carp userland notifications via devc 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 f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic 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 [in] Network: 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 f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr 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/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p 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/123881 net [tcp] Turning on TCP blackholing causes slow localhost 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 o 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/123200 net [netgraph] Server failure due to netgraph mpd and dhcp 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/123066 net [ipsec] [panic] kernel trap with ipsec 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 [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/122427 net [apm] [panic] apm and mDNSResponder cause panic during 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/122068 net [ppp] ppp can not set the correct interface with pptpd 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 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 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 [panic] gnugk causes kernel panic when closing UDP soc 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 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/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented 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 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/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat 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/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 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/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 bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a 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 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 conf/102502 net [patch] ifconfig name does't rename netgraph node in n 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/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/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 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 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/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/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 FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic 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/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 196 problems total. From remko at FreeBSD.org Mon Nov 24 09:21:48 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Mon Nov 24 09:21:55 2008 Subject: i386/129135: vge driver on a VIA mini-ITX not working Message-ID: <200811241721.mAOHLmYD018746@freefall.freebsd.org> Synopsis: vge driver on a VIA mini-ITX not working Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Nov 24 17:21:47 UTC 2008 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=129135 From davidch at broadcom.com Mon Nov 24 11:50:04 2008 From: davidch at broadcom.com (David Christensen) Date: Mon Nov 24 11:50:10 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811241950.mAOJo4hF024913@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: "David Christensen" To: "Marius Strobl" Cc: "bug-followup@FreeBSD.org" Subject: RE: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Mon, 24 Nov 2008 11:28:10 -0800 > > There is a documented errata for the 5701 A3 where a 64bit DMA > > read can be terminated early by the bridge and then completed > > later as a 32bit access, causing corruption on the 5701. The > > errata states this type of behavior is rare in bridges and that > > the workaround is to force 32bit operation (set bit 15 of register > > 0x6800). It's not clear whether this errata is occurring without > > seeing a but trace but it certainly sounds right. The only > > question would be knowing "when" to force 32bit operation. Should > > it be done in all cases or only for this bridge? > > >=20 > David, >=20 > could it be that bug doesn't only affect 5701 A3 but also > B3 (i.e. chipid 0x01050000) as in this case or even all 5701 > revisions?=20 I checked the assembly instructions for the 5701 and even though the ASIC ID decodes as B5, the revision of the chip is actually A3. (You should be able to verify this as the silkscreen on the part should show "P13".) Unfortunately the "friendly" revision of the chip doesn't match the "ASIC" revision of the chip for the 5701 and the errata references the "friendly" name. The result is that the part you know as B5 is affected by this errata. Other versions of the chip (A2 which you know as B2 and A1 which you=20 know as B1) are not subject to this errata. > How does the problem you describe relate to the > 5701 PCI-X issue, which we align the RX buffer differently > for as a workaround, would that problem also be avoided > by limiting 5701 to 32-bit operations? Or is the A3-errata > you described an entirely different issue and limited to 5701 > in a 64-bit non-PCI-X slot, or would 5701 in a PCI-X slot > even require both workarounds? Which PCI-X issue are you referring to? Can you point me to the line number on http://fxr.watson.org/fxr/source/dev/bge/if_bge.c? Dave From davidch at broadcom.com Mon Nov 24 13:46:15 2008 From: davidch at broadcom.com (David Christensen) Date: Mon Nov 24 13:46:21 2008 Subject: Gathering Hardware State During a Driver Initiated Kernel Panic Message-ID: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> Is there a method or callback in FreeBSD where a driver can be notified that it has caused a kernel panic in order to generate a dump of internal hardware state information? I've written a sysctl call for manual intervention and can handle some "expected" hardware events completely in the driver but I don't know of a way to get control again in cases where the driver wasn't expecting a failure. Dave From marius at alchemy.franken.de Mon Nov 24 13:50:04 2008 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon Nov 24 13:50:11 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811242150.mAOLo4LZ015020@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: Marius Strobl To: David Christensen Cc: "bug-followup@FreeBSD.org" Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Mon, 24 Nov 2008 22:40:36 +0100 On Mon, Nov 24, 2008 at 11:28:10AM -0800, David Christensen wrote: > > > There is a documented errata for the 5701 A3 where a 64bit DMA > > > read can be terminated early by the bridge and then completed > > > later as a 32bit access, causing corruption on the 5701. The > > > errata states this type of behavior is rare in bridges and that > > > the workaround is to force 32bit operation (set bit 15 of register > > > 0x6800). It's not clear whether this errata is occurring without > > > seeing a but trace but it certainly sounds right. The only > > > question would be knowing "when" to force 32bit operation. Should > > > it be done in all cases or only for this bridge? > > > > > > > David, > > > > could it be that bug doesn't only affect 5701 A3 but also > > B3 (i.e. chipid 0x01050000) as in this case or even all 5701 > > revisions? > > I checked the assembly instructions for the 5701 and even though > the ASIC ID decodes as B5, the revision of the chip is actually > A3. (You should be able to verify this as the silkscreen on the > part should show "P13".) Unfortunately the "friendly" revision > of the chip doesn't match the "ASIC" revision of the chip for the > 5701 and the errata references the "friendly" name. The result > is that the part you know as B5 is affected by this errata. Other > versions of the chip (A2 which you know as B2 and A1 which you > know as B1) are not subject to this errata. Ah, this explains it. Thanks for looking it up! > > > How does the problem you describe relate to the > > 5701 PCI-X issue, which we align the RX buffer differently > > for as a workaround, would that problem also be avoided > > by limiting 5701 to 32-bit operations? Or is the A3-errata > > you described an entirely different issue and limited to 5701 > > in a 64-bit non-PCI-X slot, or would 5701 in a PCI-X slot > > even require both workarounds? > > Which PCI-X issue are you referring to? Can you point me to > the line number on http://fxr.watson.org/fxr/source/dev/bge/if_bge.c? > I was refering to BGE_FLAG_RX_ALIGNBUG, the lines dealing with it are 874-875, 933-934, 2698-2708 and 3112-3122. The Linux tg3 driver does pretty much the same via rx_offset. Marius From sam at freebsd.org Mon Nov 24 14:14:18 2008 From: sam at freebsd.org (Sam Leffler) Date: Mon Nov 24 14:14:24 2008 Subject: Gathering Hardware State During a Driver Initiated Kernel Panic In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <492B2306.60404@freebsd.org> David Christensen wrote: > Is there a method or callback in FreeBSD where a driver can > be notified that it has caused a kernel panic in order to > generate a dump of internal hardware state information? I've > written a sysctl call for manual intervention and can handle > some "expected" hardware events completely in the driver but > I don't know of a way to get control again in cases where the > driver wasn't expecting a failure. > Not sure how one can deduce a driver is at fault but you might define a ddb command for the driver and invoke that on panic using the ddb script mechanisms (see ddb(4)). Sam From davidch at broadcom.com Mon Nov 24 14:40:04 2008 From: davidch at broadcom.com (David Christensen) Date: Mon Nov 24 14:40:10 2008 Subject: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Message-ID: <200811242240.mAOMe4kr052672@freefall.freebsd.org> The following reply was made to PR kern/128833; it has been noted by GNATS. From: "David Christensen" To: "Marius Strobl" Cc: "bug-followup@FreeBSD.org" Subject: RE: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot Date: Mon, 24 Nov 2008 14:38:35 -0800 > > > How does the problem you describe relate to the > > > 5701 PCI-X issue, which we align the RX buffer differently > > > for as a workaround, would that problem also be avoided > > > by limiting 5701 to 32-bit operations? Or is the A3-errata > > > you described an entirely different issue and limited to 5701 > > > in a 64-bit non-PCI-X slot, or would 5701 in a PCI-X slot > > > even require both workarounds? > > > > Which PCI-X issue are you referring to? Can you point me to > > the line number on http://fxr.watson.org/fxr/source/dev/bge/if_bge.c? > > >=20 > I was refering to BGE_FLAG_RX_ALIGNBUG, the lines dealing with it > are 874-875, 933-934, 2698-2708 and 3112-3122. The Linux tg3 > driver does pretty much the same via rx_offset. It's a different problem. The RX_ALIGNBUG is described in the errata as follows: "Description: In PCI-X mode, on rare instances, the DMA write engine=20 can incorrectly DMA duplicate data to the host if the first word of=20 the data being transferred is to a non-zero-offset address (offset=20 from the 8-byte boundary). Workaround: Align buffers to zero offset in the driver." I suppose you could force PCI mode for this problem too though at the expense of possible reduced performance. Dave From janm at transactionware.com Tue Nov 25 05:28:59 2008 From: janm at transactionware.com (Jan Mikkelsen) Date: Tue Nov 25 05:29:06 2008 Subject: [em] 7.1-PRE, one em port works, one fails, no problem on 6.3-p1 Message-ID: Hi, On a machine with a Supermicro X7DB8 board I get this error on startup: em1: port 0x3020-0x303f mem 0xd8420000-0xd843ffff irq 19 at device 0.1 on pci6 em1: Using MSI interrupt em1: Hardware Initialization Failed em1: Unable to initialize the hardware device_attach: em1 attach returned 5 There is no management card in this particular machine, and em0 on the same motherboard is fine. I can see a few similar problems in the archives, but I don't see a definitive solution. The same machine runs fine with 6.3-p1. Dmesg below. Any suggestions? Thanks, Jan Mikkelsen Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Tue Nov 25 10:07:25 EST 2008 root@dm.transactionware.com:/home/janm/p4/freebsd-image-std-2008.2/work/base -freebsd/home/janm/p4/freebsd-image-std-2008.2/FreeBSD/src/sys/TW-SMP Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2333.35-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4280651776 (4082 MB) avail memory = 4117843968 (3927 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 ahd0: port 0x2400-0x24ff,0x2000-0x20ff mem 0xd8500000-0xd8501fff irq 16 at device 2.0 on pci4 ahd0: [ITHREAD] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs ahd1: port 0x2c00-0x2cff,0x2800-0x28ff mem 0xd8502000-0xd8503fff irq 17 at device 2.1 on pci4 ahd1: [ITHREAD] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs pcib5: at device 0.2 on pci3 pci5: on pcib5 bge0: mem 0xd8600000-0xd860ffff irq 16 at device 1.0 on pci5 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:40:f4:66:b1:56 bge0: [ITHREAD] pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x3000-0x301f mem 0xd8400000-0xd841ffff irq 18 at device 0.0 on pci6 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:31:67:86 em1: port 0x3020-0x303f mem 0xd8420000-0xd843ffff irq 19 at device 0.1 on pci6 em1: Using MSI interrupt em1: Hardware Initialization Failed em1: Unable to initialize the hardware device_attach: em1 attach returned 5 pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 4.0 on pci0 pci8: on pcib8 pcib9: at device 6.0 on pci0 pci9: on pcib9 pcib10: at device 0.0 on pci9 pci10: on pcib10 arcmsr0: mem 0xd8900000-0xd8900fff,0xd8000000-0xd83fffff irq 16 at device 14.0 on pci10 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 arcmsr0: [ITHREAD] pcib11: at device 0.2 on pci9 pci11: on pcib11 pcib12: irq 17 at device 28.0 on pci0 pci12: on pcib12 uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd8c00000-0xd8c003ff irq 17 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib13: at device 30.0 on pci0 pci13: on pcib13 vgapci0: port 0x4000-0x40ff mem 0xd0000000-0xd7ffffff,0xd8800000-0xd880ffff irq 18 at device 1.0 on pci13 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 728072806000728 device_attach: est3 attach returned 6 p4tcc3: on cpu3 orm0: at iomem 0xc0000-0xcafff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: DVDR at ata0-master UDMA66 Waiting 5 seconds for SCSI devices to settle (probe46:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: 77247MB (158201856 512 byte sectors: 255H 63S/T 9847C) da1 at arcmsr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da1: 953673MB (1953122304 512 byte sectors: 255H 63S/T 121576C) da2 at arcmsr0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da2: 800131MB (1638669312 512 byte sectors: 255H 63S/T 102002C) sa0 at ahd1 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 15) SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/da0s1a This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 em0: link state changed to UP bge0: link state changed to UP From eugen at kuzbass.ru Tue Nov 25 05:42:42 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Nov 25 05:42:50 2008 Subject: m_tag_find() overhead Message-ID: <20081125134239.GA17138@svzserv.kemerovo.su> Hi! I wonder if one more call to m_tag_find() for every outgoing packet would be expensive. For many years conventional way to implement PBR was: use 'ipfw fwd'. Currently 'ipfw add fwd ... in' marks a packet with PACKET_TAG_IPFORWARD. Such forwarding changes packet's outgoing interface generally but none in the kernel reflect this in packet's metadata and packets are passed by ip_output() to PFIL hooks with wrong outgoing interface name ( details and How-To-Repeat may be found here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/129036 ) I've patched src/sys/netinet/ip_output.c to fix this problem by extra check for PACKET_TAG_IPFORWARD and update of route if necessary. This adds a call to m_tag_find() for every outgoing packet if packet filtering is enabled and kernel has options IPFIREWALL_FORWARD. Please review. It works for my test lab but I'm not sure if that's correct: should a call to rtalloc_ign() be accomplished with some resource freeing call? And what's the meaning of RTF_CLONING second argument of rtalloc_ign? --- ip_output.c.orig 2008-11-25 14:21:26.000000000 +0700 +++ ip_output.c 2008-11-25 18:29:32.000000000 +0700 @@ -195,6 +195,20 @@ ro->ro_rt = (struct rtentry *)0; } #ifdef IPFIREWALL_FORWARD + /* + * Check if packet has changed next-hop in ip_input() + * If so, update route so pfil hooks get it right + */ + if ((inet_pfil_hook.ph_busy_count != -1) && + (fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL))) { + bzero(&iproute, sizeof(iproute)); + ro = &iproute; + bcopy((fwd_tag+1), &ro->ro_dst, sizeof(struct sockaddr_in)); + m_tag_delete(m, fwd_tag); + rtalloc_ign(ro, RTF_CLONING); + dst = (struct sockaddr_in *)&ro->ro_dst; + } + if (ro->ro_rt == NULL && fwd_tag == NULL) { #else if (ro->ro_rt == NULL) { Eugene Grosbein From mamruoc at gmail.com Tue Nov 25 05:50:04 2008 From: mamruoc at gmail.com (Mam Ruoc) Date: Tue Nov 25 05:50:11 2008 Subject: kern/129135: vge driver on a VIA mini-ITX not working Message-ID: <200811251350.mAPDo4Wq073967@freefall.freebsd.org> The following reply was made to PR kern/129135; it has been noted by GNATS. From: Mam Ruoc To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/129135: vge driver on a VIA mini-ITX not working Date: Tue, 25 Nov 2008 14:14:02 +0100 Seems like I'm not the only one that have this problem in 7.0: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/106851 From jfvogel at gmail.com Tue Nov 25 09:31:47 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Nov 25 09:32:08 2008 Subject: [em] 7.1-PRE, one em port works, one fails, no problem on 6.3-p1 In-Reply-To: References: Message-ID: <2a41acea0811250931x53e545b8qd392c56c7705104d@mail.gmail.com> There is a fix for this, but have not been able to get it in yet :( Jack On Tue, Nov 25, 2008 at 5:02 AM, Jan Mikkelsen wrote: > Hi, > > On a machine with a Supermicro X7DB8 board I get this error on startup: > > em1: port 0x3020-0x303f mem > 0xd8420000-0xd843ffff irq 19 at device 0.1 on pci6 > em1: Using MSI interrupt > em1: Hardware Initialization Failed > em1: Unable to initialize the hardware > device_attach: em1 attach returned 5 > > There is no management card in this particular machine, and em0 on the same > motherboard is fine. I can see a few similar problems in the archives, but > I don't see a definitive solution. The same machine runs fine with 6.3-p1. > > Dmesg below. > > Any suggestions? > > Thanks, > > Jan Mikkelsen > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-PRERELEASE #0: Tue Nov 25 10:07:25 EST 2008 > > root@dm.transactionware.com: > /home/janm/p4/freebsd-image-std-2008.2/work/base > -freebsd/home/janm/p4/freebsd-image-std-2008.2/FreeBSD/src/sys/TW-SMP > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2333.35-MHz K8-class > CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > > > Features=0xbfebfbff ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > > Features2=0x4e3bd > > AMD Features=0x20100800 > AMD Features2=0x1 > Cores per package: 2 > usable memory = 4280651776 (4082 MB) > avail memory = 4117843968 (3927 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: irq 16 at device 0.0 on pci1 > pci2: on pcib2 > pcib3: irq 16 at device 0.0 on pci2 > pci3: on pcib3 > pcib4: at device 0.0 on pci3 > pci4: on pcib4 > ahd0: port > 0x2400-0x24ff,0x2000-0x20ff mem 0xd8500000-0xd8501fff irq 16 at device 2.0 > on pci4 > ahd0: [ITHREAD] > aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs > ahd1: port > 0x2c00-0x2cff,0x2800-0x28ff mem 0xd8502000-0xd8503fff irq 17 at device 2.1 > on pci4 > ahd1: [ITHREAD] > aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs > pcib5: at device 0.2 on pci3 > pci5: on pcib5 > bge0: mem > 0xd8600000-0xd860ffff irq 16 at device 1.0 on pci5 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bge0: Ethernet address: 00:40:f4:66:b1:56 > bge0: [ITHREAD] > pcib6: irq 18 at device 2.0 on pci2 > pci6: on pcib6 > em0: port 0x3000-0x301f mem > 0xd8400000-0xd841ffff irq 18 at device 0.0 on pci6 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:30:48:31:67:86 > em1: port 0x3020-0x303f mem > 0xd8420000-0xd843ffff irq 19 at device 0.1 on pci6 > em1: Using MSI interrupt > em1: Hardware Initialization Failed > em1: Unable to initialize the hardware > device_attach: em1 attach returned 5 > pcib7: at device 0.3 on pci1 > pci7: on pcib7 > pcib8: at device 4.0 on pci0 > pci8: on pcib8 > pcib9: at device 6.0 on pci0 > pci9: on pcib9 > pcib10: at device 0.0 on pci9 > pci10: on pcib10 > arcmsr0: > mem 0xd8900000-0xd8900fff,0xd8000000-0xd83fffff irq 16 at device 14.0 on > pci10 > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 > arcmsr0: [ITHREAD] > pcib11: at device 0.2 on pci9 > pci11: on pcib11 > pcib12: irq 17 at device 28.0 on pci0 > pci12: on pcib12 > uhci0: port 0x1800-0x181f > irq 17 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0x1820-0x183f > irq 19 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0x1840-0x185f > irq 18 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem 0xd8c00000-0xd8c003ff irq 17 > at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: on usb3 > uhub3: 6 ports with 6 removable, self powered > pcib13: at device 30.0 on pci0 > pci13: on pcib13 > vgapci0: port 0x4000-0x40ff mem > 0xd0000000-0xd7ffffff,0xd8800000-0xd880ffff irq 18 at device 1.0 on pci13 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > sio1: [FILTER] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > ppbus0: [ITHREAD] > plip0: on ppbus0 > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > cpu2: on acpi0 > est2: on cpu2 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est2 attach returned 6 > p4tcc2: on cpu2 > cpu3: on acpi0 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > orm0: at iomem 0xc0000-0xcafff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > acd0: DVDR at ata0-master UDMA66 > Waiting 5 seconds for SCSI devices to settle > (probe46:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step > da0 at arcmsr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da0: 77247MB (158201856 512 byte sectors: 255H 63S/T 9847C) > da1 at arcmsr0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da1: 953673MB (1953122304 512 byte sectors: 255H 63S/T 121576C) > da2 at arcmsr0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI-5 device > da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da2: 800131MB (1638669312 512 byte sectors: 255H 63S/T 102002C) > sa0 at ahd1 bus 0 target 6 lun 0 > sa0: Removable Sequential Access SCSI-2 > device > sa0: 10.000MB/s transfers (10.000MHz, offset 15) > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #3 Launched! > Trying to mount root from ufs:/dev/da0s1a > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > ZFS filesystem version 6 > ZFS storage pool version 6 > em0: link state changed to UP > bge0: link state changed to UP > > _______________________________________________ > 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 janm at transactionware.com Tue Nov 25 11:50:54 2008 From: janm at transactionware.com (Jan Mikkelsen) Date: Tue Nov 25 11:51:01 2008 Subject: [em] 7.1-PRE, one em port works, one fails, no problem on 6.3-p1 In-Reply-To: <2a41acea0811250931x53e545b8qd392c56c7705104d@mail.gmail.com> Message-ID: <60C2C2D3A191401FAF7897C07C6C51E8@STUDYPC> Hi Jack, Thanks for the reply. Is there a workaround, or something I can merge myself? If not, any idea on when it might make it in? Thanks, Jan > -----Original Message----- > From: Jack Vogel [mailto:jfvogel@gmail.com] > Sent: Wednesday, 26 November 2008 4:32 AM > To: Jan Mikkelsen > Cc: freebsd-net@freebsd.org > Subject: Re: [em] 7.1-PRE, one em port works, one fails, no > problem on 6.3-p1 > > > There is a fix for this, but have not been able to get it in yet :( > > Jack > > > > On Tue, Nov 25, 2008 at 5:02 AM, Jan Mikkelsen > wrote: > > > Hi, > > On a machine with a Supermicro X7DB8 board I get this > error on startup: > > em1: port > 0x3020-0x303f mem > 0xd8420000-0xd843ffff irq 19 at device 0.1 on pci6 > em1: Using MSI interrupt > em1: Hardware Initialization Failed > em1: Unable to initialize the hardware > device_attach: em1 attach returned 5 > > There is no management card in this particular machine, > and em0 on the same > motherboard is fine. I can see a few similar problems > in the archives, but > I don't see a definitive solution. The same machine > runs fine with 6.3-p1. > > Dmesg below. > > Any suggestions? > > Thanks, > > Jan Mikkelsen > > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, > 1992, 1993, 1994 > The Regents of the University of California. All > rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.1-PRERELEASE #0: Tue Nov 25 10:07:25 EST 2008 > > > root@dm.transactionware.com:/home/janm/p4/freebsd-image-std-20 > 08.2/work/base > > -freebsd/home/janm/p4/freebsd-image-std-2008.2/FreeBSD/src/sys/TW-SMP > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz > (2333.35-MHz K8-class > CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > > > Features=0xbfebfbff P,MTRR,PGE,MCA > > ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > > Features2=0x4e3bd ,xTPR,PDCM,DCA > > > AMD Features=0x20100800 > AMD Features2=0x1 > Cores per package: 2 > usable memory = 4280651776 (4082 MB) > avail memory = 4117843968 (3927 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 6 > cpu3 (AP): APIC ID: 7 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, > RF5112, RF2413, RF5413) > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port > 0x1008-0x100b on acpi0 > acpi_hpet0: iomem > 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: irq 16 at device 0.0 on pci1 > pci2: on pcib2 > pcib3: irq 16 at device 0.0 on pci2 > pci3: on pcib3 > pcib4: at device 0.0 on pci3 > pci4: on pcib4 > ahd0: port > 0x2400-0x24ff,0x2000-0x20ff mem 0xd8500000-0xd8501fff > irq 16 at device 2.0 > on pci4 > ahd0: [ITHREAD] > aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X > 67-100Mhz, 512 SCBs > ahd1: port > 0x2c00-0x2cff,0x2800-0x28ff mem 0xd8502000-0xd8503fff > irq 17 at device 2.1 > on pci4 > ahd1: [ITHREAD] > aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X > 67-100Mhz, 512 SCBs > pcib5: at device 0.2 on pci3 > pci5: on pcib5 > bge0: mem > 0xd8600000-0xd860ffff irq 16 at device 1.0 on pci5 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > bge0: Ethernet address: 00:40:f4:66:b1:56 > bge0: [ITHREAD] > pcib6: irq 18 at device 2.0 on pci2 > pci6: on pcib6 > em0: port > 0x3000-0x301f mem > 0xd8400000-0xd841ffff irq 18 at device 0.0 on pci6 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:30:48:31:67:86 > em1: port > 0x3020-0x303f mem > 0xd8420000-0xd843ffff irq 19 at device 0.1 on pci6 > em1: Using MSI interrupt > em1: Hardware Initialization Failed > em1: Unable to initialize the hardware > device_attach: em1 attach returned 5 > pcib7: at device 0.3 on pci1 > pci7: on pcib7 > pcib8: at device 4.0 on pci0 > pci8: on pcib8 > pcib9: at device 6.0 on pci0 > pci9: on pcib9 > pcib10: at device 0.0 on pci9 > pci10: on pcib10 > arcmsr0: (RAID6 capable) > > mem 0xd8900000-0xd8900fff,0xd8000000-0xd83fffff irq > 16 at device 14.0 on > pci10 > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 > arcmsr0: [ITHREAD] > pcib11: at device 0.2 on pci9 > pci11: on pcib11 > pcib12: irq 17 at device 28.0 on pci0 > pci12: on pcib12 > uhci0: USB-1> port 0x1800-0x181f > irq 17 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: addr 1> on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: USB-2> port 0x1820-0x183f > irq 19 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: addr 1> on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: USB-3> port 0x1840-0x185f > irq 18 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: addr 1> on usb2 > uhub2: 2 ports with 2 removable, self powered > ehci0: mem > 0xd8c00000-0xd8c003ff irq 17 > at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb3: EHCI version 1.0 > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > usb3: on ehci0 > usb3: USB revision 2.0 > uhub3: addr 1> on usb3 > uhub3: 6 ports with 6 removable, self powered > pcib13: at device 30.0 on pci0 > pci13: on pcib13 > vgapci0: port 0x4000-0x40ff mem > 0xd0000000-0xd7ffffff,0xd8800000-0xd880ffff irq 18 at > device 1.0 on pci13 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at > device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atkbdc0: port 0x60,0x64 > irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model Generic PS/2 mouse, device ID 0 > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq > 4 flags 0x10 on > acpi0 > sio0: type 16550A > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq > 3 on acpi0 > sio1: type 16550A > sio1: [FILTER] > fdc0: port 0x3f0-0x3f5,0x3f7 > irq 6 drq 2 on acpi0 > fdc0: [FILTER] > ppc0: port 0x378-0x37f,0x778-0x77f irq > 7 drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > ppbus0: [ITHREAD] > plip0: on ppbus0 > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > cpu2: on acpi0 > est2: on cpu2 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est2 attach returned 6 > p4tcc2: on cpu2 > cpu3: on acpi0 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 728072806000728 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > orm0: at iomem 0xc0000-0xcafff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem > 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > acd0: DVDR at ata0-master UDMA66 > Waiting 5 seconds for SCSI devices to settle > (probe46:arcmsr0:0:16:0): inquiry data fails comparison > at DV1 step > da0 at arcmsr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access > SCSI-5 device > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da0: 77247MB (158201856 512 byte sectors: 255H 63S/T 9847C) > da1 at arcmsr0 bus 0 target 1 lun 0 > da1: Fixed Direct Access > SCSI-5 device > da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da1: 953673MB (1953122304 512 byte sectors: 255H 63S/T 121576C) > da2 at arcmsr0 bus 0 target 2 lun 0 > da2: Fixed Direct Access > SCSI-5 device > da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da2: 800131MB (1638669312 512 byte sectors: 255H 63S/T 102002C) > sa0 at ahd1 bus 0 target 6 lun 0 > sa0: Removable > Sequential Access SCSI-2 > device > sa0: 10.000MB/s transfers (10.000MHz, offset 15) > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #3 Launched! > Trying to mount root from ufs:/dev/da0s1a > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > WARNING: ZFS is considered to be an experimental > feature in FreeBSD. > ZFS filesystem version 6 > ZFS storage pool version 6 > em0: link state changed to UP > bge0: link state changed to UP > > _______________________________________________ > 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 jfvogel at gmail.com Tue Nov 25 15:41:30 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Nov 25 15:41:37 2008 Subject: 7.1 RC E1000 fix testing Message-ID: <2a41acea0811251541n53887005oabd7d2d96f346b6d@mail.gmail.com> Anyone running 7.1 and using E1000 hardware that has the time, I would appreciate any testing you can do. This has an important fix for SuperMicro servers but any regression test of the code would be helpful. The email was getting rejected due to the tarball size, so contact me and I will send you the code directly. Jack From jfvogel at gmail.com Tue Nov 25 15:38:44 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Nov 25 16:07:15 2008 Subject: 7.1 RC E1000 fix Message-ID: <2a41acea0811251538x6dbc8d5etcb114b99b784800a@mail.gmail.com> Anyone running 7.1 and using E1000 hardware that has the time, I would appreciate any testing you can do. This has an important fix for SuperMicro servers but any regression test of the code would be helpful. Backup the contents of /usr/src/sys/dev/e1000 and then overwrite with this tarball. Send feedback to me, Jack From killing at multiplay.co.uk Tue Nov 25 16:19:47 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Tue Nov 25 16:19:53 2008 Subject: 7.1 RC E1000 fix testing References: <2a41acea0811251541n53887005oabd7d2d96f346b6d@mail.gmail.com> Message-ID: <6D1A722EC3A74794A4DC82D8DC35F85B@multiplay.co.uk> We run a large about of supermicro servers here and I've got two just about to be commissioned which I could use for testing. What sort of thing should we be looking for and what's the nature of the patch? Regards Steve ----- Original Message ----- From: "Jack Vogel" To: ; "FreeBSD stable" Sent: Tuesday, November 25, 2008 11:41 PM Subject: 7.1 RC E1000 fix testing > Anyone running 7.1 and using E1000 hardware that has the time, I would > appreciate > any testing you can do. This has an important fix for SuperMicro servers but > any > regression test of the code would be helpful. > > The email was getting rejected due to the tarball size, so contact me and I > will send > you the code directly. > > Jack > _______________________________________________ > 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 janm at transactionware.com Tue Nov 25 22:02:54 2008 From: janm at transactionware.com (Jan Mikkelsen) Date: Tue Nov 25 22:03:01 2008 Subject: [em] 7.1-PRE, one em port works, one fails, no problem on 6.3-p1 In-Reply-To: <2a41acea0811251429l1899a839p68abfaf02fb3f682@mail.gmail.com> References: <2a41acea0811250931x53e545b8qd392c56c7705104d@mail.gmail.com> <60C2C2D3A191401FAF7897C07C6C51E8@STUDYPC> <2a41acea0811251429l1899a839p68abfaf02fb3f682@mail.gmail.com> Message-ID: <492CE68A.2070503@transactionware.com> Hi Jack, I've just run some simple tests with your second tar file, and seems to work fine. The error message on boot up is gone, and data can be transferred. I'll leave it running on this version and report any other issues I see. Thanks! Jan. Jack Vogel wrote: > I would appreciate any and all that can give this some quick test to do > so, this is what you > do: > 1) save the contents of /usr/src/sys/dev/e1000 > 2) then overwrite it with this tarball, due to the way the > drivers are > packaged this change effects igb and em > > I most need to know if it fixes your ESB2 problem, but sanity testing on > BOTH drivers > would be most appreciated. I would really like this checked into 7.1 ASAP. > > > On Tue, Nov 25, 2008 at 11:50 AM, Jan Mikkelsen > > wrote: > > Hi Jack, > > Thanks for the reply. > > Is there a workaround, or something I can merge myself? If not, any > idea on > when it might make it in? > > Thanks, > > Jan > > > -----Original Message----- > > From: Jack Vogel [mailto:jfvogel@gmail.com > ] > > Sent: Wednesday, 26 November 2008 4:32 AM > > To: Jan Mikkelsen > > Cc: freebsd-net@freebsd.org > > Subject: Re: [em] 7.1-PRE, one em port works, one fails, no > > problem on 6.3-p1 > > > > > > There is a fix for this, but have not been able to get it in yet :( > > > > Jack > > > > > > > > On Tue, Nov 25, 2008 at 5:02 AM, Jan Mikkelsen > > > wrote: > > > > > > Hi, > > > > On a machine with a Supermicro X7DB8 board I get this > > error on startup: > > > > em1: port > > 0x3020-0x303f mem > > 0xd8420000-0xd843ffff irq 19 at device 0.1 on pci6 > > em1: Using MSI interrupt > > em1: Hardware Initialization Failed > > em1: Unable to initialize the hardware > > device_attach: em1 attach returned 5 > > > > There is no management card in this particular machine, > > and em0 on the same > > motherboard is fine. I can see a few similar problems > > in the archives, but > > I don't see a definitive solution. The same machine > > runs fine with 6.3-p1. > > > > Dmesg below. > > > > Any suggestions? > > > > Thanks, > > > > Jan Mikkelsen > > > > Copyright (c) 1992-2008 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, > > 1992, 1993, 1994 > > The Regents of the University of California. All > > rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 7.1-PRERELEASE #0: Tue Nov 25 10:07:25 EST 2008 > > > > > > root@dm.transactionware.com:/home/janm/p4/freebsd-image-std-20 > > 08.2/work/base > > > > -freebsd/home/janm/p4/freebsd-image-std-2008.2/FreeBSD/src/sys/TW-SMP > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz > > (2333.35-MHz K8-class > > CPU) > > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > > > > > > Features=0xbfebfbff > P,MTRR,PGE,MCA > > > > ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > > > > > Features2=0x4e3bd > ,xTPR,PDCM,DCA > > > > > AMD Features=0x20100800 > > AMD Features2=0x1 > > Cores per package: 2 > > usable memory = 4280651776 (4082 MB) > > avail memory = 4117843968 (3927 MB) > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > cpu2 (AP): APIC ID: 6 > > cpu3 (AP): APIC ID: 7 > > ioapic0 irqs 0-23 on motherboard > > ioapic1 irqs 24-47 on motherboard > > kbd1 at kbdmux0 > > ath_hal: 0.9.20.3 (AR5210, AR5211, > AR5212, RF5111, > > RF5112, RF2413, RF5413) > > acpi0: on motherboard > > acpi0: [ITHREAD] > > acpi0: Power Button (fixed) > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > acpi_timer0: <24-bit timer at 3.579545MHz> port > > 0x1008-0x100b on acpi0 > > acpi_hpet0: iomem > > 0xfed00000-0xfed003ff on > > acpi0 > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > pcib1: at device 2.0 on pci0 > > pci1: on pcib1 > > pcib2: irq 16 at device 0.0 on pci1 > > pci2: on pcib2 > > pcib3: irq 16 at device 0.0 on pci2 > > pci3: on pcib3 > > pcib4: at device 0.0 on pci3 > > pci4: on pcib4 > > ahd0: port > > 0x2400-0x24ff,0x2000-0x20ff mem 0xd8500000-0xd8501fff > > irq 16 at device 2.0 > > on pci4 > > ahd0: [ITHREAD] > > aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X > > 67-100Mhz, 512 SCBs > > ahd1: port > > 0x2c00-0x2cff,0x2800-0x28ff mem 0xd8502000-0xd8503fff > > irq 17 at device 2.1 > > on pci4 > > ahd1: [ITHREAD] > > aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X > > 67-100Mhz, 512 SCBs > > pcib5: at device 0.2 on pci3 > > pci5: on pcib5 > > bge0: mem > > 0xd8600000-0xd860ffff irq 16 at device 1.0 on pci5 > > miibus0: on bge0 > > brgphy0: PHY 1 on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, > > 100baseTX-FDX, 1000baseT, > > 1000baseT-FDX, auto > > bge0: Ethernet address: 00:40:f4:66:b1:56 > > bge0: [ITHREAD] > > pcib6: irq 18 at device 2.0 on pci2 > > pci6: on pcib6 > > em0: port > > 0x3000-0x301f mem > > 0xd8400000-0xd841ffff irq 18 at device 0.0 on pci6 > > em0: Using MSI interrupt > > em0: [FILTER] > > em0: Ethernet address: 00:30:48:31:67:86 > > em1: port > > 0x3020-0x303f mem > > 0xd8420000-0xd843ffff irq 19 at device 0.1 on pci6 > > em1: Using MSI interrupt > > em1: Hardware Initialization Failed > > em1: Unable to initialize the hardware > > device_attach: em1 attach returned 5 > > pcib7: at device 0.3 on pci1 > > pci7: on pcib7 > > pcib8: at device 4.0 on pci0 > > pci8: on pcib8 > > pcib9: at device 6.0 on pci0 > > pci9: on pcib9 > > pcib10: at device 0.0 on pci9 > > pci10: on pcib10 > > arcmsr0: > (RAID6 capable) > > > mem 0xd8900000-0xd8900fff,0xd8000000-0xd83fffff irq > > 16 at device 14.0 on > > pci10 > > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 > 2007-10-07 > > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 > > arcmsr0: [ITHREAD] > > pcib11: at device 0.2 on pci9 > > pci11: on pcib11 > > pcib12: irq 17 at device 28.0 on pci0 > > pci12: on pcib12 > > uhci0: > USB-1> port 0x1800-0x181f > > irq 17 at device 29.0 on pci0 > > uhci0: [GIANT-LOCKED] > > uhci0: [ITHREAD] > > usb0: on > uhci0 > > usb0: USB revision 1.0 > > uhub0: > addr 1> on usb0 > > uhub0: 2 ports with 2 removable, self powered > > uhci1: > USB-2> port 0x1820-0x183f > > irq 19 at device 29.1 on pci0 > > uhci1: [GIANT-LOCKED] > > uhci1: [ITHREAD] > > usb1: on > uhci1 > > usb1: USB revision 1.0 > > uhub1: > addr 1> on usb1 > > uhub1: 2 ports with 2 removable, self powered > > uhci2: > USB-3> port 0x1840-0x185f > > irq 18 at device 29.2 on pci0 > > uhci2: [GIANT-LOCKED] > > uhci2: [ITHREAD] > > usb2: on > uhci2 > > usb2: USB revision 1.0 > > uhub2: > addr 1> on usb2 > > uhub2: 2 ports with 2 removable, self powered > > ehci0: mem > > 0xd8c00000-0xd8c003ff irq 17 > > at device 29.7 on pci0 > > ehci0: [GIANT-LOCKED] > > ehci0: [ITHREAD] > > usb3: EHCI version 1.0 > > usb3: companion controllers, 2 ports each: usb0 usb1 usb2 > > usb3: on ehci0 > > usb3: USB revision 2.0 > > uhub3: > addr 1> on usb3 > > uhub3: 6 ports with 6 removable, self powered > > pcib13: at device 30.0 on pci0 > > pci13: on pcib13 > > vgapci0: port 0x4000-0x40ff mem > > 0xd0000000-0xd7ffffff,0xd8800000-0xd880ffff irq 18 at > > device 1.0 on pci13 > > isab0: at device 31.0 on pci0 > > isa0: on isab0 > > atapci0: port > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at > > device 31.1 on pci0 > > ata0: on atapci0 > > ata0: [ITHREAD] > > pci0: at device 31.3 (no driver attached) > > acpi_button0: on acpi0 > > atkbdc0: port 0x60,0x64 > > irq 1 on acpi0 > > atkbd0: irq 1 on atkbdc0 > > kbd0 at atkbd0 > > atkbd0: [GIANT-LOCKED] > > atkbd0: [ITHREAD] > > psm0: irq 12 on atkbdc0 > > psm0: [GIANT-LOCKED] > > psm0: [ITHREAD] > > psm0: model Generic PS/2 mouse, device ID 0 > > sio0: configured irq 4 not in bitmap of probed irqs 0 > > sio0: port may not be enabled > > sio0: configured irq 4 not in bitmap of probed irqs 0 > > sio0: port may not be enabled > > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq > > 4 flags 0x10 on > > acpi0 > > sio0: type 16550A > > sio0: [FILTER] > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > sio1: port may not be enabled > > sio1: configured irq 3 not in bitmap of probed irqs 0 > > sio1: port may not be enabled > > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq > > 3 on acpi0 > > sio1: type 16550A > > sio1: [FILTER] > > fdc0: port 0x3f0-0x3f5,0x3f7 > > irq 6 drq 2 on acpi0 > > fdc0: [FILTER] > > ppc0: port 0x378-0x37f,0x778-0x77f irq > > 7 drq 3 on acpi0 > > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > > ppc0: FIFO with 16/16/9 bytes threshold > > ppbus0: on ppc0 > > ppbus0: [ITHREAD] > > plip0: on ppbus0 > > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag > > lpt0: on ppbus0 > > lpt0: Interrupt-driven port > > ppi0: on ppbus0 > > ppc0: [GIANT-LOCKED] > > ppc0: [ITHREAD] > > cpu0: on acpi0 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 728072806000728 > > device_attach: est0 attach returned 6 > > p4tcc0: on cpu0 > > cpu1: on acpi0 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 728072806000728 > > device_attach: est1 attach returned 6 > > p4tcc1: on cpu1 > > cpu2: on acpi0 > > est2: on cpu2 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 728072806000728 > > device_attach: est2 attach returned 6 > > p4tcc2: on cpu2 > > cpu3: on acpi0 > > est3: on cpu3 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 728072806000728 > > device_attach: est3 attach returned 6 > > p4tcc3: on cpu3 > > orm0: at iomem 0xc0000-0xcafff on isa0 > > sc0: at flags 0x100 on isa0 > > sc0: VGA <16 virtual consoles, flags=0x300> > > vga0: at port 0x3c0-0x3df iomem > > 0xa0000-0xbffff on isa0 > > Timecounters tick every 1.000 msec > > acd0: DVDR at ata0-master UDMA66 > > Waiting 5 seconds for SCSI devices to settle > > (probe46:arcmsr0:0:16:0): inquiry data fails comparison > > at DV1 step > > da0 at arcmsr0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access > > SCSI-5 device > > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > > da0: 77247MB (158201856 512 byte sectors: 255H 63S/T 9847C) > > da1 at arcmsr0 bus 0 target 1 lun 0 > > da1: Fixed Direct Access > > SCSI-5 device > > da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > > da1: 953673MB (1953122304 512 byte sectors: 255H 63S/T 121576C) > > da2 at arcmsr0 bus 0 target 2 lun 0 > > da2: Fixed Direct Access > > SCSI-5 device > > da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > > da2: 800131MB (1638669312 512 byte sectors: 255H 63S/T 102002C) > > sa0 at ahd1 bus 0 target 6 lun 0 > > sa0: Removable > > Sequential Access SCSI-2 > > device > > sa0: 10.000MB/s transfers (10.000MHz, offset 15) > > SMP: AP CPU #1 Launched! > > SMP: AP CPU #2 Launched! > > SMP: AP CPU #3 Launched! > > Trying to mount root from ufs:/dev/da0s1a > > This module (opensolaris) contains code covered by the > > Common Development and Distribution License (CDDL) > > see http://opensolaris.org/os/licensing/opensolaris_license/ > > WARNING: ZFS is considered to be an experimental > > feature in FreeBSD. > > ZFS filesystem version 6 > > ZFS storage pool version 6 > > em0: link state changed to UP > > bge0: link state changed to UP > > > > _______________________________________________ > > 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 cihangir at akademi.enderunix.org Wed Nov 26 00:15:05 2008 From: cihangir at akademi.enderunix.org (Cihangir Besiktas) Date: Wed Nov 26 00:15:12 2008 Subject: Measuring processes' bandwidth usage Message-ID: <20081126074819.74241.qmail@istanbul.enderunix.org> Hi, I am planning to develop a project, and in this project, there must be a module that outputs all the processes' bandwidth usage. How can I handle a process' bandwidth usage? I am looking forward to your advices. Thanks. Cihangir Besiktas ?stanbul Technical University Computer Eng Student http://www.students.itu.edu.tr/~besiktas Enderunix SDT | Student Participant in Google Summer of Code 2008 http://www.enderunix.org | http://code.google.com/soc/2008/ From yonyossef.lists at gmail.com Wed Nov 26 05:41:10 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Wed Nov 26 05:41:16 2008 Subject: TSO on VLAN interface, FreeBSD 7 In-Reply-To: <20def4870811260540x3d44a02bw43b6d18bc675de67@mail.gmail.com> References: <20def4870811260540x3d44a02bw43b6d18bc675de67@mail.gmail.com> Message-ID: <20def4870811260541x2f9bb410o44152a406407686@mail.gmail.com> Hi All, When I create a VLAN interface it does not inherit the parent interface capabilities. Is there a way to enable TSO (as other capabilities) on VLAN interfaces? Thanks, Yony From peterjeremy at optushome.com.au Wed Nov 26 10:08:37 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Nov 26 10:08:44 2008 Subject: Measuring processes' bandwidth usage In-Reply-To: <20081126074819.74241.qmail@istanbul.enderunix.org> References: <20081126074819.74241.qmail@istanbul.enderunix.org> Message-ID: <20081126180822.GF51761@server.vk2pj.dyndns.org> Hi Cihangir, On 2008-Nov-26 09:48:19 +0200, Cihangir Besiktas wrote: >I am planning to develop a project, and in this project, there must be a >module that outputs all the processes' bandwidth usage. How can I handle a >process' bandwidth usage? I am looking forward to your advices. Can you explain further what you mean by a "processes' bandwidth usage". The process-related information collected by the kernel is listed in getrusage(2). You might also like to look at ktrace(1,2). I suspect you may need to modify the kernel to capture the information you are looking for. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- 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/20081126/749990f4/attachment.pgp From linimon at FreeBSD.org Wed Nov 26 21:48:35 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Nov 26 21:48:42 2008 Subject: kern/129219: [ppp] Kernel panic when using kernel mode ppp Message-ID: <200811270548.mAR5mZhb019559@freefall.freebsd.org> Synopsis: [ppp] Kernel panic when using kernel mode ppp Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 27 05:48:22 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129219 From remko at FreeBSD.org Wed Nov 26 23:44:15 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Wed Nov 26 23:44:26 2008 Subject: bin/129218: [ipsec]: freebsd6.2 kernel cannot support ipsec "-E null -A hmac-sha1", FreeBSD7.0 kernel cannot support -A aes-xcbc-mac Message-ID: <200811270744.mAR7iFpI038586@freefall.freebsd.org> Old Synopsis: freebsd6.2 kernel cannot support ipsec "-E null -A hmac-sha1", FreeBSD7.0 kernel cannot support -A aes-xcbc-mac New Synopsis: [ipsec]: freebsd6.2 kernel cannot support ipsec "-E null -A hmac-sha1", FreeBSD7.0 kernel cannot support -A aes-xcbc-mac Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Thu Nov 27 07:43:48 UTC 2008 Responsible-Changed-Why: reassign to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=129218 From phoemix at harmless.hu Thu Nov 27 01:24:05 2008 From: phoemix at harmless.hu (Gergely CZUCZY) Date: Thu Nov 27 01:24:13 2008 Subject: TSO on VLAN interface, FreeBSD 7 In-Reply-To: <20def4870811260541x2f9bb410o44152a406407686@mail.gmail.com> References: <20def4870811260540x3d44a02bw43b6d18bc675de67@mail.gmail.com> <20def4870811260541x2f9bb410o44152a406407686@mail.gmail.com> Message-ID: <20081127100758.0000577c@unknown> Hello, I'd be also pretty interested in this one. And also, the question arises me for the very same issue, for LACP interfaces, and VLAN-over-LACP interfaces (lagg(4) as LACP). Having a gateway requires performances, and it often also means having VLANs, and LACP for failure tolerance. So I think this is a pretty important issue. On Wed, 26 Nov 2008 15:41:09 +0200 "Yony Yossef" wrote: > Hi All, > > When I create a VLAN interface it does not inherit the parent > interface capabilities. > Is there a way to enable TSO (as other capabilities) on VLAN > interfaces? > > Thanks, > Yony > _______________________________________________ > 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" -- Sincerely, Gergely CZUCZY Tel: +36-30-8414202 From jiabwang at redhat.com Thu Nov 27 01:30:04 2008 From: jiabwang at redhat.com (wang_jiabo) Date: Thu Nov 27 01:30:11 2008 Subject: i386/129218: freebsd6.2 kernel cannot support ipsec "-E null -A hmac-sha1", FreeBSD7.0 kernel cannot support -A aes-xcbc-mac Message-ID: <200811270930.mAR9U3dr015969@freefall.freebsd.org> The following reply was made to PR bin/129218; it has been noted by GNATS. From: wang_jiabo To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-i386@FreeBSD.org Cc: Subject: Re: i386/129218: freebsd6.2 kernel cannot support ipsec "-E null -A hmac-sha1", FreeBSD7.0 kernel cannot support -A aes-xcbc-mac Date: Thu, 27 Nov 2008 17:23:58 +0800 FreeBSD-gnats-submit@FreeBSD.org wrote: > Thank you very much for your problem report. > It has the internal identification `i386/129218'. > The individual assigned to look at your > report is: freebsd-i386. > > You can access the state of your problem report at any time > via this link: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=129218 > > >> Category: i386 >> Responsible: freebsd-i386 >> Synopsis: freebsd6.2 kernel cannot support ipsec "-E null -A hmac-sha1", FreeBSD7.0 kernel cannot support -A aes-xcbc-mac >> Arrival-Date: Thu Nov 27 03:10:01 UTC 2008 >> How to close the bug, I found that freebsd 6.3 can reslove the problem. but i do not know why FreeBSD7.0 can not support ipsec aes-xcbc-mac and null AH Thanks From remko at FreeBSD.org Thu Nov 27 01:55:19 2008 From: remko at FreeBSD.org (remko@FreeBSD.org) Date: Thu Nov 27 01:55:34 2008 Subject: bin/129218: [ipsec]: freebsd6.2 kernel cannot support ipsec "-E null -A hmac-sha1", FreeBSD7.0 kernel cannot support -A aes-xcbc-mac Message-ID: <200811270955.mAR9tHKT038352@freefall.freebsd.org> Synopsis: [ipsec]: freebsd6.2 kernel cannot support ipsec "-E null -A hmac-sha1", FreeBSD7.0 kernel cannot support -A aes-xcbc-mac State-Changed-From-To: open->closed State-Changed-By: remko State-Changed-When: Thu Nov 27 09:55:17 UTC 2008 State-Changed-Why: Close per request of the submitter. the other question you have should be asked on the net@ mailinglist I think since this might be an implementation decision but isn't a bug just yet. Thanks for reporting and taking the time to make freebsd better. http://www.freebsd.org/cgi/query-pr.cgi?pr=129218 From ivoras at freebsd.org Thu Nov 27 02:28:14 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Nov 27 02:28:21 2008 Subject: TSO on VLAN interface, FreeBSD 7 In-Reply-To: <20081127100758.0000577c@unknown> References: <20def4870811260540x3d44a02bw43b6d18bc675de67@mail.gmail.com> <20def4870811260541x2f9bb410o44152a406407686@mail.gmail.com> <20081127100758.0000577c@unknown> Message-ID: Gergely CZUCZY wrote: > Hello, > > I'd be also pretty interested in this one. And also, the question > arises me for the very same issue, for LACP interfaces, and > VLAN-over-LACP interfaces (lagg(4) as LACP). > Having a gateway requires performances, and it often also means having > VLANs, and LACP for failure tolerance. So I think this is a pretty > important issue. > > On Wed, 26 Nov 2008 15:41:09 +0200 > "Yony Yossef" wrote: > >> Hi All, >> >> When I create a VLAN interface it does not inherit the parent >> interface capabilities. >> Is there a way to enable TSO (as other capabilities) on VLAN >> interfaces? It will probably be implemented in the future: http://lists.freebsd.org/pipermail/freebsd-net/2008-October/019729.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20081127/fe6a2fd3/signature.pgp From gergely.czuczy at harmless.hu Thu Nov 27 04:03:13 2008 From: gergely.czuczy at harmless.hu (Gergely CZUCZY) Date: Thu Nov 27 04:03:20 2008 Subject: TSO on VLAN interface, FreeBSD 7 In-Reply-To: References: <20def4870811260540x3d44a02bw43b6d18bc675de67@mail.gmail.com> <20def4870811260541x2f9bb410o44152a406407686@mail.gmail.com> <20081127100758.0000577c@unknown> Message-ID: <20081127130310.00006eaf@unknown> And an other question. For now, if these options are manually set for the derived interfaces, will that work? On Thu, 27 Nov 2008 11:28:05 +0100 Ivan Voras wrote: > Gergely CZUCZY wrote: > > Hello, > > > > I'd be also pretty interested in this one. And also, the question > > arises me for the very same issue, for LACP interfaces, and > > VLAN-over-LACP interfaces (lagg(4) as LACP). > > Having a gateway requires performances, and it often also means > > having VLANs, and LACP for failure tolerance. So I think this is a > > pretty important issue. > > > > On Wed, 26 Nov 2008 15:41:09 +0200 > > "Yony Yossef" wrote: > > > >> Hi All, > >> > >> When I create a VLAN interface it does not inherit the parent > >> interface capabilities. > >> Is there a way to enable TSO (as other capabilities) on VLAN > >> interfaces? > > It will probably be implemented in the future: > http://lists.freebsd.org/pipermail/freebsd-net/2008-October/019729.html > > -- Sincerely, Gergely CZUCZY Tel: +36-30-8414202 From dave.edwards at adelaide.on.net Thu Nov 27 04:13:20 2008 From: dave.edwards at adelaide.on.net (Dave Edwards) Date: Thu Nov 27 04:13:26 2008 Subject: nmap on FreeBSD 7.0-RELEASE Message-ID: <492E8B52.9010408@adelaide.on.net> Hi, I'm having some problems with nmap over the tun device. I connect to the net using ppp and pppoe (adsl) which creates the "tun0" device. My default route goes out that way. Using nmap to try to map an external host: ------------------------- # nmap -vvv -e tun0 -sS -p80,443 1.2.3.4 Starting Nmap 4.76 ( http://nmap.org ) at 2008-11-27 22:05 CST WARNING: Unable to find appropriate interface for system route to 1.2.3.4 nexthost: failed to determine route to 1.2.3.4 QUITTING! -------------------------- This only seems to occur when running nmap as root. As a normal user (using the "connect" scan option) it seems to work ok, but you can only run a SYN scan (or force a specific source port) as root. I think this means that the problem may be related to using a raw socket.. I have the same problem with nmapping over a VPN tunnel as well (another tun device) so I don't think it's the configuration of the ppp session. As root, nmap finds the following interface list (note the missing default route) -------------------------- $ nmap --iflist Starting Nmap 4.76 ( http://nmap.org ) at 2008-11-27 22:00 CST ************************INTERFACES************************ DEV (SHORT) IP/MASK TYPE UP MAC rl0 (rl0) x.x.x.x ethernet up 00:00:E8:7A:EE:1C re0 (re0) x.x.x.x ethernet up 00:E0:4C:50:19:8F lo0 (lo0) 127.0.0.1/8 loopback up tun0 (tun0) x.x.x.x/32 point2point up WARNING: Unable to find appropriate interface for system route to 203.16.215.186 **************************ROUTES************************** DST/MASK DEV GATEWAY 127.0.0.1/32 lo0 127.0.0.1 203.16.215.186/32 tun0 x.x.x.x -------------------------- I've tried creating a host route for the nmap target instead of relying on the default route and I've tried three other versions of nmap. As an aside (or maybe a hint) when compiling nmap from source, there are a number of warnings like: ------------------------ checking net/route.h presence... yes configure: WARNING: net/route.h: present but cannot be compiled configure: WARNING: net/route.h: check for missing prerequisite headers? configure: WARNING: net/route.h: see the Autoconf documentation configure: WARNING: net/route.h: section "Present But Cannot Be Compiled" configure: WARNING: net/route.h: proceeding with the preprocessor's result configure: WARNING: net/route.h: in the future, the compiler will take precedence checking for net/route.h... yes ------------------------- Google has let me down this time. There are a few comments about nmap and FreeBSD but nothing that seems helpful and they are mostly fairly old. Anyone got a clue for me? davo From yonyossef.lists at gmail.com Thu Nov 27 04:41:38 2008 From: yonyossef.lists at gmail.com (Yony Yossef) Date: Thu Nov 27 04:41:44 2008 Subject: IFCAP_LRO on FreeBSD 7 Message-ID: <20def4870811270441n6b201076k715e1c7e1adc8781@mail.gmail.com> Hi All, Is there a native interface for LRO in FreeBSD 7? I can't find any use for IFCAP_LRO but notifying the driver if to use or not to use this offload. If not, is it planned for FreeBSD 8? Thanks Yony From rwatson at FreeBSD.org Thu Nov 27 04:51:29 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Nov 27 04:51:40 2008 Subject: IFCAP_LRO on FreeBSD 7 In-Reply-To: <20def4870811270441n6b201076k715e1c7e1adc8781@mail.gmail.com> References: <20def4870811270441n6b201076k715e1c7e1adc8781@mail.gmail.com> Message-ID: On Thu, 27 Nov 2008, Yony Yossef wrote: > Is there a native interface for LRO in FreeBSD 7? I can't find any use for > IFCAP_LRO but notifying the driver if to use or not to use this offload. > > If not, is it planned for FreeBSD 8? IFCAP_LRO is a capability/policy flag allowing drivers to declare support for LRO, and for administrators to enable/disable it if present. Drivers can either provide their own implementation (mxge, nxge) or use the system implementation (cxgb, igb). I'm slightly surprised to see that igb references tcp_lro_init() but not IFCAP_LRO -- perhaps lro isn't yet fully hooked up, or perhaps there's a bug? I believe all of the above applies to 7.1 but not 7.0, except possibly mxge supporting LRO in 7.0. Robert N M Watson Computer Laboratory University of Cambridge From chflags at gmail.com Thu Nov 27 04:54:03 2008 From: chflags at gmail.com (Kevin Foo) Date: Thu Nov 27 04:54:10 2008 Subject: if_bridge + pf rdr (bridged inline proxy) Message-ID: <25cb30811270426i6b5cc4c2s49030f64d06b0ec8@mail.gmail.com> Hi list, I recently setup a bridge box with inline cache proxy. if_bridge with pf filtering was working perfectly. However, squid-cache listening on loopback device did not get any packets from pf rdr. I have seen successful setups with OpenBSD's bridge spamd which rather a similar setup. Is something broken on FreeBSD's if_bridge or am I missing some configuration here? pfctl -ss (on bridge box): ------------------ all tcp 127.0.0.1:3128 <- 71.14.235.147:80 <- 192.168.1.100:1041 CLOSED:SYN_SENT all tcp 192.168.1.100:1041 -> 127.0.0.1:3128 SYN_SENT:CLOSED Environment ------------------ FreeBSD bridge.mybox 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Nov 25 22:56:22 MYT 2008 kev@bridge.mybox:/usr/obj/usr/src/sys/BRIDGE i386 Squid Cache: Version 2.7.STABLE5 with --enable-pf-transparent rc.conf: ------------------ cloned_interfaces="bridge0" ifconfig_bridge0="addm bge0 addm bge1 up" ifconfig_bge0="up" ifconfig_bge1="up" pf_enable="YES" squid_enabld="YES" pf.conf: ------------------ int_if="bge0" ext_if="bge1" rdr pass on $int_if inet proto tcp from any to any port 80 -> 127.0.0.1 port 3128 pass in all pass out all pass on $int_if route-to lo0 proto tcp from any to 127.0.0.1 port 3128 sysctl net.link.bridge : ------------------ net.link.bridge.ipfw: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 1 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 0 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 0 Hping Testing (from client 192.168.1.100): ------------------ hping -S -p 80 -c 10 www.google.com A quick search on freebsd-pf archive, I found a thread on similar setup in 2004. http://lists.freebsd.org/pipermail/freebsd-pf/2004-October/000522.html However, the bridge code of FreeBSD was blamed for poor performance and lack of functionalities. A more recent post on freebsd-net mailing list on similar issue. http://lists.freebsd.org/pipermail/freebsd-net/2008-September/019556.html Any ideas? TIA. P/S : please cc me as I'm not subscribed to freebsd-pf nor freebsd-net mailing list. Thanks. -- Regards Kevin Foo From rea-fbsd at codelabs.ru Thu Nov 27 05:57:06 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Nov 27 05:57:12 2008 Subject: nmap on FreeBSD 7.0-RELEASE In-Reply-To: <492E8B52.9010408@adelaide.on.net> References: <492E8B52.9010408@adelaide.on.net> Message-ID: <4CREIW43kKwxaB43gZShXkxNn3U@2DcjJpvUBcA8GzIZe2t/Ulo9G+Y> Dave, good day. Thu, Nov 27, 2008 at 10:28:10PM +1030, Dave Edwards wrote: > I've tried creating a host route for the nmap target instead of relying > on the default route and I've tried three other versions of nmap. As an > aside (or maybe a hint) when compiling nmap from source, there are a > number of warnings like: > ------------------------ > checking net/route.h presence... yes > configure: WARNING: net/route.h: present but cannot be compiled > configure: WARNING: net/route.h: check for missing prerequisite headers? > configure: WARNING: net/route.h: see the Autoconf documentation > configure: WARNING: net/route.h: section "Present But Cannot Be > Compiled" > configure: WARNING: net/route.h: proceeding with the preprocessor's result > configure: WARNING: net/route.h: in the future, the compiler will take > precedence > checking for net/route.h... yes > ------------------------- Could you, please, post the accompanying config.log that was produced by configure and the configure script itself? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- 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/20081127/5c1c58d1/attachment.pgp From rea-fbsd at codelabs.ru Thu Nov 27 06:00:17 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Nov 27 06:00:24 2008 Subject: if_bridge + pf rdr (bridged inline proxy) In-Reply-To: <25cb30811270426i6b5cc4c2s49030f64d06b0ec8@mail.gmail.com> References: <25cb30811270426i6b5cc4c2s49030f64d06b0ec8@mail.gmail.com> Message-ID: Kevin, good day. Thu, Nov 27, 2008 at 08:26:55PM +0800, Kevin Foo wrote: > I recently setup a bridge box with inline cache proxy. if_bridge with > pf filtering was working perfectly. However, squid-cache listening on > loopback device did not get any packets from pf rdr. I have seen > successful setups with OpenBSD's bridge spamd which rather a similar > setup. Is something broken on FreeBSD's if_bridge or am I missing some > configuration here? pf can 'rdr' only incoming packets (from 'man pf.conf'): ----- Evaluation order of the translation rules is dependent on the type of the translation rules and of the direction of a packet. binat rules are always evaluated first. Then either the rdr rules are evaluated on an inbound packet or the nat rules on an outbound packet. Rules of the same type are evaluated in the same order in which they appear in the ruleset. The first matching rule decides what action is taken. ----- So this can be just pf-related. And may be not, as usual... -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- 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/20081127/edec6a87/attachment.pgp From dwmalone at maths.tcd.ie Thu Nov 27 06:03:26 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Thu Nov 27 06:03:34 2008 Subject: FreeBSD Window updates Message-ID: <200811271403.aa55110@walton.maths.tcd.ie> I was looking at some tcpdumps from a FreeBSD box receiving a TCP stream with someone yesterday and noticed that it seemed to be generating quite a lot of dupliacte acks. Looking more carefully, we noticed that the duplicates were actually window updates. The code for sending window updates can be found in: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c?annot ate=1.157 around lines 541-565. It seems that we generate a window update if the available buffer space changes by more than two packets, or if it changes by more than half the buffer size. This is probably a little aggressive, and in some cases seems to result in bursts of window updates that look like they should be batched. I wonder if it would make sense to not do a window update if a delayed ack is scheduled? It might even be possible to do them as a delayed ack without causing problems. I note that there is at least one PR mentioning we generate many window updates: http://www.freebsd.org/cgi/query-pr.cgi?pr=116335 I also wonder if it might cause non-FreeBSD senders to back off, we are careful not to retransmit if we get window updates (see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c?annota te=1.392 about line 1836, but other OSes might not be and that might degrade our performance when receiving from a non-FreeBSD sender. David. From frank at harz.behrens.de Thu Nov 27 06:25:46 2008 From: frank at harz.behrens.de (Frank Behrens) Date: Thu Nov 27 06:25:53 2008 Subject: Problem with new source address selection (was Anyone interested in jail patches?) In-Reply-To: <20081126234502.S61259@maildrop.int.zabbadoz.net> Message-ID: <200811271425.mAREPSwm004057@post.behrens.de> Bjoern A. Zeeb wrote on 26 Nov 2008 23:56: > If you are interested in a new set of jail patches... anyone?;-) Yes, but about jail specific things I'll write later, in another mail and on another list. > 2b) for RELENG_7: > http://people.freebsd.org/~bz/bz_jail7-20081126-02-at153644.diff With this patch I received a new source selection implementation, I believe the same as announced for HEAD. Here I found a problem. One of my machines tunnels a private subnet via IPSEC (esp/tunnel). Lets assume my private subnet is 192.168.90.0/24 and the "foreign" subnet is 192.168.200.0/24. When I send packets via this tunnel I must ensure the right source address, because the machine has several interfaces. (BTW: this is so easy with openvpn and real routing, but sometimes other people decide..) An easy solution was for me ifconfig lo2 inet 192.168.90.254/32 route add -net 192.168.200.0/24 -iface lo2 The route is a "dummy" route only, because the IPSEC SPD determines the packet flow. This worked well in the past, but not with your patch. On connect(2) call for the tunneled subnet I receive always "Network unreachable". The following _wild hack_(tm) solves the problem _for me_, it is only to show the problem to you: --- sys/netinet/in_pcb.c.orig 2008-11-27 14:57:25.887082927 +0100 +++ sys/netinet/in_pcb.c 2008-11-27 14:29:28.918257601 +0100 @@ -697,6 +697,9 @@ in_pcbladdr(struct inpcb *inp, struct in ia = ifatoia(ifa_ifwithnet(sintosa(&sain))); if (cred == NULL || !jailed(cred)) { +// FB2008-11-27 + ia = (struct in_ifaddr *)sro.ro_rt->rt_ifa; +// FB if (ia == NULL) { error = ENETUNREACH; goto done; Can you provide a patch to solve the connect problem? Is there a better solution to setup source address selection for IPSEC tunnels? Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From bzeeb-lists at lists.zabbadoz.net Thu Nov 27 06:55:08 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Nov 27 06:55:18 2008 Subject: Problem with new source address selection (was Anyone interested in jail patches?) In-Reply-To: <200811271425.mAREPSwm004057@post.behrens.de> References: <200811271425.mAREPSwm004057@post.behrens.de> Message-ID: <20081127143300.M61259@maildrop.int.zabbadoz.net> On Thu, 27 Nov 2008, Frank Behrens wrote: >> 2b) for RELENG_7: >> http://people.freebsd.org/~bz/bz_jail7-20081126-02-at153644.diff > > With this patch I received a new source selection implementation, I > believe the same as announced for HEAD. Here I found a problem. HEAD has had it since beginning of October and older jail patches also had it for a while now. > One of my machines tunnels a private subnet via IPSEC (esp/tunnel). > Lets assume my private subnet is 192.168.90.0/24 and the "foreign" > subnet is 192.168.200.0/24. When I send packets via this tunnel I > must ensure the right source address, because the machine has several > interfaces. (BTW: this is so easy with openvpn and real routing, but > sometimes other people decide..) An easy solution was for me > ifconfig lo2 inet 192.168.90.254/32 > route add -net 192.168.200.0/24 -iface lo2 > The route is a "dummy" route only, because the IPSEC SPD determines > the packet flow. Yes I know that hack though I never actually used it with a loopback as the loopback case is *uhm* gross. You know you are telling the kernel to actually send the packets to yourself which so far has just worked more or less out of luck in my eyes. So is your 192.168.90.0/24 on any other interface but the lo2? Is it the only network on that interface or are there aliases? > This worked well in the past, but not with your patch. On connect(2) > call for the tunneled subnet I receive always "Network unreachable". > The following _wild hack_(tm) solves the problem _for me_, it is only > to show the problem to you: >From the code down I take it that the connect(2) call happens outside any jail and not within a jail, right? > --- sys/netinet/in_pcb.c.orig 2008-11-27 14:57:25.887082927 +0100 > +++ sys/netinet/in_pcb.c 2008-11-27 14:29:28.918257601 +0100 > @@ -697,6 +697,9 @@ in_pcbladdr(struct inpcb *inp, struct in > ia = ifatoia(ifa_ifwithnet(sintosa(&sain))); > > if (cred == NULL || !jailed(cred)) { > +// FB2008-11-27 > + ia = (struct in_ifaddr *)sro.ro_rt->rt_ifa; > +// FB > if (ia == NULL) { > error = ENETUNREACH; > goto done; > > Can you provide a patch to solve the connect problem? > Is there a better solution to setup source address selection for > IPSEC tunnels? Let me answer those later; in case you cannot reveal your network setup in public; contact me offlist. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From frank at harz.behrens.de Thu Nov 27 07:42:48 2008 From: frank at harz.behrens.de (Frank Behrens) Date: Thu Nov 27 07:42:55 2008 Subject: Problem with new source address selection In-Reply-To: <20081127143300.M61259@maildrop.int.zabbadoz.net> References: <200811271425.mAREPSwm004057@post.behrens.de> Message-ID: <200811271542.mARFgglB004902@post.behrens.de> Bjoern, thanks for your fast answer. Bjoern A. Zeeb wrote on 27 Nov 2008 14:53: > Yes I know that hack though I never actually used it with a loopback > as the loopback case is *uhm* gross. You know you are telling the > kernel to actually send the packets to yourself which so far has just > worked more or less out of luck in my eyes. IMHO here we see again the main problem of IPSEC. Suddenly packets disappear in kernel, are tunneled with ipsec and appear on other end. A gif-like device with routes instead of SPD entries would have some advantages. > So is your 192.168.90.0/24 on any other interface but the lo2? > Is it the only network on that interface or are there aliases? For this machine the simplified setup is: - an ethernet interface for private net with address 192.168.90.1/24 and additional aliases for external addresses - several tun devices with external and private addresses and routes - lo0 as real loopback device with 127.0.0.1/8 - lo1 with private jail addresses Now I want to tunnel between my 192.168.90.0/24 and a foreign 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created a static route. > From the code down I take it that the connect(2) call happens outside > any jail and not within a jail, right? Yes, this is outside a jail. With jails I had no problems, every jail has currently one ipv4 and one ipv6 address. > Let me answer those later; in case you cannot reveal your network > setup in public; contact me offlist. If desired I could send you the complete interface and routing table. But I believe you should be able to see the problem with my example above. Thanks for sour support, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From bzeeb-lists at lists.zabbadoz.net Thu Nov 27 08:50:07 2008 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Thu Nov 27 08:50:14 2008 Subject: Problem with new source address selection In-Reply-To: <200811271542.mARFgglB004902@post.behrens.de> References: <200811271425.mAREPSwm004057@post.behrens.de> <200811271542.mARFgglB004902@post.behrens.de> Message-ID: <20081127164201.M61259@maildrop.int.zabbadoz.net> On Thu, 27 Nov 2008, Frank Behrens wrote: Hi, I am running out the door but ... will check again tonight. > Bjoern A. Zeeb wrote on 27 Nov 2008 14:53: [gif-like ipsec and routes] routes are not alternatives for fixing applications;) Often it's easier to apply a hack instead of fix the application but that's a different story... >> So is your 192.168.90.0/24 on any other interface but the lo2? >> Is it the only network on that interface or are there aliases? > > For this machine the simplified setup is: > - an ethernet interface for private net with address 192.168.90.1/24 > and additional aliases for external addresses ... > Now I want to tunnel between my 192.168.90.0/24 and a foreign > 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created > a static route. So if you don't mind to go out with a source address of 192.168.90.1 instead of .254, what about this hack. What happens if you change the route to route change -net 192.168.200.0/24 192.168.90.2 (assuming the .2 is not on your local machine). /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From frank at harz.behrens.de Thu Nov 27 09:09:14 2008 From: frank at harz.behrens.de (Frank Behrens) Date: Thu Nov 27 09:09:21 2008 Subject: Problem with new source address selection In-Reply-To: <20081127164201.M61259@maildrop.int.zabbadoz.net> References: <200811271542.mARFgglB004902@post.behrens.de> Message-ID: <200811271709.mARH99HH009871@post.behrens.de> Bjoern A. Zeeb wrote on 27 Nov 2008 16:47: > I am running out the door but ... will check again tonight. Thanks! > So if you don't mind to go out with a source address of 192.168.90.1 > instead of .254, what about this hack. What happens if you change the > route to > route change -net 192.168.200.0/24 192.168.90.2 > (assuming the .2 is not on your local machine). Hm, looks fine. I thought there must be another way for address selection. :-) Thanks for your idea, I'll test this and report. -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From jfvogel at gmail.com Thu Nov 27 11:43:33 2008 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Nov 27 11:43:39 2008 Subject: IFCAP_LRO on FreeBSD 7 In-Reply-To: References: <20def4870811270441n6b201076k715e1c7e1adc8781@mail.gmail.com> Message-ID: <2a41acea0811271143q25f83e89i4df2791052a980ac@mail.gmail.com> On Thu, Nov 27, 2008 at 4:51 AM, Robert Watson wrote: > > On Thu, 27 Nov 2008, Yony Yossef wrote: > > Is there a native interface for LRO in FreeBSD 7? I can't find any use for >> IFCAP_LRO but notifying the driver if to use or not to use this offload. >> >> If not, is it planned for FreeBSD 8? >> > > IFCAP_LRO is a capability/policy flag allowing drivers to declare support > for LRO, and for administrators to enable/disable it if present. Drivers > can either provide their own implementation (mxge, nxge) or use the system > implementation (cxgb, igb). I'm slightly surprised to see that igb > references tcp_lro_init() but not IFCAP_LRO -- perhaps lro isn't yet fully > hooked up, or perhaps there's a bug? I believe all of the above applies to > 7.1 but not 7.0, except possibly mxge supporting LRO in 7.0. > Been so busy internally that I did not even realize that this capability had been created, I need to change both igb and ixgbe to use it. Thanks for pointing this out, Jack From chflags at gmail.com Thu Nov 27 21:29:36 2008 From: chflags at gmail.com (Kevin Foo) Date: Thu Nov 27 21:29:48 2008 Subject: if_bridge + pf rdr (bridged inline proxy) In-Reply-To: References: <25cb30811270426i6b5cc4c2s49030f64d06b0ec8@mail.gmail.com> Message-ID: <25cb30811272129h68e50bf4u46b15823b101a3@mail.gmail.com> Thank Eygene for the reply. It might be but I'm not sure. Anyone is having the same setting or any info on this? -- Regards Kevin Foo On Thu, Nov 27, 2008 at 10:00 PM, Eygene Ryabinkin wrote: > Kevin, good day. > > Thu, Nov 27, 2008 at 08:26:55PM +0800, Kevin Foo wrote: >> I recently setup a bridge box with inline cache proxy. if_bridge with >> pf filtering was working perfectly. However, squid-cache listening on >> loopback device did not get any packets from pf rdr. I have seen >> successful setups with OpenBSD's bridge spamd which rather a similar >> setup. Is something broken on FreeBSD's if_bridge or am I missing some >> configuration here? > > pf can 'rdr' only incoming packets (from 'man pf.conf'): > ----- > Evaluation order of the translation rules is dependent on the type of the > translation rules and of the direction of a packet. binat rules are > always evaluated first. Then either the rdr rules are evaluated on an > inbound packet or the nat rules on an outbound packet. Rules of the same > type are evaluated in the same order in which they appear in the ruleset. > The first matching rule decides what action is taken. > ----- > So this can be just pf-related. And may be not, as usual... > -- > Eygene > _ ___ _.--. # > \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard > / ' ` , __.--' # to read the on-line manual > )/' _/ \ `-_, / # while single-stepping the kernel. > `-'" `"\_ ,_.-;_.-\_ ', fsc/as # > _.-'_./ {_.' ; / # -- FreeBSD Developers handbook > {_.-``-' {_/ # > From frank at harz.behrens.de Thu Nov 27 22:53:11 2008 From: frank at harz.behrens.de (Frank Behrens) Date: Thu Nov 27 22:53:18 2008 Subject: Problem with new source address selection In-Reply-To: <20081127164201.M61259@maildrop.int.zabbadoz.net> References: <200811271542.mARFgglB004902@post.behrens.de> Message-ID: <200811280653.mAS6r1P3014050@post.behrens.de> Bjoern A. Zeeb wrote on 27 Nov 2008 16:47: > > Now I want to tunnel between my 192.168.90.0/24 and a foreign > > 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created > > a static route. > > So if you don't mind to go out with a source address of 192.168.90.1 > instead of .254, what about this hack. What happens if you change the > route to > route change -net 192.168.200.0/24 192.168.90.2 > (assuming the .2 is not on your local machine). That works for the router, but for incoming packets on the internal interface (from -net 192.168.90.0/24) the machine will send an ICMP redirect to new router 192.168.90.2. Of course that is a black hole. When I use the route to own interface address (route change -net 192.168.200.0/24 192.168.90.1) it works, but also for every incoming packet an ICMP redirect is sent. So that solution is a workaround for short time only. Does anybody have a better solution for source address selection? Am I the only one with an IPSEC tunnel? -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From freebsd.alex at spamfoodie.com Fri Nov 28 04:30:05 2008 From: freebsd.alex at spamfoodie.com (Alex) Date: Fri Nov 28 04:30:11 2008 Subject: kern/129022: [ath] ath cannot connect using WEP Message-ID: <200811281230.mASCU44Z058145@freefall.freebsd.org> The following reply was made to PR kern/129022; it has been noted by GNATS. From: Alex To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/129022: [ath] ath cannot connect using WEP Date: Fri, 28 Nov 2008 12:26:59 GMT >Submitter-Id: current-users >Originator: Alex >Organization: >Confidential: no >Synopsis: Re: kern/129022: [ath] ath cannot connect using WEP >Severity: serious >Priority: high >Category: kern >Class: sw-bug >Release: 8-CURRENT >Environment: FreeBSD moshnroll 8.0-CURRENT FreeBSD 8.0-CURRENT #8 r185353M: Thu Nov 27 01:48:42 CET 2008 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 >Description: could somebody please have a look at this? just tell me if you need more debug output and i'll provide it. right now i have to connect to my router using no encryption at all which obviously is far from save. thanks in advance. >How-To-Repeat: >Fix: From rpaulo at fnop.net Fri Nov 28 07:36:51 2008 From: rpaulo at fnop.net (Rui Paulo) Date: Fri Nov 28 07:36:57 2008 Subject: FreeBSD Window updates In-Reply-To: <200811271403.aa55110@walton.maths.tcd.ie> References: <200811271403.aa55110@walton.maths.tcd.ie> Message-ID: <457EB70C-A3E6-4B3A-A707-CDE62FD2E8E0@fnop.net> On 27 Nov 2008, at 14:03, David Malone wrote: > I was looking at some tcpdumps from a FreeBSD box receiving a TCP > stream with someone yesterday and noticed that it seemed to be > generating quite a lot of dupliacte acks. Looking more carefully, > we noticed that the duplicates were actually window updates. The > code for sending window updates can be found in: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c?annot > ate=1.157 > > around lines 541-565. It seems that we generate a window update if > the available buffer space changes by more than two packets, or if > it changes by more than half the buffer size. This is probably a > little aggressive, and in some cases seems to result in bursts of > window updates that look like they should be batched. I wonder if > it would make sense to not do a window update if a delayed ack is > scheduled? It might even be possible to do them as a delayed ack > without causing problems. Yes, this makes sense. Probably this is a bug since 4.4BSD-Lite. > I note that there is at least one PR mentioning we generate many > window updates: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=116335 > > I also wonder if it might cause non-FreeBSD senders to back off, > we are careful not to retransmit if we get window updates (see > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c?annota > te=1.392 > > about line 1836, but other OSes might not be and that might degrade > our performance when receiving from a non-FreeBSD sender. So, from what I understand, we do back off and that implies we are losing performance in the FreeBSD to FreeBSD case, right? -- Rui Paulo From venkatvenkatsubra at yahoo.com Fri Nov 28 08:53:04 2008 From: venkatvenkatsubra at yahoo.com (Venkat Venkatsubra) Date: Fri Nov 28 08:53:11 2008 Subject: FreeBSD Window updates References: <200811271403.aa55110@walton.maths.tcd.ie> <457EB70C-A3E6-4B3A-A707-CDE62FD2E8E0@fnop.net> Message-ID: <725753.56771.qm@web58304.mail.re3.yahoo.com> By backoff if you are referring to sender side mistakenly counting the window updates for?a "fastretransmit" on a count of 3 dup acks, isn't the following in tcp_input.c taking care of it ? [Only when twin == tp->snd_wnd it is counted as a dup ack.] 1836 if (SEQ_LEQ(th->th_ack, tp->snd_una)) { 1837 if (tlen == 0 && tiwin == tp->snd_wnd) { 1838 V_tcpstat.tcps_rcvdupack++; 1839 /* 1840 * If we have outstanding data (other than 1841 * a window probe), this is a completely 1842 * duplicate ack (ie, window info didn't 1843 * change), the ack is the biggest we've 1844 * seen and we've seen exactly our rexmt 1845 * threshhold of them, assume a packet 1846 * has been dropped and retransmit it. 1847 * Kludge snd_nxt & the congestion 1848 * window so we send only this one 1849 * packet. 1850 * How many acks do you see for every 2 full-sized segments received ? 2 or 1 ? At least one ack needs to go out for every 2 incoming segments as per the rfc. Associating window updates with delayed ack?was not clear to me. If I see the tcpdump output I might understand better. Venkat ________________________________ From: Rui Paulo To: David Malone Cc: freebsd-net@freebsd.org; Kevin Oberman Sent: Friday, November 28, 2008 9:36:45 AM Subject: Re: FreeBSD Window updates On 27 Nov 2008, at 14:03, David Malone wrote: > I was looking at some tcpdumps from a FreeBSD box receiving a TCP > stream with someone yesterday and noticed that it seemed to be > generating quite a lot of dupliacte acks. Looking more carefully, > we noticed that the duplicates were actually window updates. The > code for sending window updates can be found in: > > ??? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_output.c?annot > ate=1.157 > > around lines 541-565. It seems that we generate a window update if > the available buffer space changes by more than two packets, or if > it changes by more than half the buffer size. This is probably a > little aggressive, and in some cases seems to result in bursts of > window updates that look like they should be batched. I wonder if > it would make sense to not do a window update if a delayed ack is > scheduled? It might even be possible to do them as a delayed ack > without causing problems. Yes, this makes sense. Probably this is a bug since 4.4BSD-Lite. > I note that there is at least one PR mentioning we generate many > window updates: > > ??? http://www.freebsd.org/cgi/query-pr.cgi?pr=116335 > > I also wonder if it might cause non-FreeBSD senders to back off, > we are careful not to retransmit if we get window updates (see > > ??? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c?annota > te=1.392 > > about line 1836, but other OSes might not be and that might degrade > our performance when receiving from a non-FreeBSD sender. So, from what I understand, we do back off and that implies we are? losing performance in the FreeBSD to FreeBSD case, right? -- 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" From sam at FreeBSD.org Fri Nov 28 10:14:15 2008 From: sam at FreeBSD.org (sam@FreeBSD.org) Date: Fri Nov 28 10:14:21 2008 Subject: kern/129022: [ath] ath cannot connect using WEP Message-ID: <200811281814.mASIEEli022242@freefall.freebsd.org> Synopsis: [ath] ath cannot connect using WEP Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Fri Nov 28 18:13:53 UTC 2008 Responsible-Changed-Why: didn't know this existed; will check http://www.freebsd.org/cgi/query-pr.cgi?pr=129022 From dwmalone at maths.tcd.ie Fri Nov 28 11:36:09 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Fri Nov 28 11:36:16 2008 Subject: FreeBSD Window updates In-Reply-To: Your message of "Fri, 28 Nov 2008 15:36:45 GMT." <457EB70C-A3E6-4B3A-A707-CDE62FD2E8E0@fnop.net> Message-ID: <200811281936.aa78374@walton.maths.tcd.ie> > Yes, this makes sense. Probably this is a bug since 4.4BSD-Lite. I had a look to see what Linux does - it only generates pure window updates in the case that the advertised window would change by a factor of two. I guess this practically eliminates these updates. I would guess that changing the code to update on a change of a power of two would be OK. Another option would be to change the current limit of two MSSes to three, because this would eliminate window updates between regular delayed ACKs. > So, from what I understand, we do back off and that implies we are > losing performance in the FreeBSD to FreeBSD case, right? We do the right thing and ignore these pure window updates. I've checked, and Linux also ignores ACKs that just seem to update the window. David. From mamruoc at gmail.com Fri Nov 28 12:40:48 2008 From: mamruoc at gmail.com (Mam Ruoc) Date: Fri Nov 28 12:41:20 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG Message-ID: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> Onboard LAN: VIA VT6122 GLAN Controller I have submitted a bug report, but has not heard anything, can anybody help me because this is a big showstopper! http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/129135 Mam Ruoc From kris at FreeBSD.org Fri Nov 28 18:00:07 2008 From: kris at FreeBSD.org (kris@FreeBSD.org) Date: Fri Nov 28 18:00:13 2008 Subject: kern/129074: [ppp] [panic] kernel panic with pppoe_server Message-ID: <200811290200.mAT205Ou016575@freefall.freebsd.org> Synopsis: [ppp] [panic] kernel panic with pppoe_server State-Changed-From-To: open->feedback State-Changed-By: kris State-Changed-When: Sat Nov 29 01:59:30 UTC 2008 State-Changed-Why: Please provide some details so we can begin to investigate your problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=129074 From pyunyh at gmail.com Fri Nov 28 23:02:04 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Nov 28 23:02:10 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> Message-ID: <20081129065950.GG99324@cdnetworks.co.kr> On Fri, Nov 28, 2008 at 09:20:35PM +0100, Mam Ruoc wrote: > Onboard LAN: VIA VT6122 GLAN Controller > > I have submitted a bug report, but has not heard anything, can anybody > help me because this is a big showstopper! > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/129135 > I think there was a similar report. Would you show me the output of "pciconf -lcv"? For a long time I wanted to clean up vge(4). Unfortunately the PCI NIC I have seem to broken so I guess it's hard to complete the cleanup. You can get a WIP(now stalled) in the following URL. Note, the driver may be chatty due to various debugging statements and it may not work at all for your controller. http://people.freebsd.org/~yongari/vge/if_vge.c http://people.freebsd.org/~yongari/vge/if_vgereg.h http://people.freebsd.org/~yongari/vge/if_vgevar.h -- Regards, Pyun YongHyeon From andrew at modulus.org Fri Nov 28 23:27:37 2008 From: andrew at modulus.org (Andrew Snow) Date: Fri Nov 28 23:27:45 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <20081129065950.GG99324@cdnetworks.co.kr> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> Message-ID: <4930EE38.8010808@modulus.org> Yes it does! We have deployed many 7.0-STABLE routers based on the EPIA EN12000E motherboard, and found that vge works really well, never had any major problems with it - don't touch it! :-) I suspect the OP should try a newer version of FreeBSD than 7.0-RELEASE which was so long ago. vge0@pci0:0:14:0: class=0x020000 card=0x01101106 chip=0x31191106 rev=0x11 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6120/VT6121/VT6122 'Velocity' Gigabit Ethernet Controllers' class = network subclass = ethernet vge0: port 0xf800-0xf8ff mem 0xfdffe000-0xfdffe0ff irq 10 at device 14.0 on pci0 miibus0: on vge0 ciphy0: PHY 1 on miibus0 From kes-kes at yandex.ru Sat Nov 29 00:14:58 2008 From: kes-kes at yandex.ru (KES) Date: Sat Nov 29 00:15:09 2008 Subject: kern/129074: [ppp] [panic] kernel panic with pppoe_server In-Reply-To: <200811290200.mAT205Ou016575@freefall.freebsd.org> References: <200811290200.mAT205Ou016575@freefall.freebsd.org> Message-ID: <788223423.20081129095912@yandex.ru> ????????????, Kris. ?? ?????? 29 ?????? 2008 ?., 4:00:05: kFo> Synopsis: [ppp] [panic] kernel panic with pppoe_server kFo> State-Changed-From-To: open->feedback kFo> State-Changed-By: kris kFo> State-Changed-When: Sat Nov 29 01:59:30 UTC 2008 kFo> State-Changed-Why: kFo> Please provide some details so we can begin to investigate your problem. kFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=129074 /etc/ppp/ppp.conf default: set log Phase Chat LCP IPCP CCP tun command adsl: set log Phase LCP tun command set device PPPoE:rl0:ukrtelecom # enable lqr # enable dns disable ipv6cp set cd 10 set dial # set login set redial 0 0 set reconnect random 999 set mtu 1492 set mru 1492 set authname name set authkey password # add! default HISADD Kernel panic and server reboot if my ISP response: ppp[348]: tun0: Phase: Pap Input: FAILURE (insufficient resources available to authenticate user) or ppp[348]: tun0: Phase: Pap Output: ******** last message repeated 2 times ppp[348]: tun0: Phase: Auth: No response from server -- ? ?????????, KES mailto:kes-kes@yandex.ru From mamruoc at gmail.com Sat Nov 29 05:43:05 2008 From: mamruoc at gmail.com (Mam Ruoc) Date: Sat Nov 29 05:43:12 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <4930EE38.8010808@modulus.org> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <4930EE38.8010808@modulus.org> Message-ID: <493146DD.20201@gmail.com> Hi! Andrew Snow wrote: > We have deployed many 7.0-STABLE routers based on the EPIA EN12000E > motherboard, and found that vge works really well, never had any major > problems with it - don't touch it! :-) Unsure if it's the EPIA EN12000E (not EPIA EN12000EG) or you're using STABLE, but I will try stable. > I suspect the OP should try a newer version of FreeBSD than 7.0-RELEASE > which was so long ago. You know where I can get hold of a more recent bootonly-7.0-STABLE iso? I am reporting this bug because I use pfSense which has moved from FreeBSD 6.3 to 7.0 and that made my VIA useless. They said it was a FreeBSD problem and therefore I am here. Mam From mamruoc at gmail.com Sat Nov 29 06:10:17 2008 From: mamruoc at gmail.com (Mam Ruoc) Date: Sat Nov 29 06:10:23 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <20081129065950.GG99324@cdnetworks.co.kr> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> Message-ID: <49314D3C.4050108@gmail.com> Pyun YongHyeon wrote: > I think there was a similar report. Would you show me the output of > "pciconf -lcv"? I'll try, unsure how to manage. Have tried to use Fixit in sysinstall to create a new shell, but Ghost-something did not have lspci, where can I find freebsd livecd? > For a long time I wanted to clean up vge(4). Unfortunately the PCI > NIC I have seem to broken so I guess it's hard to complete the > cleanup. You can get a WIP(now stalled) in the following URL. Note, > the driver may be chatty due to various debugging statements and it > may not work at all for your controller. > > http://people.freebsd.org/~yongari/vge/if_vge.c > http://people.freebsd.org/~yongari/vge/if_vgereg.h > http://people.freebsd.org/~yongari/vge/if_vgevar.h As I said in the other mail, unsure how to do this because I actually ned the fix because pfSense 1.2.1RC2 have this problem and made my VIA useless as a firewall. Mam From venkatvenkatsubra at yahoo.com Sat Nov 29 07:59:55 2008 From: venkatvenkatsubra at yahoo.com (Venkat Venkatsubra) Date: Sat Nov 29 08:00:00 2008 Subject: FreeBSD Window updates References: <200811281936.aa78374@walton.maths.tcd.ie> Message-ID: <88524.13498.qm@web58307.mail.re3.yahoo.com> Looking at some very old versions (4.3 BSD Reno for instance), the regular acks used to be?sent only through these?window updates. i.e. acks were sent only when the apps read the data. Acks are piggybacked with window updates. Or, delayed till the delayed ack timer expires if the apps is not reading. This would have had other issues with congestion control due to generating too few acks. When this was changed to send acks independent of apps reading the data, we?now have lot more acks due to these window updates in addition to the regular acks. Venkat ________________________________ From: David Malone To: Rui Paulo Cc: freebsd-net@freebsd.org; Kevin Oberman Sent: Friday, November 28, 2008 1:36:04 PM Subject: Re: FreeBSD Window updates > Yes, this makes sense. Probably this is a bug since 4.4BSD-Lite. I had a look to see what Linux does - it only generates pure window updates in the case that the advertised window would change by a factor of two. I guess this practically eliminates these updates. I would guess that changing the code to update on a change of a power of two would be OK. Another option would be to change the current limit of two MSSes to three, because this would eliminate window updates between regular delayed ACKs. > So, from what I understand, we do back off and that implies we are? > losing performance in the FreeBSD to FreeBSD case, right? We do the right thing and ignore these pure window updates. I've checked, and Linux also ignores ACKs that just seem to update the window. ??? David. _______________________________________________ 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 salvataha1 at live.co.za Sat Nov 29 08:37:28 2008 From: salvataha1 at live.co.za (Col. Salva Taha (Rtd)) Date: Sat Nov 29 08:37:35 2008 Subject: PROPERTIES. Message-ID: <200811291603.mATG3b3o016642@vulcan.highspd.net> Good Day, I wish to introduce myself to you.I am Col.Salva Taha a top Sudanese Goverment official who opposed the war in Dafur in my country Sudan.Due to my oppostion to the war,the goverment of my country has been persecuting me.Consequently my wife,children and I managed to enter a red cross air plane that was evacuating foreigners and we are presently in Cape Town,South Africa. We wish to invest in properties in your country with your assistance and cooperation.If you are in a good position to help my family, please send an email to the email address below indicating your desire to help my family invest the funds in your country and beyond. I urgently await your email. best regards. God bless, Col. Salva Taha (Rtd) Email:salvataha1@live.co.za From dwmalone at maths.tcd.ie Sat Nov 29 09:46:36 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Sat Nov 29 09:46:43 2008 Subject: FreeBSD Window updates In-Reply-To: Your message of "Sat, 29 Nov 2008 07:59:54 PST." <88524.13498.qm@web58307.mail.re3.yahoo.com> Message-ID: <200811291746.aa88825@walton.maths.tcd.ie> I've got an example extract tcpdump of this at the end of the mail - here 6 ACKs are sent, 5 of which are pure window updates and several are 2us apart! I think the easy option is to delete the code that generates explicit window updates if the window moves by 2*MSS. We then should be doing something similar to Linux. The other easy alternative would be to add a sysclt that lets us generate an window update every N*MSS and by default set it to something big, like 10 or 100. That should effectively eliminate the updates during bulk data transfer, but may still generate some window updates after a loss. Normal ACKing for driving congestion control shouldn't be impacted by either of these suggested changes. David. 1227622713.276609 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40798 (DF) 1227622713.276611 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40830 (DF) 1227622713.276613 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40862 (DF) 1227622713.276615 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40894 (DF) 1227622713.276852 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40926 (DF) 1227622713.276855 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40958 (DF) 1227622713.296585 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144100641 win 40956 (DF) From kris at FreeBSD.org Sat Nov 29 12:33:17 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sat Nov 29 12:33:24 2008 Subject: kern/129074: [ppp] [panic] kernel panic with pppoe_server In-Reply-To: <788223423.20081129095912@yandex.ru> References: <200811290200.mAT205Ou016575@freefall.freebsd.org> <788223423.20081129095912@yandex.ru> Message-ID: <4931A70C.30708@FreeBSD.org> KES wrote: > ????????????, Kris. > > ?? ?????? 29 ?????? 2008 ?., 4:00:05: > > kFo> Synopsis: [ppp] [panic] kernel panic with pppoe_server > > kFo> State-Changed-From-To: open->feedback > kFo> State-Changed-By: kris > kFo> State-Changed-When: Sat Nov 29 01:59:30 UTC 2008 > kFo> State-Changed-Why: > kFo> Please provide some details so we can begin to investigate your problem. > > kFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=129074 > > /etc/ppp/ppp.conf > default: > set log Phase Chat LCP IPCP CCP tun command > > adsl: > set log Phase LCP tun command > set device PPPoE:rl0:ukrtelecom > # enable lqr > # enable dns > disable ipv6cp > set cd 10 > set dial > # set login > set redial 0 0 > set reconnect random 999 > set mtu 1492 > set mru 1492 > set authname name > set authkey password > # add! default HISADD > > Kernel panic and server reboot if my ISP response: > ppp[348]: tun0: Phase: Pap Input: FAILURE (insufficient resources available to authenticate user) > or > ppp[348]: tun0: Phase: Pap Output: ******** > last message repeated 2 times > ppp[348]: tun0: Phase: Auth: No response from server > > Please provide details of the panic too. See the developers handbook chapter on kernel debugging for full instructions. Kris From venkatvenkatsubra at yahoo.com Sat Nov 29 12:39:51 2008 From: venkatvenkatsubra at yahoo.com (Venkat Venkatsubra) Date: Sat Nov 29 12:39:59 2008 Subject: FreeBSD Window updates References: <200811291746.aa88825@walton.maths.tcd.ie> Message-ID: <10716.94191.qm@web58304.mail.re3.yahoo.com> Hi David, Assuming each of these 5 window updates are sent after the apps completed the?read that it issued, what's the buffer size the apps is passing to the read ? If it is small, could that be increased ? But I agree with you that there is room for optimizing sending of these window updates. (Since I don't know the window scale factor for the connection, I couldn't figure out how much each of the window updates was opening up the window.) Venkat ________________________________ From: David Malone To: Venkat Venkatsubra Cc: Rui Paulo ; freebsd-net@freebsd.org; Kevin Oberman Sent: Saturday, November 29, 2008 11:46:30 AM Subject: Re: FreeBSD Window updates I've got an example extract tcpdump of this at the end of the mail - here 6 ACKs are sent, 5 of which are pure window updates and several are 2us apart! I think the easy option is to delete the code that generates explicit window updates if the window moves by 2*MSS. We then should be doing something similar to Linux. The other easy alternative would be to add a sysclt that lets us generate an window update every N*MSS and by default set it to something big, like 10 or 100. That should effectively eliminate the updates during bulk data transfer, but may still generate some window updates after a loss. Normal ACKing for driving congestion control shouldn't be impacted by either of these suggested changes. ??? David. 1227622713.276609 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40798 (DF) 1227622713.276611 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40830 (DF) 1227622713.276613 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40862 (DF) 1227622713.276615 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40894 (DF) 1227622713.276852 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40926 (DF) 1227622713.276855 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40958 (DF) 1227622713.296585 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144100641 win 40956 (DF) _______________________________________________ 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 dwmalone at maths.tcd.ie Sat Nov 29 12:47:00 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Sat Nov 29 12:47:07 2008 Subject: FreeBSD Window updates In-Reply-To: Your message of "Sat, 29 Nov 2008 12:39:49 PST." <10716.94191.qm@web58304.mail.re3.yahoo.com> Message-ID: <200811292046.aa42834@salmon.maths.tcd.ie> > Each of these 5 window updates are sent after the apps completed the read > that it issued, what's the buffer size the apps is passing to the read? > If it is small, could that be increased? I'm not actually sure - the app is iperf. The window scaling factor is 8 here I think. > But I agree with you that there is room for optimizing sending of these > window updates. Any feeling for which would be the better fix? David. From Mykel at mWare.ca Sat Nov 29 12:55:26 2008 From: Mykel at mWare.ca (Mykel) Date: Sat Nov 29 12:55:33 2008 Subject: Determining counts or size of routing table? (netstat performance?) Message-ID: <4931A5B6.1060000@mWare.ca> Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a handful of peers... I'd like to determine the size of the FIB/kernel routing table. OpenBGPd does not give me this data, and on my duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. I'm not looking for exact numbers, just something I can poll via NetSNMP and plot in cacti... I looked though netstat, route, sysctl, vmstat, even pored over an snmpwalk... can't find anything. Been asking around, and the only suggestion I've received was to write a daemon that dumps the table and then monitors the changes, but I'm not a programmer, nor could I find any tool in ports that might assist in this. I'd be happy with almost any metric that gives me some absolute reference as to how big my routing table is so I can get some nice pretty graphs done up. Not pounding the system every 60-300 seconds would be very nice. Any suggestions? Or does everyone just pipe netstat? Is there a MIB for sysctl or NetSNMP I'm missing? Myke [root@jigsaw ~]# time route -vnd flush | wc -l 1121977 real 0m6.681s user 0m3.910s sys 0m2.351s [root@jigsaw ~]# time netstat -rnf inet | wc -l 280479 real 0m12.982s user 0m2.713s sys 0m9.609s [root@jigsaw ~]# From venkatvenkatsubra at yahoo.com Sat Nov 29 13:01:54 2008 From: venkatvenkatsubra at yahoo.com (Venkat Venkatsubra) Date: Sat Nov 29 13:02:00 2008 Subject: FreeBSD Window updates References: <200811292046.aa42834@salmon.maths.tcd.ie> Message-ID: <865234.28813.qm@web58308.mail.re3.yahoo.com> So the apps read buffer is possibly 32?times 2^8 = 8KB ? (32 being the increment in each of those window updates.) ________________________________ From: David Malone To: Venkat Venkatsubra Cc: Rui Paulo ; freebsd-net@freebsd.org; Kevin Oberman Sent: Saturday, November 29, 2008 2:46:53 PM Subject: Re: FreeBSD Window updates > Each of these 5 window updates are sent after the apps completed the read > that it issued, what's the buffer size the apps is passing to the read? > If it is small, could that be increased? I'm not actually sure - the app is iperf. The window scaling factor is 8 here I think. > But I agree with you that there is room for optimizing sending of these > window updates. Any feeling for which would be the better fix? ??? David. From dwmalone at maths.tcd.ie Sat Nov 29 13:08:43 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Sat Nov 29 13:08:49 2008 Subject: FreeBSD Window updates In-Reply-To: Your message of "Sat, 29 Nov 2008 13:01:52 PST." <865234.28813.qm@web58308.mail.re3.yahoo.com> Message-ID: <200811292108.aa49379@salmon.maths.tcd.ie> > So the apps read buffer is possibly 32 times 2^8 = 8KB ? (32 being the > increment in each of those window updates.) I don't have the source code to hand, but that certainly sounds plausable. It is a tcp traffic generation tool, so 8K sounds like the sort of size it is likely to read in. David. From dave.edwards at adelaide.on.net Sat Nov 29 17:02:25 2008 From: dave.edwards at adelaide.on.net (Dave Edwards) Date: Sat Nov 29 17:02:32 2008 Subject: nmap on FreeBSD 7.0-RELEASE In-Reply-To: <4CREIW43kKwxaB43gZShXkxNn3U@2DcjJpvUBcA8GzIZe2t/Ulo9G+Y> References: <492E8B52.9010408@adelaide.on.net> <4CREIW43kKwxaB43gZShXkxNn3U@2DcjJpvUBcA8GzIZe2t/Ulo9G+Y> Message-ID: <4931E629.8070503@adelaide.on.net> Eygene Ryabinkin wrote: > Dave, good day. > > Thu, Nov 27, 2008 at 10:28:10PM +1030, Dave Edwards wrote: > >> I've tried creating a host route for the nmap target instead of relying >> on the default route and I've tried three other versions of nmap. As an >> aside (or maybe a hint) when compiling nmap from source, there are a >> number of warnings like: > > Could you, please, post the accompanying config.log that was produced > by configure and the configure script itself? > Sorry, my reply contained attachments and went into the bit bucket. The config.log and configure script are at: http://chunga.apana.org.au/stuff/nmap-configure-stuff.tgz if anyone is interested. My main problem is that I can't use nmap (with options that require raw sockets) over a tun device. Any help would be appreciated. ciao dave From andrew at flarn.com Sat Nov 29 19:44:25 2008 From: andrew at flarn.com (Andrew Tulloch) Date: Sat Nov 29 19:44:32 2008 Subject: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 Message-ID: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> I've just installed from the FreeBSD 7.1-BETA1 iso and get the following when the re driver attempts to attach to the two onboard NICs found on a Gigabyte GA-EX58-UD5 motherboard: re0: port 0x9e00-0x9eff mem 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 re0: Chip rev. 0x28000000 re0: MAC rev. 0x00100000 re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 pcib9: irq 17 at device 28.5 on pci0 pci9: on pcib9 re1: port 0x8e00-0x8eff mem 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on pci9 re1: Chip rev. 0x28000000 re1: MAC rev. 0x00100000 re1: Unknown H/W revision: 0x28000000 device_attach: re1 attach returned 6 pciconf -lvc extract: re0@pci0:8:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 0 cap 11[ac] = MSI-X supports 4 messages in map 0x20 cap 03[cc] = VPD re1@pci0:9:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 0 cap 11[ac] = MSI-X supports 4 messages in map 0x20 cap 03[cc] = VPD Is there any simple patch I can apply to get the driver to attach, assuming it should work? Thanks, Andrew From julian at elischer.org Sat Nov 29 20:32:36 2008 From: julian at elischer.org (Julian Elischer) Date: Sat Nov 29 20:32:44 2008 Subject: Determining counts or size of routing table? (netstat performance?) In-Reply-To: <4931A5B6.1060000@mWare.ca> References: <4931A5B6.1060000@mWare.ca> Message-ID: <49321494.90706@elischer.org> Mykel wrote: > Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a > handful of peers... I'd like to determine the size of the FIB/kernel > routing table. OpenBGPd does not give me this data, and on my > duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. > > I'm not looking for exact numbers, just something I can poll via NetSNMP > and plot in cacti... > > I looked though netstat, route, sysctl, vmstat, even pored over an > snmpwalk... can't find anything. > Been asking around, and the only suggestion I've received was to write a > daemon that dumps the table and then monitors the changes, but I'm not a > programmer, nor could I find any tool in ports that might assist in this. > > I'd be happy with almost any metric that gives me some absolute > reference as to how big my routing table is so I can get some nice > pretty graphs done up. Not pounding the system every 60-300 seconds > would be very nice. > > Any suggestions? Or does everyone just pipe netstat? Is there a MIB for > sysctl or NetSNMP I'm missing? > no. It's a hard thing to do so that is why it hasn't been done yet. From sam at freebsd.org Sat Nov 29 21:04:35 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Nov 29 21:04:42 2008 Subject: Determining counts or size of routing table? (netstat performance?) In-Reply-To: <49321494.90706@elischer.org> References: <4931A5B6.1060000@mWare.ca> <49321494.90706@elischer.org> Message-ID: <49321EE2.6020001@freebsd.org> Julian Elischer wrote: > Mykel wrote: >> Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a >> handful of peers... I'd like to determine the size of the FIB/kernel >> routing table. OpenBGPd does not give me this data, and on my >> duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. >> >> I'm not looking for exact numbers, just something I can poll via NetSNMP >> and plot in cacti... >> >> I looked though netstat, route, sysctl, vmstat, even pored over an >> snmpwalk... can't find anything. >> Been asking around, and the only suggestion I've received was to write a >> daemon that dumps the table and then monitors the changes, but I'm not a >> programmer, nor could I find any tool in ports that might assist in >> this. >> >> I'd be happy with almost any metric that gives me some absolute >> reference as to how big my routing table is so I can get some nice >> pretty graphs done up. Not pounding the system every 60-300 seconds >> would be very nice. >> >> Any suggestions? Or does everyone just pipe netstat? Is there a MIB for >> sysctl or NetSNMP I'm missing? >> > > no. It's a hard thing to do so that is why it hasn't been done yet. Perhaps I misunderstand his question but trouble% vmstat -m |grep routetbl routetbl 14 2K - 33875 16,32,64,128,256 should show memory allocated to the routing table. Sam From Mykel at mWare.ca Sat Nov 29 21:09:14 2008 From: Mykel at mWare.ca (Mykel) Date: Sat Nov 29 21:09:21 2008 Subject: Determining counts or size of routing table? (netstat performance?) In-Reply-To: <49321EE2.6020001@freebsd.org> References: <4931A5B6.1060000@mWare.ca> <49321494.90706@elischer.org> <49321EE2.6020001@freebsd.org> Message-ID: <49321FF8.6000805@mWare.ca> Sam Leffler wrote: > Julian Elischer wrote: >> Mykel wrote: >>> Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a >>> handful of peers... I'd like to determine the size of the FIB/kernel >>> routing table. OpenBGPd does not give me this data, and on my >>> duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. >>> >>> I'm not looking for exact numbers, just something I can poll via >>> NetSNMP >>> and plot in cacti... >>> >>> I looked though netstat, route, sysctl, vmstat, even pored over an >>> snmpwalk... can't find anything. >>> Been asking around, and the only suggestion I've received was to >>> write a >>> daemon that dumps the table and then monitors the changes, but I'm >>> not a >>> programmer, nor could I find any tool in ports that might assist in >>> this. >>> >>> I'd be happy with almost any metric that gives me some absolute >>> reference as to how big my routing table is so I can get some nice >>> pretty graphs done up. Not pounding the system every 60-300 seconds >>> would be very nice. >>> >>> Any suggestions? Or does everyone just pipe netstat? Is there a MIB for >>> sysctl or NetSNMP I'm missing? >>> >> >> no. It's a hard thing to do so that is why it hasn't been done yet. > Perhaps I misunderstand his question but > > trouble% vmstat -m |grep routetbl > routetbl 14 2K - 33875 16,32,64,128,256 > > should show memory allocated to the routing table. I was also shown (privately) this: # vmstat -z | grep "rtentry" rtentry: 120, 0, 198, 474, 12190, 0 Either works for me, so I'm now happy. Thanks! Myke From sam at freebsd.org Sat Nov 29 21:18:29 2008 From: sam at freebsd.org (Sam Leffler) Date: Sat Nov 29 21:18:34 2008 Subject: Determining counts or size of routing table? (netstat performance?) In-Reply-To: <49321FF8.6000805@mWare.ca> References: <4931A5B6.1060000@mWare.ca> <49321494.90706@elischer.org> <49321EE2.6020001@freebsd.org> <49321FF8.6000805@mWare.ca> Message-ID: <49322224.8010806@freebsd.org> Mykel wrote: > Sam Leffler wrote: > >> Julian Elischer wrote: >> >>> Mykel wrote: >>> >>>> Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a >>>> handful of peers... I'd like to determine the size of the FIB/kernel >>>> routing table. OpenBGPd does not give me this data, and on my >>>> duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. >>>> >>>> I'm not looking for exact numbers, just something I can poll via >>>> NetSNMP >>>> and plot in cacti... >>>> >>>> I looked though netstat, route, sysctl, vmstat, even pored over an >>>> snmpwalk... can't find anything. >>>> Been asking around, and the only suggestion I've received was to >>>> write a >>>> daemon that dumps the table and then monitors the changes, but I'm >>>> not a >>>> programmer, nor could I find any tool in ports that might assist in >>>> this. >>>> >>>> I'd be happy with almost any metric that gives me some absolute >>>> reference as to how big my routing table is so I can get some nice >>>> pretty graphs done up. Not pounding the system every 60-300 seconds >>>> would be very nice. >>>> >>>> Any suggestions? Or does everyone just pipe netstat? Is there a MIB for >>>> sysctl or NetSNMP I'm missing? >>>> >>>> >>> no. It's a hard thing to do so that is why it hasn't been done yet. >>> >> Perhaps I misunderstand his question but >> >> trouble% vmstat -m |grep routetbl >> routetbl 14 2K - 33875 16,32,64,128,256 >> >> should show memory allocated to the routing table. >> > I was also shown (privately) this: > > # vmstat -z | grep "rtentry" > rtentry: 120, 0, 198, 474, > 12190, 0 > > Either works for me, so I'm now happy. Thanks! > Yes, was looking for that but stopped when I found malloc's for the radix tree :-) Sam From julian at elischer.org Sat Nov 29 21:25:03 2008 From: julian at elischer.org (Julian Elischer) Date: Sat Nov 29 21:25:09 2008 Subject: Determining counts or size of routing table? (netstat performance?) In-Reply-To: <49321FF8.6000805@mWare.ca> References: <4931A5B6.1060000@mWare.ca> <49321494.90706@elischer.org> <49321EE2.6020001@freebsd.org> <49321FF8.6000805@mWare.ca> Message-ID: <493223B5.7080502@elischer.org> Mykel wrote: > Sam Leffler wrote: >> Julian Elischer wrote: >>> Mykel wrote: >>>> Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a >>>> handful of peers... I'd like to determine the size of the FIB/kernel >>>> routing table. OpenBGPd does not give me this data, and on my >>>> duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. >>>> >>>> I'm not looking for exact numbers, just something I can poll via >>>> NetSNMP >>>> and plot in cacti... >>>> >>>> I looked though netstat, route, sysctl, vmstat, even pored over an >>>> snmpwalk... can't find anything. >>>> Been asking around, and the only suggestion I've received was to >>>> write a >>>> daemon that dumps the table and then monitors the changes, but I'm >>>> not a >>>> programmer, nor could I find any tool in ports that might assist in >>>> this. >>>> >>>> I'd be happy with almost any metric that gives me some absolute >>>> reference as to how big my routing table is so I can get some nice >>>> pretty graphs done up. Not pounding the system every 60-300 seconds >>>> would be very nice. >>>> >>>> Any suggestions? Or does everyone just pipe netstat? Is there a MIB for >>>> sysctl or NetSNMP I'm missing? >>>> >>> no. It's a hard thing to do so that is why it hasn't been done yet. >> Perhaps I misunderstand his question but >> >> trouble% vmstat -m |grep routetbl >> routetbl 14 2K - 33875 16,32,64,128,256 >> >> should show memory allocated to the routing table. > I was also shown (privately) this: > > # vmstat -z | grep "rtentry" > rtentry: 120, 0, 198, 474, > 12190, 0 > > Either works for me, so I'm now happy. Thanks! neither of these gives an exactly accurate answer, In hte case of dangling routes, for example, routes can be outside the table and still not freed. (their reference counts have not gone to 0 as a socket still holds a reference for example). it is however a good upper bound I guess > > Myke > > _______________________________________________ > 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 sepherosa at gmail.com Sun Nov 30 04:32:00 2008 From: sepherosa at gmail.com (Sepherosa Ziehau) Date: Sun Nov 30 04:32:07 2008 Subject: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 In-Reply-To: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> References: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> Message-ID: On Sun, Nov 30, 2008 at 11:18 AM, Andrew Tulloch wrote: > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > following when the re driver attempts to attach to the two onboard > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > re0: Ethernet> port 0x9e00-0x9eff mem > 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > pci8 > re0: Chip rev. 0x28000000 It's 8168D, driver configuration should be same as 8168CP Best Regards, sephe -- Live Free or Die From mamruoc at gmail.com Sun Nov 30 06:39:08 2008 From: mamruoc at gmail.com (Mam Ruoc) Date: Sun Nov 30 06:39:15 2008 Subject: vge driver does not work on a VIA EPIA EN12000EG In-Reply-To: <49314D3C.4050108@gmail.com> References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <49314D3C.4050108@gmail.com> Message-ID: <4932A587.9010903@gmail.com> I tried the bootonly from: ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/7.1 That didnt make any difference, any idea, anybody? Mam Mam Ruoc wrote: > Pyun YongHyeon wrote: >> I think there was a similar report. Would you show me the output of >> "pciconf -lcv"? > > I'll try, unsure how to manage. > Have tried to use Fixit in sysinstall to create a new shell, but > Ghost-something did not have lspci, where can I find freebsd livecd? > >> For a long time I wanted to clean up vge(4). Unfortunately the PCI >> NIC I have seem to broken so I guess it's hard to complete the >> cleanup. You can get a WIP(now stalled) in the following URL. Note, >> the driver may be chatty due to various debugging statements and it >> may not work at all for your controller. >> >> http://people.freebsd.org/~yongari/vge/if_vge.c >> http://people.freebsd.org/~yongari/vge/if_vgereg.h >> http://people.freebsd.org/~yongari/vge/if_vgevar.h > > As I said in the other mail, unsure how to do this because I actually > ned the fix because pfSense 1.2.1RC2 have this problem and made my VIA > useless as a firewall. > > Mam From andre at freebsd.org Sun Nov 30 15:11:21 2008 From: andre at freebsd.org (Andre Oppermann) Date: Sun Nov 30 15:11:27 2008 Subject: FreeBSD Window updates In-Reply-To: <200811291746.aa88825@walton.maths.tcd.ie> References: <200811291746.aa88825@walton.maths.tcd.ie> Message-ID: <49331DA0.3070804@freebsd.org> David Malone wrote: > I've got an example extract tcpdump of this at the end of the mail > - here 6 ACKs are sent, 5 of which are pure window updates and > several are 2us apart! > > I think the easy option is to delete the code that generates explicit > window updates if the window moves by 2*MSS. We then should be doing > something similar to Linux. The other easy alternative would be to > add a sysclt that lets us generate an window update every N*MSS and > by default set it to something big, like 10 or 100. That should > effectively eliminate the updates during bulk data transfer, but > may still generate some window updates after a loss. The main problem of the pure window update test in tcp_output() is its complete ignorance of delayed ACKs. Second is the strict 4.4BSD adherence to sending an update for every window increase of >= 2*MSS. The third issue of sending a slew of window updates after having received a FIN (telling us the other end won't ever send more data) I have already fixed some moons ago. In my new-tcp work I've come across the window update logic some time ago and backchecked with relevant RFCs and other implementations. Attached is a compiling but otherwise untested backport of the new logic. -- Andre > Normal ACKing for driving congestion control shouldn't be impacted > by either of these suggested changes. > > David. > > 1227622713.276609 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40798 (DF) > 1227622713.276611 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40830 (DF) > 1227622713.276613 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40862 (DF) > 1227622713.276615 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40894 (DF) > 1227622713.276852 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40926 (DF) > 1227622713.276855 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40958 (DF) > 1227622713.296585 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144100641 win 40956 (DF) -------------- next part -------------- Index: tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.158 diff -u -p -r1.158 tcp_output.c --- tcp_output.c 27 Nov 2008 13:19:42 -0000 1.158 +++ tcp_output.c 30 Nov 2008 22:58:46 -0000 @@ -539,14 +539,32 @@ after_sack_rexmit: } /* - * Compare available window to amount of window - * known to peer (as advertised window less - * next expected input). If the difference is at least two - * max size segments, or at least 50% of the maximum possible - * window, then want to send a window update to peer. + * Compare available window to amount of window known to peer + * (as advertised window less next expected input) and decide + * if we have to send a pure window update segment. + * + * When a delayed ACK is scheduled, do nothing. It will update + * the window anyway in a few milliseconds. + * + * If the receive socket buffer has less than 1/4 of space + * available and if the difference is at least two max size + * segments, send an immediate window update to peer. + * + * Otherwise if the difference is 1/8 (or more) of the receive + * socket buffer, or at least 1/2 of the maximum possible window, + * then we send a window update too. + * * Skip this if the connection is in T/TCP half-open state. * Don't send pure window updates when the peer has closed * the connection and won't ever send more data. + * + * See RFC793, Section 3.7, page 43, Window Management Suggestions + * See RFC1122: Section 4.2.3.3, When to Send a Window Update + * + * Note: We are less aggressive with sending window update than + * recommended in RFC1122. This is fine with todays large socket + * buffers and will not stall the peer. In addition we piggy back + * window update on regular ACKs and sends. */ if (recwin > 0 && !(tp->t_flags & TF_NEEDSYN) && !TCPS_HAVERCVDFIN(tp->t_state)) { @@ -554,14 +572,24 @@ after_sack_rexmit: * "adv" is the amount we can increase the window, * taking into account that we are limited by * TCP_MAXWIN << tp->rcv_scale. + * + * NB: adv must be equal or larger than the smallest + * unscaled window increment. */ long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - (tp->rcv_adv - tp->rcv_nxt); - if (adv >= (long) (2 * tp->t_maxseg)) - goto send; - if (2 * adv >= (long) so->so_rcv.sb_hiwat) - goto send; + if (!(tp->t_flags & TF_DELACK) && + adv >= (long)0x1 << tp->rcv_scale) { + if (recwin <= (long)(so->so_rcv.sb_hiwat / 4) && + adv >= (long)(2 * tp->t_maxseg)) + goto send; + if (adv >= (long)(so->so_rcv.sb_hiwat / 8) && + adv >= (long)tp->t_maxseg) + goto send; + if (2 * adv >= (long)so->so_rcv.sb_hiwat) + goto send; + } } /* From andre at freebsd.org Sun Nov 30 15:18:16 2008 From: andre at freebsd.org (Andre Oppermann) Date: Sun Nov 30 15:18:22 2008 Subject: FreeBSD Window updates In-Reply-To: <49331DA0.3070804@freebsd.org> References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> Message-ID: <49331F3E.2090305@freebsd.org> Andre Oppermann wrote: > David Malone wrote: >> I've got an example extract tcpdump of this at the end of the mail >> - here 6 ACKs are sent, 5 of which are pure window updates and >> several are 2us apart! >> >> I think the easy option is to delete the code that generates explicit >> window updates if the window moves by 2*MSS. We then should be doing >> something similar to Linux. The other easy alternative would be to >> add a sysclt that lets us generate an window update every N*MSS and >> by default set it to something big, like 10 or 100. That should >> effectively eliminate the updates during bulk data transfer, but >> may still generate some window updates after a loss. > > The main problem of the pure window update test in tcp_output() is > its complete ignorance of delayed ACKs. Second is the strict 4.4BSD > adherence to sending an update for every window increase of >= 2*MSS. > The third issue of sending a slew of window updates after having > received a FIN (telling us the other end won't ever send more data) > I have already fixed some moons ago. > > In my new-tcp work I've come across the window update logic some time > ago and backchecked with relevant RFCs and other implementations. > Attached is a compiling but otherwise untested backport of the new logic. Slightly improved version attached. -- Andre -------------- next part -------------- Index: tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.158 diff -u -p -r1.158 tcp_output.c --- tcp_output.c 27 Nov 2008 13:19:42 -0000 1.158 +++ tcp_output.c 30 Nov 2008 23:16:30 -0000 @@ -539,29 +539,56 @@ after_sack_rexmit: } /* - * Compare available window to amount of window - * known to peer (as advertised window less - * next expected input). If the difference is at least two - * max size segments, or at least 50% of the maximum possible - * window, then want to send a window update to peer. + * Compare available window to amount of window known to peer + * (as advertised window less next expected input) and decide + * if we have to send a pure window update segment. + * + * When a delayed ACK is scheduled, do nothing. It will update + * the window anyway in a few milliseconds. + * + * If the receive socket buffer has less than 1/4 of space + * available and if the difference is at least two max size + * segments, send an immediate window update to peer. + * + * Otherwise if the difference is 1/8 (or more) of the receive + * socket buffer, or at least 1/2 of the maximum possible window, + * then we send a window update too. + * * Skip this if the connection is in T/TCP half-open state. * Don't send pure window updates when the peer has closed * the connection and won't ever send more data. + * + * See RFC793, Section 3.7, page 43, Window Management Suggestions + * See RFC1122: Section 4.2.3.3, When to Send a Window Update + * + * Note: We are less aggressive with sending window update than + * recommended in RFC1122. This is fine with todays large socket + * buffers and will not stall the peer. In addition we piggy back + * window update on regular ACKs and sends. */ - if (recwin > 0 && !(tp->t_flags & TF_NEEDSYN) && - !TCPS_HAVERCVDFIN(tp->t_state)) { + if (recwin > 0 && !(tp->t_flags & TF_DELACK) && + !(tp->t_flags & TF_NEEDSYN) && !TCPS_HAVERCVDFIN(tp->t_state)) { /* * "adv" is the amount we can increase the window, * taking into account that we are limited by * TCP_MAXWIN << tp->rcv_scale. + * + * NB: adv must be equal or larger than the smallest + * unscaled window increment. */ long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - (tp->rcv_adv - tp->rcv_nxt); - if (adv >= (long) (2 * tp->t_maxseg)) - goto send; - if (2 * adv >= (long) so->so_rcv.sb_hiwat) - goto send; + if (adv >= (long)0x1 << tp->rcv_scale) { + if (recwin <= (long)(so->so_rcv.sb_hiwat / 4) && + adv >= (long)(2 * tp->t_maxseg)) + goto send; + if (adv >= (long)(so->so_rcv.sb_hiwat / 8) && + adv >= (long)tp->t_maxseg) + goto send; + if (2 * adv >= (long)so->so_rcv.sb_hiwat) + goto send; + } } /* From kris at FreeBSD.org Sun Nov 30 18:02:05 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sun Nov 30 18:02:17 2008 Subject: panic from ifconfig in IFAREF Message-ID: <4933459A.5090806@FreeBSD.org> I got this panic on HEAD when trying to configure an IP address on an interface immediately after boot: > Fatal trap 9: general protection fault while in kernel mode > ccpuid = 4; xapic id = 04 > ginstruction pointer = 0x8:0xffffffff80494b42 > bstack pointer = 0x10:0xffffffff20938490 > 0frame pointe:r = 0x10:0xffffffff20938610 > code segment = base 0x0, limit 0xfffff, type 0x1b > link state changed to DOWN > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1073 (ifconfig) > [thread pid 1073 tid 100250 ] > Stopped at strlen+0x2: cmpb $0,(%rdi) > db> wh > Tracing pid 1073 tid 100250 td 0xffffff00077ab720 > strlen() at strlen+0x2 > vsnprintf() at vsnprintf+0x2e > panic() at panic+0x1d8 > _mtx_lock_flags() at _mtx_lock_flags+0xd9 > rtrequest1_fib() at rtrequest1_fib+0x3e6 > rtinit() at rtinit+0x213 > in_ifinit() at in_ifinit+0x2bd > in_control() at in_control+0xe95 > ifioctl() at ifioctl+0xfa > kern_ioctl() at kern_ioctl+0x92 > ioctl() at ioctl+0xfd > syscall() at syscall+0x1bc > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x140a69dfc, rsp = 0x7fffffffe588, rbp = 0x7fffffffef7c --- > __func__.6541+0xfcb: mtx_lock() of spin mutex %s @ %s:%d The panic is here: /* * Note that we now have a reference to the ifa. * This moved from below so that rnh->rnh_addaddr() can * examine the ifa and ifa->ifa_ifp if it so desires. */ IFAREF(ifa); (net/route.c:1081) Kris From pyunyh at gmail.com Sun Nov 30 20:32:33 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Nov 30 20:32:40 2008 Subject: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 In-Reply-To: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> References: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> Message-ID: <20081201043218.GB1082@cdnetworks.co.kr> On Sun, Nov 30, 2008 at 03:18:41AM +0000, Andrew Tulloch wrote: > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > following when the re driver attempts to attach to the two onboard > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > re0: Ethernet> port 0x9e00-0x9eff mem > 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > pci8 > re0: Chip rev. 0x28000000 > re0: MAC rev. 0x00100000 > re0: Unknown H/W revision: 0x28000000 > device_attach: re0 attach returned 6 > pcib9: irq 17 at device 28.5 on pci0 > pci9: on pcib9 > re1: Ethernet> port 0x8e00-0x8eff mem > 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on > pci9 > re1: Chip rev. 0x28000000 > re1: MAC rev. 0x00100000 > re1: Unknown H/W revision: 0x28000000 > device_attach: re1 attach returned 6 > > pciconf -lvc extract: > re0@pci0:8:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > cap 03[cc] = VPD > re1@pci0:9:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > cap 03[cc] = VPD > > > Is there any simple patch I can apply to get the driver to attach, > assuming it should work? > This controller seems to support MSI-X with 4 messages. Unfortunately previous PCIe controllers from RealTek were notorious for MSI issues so it's hard to know this revision really works with MSI-X. I guess it was added to support RSS(receive-side scaling of MS NDIS 6.0). As sephe said if the controller configuration is the same as 8168C family, the attached patch would make re(4) work as expected. -- Regards, Pyun YongHyeon -------------- next part -------------- Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 185504) +++ sys/dev/re/if_re.c (working copy) @@ -172,7 +172,7 @@ { RT_VENDORID, RT_DEVICEID_8101E, 0, "RealTek 8101E/8102E/8102EL PCIe 10/100baseTX" }, { RT_VENDORID, RT_DEVICEID_8168, 0, - "RealTek 8168/8168B/8168C/8168CP/8111B/8111C/8111CP PCIe " + "RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe " "Gigabit Ethernet" }, { RT_VENDORID, RT_DEVICEID_8169, 0, "RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet" }, @@ -1225,6 +1225,7 @@ case RL_HWREV_8168C: case RL_HWREV_8168C_SPIN2: case RL_HWREV_8168CP: + case RL_HWREV_8168D: sc->rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT; /* Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 185504) +++ sys/pci/if_rlreg.h (working copy) @@ -157,6 +157,7 @@ #define RL_HWREV_8169_8110SB 0x10000000 #define RL_HWREV_8169_8110SC 0x18000000 #define RL_HWREV_8102EL 0x24800000 +#define RL_HWREV_8168D 0x28000000 #define RL_HWREV_8168_SPIN1 0x30000000 #define RL_HWREV_8100E 0x30800000 #define RL_HWREV_8101E 0x34000000