Re: ip_input - chksum - why is it done so early in ip_input?
On Sat, Jan 17, 2004 at 12:50:04AM +0100, Sten Daniel S?rsdal wrote: > > Apologies for the cross-post, i wasnt sure if this was hackers or net material. > > I've often wondered why ip checksumming is done on every incoming > packet and not only on the packets that need to be delivered locally. > It looks like a very expensive way of doing it, especially on high > PPS. Basically all hosts do checksumming so why not just pass the bad > packet on, making the forward process alot cheaper (cpu wise)? It is done this way because the standards demand that it be done this way. RFC1812 says, 4.2.2.5 Header Checksum: RFC 791 Section 3.1 As stated in Section [5.2.2], a router MUST verify the IP checksum of any packet that is received, and MUST discard messages containing invalid checksums. The router MUST NOT provide a means to disable this checksum verification. Keeping a single host from polluting the whole network, and only its LAN, with bad packets is considered worth the cost of every router doing the check. FWIW, this is one of the few places a standard demands that you not even provide the option to disable a feature. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Routing Networks
On Wed, Jan 14, 2004 at 08:43:37AM +0100, Isaac Gelado wrote: > Nicol?s de Bari Embr?z G. R. escribi?: > >Hi all, I need some help routing or making Nat on a LAN. > > > >I have something like this: > > > > > > I N T E R N E T > > - > >^ ^ > >| | > >fxp0 public IP public IP > >| | > > FreeBSD server LINUX server > >| | > >dc0 192.168.10.1| > >dc1 192.168.1.1 ^ 192.168.1.3 > >^ | ^ > >| | | > >| | | > > > > | Switch/Hub | > > > > | | > >-- - > > | LAN A | | LAN B | > > | 192.168.10.2-254 | | 192.168.1.4-100 | > >-- - > > > > > >What i want to do is that a computer on LAN A with an IP on the range of > >192.168.10.2-254 can ping, telnet, ssh, etc. to a computer on LAN B > >"192.168.1.X". > > > >How can i solve this problem, is this is a route or Nat problem ? > > I think it is a route problem. You must add next static route: > > - On the linux machine route all incoming packets with dest addr > 192.168.10.x to 192.168.1.1 > > It shouldn't be necesary a static route on the freebsd machine since it > has a network device with an addr of LAN B. This is correct. Things can get from LAN A to LAN B just fine in this picture. The problem is that machines on LAN B won't be able to get back to LAN A (i.e. your pings go from A to B, but the pongs never get back from B to A). You'll have to touch that Linux box or touch the routes on everything on LAN B to route 192.168.10.0/24 through 192.168.1.1. > Of course you must run a > route daemon in both machines (I supouse it's running now since they are > working as gateways) and the previous route must be added to the route > daemon running on the linux machine. OK now here is the problem. Why does he need a routing daemon? I saw no mention of RIP, OSPF, or any other dynamic routing protocol. Looks like it's all static routes to me. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Measuring Time on Serial Port Events
I'm doing some work involving measuring latencies of communications over serial ports. To avoid clock synchronizations issues if we were running on separate machines, a configuration is a modem hooked into /dev/cuaa0 and another in /dev/cuaa1. We talk to the modem on cuaa0 which calls the modem on cuaa1, we tell it to answer, and then we throw data back and forth and take timestamps. Right now, all of the code is running in userland. I am trying to figure out what tuning we could do to get things as accurate as possible. That is, the information we want is the time that a bunch of bits to leave the COM port versus when they arrive on the other one. Since things look more like, Userland|OS | Comms Hardware | ||| [measuring]<->|<-[ sio ]->|< UART >|<---> [ program ] | [driver] || And this doesn't account for delays between when we get the data in userland and then have to make gettimeofday() calls for timestamps and other potential delays. I'm concerned how far off our measurements in userland will be from when bits actually arrive and leave on the wire. The data we are concerned with has latencies of a few 100 ms, but calibrations on the PSTN are a typically 50-ms-ish. We need to have a few significant digits below that. Any pointers? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ether_input: drop bdg packet
On Wed, Mar 19, 2003 at 10:24:45AM -0500, Steve Bertrand wrote: [snip] > Thank you very much. Just out of curiosity, if it was removed, why does > the message still appear? You're using an older kernel/module built from source that had it? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ether_input: drop bdg packet
On Thu, Mar 13, 2003 at 01:13:29PM -0500, IAccounts wrote: > I have 5.0 running as a bridge/ipfw firewall configuration, which is > seemingly working very well in an ISP environment. However, there is > something that I don't know if it is an error, or normal. On the console, > I get the following message many times per second: > > ether_input: drop bdg packet > > I am suspecting that this is just a logging issue within part of the > bridge/ipfw code, but I would like some feeback if possible to what > exactly this is for. > > I have looked through bridge.c, ipfw.c, bpf.c, bpf_filter.c and many > others for the answer. There is much reference to DROP in bridge.c, but > nothing that looks like the console message. I would really like to find > out why this is happening, and how to make some changes, so I would > appreciate it if someone could point me in the direction of the code for > this as opposed to or in addition to the answer. The message is in src/sys/net/if_ethersubr.c. However, it was removed in revision 1.34 which is probably why you cannot find it. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP resolving
On Mon, Oct 21, 2002 at 12:19:03AM -0600, Scott Carmichael wrote: > Netstat reports properly... > > I think the issue is that an 'nslookup [ip]' will resolve to a host where > an 'nslookup [host]' will not resolve to [ip]. Its the way the DNS on the > other end is set up, but I can't exactly change that... I'd just like a > 'w' to be able to report properly (ie. if [host] doesn't resolve to [ip], > then just report [ip] with a 'w').. or something. =\ You never said if you are using TCP wrappers. Can you show us the actual output from the machine? What do, $ w $ w -n $ who $ last | head $ netstat -an Show? Do you get identical results with rlogin and ssh? Can we see both? > On Fri, 18 Oct 2002, Crist J. Clark wrote: > > > On Sun, Oct 13, 2002 at 11:00:26PM -0600, Scott Carmichael wrote: > > > Can someone help me here? Is there a code change I can make somewhere? > > > > > > Please CC me on any replies, as I am not subscribed to -net or -hackers. > > > > -net removed. -hackers left (although this might be more of a > > -questions thread). > > > > > -- Forwarded message -- > > > Date: Fri, 11 Oct 2002 14:14:08 -0600 (MDT) > > > From: Scott Carmichael <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > > > Subject: IP resolving > > > > > > I would like to know two things... Why FreeBSD acts in the following way > > > while OpenBSD does not, and if it's possible to fix this? > > > > > > It seems that if anyone connects to my FreeBSD server wish a hostname that > > > does not match their IP, > > > > "Hostname does not match their IP?" What exactly does that mean? All > > the OS knows is the remote IP address. It doesn't know what hostname > > the remote claims to have. The application server might receive a > > hostname though, but then I would expect the behavior to vary > > according to the application used to connect. > > > > > I get a console message about the mismatch, and > > > > Something is generating a message to syslogd(8). Figure out what it is > > and edit syslog.conf(5) appropriately. Are you using TCP wrappers or > > something? > > > > > then if they connect via rlogin or ssh, 'who', 'w', 'last', etc. all > > > report that they are connected _from_ MY box, which they aren't. > > > > Strange. What does 'netstat -a' or 'sockstat' report? 'w' works fine > > for me. > > -- > > Crist J. Clark | [EMAIL PROTECTED] > >| [EMAIL PROTECTED] > > http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] > > -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IP resolving
On Sun, Oct 13, 2002 at 11:00:26PM -0600, Scott Carmichael wrote: > Can someone help me here? Is there a code change I can make somewhere? > > Please CC me on any replies, as I am not subscribed to -net or -hackers. -net removed. -hackers left (although this might be more of a -questions thread). > -- Forwarded message -- > Date: Fri, 11 Oct 2002 14:14:08 -0600 (MDT) > From: Scott Carmichael <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: IP resolving > > I would like to know two things... Why FreeBSD acts in the following way > while OpenBSD does not, and if it's possible to fix this? > > It seems that if anyone connects to my FreeBSD server wish a hostname that > does not match their IP, "Hostname does not match their IP?" What exactly does that mean? All the OS knows is the remote IP address. It doesn't know what hostname the remote claims to have. The application server might receive a hostname though, but then I would expect the behavior to vary according to the application used to connect. > I get a console message about the mismatch, and Something is generating a message to syslogd(8). Figure out what it is and edit syslog.conf(5) appropriately. Are you using TCP wrappers or something? > then if they connect via rlogin or ssh, 'who', 'w', 'last', etc. all > report that they are connected _from_ MY box, which they aren't. Strange. What does 'netstat -a' or 'sockstat' report? 'w' works fine for me. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inet_aton() Bug or feature?
On Thu, Oct 03, 2002 at 04:00:26PM +0300, Artem Okounev wrote: > To my great surprise I found out that: > ping 192.168.0.26, > ping 192.168.0.032, > and even ping 192.168.0.0x1a - all correct commands doing > the same thing: pinging 192.168.0.26. Yep. > That was my problem. IP addresses was stored in text file in > the form of 192.168.000.032, and after issuing command: arp > - -s 192.168.000.032 xx:xx:xx:xx:xx:xx (which actually was > treated as arp -s 192.168.0.26) I had a great headache. That should be pretty easy to fix in your script. > After some investigation I found that both ping and arp use > inet_aton() libc call to interpret their command arguments > intonetworkformat.Futher,inet_aton()uses > strtoul(c,&endptr, 0) for each octet in IP address to > convert string representation of number to unsigned long. > > Why not to use strtoul(x, x, 10) and fix aforementioned > confusing thing with arp/ping/...? Does anybody write > command arguments to ping using octal or hex format :)? > > I am not hacker. Just curious. This is a feature not a bug since it is documented in inet_aton(3), All numbers supplied as ``parts'' in a `.' notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other- wise, the number is interpreted as decimal). People use this notation all of the time, # ifconfig if0 172.16.1.10 netmask 0xff00 ^^ -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Desired feature: ipfw pass for routed IPs
On Thu, Sep 19, 2002 at 11:07:07AM +0300, Adrian Penisoara wrote: > 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 ? On input packets, it'd be painful and not really practical. On output packets, it shouldn't be _too_ bad since the routing information would be available. I'm not quite sure I understand why it would be needed. If there isn't a route to send a packet out of an interface, it won't go out of the interface. Under what conditions would you see yourself blocking packets? Is this really an ackbassward way to filter routes from routing daemons? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.6-* sendmail misfeatures
On Mon, May 20, 2002 at 12:25:58PM -0500, Damon Anton Permezel wrote: > It is not a matter of a timeout. Correct. The NS is actually reporting a transient error in response to queries. > The "A ?" come back fine. > `dig' and 'nslookup' both resolve the name -- there is no timeout. > `ping' works, for example. > > Because sendmail "correctly" (aka: anal-retentively) adheres to a > protocol, it flags this as an error, Not sure what's so anal-retentive. The NS tells sendmail(8) there is an error and sendmail(8) believes it. > and doesn't attempt to try the > "A ?" query. This means that the outgoing mail sits in the queue forever. > > This is not a particularly useful default behavior. > > I have no control over austinenergy.com's DNS. It has nothing to do > with my ISP. I am my own ISP, which is why I spent some time looking > into this failure, to determine if it was a problem on my end. It is, > because I installed a broken sendmail. > > The success of the internet has often been attributed in part to the > philosophy stated in RFC 791. I quote: > > "The implementation of a protocol must be robust. Each >implementation must expect to interoperate with others created >by different individuals. >In general, an implementation must be conservative in its sending >behavior, and liberal in its receiving behavior." Too bad the people who wrote these broken DNS servers didn't follow the rule. > Burying a "we are correct" manifesto in some README and enforcing > a default "correct" behavior results in breaking email connectivity. > > It would be better to, perhaps, default to working, which I would > prefer over it being silently, secretly and smugly "correct". > If there really is a need to convert the world, syslog warning > entries might be a less unfriendly way to alert the unwashed masses > of the egregious violations of "correctness". The issue is that the server is reporting a _transient_ failure. That is, it's telling us that if we wait and try again later, we might get a correct response. How do we know if it is a permanently broken server or one that really is having a transient problem that will be fixed soon? See 5.2.3 of RFC 1034. Funny thing is that austinenergy.com seems to have one NS that deals with queries in an OK-way and one that doesn't. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hardlinks...
On Thu, Apr 18, 2002 at 11:18:30AM -0400, Michael Sinz wrote: > "Crist J. Clark" wrote: > > > > On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: > > [snip] > > > > > It's arguable that "/" and "/usr" themselves should be > > > mounted read-only, > > > > It's not very practical to have / read-only on a truely multi-user > > (the only time this linking stuff is much of an issue) 4-STABLE > > system. The two main reasons being /etc/master.passwd, et al, and the > > problems with a read-only /dev. It takes extensive customizations and > > kludges to get this to work. > > Actually, with minimal work in the rc.diskless* files, we have a > very workable, large-scale system with / as Read-Only. In fact, > only /dev and /var are read-write (well, in testing we also have > a /sewer for coredumps) /dev and /var are local RAM disks (and /tmp > points are /var/tmp) It may be easier to fit it in with a diskless configuration. One of the problems is that in a "normal" (i.e. not diskless) stuff in /dev is used before you get at chance to mount something over /dev. And that may or may not be a problem. But the diskless stuff is run so early in the boot process, it seems like it should be easier to manage that. > One of these days I will want to write up some of what we did. That would be interesting. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipfw fwd to named
On Mon, Apr 15, 2002 at 07:53:01PM +0300, [EMAIL PROTECTED] wrote:
> Hi.
>
> I have network interface rl0
>
> rl0: flags=8843 mtu 1500
> inet 192.168.10.22 netmask 0xff00 broadcast 192.168.10.255
> inet 192.168.10.26 netmask 0x broadcast 192.168.10.26
> ether 00:60:52:0b:a3:0a
> media: Ethernet autoselect (100baseTX )
> status: active
>
> In named.conf
>
> listen-on port 2053 {
> 192.168.10.26;
> };
>
> Named works fine in JAIL
> dig -p 2053 @192.168.10.26 test.domain
>
> I want to forward all 192.168.10.22:53 queries to the jailed named.
>
> ifpw add 300 fwd 192.168.10.26,2053 udp from any to 192.168.10.22 53
> ifpw add 310 fwd 192.168.10.26,2053 tcp from any to 192.168.10.22 53
>
> When i launch dig without port options to the server 192.168.10.22 it says
> that connection refused.
>
> I did same this sshd (put it in jail and forward its port) and
> it works fine.
>
> What's wrong?
Have you done a tcpdump(1) on the loopback to see what is going on?
# tcpdump -ni lo0
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Is natd the right tool?
On Thu, Apr 11, 2002 at 09:24:24AM -0400, Matt Simerson wrote:
> Natd is a very cool tool for doing stuff like redirecting
> connections from an external network to an internal one but I'm have a
> slightly different problem. I have a single host with one public
> interface:
>
> host - fxp0 = 192.168.7.251
>
> Also on this same host is a bunch more IP's on the loopback interface:
>
> host - lo0 = 127.0.0.1
> 127.0.0.2
> .
>
>
> On each of the loopback addresses I have a DNS server listening. This
> part works just fine:
>
> matt@matt: {101} % dig www.foo.com @127.0.0.2
>
> ;; ANSWER SECTION:
> www.foo.com.1D IN A 207.89.154.94
>
>
> What I want to be able to do is send a dns query to the external
> interface of the machine on a non-standard port and have it redirect
> the query to a loopback address/port and return the query the
> appropriate query result to me.
Why don't you just have each named(8) listen on the different port?
See 'listen-on' in named.conf(5).
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Hardlinks...
On Tue, Apr 09, 2002 at 04:42:52PM -0700, Terry Lambert wrote: > Julian Elischer wrote: > > As terry knows of course, the Interjet > > had the following /etc/symlinks: (excuse linewrap) > > lrwxrwxrwx 1 root wheel 20 Mr 28 2001 crontab@ -> > > /writable/system/crontab > > lrwxrwxrwx 1 root wheel 18 Mr 28 2001 group@ -> > > /writable/system/group > > [ ... ] > > > the single root+usr partition is mounted read-only. > > Yes, but appealing to a product I had something to do with, > even if that organization wasn't mine in particular, makes > a much less powerful argument. > > The other thing that's a bit painful about that argument > is that the symlinks failed to operate as expected for > the master.passwd, if the / was mounted read/write. I > count this as a bug in the password database generation > code, but it should be noted that it can be a problem (e.g > the symlink is renamed to the backup, and the replacement > file is created in /etc; it does the right thing, if the > symlink is read-only, though...). Exactly, you can't use symlinks with the passwd(1) and pwd_mkdb(8) commands as they stand. The commands will bail when they try to create a temporary file in /etc, /etc/pw.XX if /etc is read-only. If /etc is not read-only, the symlinks will get removed and the files actually written in /etc. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hardlinks...
On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: [snip] > It's arguable that "/" and "/usr" themselves should be > mounted read-only, It's not very practical to have / read-only on a truely multi-user (the only time this linking stuff is much of an issue) 4-STABLE system. The two main reasons being /etc/master.passwd, et al, and the problems with a read-only /dev. It takes extensive customizations and kludges to get this to work. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: total module count
On Mon, Apr 01, 2002 at 02:54:05PM -0500, Zhihui Zhang wrote: > > I am wondering how many modules in all are compiled during the kernel > compilation (make depend; make). Is there any configuration file I can > look into to find out all the module names? How about src/sys/modules/Makefile? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Junior Kernel Hacker Project: NOTES
On Fri, Mar 29, 2002 at 04:01:29PM -0500, John Baldwin wrote:
> Currently we only have a NOTES file (which contains many MD options and
> drivers) on i386, so we don't get to do LINT compiles on other arch's very
> easily. A very simple solution that doesn't involve much in the way of config
> magic would be to split NOTES up into two pieces. All of the MI drivers and
> options would live in sys/conf/NOTES. All of the MD drivers and options would
> live in sys//conf/NOTES. Each sys//conf/Makefile would contain a
> LINT target. Building LINT would be similar to the way that is done now,
> except that both sys/conf/NOTES and sys//conf/NOTES would be concatenated
> to form the input for the perl script. Also, the perl script should likely be
> moved to sys/conf so there is only one copy of it.
Actually, with FreeBSD moving to more and more arch's, is there any
interest in rearranging the sys tree into something more like
{Net,Open}BSD with a sys/arch directory? This would be pretty painful
to do and probably take a _lot_ of repo surgery, but it might be
something useful in the long run. And it doesn't hurt to stay closer
to the other BSD's.
(Just askin', not proposin'.)
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Userland Hacker Task: divert socket listener...
On Tue, Mar 12, 2002 at 11:49:53PM +0100, Poul-Henning Kamp wrote: > > Here is something I miss a lot: > > I would like a small program which can listen to a specified divert(4) > socket and act on the incoming packets. > > Specifically I want to direct all unwanted trafic from my ipfw rules > into the divert socket and have the program examine these packets > and when configured thresholds were exceeded take actions like: > > Add a blackhole route for a period of time to the source > IP to prevent any packets getting back to the attacker. > > Add a blocking ipfw rule for incoming trafic from the > attackers IP# for some period of time. > > Add a divert ipfw rule for incoming trafic from the > attackers IP# to capture all the tricks he is trying to > do. > > Log the received packets in detail in pcap format files. > > Report the packets to Dshield.org > > etc. > > Any takers ? I wrote a framework for something like that a few months ago during a fit of boredom. Meet dpcd, the Divert Packet Capture Daemon. I don't even remember if I left the code in a working state. I'm sure I had writing pcap(3) files working at one point. Tarball of what I got attatched. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] dpcd.tgz Description: application/tar-gz
Re: cryptography implications (privacy) of FreeBSD jail ?
On Mon, Mar 11, 2002 at 04:13:16PM -0800, Patrick Thomas wrote: > > Let's say I am running in a jail, and say 5 other people are running in > other, seperate jails on the same machine. > > Now lets say I start up pgp, and generate my keys, and generally use pgp > through the command line in my jail. Or, instead of pgp I do other crypto > related sensitive activities... > > what is my risk here ? Can someone either on the host machine or in one > of the other jails watch memory on the machine and discern things like my > keys or passphrases or have very easy access to the data I am decrypting ? As always, root on the host ownz you. root in your jail probably does too. If the jails are set up "promiscuously," I can think of ways users in other jails could get information, but if they are set up well, I don't see any straightforward attacks. But I haven't done exhaustive research. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bug in Time::Local (can't handle 1901)
On Fri, Mar 08, 2002 at 04:41:15PM +, Michael Stevens wrote: > This is a bug report for perl from [EMAIL PROTECTED], > generated with the help of perlbug 1.26 running under perl 5.00503. > > > - > [Please enter your report here] > > michaels@host:~> perl -MTime::Local -e 'timegm(0,0,0, 01, 01, 1901)' > Can't handle date (0, 0, 0, 1, 1, 1) at -e line 1 > > This seems contrary to the documentation which suggests that this is > a perfectly valid date that will be handled as 1901. It so happens that the 2^31 seconds before the UNIX epcoh falls on Fri Dec 13 20:45:52 UTC 1901. $ date -ju 190112132045.52 Fri Dec 13 20:45:52 UTC 1901 $ date -ju 190112132045.51 date: nonexistent time $ date -ju 190112132045.52 +%s -2147483648 $ dc 2 31^ p 2147483648 mktime(3) will choke on dates before Fri Dec 13 20:45:52 UTC 1901. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: crash partition
On Sat, Mar 02, 2002 at 08:45:18PM -0500, Michael Lucas wrote: > On Sat, Mar 02, 2002 at 03:38:47PM -0800, Crist J. Clark wrote: > > On Sat, Mar 02, 2002 at 03:28:58PM -0500, Michael Lucas wrote: > > And what's the problem with the age-old solution of using your swap > > partition? > > Is it safe, useful, and reliable to use a -stable savecore to recover > a -current dump? Will it always be so? My gut reaction is that this > isn't guaranteed to work properly. > > My laptop is configured for multi-boot, -stable and -current. While I > want to provide solid bug reports, my laptop is a production system; I > cannot have it down while I try to identify and fix today's Bug of > Slow Hideous Death. (Unfortunately, my current job is not even > vaguely FreeBSD related.) So, if -current panics, I boot -stable and > get on with life. > > I'd feel better if I had a separate place to dump these until I could > go home, boot into -current, recover the core, and get on with > prepping my bug report. Make a separate swap partition for each since you are going to be using the disk space anyway if you go with another setup. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: crash partition
On Sat, Mar 02, 2002 at 03:28:58PM -0500, Michael Lucas wrote: > After some comments from Greg Lehey during his kernel debugging > tutorial, (to paraphrase, "you can save your panic to a UFS partition, > but it won't be a UFS partition any longer"), I've been experimenting > with the idea of a "panic partition" for dumpdevs. The purpose is to > have a rapid reboot after a panic. > > Now, my laptop has a DOS sleep partition. Is it safe to use that as a > dumpdev? I have to use 320meg for a sleep partition, and 321 meg for > a dumpdev, when I could just use a 321-meg sleep/dump partition. > > It *seems* to work, but that means absolutely nothing in the real world. And what's the problem with the age-old solution of using your swap partition? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multicast problem with sis interface?
On Fri, Mar 01, 2002 at 01:41:23PM -0500, Leo Bicknell wrote: > In a message written on Fri, Mar 01, 2002 at 03:56:23AM -0800, Luigi Rizzo wrote: > > ok, these three drivers behave as follows: > > > > "ed" pads with whatever is left in the transmit buffer from > > earlier transmissions; > > "vr" pads with whatever is available in the mbuf after the actual data; > > I point out both of these are security risks. Granted, fairly > minor, but they allow someone to get all/part of a previous packet's > data, when they should have it. This sort of thing has been used > as an attack vector before. I think fixing these to pad with some > generated (0's, 1's, /dev/random, whatever) should be a top priority. The only "people" who can see the leftover stuff are the same ones who could have seen the original packet (the exception being very simple switches, but anyone who really wanted to could see everything over one of those anyway). If you are worried about this, don't buy Cisco. The first time I noticed this was watching NIDS go off multiple times from stuff coming over a 4000. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default mail.local permission
On Tue, Feb 19, 2002 at 02:26:44PM +0500, Dmitry A. Bondareff wrote: > Hi hackers! > > Help me to understand next situation: > > # cd /usr/src > # make buildworld > # make installworld > # make kernel Ugh. That's a dangerous way to go, installing world before you've installed a new kernel. [snip] > After this manipulations all works fine. > Why so problems? Why 1555 is not default permission ? Ju-ust a little behind the times. See the UPDATING from 20001020. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Odd ipfw behaviour
On Mon, Feb 18, 2002 at 11:08:02AM -0800, Julian Elischer wrote: > that patch is an MFC of a fix that went into -current. > it allows teh 'fwd' ing of packets from the 'input' filter to > external machines.. > > i.e. > this doesn't work without this patch: > > ipfw add 100 fwd 1.2.3.4 tcp from any to 1.2.3.5 80 in recv fxp0 > > > On Mon, 18 Feb 2002, Luigi Rizzo wrote: > > > On Mon, Feb 18, 2002 at 09:31:13AM -0800, Crist J. Clark wrote: > > > On Mon, Feb 18, 2002 at 12:01:17PM -0500, Michael R. Wayne wrote: > > > > On Mon, Feb 18, 2002 at 05:49:46AM -0800, Crist J. Clark wrote: > > > > > What precise version of FreeBSD are you running, BTW? > > > > > > > > 4.5 RELEASE, as stated in original message. > > > > > > Do these patches help? > > > > can you please summarise the problem and what the fix is trying to > > achieve ? Right. What I thought was happening was that the submitter did not understand that ipfw(8) 'fwd' was only supposed to work on packets leaving the system. At least that's what the documentation in -STABLE claims. However, his logs seemed to indicate that packets were getting 'fwd'ed coming in. That's what's confusing me. So I gave him what looked like a fix in -CURRENT that tries to get the incoming 'fwd's correct. My guess is that there is presently broken 'fwd'ing for incoming packets in -STABLE. But as I have been saying, I haven't had the chance/motivation to dig through the code or run the tests, so I can't say that with too much certainty. Thought the submitter could do some testing for us. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Odd ipfw behaviour
On Mon, Feb 18, 2002 at 10:09:28AM -0800, Luigi Rizzo wrote: > On Mon, Feb 18, 2002 at 10:04:58AM -0800, Crist J. Clark wrote: > > > > Do these patches help? > > > > > > can you please summarise the problem and what the fix is trying to > > > achieve ? > > > > I don't really understand what the problem might be, and the issue is > > Precisely for this reason, what is that your patch is actually > trying to fix/achieve ? Without a goal, how can even test that > your code does what it supposed to do! I was trusting what the commit log said, revision 1.187 date: 2001/12/28 21:21:57; author: julian; state: Exp; lines: +13 -5 Fix ipfw fwd so that it acts as the docs say when forwarding an incoming packet to another machine. Obtained from: Vicor Production tree MFC after: 3 weeks -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Odd ipfw behaviour
On Mon, Feb 18, 2002 at 09:38:52AM -0800, Luigi Rizzo wrote:
> On Mon, Feb 18, 2002 at 09:31:13AM -0800, Crist J. Clark wrote:
> > On Mon, Feb 18, 2002 at 12:01:17PM -0500, Michael R. Wayne wrote:
> > > On Mon, Feb 18, 2002 at 05:49:46AM -0800, Crist J. Clark wrote:
> > > > What precise version of FreeBSD are you running, BTW?
> > >
> > > 4.5 RELEASE, as stated in original message.
> >
> > Do these patches help?
>
> can you please summarise the problem and what the fix is trying to
> achieve ?
I don't really understand what the problem might be, and the issue is
further confused since I am not sure where to trust the ipfw(8) 'fwd'
documentation and where not to. In -STABLE, it still says that only
outgoing packets are 'fwd'ed, but that's not what the submitter's logs
seem to indicate. The -CURRENT documentation does not make the
distinction. I vaguely recall this "recent" change, but have not found
anything all that recent in the commit logs. Back in the fall there
was that merge from -STABLE to -CURRENT, and I wonder if the change
was hidden in there. I have not been inspired enough to dig through
ip_{{in,out}put,fw}.c to see just what is really going on. But with
the ease I made that patch, I don't think there is as much divergence
on the 'fwd' issue between -CURRENT and -STABLE as the documentation
seems to imply. But I could easily be wrong.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Odd ipfw behaviour
On Mon, Feb 18, 2002 at 12:01:17PM -0500, Michael R. Wayne wrote:
> On Mon, Feb 18, 2002 at 05:49:46AM -0800, Crist J. Clark wrote:
> > What precise version of FreeBSD are you running, BTW?
>
> 4.5 RELEASE, as stated in original message.
Do these patches help?
Index: ip_input.c
===
RCS file: /export/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.130.2.33
diff -u -r1.130.2.33 ip_input.c
--- ip_input.c 14 Feb 2002 11:19:57 - 1.130.2.33
+++ ip_input.c 18 Feb 2002 17:19:24 -
@@ -1618,21 +1618,29 @@
int error, type = 0, code = 0;
struct mbuf *mcopy;
n_long dest;
+ struct in_addr pkt_dst;
struct ifnet *destifp;
#ifdef IPSEC
struct ifnet dummyifp;
#endif
dest = 0;
+ /*
+* Cache the destination address of the packet; this may be
+* changed by use of 'ipfw fwd'.
+*/
+ pkt_dst = ip_fw_fwd_addr == NULL ?
+ ip->ip_dst : ip_fw_fwd_addr->sin_addr;
+
#ifdef DIAGNOSTIC
if (ipprintfs)
printf("forward: src %lx dst %lx ttl %x\n",
- (u_long)ip->ip_src.s_addr, (u_long)ip->ip_dst.s_addr,
+ (u_long)ip->ip_src.s_addr, (u_long)pkt_dst.s_addr,
ip->ip_ttl);
#endif
- if (m->m_flags & (M_BCAST|M_MCAST) || in_canforward(ip->ip_dst) == 0) {
+ if (m->m_flags & (M_BCAST|M_MCAST) || in_canforward(pkt_dst) == 0) {
ipstat.ips_cantforward++;
m_freem(m);
return;
@@ -1651,14 +1659,14 @@
sin = (struct sockaddr_in *)&ipforward_rt.ro_dst;
if ((rt = ipforward_rt.ro_rt) == 0 ||
- ip->ip_dst.s_addr != sin->sin_addr.s_addr) {
+ pkt_dst.s_addr != sin->sin_addr.s_addr) {
if (ipforward_rt.ro_rt) {
RTFREE(ipforward_rt.ro_rt);
ipforward_rt.ro_rt = 0;
}
sin->sin_family = AF_INET;
sin->sin_len = sizeof(*sin);
- sin->sin_addr = ip->ip_dst;
+ sin->sin_addr = pkt_dst;
rtalloc_ign(&ipforward_rt, RTF_PRCLONING);
if (ipforward_rt.ro_rt == 0) {
@@ -1704,7 +1712,7 @@
if (rt->rt_ifp == m->m_pkthdr.rcvif &&
(rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 &&
satosin(rt_key(rt))->sin_addr.s_addr != 0 &&
- ipsendredirects && !srcrt) {
+ ipsendredirects && !srcrt && !ip_fw_fwd_addr) {
#defineRTA(rt) ((struct in_ifaddr *)(rt->rt_ifa))
u_long src = ntohl(ip->ip_src.s_addr);
@@ -1713,7 +1721,7 @@
if (rt->rt_flags & RTF_GATEWAY)
dest = satosin(rt->rt_gateway)->sin_addr.s_addr;
else
- dest = ip->ip_dst.s_addr;
+ dest = pkt_dst.s_addr;
/* Router requirements says to only send host redirects */
type = ICMP_REDIRECT;
code = ICMP_REDIRECT_HOST;
Index: ip_output.c
===
RCS file: /export/ncvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.99.2.25
diff -u -r1.99.2.25 ip_output.c
--- ip_output.c 1 Feb 2002 10:42:09 - 1.99.2.25
+++ ip_output.c 18 Feb 2002 17:12:33 -
@@ -128,6 +128,7 @@
struct sockaddr_in *dst;
struct in_ifaddr *ia = NULL;
int isbroadcast, sw_csum;
+ struct in_addr pkt_dst;
#ifdef IPSEC
struct socket *so = NULL;
struct secpolicy *sp = NULL;
@@ -191,6 +192,9 @@
hlen = len;
}
ip = mtod(m, struct ip *);
+ pkt_dst = ip_fw_fwd_addr == NULL
+ ? ip->ip_dst : ip_fw_fwd_addr->sin_addr;
+
/*
* Fill in IP header.
*/
@@ -219,14 +223,14 @@
* and is still up. If not, free it and try again.
*/
if (ro->ro_rt && ((ro->ro_rt->rt_flags & RTF_UP) == 0 ||
- dst->sin_addr.s_addr != ip->ip_dst.s_addr)) {
+ dst->sin_addr.s_addr != pkt_dst.s_addr)) {
RTFREE(ro->ro_rt);
ro->ro_rt = (struct rtentry *)0;
}
if (ro->ro_rt == 0) {
dst->sin_family = AF_INET;
dst->sin_len = sizeof(*dst);
- dst->sin_addr = ip->ip_dst;
+ dst->sin_addr = pkt_dst;
}
/*
* If routing to interface only,
@@ -278,7 +282,7 @@
else
isbroadcast = in_broadcast(dst->sin_addr, ifp);
}
- if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) {
+ if (IN_MULTICAST(ntohl(pkt_
Re: file(1) returns amusing result
On Mon, Feb 18, 2002 at 01:23:08AM -0500, Dan Langille wrote:
> As part of my FreshPorts fun, I decided that after fetching a file from
> cvsweb, I should make sure the fetch worked. I decided to do that via
> file(1) and inspect the output. I was testing for ASCII, but that appears
> to not be good enough. Now I just test for HTML and reverse the sense of
> the test.
>
> Here was the most amusing output:
>
> $ file -b /usr/home/dan/ports/databases/mysql++/Makefile
> Apple Old Partition data block size: 21117 first type: AS_CONFIGURE=
> yes, number of blocks: 1702047597,
>
> $ head /usr/home/dan/ports/databases/mysql++/Makefile
> # ports collection makefile for:MySQL++
> # Date created: 20th July 2000
> # Whom: Miklos Niedermayer <[EMAIL PROTECTED]>
> #
> # $FreeBSD: ports/databases/mysql++/Makefile,v 1.10 2002/02/11 13:15:14
> ijliao Exp $
> #
>
> PORTNAME= mysql++
> PORTVERSION=1.7.9
> CATEGORIES= databases devel
As if anyone cares,
# ports collection makefile for: MySQL++
# Date created: 20th July 2000
# Whom: Miklos Niedermayer <[EMAIL PROTECTED]>
#
# $FreeBSD: ports/databases/mysql++/Makefile,v 1.10 2002/02/11 13:15:14 ijliao Exp $
#
PORTNAME= mysql++
PORTVERSION= 1.7.9
CATEGORIES= databases devel
MASTER_SITES= ftp://ftp.free.fr/pub/MySQL/Downloads/mysql++/ \
ftp://gd.tuwien.ac.at/db/mysql/Downloads/mysql++/ \
ftp://mirror.sit.wisc.edu/mirrors/mysql/Downloads/mysql++/
MAINTAINER= [EMAIL PROTECTED]
LIB_DEPENDS= mysqlclient.10:${PORTSDIR}/databases/mysql323-client
^^
It's those two characters, 0x5453, at an offset of 0x200 bytes that
causes the match. Gotta love file(1).
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Odd ipfw behaviour
What precise version of FreeBSD are you running, BTW? -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Odd ipfw behaviour
On Fri, Feb 15, 2002 at 06:09:51PM -0500, Michael R. Wayne wrote: [snip] > Using this ipfw rule on ProxyFirewall: >fwd $(squid-box) log tcp from $(windows-box) to any 80 > and checking the logs on ProxyFirewall, I see this horrible mess: > > ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 in via fxp1 > ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 out via fxp0 > <---!!! > ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 in via fxp1 > ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 out via fxp1 > ipfw: 6 Deny ICMP:5.1 ProxyFirewall BROWSERbox out via fxp1 > ipfw: 6 Deny ICMP:5.1 ProxyFirewall SQUIDbox out via fxp1 > last message repeated 31 times > > This, of course, causes terrible performance as the packets destined > for the local net bounce out the default interface. It can be > corrected by specifying an interface in the fwd rule: >fwd $(squid-box) log tcp from $(windows-box) to any 80 via fxp1 > > Is it expected behaviour for ipfw to disregard routing and put > packets out on interfaces where they have no chance of being properly > delivered (which would be odd) or is this a bug? I believe you are misinterpretting the logs. Each of those log entries is saying, "At rule 11005 I am forwarding this packet to SQUIDbox. The packet that triggered this rule was TCP BROWSERbox:1631 216.136.204.21:80 that came (out of|into) to the firewall via interface (fxp0|fxp1)" That is, the 'via fxp?' at the end is telling you about the packet that _triggered_ the rule, not where the packet was actually forwared to. If you sniffed the connection, I expect that you would have seen four packets go from the firewall to SQUIDbox. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: chroot+su idea
Also have a look at jail(8). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel after halt issued
On Thu, Feb 14, 2002 at 02:00:53PM -0500, PSI, Mike Smith wrote: > I just heard someone say that they believed that the kernel was still > running after a halt is issued, but just cannot (won't?) create any > processes. So while I realize this person may not know what they are > talking about (and am showing my own ignorance for even listening), the > question is... > > Is the kernel still running after a halt? I don't think it will work. As a simple test, I pinged the box when it was up. It ponged fine. I shut it down (shutdown -h now) to the, The operating system has halted. Please press any key to reboot. Prompt and pinged again. Silence. Since the ICMP responses all live in the kernel's IP stack, I don't think there is an IP stack running. > If it is, then there are very interesting possibilities for building in > very specific capabilities in the kernel, then under "halt" condition > have those capabilities available. AND NOTHING ELSE! Interesting from a > security standpoint. Plus it would not require to to strip your system > down to bare bones to eliminate holes. You could bring it up to a fully > capable system at any time it was necessary. It sounds like a bad trade to me anyway. Compare: a box in the shutdown state, a kernel running with no userspace, to a box up and running with absolutely no userland processes listening. In either case, the only way someone can break the box remotely is with an exploitable, remote vulnerability in the kernel. A DoS attack on the kernel has identical results in either case. In both cases, the attacker owNz yr b0>< if they find an exploitable bug. There is the slight advantage with no userland, that the attacker may have a harder time doing something they consider useful with the owned box and establishing themselves so that they retain control (but neither is impossible). The kernel-only box also has a HUGE security disadvantage that pretty much makes it a non-starter IMHO, no logging. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: crypt function - solution!
On Tue, Feb 12, 2002 at 01:44:51PM +0300, Varshavchick Alexander wrote: > Hi guys, > > Here followes how the problem was solved. Before the system upgrade to > 4.5, there was no separate /usr/lib/libcrypt.so.2 file, it was symlinked > to libdescrypt.so.2, and making the things the same way solved it! Playing > with /etc/auth.conf didn't help. > > To be more precise, symlinking libcrypt.so.2 on a running system cannot be > done, so what I did was copying /usr/lib/libedscrypt.so.2 to a temporary > directory and running command > > install -c -s -o root -g wheel -m 444 -fschg libcrypt.so.2 /usr/lib > > And beside this, the following symlinks were needed: > /usr/lib/libcrypt.a -> libdescrypt.a > /usr/lib/libcrypt.so -> libdescrypt.so > > They could be done by the ordinary way. > > If anybody have comments on the subject it's interesting to hear them, and > my big thanks to all who helped solving this issue. One small comment: This fix is completely wrong. In 4.4 (actually mid-4.3-STABLE) and above, there is no libedscrypt or libscrypt (see http://www.freebsd.org/releases/4.4R/relnotes-i386.html). libcrypt contains the code for doing DES, MD5, and Blowfish passwords. No need for the old symlink kludge. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: buildworld via ro mounted /usr/src
On Fri, Feb 01, 2002 at 10:54:55PM +0100, BOUWSMA Beery wrote: > > Mahlzeit! > %s wrote on %.3s, %lld Sep 1993 Hrm? > > > and build a kernel, and if you're trying to do that with a read-only > > > source, the default location for your kernel config file is within > > > that. This is solved in -CURRENT and is trivial to patch -STABLE to > > > Or you can just use the 'kernel,' 'buildkernel,' and 'installkernel' > > targets in the /usr/src Makefiles. > > Erm... now I'm confused. I'm not sure what I should think that you > thought that I meant to say if I didn't mean what I meant or wasn't > clear in saying what I should have said but might not have. > > The build procedure should be done as usual -- > # make (env variables if not given in /etc/make.conf) -j4 buildworld > # make KERNCONF=FreeBEER KERNCONFDIR=/usr/local/etc/conf -j4 buildkernel > # make KERNCONF=FreeBEER KERNCONFDIR=/usr/local/etc/conf installkernel > and so on... No, I was confused. I thought we were discussing how to do an "old fashioned" kernel build in a read-only /usr/src/sys. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: buildworld via ro mounted /usr/src
On Thu, Jan 31, 2002 at 10:20:01AM +0100, BOUWSMA Beery wrote: [snip] > Now, later, you'll come to the problem that you need to configure > and build a kernel, and if you're trying to do that with a read-only > source, the default location for your kernel config file is within > that. This is solved in -CURRENT and is trivial to patch -STABLE to > fix. Or you can just use the 'kernel,' 'buildkernel,' and 'installkernel' targets in the /usr/src Makefiles. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl(3) errnos wrong?
On Thu, Jan 24, 2002 at 11:52:09AM +0200, Ruslan Ermilov wrote:
> Sounds like that, but changing it now would be too backwards incompatible.
Then shouldn't we fix the documentation to reflect reality?
> On Wed, Jan 23, 2002 at 02:51:35AM -0800, Crist J . Clark wrote:
> > Here is a quick, broken, program,
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > #include
> >
> > /* #define MIB_LEN 6 */
> > #define MIB_LEN 5
> >
> > int main(int argc, char *argv[])
> > {
> > int mib[MIB_LEN];
> > size_t rttsize;
> >
> > mib[0] = CTL_NET;
> > mib[1] = PF_ROUTE;
> > mib[2] = 0;
> > mib[3] = AF_INET;
> > mib[4] = NET_RT_DUMP;
> > /* mib[5] = 0; */
> >
> > if (sysctl(mib, MIB_LEN, NULL, &rttsize, NULL, 0) != 0)
> > err(EX_OSERR, "sysctl(3) for table size failed");
> >
> > return 0;
> > }
> >
> > This broken version will return,
> >
> > $ ./sysctlerr
> > sysctlerr: sysctl(3) for table size failed: Invalid argument
> >
> > However, if we look at the errno descriptions in the sysctl(3)
> > manpage, an EINVAL is returned when,
> >
> > [EINVAL] The name array is less than two or greater than
> > CTL_MAXNAME.
> >
> > [EINVAL] A non-null newp is given and its specified length in
> > newlen is too large or too small.
> >
> > Neither of which is the case here. I think it should be returning one
> > of these,
> >
> > [ENOTDIR] The name array specifies an intermediate rather than
> > terminal name.
> >
> > [EISDIR] The name array specifies a terminal name, but the
> > actual name is not terminal.
> >
> > But "terminal" or "intermediate" names are not defined anywhere else
> > in the manpage.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: which port for libcrypto.so.2
On Tue, Jan 15, 2002 at 06:27:14PM -0500, James Housley wrote: > Alwyn Goodloe wrote: > > > > When trying to run ethereal I get the message > > > > %./ethereal > > /usr/libexec/ld-elf.so.1: Shared object "libcrypto.so.2" not found > > > > Anyone know which package I can get this from??? > > > > Check the compat port, they add the libraries from previous versions of > FreeBSD. > > misc/compat2x > misc/compat3x > misc/compat4x > > Check the pkg-plist files. My guess is compat3x Actually, libcrypto.so.2 is part of the base FreeBSD system. It is part of the 'crypto' distribution. This is much more of a -questions question than -hackers. Re-directed. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
On Mon, Jan 07, 2002 at 01:57:26PM +0200, Yonatan Bokovza wrote: > > -Original Message- > > From: Crist J. Clark [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, January 06, 2002 02:39 > > To: Leo Bicknell > > Cc: Rogier R. Mulhuijzen; [EMAIL PROTECTED] > > Subject: Re: path_mtu_discovery > [snip] > > I'd support it if anyone actually has any credible evidence that such > > attacks have ever occured. Or if there is are plausible ways to attack > > that don't require someone to sniff and inject into a connection in > > which the victim is participating (if you can do that, you can do much > > worse). > > The original message of the "old thread" mentioned: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=4186+0+archive/2001/freebsd-sec > urity/20010715.freebsd-security > > Darren Reed's post to BugTraq implied, IIRC, that an attacker can > kill (or slow down) a server if he requests a large file with low MSS. I took part in that discussion and there was no mention of real exploits. And TCP MSS is not the same thing as the PMTU (though they can be related). As I pointed out in that thread, there are much more devistating TCP attacks to worry about that are still threats like "Daytona" attacks. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
On Fri, Jan 04, 2002 at 07:08:16PM -0500, Leo Bicknell wrote: > In a message written on Sat, Jan 05, 2002 at 01:14:45AM +0100, Rogier R. Mulhuijzen >wrote: > > If we're on the internet yes. If you're in an environment other than one > > connected to the internet (do those even exist ) no. > > Hence my tuneable sysctl idea. > > I'll support a sysctl, however I'll also be quite insistant that > our defaults match the Internet. I'm fairly sure more FreeBSD > boxes are connected to the Internet than any other network. :-) I'd support it if anyone actually has any credible evidence that such attacks have ever occured. Or if there is are plausible ways to attack that don't require someone to sniff and inject into a connection in which the victim is participating (if you can do that, you can do much worse). The typical SYN flood or DDOS are real threats. This thread (and the previous ones like the one Darren started a few months back) have already expended more energy on the issue than the threat warrants. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/rc.firewall and /sys/netinet/ip_input.c are doing the same thing
On Wed, Dec 26, 2001 at 02:46:34PM +0700, Igor M Podlesny wrote: > > > On Mon, Dec 24, 2001 at 07:10:09PM +0700, Igor M Podlesny wrote: > >> > >> well, not all the same, but partly. Take a look: > > > Yes. We know. > > Well. It doesn't surprise me. > > P.S. Is it a `feature'? ;) > > P.P.S. Talking seriously (as much as possible ;), which reasons don't > let removing of 3 lines from rc.firewall? The reason not to remove them is to avoid the steady stream of emails to -questions, -security, -ipfw, and -net from people unaware of the built-in protection from loopback addresses informing us that we should have rules like that by default. The rules don't hurt anything (just _try_ to measure a performance impact), but you should of course feel free to not include them in your own firewall scripts. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/rc.firewall and /sys/netinet/ip_input.c are doing the same thing
On Mon, Dec 24, 2001 at 07:10:09PM +0700, Igor M Podlesny wrote: > > well, not all the same, but partly. Take a look: Yes. We know. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: install and boot on secondary master possible ? seems not...
On Sat, Dec 08, 2001 at 09:22:36AM -0700, Joesh Juphland wrote: > > If this is the case, that is, that it is the bios that is at fault, why is > it that when the computer boots it gets to the F1 ... Default ... boot menu > ? If it cannot read that drive to boot off of, why does it get there and > try, and _then_ fail ? Good point, I should read more carefully. That menu is in boot0 and the error message you see is from boot1. My guess (just a guess) is that boot1 is trying to read disks off of the bad driver. You can still try a boot floppy. Drop '1:ad(0,a)/boot/loader' (depending on your device numbering) in boot.config. I've done this when I put FreeBSD on a second hard drive and don't want to mess with the MBR on the primary disk, and it works well. > >On Fri, Dec 07, 2001 at 07:23:07PM -0700, Joesh Juphland wrote: > > > Hello, > > > > > > I have a machine whose primary IDE controller is blown. Only the > >secondary > > > works. So, I connected my single IDe drive as the secondary master, and > > > proceeded to install FreeBSD. > > > > > > The install went flawlessly. I installed with the FreeBSD boot > >manager(the > > > first choice on that screen of three boot loader choices) > > > > > > When I boot, I see the F1 .. Default menu. If I wait, or if I hit > >enter, I > > > am told: > > > > > > Read error > > > > > > I reinstalled, and this time didn't use the freeBSD boot manager. Just > >the > > > normal loader. This time, after POST, it goes directly to "read error". > > > > > > So, what can I do to this disk to make it possible for the machine to > >boot > > > off what I have installed on the secondary master ? I used the fixit > >disk > > > to mount the drive and tried to edit things in /boot, but I cannot > >figure > > > out exactly what to change. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: install and boot on secondary master possible ? seems not...
On Fri, Dec 07, 2001 at 07:23:07PM -0700, Joesh Juphland wrote: > Hello, > > I have a machine whose primary IDE controller is blown. Only the secondary > works. So, I connected my single IDe drive as the secondary master, and > proceeded to install FreeBSD. > > The install went flawlessly. I installed with the FreeBSD boot manager(the > first choice on that screen of three boot loader choices) > > When I boot, I see the F1 .. Default menu. If I wait, or if I hit enter, I > am told: > > Read error > > I reinstalled, and this time didn't use the freeBSD boot manager. Just the > normal loader. This time, after POST, it goes directly to "read error". > > So, what can I do to this disk to make it possible for the machine to boot > off what I have installed on the secondary master ? I used the fixit disk > to mount the drive and tried to edit things in /boot, but I cannot figure > out exactly what to change. This is most likely a problem with your BIOS. It doesn't matter what disk lables and boot blocks you put on your drive on the secondary controller if the BIOS never attempts to boot it. Go into the BIOS settings and see if there is a way to try to boot off of that drive. If that fails, make up a boot floppy. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Wed, Dec 05, 2001 at 04:02:47PM +0100, Bernd Walter wrote: > On Tue, Dec 04, 2001 at 11:26:39PM -0800, Crist J . Clark wrote: [snip] > > From what Ian said elsewhere in this thread, the O_TRUNC already does > > not "act strange" on a tape device. I don't see any new POLA issues if > > adding O_TRUNC to the write call doesn't change how dump(8) has been > > working on tapes for FreeBSD for these n years now. The only POLA > > issue I see is the current behavior that "regular" files are _not_ > > truncated, which was the start of the thread and the issue in the PR. > > That FreeBSD tape devices ignore this isn't a strong reason to do. > People may also dump to disk devices, I tested it. They don't care about O_TRUNC. > unix domains sockets, fifo I tested it. They don't care about O_TRUNC. > devices or media your don't even know today. How can you say if O_TRUNC or !O_TRUNC will be the desired behavior? Right now, O_TRUNC is desired for plain ol' files. O_TRUNC doesn't make a difference for tapes, raw disks, or FIFOs. If we need to add support for something else in the future, fine. If a future media type wants O_TRUNC, it's already there. > And the fstat way don't hurt anyone but instead is an absolute save > way without expecting anything about the output stream behavour. So you are going to do a switch for every possible file type? But what about the future unknown types? What do you do for the default case? Why bother since what to do for all of the known cases can be the same and should work for unknown cases too. > > I don't see who would care if FreeBSD's dump(8) might have some funny > > reactions on UNIX-like systems where O_TRUNC has a different behavior > > on tape devices. I don't think the Project is overly concerned about > > porting FreeBSD's dump(8) to other OSes. > > But we might care porting device drivers to FreeBSD. This will have no impact on device drivers. > Think of that we may start and run linux kernel modules someday. If open(2) calls behave differently, dump(8) is going to be the least of our concerns. > I don't asume it to be very likely - but you never know. Nope, not very likely. How about I put this in CURRENT, let it sit for a while, and if anyone has problems, we can deal with them? I don't see a big problem here. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wed, Dec 05, 2001 at 01:19:03PM -0500, Leo Bicknell wrote: > On Tue, Dec 04, 2001 at 11:48:52AM -0500, Jim Durham wrote: > > I know that only security fixes are supposed to go in RELENG_4, but > > the recent changes in the TCP stuff seem important enough that > > perhaps they could be put in RELENG_4 for those of us who run > > productions servers on -RELEASE ? > > After reading the replies a bit, I'm going to suggest some middle > ground. > > I think the changes should sit in stable for "a while", and while > they are there we should make notes of it in a few different places > and have people beat up on the changes with various tests. > > I think this is very good stuff, and that most of the people > tracking RELENG4_4 would want it, but only if it is 210% fully > tested and helps out 99.999% of all people. So let's verify > both of those and then revisit the issue. 4.5-RELEASE is only a month and a half away. By the time this "while" passes, we'll be there. If people have lived this long with the bugs, they can last until late January. -- "It's always funny until someone gets hurt. Then it's hilarious." Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Wed, Dec 05, 2001 at 05:10:49PM +1000, Greg Black wrote: > "Crist J . Clark" wrote: > > | On Wed, Dec 05, 2001 at 06:02:49AM +1000, Greg Black wrote: > | > Matthew Dillon wrote: > | > > | > | :In message <[EMAIL PROTECTED]>, Bernd Walter writes: > | > | :>> Is there any reason we don't want to truncate the file? Does O_TRUNC > | > | :>> not work well of the file is a tape device or something? > | > | :> > | > | :>I don't expect O_TRUNK to work on devices such tapes and disks. > | > | : > | > | :Well, it won't achieve anything on tapes or disk devices, but it > | > | :should be completely harmless to add the O_TRUNC flag. The current > | > | :behaviour is likely to be unexpected and cause confusion so it > | > | :might as well be changed. I'll commit this later unless someone > | > | :can think of a good reason not to. > | > | : > | > | :Ian > | > | > | > | Woa! That sounds like a bad idea to me. If you want to do it right > | > | then open(), fstat(), and only if the stat says it is a regular file > | > | do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored > | > | by us, but it's not a valid flag to pass to a tape device and we shouldn't > | > | do it. > | > > | > I haven't used any of them for a while, but there are certainly > | > Unix systems that treat O_TRUNC as a signal to rewind a tape > | > device before writing to it. > | > | So? Who cares? This is FreeBSD's dump(8) and FreeBSD's write(2). There > | is no reason to worry about portability of FreeBSD's dump(8) in how > | write(2) flags work. If our write(2) "does the right thing" with > | O_TRUNC and tape devices, there is no reason not to let it do the > | right thing on its own. > > That's a rather strange attitude. All I was suggesting that, > from the once-respected POLA, it would be less surprising to > people who might have experience of other systems if FreeBSD did > not make its own arrangements without some good reason. >From what Ian said elsewhere in this thread, the O_TRUNC already does not "act strange" on a tape device. I don't see any new POLA issues if adding O_TRUNC to the write call doesn't change how dump(8) has been working on tapes for FreeBSD for these n years now. The only POLA issue I see is the current behavior that "regular" files are _not_ truncated, which was the start of the thread and the issue in the PR. > There's > no need for responses like: "So? Who cares?" -- if there's some > reason not to consider other people, by all means explain it; > but be polite while you're at it. I don't see who would care if FreeBSD's dump(8) might have some funny reactions on UNIX-like systems where O_TRUNC has a different behavior on tape devices. I don't think the Project is overly concerned about porting FreeBSD's dump(8) to other OSes. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Wed, Dec 05, 2001 at 06:02:49AM +1000, Greg Black wrote: > Matthew Dillon wrote: > > | :In message <[EMAIL PROTECTED]>, Bernd Walter writes: > | :>> Is there any reason we don't want to truncate the file? Does O_TRUNC > | :>> not work well of the file is a tape device or something? > | :> > | :>I don't expect O_TRUNK to work on devices such tapes and disks. > | : > | :Well, it won't achieve anything on tapes or disk devices, but it > | :should be completely harmless to add the O_TRUNC flag. The current > | :behaviour is likely to be unexpected and cause confusion so it > | :might as well be changed. I'll commit this later unless someone > | :can think of a good reason not to. > | : > | :Ian > | > | Woa! That sounds like a bad idea to me. If you want to do it right > | then open(), fstat(), and only if the stat says it is a regular file > | do you then ftruncate(). Passing O_TRUNC to a tape device may be ignored > | by us, but it's not a valid flag to pass to a tape device and we shouldn't > | do it. > > I haven't used any of them for a while, but there are certainly > Unix systems that treat O_TRUNC as a signal to rewind a tape > device before writing to it. So? Who cares? This is FreeBSD's dump(8) and FreeBSD's write(2). There is no reason to worry about portability of FreeBSD's dump(8) in how write(2) flags work. If our write(2) "does the right thing" with O_TRUNC and tape devices, there is no reason not to let it do the right thing on its own. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Tue, Dec 04, 2001 at 07:37:04PM -0500, Garance A Drosihn wrote: > While on the topic of 'dump', note that there's also the patch in > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=bin/32414 > > which fixes a problem where dump will include information that > should not be included (due to the nodump flag being set). This > too would result in dump files larger than they "should" be... > > The PR includes a patch which is meant to fix this problem. Yeah, I've been looking at these two together. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/32261: dump creates a dump file much larger than sum of dumped files
On Tue, Dec 04, 2001 at 10:04:57PM +1100, Mark Hannon wrote:
> Hi Chris,
>
> This is exactly what I was seeing! (I finally twigged when I did a
> low level backup of a filesystem and then noticed that my level 9
> backup was the same length as the night before )
>
> Thanks, Mark
>
>
> "Crist J . Clark" wrote:
> >
> > I did some more checking on how dump(8) works. If you dump to an
> > existing file, the file can never get smaller. That is, the file is
> > not truncated. I'll look at whether there is a good reason for this.
> > Is this actually what you were describing?
I don't really see a reason why dump(8) needs to work that way. Here
is an untested patch that should change that behavior.
Index: src/sbin/dump/tape.c
===
RCS file: /export/ncvs/src/sbin/dump/tape.c,v
retrieving revision 1.12.2.1
diff -u -r1.12.2.1 tape.c
--- src/sbin/dump/tape.c1 Aug 2001 06:29:35 - 1.12.2.1
+++ src/sbin/dump/tape.c4 Dec 2001 11:24:12 -
@@ -609,10 +609,10 @@
}
#ifdef RDUMP
while ((tapefd = (host ? rmtopen(tape, 2) :
- pipeout ? 1 : open(tape, O_WRONLY|O_CREAT, 0666))) < 0)
+ pipeout ? 1 : open(tape, O_WRONLY | O_CREAT | O_TRUNC, 0666)))
+< 0)
#else
while ((tapefd = (pipeout ? 1 :
- open(tape, O_WRONLY|O_CREAT, 0666))) < 0)
+ open(tape, O_WRONLY | O_CREAT| O_TRUNC, 0666))) < 0)
#endif
{
msg("Cannot open output \"%s\".\n", tape);
Is there any reason we don't want to truncate the file? Does O_TRUNC
not work well of the file is a tape device or something?
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs(1) Update and CVS/Entries
On Sun, Nov 11, 2001 at 02:28:41AM +, Christian Weisgerber wrote: > Crist J. Clark <[EMAIL PROTECTED]> wrote: [snip] > > Even though the modification time of CVS/Entries is changed > > everytime, those directories are not added. > > Like it or not, that's a feature. Those directories where not > checked out into this parent directory. CVS doesn't know about > them, so it purposely ignores them. CVS will not pick up random > files lying around and add or sync them to the repository. That > they happen to share the names of directories already in the > repository doesn't matter. Things either need to have been checked > out or added. They were added by CVS... I think. > > Am I not doing something correctly. > > I don't know how you created this particular situation, but you > must have done something wrong along the way. Those ports have been added since I initially did a 'cvs co' of the ports tree. I would have expected CVS to have added them to 'CVS/Entries' when it first added those directories in a 'cvs up'. I am not sure why it didn't. Oh, well. I'll just do some surgery the 'Entries' and be done with it. Thanks for the response. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cvs(1) Update and CVS/Entries
I cvsup(1) the FreeBSD CVS repository. I've noticed something that annoys me slightly, but also makes me worry if I am not doing something correctly. The CVS/Entries file does not seem to get updated when I do a 'cvs update.' First, I have, $ cat .cvsrc # $Id: .cvsrc,v 1.1 2001/10/08 04:52:43 cjc Exp $ # diff -u update -dP As an example, when I run, $ cvs up ports/x11-wm cvs update: Updating ports/x11-wm ? ports/x11-wm/golem ? ports/x11-wm/kdeartwork ? ports/x11-wm/mosfet-liquid ? ports/x11-wm/phluid ? ports/x11-wm/ratmenu cvs update: Updating ports/x11-wm/9menu cvs update: Updating ports/x11-wm/9menu/files cvs update: Updating ports/x11-wm/9wm cvs update: Updating ports/x11-wm/9wm/files cvs update: Updating ports/x11-wm/aewm . . . cvs update: Updating ports/x11-wm/golem . . . cvs update: Updating ports/x11-wm/kdeartwork . . . It claims it does not know about golem, kdeartwork, mosfet-liquid, phluid, and ratmenu, but they are recursed into and updated. If I run the same 'cvs up' again, I get the same result. Even though the modification time of CVS/Entries is changed everytime, those directories are not added. If I do a fresh 'cvs co' of ports_x11_wm, those directories are in the CVS/Entries file, so they are not actually stale directories. Why isn't the CVS/Entries file updated? Am I not doing something correctly. I've got a bunch of '?' entries produced everytime I update the ports tree and it would be nice to know which are problems and which, like these, are "false alarms." -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Valid user name
On Sat, Oct 13, 2001 at 01:05:10PM +0400, Yar Tikhiy wrote:
> On Fri, Oct 12, 2001 at 07:24:57PM +0300, Peter Pentchev wrote:
> > On Fri, Oct 12, 2001 at 09:52:10AM -0600, Warner Losh wrote:
> > > In message <[EMAIL PROTECTED]> Yar Tikhiy writes:
> > > : Is there any reason to omit the period ('.') from the list of valid
> > > : characters? With the period included, the list would conform to
> > > : POSIX's definition of a valid user name.
> > >
> > > Not any more. it used to be that chown user.group would be
> > > ambiguous. now it isn't, since user:group is the right syntax.
> >
> > This might be a problem for NIS or Kerberos domains - an older version
> > of FreeBSD might be confuzzled by usernames which are perfectly valid
> > for the rest of the client boxes.
>
> Oh, I see. Given that the only issue about the period in user names
> is compatibility, should pw(8) and adduser(8) still reject it or accept
> it and print a warning? I think printing a warning is better since
> the validity check is by no means a panacea--a stupid admin can always
> use vipw(8) to create any kind of an invalid user name.
That arguement goes both ways. They can use vipw(8) or they can edit
master.passwd directly if they insist on living dangerously. They can
even hack pw(8) or adduser(8) if they want. But no reason to let
pw(8) or adduser(8) fsck up their systems for them. After all, tools
like adduser(8) are aimed more towards the inexperienced admin. If any
administrative apps are going to do hand-holding, adduser(8) is one of
them.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Valid user name
On Fri, Oct 12, 2001 at 02:52:28PM +0400, Yar Tikhiy wrote:
> Hi there,
>
> Now adduser(8) and pw(8) differ in what a valid user name is.
> Adduser(8) enforces a user name to match the /^[a-z0-9_][a-z0-9_\-]*$/
> regexp. OTOH, pw(8) uses the Good Old Wrong Way of checking validity--
> it checks a user name against a list of *invalid* characters.
>
> I'm going to fix pw(8) so its view on valid user names is consistent
> with that of adduser(8).
>
> Is there any reason to omit the period ('.') from the list of valid
> characters? With the period included, the list would conform to
> POSIX's definition of a valid user name.
The historical reason '.' is avoided is because it breaks,
# chown user.group file
Syntax. See the COMPATIBILITY section of chown(8).
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: nfsd and mountd in the wrong place
On Tue, Oct 09, 2001 at 05:33:18PM -0700, Gordon Tetlow wrote: > I posted this to -arch and was met with (mostly) deafening silence. If > someone could please take care of this, I would be most grateful. Since it > requires a repo-copy, I guess Peter Wemm or JDP will need to be involved. Perhaps well tested patches to the rc(8) files and any source files than need to be modified would make this go more smoothly. -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FW: How To Recreate /var Files?
On Fri, Oct 05, 2001 at 08:42:45AM -0700, Drew Tomlinson wrote: > I posted a message to Questions and received the response below which > resolved half of the problem. I *can* reinstall FBSD without much pain as > it was a (mostly) fresh install before I ruined it. But I would *really* > like to learn how to fix this as opposed to starting over. > > I believe there is some part of the install process that creates the default > files. What is it and can I run just that part? I thank you for your time! Run mergemaster(8) and look at the contents of the var/ it creates under its temproot. Make sure that any log files that you may have added to your syslog.conf(5) are touched. -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: startx /dev/mem problem
On Sat, Jan 20, 2001 at 01:51:43AM +0100, Dag-Erling Smorgrav wrote: > Chris Stenton <[EMAIL PROTECTED]> writes: > > Fatal server error: > > xf86OpenConsole: Server must be suid root > > This is your clue. He might also be running at elevated securelevel. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
||_ | PLEASE DO | | | | NOT FEED | | THANK | | THE TROLLS | | YOU | || |_| || | || | || | || | || | || | || | || | || |```|| |` Please, not on another list. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Great American Gas Out
On Sat, Mar 04, 2000 at 09:20:09AM -0700, Brett Glass wrote: > At 04:42 PM 3/3/2000 , Mark Newton wrote: > > >Our prices are held *up* by the fact that over 50% of them constitute > >State and Federal taxes. > > Same in the US and Europe. Driving is a sin that must be taxed, y'know. Driving is an activity that incurrs a cost on society, building roads, regular maintainance, salter, snow plows, maintainace to fix the damage the snow plows did, etc. > This week, I traveled from Wyoming to California and discovered that > gas prices were 25% higher in the Golden State than in the Cowboy > State. Why? Because Californians "tax" themselves by requiring that > everyone buy fuel with high concentrations of MTBE, an oxygenating agent. > MTBE was supposed to reduce pollution, but in fact is a worse pollutant > than oxides of nitrogen ever were. However, since only California > refineries make gas with a high enough concentration of MTBE, Californians > are locked into buying from these few sources and the price goes up. > WAY up. Los Angeles will have $2.50 gas this summer. Yet the number of f*cking SUVs and other gas-guzzling vehicles in the region will continue to rise as will the miles driven per vehicle. > It's the same the whole world over. Energy policies and fuel costs aren't > driven by markets or even common sense. They are controlled by big > cartels, big government, and politics. Just like everything else. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: patches for de driver (full-duplex packet loss problems)
On Sun, Feb 13, 2000 at 09:29:15PM -0500, Jim Mercer wrote: > On Sun, Feb 13, 2000 at 06:05:55PM -0500, Crist J. Clark wrote: > > > with the mailing list archives down, i can't do my own search, but i was > > > hoping someone on these lists could give me some pointers. > > > > Try www.deja.com and search the muc.lists.freebsd.* hierarchy. > > i'll poke about there. > > > Just one question I always ask people trying to get things working at > > full-duplex, is the card plugged into a hub at the other end? > > actually, we started with cross over cables, and then suspecting them, tried > jacking into a number of 10mbp and 10/100mbps hubs. > > still getting various problems (from high packet loss to not being able to > sync up 100bps/fullduplex). You can't go full-duplex with a hub. -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: patches for de driver (full-duplex packet loss problems)
On Fri, Feb 11, 2000 at 03:59:49PM -0500, Jim Mercer wrote: > > i hear that there are some patches which might fix some serious packet loss > problems with the de driver in 100mbps fullduplex. > > i am running 3.4 (synced to stable via cvsup). > > with the mailing list archives down, i can't do my own search, but i was > hoping someone on these lists could give me some pointers. Try www.deja.com and search the muc.lists.freebsd.* hierarchy. Just one question I always ask people trying to get things working at full-duplex, is the card plugged into a hub at the other end? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATAPI tape drive (wst0) problem.
Alexander Prohorenko wrote, > Hello, > > I've got some problem and I need your help to solve it. > > uname -mrs > FreeBSD 3.3-STABLE i386 > > dmesg output: > > wdc1: unit 1 (atapi): , removable, accel, iordy > > I've added such strings to kernel configuration file: > > options ATAPI > device wst0 And you did rebuild the kernel and reboot right? The dmesg output should contain references to this device, wst0, besides just the fact wcd1 found _something,_ no? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
