Viewing multicast group membership?
Hi, Pardon me if this is an FAQ or answered somewhere else. I've had a quick skim through the man pages and the source, and can't seem to find a means of listing which IPv4 multicast groups a host is currently a member of. The net.igmp.stats sysctl only seems to maintain general protocol level statistics; it doesn't contain group information. This is the sysctl reported by 'netstat -g'. I guess I need to write some code to open /dev/kmem and walk ifmultihead. Or does someone have a hack lying around for this I can clean up and commit? BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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.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 problems (smbclient). >> > Additionally the sysctl setting has veird impact on mozilla: trying to >> > write to web forms causes freezing of mozilla. Now setting >> > net.inet.tcp.blackhole=0 reverts all the problemsr: samba starts fast >> > and no problems with writing to the web forms. >> > my system: >> > FreeBSD 5.1-CURRENT #0: Thu Oct 30 17:49:13 EST 2003 >> > ports updated 11-08-03 >> > >> > I appreciate any suggestions >> >> I looked at a similar problem that someone was having a while back. It >> appears that the problem is that this sysctl setting is suppressing the >> sending of TCP RST packets which are needed to tear down dead >> connections, and if one end of the connection thinks the connection is >> still established, it is not possible to create a new connection between >> the hosts that reuses the same addresses and ports as the old >> connection. >> >> Since the whole point of net.inet.tcp.blackhole=2 is to block the RST >> packets that could allow the host to be scanned, I suspect you are >> stuck. > > That's not a bug, that is the only feature :) > > First of all, check on which ports the connections that time out occur. > One possibility would be `tcpdump', the other is to set the sysctl > net.inet.tcp.log_in_vain to 1. Then start samba and look in the logs to > which closed ports connection attempts were made. > Maybe there is a decent solution to provide these packets the answer they > desire so hard. You'll probably need to crank net.inet.tcp.log_in_vain all the way up to 2. If you just set it to 1, it won't tell you about packets that don't have the SYN flag set. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
On Sun, 9 Nov 2003, Andre Oppermann wrote: > Hello all, > > this patch contains three things (to be separated for committing): I don't have much time free in the next week, so I cannot do a complete review. However, I just did a quick readthrough. > tcp_hostcache This looks good to me, I've been waiting for you to finish it for a long time. You actually missed a point: - Ensures that a cached entry isn't added until the 3WHS is completed. This should help make synfloods with random source addresses less damaging. Would it be possible to provide a way for netstat to view the host cache table? I think that it would be useful. > ip_fastforward No comment, I didn't read through this part, and I'm not familiar with the forwarding code. > tcp bug fixes and MSS DoS attack prevention Generally good, but: > - adds tcp_minmssoverload which disconnects a TCP session if > it receives too many (1000) packets per second whose average > segement size is lower than tcp_minmss > - DoS attack 2: make MSS very low on local side of connection > and send mny small packet to remote host. For every packet > (eg. 2 bytes payload) a sowakeup is done to the listening > process. Consumes a lot of CPU there. I don't think that your patch for this really solves anything. Anyone who would write such a program could just as easily make it use concurrent connections, have it auto-reconnect, and/or have it only send 900 packets per second. I think that you should remove this section of the patch, but leave a comment about this problem existing so that it will be thought more about in the future. After the rest of the code is in, we can brainstorm on other possible solutions... I think that Mini's idea of approaching it as an optimization is the correct one. Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Jonathan Mini wrote: > > On Nov 9, 2003, at 2:47 PM, Andre Oppermann wrote: > > > Jonathan Mini wrote: > >> > >> On Nov 9, 2003, at 8:19 AM, Andre Oppermann wrote: > >> > >>> - DoS attack 2: make MSS very low on local side of connection > >>> and send mny small packet to remote host. For every packet > >>> (eg. 2 bytes payload) a sowakeup is done to the listening > >>> process. Consumes a lot of CPU there. > >>> > >> > >> This sounds as if it might be worthwhile to add a delay to > >> the TF_NODELAY case for receive processing as well. > > > > Unfortunatly it is not that easy. We can't just do that unconditionally > > to all connections. It would probably break or delay many things. You > > never know how much data is outstanding and whether it's just this > > packet with 2 bytes outstanding... > > This would be disastrous to the performance of interactive > sockets, however theoretically those connections have > NODELAY set. My above comment is a bit confusing: I meant the > "non TF_NODELAY" case, that is when Nagling is enabled. > > In this situation, you would be delay an sowakeup until > either a timeout or SO_RCVLOWAT-set value was reached. The normal > SO_RCVLOWAT case delays until SO_RCVTIMEO is reached. I suppose > the application could simulate this with a large SO_RCVLOWAT and a > small SO_RCVTIMEO, but I was wondering about the effects of such a > change as part of !TF_NODELAY. To do this we need another callout to do the eventual wakeup if no further packet arrive within whatever/HZ. In addition it probably would make FreeBSD look bad in network benchmarks since this causes the connection RTT to go up. All in all I don't think it is worth adding this complexity. > Sadly, there's this PSH bit in the TCP header that's completely > unreliable and could be used for scenarios like this. > > > As an application aware of this problematic you have currently two > > options: use accept filters (FreeBSD only) or set SO_RCVLOWAT to some > > higher value than the default 1 byte. Only the first one is workable > > if you don't know what and how much the clients send to you. Relying > > on the application to activate any such option to prevent this kind > > of DoS is unfortunatly whishful thinking. > > I was not suggesting that we use this to counter an attack, only asking > if it might be a worthwhile performance optimization to consider. > This is an unlikely case (many small packets sent to a non-interactive > application), so I can't see the improvement as being globally useful. No, I don't think it is a worthwhile opimization. If the application wants to do it, it can do so already via socket options. Normally an application needs such a delay feature to be specific to it's message types. Like with http accept filter. > > The code I've put in here simply caps off the extreme cases. It > > counts all packets and bytes in any given second and computes the > > average payload size per packet. If that is less than we have defined > > for minmss it will reset and drop the connection. However it will only > > start to compute the average if there are more than 1'000 packets per > > second on the same tcp connection. I've chosen this quite high value > > to never disconnect any ligitimate connection which just happens to > > send many small packets. In my tests I've seen telnet/ssh sending > > close to 100 small packets per second (some large copy-pasting and > > cat'ing of many small files). Probably 500 packets per second is a > > better cut-off value but I just want to be sure to never hit a false > > positive. > > This is actually a small value for TCP connections which are being > used to forward messages, especially on gigabit links. > Heavily-intensive > web applications that are using small HTTP requests (pipelined inside a > persistent connection) to update small manipulations of state are > a good example of this. I wouldn't be surprised to see chatter > between SQL servers follow similar patterns. Applications which > use XML-based messaging often send several small packets per message, > which is unfortunate. Do you think such applications manage to send 1000 packets per second with less than 256 bytes payload per packet? I think the network code would collect some data to form a larger packet (unless TCP_NODELAY set)? > On the other hand, I'm used to looking at proxies, which are not > the general case. This is why the limits are tunable, after all. =) Is there way you could monitor such connections and compile some statistics how many small packets per second are sent? I could adjust the patch to just report the fact instead of dropping the connection. Could do it for 4.9-R too, it's fairly easy. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Mike Silbersack wrote: > > On Sun, 9 Nov 2003, Andre Oppermann wrote: > > > Hello all, > > > > this patch contains three things (to be separated for committing): > > I don't have much time free in the next week, so I cannot do a complete > review. However, I just did a quick readthrough. > > > tcp_hostcache > > This looks good to me, I've been waiting for you to finish it for a long > time. You actually missed a point: > > - Ensures that a cached entry isn't added until the 3WHS is completed. > > This should help make synfloods with random source addresses less > damaging. The cache will only be updated if the tcp connection is being closed. All updates are done in tcp_drop. The T/TCP updates have to be done inline during connection setup. I've converted all places which updated the T/TCP rtmetrics in routing table with updates to the hostcache. > Would it be possible to provide a way for netstat to view the host cache > table? I think that it would be useful. At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". Syncache ain't visible via netstat either. So far you had to use route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm sure whether netstat is the right place for it. But I can do that in a second step. > > ip_fastforward > > No comment, I didn't read through this part, and I'm not familiar with > the forwarding code. > > > tcp bug fixes and MSS DoS attack prevention > > Generally good, but: > > > - adds tcp_minmssoverload which disconnects a TCP session if > > it receives too many (1000) packets per second whose average > > segement size is lower than tcp_minmss > > - DoS attack 2: make MSS very low on local side of connection > > and send mny small packet to remote host. For every packet > > (eg. 2 bytes payload) a sowakeup is done to the listening > > process. Consumes a lot of CPU there. > > I don't think that your patch for this really solves anything. Anyone who > would write such a program could just as easily make it use concurrent > connections, have it auto-reconnect, and/or have it only send 900 packets > per second. I think that you should remove this section of the patch, but > leave a comment about this problem existing so that it will be thought > more about in the future. The actually solves the problem. Let me explain in more detail. When we get so many small packets per second the CPU will become pretty saturated. Depending on how much data is sent it can go on for minutes or hours. This code jumps in there and disconnects the within a second. Of course someone can immediatly reconnect and do it again. But that needs the 3WHS again and gives some delay. In the end this code is like the ICMP rate limiter code. It there to migitate a problem to manageable level, not to make it go away. > After the rest of the code is in, we can brainstorm on other possible > solutions... I think that Mini's idea of approaching it as an optimization > is the correct one. Ok, for brainstorming. For Mini's idea see my answer to him. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
On Nov 10, 2003, at 1:39 AM, Andre Oppermann wrote: Jonathan Mini wrote: All in all I don't think it is worth adding this complexity. I agree. This is actually a small value for TCP connections which are being used to forward messages, especially on gigabit links. Heavily-intensive web applications that are using small HTTP requests (pipelined inside a persistent connection) to update small manipulations of state are a good example of this. I wouldn't be surprised to see chatter between SQL servers follow similar patterns. Applications which use XML-based messaging often send several small packets per message, which is unfortunate. Do you think such applications manage to send 1000 packets per second with less than 256 bytes payload per packet? I think the network code would collect some data to form a larger packet (unless TCP_NODELAY set)? Traffic like that only happens when TCP_NODELAY is set. Otherwise, you get what you would expect. On the other hand, I'm used to looking at proxies, which are not the general case. This is why the limits are tunable, after all. =) Is there way you could monitor such connections and compile some statistics how many small packets per second are sent? I could adjust the patch to just report the fact instead of dropping the connection. Could do it for 4.9-R too, it's fairly easy. Alas, no. This is from anecdotal experience from our support staff at work. -- Jonathan Mini [EMAIL PROTECTED] http://www.freebsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Routing With Two ISPs?
> Subject: Re: Routing With Two ISPs? > > > [ Charset windows-1252 unsupported, converting... ] > > I have a 4.8 box serving as a gateway with two connections to the > > Internet. Is there some way to set the box up so that packets are > > routed out through the same interface from which they arrived? For > > example, if a connection is initiated on port 80 from a packet arriving > > on one interface, is there a way to make the outgoing packets from my > > web server use that same interface as a gateway instead of the default > > interface? > > > > Any suggestions appreciated. > It's easy IMHO Its not too difficult to set up and get running. I also have two ISP's (Cable Modem and DSL). If I understand what your asking, its similar to my situation. Because I run natd on both interfaces, I had to do a little poking around until I finally got everything working correctly. One of my ip addresses is provided via DHCP, the other is static. First off, in /etc/services copy the natd line and rename it natd2, change the port number to 8669 as well. (eg ..) natd8668/divert # Network Address Translation natd2 8669/divert # Network Address Translation Second, I created a scripts that run natd on both ethernet cards and set them as executable. europa# more /usr/local/etc/rc.d/dc0-natd.sh #!/bin/sh if [ $# -eq 0 -o x$1 = xstart ]; then /sbin/natd -p natd -s -u -f /etc/natd.conf -n dc0 && echo -n ' natd started on dc0' cp /var/run/natd.pid /var/run/natd.dc0.pid fi if [ x$1 = xstop ]; then if [ -f /var/run/natd.dc0.pid ]; then kill `cat /var/run/natd.dc0.pid` fi fi europa# more /usr/local/etc/rc.d/ed0-natd.sh #!/bin/sh if [ $# -eq 0 -o x$1 = xstart ]; then /sbin/natd -p natd2 -s -u -f /etc/natd.conf -n ed0 && echo -n ' natd started on ed0' cp /var/run/natd.pid /var/run/natd.ed0.pid fi if [ x$1 = xstop ]; then if [ -f /var/run/natd.ed0.pid ]; then kill `cat /var/run/natd.ed0.pid` fi fi Then I commented out the natd lines in /etc/rc.conf for natd, because I am running it from these other scripts instead. I would run it from rc.conf, but I would have needed to hack up some other rc.files to get that working. A seperate script requred less code. At this point both networks work, and they can both be used as the default gateway. I also suggest adding mappings to the default gateway on both ISP's to /etc/hosts . This will save most people a small head ache. Next up, my DSL provider has given me a subnet mask of 255.255.255.224. However, he owns the entire class C address space. So to save myself a bit of time, I added a static route to his Class C in /etc/rc.conf . (in /etc/rc.conf) static_routes="dsl" route_dsl=" -net x.y.172 x.y.172.104 255.255.255.0" And finally, if you are running a firewall, you need to make sure that you have divert rules in place for both natd interfaces. In my case I use (dc0 = Cable, ed0 = DSL): ipfw add 00100 divert 8668 ip from any to any via dc0 ipfw add 00101 divert 8669 ip from any to any via ed0 > Each external iface with it's own natd, > each forwards 80 port incoming to two > http servers with different IP or port. Just remember, natd needs to run on seperate ports. And you can tell natd which port to use with the -p arguement. > > outgoing traffic can be forwarded to appropriate > natd via ipfw rules depending on src IP or port Yes, several people also divert certain types of traffic out specific interfaces using Firewall rules. My situation doesnt really require this, but several people can share there examples. Hope this is what you were asking for. And with any luck, I have not forgotten to mention anything. If it isnt working for you, feel free to get in touch with me via [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Viewing multicast group membership?
On Mon, 10 Nov 2003, Bruce M Simpson wrote: > Pardon me if this is an FAQ or answered somewhere else. > > I've had a quick skim through the man pages and the source, and can't > seem to find a means of listing which IPv4 multicast groups a host is > currently a member of. > > The net.igmp.stats sysctl only seems to maintain general protocol level > statistics; it doesn't contain group information. This is the sysctl > reported by 'netstat -g'. > > I guess I need to write some code to open /dev/kmem and walk > ifmultihead. Or does someone have a hack lying around for this I can > clean up and commit? I can't speak to existing code for this, but I can say I have a preference for having a sysctl version of the code available in the vague hopes that someday we can drop the setgid kmem bit from netstat... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Current problem reports assigned to you
Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description --- o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI 1 problem total. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Current problem reports assigned to you
FreeBSD bugmaster wrote: > > Current FreeBSD problem reports > Critical problems > Serious problems > Non-critical problems > > S Submitted Tracker Resp. Description > --- > o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI > > 1 problem total. What is going on with this? It comes up every other week. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Viewing multicast group membership?
On Mon, Nov 10, 2003 at 01:14:59PM -0500, Robert Watson wrote: > I can't speak to existing code for this, but I can say I have a preference > for having a sysctl version of the code available in the vague hopes that > someday we can drop the setgid kmem bit from netstat... During operation, the kernel routing socket will report multicast group joins/leaves using RTM_NEWMADDR/RTM_DELADDR messages. These contain an ifma_msghdr structure, which encapsulates multicast addresses in an address family independent manner. However, there is no mechanism to report currently existing associations. Maybe the way to go is to extend getifaddrs(), or create a new API a lot like it. Right now, it uses the NET_RT_IFLIST sysctl to retrieve the interface list; the kernel appends RTM_NEWADDR messages to the buffer contents returned by the sysctl to report each address family. The function sysctl_iflist() in net/rtsock.c is responsible for this. However, not all getifaddrs() consumers are likely to be interested in multicast associations, so this could end up adding bloat. The getifaddrs() libc function and sysctl_iflist() kernel code do not touch ifnet->if_multiaddrs at all. So my next question is: Do I create a new API function and sysctl, or integrate into the existing code path? BMS pgp0.pgp Description: PGP signature
libpcap again
(I might sound like a broken record, but...) Any chance of libpcap vendor import before 5.2 release? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: Current problem reports assigned to you
Monday, November 10, 2003, 8:11:12 PM, you wrote: AO> FreeBSD bugmaster wrote: >> >> Current FreeBSD problem reports >> Critical problems >> Serious problems >> Non-critical problems >> >> S Submitted Tracker Resp. Description >> --- >> o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI >> >> 1 problem total. AO> What is going on with this? It comes up every other week. Kris wrote: "Assign to net mailing list for evaluation" when he changed resp. Seems no-one ever reads it (or uses this emacs thingy). Take a look: http://www.freebsd.org/cgi/query-pr.cgi?pr=37761 and "evaluate" -- Best regards, Maxmailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Current problem reports assigned to you
Max Laier wrote: > > Monday, November 10, 2003, 8:11:12 PM, you wrote: > AO> FreeBSD bugmaster wrote: > >> > >> Current FreeBSD problem reports > >> Critical problems > >> Serious problems > >> Non-critical problems > >> > >> S Submitted Tracker Resp. Description > >> --- > >> o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI > >> > >> 1 problem total. > > AO> What is going on with this? It comes up every other week. > > Kris wrote: > "Assign to net mailing list for evaluation" when he changed resp. > > Seems no-one ever reads it (or uses this emacs thingy). Take a look: > http://www.freebsd.org/cgi/query-pr.cgi?pr=37761 and "evaluate" Neither do I have this emacs thing (and I don't want to install it). Anyway, this bug sounds like a fork cleanup problem. Process forks child. child opens socket. childs goes away without closing socket. Partent goes away too, and socket stays around as zombie. But how to reproduce... Maybe I will look into it a bit more but no promises. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Viewing multicast group membership?
On Mon, 10 Nov 2003, Bruce M Simpson wrote: BMS>On Mon, Nov 10, 2003 at 01:14:59PM -0500, Robert Watson wrote: BMS>> I can't speak to existing code for this, but I can say I have a preference BMS>> for having a sysctl version of the code available in the vague hopes that BMS>> someday we can drop the setgid kmem bit from netstat... BMS> BMS>During operation, the kernel routing socket will report multicast group BMS>joins/leaves using RTM_NEWMADDR/RTM_DELADDR messages. These contain an BMS>ifma_msghdr structure, which encapsulates multicast addresses in an address BMS>family independent manner. However, there is no mechanism to report currently BMS>existing associations. BMS> BMS>Maybe the way to go is to extend getifaddrs(), or create a new API BMS>a lot like it. Right now, it uses the NET_RT_IFLIST sysctl to retrieve BMS>the interface list; the kernel appends RTM_NEWADDR messages to the BMS>buffer contents returned by the sysctl to report each address family. BMS>The function sysctl_iflist() in net/rtsock.c is responsible for this. BMS> BMS>However, not all getifaddrs() consumers are likely to be interested in BMS>multicast associations, so this could end up adding bloat. The getifaddrs() BMS>libc function and sysctl_iflist() kernel code do not touch BMS>ifnet->if_multiaddrs at all. BMS> BMS>So my next question is: Do I create a new API function and sysctl, or BMS>integrate into the existing code path? I have a patch that creates a sysctl that returns the per-interface multicast address lists that mimics the sysctl that returns the interface address lists. If you can wait until tomorrow I'll send you the patch. This is running for more than two years on all my machines. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Current problem reports assigned to you
On Mon, 10 Nov 2003, Andre Oppermann wrote: > FreeBSD bugmaster wrote: > > > > Current FreeBSD problem reports > > Critical problems > > Serious problems > > Non-critical problems > > > > S Submitted Tracker Resp. Description > > --- > > o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI > > > > 1 problem total. > > What is going on with this? It comes up every other week. freebsd-net has been set as the owner for the PR, and gnats will send a weekly reminder e-mail that the problem report is still open until such time as it gets closed (or suspended, I suspect). Sometimes when a specific owner for a problem hasn't been found, or is considered undesured, mailing lists are assigned ownership of PRs (i.e., threads@, et al). Speaking of dangling PRs, and since we're talking generally about multicast, does anyone know if we're going to make progress on kern/58359? It sounded like this change did get picked up by Apple, but I haven't checked to see if it was picked up by other *BSD as well. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Current problem reports assigned to you
I have been too busy over the last couple of weeks. I have no problem with the multicast filtering API change actually happening, and if someone who actually has time wants to commit it that'd be fine with me. Bill ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Viewing multicast group membership?
< said: > a lot like it. Right now, it uses the NET_RT_IFLIST sysctl to retrieve > the interface list; the kernel appends RTM_NEWADDR messages to the > buffer contents returned by the sysctl to report each address family. > The function sysctl_iflist() in net/rtsock.c is responsible for this. The plan was to create a parallel NET_RT_IFMLIST which returns this information. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ip6fw problem, ignores "icmptypes 8" (icmp-request)
Hello: I'm trying to block IPv6 icmp-request packets which might be sent to my host. I'm using ip6fw on a FreeBSD-4.9.0-RELEASE. When I do this: add 100 deny ipv6-icmp from any to 2001:720:410:100f:20d:9dff:fe46:f2c9 icmptypes 8 Nothing seems to happen. I still can ping6 my host from a remote machine. Could someone else try this ? I think that "icmptypes" isn't working although it's on the man page of ip6fw. Any suggestion will be appreciated. Bye! -- ** JFRH ** For a good time, call (510) 642-9483 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Viewing multicast group membership?
On Mon, Nov 10, 2003 at 08:49:40PM +0100, Harti Brandt wrote: > I have a patch that creates a sysctl that returns the per-interface > multicast address lists that mimics the sysctl that returns the interface > address lists. If you can wait until tomorrow I'll send you the patch. > This is running for more than two years on all my machines. Sounds like what I was planning to do anyway. Ok, look forward to it. :^) BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Viewing multicast group membership?
ifmcstat delievered by KAME is not sufficient? http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/ifmcstat/ -- Hitoshi Asaeda p.s. it can also show (S,G) info if your kernel supports IGMPv3/MLDv2. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Viewing multicast group membership?
On Tue, Nov 11, 2003 at 12:36:44AM +0100, Hitoshi Asaeda wrote: > ifmcstat delievered by KAME is not sufficient? > http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/ifmcstat/ ifmcstat only appears to report IPv6 group memberships. However, reading its manpage prompted me to try netstat -ina -- this does what I originally wanted. Thank you. However, I still think that Harti's patch is worth looking at, as expecting client programs other than netstat(1) to cough up the incantations found in intpr() on demand is too much -- there is also the fact that it relies upon being setgid kmem to discover these properties, and less of that is definitely a good thing. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hi, > On Sun, 09 Nov 2003 17:19:07 +0100 > Andre Oppermann <[EMAIL PROTECTED]> said: oppermann> Hajimu-san, I'm looking especially for comments on whether my changes oppermann> to IPv6 are correct wrt IPv6 concepts. (I hope they are). I don't see the patch in detail, yet, it seems your change will affect KAME's development. You should ask [EMAIL PROTECTED] for review your patch in detail before committing into FreeBSD. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
Hajimu UMEMOTO wrote: > > Hi, > > > On Sun, 09 Nov 2003 17:19:07 +0100 > > Andre Oppermann <[EMAIL PROTECTED]> said: > > oppermann> Hajimu-san, I'm looking especially for comments on whether my changes > oppermann> to IPv6 are correct wrt IPv6 concepts. (I hope they are). > > I don't see the patch in detail, yet, it seems your change will affect > KAME's development. You should ask [EMAIL PROTECTED] for review your > patch in detail before committing into FreeBSD. Ok, I've written an email [EMAIL PROTECTED] However there is not very much time for them to respond before 5.2 code freeze. I've taken care in my changes not to break IPv6 and to be only minimal intrusive. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
On Mon, 10 Nov 2003, Andre Oppermann wrote: > > - Ensures that a cached entry isn't added until the 3WHS is completed. > > > > This should help make synfloods with random source addresses less > > damaging. > > The cache will only be updated if the tcp connection is being closed. > All updates are done in tcp_drop. The T/TCP updates have to be done > inline during connection setup. I've converted all places which > updated the T/TCP rtmetrics in routing table with updates to the > hostcache. Good, that's exactly how it should work. > > Would it be possible to provide a way for netstat to view the host cache > > table? I think that it would be useful. > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > Syncache ain't visible via netstat either. So far you had to use > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > sure whether netstat is the right place for it. But I can do that > in a second step. Ok, that should be good enough for now. > The actually solves the problem. Let me explain in more detail. When > we get so many small packets per second the CPU will become pretty > saturated. Depending on how much data is sent it can go on for minutes > or hours. This code jumps in there and disconnects the within a second. > Of course someone can immediatly reconnect and do it again. But that > needs the 3WHS again and gives some delay. In the end this code is > like the ICMP rate limiter code. It there to migitate a problem to > manageable level, not to make it go away. Ok, so the problem is that the sockbuf chain keeps getting longer, causing the delay to grow as more fragments pile in... I see now. I drop my objection to it. Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
In a message written on Mon, Nov 10, 2003 at 01:45:48PM -0600, Mike Silbersack wrote: > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > > Syncache ain't visible via netstat either. So far you had to use > > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > > sure whether netstat is the right place for it. But I can do that > > in a second step. > > Ok, that should be good enough for now. I'm not going to say it's not good enough, but more than once the whole "route get" thing has been quite inconveniant, so I'll put in a big vote that both be available in easy to get table form from some command line utility (netstat seems like a good place). -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: tcp hostcache and ip fastforward for review
Leo Bicknell wrote: > > In a message written on Mon, Nov 10, 2003 at 01:45:48PM -0600, Mike Silbersack wrote: > > > At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". > > > Syncache ain't visible via netstat either. So far you had to use > > > route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm > > > sure whether netstat is the right place for it. But I can do that > > > in a second step. > > > > Ok, that should be good enough for now. > > I'm not going to say it's not good enough, but more than once the whole > "route get" thing has been quite inconveniant, so I'll put in a big vote > that both be available in easy to get table form from some command line > utility (netstat seems like a good place). I'll look into that when 5.2 is in code freeze. Can then put it in afterwards. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ip6fw problem, ignores "icmptypes 8" (icmp-request)
Hi, > On Mon, 10 Nov 2003 22:41:02 +0100 > Juan Rodriguez Hervella <[EMAIL PROTECTED]> said: jrh> I'm trying to block IPv6 icmp-request packets which might be sent jrh> to my host. I'm using ip6fw on a FreeBSD-4.9.0-RELEASE. jrh> When I do this: jrh> add 100 deny ipv6-icmp from any to 2001:720:410:100f:20d:9dff:fe46:f2c9 jrh> icmptypes 8 ICMPv6 is not same as ICMPv4. ICMP6_ECHO_REQUEST is 128. Please refer /usr/include/netinet/icmp6.h. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
