Re: IP_MAX_MEMBERSHIPS story.
On Thu, May 11, 2006 at 11:12:29PM -0400, Stephen Clark wrote: > >I'm loosely of the opinion that the membership array should be > >variable length, and that we should default it to 20, but have a > >significantly larger maximum. It's not horribly efficient, but also > >wouldn't be so particularly terrible either. > > I think it should be tunable other than going in a changing the source > code, which I have to do every time I do a cvsup. This is the express intention of such a change. The problem the user(s) are having is because each imo_membership member's cardinality of relationship is 1:1 with respect to each multicast group membership and each ifnet interface upon which the membership is established. Therefore, joining the same group 20 times on different interfaces would exceed IP_MAX_MEMBERSHIPS. Fixing this in any way would still break the ip_mroute_kmod ABI and as such is a HEAD change. Based on Robert's feedback I would therefore make a change such that imo_membership is dynamically sized at runtime, rather than making IP_MAX_MEMBERSHIPS a load-time tunable. Based on reading of the code it looks like it may be best that imo_moptions becomes a pointer, not an array. I am happier with this kind of change because it is less invasive to other parts of netinet, and also because it fits in with the lazy allocation which already exists viz ip_findmoptions(). It is also much simpler -- the complexity belongs in ip_findmoptions() and ip_freemoptions(). Further feedback hoped for. I will post patches soon. Regards, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[patch] ipfw packet tagging
Hi, All! I've tried Andrey Elsukov's ipfw "tag/tagged" patches from: http://butcher.heavennet.ru/patches/kernel/ipfw_tags/ Tested on 5.5-PRERELEASE production server with moderate load - rock stable [I've also looked through the code - patch is small, so it simply can't be any bugs there ;)]. Personally I very like the idea from original Andrey's letter about possibility to make a netgraph(4) node able to mark packets: this is a potential ability to build fast (in-kernel) level 7 firewall / traffic filter without need to fully duplicate entire TCP/IP stack in this marking node - that's ipfw's work. For example, rules can look like this: # node marks traffic as good or bad based on first packets in the flow node=300 good=1 bad=2 check-state # here most sorted traffic goes netgraph $node all from any to any # divert unmarked traffic to node deny all from any to any tagged $bad allow all from any to any tagged $good keep-state -- WBR, Vadim Goncharov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] ipfw packet tagging
Vadim Goncharov wrote: Hi, All! I've tried Andrey Elsukov's ipfw "tag/tagged" patches from: http://butcher.heavennet.ru/patches/kernel/ipfw_tags/ Tested on 5.5-PRERELEASE production server with moderate load - rock stable [I've also looked through the code - patch is small, so it simply can't be any bugs there ;)]. Personally I very like the idea from original Andrey's letter I have tested on 6.1 and works fine too. Hope it gets commited. Very useful for altq/dummynet flexibility too. -- Patrick Tracanelli ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] ipfw packet tagging
On Fri, May 12, 2006 at 10:32:22AM -0300, Patrick Tracanelli wrote: > Vadim Goncharov wrote: > > Hi, All! > > > > I've tried Andrey Elsukov's ipfw "tag/tagged" patches from: > > http://butcher.heavennet.ru/patches/kernel/ipfw_tags/ > > > > Tested on 5.5-PRERELEASE production server with moderate > > load - rock stable [I've also looked through the code - patch > > is small, so it simply can't be any bugs there ;)]. > > > > Personally I very like the idea from original Andrey's letter > > I have tested on 6.1 and works fine too. > > Hope it gets commited. Very useful for altq/dummynet flexibility too. i would, however, like to have a bit more documentation in the patch, in particular: - a manpage patch describing how to use the thing, and also the behaviour in in odd situations (e.g. what happens when we try to tag a packet multiple times ? does the tag survive between the 'input' and 'output' path of ipfw for routed packets, etc ?). I can look this up in the code, but the average user cannot, and the patch does not contain a single line of comment, plus we generally want to have some textual description of the behaviour (so we can RTFM), not just an implementation without comments. - more comments in the code, per the above. cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] ipfw packet tagging
12.05.06 в 20:53 Luigi Rizzo wrote: > I've tried Andrey Elsukov's ipfw "tag/tagged" patches from: > http://butcher.heavennet.ru/patches/kernel/ipfw_tags/ > > Tested on 5.5-PRERELEASE production server with moderate > load - rock stable [I've also looked through the code - patch > is small, so it simply can't be any bugs there ;)]. > > Personally I very like the idea from original Andrey's letter I have tested on 6.1 and works fine too. Hope it gets commited. Very useful for altq/dummynet flexibility too. i would, however, like to have a bit more documentation in the patch, in particular: - a manpage patch describing how to use the thing, and also the behaviour in in odd situations (e.g. what happens when we try to tag a packet multiple times ? does the tag survive between the 'input' and 'output' path of ipfw for routed packets, etc ?). I can look this up in the code, but the average user cannot, I think it will always survive, but not sure, may be it is better for your to review the code and correct description. and the patch does not contain a single line of comment, plus we generally want to have some textual description of the behaviour (so we can RTFM), not just an implementation without comments. OK, Andrey currently comments the code and implements untag action, and here is my patch for manpage describing all this stuff: --- ipfw.8.orig Fri May 12 21:09:14 2006 +++ ipfw.8 Fri May 12 22:08:42 2006 @@ -563,6 +563,30 @@ Note: logging is done after all other packet matching conditions have been successfully verified, and before performing the final action (accept, deny, etc.) on the packet. +.It Cm tag Ar number +When a packet matches a rule with the +.Cm tag +keyword, the numeric tag for the given +.Ar number +in the range 0..65535 will be attached to the packet. +The tag acts as an internal marker (it is not sent out over +the wire) that can be used to identify these packets later on. +This can be used, for example, to provide trust between interfaces +and to start doing policy-based filtering. +A packet can have mutiple tags at the same time. +Tags are "sticky", meaning once a tag is applied to a packet by a +matching rule it exists everywhere while packet is still in kernel +until explicit removal or sending packet out to the network. +To check for previously applied tags, use the +.Cm tagged +rule option. +.It Cm untag Ar number +When a packet matches a rule with the +.Cm untag +keyword, the tag with the number +.Ar number +is searched in the set of tags attached to +this packet and, if found, removed from this set. .It Cm altq Ar queue When a packet matches a rule with the .Cm altq @@ -1257,6 +1281,15 @@ .It Cm src-port Ar ports Matches IP packets whose source port is one of the port(s) specified as argument. +.It Cm tagged Ar number +Match if packet has a tag with number +.Ar number . +Tags can be applied to the packet using +.Cm tag +rule action parameter or set somewhere in another part of the kernel +network subsytem using +.Xr mbuf_tags 9 +facility. .It Cm tcpack Ar ack TCP packets only. Match if the TCP header acknowledgment number field is set to -- WBR, Vadim Goncharov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] ipfw packet tagging
12.05.06 в 20:53 Luigi Rizzo в своём письме писал(а): > I've tried Andrey Elsukov's ipfw "tag/tagged" patches from: > http://butcher.heavennet.ru/patches/kernel/ipfw_tags/ > > Tested on 5.5-PRERELEASE production server with moderate > load - rock stable [I've also looked through the code - patch > is small, so it simply can't be any bugs there ;)]. > > Personally I very like the idea from original Andrey's letter I have tested on 6.1 and works fine too. Hope it gets commited. Very useful for altq/dummynet flexibility too. i would, however, like to have a bit more documentation in the patch, in particular: - a manpage patch describing how to use the thing, and also the behaviour in in odd situations (e.g. what happens when we try to tag a packet multiple times ? does the tag survive between the 'input' and 'output' path of ipfw for routed packets, etc ?). A question about features: is it worth adding functionality of matching range of tags? For example: ipfw add pass ip from any to any tagged 1-5,10,20 -- WBR, Vadim Goncharov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] ipfw packet tagging
On Fri, May 12, 2006 at 10:50:10PM +0700, Vadim Goncharov wrote: > A question about features: is it worth adding functionality of matching > range of tags? For example: > > ipfw add pass ip from any to any tagged 1-5,10,20 i think it is a useful feature, and if you reuse the existing code for matching port ranges etc to implement it, performance should be reasonably good. cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vlan/bridge problems..
I tried to bridge vlan with ethernet but I am having troubles. net.link.ether.bridge_cfg: fxp0:2,fxp3:2,fxp2:3,vlan0:3 net.link.ether.bridge: 1 net.link.ether.bridge_ipfw: 0 net.link.ether.bridge_ipf: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 fxp0 - fxp3 bridge works fine vlan0 is attached to fxp3 (trunk) vlan0 - fxp2 bridge doesnt work! I can ping IP of fxp2 but not to any host connected to fxp2. Can this be because I am using fxp3 as a normal interface + a vlan trunk at the same time? Thanks, Evren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RFC: Updated window update algorithm
It's been nearly four years, I was wondering if anyone has had a thought
on this change yet. :)
Mike "Silby" Silbersack
-- Forwarded message --
Date: Tue, 30 Jul 2002 15:15:55 -0500 (CDT)
From: Mike Silbersack <[EMAIL PROTECTED]>
To: freebsd-net@freebsd.org
Subject: RFC: Updated window update algorithm
I'd appreciate if the tcp inclined could take a quick look over the
attached patch. What it does is implement a simpler algorithm used to
determine whether or not to accept window updates. Our existing algorithm
(the one in RFC793/1122) had a weakness in that it will ignore window
updates piggybacked on retransmitted packets. In a unidirectional
transfer situation, this is not a problem. However, in the case of a
bidirectional transfer, this could cause retransmission in one direction
to stall transmission in the other direction.
For more info on this case, see the thread at:
http://tcp-impl.grc.nasa.gov/tcp-impl/list/archive/2184.html
The algorithm I used in the attached patch is the one created by Alexey
Kuznetsov, currently used in Linux 2.4.
Any comments (on the algorithm or implementation) would be appreciated.
Thanks,
Mike "Silby" Silbersack--- /usr/src/sys.old/netinet/tcp_input.cTue Jul 30 00:41:38 2002
+++ tcp_input.c Tue Jul 30 14:15:40 2002
@@ -1939,11 +1939,15 @@
/*
* Update window information.
* Don't look at window if no ACK: TAC's send garbage on first SYN.
+* Update window if:
+* - New data acked
+* - New data sent to us
+* - Data has not advanced, but larger window is reported
*/
if ((thflags & TH_ACK) &&
(SEQ_LT(tp->snd_wl1, th->th_seq) ||
- (tp->snd_wl1 == th->th_seq && (SEQ_LT(tp->snd_wl2, th->th_ack) ||
-(tp->snd_wl2 == th->th_ack && tiwin > tp->snd_wnd) {
+SEQ_LT(tp->snd_una, th->th_ack) ||
+((th->th_seq == tp->snd_wl1) && (tiwin > tp->snd_wnd {
/* keep track of pure window updates */
if (tlen == 0 &&
tp->snd_wl2 == th->th_ack && tiwin > tp->snd_wnd)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vlan/bridge problems..
Evren Yurtesen writes: | I tried to bridge vlan with ethernet but I am having troubles. | | net.link.ether.bridge_cfg: fxp0:2,fxp3:2,fxp2:3,vlan0:3 | net.link.ether.bridge: 1 | net.link.ether.bridge_ipfw: 0 | net.link.ether.bridge_ipf: 0 | net.link.ether.bridge_ipfw_drop: 0 | net.link.ether.bridge_ipfw_collisions: 0 | | fxp0 - fxp3 bridge works fine | vlan0 is attached to fxp3 (trunk) | | vlan0 - fxp2 bridge doesnt work! I can ping IP of fxp2 but not to any | host connected to fxp2. | | Can this be because I am using fxp3 as a normal interface + a vlan trunk | at the same time? It wouldn't work for me since the if_vlan device call the device driver's output mechanism direct and the SW input path would ignore handling of VLAN packets ... or atleast this used to be issues. My machine's that I needed this for are patched locally to make it work. I don't know the current state of this. It gets to be a bit of a mess re-injection the packet into the stack on output with loops etc. The ordering of post netgraph/bridge has some issues. It probably should be tagged and use that to prevent loops. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vlan/bridge problems..
Doug Ambrisko wrote: Evren Yurtesen writes: | I tried to bridge vlan with ethernet but I am having troubles. | | net.link.ether.bridge_cfg: fxp0:2,fxp3:2,fxp2:3,vlan0:3 | net.link.ether.bridge: 1 | net.link.ether.bridge_ipfw: 0 | net.link.ether.bridge_ipf: 0 | net.link.ether.bridge_ipfw_drop: 0 | net.link.ether.bridge_ipfw_collisions: 0 | | fxp0 - fxp3 bridge works fine | vlan0 is attached to fxp3 (trunk) | | vlan0 - fxp2 bridge doesnt work! I can ping IP of fxp2 but not to any | host connected to fxp2. | | Can this be because I am using fxp3 as a normal interface + a vlan trunk | at the same time? It wouldn't work for me since the if_vlan device call the device driver's output mechanism direct and the SW input path would ignore handling of VLAN packets ... or atleast this used to be issues. My machine's that I needed this for are patched locally to make it work. I don't know the current state of this. It gets to be a bit of a mess re-injection the packet into the stack on output with loops etc. The ordering of post netgraph/bridge has some issues. It probably should be tagged and use that to prevent loops. Doug A. Well, I think vlans do not bridge on 4.x Bridging works in 5.x/6.x but not the way that I explained here I cant bridge 1 interface and its vlan interface at the same time. Thanks, Evren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vlan/bridge problems..
Evren Yurtesen wrote: Doug Ambrisko wrote: Evren Yurtesen writes: | I tried to bridge vlan with ethernet but I am having troubles. | | net.link.ether.bridge_cfg: fxp0:2,fxp3:2,fxp2:3,vlan0:3 | net.link.ether.bridge: 1 | net.link.ether.bridge_ipfw: 0 | net.link.ether.bridge_ipf: 0 | net.link.ether.bridge_ipfw_drop: 0 | net.link.ether.bridge_ipfw_collisions: 0 | | fxp0 - fxp3 bridge works fine | vlan0 is attached to fxp3 (trunk) | | vlan0 - fxp2 bridge doesnt work! I can ping IP of fxp2 but not to any | host connected to fxp2. | | Can this be because I am using fxp3 as a normal interface + a vlan trunk | at the same time? It wouldn't work for me since the if_vlan device call the device driver's output mechanism direct and the SW input path would ignore handling of VLAN packets ... or atleast this used to be issues. My machine's that I needed this for are patched locally to make it work. I don't know the current state of this. It gets to be a bit of a mess re-injection the packet into the stack on output with loops etc. The ordering of post netgraph/bridge has some issues. It probably should be tagged and use that to prevent loops. Doug A. Well, I think vlans do not bridge on 4.x that may or may not be true.. I think I have seen it working.. I think netgraph bridging should work. it may depend of whether you are doing hardware vlan tagging. Bridging works in 5.x/6.x but not the way that I explained here I cant bridge 1 interface and its vlan interface at the same time. Thanks, Evren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[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: vlan/bridge problems..
Julian Elischer writes: | Evren Yurtesen wrote: | > Doug Ambrisko wrote: | > | >> Evren Yurtesen writes: | >> | I tried to bridge vlan with ethernet but I am having troubles. | >> | | net.link.ether.bridge_cfg: fxp0:2,fxp3:2,fxp2:3,vlan0:3 | >> | net.link.ether.bridge: 1 | >> | net.link.ether.bridge_ipfw: 0 | >> | net.link.ether.bridge_ipf: 0 | >> | net.link.ether.bridge_ipfw_drop: 0 | >> | net.link.ether.bridge_ipfw_collisions: 0 | >> | | fxp0 - fxp3 bridge works fine | >> | vlan0 is attached to fxp3 (trunk) | >> | | vlan0 - fxp2 bridge doesnt work! I can ping IP of fxp2 but not to | >> any | host connected to fxp2. | >> | | Can this be because I am using fxp3 as a normal interface + a | >> vlan trunk | at the same time? | >> | >> It wouldn't work for me since the if_vlan device call the device | >> driver's output mechanism direct and the SW input path would ignore | >> handling of VLAN | >> packets ... or atleast this used to be issues. My machine's that I | >> needed | >> this for are patched locally to make it work. | >> | >> I don't know the current state of this. It gets to be a bit of | >> a mess re-injection the packet into the stack on output with loops etc. | >> The ordering of post netgraph/bridge has some issues. It probably | >> should be tagged and use that to prevent loops. | > | > Well, I think vlans do not bridge on 4.x | | that may or may not be true.. I think I have seen it working.. | I think netgraph bridging should work. Only if doing netgraph vlan. Not if_vlan. | it may depend of whether you are doing hardware vlan tagging. I disable HW vlan support. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
