microuptime() went backwards... on a K7 with 7kxa mobo

2004-05-09 Thread Micael Ebbmar 
Thought I would use my old K7 600 MHz and 7KXA mobo as a gateway since my old K6-2 
died, 
and have run into a common problem when I installed 4.9.

When under high IO (network or CPU use) I get the microuptime() went backwards
flooding my screen, and syslog logging it making the system crawl until syslog is 
killed.
I have went through the standard procedure, disabled APM in bios and removing it from
the kernel, made sure sysctl kern.timecounter.method is set to 1, but to no help.

Anyone got any hints?
-- 
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]

IPFW2 denies packet although they match ALLOW rule?

2002-11-09 Thread Micael Ebbmar 
Excuse me if I'm posting to the wrong list, I thought at first that freebsd-ipfw 
should be
the correct one, but obviously only discussion about the redesign of IPFW should be 
discussed there.

Anyways, I hope someone can help me here..

A week ago, I made the transition from IPFW to IPFW2 (on my 4.7-Stable box), and I 
thought it would
be a good idea to rewrite my previous stateless rules to stateful.
After a few days I noticed in /var/log security that IPFW once in a while blocks 
outbound
packets to my pop servers and a webserver, which I've allowed in a previously rule 
(0310).
I still can pop my mail and browse the web without any problems, but I'm stil curious 
why it denies the packets. Can it be
that the stateful rule has expired and the interface is resending/receiving some old 
packets? If so, is that normal or an
indication of a broken NIC?
Or is any of the sysctl variables net.inet.ip.fw.* too short? (Haven't touched them 
yet)

Log snippet of /var/log/security:


Nov  8 00:25:42 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1938 
207.174.189.161:80 out via ep1
Nov  8 00:26:12 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1940 
207.174.189.161:80 out via ep1
Nov  8 00:26:12 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1938 
207.174.189.161:80 out via ep1
Nov  8 00:26:14 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1940 
207.174.189.161:80 out via ep1
Nov  8 00:26:18 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1940 
207.174.189.161:80 out via ep1
Nov  8 00:26:26 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1940 
207.174.189.161:80 out via ep1
Nov  8 00:26:27 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1939 
207.174.189.161:80 out via ep1
Nov  8 00:26:29 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1939 
207.174.189.161:80 out via ep1
Nov  8 00:26:33 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1939 
207.174.189.161:80 out via ep1
Nov  8 00:26:41 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1939 
207.174.189.161:80 out via ep1
Nov  8 00:26:42 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1940 
207.174.189.161:80 out via ep1
Nov  8 00:26:45 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1938 
207.174.189.161:80 out via ep1
Nov  8 00:26:57 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1939 
207.174.189.161:80 out via ep1
Nov  8 00:27:15 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1940 
207.174.189.161:80 out via ep1
Nov  8 00:27:30 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1939 
207.174.189.161:80 out via ep1
Nov  8 00:27:49 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1938 
207.174.189.161:80 out via ep1
...
Nov  8 16:47:10 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:47:31 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:48:14 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:49:18 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:50:22 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:51:26 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:52:30 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:53:34 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:54:38 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:55:42 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:56:46 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:57:50 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1
Nov  8 16:58:54 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:2529 66.54.152.7:110 
out via ep1

And my rules look like this:

# Identd
add 0200 reset log tcp from any to any 113

# Only allow outbound TCP connections I have created
add 0300 check-state

# Deny packets with ACK flag set which doesn't match the above rule
add 0305 deny tcp from any to any in established

# Allow all outgoing setup TCP connections (SYN)
add 0310 allow tcp from any to any out setup keep-state

# Allow login on ISP
add 0350 allow tcp from me to 10.0.0.6 80 setup keep-state

# Allow DNS
add 0400 allow udp from me to 10.0.0/24{1,2} 53 keep-state out xmit ep1

# Allow DHCP offers and requests
add 0500 allow udp from me 68 to 213.64.75.1 keep-state out via ep1

# Allow ntpd to lth.se and ntp1.sp.se
add 0600 allow ip from me 123 to 130.235.20.3 keep-state out via ep1

# Allow some ICMP types (dest. unreachable, source quench,
# echo reply/request, time exceed)
add 0650 allow icmp from any to any icmptypes 3,4
add 0655 allow icmp from any to any icmptypes 8 out
add 0660 allow icmp from any to any icmptypes 0,11 in

# Allow access to my webserver from school
add 0700 allow tcp from 193.10.0.0/16 to me 80 setup

Re: IPFW2 denies packet although they match ALLOW rule?

2002-11-09 Thread Micael Ebbmar 
* Giorgos Keramidas [EMAIL PROTECTED] [021109 23:11]:
 
 Web clients some times cache connections to web servers, hoping to save
 some time from avoiding a reconnect for every GET request.  Could it be
 that your clients thinks that a cached connection is still valid long
 after the dynamic ipfw rule has expired?

Well, that's a possibility.. esp. with all those banners that refreshes every now
and then.

But that doesn't explain why the computer tries to contact the pop servers (through
Fetchmail) even after the normal connection has been terminated. Since Fetchmail has
finished the conversation with the popservers, the rule terminates. Then after
some time, it tries to connect again (note: not initialize, since obviously the SYN 
isn't set and there it's blocked by rule 1000). 
I just find it very odd.

 
 : Log snippet of /var/log/security:
 : 
 : Nov  8 00:25:42 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1938 
207.174.189.161:80 out via ep1
 : Nov  8 00:26:12 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1940 
207.174.189.161:80 out via ep1
 : Nov  8 00:26:12 grendel /kernel: ipfw: 1000 Deny TCP 213.64.x.x:1938 
207.174.189.161:80 out via ep1
 : [...]
 : And my rules look like this:
 : 
 : add 0200 reset log tcp from any to any 113
 : add 0300 check-state
 : add 0305 deny tcp from any to any in established
 : add 0310 allow tcp from any to any out setup keep-state
 : [...]
 : add 0350 allow tcp from me to 10.0.0.6 80 setup keep-state
 
 Doesn't rule 0310 make rule 0350 redundant?

Ah, sure it is redundant! Thanx for pointing it out :)

 
 : add 1000 deny log logamount 1000 ip from any to any via ep1

Cheers,
Micke

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message