bridge interface vs. altq
I recently upgraded a system from FreeBSD 9.2 to 12.1-BETA1 and found that pf on the new system complained that my bridge interface did not support ALTQ (worked fine on 9.2) The new kernel is built with OPtions ALTQ options ALTQ_CBQ options ALTQ_CODEL options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ALTQ_FAIRQ options ALTQ_NOPCC and it seems to have no issues configuring altq on "re" and "dc" interfaces. I searched but could not find any mention of removal of altq support from "bridge," and in fact the current handbook seems to indicate it is supported [www.freebsd.org/doc/handbook/network-bridging.html]: Note: Packet filtering can be used with any firewall package that hooks into the pfil(9) framework. The bridge can be used as a traffic shaper with altq(4) or dummynet(4). What am I missing? thanks! -- G. Paul Ziemba FreeBSD unix: 7:46PM up 4:50, 9 users, load averages: 0.52, 0.41, 0.32 ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: vimage vs. ipfilter
jul...@elischer.org (Julian Elischer) writes: [vimage compatibility in 8.0] ipfw is, (experimentally) and pf has patches to make it so. Thanks for your reply (and for your vimage efforts). I'd like to try vimage + pf and searched for the patch (including freebsd-pf and freebsd-virtualization list archives) but couldn't find it. Do you have a pointer? thanks, ~!paul -- G. Paul Ziemba FreeBSD unix: 11:06PM up 29 days, 47 mins, 26 users, load averages: 0.21, 0.20, 0.21 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
vimage vs. ipfilter
Can anyone comment on the usability of ipfilter with an 8.X kernel built with options VIMAGE ? I'm seeing a fatal kernel trap when rc.mumble starts to configure ipfilter during the boot sequence. I'm using 8.0-RC1. many thanks! -- G. Paul Ziemba FreeBSD unix: 8:41AM up 24 days, 10:22, 21 users, load averages: 0.18, 0.25, 0.24 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: How to port/build TCP/IP Stack.
boseatj...@yahoo.com (bose vemuri) writes: Actually we need to implement TCP/IP stack on B oot Loader(MIPS). We are planning to port FreeBSD TCP/IP Stack. Please help me out how can i proceed further. An experienced developer could port IP, UDP, and TCP to an existing embedded system that already has an ethernet (or whatever lower layer you need) driver in a few weeks. You'll need to grab appropriate files from /usr/src/sys/netinet as well as the socket and mbuf related files from /usr/src/sys/kern and then connect it to the network driver for your physical interface. -- G. Paul Ziemba FreeBSD unix: 9:01PM up 13:05, 11 users, load averages: 0.02, 0.07, 0.07 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
should tcp_reass() update tcps_rcvpartduppack, tcps_rcvpartdupbyte?
This is just a nit, but it seems to me that although the code
in tcp_reass() counts completely overlapping packets via the
statistics tcps_rcvduppack and tcps_rcvdupbyte, it does NOT
count partially overlapping packets as it should with
tcps_rcvpartduppack and tcps_rcvpartdupbyte.
I'm thinking that the following change ought to do the
right thing, but I'd like to know if anyone disagrees:
--- tcp_input.c Sat Dec 15 03:23:56 2001
+++ tcp_input.c+Tue Mar 26 11:04:35 2002
@@ -223,6 +223,9 @@
* completes.
*/
goto present; /* ??? */
+ } else {
+ tcpstat.tcps_rcvpartduppack++;
+ tcpstat.tcps_rcvpartdupbyte += *tlenp;
}
m_adj(m, i);
*tlenp -= i;
--
G. Paul Ziemba [EMAIL PROTECTED]
FreeBSD unix:
12:36PM up 1 day, 2:44, 9 users, load averages: 0.04, 0.04, 0.01
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
