Re: multiple routing tables review patch ready for simple testing.
> >This confuses me > > > >The whole point of a FIB is to decide the *next* hop for a > >given input packet. So questions. > >1) A packet arrives on an interface. If this interface is > > associated with more than one FIB, which FIB does it get > > given to? > > > > which ever one you select, using the policy of your choice. > > that's what policy routing is about. > if you don't WANT policy based routing, dont turn it on. > > > > >2) If that decision is taken by a a packet 'classifier', > > isn't it in effect doing the job of a FIB (deciding the > > next hop, which happens to be a local FIB)? Recall that > > basically a packet passes from a FIB to another FIB until > > it gets to its eventual destination. > > the packet classifier selects a FIB which in turn implements a > particular routing decision tree. > In the degenerate case where a FIB has only one route > then you are correct, but there are technical reasons why this is > superior to just using a fwd rule in the firewall. The linux guys seems to have multiple fibs (or whatever they call them) which they can chain together by giving them different priorities. The effect seems to be that a packet will be matched through the highest priority fib to the lowest until a route match is found en then is used. Will something like that be possible? I came across that kind of use with the olsr guys. They let olsrd twiddle one of the higher priority fibs and then put fallback routes in a lower priority fib. That way olsrd can override a route (even the default route) and when olsrd exists and deltes all its routes, the original ones are still in the lower priority fib and will be used. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/120725: [bce] On board second lan port 'bce1' with Broadcom NetXtreme II BCM5708 1000Base-T 0.9.6 driver in Dell 1950 and 2950 behave super slow
Synopsis: [bce] On board second lan port 'bce1' with Broadcom NetXtreme II BCM5708 1000Base-T 0.9.6 driver in Dell 1950 and 2950 behave super slow State-Changed-From-To: feedback->closed State-Changed-By: vwe State-Changed-When: Fri May 2 09:47:48 UTC 2008 State-Changed-Why: We're sorry to not see any feedback received for quite some time. If you think this is still an issue which should be worked on, please provide the requested information and we'll be happy to reopen this ticket. Thank you for bringing this problem to attention! http://www.freebsd.org/cgi/query-pr.cgi?pr=120725 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
authentication timeouts with ath(4) in hostap mode
Hi, I'm using an alix2c0 board with two winstron CM9 ath(4)-cards and FreeBSD 7: ifconfig ath0 (...) mediaopt hostap mode 11a channel 36 ssid sn.a -bgscan ifconfig ath1 (...) mediaopt hostap mode 11g channel 11 ssid sn.g -bgscan When I try to raise the traffic (i.e. dd | ssh AP dd) my Linux wpa_supplicant drops the connection and has to reassociate. This however does not work immediately; The supplicant fails a few times before reconnecting: <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Associated with 00:0b:0b:06:0d:09 <2>WPA: Key negotiation completed with 00:0b:0b:06:0d:09 [PTK=CCMP GTK=CCMP] <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] This happens more on the 11a than on the 11g network. When I'm next to the AP, the timeouts are almost gone but they still happen. (My laptop is just one room away from the AP). Here is the athstats-output of ath0 (11a): # ./athstats -i ath0 481546 data frames received 330669 data frames transmit 13395 tx frames with an alternate rate 78558 long on-chip tx retries 1431 tx failed 'cuz too many retries 36M current transmit rate 78 tx management frames 3 tx frames discarded prior to association 45 tx frames with no ack marked 2894 rx failed 'cuz of bad CRC 2 rx failed 'cuz decryption 92711 rx failed 'cuz of PHY err 92708 OFDM timing 3 OFDM restart 318332 beacons transmitted periodic calibrations 2 rfgain value change 22 rssi of last ack 23 avg recv rssi -96 rx noise floor 2530 switched default/rx antenna Antenna profile: [1] tx 173364 rx 123068 [2] tx 155874 rx 358671 All this is well known to me, since I had NetBSD running on this device for months and it suffered the same problems -- it was even worse, the timeouts occured every few minutes. Back then, it seemed that ath had some interrupt problems: ath0: device timeout as David Young from NetBSD noticed in his mail some time ago: http://mail-index.netbsd.org/tech-net/2007/11/29/0001.html FreeBSD doesn't seem to have this `device timeouts'. I don't see any in /var/log/messages and there are none when I'm connected to the device over a serial port. I'm a bit lost here, but ready to debug if someone knows more. Thanks, Petar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
John Hay wrote: The linux guys seems to have multiple fibs (or whatever they call them) which they can chain together by giving them different priorities. The effect seems to be that a packet will be matched through the highest priority fib to the lowest until a route match is found en then is used. Will something like that be possible? I came across that kind of use with the olsr guys. They let olsrd twiddle one of the higher priority fibs and then put fallback routes in a lower priority fib. That way olsrd can override a route (even the default route) and when olsrd exists and deltes all its routes, the original ones are still in the lower priority fib and will be used. XORP already does this without relying on any kernel support. Each routing protocol supplies an origin table of its own. The RIB makes the decision on which route to plumb to the kernel based on administrative distance. When xorp_olsr exits, its origin table is removed, and the winning routes are recalculated. You don't need to go to the kernel for this sort of thing unless you specifically need to implement route policy based on which interface(s) a packet came in on. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
On Fri, May 02, 2008 at 04:44:20PM +0100, Bruce M. Simpson wrote: > John Hay wrote: > >The linux guys seems to have multiple fibs (or whatever they call them) > >which they can chain together by giving them different priorities. The > >effect seems to be that a packet will be matched through the highest > >priority fib to the lowest until a route match is found en then is used. > >Will something like that be possible? I came across that kind of use > >with the olsr guys. They let olsrd twiddle one of the higher priority > >fibs and then put fallback routes in a lower priority fib. That way > >olsrd can override a route (even the default route) and when olsrd > >exists and deltes all its routes, the original ones are still in the > >lower priority fib and will be used. > > > > XORP already does this without relying on any kernel support. > > Each routing protocol supplies an origin table of its own. The RIB makes > the decision on which route to plumb to the kernel based on > administrative distance. When xorp_olsr exits, its origin table is > removed, and the winning routes are recalculated. > > You don't need to go to the kernel for this sort of thing unless you > specifically need to implement route policy based on which interface(s) > a packet came in on. Yes I know that. But in the world of adhoc wireless mesh networking there are very few non-linux people, so they basically call the shots and use the linux kernel features to the full. To them it is unneeded complexity that the kernel already takes care of. :-/ In a sense I can understand them because their stuff also run on the small embedded stuff like the linksys wireless boxes and it needs to scale. The biggest adhoc olsr network is probably the Freifunk one that have more than 600 wireless nodes, mostly consisting of linksys boxes. On some boxes that are also connected to different kinds of networks, they run a different routing daemon into another fib and by setting the priorities on the fibs, they can decide which daemon's routes have the highest priority. And both routing daemons are happy because the other is not stomping on its feet. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
John Hay wrote: This confuses me The whole point of a FIB is to decide the *next* hop for a given input packet. So questions. 1) A packet arrives on an interface. If this interface is associated with more than one FIB, which FIB does it get given to? which ever one you select, using the policy of your choice. that's what policy routing is about. if you don't WANT policy based routing, dont turn it on. 2) If that decision is taken by a a packet 'classifier', isn't it in effect doing the job of a FIB (deciding the next hop, which happens to be a local FIB)? Recall that basically a packet passes from a FIB to another FIB until it gets to its eventual destination. the packet classifier selects a FIB which in turn implements a particular routing decision tree. In the degenerate case where a FIB has only one route then you are correct, but there are technical reasons why this is superior to just using a fwd rule in the firewall. The linux guys seems to have multiple fibs (or whatever they call them) which they can chain together by giving them different priorities. The effect seems to be that a packet will be matched through the highest priority fib to the lowest until a route match is found en then is used. Will something like that be possible? I came across that kind of use with the olsr guys. They let olsrd twiddle one of the higher priority fibs and then put fallback routes in a lower priority fib. That way olsrd can override a route (even the default route) and when olsrd exists and deltes all its routes, the original ones are still in the lower priority fib and will be used. no we are going to do the simple thing.. such enhancements can be done later if there is a call for it. We will just have a number of tables that you can associate a packet with at a number of points in its path. having another table as the 'default route' for a table (i.e. if you don't find something look in another table) is something that would be relatively easy to do, but I have not done it. John ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Julian Elischer wrote: John Hay wrote: This confuses me The whole point of a FIB is to decide the *next* hop for a given input packet. So questions. 1) A packet arrives on an interface. If this interface is associated with more than one FIB, which FIB does it get given to? which ever one you select, using the policy of your choice. that's what policy routing is about. if you don't WANT policy based routing, dont turn it on. 2) If that decision is taken by a a packet 'classifier', isn't it in effect doing the job of a FIB (deciding the next hop, which happens to be a local FIB)? Recall that basically a packet passes from a FIB to another FIB until it gets to its eventual destination. the packet classifier selects a FIB which in turn implements a particular routing decision tree. In the degenerate case where a FIB has only one route then you are correct, but there are technical reasons why this is superior to just using a fwd rule in the firewall. The linux guys seems to have multiple fibs (or whatever they call them) which they can chain together by giving them different priorities. The effect seems to be that a packet will be matched through the highest priority fib to the lowest until a route match is found en then is used. Will something like that be possible? I came across that kind of use with the olsr guys. They let olsrd twiddle one of the higher priority fibs and then put fallback routes in a lower priority fib. That way olsrd can override a route (even the default route) and when olsrd exists and deltes all its routes, the original ones are still in the lower priority fib and will be used. no we are going to do the simple thing.. such enhancements can be done later if there is a call for it. We will just have a number of tables that you can associate a packet with at a number of points in its path. having another table as the 'default route' for a table (i.e. if you don't find something look in another table) is something that would be relatively easy to do, but I have not done it.hav Having been prodded to go look up OLSR i an say that this is exactly the kind of thing that multiple routing tables are useful for. OLSR is an overlay network and any machine that participated must have a split personality. First it must be able to think in terms of the basic local network, and it must be able to think in terms of the world from the perspective of the overlay. In this case you would set the overlay interfaces to work with FIB 1 so that packets are transported according to rules defined there and the application packets to the internet would be routed according to FIB 0 which would have entries for the overlay interfaces but not necessarily entries for the actual physical interfaces. (for example) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: read() returns ETIMEDOUT on steady TCP connection
Mark Hills wrote: On Wed, 23 Apr 2008, Andre Oppermann wrote: http://people.freebsd.org/~andre/tcp_output-error-log.diff Please apply this patch and enable the sysctl net.inet.tcp.log_debug=1 and report any output. You likely get some (normal) noise from syncache. What we are looking for is reports from tcp_output. Hi Andre, I've applied the patch and tested. Aside from syncache noise, I get a constant stream of 'error 55' (ENOBUFS?), once the number of connection gets to around 150 at 192kbps. TCP: [192.168.5.43]:52153 to [192.168.5.40]:8080; tcp_output: error 55 while sending 192.168.5.40 is the IP address of this host, running the server. I tried to correlate the point of the application receiving ETIMEDOUT with these messages, but that is tricky as it seems to be outputting a lot of messages, and multiple messages over eachother (see below). Because of the mention of no buffer space available, I checked the values of net.inet.tcp.sendbuf* and recvbuf*, and increased the max values with no effect. When I get time I will modify the kernel to print errors which aren't ENOBUFS to see if there are any others. But in the meantime, this sounds like a problem to me. Is that correct? Mark :8080; tcp_output: error 55 while sending TCP: [192.168.5.42]:57384T CtPo: [[119922..116688..55..4402]]::85048400;1 ttoc p[_1o9u2t.p1u6t8:. 5e.r4r0o]r: 8080;5 5t cwp_hoiultep uste:n deirnrgor 55 while sending TCP: [192.168.5.42]:57382 to [192.168.5.40]:8080; tcp_output: error 55 while sending TCP: [192.168.5.42]:57381 to [192.168.5.40]:8080; tcp_output: error 55 while sending TCP: [192.168.5.42]:57380 to [192.168.5.40]:8080; tcp_output: error 55 while sending After tracing through the code it seems you are indeed memory limited. Looking back at the netstat -m output: 12550/250/12800/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) This shows that the supply of 4k jumbo clusters is pretty much exhausted. The cache may be allocated to different CPUs and the one making the request at a given point may be depleted and can't get any from the global pool. The big question is why the denied counter doesn't report anything. I've looked at the code paths and don't see any obvious reason why it doesn't get counted. Maybe Robert can give some insight here. Try doubling the amount of 4k page size jumbo mbufs. They are the primary workhorse in the kernel right now: sysctl kern.ipc.nmbjumbop=25600 This should get further. Still more may be necessary depending on workloads. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Not All Symbols Present in a Loadable Kernel Module
On Thu, May 1, 2008 at 10:04 PM, David Christensen <[EMAIL PROTECTED]> wrote: > I'm trying to build the "bce" driver as a kernel module under RELENG_7 but I'm > finding that not all of the functions in the driver are exported as symbols. > This > makes it difficult to "call" a function from ddb because I get the error > "Symbol > not found". I'm building and loading the driver from > /usr/src/sys/modules/bce. > What am I doing wrong? How can I get all functions in the driver exported as > symbols usable by the debugger? Are you building a debug kernel or regular kernel? Have you turned on debug symbols? makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols Just a quick thought...I'm assuming these symbols are listed under your final kernel image (nm it etc.). -aps ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/123330: [nsswitch] Enabling samba wins in nsswitch.conf causes sshd, ftpd, etc services to die
Old Synopsis: Enabling samba wins in nsswitch.conf causes sshd, ftpd, etc services to die New Synopsis: [nsswitch] Enabling samba wins in nsswitch.conf causes sshd, ftpd, etc services to die Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 2 20:55:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123330 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
Julian Elischer wrote: OLSR is an overlay network Nope -- the express intention was that it could be used for basic IP connectivity, for mobile devices. In OLSR, every node is a potential IP forwarder unless it explicitly advertises itself as being unwilling to forward. and any machine that participated must have a split personality. First it must be able to think in terms of the basic local network, and it must be able to think in terms of the world from the perspective of the overlay. Applying routing policy gets more important at the border. The OLSR implementation in XORP is intended to give people a means of connectivity between MANET and non-MANET routing domains, by redistributing routes into the OLSR cloud. I daresay these capabilities will get more important, and relevant, to the MANET picture as time goes on, but it's best to leave them out of the operational picture for now, in my opinion. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple routing tables review patch ready for simple testing.
John Hay wrote: You don't need to go to the kernel for this sort of thing unless you specifically need to implement route policy based on which interface(s) a packet came in on. Yes I know that. But in the world of adhoc wireless mesh networking there are very few non-linux people, so they basically call the shots and use the linux kernel features to the full. Not true. There's an awful lot going on behind closed doors in the MANET world, and from the sounds of the emanations, they might not be using Linux at all. In a sense I can understand them because their stuff also run on the small embedded stuff like the linksys wireless boxes and it needs to scale. The biggest adhoc olsr network is probably the Freifunk one that have more than 600 wireless nodes, mostly consisting of linksys boxes. The complexity of any system like that is still there, regardless of whether or not people choose to make it harder to debug code by prematurely pushing it into the kernel. On some boxes that are also connected to different kinds of networks, they run a different routing daemon into another fib and by setting the priorities on the fibs, they can decide which daemon's routes have the highest priority. And both routing daemons are happy because the other is not stomping on its feet. Yes, but this is largely to do with the fact that the Linux netlink socket allows daemons to coexist due to its use of a tag-length-value which captures that information, a different kettle of fish. The feature you describe is totally possible without adding complexity to Julian's current effort. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Not All Symbols Present in a Loadable Kernel Module
> > I'm trying to build the "bce" driver as a kernel module under > RELENG_7 but I'm > > finding that not all of the functions in the driver are exported as > symbols. This > > makes it difficult to "call" a function from ddb because I get the > error "Symbol > > not found". I'm building and loading the driver from > /usr/src/sys/modules/bce. > > What am I doing wrong? How can I get all functions in the driver > exported as > > symbols usable by the debugger? > > Are you building a debug kernel or regular kernel? Have you turned on > debug symbols? > > makeoptions DEBUG=-g# Build kernel with gdb(1) > debug symbols > > Just a quick thought...I'm assuming these symbols are listed under > your final kernel image (nm it etc.). Yes, I'm building a debug kernel. I have the line listed above as well as the following: options KDB options DDB options GDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN Dave ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: authentication timeouts with ath(4) in hostap mode
Petar Bogdanovic wrote: Hi, I'm using an alix2c0 board with two winstron CM9 ath(4)-cards and FreeBSD 7: ifconfig ath0 (...) mediaopt hostap mode 11a channel 36 ssid sn.a -bgscan ifconfig ath1 (...) mediaopt hostap mode 11g channel 11 ssid sn.g -bgscan When I try to raise the traffic (i.e. dd | ssh AP dd) my Linux wpa_supplicant drops the connection and has to reassociate. This however does not work immediately; The supplicant fails a few times before reconnecting: <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Authentication with 00:0b:0b:06:0d:09 timed out. <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) <2>Associated with 00:0b:0b:06:0d:09 <2>WPA: Key negotiation completed with 00:0b:0b:06:0d:09 [PTK=CCMP GTK=CCMP] <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] This happens more on the 11a than on the 11g network. When I'm next to the AP, the timeouts are almost gone but they still happen. (My laptop is just one room away from the AP). Here is the athstats-output of ath0 (11a): # ./athstats -i ath0 481546 data frames received 330669 data frames transmit 13395 tx frames with an alternate rate 78558 long on-chip tx retries 1431 tx failed 'cuz too many retries 36M current transmit rate 78 tx management frames 3 tx frames discarded prior to association 45 tx frames with no ack marked 2894 rx failed 'cuz of bad CRC 2 rx failed 'cuz decryption 92711 rx failed 'cuz of PHY err 92708 OFDM timing 3 OFDM restart 318332 beacons transmitted periodic calibrations 2 rfgain value change 22 rssi of last ack 23 avg recv rssi -96 rx noise floor 2530 switched default/rx antenna Antenna profile: [1] tx 173364 rx 123068 [2] tx 155874 rx 358671 So the obvious question is whether your system config has enough isolation of the radios for them not to impact each other? I have no experience with Alix boards but it's not uncommon for there to be power and signal issues when operating multiple radios in an enclosure (and yes, even with the radios on different bands). You don't indicate what you've done to diagnose this problem. Have you verified the packets are present in the air? Have you traced packets and/or phy errors around the time of the problem? Does turning off one radio give you stable operation? Have you tried different channels? Have you tried different boards? All this is well known to me, since I had NetBSD running on this device for months and it suffered the same problems -- it was even worse, the timeouts occured every few minutes. Back then, it seemed that ath had some interrupt problems: ath0: device timeout as David Young from NetBSD noticed in his mail some time ago: http://mail-index.netbsd.org/tech-net/2007/11/29/0001.html FreeBSD doesn't seem to have this `device timeouts'. I don't see any in /var/log/messages and there are none when I'm connected to the device over a serial port. I'm a bit lost here, but ready to debug if someone knows more. netbsd's code base is many _years_ out of date wrt freebsd; comparing operation of the two systems is unlikely to be useful. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network Instability when upgrading to 4GB of RAM
All, As a follow up to myself I installed an Intel PCIe NIC and disabled the on board RTL based one and all my problems went away. Been running with 4GB installed for a couple days now with absolutely no network issues. So seems like there's some problem with RTL NICs and >= 4GB of RAM. -- Paul Haddad ([EMAIL PROTECTED] [EMAIL PROTECTED]) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
