Re: em driver input errors
Hi, On Sat, Aug 1, 2009 at 3:05 PM, wrote: > Good day > > I'm running a FreeBSD 7.2 router and I am seeing a lot of input errors on one > of the em interfaces (em0), coupled with (at approximately the same times) > much fewer errors on em1 and em2. Monitoring is done with SNMP from another > machine, and the CPU load as reported via SNMP is mostly below 30%, with a > couple of spikes up to 35%. First question that comes to mind is: have you tried device polling ? Looking up the thorough decscription you made it appears not to. Please check the polling(4) manual page and Luigi's page [1] for detailed information. Basically it switches the device driver from interrupt mode to polling mode, allowing to specify the user/system CPU usage fraction. [1] http://info.iet.unipi.it/~luigi/polling/ Regards, Adrian Penisoara EnterpriseBSD ___ 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: permissions on /etc/namedb
Hi,
On Mon, Aug 4, 2008 at 12:57 PM, Ian Smith <[EMAIL PROTECTED]> wrote:
> On Sun, 3 Aug 2008, Doug Barton wrote:
> > Eugene Grosbein wrote:
> > > On Sun, Aug 03, 2008 at 10:54:05PM -0700, Doug Barton wrote:
> [..]
> > >>> Well, I just want bind be allowed to write to is working directory.
> > >> I think that your idea of "BIND's working directory" is probably
> > >> flawed
> > >
> > > That's not my idea. From /var/log/messages:
> > >
> > > Aug 3 15:02:18 host named[657]: the working directory is not writable
> >
> > That is a quaint reminder of a simpler time. It's far better nowadays
> > to separate the idea of configuration directories and directories that
> > named should write to. (One could easily make the argument that this
> > division should have been enforced from the start, and personally I
> > never liked having named dropping stuff all over my config directory,
> > but I digress.)
>
> In the olden days (bind 4) named.run, named.stats and named_dump.db were
> all written to /var/tmp .. perhaps because it had the sticky bit set?
>
> > >> but if what you want is to make /etc/namedb writable by the
> > >> bind user and have it persist from boot to boot someone else already
> > >> told you how to do that, so good luck.
> > >
> > > Sigh... I have to study mtree now.
> >
> > If it takes you more than 5 minutes, give up. :)
> >
> > > And for what reason? Just because the system thinks it knows better
> what user needs.
> >
> > You previously agreed with me that the defaults should be appropriate
> > for non-expert users, and I would still argue that they are.
>
> With the notable exception of making standard functions rndc trace and
> querylog work, writing to the default file named.run, which named wants
> to write in 'the working directory'. You'll have seen my solution to
> that, touching named.run in case it doesn't exist then chown'ing it to
> bind:wheel in /etc/rc.d/named, which I don't think endangers security.
>
> I've not been able to find another solution, and there's no equivalent
> of dump-file and statistics-file for the trace/querylog file (that I
Quoting from a default distributed /etc/namedb/named.conf:
options {
// Relative to the chroot directory, if any
directory "/etc/namedb";
pid-file"/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
You have to take into account that "directory" is used for any non-absolute
pathname specified in named.conf, including the "file" clauses for
master/slave zones. If you were to change it now then you would break a lot
of setups.
I believe that the "working directory" and "root config directory"
concepts should have been dissociated.
>
> can find) but perhaps you know some way the directory to write this
> file can be specified in named.conf? Maybe to /var/named/var/log ?
>
> > Also, I'm not sure whether you've actually looked at the default
> > named.conf or not, but the two most common files that someone would
> > want to write are the dump and statistics files, and there are already
> > suitable paths for those files provided, and the bind user can
> > actually write to them by default. It would be trivial to expand those
> > examples to other things that are of particular interest to you.
>
> That's what I thought, but my extensive reading hasn't shown me how to
> do that for named.run, so I'd appreciate a clue for a better solution.
>
Best is to have a sepatate configuration directive for the "working
directory" versus "root config directory" assumed by the current "directory"
statement.
Another idea would be to add a final "options { directory "/var/run/named";
}; " statement at the end of the file -- from the BIND sources it appears
that there is a callback function which may pickup this final statement in
order to make it the current working directory for the named process.
Oh, and in the idea that we should keep the default configuration as simple
as possible for the average user and for whatever scenario, here is my
proposal:
directory "/etc/namedb";
pid-file"/var/run/named/pid";
dump-file "/var/run/named/named_dump.db";
statistics-file "/var/run/named/named.stats";
Now the reasons:
- the directory statement should remain the same in order not to break
existing "file" functionality for DNS zones;
- we should use /var/run/named since this is the single common path
available for both chrooted and non-chrooted setups;
- rather then dispersing the various output files we should standardize
for a single common output location
I'm not sure what happens when the user toggles tracing / query logging
(with rndc) -- where would these files go by default ?
My 2cents,
Adrian.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
T
Re: permissions on /etc/namedb
Hi,
On Tue, Aug 5, 2008 at 12:59 AM, Doug Barton <[EMAIL PROTECTED]> wrote:
>
> Adrian Penisoara wrote:
>>
>> Quoting from a default distributed /etc/namedb/named.conf:
>>
>> options {
>>// Relative to the chroot directory, if any
>>directory "/etc/namedb";
>>pid-file"/var/run/named/pid";
>>dump-file "/var/dump/named_dump.db";
>>statistics-file "/var/stats/named.stats";
>>
>> You have to take into account that "directory" is used for any non-absolute
>> pathname specified in named.conf, including the "file" clauses for
>> master/slave zones. If you were to change it now then you would break a lot
>> of setups.
>
> Agreed.
>
>> I believe that the "working directory" and "root config directory" concepts
>> should have been dissociated.
>
> Also agreed. :) I plan to send some feature requests to the bind-users list
> based on the discussions in this thread. If you're interested in this topic
> I'd suggest that you follow the discussion on that list.
I will try to :).
>
> I have an (unreviewed) patch to add a debug-only option at
> http://dougbarton.us/bind-debug-only-channel.diff if anyone wants to
> experiment with this. Using that patch I was able to do this:
>
> logging {
>channel our_debug {
>file "/var/log/named.run";
>severity dynamic;
>print-time yes;
>debug-only yes;
>};
>category default { default_syslog; our_debug; };
>category unmatched { null; };
> };
>
> Which duplicates the default logging configuration except that you can now
> specify the location for the named.run file (or give it another file name,
> etc.).
>
>> Another idea would be to add a final "options { directory "/var/run/named";
>> }; " statement at the end of the file -- from the BIND sources it appears
>> that there is a callback function which may pickup this final statement in
>> order to make it the current working directory for the named process.
>
> The problem is that when you do a reconfig or a reload named won't be able to
> see its configuration file.
>
>> Oh, and in the idea that we should keep the default configuration as simple
>> as possible for the average user and for whatever scenario, here is my
>> proposal:
>>
>>dump-file "/var/run/named/named_dump.db";
>>statistics-file "/var/run/named/named.stats";
>
> This idea is not without merit, but I actually have them separated for a
> reason. The reason is sort of an "intermediate" level thing, but if you want
> to dump the db or the stats more than once and keep more than one version
> around it's more convenient to do this in a separate directory. Also the
> assumption is that /var/run is supposed to be cleaned out at each boot, and I
> wouldn't want to lose those files.
Yep, you've got a point here.
>
>> I'm not sure what happens when the user toggles tracing / query logging
>> (with rndc) -- where would these files go by default ?
>
> That depends on how you have syslog configured. If you have no other logging
> configured and you do 'rndc querylog' to toggle it on it will go to syslog
> with daemon.info. Unfortunately, FreeBSD's default configuration doesn't log
> that by default. One could argue that it should, but I really don't want to
> open that can of worms. If you want to give that a try you could change
> *.notice in syslog.conf for the /var/log/messages file to *.info, then
> /etc/rc.d/syslogd restart. (Or uncomment the all.log option, etc.)
Umm, I'd rather add something along the following to /etc/syslog.conf
(I usually do it for my nameservers):
!named
*.* /var/log/named.log
And of course, one would accompany this with the following line in
/etc/newsyslog.conf:
/var/log/named.log 644 7 100 * J
Regards,
Adrian.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for the FreeBSD equivalent of an OpenBSD function
Hi, On Sat, Aug 9, 2008 at 12:09 PM, Ryan French <[EMAIL PROTECTED]> wrote: > Hi all, > > First of all thank you for all the help with my question yesterday, my problem > today is unfortunately not something syntactical like the last one. > > I am working on moving over code from OpenBSDs implementation ofMPLS to > FreeBSD, and I have run up against a function called 'sysctl_ifq' and I was > wondering if anyone knew of an equivalent in FreeBSD. The code that calls the > function is shown below. Thanks for any help. You mean the following one: http://fxr.watson.org/fxr/source/net/if.c?v=OPENBSD#L1944 In FreeBSD I think one can extract the values for queue (maximum) length and drops stats from the ifq structure using the _IF_DROP()/_IF_QLEN() macros here: http://fxr.watson.org/fxr/source/net/if_var.h?im=bigexcerpts#L247 I'm not sure whether you might need to use locking primitives to query these values for MP reasons with IF_LOCK()/IF_UNLOCK(). Regards, Adrian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Override default ICMP (and other protocols) default replies.
Hi, On Wed, 20 Aug 2008, Javier Ubillos wrote: Hi freebsd-net. (Sorry for cross posting. This time I think I found the right forum for my question) I'm implementing a NAT (1 ip - 1 ip) like router. (it's not actually NAT, but it's a good analogy for this case). I have chosen to use pcaplib to pick up the packets. I have an implementation which picks up the packets, inspects them, rewrites the destination/source ip-addresses and sends them out on the repective interface. Umm, this is going parallel to the real network stack. Why not try to "hijack" the packets fro the kernel to the userland process with a feature like divert in ipfw(8) ? The problem I'm facing however is that my interfaces are answering to e.g. icmp-echo (ping) automatically, and I don't know how to turn this behaviour off. This is a normal TCP/IP network stack feature in the kernel. You may also find that connecting to one of the open ports on the machine will trigger a similar effect. You need to cut off that packet before entering the upper network application layer in the kernel -- see suggestion above. Regards, Adrian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to protect FreeBSD from IP spoofing ?
Hi, Check the ipfw(8) manual (includes examples) or rather go for pf (packetfilter) and check the pf.conf(5) manual. For pf you just need to add something like "antispoof for lo0". Regards, Adrian. On Tue, Feb 17, 2009 at 3:24 PM, Blog Tieng Viet wrote: > Dear all. > I am a newbie of FreeBSD, would like to get alot of information about > FreeBSD such as IPFW. > I am annoyed by IP spoofing but dont have any way to prevent it. > Can any one tell me how to do ? > Thanks in advance. > > PS: > I am using 6.4-PRERELEASE FreeBSD 6.4-PRERELEASE. > The FreeBSD box is used for web server, and it is forwarded every parket of > port 80 from LAN router. > > > > > ___ > freebsd-i...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" > ___ 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: FreeBSD Router Problem
Hi, On Fri, Feb 27, 2009 at 1:06 AM, Shawn Everett wrote: > Sorry I meant to say FreeBSD 7.0 :) > > > Hi Guys, > > > > Here's a weird one... I set up FreeBSD 5.2 to act as a router. I used > > the pf.conf script shown at: > > http://www.openbsd.org/faq/pf/pools.html#outgoing > > > > Everything works just fine. Traffic is appropriately load balanced and > > things work as expected. > > > > Strangely after a few hours something just stops routing traffic. I > can't > > ping the remote gateways either. Both external interfaces still show the > > correct IP addresses. Rebooting the BSD box solves the problem. Nothing > > else gets rebooted. Any error messages in dmesg output ? Significant changes in "netstat -m" output before and after ? The same for "pfctl -s all" output... > > > > > Any suggestions would be appreciated. Try tcpdump'ing on the router's interfaces an on the source machine and compare the packet flows -- do the packets reach the router ? Do they attempt to pass to the outside ? Regards, Adrian. ___ 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: FreeBSD Router Problem
Hi,
On Fri, Feb 27, 2009 at 8:41 AM, Shawn Everett wrote:
> > Any error messages in dmesg output ?
> > Significant changes in "netstat -m" output before and after ?
> > The same for "pfctl -s all" output...
>
> The box has been up for about 12 hours now. As a point of discussion here
> is the output from netstat and pfctl in case anything obvious jumps out.
>
> 385/905/1290 mbufs in use (current/cache/total)
> 384/484/868/25600 mbuf clusters in use (current/cache/total/max)
> 256/384 mbuf+clusters out of packet secondary zone in use (current/cache)
> 0/44/44/12800 4k (page size) jumbo clusters in use
> (current/cache/total/max)
> 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
> 864K/1370K/2234K bytes allocated to network (current/cache/total)
> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
> 0/0/0 requests for jumbo clusters denied (4k/9k/16k)
> 0/5/6656 sfbufs in use (current/peak/max)
> 0 requests for sfbufs denied
> 0 requests for sfbufs delayed
> 0 requests for I/O initiated by sendfile
> 0 calls to protocol drain routines
>
This looks OK to me...
>
>
> # pfctl -s all
> No ALTQ support in kernel
> ALTQ related functions disabled
> TRANSLATION RULES:
> nat on ste0 inet from 172.16.3.0/24 to any -> (ste0) round-robin
> nat on ste1 inet from 172.16.3.0/24 to any -> (ste1) round-robin
>
> FILTER RULES:
> pass out on em0 inet from any to 172.16.3.0/24 flags S/SA keep state
> pass in quick on em0 inet from 172.16.3.0/24 to 172.16.3.253 flags S/SA
> keep state
> pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) }
> round-robin inet proto tcp from 172.16.3.0/24 to any flags S/SA modulate
> state
> pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) }
> round-robin inet proto udp from 172.16.3.0/24 to any keep state
> pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) }
> round-robin inet proto icmp from 172.16.3.0/24 to any keep state
> pass out on ste0 proto tcp all flags S/SA modulate state
> pass out on ste0 proto udp all keep state
> pass out on ste0 proto icmp all keep state
> pass out on ste1 proto tcp all flags S/SA modulate state
> pass out on ste1 proto udp all keep state
> pass out on ste1 proto icmp all keep state
> pass out on ste0 route-to (ste1 204.244.159.254) inet from 204.244.159.55
> to any flags S/SA keep state
> pass out on ste1 route-to (ste0 204.244.159.254) inet from 204.244.159.68
> to any flags S/SA keep state
>
Quite an evolved route forwarding setup ;)...
>
> STATES:
> all udp 172.16.3.255:137 <- 172.16.3.17:137 NO_TRAFFIC:SINGLE
> all udp 172.16.3.17:137 -> 204.244.159.68:57827 -> 172.16.3.255:137
> SINGLE:NO_TRAFFIC
> all tcp 10.170.54.1:81 <- 172.16.3.71:3064 CLOSED:SYN_SENT
> all tcp 172.16.3.71:3064 -> 204.244.159.55:56563 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.30:2021 CLOSED:SYN_SENT
> all tcp 172.16.3.30:2021 -> 204.244.159.68:54557 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.72:1414 CLOSED:SYN_SENT
> all tcp 172.16.3.72:1414 -> 204.244.159.55:52567 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.31:2865 CLOSED:SYN_SENT
> all tcp 172.16.3.31:2865 -> 204.244.159.68:59429 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.72:1415 CLOSED:SYN_SENT
> all tcp 172.16.3.72:1415 -> 204.244.159.55:61425 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.49:1914 CLOSED:SYN_SENT
> all tcp 172.16.3.49:1914 -> 204.244.159.68:58532 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all udp 172.16.3.255:138 <- 172.16.3.39:138 NO_TRAFFIC:SINGLE
> all udp 172.16.3.39:138 -> 204.244.159.68:62224 -> 172.16.3.255:138
> SINGLE:NO_TRAFFIC
> all tcp 64.56.145.72:110 <- 172.16.3.48:1494 FIN_WAIT_2:FIN_WAIT_2
> all tcp 172.16.3.48:1494 -> 204.244.159.55:62928 -> 64.56.145.72:110
> FIN_WAIT_2:FIN_WAIT_2
> all udp 172.16.3.255:137 <- 172.16.3.49:137 NO_TRAFFIC:SINGLE
> all udp 172.16.3.49:137 -> 204.244.159.55:61053 -> 172.16.3.255:137
> SINGLE:NO_TRAFFIC
> all tcp 10.170.54.1:81 <- 172.16.3.37:1508 CLOSED:SYN_SENT
> all tcp 172.16.3.37:1508 -> 204.244.159.68:54656 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.74:3126 CLOSED:SYN_SENT
> all tcp 172.16.3.74:3126 -> 204.244.159.55:61282 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.18:2446 CLOSED:SYN_SENT
> all tcp 172.16.3.18:2446 -> 204.244.159.68:58385 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.73:2057 CLOSED:SYN_SENT
> all tcp 172.16.3.73:2057 -> 204.244.159.55:61692 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all udp 198.208.22.27:53 <- 172.16.3.74:58071 SINGLE:MULTIPLE
> all udp 172.16.3.74:58071 -> 204.244.159.68:54669 -> 198.208.22.27:53
> MULTIPLE:SINGLE
> all udp 198.208.22.27:53 <- 172.16.3.7
Re: FreeBSD Router Problem
Hi, On Fri, Feb 27, 2009 at 9:04 AM, Shawn Everett wrote: > On Thursday 26 February 2009, Adrian Penisoara wrote: > > pfctl -v -s state > > It's midnight here. There should be very little active traffic from > workstations at this hour. I was just about to head off to bed. > OK, then check what's the output around the time it reproduces (before and after)... Bonne nuit :-P Adrian. ___ 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: crazy network problem -- sleep?
Hi, 2009/3/1 stutiredboy > hi,all: > >recently , we found a problem that , some server which with FreeBSD > 6.2 may stop networking after > days of services, it is so difficulty express this status, e, such as > sleep? i can not ping this server, tracert is also > failure, and other services ,network/server seems to be down... but > while i insert the keyboard/mouse/crt in , > everything is ok, such as a ring to call the system to wake-up... no > errors found in dmesg or /var/log/messages, > such as nothing happened...orz，our unlimit args as follow: > > cputime unlimited > filesize unlimited > datasize 2088152 kbytes > stacksize65536 kbytes > coredumpsize unlimited > memoryuseunlimited > vmemoryuse unlimited > descriptors 655000 > memorylocked unlimited > maxproc 5547 > sbsize unlimited > > plz give me some suggestion to trace the problem or solve it . thanks a > lot ! > First you need to check whether packets are reaching the system and whether the response packets are leaving it with tcpdump(8) on the appropriate interface. If you see the packets coming but not coming out then you need to check the status of your TCP/IP stack -- e.g. post the output of "netstat -m" and "netstat -s". Also check dmesg output for any errors. If you are using firewall(s) (ipfw/ipfilter/pf) then check the rules and the firewall states status; try temporarily disabling the firewall (ipfw disable firewall / ipf -D / pfctl -d) and check whether your system becomes reachable. Check CPU load, interrupts, packet stats (systat -vmstat / systat -ifstat). Regards, Adrian Penisoara EnterpriseBSD ___ 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: crazy network problem -- sleep?
Hi, 2009/3/1 stutiredboy > Adrian Penisoara 写道: > > Hi, > > > > 2009/3/1 stutiredboy > <mailto:stutired...@gmail.com>> > > > > hi,all: > > > > recently , we found a problem that , some server which with FreeBSD > > 6.2 may stop networking after > > days of services, it is so difficulty express this status, e, such as > > sleep? i can not ping this server, tracert is also > > failure, and other services ,network/server seems to be down... but > > while i insert the keyboard/mouse/crt in , > > everything is ok, such as a ring to call the system to wake-up... no > > errors found in dmesg or /var/log/messages, > > such as nothing happened...orz，our unlimit args as follow: > > > > cputime unlimited > > filesize unlimited > > datasize 2088152 kbytes > > stacksize 65536 kbytes > > coredumpsize unlimited > > memoryuse unlimited > > vmemoryuse unlimited > > descriptors 655000 > > memorylocked unlimited > > maxproc 5547 > > sbsize unlimited > > > > plz give me some suggestion to trace the problem or solve it . > > thanks a > > lot ! > > > > > > First you need to check whether packets are reaching the system and > > whether the response packets are leaving it with tcpdump(8) on the > > appropriate interface. > > > > If you see the packets coming but not coming out then you need to > > check the status of your TCP/IP stack -- e.g. post the output of > > "netstat -m" and "netstat -s". Also check dmesg output for any errors. > > > > If you are using firewall(s) (ipfw/ipfilter/pf) then check the rules > > and the firewall states status; try temporarily disabling the firewall > > (ipfw disable firewall / ipf -D / pfctl -d) and check whether your > > system becomes reachable. > > > > Check CPU load, interrupts, packet stats (systat -vmstat / systat > > -ifstat). > > > > Regards, > > Adrian Penisoara > > EnterpriseBSD > hi, thank you for your help, i can only ssh to the system, so while the > network is down, i can not login in > > yes, we have ipfw on , these rules have used a long time, and many other > severs do not have this problem, > > this sistutation happened scarce, in different machine rooms, different > isps, different servers, such as hp\dell. > > while the network usable, the cpu and system load is normal, i have > checked dmesg and syslog, nothing > > special found , where our colleague in machine room insert the keyboard > or mouse in ,then the network > > recover , it is so difficult to catch the ouput of tcpdump or other > messages form netstat , the moment you > > have the keyboard connected , the network recover... thanks very much ! You mean that once you plugin a keyboard the machine recovers ? That's weird. What if you leave the keyboard connected all the time ? Try to attach one of the machines which reproduces the problem to a KVM switch (Keyboard/Video/Mouse switcher). If you are able to reproduce again the problem then you might have more chances to catch it. Regards, Adrian. ___ 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: crazy network problem -- sleep?
Hi, 2009/3/2 stutiredboy [...] > > > > > > You mean that once you plugin a keyboard the machine recovers ? That's > > weird. What if you leave the keyboard connected all the time ? > > > > Try to attach one of the machines which reproduces the problem to a > > KVM switch (Keyboard/Video/Mouse switcher). If you are able to > > reproduce again the problem then you might have more chances to catch it. > > > > Regards, > > Adrian. > > > hi, thanks Adrian. yes,it is weird and thanks for your opinion, it's a > good a idea , but it is a pity that i do not know which machine will run > into this problem again, we have thousands of machines in different > machine rooms, i will try this , hope i have the chances to catch the > useful info. :-) > Please keep in mind hat having a predictable reproduction method for the issue would greatly help resolving the problem, so try to keep tabs on what triggers producing it. Regards, Adrian. ___ 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: FreeBSD Router Problem
Hi, On Wed, Mar 25, 2009 at 11:21 PM, Shawn Everett wrote: > > tcp.established 86400s > > > > ^^ This should be 3600. > > > > Pierre > > That's an interesting thought. Why would that matter? It's the PF TCP established session timeout, which defaults to 1 day. This is relevant only if you see a lot of ESTABLISHED sessions in the 'pfctl -s state' output, which appears not to be the case... Regards, Adrian. ___ 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: FreeBSD Router Problem
Hi, On Thu, Mar 26, 2009 at 5:02 PM, Pierre Lamy wrote: > stateshard limit1 > > If I want to dos this box all I need to do is hold 10k tcp connections open > in established. > > A 1 day default timeout for established connections is retarded, since > virtually all client apps and OSs as well as intervening stateful firewalls > will lose state after 1 hour. A session which is idle for more than an hour > can't be considered to be active. Coupled with an extremely low state limit, > and you're asking for problems. If the session is active at all before the > session timeout is hit, the timer is reset. I'm sorry but I have to object. Having past experience in Oracle Support for networking issues I did see many problems with statefull firewalls which were cutting off idle Oracle connections. The base line is: DO NOT assume connections are dead even if they are idle for more than an hour... > > > I'm not saying he's getting DOSd, but with such low limits, even a normal > home network is going to run into problems at some point. We can see from > the diagnostic output provided earlier that there were no issues when it was > collected, but was it collected while there was an outage? > > If the problem still occurs, it may be worth scripting something to collect > some pfctl -g -v -v -v -s all and some sysctl -a, vmstat output as well. Well, just keep a 'pfctl -s state >/var/tmp/pf-states.txt' running in cron every few minutes then and let's check it out... Regards, Adrian. > > > Pierre > > Adrian Penisoara wrote: > >> Hi, >> >> On Wed, Mar 25, 2009 at 11:21 PM, Shawn Everett wrote: >> >> >> >>> tcp.established 86400s >>>> >>>> ^^ This should be 3600. >>>> >>>> Pierre >>>> >>>> >>> That's an interesting thought. Why would that matter? >>> >>> >> >> >> It's the PF TCP established session timeout, which defaults to 1 day. This >> is relevant only if you see a lot of ESTABLISHED sessions in the 'pfctl -s >> state' output, which appears not to be the case... >> >> >> Regards, >> Adrian. >> ___ >> 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" >> >> > ___ 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: kevent behavior with TCP socket
Hi,
On Sat, Aug 8, 2009 at 10:42 AM, Denis Berezhnoy
wrote:
> Hi,
>
> Sorry for my previous post it was completely unclear I believe. Here is
> problem description in pure C. Can you please take a look at the code
> below:
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include
> #include
> #include
> #include
>
>
>
> int main(int argc, char *argv[])
> {
> struct sockaddr_in addr;
> struct sockaddr_in addr2;
>
> int sd, cd, port, sRet;
>
> int sHandle;
> int sEventNum = 0;
>
> struct kevent sChange;
> struct kevent sEvent;
>
> struct timespec *sTimeoutPtr;
> struct timespec sTimeout;
>
> struct timeval sTimeVal1 = {0,0};
> struct timeval sTimeVal2 = {0,0};
>
> printf("Socket test start\n");
>
> sd = socket(PF_INET, SOCK_STREAM, 0);
>
> if ( sd < 0 )
> {
> printf("Server socket error\n");
> return 0;
> }
>
> port = htons(1);
>
>
> memset(&addr, 0, sizeof(addr));
> addr.sin_family = AF_INET;
> addr.sin_port = port;
> addr.sin_addr.s_addr = htonl(INADDR_ANY);
>
> if ( bind(sd, (struct sockaddr*)&addr, sizeof(addr)) != 0 )
>
> {
> printf ("Server bind errror\n");
> return 0;
> }
>
>
>
> if ( listen(sd, 1) != 0 )
> {
> printf ("Server listen error \n");
> return 0;
> }
>
>
> cd = socket(PF_INET, SOCK_STREAM, 0);
>
> if ( cd < 0 )
> {
> printf("Client socket error\n");
> return 0;
> }
>
> sRet = fcntl(cd, F_GETFL, 0);
>
> sRet |= O_NONBLOCK;
>
> sRet = fcntl(cd, F_SETFL, sRet);
>
> if (sRet < 0)
> {
> printf("can not set non block\n");
> }
>
> port = htons(1);
>
> memset(&addr2, 0, sizeof(addr2)); /* Clear struct */
> addr2.sin_family = AF_INET; /* Internet/IP */
> addr2.sin_addr.s_addr = htonl(INADDR_LOOPBACK); /* IP address */
> addr2.sin_port = port; /* server port */
>
> /* Establish connection */
>
> if ((sRet = connect(cd,
> (struct sockaddr *) &addr2,
> sizeof(addr2))) < 0)
> {
>
> printf("Failed to connect with server %d\n", errno);
>
> }
>
>
> sHandle = kqueue();
>
>
> if (sHandle == -1)
> {
> printf("Poll can not created queue\n");
> }
>
> sTimeout.tv_sec = 0;
> sTimeout.tv_nsec = 1;;
>
> EV_SET(&sChange, cd, EVFILT_WRITE, EV_ADD,0, 0, 0);
>
>
> gettimeofday(&sTimeVal1, NULL);
>
> sEventNum = kevent(sHandle,
> &sChange,
> 1,
> &sEvent,
> 1,
> &sTimeout);
>
> gettimeofday(&sTimeVal2, NULL);
>
> printf ("Kevent event num %d wait time %d \n", sEventNum, sTimeVal2.tv_usec
> - sTimeVal1.tv_usec);
>
> if (sEventNum == 1)
> {
> printf ("Event filter %d flag %d data %d \n", sEvent.filter, sEvent.flags,
> sEvent.data);
> }
>
> close(sHandle);
>
> close(cd);
>
> close(sd);
>
> printf("Socket test end\n");
> }
>
> Program output
>
> Socket test start
> Failed to connect with server 36
> Kevent event num 1 wait time 26
> Event filter -2 flag 0 data 43008
> Socket test end
>
> The question is why kevent returns 1 event when server does not accept
> connections from clients.
>
Question: is there something listening on your loopback address
(127.0.0.1) or all addresses at port 1 (sockstat -4 output should be
evident) ? If not, have you also tested with something listening on that
address ?
If there is nothing to connect onto the loopback address then the
connection will immediately fail. Then I believe kevent should return with a
failure filter flag set.
One problem I see is that you are checking the action flags (kevent.flags)
instead of the filter flags (kevent.fflags). Please re-run checking the
sEvent.fflags field and compare with values in and let us/me
know what do you get.
Regards,
Adrian Penisoara
EnterpriseBSD
___
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: kevent behavior with TCP socket
Hi, On Mon, Aug 10, 2009 at 5:17 AM, Denis Berezhnoy wrote: > Hi Adrian, > Thank for your answer! I checked that nobody listens for loopback address: > > [de...@freebsd ~]$ sockstat -4 > USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS > > denissshd 95390 3 tcp4 192.168.1.103:22 > 192.168.11.26:53616 > root sshd 95387 3 tcp4 192.168.1.103:22 > 192.168.11.26:53616 > denissshd 95324 3 tcp4 192.168.1.103:22 > 192.168.11.26:53608 > root sshd 95321 3 tcp4 192.168.1.103:22 > 192.168.11.26:53608 > root sshd 8149 4 tcp4 *:22 *:* > root inetd 870 5 tcp4 *:21 *:* > root inetd 870 6 tcp4 *:23 *:* > root sendmail 821 4 tcp4 127.0.0.1:25 *:* > root syslogd689 7 udp4 *:514 *:* > [de...@freebsd ~]$ > > > I printed out fflags. Here is the result: > > Kevent event num 1 wait time 46 > Event filter -2 flag 0 filter flags 0 data 43008 > > > When I comment out the part of the code that listens socket then I have the > following output: > > Kevent event num 1 wait time 23 > Event filter -2 flag 32768 filter flags 61 data 32768 > > > 61 is ECONNREFUSED > > > And more when I make loopback address listening and try to connect it I > still get the same output: > > Socket test start > Failed to connect with server 36 > Kevent event num 1 wait time 23 > Event filter -2 flag 0 filter flags 0 data 43008 > Socket test end > > but connection is actually accepted. I am totally confused here. > Well, actually it's very much evident: * When you don't make the listen() first, then the connection is correctly reported as refused * When you make the listen() on the INADDR_ANY then you will open port 1 on all local IP addresses, _including_ the loopback address -- that's why the client connect() succeeds and kevent reports a success event. This is an expected behavior. Try to bind the sd descriptor to another port than the one used to connect onto the loopback address and you will see the connection being refused. Regards, Adrian EnterpriseBSD ___ 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: RFC: ARP Statistics
Hi,
Perhaps it would be useful to add a "ARP flip-flop events" field, counting
the "arp: is on but got reply from on " events.
PS: minor nit/correction: use "ARP cache entries timed out" instead of "ARP
entrys timed out"
Regards,
Adrian Penisoara
EnterpriseBSD
On Wed, Aug 12, 2009 at 3:43 PM, George Neville-Neil
wrote:
> Howdy,
>
> Here is a small patch that updates the kernel and the netstat(1) program to
> print out protocol
> statistics for ARP. I'd be interested in any feedback people have on this.
>
> Sample output:
>
> netstat -s -p arp
> arp:
>469 ARP requests sent
>2117 ARP replies received
>0 total packets dropped due to no ARP entry
>469 ARP entrys timed out
>0 Duplicate IPs seen
>
>
> Best,
> George
>
>
>
> Index: usr.bin/netstat/inet.c
> ===
> --- usr.bin/netstat/inet.c (revision 196095)
> +++ usr.bin/netstat/inet.c (working copy)
> @@ -49,6 +49,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -871,6 +872,44 @@
> #undef p1a
> }
>
> +/*
> + * Dump ARP statistics structure.
> + */
> +void
> +arp_stats(u_long off, const char *name, int af1 __unused, int proto
> __unused)
> +{
> + struct arpstat arpstat, zerostat;
> + size_t len = sizeof(arpstat);
> +
> + if (live) {
> + if (zflag)
> + memset(&zerostat, 0, len);
> + if (sysctlbyname("net.link.ether.arp.stats", &arpstat,
> &len,
> + zflag ? &zerostat : NULL, zflag ? len : 0) < 0) {
> + warn("sysctl: net.link.ether.arp.stats");
> + return;
> + }
> + } else
> + kread(off, &arpstat, len);
> +
> + printf("%s:\n", name);
> +
> +#definep(f, m) if (arpstat.f || sflag <= 1) \
> +printf(m, arpstat.f, plural(arpstat.f))
> +#definep1a(f, m) if (arpstat.f || sflag <= 1) \
> +printf(m, arpstat.f)
> +
> + p(arp_requests, "\t%lu ARP request%s sent\n");
> + p(arp_replies, "\t%lu ARP replie%s received\n");
> + p(arp_dropped, "\t%lu total packet%s dropped due to no ARP
> entry\n");
> + p(arp_timeout, "\t%lu ARP entry%s timed out\n");
> + p(arp_dupips, "\t%lu Duplicate IP%s seen\n");
> +#undef p
> +#undef p1a
> +}
> +
> +
> +
> static const char *icmpnames[ICMP_MAXTYPE + 1] = {
>"echo reply", /* RFC 792 */
>"#1",
> Index: usr.bin/netstat/main.c
> ===
> --- usr.bin/netstat/main.c (revision 196095)
> +++ usr.bin/netstat/main.c (working copy)
> @@ -184,6 +184,8 @@
>{ .n_name = "_sctpstat" },
> #defineN_MFCTABLESIZE 54
>{ .n_name = "_mfctablesize" },
> +#define N_ARPSTAT 55
> + { .n_name = "_arpstat" },
>{ .n_name = NULL },
> };
>
> @@ -232,6 +234,8 @@
> carp_stats, NULL, "carp", 1, 0 },
>{ -1, N_PFSYNCSTAT, 1, NULL,
> pfsync_stats, NULL, "pfsync", 1,0 },
> + { -1, N_ARPSTAT, 1, NULL,
> + arp_stats,NULL, "arp", 1, 0 },
>{ -1, -1, 0, NULL,
> NULL, NULL, NULL, 0, 0 }
> };
> Index: usr.bin/netstat/netstat.h
> ===
> --- usr.bin/netstat/netstat.h (revision 196095)
> +++ usr.bin/netstat/netstat.h (working copy)
> @@ -75,6 +75,7 @@
> void sctp_protopr(u_long, const char *, int, int);
> void sctp_stats(u_long, const char *, int, int);
> #endif
> +void arp_stats(u_long, const char *, int, int);
> void ip_stats(u_long, const char *, int, int);
> void icmp_stats(u_long, const char *, int, int);
> void igmp_stats(u_long, const char *, int, int);
> Index: sys/netinet/if_ether.c
> ===
> --- sys/netinet/if_ether.c (revision 196095)
> +++ sys/netinet/if_ether.c (working copy)
> @@ -80,6 +80,7 @@
>
> SYSCTL_DECL(_net_link_ether);
> SYSCTL_NODE(_net_link_ether, PF_INET, inet, CTLFLAG_RW, 0, "");
> +SYSCTL_NODE(_net_link_ether, PF_ARP, arp, CTLFLAG_RW, 0, "");
>
> VNET_DEFIN
Kernel crush due to frag attack
Hi,
As we are facing a heavy fragments attack (40-60byte packets in a
~ 1000 pkts/sec flow) I see some sporadic panics. Kernel/world is
4.2-STABLE as of 18 Jan 2001 -- it's a production machine and I hadn't yet
the chance for another update; if it's been fixed in the mean time I would
be glad to hear it...
I have attached a gdb trace and a snip of a tcpdump log. When I rebuilt
the kernel with debug options it seemed to crush less often. I remember
that at the time of this panic I had an ipfw rule to deny IP fragments.
If you need further data just ask, I'd be glad to help,
Ady (@warpnet.ro)
Script started on Sun Feb 25 20:00:14 2001
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.0
(kgdb) core-file /var/crash/vmcore.0
IdlePTD 2928640
initial pcb at 24d1a0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x89c0c800
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc014de98
stack pointer = 0x10:0xc0231340
frame pointer = 0x10:0xc023135c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = net
trap number = 12
panic: page fault
syncing disks...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x30
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01a9034
stack pointer = 0x10:0xc0231170
frame pointer = 0x10:0xc0231174
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = net bio cam
trap number = 12
panic: page fault
Uptime: 5d14h45m42s
dumping to dev #ad/0x20001, offset 525953
dump ata0: resetting devices .. done
126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106
105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79
78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50
49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21
20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../kern/kern_shutdown.c:469
469 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc0132d67 in boot (howto=260) at ../../kern/kern_shutdown.c:309
#2 0xc01330e4 in poweroff_wait (junk=0xc02292af, howto=0)
at ../../kern/kern_shutdown.c:556
#3 0xc01f8e05 in trap_fatal (frame=0xc0231130, eva=48)
at ../../i386/i386/trap.c:951
#4 0xc01f8add in trap_pfault (frame=0xc0231130, usermode=0, eva=48)
at ../../i386/i386/trap.c:844
#5 0xc01f86c3 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = -1072562160,
tf_edi = 0, tf_esi = -1071245792, tf_ebp = -1071443596,
tf_isp = -1071443620, tf_ebx = -1071385060, tf_edx = 6864960,
tf_ecx = 5, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1072000972, tf_cs = 8, tf_eflags = 66054, tf_esp = 0,
tf_ss = -1071443568}) at ../../i386/i386/trap.c:443
#6 0xc01a9034 in acquire_lock (lk=0xc023f61c)
at ../../ufs/ffs/ffs_softdep.c:268
#7 0xc01ad2ce in softdep_fsync_mountdev (vp=0xc880fa80)
at ../../ufs/ffs/ffs_softdep.c:3846
#8 0xc01b143a in ffs_fsync (ap=0xc02311e8) at ../../ufs/ffs/ffs_vnops.c:134
#9 0xc01b013a in ffs_sync (mp=0xc0cd4c00, waitfor=2, cred=0xc072c900,
p=0xc0261620) at vnode_if.h:537
#10 0xc016109b in sync (p=0xc0261620, uap=0x0) at ../../kern/vfs_syscalls.c:545
#11 0xc0132b3a in boot (howto=256) at ../../kern/kern_shutdown.c:233
#12 0xc01330e4 in poweroff_wait (junk=0xc02292af, howto=0)
at ../../kern/kern_shutdown.c:556
#13 0xc01f8e05 in trap_fatal (frame=0xc0231300, eva=232704)
at ../../i386/i386/trap.c:951
#14 0xc01f8add in trap_pfault (frame=0xc0231300, usermode=0, eva=232704)
at ../../i386/i386/trap.c:844
#15 0xc01f86c3 in trap (frame={tf_fs = -1072234480, tf_es = 6422544,
tf_ds = 16, tf_edi = -1071443112, tf_esi = 6422528,
tf_ebp = -1071443108, tf_isp = -1071443156, tf_ebx = 1,
Re: Kernel crush due to frag attack
Hi,
Coming back to you with a reply I should have given earlier. See below.
In the mean time I have applied one of Ruslan Emirov's patches and had
no panics ever since. Clearly not a hardware issue but faulty code :) ...
I also see that there has been applied a patch (by jkh) in the CVS tree
for this matter, I hope it solves the problem, I haven't checked yet.
On Sun, 25 Feb 2001, Bosko Milekic wrote:
>
> Adrian Penisoara wrote:
>
> > Hi,
> >
> > As we are facing a heavy fragments attack (40-60byte packets in a
> > ~ 1000 pkts/sec flow) I see some sporadic panics. Kernel/world is
> > 4.2-STABLE as of 18 Jan 2001 -- it's a production machine and I
> hadn't yet
> > the chance for another update; if it's been fixed in the mean time I
> would
> > be glad to hear it...
> >
> > I have attached a gdb trace and a snip of a tcpdump log. When I
> rebuilt
> > the kernel with debug options it seemed to crush less often. I
> remember
> > that at the time of this panic I had an ipfw rule to deny IP
> fragments.
>
> This is one of those "odd" faults I've seen in -STABLE sometimes.
> Thanks to good debugging information you've provided, to be noted:
>
> #16 0xc014de98 in m_copym (m=0xc07e7c00, off0=0, len=40, wait=1)
> at ../../kern/uipc_mbuf.c:621
> 621 n->m_pkthdr.len -= off0;
> (kgdb) list
> 616 if (n == 0)
> 617 goto nospace;
> 618 if (copyhdr) {
> 619 M_COPY_PKTHDR(n, m);
> 620 if (len == M_COPYALL)
> 621 n->m_pkthdr.len -= off0;<-- fault happens here (XXX)
> 622else
> 623 n->m_pkthdr.len = len;
> 624 copyhdr = 0;
> 625}
> (kgdb) print n
> $1 = (struct mbuf *) 0x661c20
> (kgdb) print *n
> cannot read proc at 0
> (kgdb) print m
> $2 = (struct mbuf *) 0xc07e7c00
>
> Where the fault happens (XXX), the possible problem is that the mbuf
> pointer n is bad, and as printed from the debugger, it does appear to
> be bad. However, there are two things to note:
>
> 1. the fault virtual address displayed in the trap message:
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x89c0c800
> [...]
>
> is different from the one printed in your analysis (even though
> 0x89c0c800 seems bogus as well, although it is at a correct boundry).
>
> 2. Nothing bad happens in M_COPY_PKTHDR() which dereferences an
> equivalent pointer.
>
> Something seriously evil is happening here and, unfortunately, I have
> no idea what.
>
> Does this only happen on this one machine? Or is it reproducable on
> several different machines? I used to stress test -STABLE for mbuf
> starvation and never stumbled upon one of these `spontaneous pointer
> deaths' myself. Although I have seen other weird problems reported by
> other people, but only in RELENG_3.
I see this exhibited so far only on our server (other machines don't get
the fragments as they are dropped on entry in our gateway).
>
> If you cannot reproduce it on any other machines, I would start
> looking at possibly bad hardware... unless someone else sees something
> I'm not.
As I said, ever since I applied Ruslan Emirov's patch the panics didn't
exhibit anymore.
RGDS,
Ady (@warpnet.ro)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
ALTQ integration in FreeBSD
Hi, For my diploma exam I will study the state of QoS in today's networking and further directions and I probably will concentrate on ALTQ in FreeBSD (as I'm pretty familiar w/ FreeBSD). I see that most of today's OSes have a default QoS implementation (at least Win2000 and OpenBSD come to my mind) and there is a growing need for QoS integration into the OS. I was wondering what kept FreeBSD from integrating a QoS implementation (as it did with Kame IPv6) -- for example what are pro and cons of integration ALTQ in FreeBSD (I saw there was a thread launched sometime in the beginning of May 2001). I also saw that ALTQ on FreeBSD seems to be used pretty much even in production. What other QoS implementation alternatives are available for FreeBSD ? Why didn't FreeBSD follow tracks along OpenBSD's integration of ALTQ ? I would be delighted to know that FreeBSD will integrate a QoS implementation (ALTQ) and I would like to contribute in this direction. Thank you, Ady (@freebsd.ady.ro) ___ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra)| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Help needed: ALTQ integration into FreeBSD
Hi, Having the prerequisite agreement of the FreeBSD core team I'm delighted to announce my intention of putting the basis of a "ALTQ framework integration into FreeBSD" project. The current set target is "porting" the sources of the ALTQ project (ALTQ 3.1 is available for the 4.5-RELEASE branch) to FreeBSD-current. This is certainly not a easy nor simple task and I surely don't have all the skills needed right now, so I'm going to need help. I'm looking for a mentor (or more) with FreeBSD core networking knowledge and, if possible, with commit privileges to the right spots. If you know such a person or if you are one please contact me. Also, anybody interested to discuss, contribute or help in any other way is very welcomed to contact me. Reference: ALTQ project home http://www.csl.sony.co.jp/person/kjc/kjc/software.html Thank you very much, Adrian Penisoara Ady (@freebsd.ady.ro) ___ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra)| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Help needed: ALTQ integration into FreeBSD
Hi, Thank you all for your replies. I will keep track of all the mentioned issues. In the mean time I will be waiting for Mr. Kenjiro Cho to return and have a chat with him. I will keep you posted with my/our progress. Thanks! Ady (@freebsd.ady.ro) ___ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra)| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ATTN: ALTQ integration -- looking for people
Hi, The ALTQ integration project is about to emerge. We will need heelp with code reviewing, SMP procedures (making ALTQ SMP-safe), networking architecture and, last but not least, we are looking for one (or more) committer to help us with patch integrations. All interested people please reply to the address <[EMAIL PROTECTED]> (an ALTQ developing mini-list). Please also specify wether you'd like your e-mail address to be added to this list. Thanks! Adrian Penisoara Ady (@freebsd.ady.ro) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
HEADS UP: ALTQ integration developer preview
We have started a "ALTQ integration in FreeBSD" project which is headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been advised and we have received on principle approval. We are looking for help with committing these bits to the CVS tree. Please have a look at the proposed ALTQ package for 5.0-current, which is found here: http://www.rofug.ro/projects/freebsd-altq/altq-freebsd-5.0-current-May14.tar.gz Installation details are found in the README file; for further details consult the documentation referenced below. Please send us any comments you have, your feedback is valuable. ALTQ integration implies some changes in the network drivers code and in the design of the the network queues management. Here is a summary of the ALTQ design document: The BSD systems need better output queueing abstraction to support packet scheduling (e.g., CBQ) or active queue management (e.g., RED). To introduce a new model, we need to convert the existing code to be conformant to the new model. But the problem is that there are too many drivers to convert all at once. This is a proposal that allows incremental transition to the new model. (If we are going to modify the existing drivers, we need to get it right.) The model is designed for ALTQ but it is general enough for other implementations so that we can make the driver conversion once and for all. The new model removes direct references to the fields within ifp->if_snd, and defines the following macros to manipulate ifp->if_snd: IFQ_ENQUEUE(ifq, m, err) IFQ_DEQUEUE(ifq, m) IFQ_POLL(ifq, m) IFQ_PURGE(ifq) IFQ_IS_EMPTY(ifq) The new model also enforces some rules regarding how to use these macros. Another requirement for a driver is to work under rate-limiting. - IFQ_DEQUEUE() could return NULL even when IFQ_IS_EMPTY() is FALSE under rate-limiting. a driver should always check if (m == NULL). - a driver is supposed to call if_start from the tx complete interrupt under late-limiting (in order to trigger the next dequeue). For most drivers, it is a simple task of replacing old-style lines by the corresponding new-style lines, and usually just a few lines need to be modified. But some drivers need more than that. The old-style drivers still work with the original FIFO queue but they cannot take advantage of new queueing disciplines. For locking an output queue to support SMP, ALTQ uses the same model as in FreeBSD-5.0. One restriction is that, if a driver uses poll-and-dequeue, the driver needs to explicitly lock the queue between the poll operation and the dequeue operation. You can find more details here: http://www.csl.sony.co.jp/person/kjc/kjc/software/altq-new-design.txt http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ Current development is headed by Kenjiro Cho and myself. If you want to join our efforts please subscribe to our mailing list by sending "subscribe" in the body of a message to [EMAIL PROTECTED] Adrian Penisoara Ady (@freebsd.ady.ro, @rofug.ro) ___ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra)| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: HEADS UP: ALTQ integration developer preview
Hi, On Fri, 17 May 2002, Attila Nagy wrote: > >We have started a "ALTQ integration in FreeBSD" project which is > > headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD > > 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been > > advised and we have received on principle approval. We are looking for > > help with committing these bits to the CVS tree. > Great. Do you have plans to merge OpenBSD's TCP_ECN stuff, committed > yesterday to the tree? Thanks for the pointer ! I don't know yet if we will merge it, but be sure we will review it. BTW, who does the integration/maintainance of ALTQ in OpenBSD ? > > > Please have a look at the proposed ALTQ package for 5.0-current, which > > is found here: > > http://www.rofug.ro/projects/freebsd-altq/altq-freebsd-5.0-current-May14.tar.gz > Although I'm not a coder myself, I would also look for the way to patch > the "em" driver (if "gx" is already in the initial plan), because it > reportedly works better (for example I couldn't do NFS serving with UDP > packets bigger than the MTU with that, while the "em" driver works OK). Our goal is to have _all_ the drivers modified and new drivers to use by default the new queueing handling scheme :). Ady (@freebsd.ady.ro) ___ | Programming in BASIC causes brain damage. | | (Edsger Wybe Dijkstra)| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Desired feature: ipfw pass for routed IPs
Hi, When building anti-spoofing firewall rules on a routing server it would be very helpfull to have a way to tell ipfw (or other firewalling mechanisms) to pass all pachets that the source or destination IP has a valid (static/daemon) routing entry in the kernel. Something maybe like: ipfw add allow ip from any to any routed static via xl0 ipfw add deny ip from any to any via xl0 The 'routed' keyword should accept route associated flags (like those listed in route(8)). That would be a desired feature too, because some routing daemons mark their routes in a different way (for example Zebra brings up the RTF_PROTO1 flag on its routes). It's been said that iproute2 in the recent Linux kernels alreay support this, but I haven't checked out closely. How hard would that be to implement ? Thank you, Adrian Penisoara Ady (@freebsd.ady.ro) | An age is called Dark not because the light fails to shine, but | | because people refuse to see it. | | -- James Michener, "Space" | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
New sys-altw patchset for FreeBSD 4.9-[PRE]RELEASE
Hi, I have rebuilt the sys-altq patches against the sources of FreeBSD 4.9-RC as of 9th October. As the RELENG_4 branch has entered the 4.9 pre-release stage, I assume that no critical changes will occur until official release time which would broke this patchset. You can download the patchsed from the FreeBSD/ALTQ's project page: http://www.rofug.ro/projects/freebsd-altq/ Or directly from here: http://www.rofug.ro/projects/freebsd-altq/sys-altq-freebsd-4.9-RELEASE.patch.gz Side-notes: * No major modifications, just driver updates * dev/em/if_em.c, dev/ie/if_ie.c fixups * pci/if_dc.c fixup which needs review * This patchsed has been used in production for about one week using the rl(4) newtork interface with no problems -- Adrian Penisoara Ady (@freebsd.ady.ro) www.rofug.ro ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Handling 100.000 packets/sec or more
Hi, At one site that I administer we have a gateway server which services a large SOHO LAN (more than 300 stations) and I'm facing a serious issue: very often we see strong spoofed floods (variable source IP and port, variable destination IP, destination port 80) which can go as far as 100 000 packets/sec! Of course, the server (FreeBSD 5.2-REL, PIII 733Mhz, 256Mb RAM, 3COM 3C905B-TX aka xl0 with checksum offloading support) has a hard time swallowing this kind of traffic. The main issue are the IRQ interrupts: over 15000 interrupts/sec which consume more than 90% of the CPU time. We got ingress filtering so the packets go no further than the firewall (which, BTW, is not the issue, even disabling it it's the same problem). The system is still responsive but the load average goes as high as 10 and the interface is losing packets (input errors) which dramatically affects legitimate traffic, besides mbuf(9) starvation. We are taking down the culprit clients, but this takes time and we need the other clients not to be affected by it. What can I do to make the system better handle this kind of traffic ? Could device polling(8) or just increasing the kernel frequency clock to 1000Hz or more improve the situation ? What kind of network cards could face a lot better this burden ? Are there any other solutions ? On a side note: what would be a adequate formula to calculate the NMBCLUSTERS and MBUFS we should set on this server (via boot-time kern.ipc.nmbclusters and kern.ipc.nmbufs) ? Thank you. -- Adrian Penisoara Ady (@freebsd.ady.ro) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
The forthcoming altq-freebsd-5.2-release-beta2
Hi, The second beta package is coming out soon and will contain some small fixes (if_fxp.c compile fix, dc(4) not-working fix). Does anyone have any more issues or suggested patches for -beta1 ? Thank you. -- Adrian Penisoara Ady (@freebsd.ady.ro) FreeBSD/ALTQ project http://www.rofug.ro/projects/freebsd-altq/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Handling 100.000 packets/sec or more
Hi again, Thanks for all your answers. A small comment though. Vlad Galu wrote: > Try fxp. It has better polling support, and there's the >advantage of >the link0 flag. When it's set, the interface won't send interrupts to The man page sais that only some versions of the chipset supports this (microcode download). Do you (or anyone else) know the exact version(s) of the EtherExpress chip that supports this (and perhaps you have tried it) ? Oh well, looking at the source code it seems you can discern the enabled versions from here: sys/dev/fxp/rcvbundl.h (Intel source) and sys/dev/fxp/if_fxp.c (to the end of file). Resumed: FXP_REV_82558_A4 FXP_REV_82558_B0 FXP_REV_82559_A0 FXP_REV_82559S_A FXP_REV_82550 FXP_REV_82550_C Or by Intel revision codes: D101 A-step, D101 B-step, D101M (B-step only), D101S, D102 B-step, D102 B-step with TCO work around and D012 C-step. I did not quite understand wether the embedded ICH3/4 network interfaces are also "link0" enabled. >the kernel for each packet it catches from the wire, but instead will >wait until its own buffer is full, and generate an interrupt >afterwards. >It should be a great deal of improvement when asociated with device >polling. As you surely know, when the kernel receives an interrupt from >an interface, it masks all further interrupts and schedules a polling >task instead. [...] >| On a side note: what would be a adequate formula to calculate the >|NMBCLUSTERS and MBUFS we should set on this server (via boot-time >|kern.ipc.nmbclusters and kern.ipc.nmbufs) ? >| > > I'm still thinking about that ... > Did you come up with anything ? PS: Keep me in CC:. Thanks. -- Adrian Penisoara Ady (@freebsd.ady.ro) On Wed, 14 Jan 2004, Adrian Penisoara wrote: > Hi, > > At one site that I administer we have a gateway server which services > a large SOHO LAN (more than 300 stations) and I'm facing a serious > issue: very often we see strong spoofed floods (variable source IP and > port, variable destination IP, destination port 80) which can go as far > as 100 000 packets/sec! > > Of course, the server (FreeBSD 5.2-REL, PIII 733Mhz, 256Mb RAM, 3COM > 3C905B-TX aka xl0 with checksum offloading support) has a hard time > swallowing this kind of traffic. The main issue are the IRQ interrupts: > over 15000 interrupts/sec which consume more than 90% of the CPU time. > We got ingress filtering so the packets go no further than the firewall > (which, BTW, is not the issue, even disabling it it's the same problem). > The system is still responsive but the load average goes as high as 10 > and the interface is losing packets (input errors) which dramatically > affects legitimate traffic, besides mbuf(9) starvation. We are taking > down the culprit clients, but this takes time and we need the other > clients not to be affected by it. > > What can I do to make the system better handle this kind of traffic ? > Could device polling(8) or just increasing the kernel frequency clock to > 1000Hz or more improve the situation ? > What kind of network cards could face a lot better this burden ? Are > there any other solutions ? > > On a side note: what would be a adequate formula to calculate the > NMBCLUSTERS and MBUFS we should set on this server (via boot-time > kern.ipc.nmbclusters and kern.ipc.nmbufs) ? > > Thank you. > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ALTQ second beta package for FreeBSD 5.2-RELEASE
Hi, You can download the package from the FreeBSD/ALTQ project webpage: http://www.rofug.ro/projects/freebsd-altq/ or directly from here: http://www.rofug.ro/projects/freebsd-altq/altq-freebsd-5.2-release-beta2.tar.gz MD5: 7bddb0ff3564cc03c180b5f10286db2e Notes: * Focus is shifting on preparing ALTQ for the Giantlock-free environment in 5-CURRENT, which will become the default for the network stack at some point in time. * There are still quite a few drivers that could be ALTQ enabled without much effort. Changelog: - fxp(4) fix (credit goes to Max Layer) - net80211 fix (idem) - disabled TBR interaction in fxp(4) -- Pyun YongHyeon experienced IRQ storms under SMP; plus architecture independency fix - dc(4) small fix related to architecture independency - dc(4) not-working fix from Max Laier, spotted by rik - rl(4) ALTQ diffs rewritten & simplified (spotted by Pyun YongHyeon) - updated ALTQ core files to enable the MPSAFE bit and mark some timecounters as volatile (credit to Pyun YongHyeon) - updated the ALTQ kernel configuration file - updated README - updated Changelog (properly credit folks in -beta1 history) -- Adrian Penisoara Ady (@freebsd.ady.ro) FreeBSD/ALTQ project http://www.rofug.ro/projects/freebsd-altq/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vlan(4)/bridge(4) interaction ?
Hi, I recently made a test bridging a few VLAN interfaces under FreeBSD 5.2-REL and ran into some unexpected issue: some packets coming from one vlan inteface with destination MAC on another vlan would pass in the parent VLAN interface, but didn't make it into the child vlan interface, as seen by tcpdump'ing on both of them. Like the packet was eaten before it made it into the child vlan interface. Activating the debug code shows that neither the bridge fordwarding routine wasn't catching the packets. All vlans were child of the same parent interface (a RealTek) and they were all configuren in the same bridge cluster. Either with configured IPs or without (just up'ed the intefaces). I might have botched the interfaces by mutiple reconfigurations, but I just would like to know if other people had success with bridged VLAN interfaces (yes, it sounds a bit weird if you think of it :) ). -- Adrian Penisoara Ady (@freebsd,ady.ro) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
