[ath] IBM 802.11B B/G 39T0073 card doesn't work in 8-STABLE but worked in 7-STABLE

I upgraded my Thinkpad from 7-STABLE to 8-STABLE a few weeks ago and now my wireless card no longer works. It is recognized, but appears to be somewhat brain dead. # ifconfig ath0 ath0: flags=8802 metric 0 mtu 2290 ether 00:16:ce:00:ac:a7 media: IEEE 802.11 Wireless Ethernet autos

Re: [ath] IBM 802.11B B/G 39T0073 card doesn't work in 8-STABLE but worked in 7-STABLE

On 6 Aug, Mike Tancsa wrote: > At 03:59 PM 8/6/2010, Don Lewis wrote: >># ifconfig ath0 up >># ifconfig ath0 >>ath0: flags=8843 metric 0 mtu 2290 >> ether 00:16:ce:00:ac:a7 >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >>

Re: Can I make this simple ipfw ruleset any more restrictive ?

On 9 Sep, John Case wrote: > > I have a very simple firewall - it*blocks everything*, and the only > traffic that is allowed is for internal clients to make outbound > connections to tcp port 40. > > Also, internal clients can ping/traceroute. > > But that's it - no other connections in or ou

Re: A defensive NFS server (sbwait, flow control)

On 12 Mar, Tim Borgeaud wrote: > Hi again FreeBSD folks, > > A short while ago I sent a couple of emails regarding the idea of 'fair > share' NFS scheduling. Amongst others, Garrett Wollman replied, and also > sent a related email "Implementing backpressure in the NFS server". The > common theme:

a couple /etc/rc.firewall questions

The example /etc/rc.firewall has provisions to use either in-kernel NAT or natd for the open and client firewall types, but the simple filewall type only has code for natd. Is there any reason that in-kernel NAT could not be used with the simple firewall type? After allowing connections to select

Re: a couple /etc/rc.firewall questions

On 23 Aug, Ian Smith wrote: > On Sun, 23 Aug 2015 08:44:53 +0900, Hiroki Sato wrote: > > Don Lewis wrote > > in <201508222103.t7ml3gax000...@gw.catspoiler.org>: > > > > tr> The example /etc/rc.firewall has provisions to use either in-kernel NAT >

Re: a couple /etc/rc.firewall questions

On 23 Aug, Hiroki Sato wrote: > Don Lewis wrote > in <201508222103.t7ml3gax000...@gw.catspoiler.org>: > > tr> The example /etc/rc.firewall has provisions to use either in-kernel NAT > tr> or natd for the open and client firewall types, but the simple filewall > t

Re: a couple /etc/rc.firewall questions

On 24 Aug, Hiroki Sato wrote: > Don Lewis wrote > in <201508240052.t7o0qsff002...@gw.catspoiler.org>: > > tr> > A TCP setup packet coming from a host on the internal LAN to the NAPT > tr> > router falls into the last deny-all rule because it does not mat

CoDel and ECN questions

Bufferbloat on my DSL link to the outside world has been bugging me lately. I was considering adding an OpenWrt box between my DSL modem and my FreeBSD firewall in order to get CoDel, when I discovered that CoDel had been quietly added to FreeBSD 11. Unfortunately the documentation is severely la

Re: default ECN settings

On 4 Sep, K. Macy wrote: > By default ECN is completely disabled on FreeBSD. On Linux the default > is to disable it outbound (not request it) but enable it inbound > (accept new connections asking for it). Is there a good reason to only > set ECN_PERMIT on inbound connections if the system is doi

Re: CoDel and ECN questions

On 1 Sep, Don Lewis wrote: > Bufferbloat on my DSL link to the outside world has been bugging me > lately. I was considering adding an OpenWrt box between my DSL modem > and my FreeBSD firewall in order to get CoDel, when I discovered that > CoDel had been quietly added t

Re: AQMs for FreeBSD

On 28 Sep, grenville armitage wrote: > All, > > With the support of a small grant from Comcast's TechFund, I and one > of my students will soon start working with over the next 6+ months to > implement codel, PIE, fq_codel and fq_PIE in FreeBSD's dummynet. We're > doing this in large part test the

Re: An ISN(initial sequence number) bug?

On 13 Aug, Huang, Yusheng wrote: > Hi, > > > > I think there is a bug in the tcp_isn_tick() function. > > > >1477 static void > >1478 tcp_isn_tick(xtp) > >1479 void *xtp; > >1480 { > >1481 u_int32_t projected_offset; > >1482 > >1483 INP_INFO_WL

Re: net.inet.ip.portrange.randomized=1 hurts

On 2 Jun, Dmitry Pryanishnikov wrote: > > Hello! > >> Date: Tue, 1 Jun 2004 19:07:35 -0500 (CDT) >> From: Mike Silbersack <[EMAIL PROTECTED]> >> >> On Tue, 1 Jun 2004, Andre Oppermann wrote: >> >>> A port should not be reused this fast. Maybe the randomness isn't >>> so random after a

Re: Fixing "Slipping in the window" before 4.11-release

On 3 Jan, Mike Silbersack wrote: > > With re's permission, I'm going to commit FreeBSD's fix for the RST part > of the slipping in the window attack to 4.11 in the next few days. That's > not a big deal, we seem to have an acceptable solution there. (See > tcp_input.c rev 1.235 for more info

Re: Fixing "Slipping in the window" before 4.11-release

On 3 Jan, Don Lewis wrote: > /* > * If a SYN is in the window, then this is an > * error and we send an RST and drop the connection. > */ > if (thflags & TH_SYN) { > if (tcp_insecure_syn == 0) >

Re: Fixing "Slipping in the window" before 4.11-release

On 3 Jan, Mike Silbersack wrote: > > On Mon, 3 Jan 2005, Don Lewis wrote: > >>> For the life of me, I can't figure out why SYN packets (other than delayed >>> retransmissions of the original SYN) would ever show up once a connection >>> is in the ESTA

Re: Fixing "Slipping in the window" before 4.11-release

On 4 Jan, Mike Silbersack wrote: > > On Mon, 3 Jan 2005, Don Lewis wrote: >> I'm not sure that it makes sense to rate limit the ACKs in this special >> case. If an attacker has enough information to trigger an ACK response >> flood from the hardened stack, he c

Re: Slipping in the window update

On 9 Jan, Mike Silbersack wrote: > > Ok, here's an updated patch for the SYN case. I've included the patch > relative to 6.x, and some text from a tcpdump showing it in action. > > It responds to each SYN with an ACK like the latest tcpsecure document > states, but it uses a global counter to

Re: Slipping in the window update

After a bit more thinking ... On 10 Jan, Don Lewis wrote: > and then after the dropafterack label add the code: > > + if (thflags & TH_SYN) { > + if (tp->t_state == TCPS_ESTABLISHED && > + tcp_insecure_syn == 0) { > +

Re: Slipping in the window update

On 10 Jan, Mike Silbersack wrote: > > On Mon, 10 Jan 2005, Don Lewis wrote: > >> Now that I've looked at the above case, it looks to me like your >> suggested patch might affect the response to a legitimate duplicate SYN. >> It will definitely follow a different

Re: known TCP vulnerability ??

On 11 Feb, Andre Oppermann wrote: > "Li, Qing" wrote: >> >> http://www.kb.cert.org/vuls/id/464113 >> >> http://www.linuxsecurity.com/content/view/104980/98/ >> >> Ran the packet tests against FreeBSD 5.3 and 6-CURRENT and both >> respond to the SYN+FIN packets wit

Re: 6rd: when in Base FreeBSD?

On 11 Oct, Larry Rosenman wrote: > Hi, >I'm currently using pfSense, and it has a working 6rd implementation, and > I need 6rd > as that's how ATT Fiber delivers IPv6. > >Apparently for whatever reason, the pfSense guys can't/won't upstream or > release their 6rd > patch. (see https://f

Re: 6rd: when in Base FreeBSD?

On 11 Oct, Larry Rosenman wrote: > On Thu, Oct 12, 2017 at 01:54:10AM +0000, Don Lewis wrote: >> On 11 Oct, Larry Rosenman wrote: >> > Hi, >> >I'm currently using pfSense, and it has a working 6rd implementation, >> > and I need 6rd &

Re: IPv6 fragment reassembly regression following FreeBSD-SA-18:10.ip

On 23 Sep, John W. O'Brien wrote: > I'd like to check my understanding and then ask a procedural question. > > FreeBSD-SA-18:10.ip [0], released on 08/14, was resolved by r337828 [1]. > That changeset, resulting in 11.1R-p13 and 11.2R-p2, included a patch to > the way IPv6 fragment reassembly is h

Re: IPv6 fragment reassembly regression following FreeBSD-SA-18:10.ip

On 24 Sep, John W. O'Brien wrote: > On 9/23/18 17:50, Don Lewis wrote: >> On 23 Sep, John W. O'Brien wrote: >>> I'd like to check my understanding and then ask a procedural question. >>> >>> FreeBSD-SA-18:10.ip [0], released on 08/14, was resolv

Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet

On 26 Feb, Rasool Al-Saadi wrote: > Dear all, > > I would like to announce that we (myself and Grenville Armitage) > released Dummynet AQM v0.1, which is an independent implementation of > CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on the > IETF CoDel [1] and FQ-CoDel [2] Int

Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet

On 26 Feb, Rasool Al-Saadi wrote: > Dear all, > > I would like to announce that we (myself and Grenville Armitage) released > Dummynet AQM v0.1, which is an independent implementation of CoDel and > FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on the IETF CoDel [1] > and FQ-CoDel [2]

Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet

On 10 Mar, Rasool Al-Saadi wrote: > > > On Wednesday, 9 March 2016, Don Lewis wrote: >> >> On 26 Feb, Rasool Al-Saadi wrote: >> > Dear all, >> > >> > I would like to announce that we (myself and Grenville Armitage) >> > released >&g

Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet

On 26 Feb, Rasool Al-Saadi wrote: > Dear all, > > I would like to announce that we (myself and Grenville Armitage) released > Dummynet AQM v0.1, which is an independent implementation of CoDel and > FQ-CoDel for FreeBSD's ipfw/dummynet framework, based on the IETF CoDel [1] > and FQ-CoDel [2]

Re: Dummynet AQM v0.1- CoDel and FQ-CoDel for FreeBSD's ipfw/dummynet

On 9 Mar, To: ralsa...@swin.edu.au wrote: > On 10 Mar, Rasool Al-Saadi wrote: >> >> >> On Wednesday, 9 March 2016, Don Lewis wrote: >>> Without the patch below, the dummynet module fails to load >>> >>> # kldload dummynet.ko >>> k

changing net.inet.tcp.ecn.enable=1 to a three-way knob

I posted a patch here: to change net.inet.tcp.ecn.enable from a binary off/on knob to a three way knob that adds a setting allow incoming TCP connections to negotiate ECN while outgoing connections don't request ECN. Always requesting ECN on outgoing connections

dummynet + CoDel, FQ-Codel, PIE, and FQ-PIE

I'd like to see us get these patches committed to HEAD in time for 11.0-RELEASE: I've been running this stuff on my firewall box for a few months and it has tamed the latency problems I was having with my DSL connection to the internet whenever

Re: dummynet + CoDel, FQ-Codel, PIE, and FQ-PIE

On 16 May, To: freebsd-net@FreeBSD.org wrote: > I'd like to see us get these patches committed to HEAD in time for > 11.0-RELEASE: > > I've been running this stuff on my firewall box for a few months > and it has tamed the latency problems I was

Re: dummynet + CoDel, FQ-Codel, PIE, and FQ-PIE

On 16 May, To: freebsd-net@FreeBSD.org wrote: > On 16 May, To: freebsd-net@FreeBSD.org wrote: >> I'd like to see us get these patches committed to HEAD in time for >> 11.0-RELEASE: >> >> I've been running this stuff on my firewall box for a few

Re: Dummynet AQM version 0.2.1

On 17 May, Nikolay Denev wrote: > Hi Rasool, > > Is the patch supposed to work if DUMMYNET is compiled in the kernel? > I've applied it and rebuilt my kernel by I still see only FIFO, PRIQ, > QFQ, RR and WF2Q+ in dmesg. I suspect that the new files need to be added to /usr/src/sys/conf/files. __

Re: Dummynet AQM version 0.2.1

On 17 May, To: nik...@cytexbg.com wrote: > On 17 May, Nikolay Denev wrote: >> Hi Rasool, >> >> Is the patch supposed to work if DUMMYNET is compiled in the kernel? >> I've applied it and rebuilt my kernel by I still see only FIFO, PRIQ, >> QFQ, RR and WF2Q+ in dmesg. > > I suspect that the new fi

IPv6 -> IPv4 fallback broken in serf, kernel bug?

Serf has some code to fall back from IPv4 if an IPv6 and more generally try different addresses on multi-homed servers if connection attempts fail, but it does not work properly on recent versions of FreeBSD. I've tested both recent FreeBSD 10.3-STABLE and HEAD. The way that it is supposed to work

Re: IPv6 -> IPv4 fallback broken in serf, kernel bug?

On 26 Jul, Don Lewis wrote: > It looks like it should be possible to patch serf to handle this, but: > * Should POLLIN be set for this event? I don't think it should, but the standard doesn't cover this case. On a successful non-blocking connect(), our man page says tha

Re: IPv6 -> IPv4 fallback broken in serf, kernel bug?

On 26 Jul, Karl Denninger wrote: > On 7/26/2016 10:59, Don Lewis wrote: >> Serf has some code to fall back from IPv4 if an IPv6 and more generally >> try different addresses on multi-homed servers if connection attempts >> fail, but it does not work properly on recent vers

Re: IPv6 -> IPv4 fallback broken in serf, kernel bug?

On 27 Jul, Bruce Evans wrote: > On Tue, 26 Jul 2016, Don Lewis wrote: > >> Serf has some code to fall back from IPv4 if an IPv6 and more generally >> try different addresses on multi-homed servers if connection attempts >> fail, but it does not work properly on recent v

Re: IPv6 -> IPv4 fallback broken in serf, kernel bug?

After giving this some more thought, I believe that the read and write wakeups are correct when the connection attempt fails. I also think that read() should return ENOTCONN if the socket never got to the connected state. I'm not sure how write() should behave. The Open Group Base Specifications

Re: IPv6 -> IPv4 fallback broken in serf, kernel bug?

On 26 Jul, Karl Denninger wrote: > On 7/26/2016 10:59, Don Lewis wrote: >> Serf has some code to fall back from IPv4 if an IPv6 and more generally >> try different addresses on multi-homed servers if connection attempts >> fail, but it does not work properly on recent vers

Re: IPv6 -> IPv4 fallback broken in serf, kernel bug?

On 26 Jul, Karl Denninger wrote: > On 7/26/2016 10:59, Don Lewis wrote: >> Serf has some code to fall back from IPv4 if an IPv6 and more generally >> try different addresses on multi-homed servers if connection attempts >> fail, but it does not work properly on recent vers

inheriting fib from an interface

Let's say that I have an application running on a server that is connected to the Internet via two different ISPs and is using IP addresses (ISP A:10.0.0.10 and ISP B:192.168.1.10) delegated by those two ISPs on it's two interfaces. Responses to requests sent to 10.0.0.10 should be sent via ISP A,

Re: inheriting fib from an interface

On 24 Jan, Eugene Grosbein wrote: > On Mon, Jan 23, 2017 at 05:31:22PM -0800, Don Lewis wrote: > >> Let's say that I have an application running on a server that is >> connected to the Internet via two different ISPs and is using IP >> addresses (ISP A:10.0.0.10 and

Re: Ratelimint Enhancement patch (Please Review One Last Time!)

On Dec 13, 2:42pm, "Richard A. Steenbergen" wrote: } Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) } On Wed, 13 Dec 2000, Alfred Perlstein wrote: } > Suppressing outgoing RST due to high rate of connections on an unopen } > port (possible portscan): 202/200 pps } } It

Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h

On Dec 18, 6:26pm, Jesper Skriver wrote: } Subject: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_ } Hi, } } I'm trying to find out what to to now regarding this. } } To summarize. } } PHK committed my original patch, this patch have the following } functionality } - When a

Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h

On Dec 19, 7:19pm, Jesper Skriver wrote: } Subject: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c } } I'll submit a new later tonight, as I havn't heard anything, I'll make a } sysctl control if it should have effect on all sessions, or only those } in SYN-SENT state, default

Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h

On Dec 19, 10:27pm, Jesper Skriver wrote: } Subject: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c } } --17pEHd4RhPHOinZp } Content-Type: text/plain; charset=us-ascii } Content-Disposition: inline } } On Mon, Dec 18, 2000 at 06:26:00PM +0100, Jesper Skriver wrote: } > Hi, } >

Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h

On Dec 20, 3:51pm, Jesper Skriver wrote: } Subject: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c } On Wed, Dec 20, 2000 at 02:46:21AM -0800, Don Lewis wrote: } } > } It has the following functionality. } > } } > } - If the sysctl net.inet.tcp.icmp_admin_prohib

ICMP error processing (was: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h)

[ cc: trimmed ] On Dec 31, 9:07pm, Jesper Skriver wrote: } Subject: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c } On Wed, Dec 20, 2000 at 03:51:18PM +0100, Jesper Skriver wrote: } > On Wed, Dec 20, 2000 at 02:46:21AM -0800, Don Lewis wrote: } > } > > } @@ -7

Re: Spoofing multicast addresses

[ freebsd-net added ] On Jan 9, 6:58pm, Wes Peters wrote: } Subject: Re: Spoofing multicast addresses } Mike Silbersack wrote: } > } > The check is done when the SYN is received, hence such a situation as you } > describe should not be able to occur. } > } > >From tcp_input.c: } > } >

Re: Spoofing multicast addresses

On Jan 10, 1:13am, Mike Silbersack wrote: } Subject: Re: Spoofing multicast addresses } } On Wed, 10 Jan 2001, Wes Peters wrote: } } > Don Lewis wrote: } > > A good reason for putting these checks in their present location is } > > that it gets them out of the main code path

Re: Spoofing multicast addresses

On Jan 10, 12:05am, Wes Peters wrote: } Subject: Re: Spoofing multicast addresses } The real problem with the "stream" attack was not the volume of incoming } SYN packets, but the reflector nature of the attack when using forged } multicast source addresses. The code did not correctly "ignore" t

Re: ICMP error processing (was: Re: what to do now ? Was: cvs commit: src/sys/netinet ip_icmp.c tcp_subr.c tcp_var.h)

On Jan 9, 6:16pm, Jesper Skriver wrote: } Subject: Re: ICMP error processing (was: Re: what to do now ? Was: cvs co } On Mon, Jan 08, 2001 at 11:02:17PM -0800, Don Lewis wrote: } > In the current code, it looks like an ICMP error that the addresses } > and ports zeroed out will erron

Re: cvs commit: src/sys/netinet ip_input.c

On Feb 27, 11:43am, Jonathan Lemon wrote: } Subject: cvs commit: src/sys/netinet ip_input.c } jlemon 2001/02/27 11:43:14 PST } } Modified files: } sys/netinet ip_input.c } Log: } When iterating over our list of interface addresses in order to determine } if an arriving

Re: New TCP sequence number generation algorithm; review needed

On Jun 8, 12:56am, Mike Silbersack wrote: } Subject: New TCP sequence number generation algorithm; review needed [ snip ] } Q: How does this new patch generate sequence numbers? } } A: In short, the patch provides a seperate sequence number space for each } host. These sequence spaces have n

Re: questions about TCP RST validity

On 1 Jul, Tom Pavel wrote: > > Hi. I'm confused about some code dealing with the acceptance of RSTs > in tcp_input.c. I've gleaned what I can about the history of that > code through the CVS repository, but I'm still looking for some more > insight. The code in question requires that a RST ha

Re: Bind to specific address on FreeBSD

On 9 Jul, Chris Given wrote: > I can't figure out why this code won't bind to 127.0.0.1 on FreeBSD. I get > an error "Can't assign requested address". > > struct sockaddr_in dp; > unsigned long bind_to_addr = inet_addr("127.0.0.1"); > > sock = socket(PF_INET, SOCK_STREAM, IPP

Re: CFR: m_tag patch

On 7 Oct, Nate Lawson wrote: > On Mon, 7 Oct 2002, Julian Elischer wrote: >> it is just working on the principal that there is not going to be >> a collision in the 32 bit space. Especially when we create them from >> "time since the epoch", and when teh various authors can see each >> other's

Re: CFR: m_tag patch

On 8 Oct, Harti Brandt wrote: > On Mon, 7 Oct 2002, Don Lewis wrote: > DL>Why not name them? At boot or module load time stuff the name in a > DL>table and use the table index as the 16 bit ID. Is there any reason the > DL>ID has to be the same each time the system is b

Re: Configure wireless connection using Cisco aironet 350

On 1 Dec, Doug Ambrisko wrote: > Imrani writes: > [ Charset ISO-8859-1 unsupported, converting... ] > | Hi, > | > | I am trying to configure Cisco Aironet 350 wireless PCI card but I > | get an error which I am unable to find much details for that. Following > | is description of ifconfing

Re: Request for Review: bin/54151

On 6 Jul, Dmitry Morozovsky wrote: > Dear colleagues, > > would you please spend a bit of your time to review > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/54151 > [patch to add -i option to arp(8)]? > > Thanks in advance; please keep me CC:d as I'm not subscribet to -net. The first patch lo

Re: broadcast udp packets ...

On 11 Jul, Wes Peters wrote: > What we observed on our embedded system is the packet gets sent on all > attached interfaces, with dest IP 255.255.255.255, and a src IP of the > local address that has the default route. If there isn't a default > route, sending to 255.255.255.255 fails with "n

Re: Kernel tuning for large maxsockets

On 15 Jul, Mike Silbersack wrote: > > On Tue, 15 Jul 2003, Scot Loach wrote: > >> Is there any reason I should not modify the kernel code to only let a small, >> fixed number of raw and divert pcbs be preallocated instead of having them >> scale with maxsockets? > > Your idea is sound. > >> Nex

Re: HEADS UP: network locking work going on

On 19 Aug, Sam Leffler wrote: > Once the work on the lower layer is stable I'll be turning my attention to > the upper layers of the network and to IPv6 and NFS. There's plenty of > work to go around, so if you're interested in participating please let me > know. BTW, there is a buf vs. vnode

Re: problems caused by net.inet.tcp.blackhole=2

On 8 Nov, Michal wrote: > Hello, > maybe someone will be able to help me with the problem. Namely setting > net.inet.tcp.blackhole=2 make samba to start very slow (90sec). Also > smbclient is slow. After samba starts there is no delay to connect from > the another machine with persistant local

Re: problems caused by net.inet.tcp.blackhole=2

On 10 Nov, Joerg Pernfuss wrote: > On Sat, 8 Nov 2003 15:25:18 -0800 (PST) > Don Lewis <[EMAIL PROTECTED]> wrote: > >> On 8 Nov, Michal wrote: >> > Hello, >> > maybe someone will be able to help me with the problem. Namely setting >> > net.in

panic in in6_ifdetach()

I was testing one of Warner's patches on my laptop and found that it paniced during boot. The trigger was that fxp0 couldn't gets its irq configured in fxp_attach(), so it called ether_ifdetach(), which eventually ended up calling in6_ifdetach(), which blew up at the line of code marked below:

Re: Paper on device polling and packet capture performance

On 11 Jan, Bruce M Simpson wrote: > On Fri, Jan 09, 2004 at 03:51:43PM -0600, Guy Helmer wrote: >> I want to look at memory-mapped access to the BPF device. >> This would preserve the existing network device drivers >> while reducing mbuf copies, context switches/user-kernel >> transitions, and lat

Re: jumbo-frames on the network

On 28 Jan, Garrett Wollman wrote: > < >> Can different MTUs be mixed on the same wire > > No. It's ugly, but I wonder if adding host routes with the -lock -mtu options might work ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/l

Re: My planned work on networking stack

On 1 Mar, Andre Oppermann wrote: > [] move ARP out of the routing table and instantiate it once per ethernet > broadcast domain. (started) Applause! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsub

Re: Frozen connections

On 3 Mar, Eugene Grosbein wrote: > H! > > I'm experiencing strange problems with HTTP connections between > two machines connected using 100Mbit ethernet switch. > Client is Windows 2000 SP4 (named kost), > server is FreeBSD 4.9/Apache 1.3.27 (named www). > --