Re: rc.local equivalent
Doug Barton wrote: Morgan Reed wrote: Given that rc.local is now deprecated, Where did you get that idea? man rc.local on a freebsd 7 box says The rc utility is the command script which controls the automatic boot process after being called by init(8). The rc.local script contains com- mands which are pertinent only to a specific site. Typically, the /usr/local/etc/rc.d/ mechanism is used instead of rc.local these days but if you want to use rc.local, it is still supported. In this case, it should source /etc/rc.conf and contain additional custom startup code for your system. The best way to handle rc.local, however, is to separate it out into rc.d/ style scripts and place them under /usr/local/etc/rc.d/. The rc.conf file contains the global system configuration information referenced by the startup scripts, while rc.conf.local contains the local system configuration. See rc.conf(5) for more information. The rc.d/ directories contain scripts which will be automatically exe- cuted at boot time and shutdown time. So, rc.local, though not current is still supported. Brian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfilter 4.13 - http traffic going thru ftp proxy
On Wed, 11 Jul 2007 09:42:22 -0400, Stephen Clark wrote viper wrote: On Tue, 10 Jul 2007 15:59:46 -0400, Stephen Clark wrote Hello List, I posted a while ago that our testers of our network appliance were complaining that browsing was slower when using our appliance based on 6.x as compared to our appliance using 4.9 FreeBSD. Well it turns out they were right! After spending much time trying to figure out what was going on we discovered that all http traffic was being routed thru the ipf ftp proxy module. Does anyone know why this is happening? Here is 4.9 H101491# ipnat -l List of active MAP/Redirect filters: map rl1 from 192.168.1.0/24 to any - 10.0.133.44/32 proxy port ftp ftp/tcp map rl1 from 192.168.1.0/24 to any - 10.0.133.44/32 portmap tcp/udp 4:6 map rl1 from 192.168.1.0/24 to any - 10.0.133.44/32 List of active sessions: MAP 192.168.1.9 2949 - - 10.0.133.44 40075 [64.154.83.47 80] MAP 192.168.1.9 2948 - - 10.0.133.44 40074 [209.67.78.5 80] MAP 192.168.1.9 2947 - - 10.0.133.44 40073 [216.168.252.103 443] MAP 192.168.1.9 2946 - - 10.0.133.44 40072 [65.243.74.133 80] MAP 192.168.1.9 2945 - - 10.0.133.44 40071 [216.168.252.103 443] MAP 192.168.1.9 2944 - - 10.0.133.44 40070 [66.155.171.116 80] MAP 192.168.1.9 2943 - - 10.0.133.44 40069 [64.9.212.6 80] MAP 192.168.1.9 2942 - - 10.0.133.44 40068 [209.104.135.123 80] MAP 192.168.1.9 2941 - - 10.0.133.44 40067 [65.243.74.133 80] MAP 192.168.1.9 2940 - - 10.0.133.44 40066 [65.243.74.133 80] MAP 192.168.1.9 2939 - - 10.0.133.44 40065 [65.243.74.133 80] MAP 192.168.1.9 2938 - - 10.0.133.44 40064 [216.239.51.95 80] MAP 192.168.1.9 2924 - - 10.0.133.44 40050 [64.233.169.99 80] MAP 192.168.1.9 2922 - - 10.0.133.44 40048 [64.233.169.99 80] MAP 192.168.1.9 2920 - - 10.0.133.44 40046 [64.233.169.147 80] MAP 192.168.1.9 1031 - - 10.0.133.44 40045 [198.6.1.2 53] MAP 192.168.1.9 2884 - - 10.0.133.44 40012 [207.159.120.157 80] Here is 6.2 Notice in the mappings for port 80 the source port is not being mapped into the 4:6 range. Also notice that the ftp proxy thought it found something and dumps out some diags. H101490# ipnat -l List of active MAP/Redirect filters: map rl1 from 192.168.1.0/24 to any - 10.0.133.77/32 proxy port ftp ftp/tcp map rl1 from 192.168.1.0/24 to any - 10.0.133.77/32 portmap tcp/udp 4:6 map rl1 from 192.168.1.0/24 to any - 10.0.133.77/32 List of active sessions: MAP 192.168.1.881397 - - 10.0.133.77 1397 [64.154.83.47 80] MAP 192.168.1.881396 - - 10.0.133.77 1396 [209.67.78.5 80] MAP 192.168.1.881395 - - 10.0.133.77 1395 [216.168.252.103 443] MAP 192.168.1.881394 - - 10.0.133.77 1394 [216.168.252.103 443] MAP 192.168.1.881393 - - 10.0.133.77 1393 [65.243.74.144 80] MAP 192.168.1.881392 - - 10.0.133.77 1392 [65.243.74.144 80] MAP 192.168.1.88 1378 - - 10.0.133.77 1378 [64.233.169.103 80]proxy ftp/6 use -54 flags 0proto 6 flags 0 bytes 0 pkts 0 data YES size 312FTP Proxy:passok: 1Client: seq 0 (ack 0) len 0 junk 0 cmds 0 buf [\000] Server: seq 2b451493 (ack 0) len 0 junk 0 cmds 0 buf [\000] MAP 192.168.1.881391 - - 10.0.133.77 1391 [65.205.8.52 80] MAP 192.168.1.881390 - - 10.0.133.77 1390 [65.203.229.71 80] MAP 192.168.1.881389 - - 10.0.133.77 1389 [72.247.8.26 80] MAP 192.168.1.881388 - - 10.0.133.77 1388 [216.239.51.93 80] MAP 192.168.1.881033 - - 10.0.133.77 4 [198.6.1.2 53] -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) Use map rl1 from 192.168.1.0/24 to any port=21 - 10.0.133.77/32 proxy port 21 ftp/tcp It`s feature. ___ Best regards, VipeR Use map rl1 from 192.168.1.0/24 to any port=21 - 10.0.133.77/32 proxy port 21 ftp/tcp you know this works but if I use the same line but use proxy port ftp instead of proxy port 21 I get: map rl1 from 192.168.1.0/24 to any port = 5376 - 10.0.133.77/32 proxy port 5376 ftp/tcp Go figure. Again, this is known feature. The truth is similar to the bug.
Re: Problem with KDM not passing to Xorg/KDE after login
Michael Nottebrock wrote: On Monday, 9. July 2007, Kim Attree wrote: I made Root's $HOME point to /var/db (touched to make sure it's writable on the diskless workstation - it is) and the KDM still refuses to pass to Xorg/KDE. Any Other Ideas ??? Make sure you have a hostname set (in rc.conf or via dhcp) and localhost is resolvable. Mike, I've checked rc.conf and the hostname is defined and a 'hostname' command on the workstation confirms this. I've added a /etc/hosts file on the workstation (through the /conf/default directory on diskless server) with the following: 127.0.0.1 localhost 196.31.157.162 diskless02.csc.jnb6.za.uu.net (server) 196.31.157.130 csc01.csc.jnb6.za.uu.net (workstation) confirmed that localhost resolves to 127.0.0.1 on the workstation. KDM still refuses to pass to Xorg. Kim Attree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: Getting this Fatal Trap with heavy network activity
#16 0xc0539c1c in ithread_execute_handlers () #17 0xc0539d66 in ithread_loop () #18 0xc053878f in fork_exit () #19 0xc06ec18c in fork_trampoline () XL I think this was a fatal trap 12 and you may want to try if updating to XL 6.2-STABLE helps. There was some important related fixes in RELENG_6 XL but not yet merged to RELENG_6_2 (by jhb@). I've just updated my system to 6.2-STABLE #4. Hope this helps. -- [ /Iexa ] mailto:[EMAIL PROTECTED] pgplcHwmcULzi.pgp Description: PGP signature
Seems like pf skips some packets.
Hi
On my machine with FreeBSD 6.2-STABLE #4 I noticed there are
outgoing packets from net 192.168.0.0/16 on external interface
Some details:
Here 1 a,b,c,d,e,f 254
~ ifconfig internal
internal: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=4bRXCSUM,TXCSUM,VLAN_MTU,POLLING
inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255
ether 00:04:23:b0:53:ca
media: Ethernet autoselect (1000baseTX full-duplex)
status: active
~ ifconfig external
external: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=48VLAN_MTU,POLLING
inet a.b.c.22 netmask 0xfffc broadcast a.b.c.23
ether 00:02:b3:4c:83:6e
media: Ethernet autoselect (100baseTX full-duplex)
status: active
~ grep -v '^#' /etc/pf.conf | grep mynet
table mynet { 192.168.0.0/16, 172.16.0.0/16 }
~ sudo pfctl -s a | less
No ALTQ support in kernel
ALTQ related functions disabled
TRANSLATION RULES:
nat on external inet from mynet to ! mynet - a.b.d.240/28 bitmask
rdr on external inet proto tcp from any to a.b.e.1 port = ftp - 192.168.0.2
port 21
rdr on external inet proto udp from any to a.b.e.1 port = 4127 - 192.168.0.2
port 4127
rdr on external inet proto tcp from any to a.b.e.1 port = 4899 - 192.168.0.2
port 4899
rdr on external inet proto tcp from any to a.b.c.22 port = 4022 - 172.16.56.57
port 22
FILTER RULES:
pass in all
pass out all
pass out quick on external inet from a.b.c.20/30 to any
pass out quick on external inet from a.b.d.224/27 to any
pass out quick on external inet from a.b.e.0/24 to any
block drop out on external all
STATES:
#a lot of states
INFO:
Status: Enabled for 0 days 11:06:40 Debug: Urgent
Hostid: 0x2055eb8b
State Table Total Rate
current entries 4182
searches 250779576 6269.5/s
inserts 1877065 46.9/s
removals 1872883 46.8/s
Counters
match 165990128 4149.8/s
bad-offset 00.0/s
fragment 150.0/s
short 20.0/s
normalize 00.0/s
memory 00.0/s
bad-timestamp 00.0/s
congestion 00.0/s
ip-option 45500.1/s
proto-cksum00.0/s
state-mismatch 62330.2/s
state-insert 00.0/s
state-limit00.0/s
src-limit 00.0/s
synproxy 00.0/s
TIMEOUTS:
tcp.first30s
tcp.opening 5s
tcp.established 18000s
tcp.closing 60s
tcp.finwait 30s
tcp.closed 30s
tcp.tsdiff 10s
udp.first60s
udp.single 30s
udp.multiple 60s
icmp.first 20s
icmp.error 10s
other.first 60s
other.single 30s
other.multiple 60s
frag 5s
interval 2s
adaptive.start0 states
adaptive.end 0 states
src.track 0s
LIMITS:
states hard limit 5
src-nodes hard limit 3
frags hard limit 5
TABLES:
mynet
OS FINGERPRINTS:
348 fingerprints loaded
Here I try to catch packets on external interface:
~ sudo tcpdump -ni external src net 192.168.0.0/16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on external, link-type EN10MB (Ethernet), capture size 96 bytes
12:59:44.401906 IP 192.168.56.152.1090 64.12.31.180.5190: . ack 1528988903
win 0
12:59:44.401921 IP 192.168.12.43.60481 81.19.88.11.80: . ack 2815867423 win 0
12:59:44.401933 IP 192.168.46.101.1650 81.176.76.116.80: . ack 669974985 win 0
12:59:44.401946 IP 192.168.54.12.2124 194.145.212.35.80: . ack 2208596276 win 0
12:59:44.401958 IP 192.168.22.10.1510 194.67.45.129.80: . ack 1166126606 win 0
12:59:44.401971 IP 192.168.46.101.1652 81.19.80.2.80: . ack 1004425830 win 0
12:59:44.401983 IP 192.168.38.79.63441 66.102.11.164.80: . ack 1120457487 win 0
12:59:44.401995 IP 192.168.54.71.1578 87.248.217.79.80: . ack 2473371997 win 0
12:59:44.402022 IP 192.168.38.49.4183 65.54.195.188.80: . ack 964472648 win 0
12:59:44.402041 IP 192.168.42.90.60363 66.249.93.91.80: . ack 2862783680 win 0
12:59:44.402055 IP 192.168.46.46.58867 89.188.102.70.80: . ack 2523375288 win 0
12:59:44.402075 IP 192.168.38.16.1222 208.166.56.114.80: . ack 0
Re: Getting this Fatal Trap with heavy network activity
Alexey Sopov wrote: #16 0xc0539c1c in ithread_execute_handlers () #17 0xc0539d66 in ithread_loop () #18 0xc053878f in fork_exit () #19 0xc06ec18c in fork_trampoline () XL I think this was a fatal trap 12 and you may want to try if updating to XL 6.2-STABLE helps. There was some important related fixes in RELENG_6 XL but not yet merged to RELENG_6_2 (by jhb@). I've just updated my system to 6.2-STABLE #4. Hope this helps. Ok, be sure to report any problem so we can investigate further. Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
pmtud + ipnat RELENG_6_2 appears to be broken
Hi List, When using ipnat, part of ipfilter 4.1.13, I don't see any icmp packets being returned saying: Host Unreachable, frag needed and DF set. type 3, code 4 It does work if I am not using ipnat. Any ideas? Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.local equivalent
On 7/12/07, Brian [EMAIL PROTECTED] wrote: man rc.local on a freebsd 7 box says Same for 6.2-STABLE. So, rc.local, though not current is still supported. Yes, effectively deprecated (although the mechanism may not be removed for a significant time, if at all). I'm going to write an rc.d script to do the loading and saving of configs for my system. Thanks for your assistance. Morgan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Seems like pf skips some packets.
On 7/12/07, Alexey Sopov [EMAIL PROTECTED] wrote:
Hi
On my machine with FreeBSD 6.2-STABLE #4 I noticed there are
outgoing packets from net 192.168.0.0/16 on external interface
Some details:
Here 1 a,b,c,d,e,f 254
~ ifconfig internal
internal: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=4bRXCSUM,TXCSUM,VLAN_MTU,POLLING
inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255
ether 00:04:23:b0:53:ca
media: Ethernet autoselect (1000baseTX full-duplex)
status: active
~ ifconfig external
external: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=48VLAN_MTU,POLLING
inet a.b.c.22 netmask 0xfffc broadcast a.b.c.23
ether 00:02:b3:4c:83:6e
media: Ethernet autoselect (100baseTX full-duplex)
status: active
~ grep -v '^#' /etc/pf.conf | grep mynet
table mynet { 192.168.0.0/16, 172.16.0.0/16 }
~ sudo pfctl -s a | less
No ALTQ support in kernel
ALTQ related functions disabled
TRANSLATION RULES:
nat on external inet from mynet to ! mynet - a.b.d.240/28 bitmask
rdr on external inet proto tcp from any to a.b.e.1 port = ftp - 192.168.0.2
port 21
rdr on external inet proto udp from any to a.b.e.1 port = 4127 - 192.168.0.2
port 4127
rdr on external inet proto tcp from any to a.b.e.1 port = 4899 - 192.168.0.2
port 4899
rdr on external inet proto tcp from any to a.b.c.22 port = 4022 - 172.16.56.57
port 22
FILTER RULES:
pass in all
pass out all
pass out quick on external inet from a.b.c.20/30 to any
pass out quick on external inet from a.b.d.224/27 to any
pass out quick on external inet from a.b.e.0/24 to any
block drop out on external all
STATES:
#a lot of states
INFO:
Status: Enabled for 0 days 11:06:40 Debug: Urgent
Hostid: 0x2055eb8b
State Table Total Rate
current entries 4182
searches 250779576 6269.5/s
inserts 1877065 46.9/s
removals 1872883 46.8/s
Counters
match 165990128 4149.8/s
bad-offset 00.0/s
fragment 150.0/s
short 20.0/s
normalize 00.0/s
memory 00.0/s
bad-timestamp 00.0/s
congestion 00.0/s
ip-option 45500.1/s
proto-cksum00.0/s
state-mismatch 62330.2/s
state-insert 00.0/s
state-limit00.0/s
src-limit 00.0/s
synproxy 00.0/s
TIMEOUTS:
tcp.first30s
tcp.opening 5s
tcp.established 18000s
tcp.closing 60s
tcp.finwait 30s
tcp.closed 30s
tcp.tsdiff 10s
udp.first60s
udp.single 30s
udp.multiple 60s
icmp.first 20s
icmp.error 10s
other.first 60s
other.single 30s
other.multiple 60s
frag 5s
interval 2s
adaptive.start0 states
adaptive.end 0 states
src.track 0s
LIMITS:
states hard limit 5
src-nodes hard limit 3
frags hard limit 5
TABLES:
mynet
OS FINGERPRINTS:
348 fingerprints loaded
Here I try to catch packets on external interface:
~ sudo tcpdump -ni external src net 192.168.0.0/16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on external, link-type EN10MB (Ethernet), capture size 96 bytes
12:59:44.401906 IP 192.168.56.152.1090 64.12.31.180.5190: . ack 1528988903
win 0
12:59:44.401921 IP 192.168.12.43.60481 81.19.88.11.80: . ack 2815867423 win 0
12:59:44.401933 IP 192.168.46.101.1650 81.176.76.116.80: . ack 669974985 win 0
12:59:44.401946 IP 192.168.54.12.2124 194.145.212.35.80: . ack 2208596276 win 0
12:59:44.401958 IP 192.168.22.10.1510 194.67.45.129.80: . ack 1166126606 win 0
12:59:44.401971 IP 192.168.46.101.1652 81.19.80.2.80: . ack 1004425830 win 0
12:59:44.401983 IP 192.168.38.79.63441 66.102.11.164.80: . ack 1120457487 win 0
12:59:44.401995 IP 192.168.54.71.1578 87.248.217.79.80: . ack 2473371997 win 0
12:59:44.402022 IP 192.168.38.49.4183 65.54.195.188.80: . ack 964472648 win 0
12:59:44.402041 IP 192.168.42.90.60363 66.249.93.91.80: . ack 2862783680 win 0
12:59:44.402055 IP 192.168.46.46.58867 89.188.102.70.80: . ack 2523375288 win 0
12:59:44.402075 IP
Best release or snapshot to install?
We have a FreeBSD 6.0 server that needs upgrading. This is a production server, and it needs to be stable. There is no posted date for 6.3-RELEASE, so we're looking for a good snapshot to install -- preferably a known good build from 6-STABLE or a build of the security branch of the tree. This would be for a 386-architecture machine. Recommendations? Also, when is 6.3-RELEASE (which will hopefully incorporate a bunch of MFCed improvements from CURRENT) likely to happen? --Brett Glass ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
Stephen Clark wrote: Hi List, When using ipnat, part of ipfilter 4.1.13, I don't see any icmp packets being returned saying: Host Unreachable, frag needed and DF set. type 3, code 4 It does work if I am not using ipnat. Any ideas? Thanks, Steve Sorry for the noise - this seems to be OK. But the problem I am seeing relates to: Did something change in 6.2? If my mtu size on rl0 is 1280 it won't accept a larger incoming packet. kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 max 1294) I don't think it worked this way in the past. Won't this affect pmtud? man page for ifconfig says mtu limits size of transmission not reception. mtu n Set the maximum transmission unit of the interface to n, default is interface specific. -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
On Jul 12, 2007, at 12:34 PM, Stephen Clark wrote: Did something change in 6.2? If my mtu size on rl0 is 1280 it won't accept a larger incoming packet. Nothing changed; that is the expected behavior. (Modulo support for 4-byte VLAN tags.) kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 max 1294) I don't think it worked this way in the past. Well, it did. :-) Won't this affect pmtud? Nope. man page for ifconfig says mtu limits size of transmission not reception. mtu n Set the maximum transmission unit of the interface to n, default is interface specific. The MTU is actually defined in reference to a network segment such as an ethernet collision domain, and applies to all machines sending traffic to that segment. If the MTU is really 1280, nobody else should be sending larger packets, and the drivers will drop any larger packets they receive and generate the appropriate ICMP error -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best release or snapshot to install?
At 12:31 PM 7/12/2007, Brett Glass wrote: We have a FreeBSD 6.0 server that needs upgrading. This is a production server, and it needs to be stable. There is no posted date for 6.3-RELEASE, so we're looking for a good snapshot to install -- preferably a known good build from 6-STABLE or a build of the security branch of the tree. I would say from today. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.local equivalent
Morgan Reed wrote: On 7/12/07, Brian [EMAIL PROTECTED] wrote: man rc.local on a freebsd 7 box says Same for 6.2-STABLE. So, rc.local, though not current is still supported. Yes, effectively deprecated No, not deprecated at all. That term has a specific meaning in the FreeBSD community, and your use of it here is very far away from it. There is a big difference between the current status, rc.local is still supported, however you will probably get better results using local rc.d scripts; and This is going away, so stop using it. The latter would be deprecated in FreeBSD terminology, the former is supported in anyone's book. I'm harping on this a bit because I'm tired of hearing people say that rc.local is deprecated. It leads to unnecessary stress on the part of people who are reasonably relying on this mechanism. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
Chuck Swiger wrote: On Jul 12, 2007, at 12:34 PM, Stephen Clark wrote: Did something change in 6.2? If my mtu size on rl0 is 1280 it won't accept a larger incoming packet. Nothing changed; that is the expected behavior. (Modulo support for 4-byte VLAN tags.) kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 max 1294) I don't think it worked this way in the past. Well, it did. :-) Won't this affect pmtud? Nope. man page for ifconfig says mtu limits size of transmission not reception. mtu n Set the maximum transmission unit of the interface to n, default is interface specific. The MTU is actually defined in reference to a network segment such as an ethernet collision domain, and applies to all machines sending traffic to that segment. If the MTU is really 1280, nobody else should be sending larger packets, and the drivers will drop any larger packets they receive and generate the appropriate ICMP error Hi Chuck, First thanks for responding but thats the problem, this did't generate an icmp when the packet was dropped. kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 max 1294) This message did not result in any icmp packet. I was running tcpdump looking for them. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
On Jul 12, 2007, at 1:38 PM, Stephen Clark wrote: The MTU is actually defined in reference to a network segment such as an ethernet collision domain, and applies to all machines sending traffic to that segment. If the MTU is really 1280, nobody else should be sending larger packets, and the drivers will drop any larger packets they receive and generate the appropriate ICMP error First thanks for responding but thats the problem, this did't generate an icmp when the packet was dropped. kernel: rl0: discard oversize frame (ether type 800 flags 3 len 1514 max 1294) This message did not result in any icmp packet. I was running tcpdump looking for them. Taking a quick look at ether_input() in src/sys/net/if_ethersubr.c suggests that you are right-- if the incoming packet exceeds the MTU being set, the input errors count for that interface is incremented, but no ICMP_UNREACH_NEEDFRAG is generated even if DF flag is set. You might file a PR and see whether you can get Andre or one of the other networking gurus interested in fixing this. Or maybe I'll give it a try myself if I can get some free time :-) -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HP Desktjet D1420 detected by Freebsd, but not CUPS
Hullo, I have a brand-new Hp Deskjet d1420 which is perfectly detected by FreeBSD: ~ % usbdevs addr 1: UHCI root hub, VIA addr 2: Deskjet D1400 series, HP addr 1: UHCI root hub, VIA addr 1: UHCI root hub, VIA addr 1: EHCI root hub, VIA -- and -- ~ % dmesg | grep ugen0 ugen0: HP Deskjet D1400 series, rev 2.00/1.00, addr 2 I installed print/hplip and print/cups I followed the directions at http://am-productions.biz/docs/hplip.php exactly, but when I try to run hp-setup, I get this: error: No devices found.Please make sure your printer is properly connected and powered-on So, I tried using CUPS own web-interface, no luck, it doesn't even list USB as an option, KDE's kprinter interface does, but it's greyed out. I tried the find manually function in hp-setup, but was instructed to use the command lsusb, which doesn't seem to exist; I suspect lsusb is a Linux specific command, and, indeed, the portions of HPLIP's web-site dealing with this aspect make clear references to Linux's method of handling USB device notes. I am at my wits end. I have tried everything I could think of, to no avail. Thanks in advance. --John. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best release or snapshot to install?
On 7/12/07, Brett Glass [EMAIL PROTECTED] wrote: We have a FreeBSD 6.0 server that needs upgrading. This is a production server, and it needs to be stable. There is no posted date for 6.3-RELEASE, so we're looking for a good snapshot to install -- preferably a known good build from 6-STABLE or a build of the security branch of the tree. This would be for a 386-architecture machine. Recommendations? Also, when is 6.3-RELEASE (which will hopefully incorporate a bunch of MFCed improvements from CURRENT) likely to happen? 6.2-RELEASE is the latest stable branch. you should be able to upgrade your world to this release with little problems. going from 6.2-RELEASE to 6.3-RELEASE should be trivial, and any gotcha's should be documented in /usr/src/UPDATE. the latest patch level of 6.2-RELEASE should include all security updates, and bug fixes (as should 6.0-RELEASE/6.1-RELEASE/etc. i do not think snapshot's have gone through the same amount of regression testing as official releases, so you may not want to use those in production environments. -p -- ~~o0OO0o~~ Pete Wright www.nycbug.org NYC's *BSD User Group ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.local equivalent
On Thu, Jul 12, 2007 at 01:47:53PM -0700, Doug Barton wrote: There is a big difference between the current status, rc.local is still supported, however you will probably get better results using local rc.d scripts; and This is going away, so stop using it. The text from rc(8): The rc.local script contains commands which are pertinent only to a specific site. Typically, the /usr/local/etc/rc.d/ mechanism is used instead of rc.local these days but if you want to use rc.local, it is still supported. I had earlier read that as don't use this. I would prefer we change it to your text, which is clearer. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rc.local equivalent
Mark Linimon wrote: On Thu, Jul 12, 2007 at 01:47:53PM -0700, Doug Barton wrote: There is a big difference between the current status, rc.local is still supported, however you will probably get better results using local rc.d scripts; and This is going away, so stop using it. The text from rc(8): The rc.local script contains commands which are pertinent only to a specific site. Typically, the /usr/local/etc/rc.d/ mechanism is used instead of rc.local these days but if you want to use rc.local, it is still supported. I had earlier read that as don't use this. I would prefer we change it to your text, which is clearer. I had sort of thought adding this to my TODO list was a good idea, but now I will definitely do so. Thanks, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HOW TO: Enabling root on a new server?
Hi All, I recently purchased a co-located server from Cedant and need to enable the root user. It's running FreeBSD 6.1. Currently there appears to be no root user enabled on the server. I can't even su to root. I've tried using pw to add my user to wheel but I receive a warning informing me that I must be root to even do such a thing. You can see my quandary. Please advise. Regards, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HOW TO: Enabling root on a new server?
On Thu, Jul 12, 2007 at 11:06:07PM -0400, Michael Williams wrote: I recently purchased a co-located server from Cedant and need to enable the root user. It's running FreeBSD 6.1. Currently there appears to be no root user enabled on the server. I can't even su to root. I've tried using pw to add my user to wheel but I receive a warning informing me that I must be root to even do such a thing. You can see my quandary. Please advise. FreeBSD, out-of-the-box, definitely includes user root, and there is no password (unless during the installation you choose to set one). This sounds like a question you should be talking to Cedant/your provider about. What you purchased may not be a real co-located box that's personally dedicated to you -- it may be something shared with other people, and something that Cedant maintains. This is purely speculative on my part, because I know nothing about their services. But this really does sound like something specific to their servers. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
