Re: CFR: Exceedingly minor fixes to libc
Hi,
>>>>> On Fri, 13 Nov 2009 00:18:49 -0500
>>>>> Garrett Wollman said:
wollman> Index: inet/inet_cidr_pton.c
wollman> ===
wollman> --- inet/inet_cidr_pton.c (revision 199242)
wollman> +++ inet/inet_cidr_pton.c (working copy)
wollman> @@ -236,7 +236,6 @@
wollman>endp[- i] = colonp[n - i];
wollman>colonp[n - i] = 0;
wollman>}
wollman> - tp = endp;
wollman>}
wollman>
wollman>memcpy(dst, tmp, NS_IN6ADDRSZ);
Since this function is vendor import one from ISC, such cosmetic
change may cause problem during further import. So, you should send
this patch to ISC folks 1st.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: ping6 and traceroute6 trouble
Hi,
>>>>> On Sun, 29 Mar 2009 18:26:04 +
>>>>> Pegasus Mc Cleaft said:
ken>I have only seen this recently and was wondering if anyone else can
confirm
ken> this as a bug or perhaps a setup problem on my end. I think it started to
ken> appear with 8-Current from about the 25th of march.
ken>Any time I do a ping6 or traceroute6 I receive an error stating
"Invalid
ken> value for hints." However, I am able to do all other functions (telnet,
ssh,
ken> etc.)
ken> feathers# ping6 ipv6.google.com
ken> ping6: Invalid value for hints
ken> feathers# traceroute6 ipv6.google.com
ken> traceroute6: Invalid value for hints
I've committed the change to lib/libc/net/getaddrinfo.c little while
ago that also fixed the problem. Please re-cvsup and try it.
http://svn.freebsd.org/viewvc/base/head/lib/libc/net/getaddrinfo.c?r1=190416&r2=190525&view=patch
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: getaddrinfo() spec doesn't match behaviour
Hi, >>>>> On Sun, 3 Feb 2008 14:50:18 +0100 >>>>> "Heiko Wundram (Beenic)" <[EMAIL PROTECTED]> said: wundram> hints.ai_flags is logically anded with AI_MASK at the beginning of the wundram> function, and AI_MASK (at least in my local netdb.h header) does not contain wundram> the flag AI_V4MAPPED. In case the result of that is non-zero (which it is due wundram> to me specifying AI_V4MAPPED), the function returns EAI_BADFLAGS. wundram> After that, getaddrinfo() does some checks on AI_V4MAPPED and AI_ALL (masking wundram> the respective flags in case the ai_family isn't AF_INET6), which are wundram> basically superfluous (as they can never be set anyway due to AI_MASK), but I wundram> didn't find any other reference to the flag in the whole of wundram> lib/libc/net/getaddrinfo.c, so I actually don't know whether the cause of wundram> this failing is that it simply isn't implemented (completely), or there's any wundram> other reason for AI_MASK not to contain these flags that I haven't grasped so wundram> far. Since the part is incomplete support of AI_ALL and AI_V4MAPPED, I've just nuked it. http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/net/getaddrinfo.c#rev1.87 Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6to4, stf and shoebox NAT routers
Hi, >>>>> On Fri, 03 Aug 2007 10:08:48 +0200 >>>>> Lapo Luchini <[EMAIL PROTECTED]> said: lapo> Hajimu UMEMOTO wrote: > I posted my proposed patch to current@ for review in the past. But, > no one responded. Could you test this? This is for 6-CURRENT at Feb 1. > If it doesn't apply cleanly, please let me know. lapo> It applied cleanly to 6.2-STABLE and seems to work perfectly... outbound lapo> at least. lapo> I have a box at home called cyberx which has static IPv4 but is NATted lapo> (and is thus using your patch). lapo> The other test box is a server called motoko which has static IPv4 lapo> assigned to one of his interfaces directly (no patches here). lapo> The wl500g router correctly forwards the protocol 41 packets to cyberx. lapo> Pinging from cyberx to motoko (and using tcpdump on both) I can see that: lapo> a. cyberx if producing correct IPv4 packets that are from his local lapo> NATted address to the real motoko address, but containing a IPv6 packet lapo> that contains the '2002:'-encoding of both real IPv4 addresses lapo> b. motoko is receiving the echo request correctly lapo> c. motoko is sending the echo reply correctly lapo> d. cyberx is receiving the echo reply encapsulated in IPv4 packets correctly lapo> e. cyberx's stf0 interface IS NOT RECEIVING his IPv6 echo reply lapo> f. the 'ping' command thinks that all packets are lost lapo> Does you patch address incoming packets too? Yes, it should address incoming packets. lapo> Can I do some ipfw magic to convince stf to receive also incoming lapo> packets with a mismatched IPv4-IPv6 address? No, you shouldn't need any ipfw magic. However, the NAT box have to forward the incomming tunneling packets to your stf box correctly. I guess you do so. How do you configure your stf interface? You need to assign a 6to4 address which is derived from the IPv4 global address assigned to the NAT box. And you need to set net.link.stf.no_addr4check to 1. Is it okay? sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [SOLVED] Re: [patch] enhance powerd(8) to handle max temperature
Hi, >>>>> On Tue, 31 Jul 2007 12:44:06 +0200 >>>>> Pietro Cerutti <[EMAIL PROTECTED]> said: gahr> Nevermind, I finally got my passive cooling working. Congratulation! gahr> I don't know if the values of _TC1, _TC2 and TSP are meaningful, but it gahr> seems to work for me, having a _PSV value of 65C. gahr> Any suggestions on those values are welcome. The cpufreq is controlled according to the following formula: P [%] = _TC1 * ( Tn - Tn-1 ) + _TC2 * ( Tn - _PSV ) Pn = Pn-1 + HW[ - P ] where 0% <= Pn <= 100% And, this evaluation is examined every _TSP / 10 second. I'm not sure which values are appropriate for your box, but my laptop has the following values: Name (_TC1, Zero) Name (_TC2, 0x0C) Name (_TSP, 0x28) The values are same as you chose. Please refer the following document for detail: http://www.acpi.info/DOWNLOADS/ACPIspec-2-0c.pdf Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] enhance powerd(8) to handle max temperature
Hi, >>>>> On Tue, 31 Jul 2007 07:54:20 +0200 >>>>> Pietro Cerutti <[EMAIL PROTECTED]> said: gahr> Thanks for your help! I cannot see _TC1, _TC2 nor _TSP in your `acpidump -dt' output. Further, there is no _PSV definition in anywhere, in the first place. It seems to me that your ACPI BIOS doesn't support passive cooling at all. gahr> hw.acpi.thermal.user_override: 1 gahr> hw.acpi.thermal.tz0._PSV: 80.0C I suspect that you set hw.acpi.thermal.tz0._PSV manually. Of cource, it is insufficient to make passive cooling work with your ACPI BIOS, and you need the definition of _TC1, _TC2 and _TSP as well. If you define apropreate definition of them, passive cooling will work. But, we don't provide overriding the values of them. Perhaps, modifying your ASL (`acpidump -dt' output) to add the definitions of _TC1, _TC2, _TSP and _PSV, and loading it from loader will make passive cooling work. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] enhance powerd(8) to handle max temperature
Hi, >>>>> On Mon, 30 Jul 2007 23:31:33 +0200 >>>>> Pietro Cerutti <[EMAIL PROTECTED]> said: gahr> I can't test it, since I can't use passive cooling, but how do not these gahr> two systems interfere with each other wrt setting the CPU frequency? gahr> What if, for example, my CPU temperature rises above _PSV but the CPU gahr> usage drops below 65%? Do you mean that your hw.acpi.thermal.tz0._PSV has reasonable value? If so, perhaps, your ACPI BIOS is broken, and _TC1, _TC2 and _TSP are not defined correctly. Please show me the output of `sysctl hw.acpi' and `acpidump -dt'. gahr> In this case, the CPU frequency should be increased according to gahr> powerd's algorithm and should be decreased according to passive gahr> cooling's algorithm. gahr> Wouldn't it be better to have one subsystem deal with both usage and gahr> temperature in order to decide which is the best next frequency to be set? No, we have a priority to control a cpufreq in our kernel, to deal with conflict between kernel and userland. Controlling cpufreq within our kernel is considered as high proirity. So, during our kernel is controlling a cpufreq, we cannot change cpufreq from userland. And, our kernel releasing the control, a cpufreq is back to the value before our kernel changed it. gahr> My patch is really just a first draft that I wrote in order to have gahr> feedbacks on the general idea to implement a temperature controlling gahr> system inside powerd, and doesn't implement hysteresis as you noted, and gahr> your feedback is that it's not a good idea, which I respect. It is rather backward, IMHO. I did implement a passive cooling feature as an enhancement of powerd(8) like you did, during initial phases. Then, I implemented it in our kernel as a result. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] enhance powerd(8) to handle max temperature
Hi, >>>>> On Fri, 27 Jul 2007 16:43:29 +0200 >>>>> Pietro Cerutti <[EMAIL PROTECTED]> said: gahr> Hi list, gahr> here is a patch to allow powerd(8) accept a "-t tval" option to set a gahr> temperature limit above which performance should be decreased. gahr> It's a first draft, and I identified the following problems: gahr> - the CPU temperature takes some time to decrease, so powerd keeps gahr> decreasing the CPU frequency until the temperature is below the limit. gahr> The effect is a "increase to maximum, decrease to minimum, increase to gahr> maximum, decrease to minimum, " which may not be desirable. gahr> - the temperature is retrieved by the hw.acpi.thermal.tz0.temperature gahr> sysctl MIB. Support for other methods would be desirable. gahr> The patches to powerd.c and powerd.8 are here: gahr> http://www.gahr.ch/FreeBSD/patches/powerd.c.diff gahr> http://www.gahr.ch/FreeBSD/patches/powerd.8.diff gahr> Any comment is welcome! We have a passive cooling mechanism already in our kernel. It runs according to an ACPI specification. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Advice on the lightweight resolver, lwres.
Hi, >>>>> On Thu, 09 Mar 2006 08:23:24 -0800 >>>>> othermark <[EMAIL PROTECTED]> said: atkin901> I was working on converting the STAF (staf.sourceforge.net) project to an atkin901> freebsd port, and on my first attempt, I attempted to use the lightweight atkin901> resolver library because of the thread safe functions _r() that were atkin901> available. FYI: Though we don't expose _r() functions, our netdb functions without _r are thread-safe. So, you don't need _r() functions to be thread-safe. Further, getaddrinfo(3) in lwres still has query order problem which was solved in our getaddrinfo(3). BTW, I'm now working on upgrading the base of our resolver to BIND8's. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: res_nXXX function
Hi, >>>>> On Fri, 18 Nov 2005 16:56:39 +0100 >>>>> Jose Marcio Martins da Cruz <[EMAIL PROTECTED]> said: Jose-Marcio> Since which version I can consider the resolver is thread-safe ? The resolver itself (res_* functions) is thread-safe since 5.3-RELEASE. The netdb functions such as gethostbyname(3) and gethostbyaddr(3) are since 5.4-STABLE as of May 19 2005 and 6.0-RELEASE. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: res_nXXX function
Hi, >>>>> On Thu, 17 Nov 2005 15:17:38 +0100 >>>>> Jose Marcio Martins da Cruz <[EMAIL PROTECTED]> said: Jose-Marcio> It seems that FreeBSD doesn't have reentrant versions of DNS query functions Jose-Marcio> (res_nXXX, ...). Our recent resolver is thread-safe. So we don't need to use res_n*(), basically. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ip6.int deprecated
Hi, >>>>> On Tue, 30 Aug 2005 00:55:29 -0700 >>>>> Doug Barton <[EMAIL PROTECTED]> said: dougb> The one step I'm going to take directly to support this deprecation is to dougb> remove the ip6.int example from the sample named.conf file in the base. I'm dougb> sending this message to provide notice of that, and notice to the community dougb> generally that we should start moving in the direction of deprecating dougb> ip6.int wherever it might be found. I think it's a time to nuke RFC 1886 example from our named.conf. dougb> Other than some old references in src/contrib/bind9, the only place I see a dougb> reference to ip6.int in our base is in the named.conf file that I mentioned dougb> above. I hope that this note is useful however as a more general source of dougb> information, and of course if there is anything I've missed, I welcome dougb> others to take appropriate action. Yes, there were ip6.int. lookups in our libc. But, I nuked them already about one year ago. I left named.conf as is intentionally at the time to help the boxes which don't support RFC 3152. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Converting libfoo.so for linux to freebsd
Hi, >>>>> On Tue, 9 Aug 2005 16:31:30 -0500 >>>>> Dan Nelson <[EMAIL PROTECTED]> said: dnelson> In the last episode (Aug 09), M. Warner Losh said: > I have recently purcahsed a device that comes with a .so for linux, > but no sources. Is there any way one can take an arbitrary linux .so > which appears to have no dependencies to a FreeBSD .so? The binary > code is about 20k or so. dnelson> As long as any structs that are passed back and forth have the same dnelson> members and alignment, it should work. This includes struct FILE, dnelson> which means if the app tries to use stdio it'll likely crash. dnelson> I just compiled a little "hello world" object file on SUSE and linked dnelson> it on FreeBSD and it ran (it just calls printf, which is safe since it dnelson> doesn't pass a FILE *). As far as the Linux shlib uses the functions which ABI are compatible with FreeBSD's one, it should work. However, if there are some ABI incompatibility, you may want to consider the approach of linuxpluginwrapper. The PIPS ports (print/pips*) link Linux shlib to FreeBSD binary. To do this, the PIPS ports use www/linuxpluginwrapper to fixup some ABI incompatibility. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: wishlist for sysutils/xbatt: two batteries
Hi, >>>>> On Wed, 01 Jun 2005 22:16:28 +0200 >>>>> Poul-Henning Kamp <[EMAIL PROTECTED]> said: phk> Isn't there some kind soul who can make sysutils/xbatt (or some other phk> X11 tool) show the status for the two batteries individually ? sysutils/gkrellm2 does. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] sbin/route should attempt to resolve hostnames for INET6
Hi, >>>>> On Sat, 21 May 2005 00:39:51 +0200 >>>>> Andreas Kohn <[EMAIL PROTECTED]> said: andreas> attached is a small patch to /sbin/route.c 1.78 so that route's behavior andreas> matches the description from the manpage: andreas> All symbolic names specified for a destination or gateway are andreas> looked up first as a host name using gethostbyname(3). If this andreas> lookup fails, getnetbyname(3) is then used to interpret the name as andreas> that of a network. I've committed it. andreas> - removes SOCK_DGRAM requirement, which was marked as "dummy". andreas> getaddrinfo(3) says 0 should be given if one does not care No, we should care it in usual. Unless this, two entries are returned; one is for SOCK_DGRAM and the other is for SOCK_STREAM. I feel that `dummy' means route(8) doesn't use ai_socktype later. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can't get correct address in string form
Hi,
>>>>> On Tue, 3 May 2005 18:39:10 +0300
>>>>> Sergey <[EMAIL PROTECTED]> said:
fenix>//get local address - local address is 192.168.0.250
fenix>if ((gaierr = getaddrinfo(argv[1], argv[2], &hints, &localaddr))
!= 0)
fenix>errx(1, "%s port %s: %s", argv[1], argv[2],
gai_strerror(gaierr));
You need to initialize hints before calling getaddrinfo(3).
fenix> inet_ntop(la->ai_family, la->ai_addr->sa_data, buf, sizeof(struct
sockaddr));
The usage of inet_ntop(3) is wrong.
It should be something like:
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
struct addrinfo hints, *la, *localaddr;
char buf[46];
int gaierr=0;
//get local address - local address is 192.168.0.250
bzero(&hints, sizeof(hints));
hints.ai_flags = AI_PASSIVE;
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
if ((gaierr = getaddrinfo(argv[1], argv[2], &hints, &localaddr)) != 0)
errx(1, "%s port %s: %s", argv[1], argv[2], gai_strerror(gaierr));
for (la = localaddr; la; la = la->ai_next)
{
switch (la->ai_family) {
case AF_INET:
inet_ntop(la->ai_family,
&((struct sockaddr_in *)la->ai_addr)->sin_addr,
buf, sizeof(buf));
break;
case AF_INET6:
inet_ntop(la->ai_family,
&((struct sockaddr_in6 *)la->ai_addr)->sin6_addr,
buf, sizeof(buf));
break;
default:
continue;
}
fprintf(stderr, "Address: %s\n", buf);
}
return 0;
}
You can use getnameinfo(3) to simplify usage of inet_ntop(3).
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6to4, stf and shoebox NAT routers
Hi, >>>>> On Fri, 11 Mar 2005 23:24:52 -0800 >>>>> Nick Sayer <[EMAIL PROTECTED]> said: nsayer> Well, I'm screwed. nsayer> I set up the Linksys router so that the FreeBSD machine is the "DMZ" nsayer> host on the inside. Sending 6to4 to the router's outside address nsayer> results in tcpdump showing these on the inside: nsayer> 22:09:36.138924 [linksys mac address] > ff:ff:ff:ff:ff:ff, ethertype nsayer> ARP (0x0806), length 60: arp who-has [linksys outside ip] tell [linksys nsayer> inside ip] nsayer> Which, quite frankly, is laughable. If that weren't enough, the packets nsayer> come out of the linksys router with the source IP address being from nsayer> the inside (meaning, it didn't get NATted). Humph. nsayer> So it appears that for now, I will have to keep a 2nd interface active nsayer> on this box solely for the purpose of doing IPv6. What a nightmare. It seems your Linksys box simply forward packets without translating destination address to your 6to4 box. I don't know actually what DMZ concept of Linksys is. However, you may need some additional setting into your Linksys box. Or, when you just set global addres of your Linksys box to your 6to4 box, you may be able to use 6to4 without my patch. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6to4, stf and shoebox NAT routers
1st paragraph)
-*/
- if (isrfc1918addr(in))
- return -1;
-
- /*
* reject packets with broadcast
*/
for (ia4 = TAILQ_FIRST(&in_ifaddrhead);
@@ -645,7 +658,16 @@ stf_checkaddr6(sc, in6, inifp)
*/
if (IN6_IS_ADDR_6TO4(in6)) {
struct in_addr in4;
+
bcopy(GET_V4(in6), &in4, sizeof(in4));
+
+ /*
+* reject packets with private address range.
+* (requirement from RFC3056 section 2 1st paragraph)
+*/
+ if (isrfc1918addr(&in4))
+ return -1;
+
return stf_checkaddr4(sc, &in4, inifp);
}
@@ -694,6 +716,18 @@ in_stf_input(m, off)
#ifdef MAC
mac_create_mbuf_from_ifnet(ifp, m);
#endif
+
+ /*
+* Skip RFC1918 check against dest address to allow incoming
+* packets with private address for dest. Though it may
+* breasks the requirement from RFC3056 section 2 1st
+* paragraph, it helps for 6to4 over NAT.
+*/
+ if ((!no_addr4check && isrfc1918addr(&ip->ip_dst)) ||
+ isrfc1918addr(&ip->ip_src)) {
+ m_freem(m);
+ return;
+ }
/*
* perform sanity check against outer src/dst.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Global (non _KERNEL) place for sockaddr_union?
Hi, >>>>> On Tue, 21 Sep 2004 09:14:20 -0700 >>>>> Brooks Davis <[EMAIL PROTECTED]> said: brooks> The real problem may be that KAME mistakenly gave sockaddr_union a brooks> general name when it isn't and such a type would be hell to actually brooks> work with. A custom union that does exactly what pf needs may be the brooks> best approach. I believe KAME doesn't use non standard struct such as sock_union. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: getaddrinfo
Hi,
>>>>> On Thu, 8 Jul 2004 12:05:52 +0300
>>>>> Jan Mikael Melen <[EMAIL PROTECTED]> said:
Jan.Melen> /etc/hosts:
Jan.Melen> 1ffe::10 oneffeten
Jan.Melen> 1ffe:1000:0001:10 oneffeten
Jan.Melen> 1ffe:1000:0002:10 oneffeten
It should be:
1ffe::10 oneffeten
1ffe:1000:0001::10 oneffeten
1ffe:1000:0002::10 oneffeten
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: inetd needs "discard" service in /etc/services
Hi,
>>>>> On Fri, 12 Mar 2004 09:06:30 -0800
>>>>> Brooks Davis <[EMAIL PROTECTED]> said:
brooks> Nope, I tried that. It turns out there's an annoying edge case that
brooks> makes it not work in this case (from line 496):
brooks> * check for special cases. (1) numeric servname is disallowed if
brooks> * socktype/protocol are left unspecified. (2) servname is disallowed
brooks> * for raw and other inet{,6} sockets.
How about this patch?
Index: usr.sbin/inetd/inetd.c
diff -u -p usr.sbin/inetd/inetd.c.orig usr.sbin/inetd/inetd.c
--- usr.sbin/inetd/inetd.c.orig Sat Nov 1 04:39:15 2003
+++ usr.sbin/inetd/inetd.c Tue Mar 23 17:41:17 2004
@@ -403,12 +403,16 @@ main(int argc, char **argv)
* getaddrinfo(). But getaddrinfo() requires at least one of
* hostname or servname is non NULL.
* So when hostname is NULL, set dummy value to servname.
+* Since getaddrinfo() doesn't accept numeric servname, and
+* we doesn't use ai_socktype of struct addrinfo returned
+* from getaddrinfo(), we set dummy value to ai_socktype.
*/
- servname = (hostname == NULL) ? "discard" /* dummy */ : NULL;
+ servname = (hostname == NULL) ? "0" /* dummy */ : NULL;
bzero(&hints, sizeof(struct addrinfo));
hints.ai_flags = AI_PASSIVE;
hints.ai_family = AF_UNSPEC;
+ hints.ai_socktype = SOCK_STREAM;/* dummy */
error = getaddrinfo(hostname, servname, &hints, &res);
if (error != 0) {
syslog(LOG_ERR, "-a %s: %s", hostname, gai_strerror(error));
brooks> The real problem is that we should either not use getaddrinfo to make
brooks> sockaddrs or we should do it on demand when we actually have what we
brooks> need (i.e. a service name and protocol).
It seems NetBSD's inetd do it on demand.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
Hi, >>>>> On Fri, 02 Jan 2004 11:23:11 -0700 (MST) >>>>> "M. Warner Losh" <[EMAIL PROTECTED]> said: imp> This looks like it isn't mapping the cis in correctly. Can you turn imp> on hw.cardbus.debug_cis=1? I assumed you meant hw.cardbus.cis_debug. ;) cardbus0: Resource not specified in CIS: id=10, size=800 cardbus0: Resource not specified in CIS: id=14, size=2 cardbus0: Resource not specified in CIS: id=18, size=80 cardbus0: Non-prefetchable memory at 8800-9001 cardbus0: IO port at 1000-107f cardbus0: at device 0.0 (no driver attached) cbb0: CardBus card activation failed Full output of dmesg is also attached in this mail. imp> : imp> 1) You are using hw.pci.unsupported_io=1. Turn it off and use imp> : imp>these patches. Let me know if it doesn't. Typically it imp> : imp>appears that this helps people hitting the double imp> : imp>allocation problem. imp> : imp> : I used to set hw.pci.unsupported_io=1. Changing this value doesn't imp> : help. imp> Dang. I'd like to get to the bottom of this. Aha, I made sure to set hw.pci.allow_unsupported_io_range. But, I did just copy&paste it from your message. :-) Sincerely, dmesg.out Description: Binary data -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Power Patches
Hi, >>>>> On Thu, 01 Jan 2004 23:30:09 -0700 (MST) >>>>> "M. Warner Losh" <[EMAIL PROTECTED]> said: imp> John Baldwin, Nate and I are putting the final touches on the imp> power/resource patches. Please try them out and let me know how well imp> they work for you. imp> http://people.freebsd.org/~imp/power.20040101.diff It fails to attach my Atheros card (I/O-Data WN-AG/CB): Jan 3 01:34:04 lyrics kernel: cardbus0: Resource not specified in CIS: id=10, size=800 Jan 3 01:34:04 lyrics kernel: cardbus0: Resource not specified in CIS: id=14, size=2 Jan 3 01:34:04 lyrics kernel: cardbus0: Resource not specified in CIS: id=18, size=80 Jan 3 01:34:04 lyrics kernel: cardbus0: at device 0.0 (no driver attached) Jan 3 01:34:04 lyrics kernel: cbb0: CardBus card activation failed imp>1) You are using hw.pci.unsupported_io=1. Turn it off and use imp> these patches. Let me know if it doesn't. Typically it imp> appears that this helps people hitting the double imp> allocation problem. I used to set hw.pci.unsupported_io=1. Changing this value doesn't help. My Aeronet 340 card is working fine. However, the card is inserted at boot, it doesn't attached at boot and after boot with following message: Jan 3 01:49:48 lyrics kernel: cbb1: Unsupported card type detected I'm using Victor InterLink MP-XP7210 (SiS 630 chipset). Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rijndael again
Hi, >>>>> On Thu, 18 Sep 2003 20:41:36 +0400 (MSD) >>>>> "lg" <[EMAIL PROTECTED]> said: zevlg> I seen patch submited to check padLen properly, but it does not covers CBC mode, which have same typo error .. Oops, I've just committed. Please re-cvsup and try it. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: possible rijndael bug
Hi, >>>>> On Wed, 17 Sep 2003 01:09:24 -0700 >>>>> [EMAIL PROTECTED] (Lev Walkin) said: > I saw it during working on next KAME merge into 5-CURRENT. > KAME/NetBSD uses assert() here like: > > assert(padLen > 0 && padLen <= 16); > > Since FreeBSD doesn't have assert() in kernel, this line was changed > to: > > if (padLen > 0 && padLen <= 16) > return BAD_CIPHER_STATE; > > for KAME/FreeBSD. Since if expression is true, the assert() macro > does nothing, the expression seems wrong, and it should be: > > if (padLen <= 0 || padLen > 16) > return BAD_CIPHER_STATE; > > as you pointed out. vlm> Absolutely NOT. vlm> According to RFC1423 and FIPS81, the padding length may be somewhere vlm> in between 1 to 16 bytes, which translated into vlm>if(padLen < 0 || padLen >= 16) vlm> for this particular code. Ah, yes. Then, `assert(padLen > 0 && padLen <= 16)'; should be wrong. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: possible rijndael bug
Hi,
>>>>> On Wed, 17 Sep 2003 11:25:44 +0400 (MSD)
>>>>> [EMAIL PROTECTED] ("lg") said:
zevlg> I recently examined rijndael implementation, which ships in sys/crypto/rijndael
and there
zevlg> is code in function rijndael_padEncrypt()(from rijndael-api-fst.c):
zevlg> numBlocks = inputOctets/16;
zevlg> ...
zevlg> ...
zevlg> padLen = 16 - (inputOctets - 16*numBlocks);
zevlg> if (padLen > 0 && padLen <= 16)
zevlg> panic("...");
zevlg> bcopy(input, block, 16 - padLen);
zevlg> for (cp = block + 16 - padLen; cp < block + 16; cp++)
zevlg> *cp = padLen;
zevlg> rijndaelEncrypt(block, outBuffer, key->keySched, key->ROUNDS);
zevlg> ...
zevlg> so padLen check will always success and it surely will panic, or even if we
admit that
zevlg> padLen check is bypassed(what is impossible i think) then bcopy() will be
called with
zevlg> larger size argument then size of block array or with negative size. Isn't this
padLen
zevlg> check is unneeded? or maybe it should look like 'if (padLen <= 0 || padLen >
16)'?
I saw it during working on next KAME merge into 5-CURRENT.
KAME/NetBSD uses assert() here like:
assert(padLen > 0 && padLen <= 16);
Since FreeBSD doesn't have assert() in kernel, this line was changed
to:
if (padLen > 0 && padLen <= 16)
return BAD_CIPHER_STATE;
for KAME/FreeBSD. Since if expression is true, the assert() macro
does nothing, the expression seems wrong, and it should be:
if (padLen <= 0 || padLen > 16)
return BAD_CIPHER_STATE;
as you pointed out.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gethostbyname_r
Hi, >>>>> On Mon, 30 Jun 2003 16:43:27 +0200 >>>>> Stijn Hoop <[EMAIL PROTECTED]> said: stijn> I was wondering if anybody was working on an implementation of a reentrant stijn> gethostbyname_r function, mostly because it looks like mozilla/firebird will stijn> finally gain support for an async DNS thread in the near future. However, stijn> it is claimed in Mozilla's bug reporting system that FreeBSD 5.x doesn't stijn> have support for this. See stijn> http://bugzilla.mozilla.org/show_bug.cgi?id=70213#c36 I believe Mozilla uses getipnodeby*() on FreeBSD. getipnodeby*() calls do giant lock to expect thread-safe. So, I believe we don't need gethostbyname_r() for Mozilla. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multi-threaded or async Mozilla (NSPR, really)
Hi,
>>>>> On Mon, 30 Dec 2002 19:56:46 -0600 (CST)
>>>>> D J Hawkey Jr <[EMAIL PROTECTED]> said:
hawkeyd> In article <[EMAIL PROTECTED]>,
hawkeyd>[EMAIL PROTECTED] writes:
> On Sun, Dec 22, 2002 at 07:18:54AM -0600, D J Hawkey Jr wrote:
>
>> I can't imagine what Moz is doing within it's DNS code, even with the
>> serialized DNS lookups. If nslookup replies within fractions of a second,
>> why doesn't Moz??
>
> Take a look at look at the getaddrinfo(3) man page and then try doing
> a look up of the or A6 records for the troublesome locations.
hawkeyd> After looking at the man page, and understanding all of ~35% of it, I'll
hawkeyd> ask this: Are you referring to the oft-mentioned, ill-configured, INET6
hawkeyd> records in some DNS servers, or are you referring to less-than-correct
hawkeyd> code in FreeBSD's TCP/IP stack, or are NSPR's routines indeed flawed?
hawkeyd> I guess I'll ask this, too: is getaddrinfo(3) called by gethostbyname(3)?
hawkeyd> It's the latter that Mozilla/NSPR calls, and is the blamed culprit.
Mozilla doesn't call getaddrinfo(). Mozilla uses gethostbyname2() to
resolve hostname. Since gethostbyname2() doesn't have a capability of
querying A RR and RR at same time, Mozilla calls gethostbyname2()
for RR 1st, then calls gethostbyname2() for A RR.
hawkeyd> For giggles, I disabled INET6 in the kernel, re- built and installed it,
hawkeyd> and the problem vanished. But this doesn't answer the question: Is it
hawkeyd> problematic DNS records, a problematic OS, or what? The second, I doubt...
I believe that Mozilla should be re-written by using getaddrinfo().
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Limiting clients per source IP address (ftpd, inetd, etc.)
Hi,
>>>>> On Thu, 20 Jun 2002 20:25:28 -0700
>>>>> Terry Lambert <[EMAIL PROTECTED]> said:
tlambert2> Giorgos Keramidas wrote:
> I've been thinking for quite some time to add per-client-IP limiting
> to ftpd, and I had almost decided upon something like the following,
> where each child of ftpd has two numbers associated with it. The
> client IP address, and the PID of the ftpd child that serves it. The
> hash at the beginning of the lists serves as a minor assistance in
> splitting the 2^32 address space in smaller chunks so that we don't
> end up with a singly linked list of a few thousand entries.
tlambert2> Someone just did something similar for inetd (per IP per port).
Yes, it's me. I already rewrote my patch to use open hash as you
mentioned. My patch is in testing on snapshots.jp.FreeBSD.org (thank
you Matusita-san).
You can find my patch from:
http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-hash-5c.diff (for 5-CURRENT)
http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-hash-4s.diff (for 4-STABLE)
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [CFR] max-child-per-ip restriction for inetd
Hi,
>>>>> On Sun, 16 Jun 2002 19:36:28 +0200 (SAT)
>>>>> John Hay <[EMAIL PROTECTED]> said:
jhay> Both the patches needs a colon (:) after the s on the getopt() line,
jhay> otherwise you just get a nasty coredump if you try to use the "-s num"
jhay> commandline option.
Oops, thanks. I just fix it and re-put it.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
[CFR] max-child-per-ip restriction for inetd
Hi,
I wish to add max-child-per-ip option to inetd. This enables us to
restrict maximum number of simultaneous invocations of each service
from a single IP address. The proposed patch can be found from:
http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-5c.diff (for 5-CURRENT)
http://www.imasy.or.jp/~ume/FreeBSD/inetd-perip-4s.diff (for 4-STABLE)
If there is no objection, I'll commit it at next weekend.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: IPv6-over-IPv4 problems since the upgrade to 4.5
Hi,
>>>>> On Thu, 28 Feb 2002 15:20:57 +1100
>>>>> Edwin Groothuis <[EMAIL PROTECTED]> said:
edwin> On Tue, Feb 26, 2002 at 02:38:28PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
> Finally I figured out the problem.
edwin> Thanks for these two patches, it works like a charm now!
I just committed both patches to -CURRENT. I'll do MFC after 1 week.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: rtadvd bugfix?
Hi,
>>>>> On Sat, 2 Feb 2002 02:49:49 +0100
>>>>> Marco Wertejuk <[EMAIL PROTECTED]> said:
wertejuk> I was really nerved when I noticed that rtadvd is exiting
wertejuk> without any notice if the host is not an ipv6 gateway.
wertejuk> Since it took me a lot of time to find this problem
wertejuk> I wrote a patch for rtadvd to show a message and
wertejuk> noticed something strange:
wertejuk> rtadvd won't exit even if ipv6 forwarding is not
wertejuk> enabled, take a look at this patch. (attachement)
wertejuk> Watch out for the changed if-condition.
wertejuk> Is that really a bug ?
No, I don't think it is a bug. The value of `forwarding' is checked
later. From config.c:
/*
* Basically, hosts MUST NOT send Router Advertisement messages at any
* time (RFC 2461, Section 6.2.3). However, it would sometimes be
* useful to allow hosts to advertise some parameters such as prefix
* information and link MTU. Thus, we allow hosts to invoke rtadvd
* only when router lifetime (on every advertising interface) is
* explicitly set zero. (see also the above section)
*/
if (val && forwarding == 0) {
syslog(LOG_WARNING,
"<%s> non zero router lifetime is specified for %s, "
"which must not be allowed for hosts.",
__FUNCTION__, intface);
exit(1);
}
And, I believe the message goes to syslog in this case.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [CFR] IPv6 support for pserver of cvs
Hi,
>>>>> On Sun, 4 Nov 2001 16:07:43 +0100
>>>>> Jeroen Ruigrok/Asmodai <[EMAIL PROTECTED]> said:
asmodai> -On [20011104 15:28], Hajimu UMEMOTO ([EMAIL PROTECTED]) wrote:
>I wish to add IPv6 support to pserver of cvs. You can find the patch
>from:
>
> http://www.imasy.or.jp/?(J?ume/ipv6/FreeBSD/cvs-ipv6.diff
>
>This patch is based on the patch by KAME folks. But, the patch is for
>1.11 and isn't applied cleanly to our cvs. So, some additional
>modification was made.
asmodai> Please feed this to the cvshome.org guys, that way we can just import
asmodai> the new version along the vendorbranch.
My patch requires getaddrinfo() and getnameinfo(). To do work on
other OSs which doesn't have getaddrinfo() and getnameinfo(), we need
extra work.
Original KAME patch has such code. I hope KAME folks sending their
version to cvs folks.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
[CFR] IPv6 support for pserver of cvs
Hi,
I wish to add IPv6 support to pserver of cvs. You can find the patch
from:
http://www.imasy.or.jp/‾ume/ipv6/FreeBSD/cvs-ipv6.diff
This patch is based on the patch by KAME folks. But, the patch is for
1.11 and isn't applied cleanly to our cvs. So, some additional
modification was made.
Please review it.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: About stscasestr() prototyped with string.h of current lib
Hi,
>>>>> On Fri, 2 Nov 2001 12:01:19 +0300
>>>>> "Andrey A. Chernov" <[EMAIL PROTECTED]> said:
ache> On Fri, Nov 02, 2001 at 17:36:04 +0900, NINOMIYA Hideyuki wrote:
> In implementation with current, even if you implemented it for the
> reason that Linux included, there is the problem that behavior is
> different from Linux in about prototyping reference.
ache> 1) Our strcasestr() implementation is not related to Linux that way.
ache> 2) Program must not prototype by itself system-wide functions and should
ache> relay on system headers instead.
ache> 3) Programs which not follows rule #2 must be fixed by removing
ache> prototypes in question from their headers.
I think nin said that having strcasestr() in our standard header
breaks existing program. That is, our header seems not confirm
standard. Mew2 could be compiled even on Linux which has
strcasestr().
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Fw: Fwd: (SIOCAIFADDR) Please help me!
Eduardo, your mail host (200.190.143.201) seems to have no PTR RR.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mr. Umemoto,
Sorry to bother you. I'm trying to send this e-mail to the mailing lis=
t but =
(although I'm subscribed) It just doesn't work. Could you please, relay=
this =
to the freebsd-net and freebsd-hackers list? I can receive any e-mails =
to the =
list but I can't send. =
Thanks a lot!
Eduardo.
- -- Forwarded Message --
Subject: (SIOCAIFADDR) Please help me!
Date: Sat, 7 Jul 2001 18:37:14 -0300
From: Eduardo B. Fonseca <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED], =
[EMAIL PROTECTED], [EMAIL PROTECTED]
Hello guys,
=A0=A0=A0=A0=A0=A0=A0=A0 Please... What's wrong with the code below? So=
metimes it works,
sometimes it doesn't. Yesterday, I've tested it and everything worked f=
ine...
Now, everytime I try to set the machine's IP address with this code, it=
does
not work... It sets a bogus IP, with a bogus netmask...
I'm stumped... I can't find documentation anywhere.
void
Interface::
AddAddressOnInterface(int sockfd, string ip, string netmsk, string broa=
daddr)
{
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 struct =A0=A0=A0=A0=A0=A0=
=A0=A0 ifaliasreq =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 request;
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 bzero (&request, sizeof(=
struct ifaliasreq));
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 strcpy(request.ifra_name=
,deviceName.c_str());
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 request.ifra_addr.sa_fam=
ily=A0=A0=A0=A0 =3D AF_INET;
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 inet_pton(AF_INET, ip.c_=
str(), &((struct sockaddr_in
*)&request.ifra_addr)->sin_addr);
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 inet_pton(AF_INET, netms=
k.c_str(), &((struct sockaddr_in
*)&request.ifra_mask)->sin_addr);
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 inet_pton(AF_INET, broad=
addr.c_str(), &((struct sockaddr_in
*)&request.ifra_broadaddr)->sin_addr);
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 ioctl(sockfd,SIOCAIFADDR=
,&request);
}
Thanks for any help.
Regards,
Eduardo.
- ---
- -- =
Eduardo B. Fonseca
Diretor Regional Curitiba
FutureNet Telecomunica=E7=F5es e Inform=E1tica Ltda
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE7R4QQf9aI6FhScUkRAqj4AJ9R83iKO+qQlzPvEun7tIWxgc+ERgCgrOqG
wK5nfbFrAKf2IHK+A93VLl4=3D
=3DJEsw
-END PGP SIGNATURE-
Re: cloning network interfaces
>>>>> On Fri, 22 Jun 2001 12:51:13 -0700
>>>>> Brooks Davis <[EMAIL PROTECTED]> said:
brooks> Ok, after a week and a half of doing other things, I've got a patch
brooks> together which adds interface cloning based on NetBSD's code. The
brooks> difference is that you may pass an interface of the from gif# if you
brooks> don't need a specific number. The ioctl now returns a potentialy
brooks> modified ifreq which contains the new interface name. This changes the
brooks> way drivers implement cloning in that they may return a different unit
brooks> then they were passed and they must do their own resource management
brooks> rather then relying on the clone functionality in sys/net/if.c to do it
brooks> for them.
brooks> The patch is at:
brooks> http://people.freebsd.org/~brooks/patches/gif.diff
brooks> The patch can be applied as follows (you need to make the directories):
brooks> cd /usr/src
brooks> mkdir sys/modules/if_gif sys/modules/if_stf
brooks> patch < /tmp/gif.diff
brooks> The patch does the following:
brooks> - adds interface cloning support to the kernel
brooks> - adds interface cloning support to ifconfig
brooks> - makes gif clonable
brooks> - makes gif usable as a module
brooks> - removes the need for NGIF and gif.h
brooks> - removes va_args usage in in_gif_input to remove a warning
brooks> - removes gif dependencies from stf
brooks> - makes stf usable as a module
It seems fine to me.
I just tried it on my box. You forget to include prototype change of
in_gif_input() in sys/net/if_gif.h.
BTW, why did you change gif_ioctl() to gif_ifioctl()? gif related
modules are shared among *BSDs and maintained in KAME CVS repository.
Could you please keep local changes small as possible?
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Status of encryption hardware support in FreeBSD
>>>>> On Fri, 22 Jun 2001 13:20:33 -0700
>>>>> Soren Kristensen <[EMAIL PROTECTED]> said:
soren> There has been some talks earlier about importing the OpenBSD code for
soren> encryption hardware support.
soren> As I now has prototypes avaliable of low cost PCI and MiniPCI boards,
soren> moving to production in a couple of weeks, I would like to check up on
soren> the work, as I would really like to see FreeBSD support. The boards are
soren> now supported in OpenBSD 2.9.
soren> Could the responsible person, or anybody who knows, please post or email
soren> a status ?
Because, FreeBSD's IPsec support comes from KAME, please contact to
KAME guys. [EMAIL PROTECTED] is good place.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: multiple pccard_ifconfig statements in one rc.conf ? Problems.
>>>>> On Thu, 21 Jun 2001 10:46:39 -0700
>>>>> Brooks Davis <[EMAIL PROTECTED]> said:
brooks> On Thu, Jun 21, 2001 at 05:24:29PM -, list tracker wrote:
> So what you are saying is that there _is not_ any way to perform multiple
> pccard_ifconfig statements solely in /etc/rc.conf ?
brooks> There's a method in -current, I'm not sure why it hasn't been MFC'd.
brooks> I'll put it on my todo list of no one else get's there first.
I believe it was already MFC'd. It seems working fine to me.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cloning network interfaces
>>>>> On Mon, 11 Jun 2001 14:20:31 -0700
>>>>> Brooks Davis <[EMAIL PROTECTED]> said:
brooks> On Sun, Jun 10, 2001 at 11:29:07PM +0900, Hajimu UMEMOTO wrote:
> I think it is not BSD network way. Recent NetBSD has network
> interface cloning. It uses SIOCIFCREATE and SIOCIFDESTROY. It may
> good to port it to FreeBSD.
brooks> I've looked it over and I generally like it. There is one problem
brooks> though. That's the requirement that you use static units. The problem
brooks> with this is that it forces you to implement free unit scanning in
brooks> userland if you just want to create a unit and don't care what it is.
brooks> If you have to do this, and things are being changed at any kind of
brooks> significant rate, you have race condition between scanning the
brooks> interface list for a free unit and trying to allocate it. This race can
brooks> theoreticaly lead to starvation.
I see.
brooks> My proposed solution is threefold. First, change the ifc_create pointer's
brooks> type to:
brooks> int (*ifc_create)(struct if_clone *, int *);
brooks> so you can return a unit if the caller requests a wildcard unit (by
brooks> passing -1). Second, move unit management in to the driver rather then
brooks> just using ifunit in if_clone_create. Drivers could choose to implement
brooks> wildcarding or not and if not could simply use ifunit for their test.
brooks> Third, make if_clone_lookup treat names like "gif#" as a wildcard
brooks> request and set unit to -1 as appropriate. These changes break
brooks> compatability with NetBSD slightly, but it's just a few lines to convert
brooks> an existing NetBSD clone_create handler to this style and it could
brooks> easily be handled with #ifdef's.
brooks> Thoughts, comments, objections?
I like your idea.
I'm serving tunnel broker using DTCP (Dynamic Tunnel Configuration
Protocol) in our ISP. So, I'm grad if we have dynamic gif creation,
too.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cloning network interfaces
Hi,
>>>>> On Fri, 8 Jun 2001 19:19:04 -0700
>>>>> Brooks Davis <[EMAIL PROTECTED]> said:
brooks> Following Brian's suggestion, I've modified gif to create a /dev/if_gif
brooks> device with is controlled by the IOCIFMANAGE ioctl which allows creation
brooks> and deletion of specific devices and creation of wildcard devices. I've
brooks> hacked ifconfig to support this in a general manner. If you know which
brooks> one you want to use you can do something like
I think it is not BSD network way. Recent NetBSD has network
interface cloning. It uses SIOCIFCREATE and SIOCIFDESTROY. It may
good to port it to FreeBSD.
brooks> ifconfig gif783 10.0.0.1 10.0.0.2
brooks> # gifconfig has to come second because I didn't add creation support to
brooks> # it because I want to kill it off in favor of ifconfig "tsrc" and
brooks> # "tdst" parameters like Solaris uses.
brooks> gifconfig gif783 blah
brooks> or if you don't care which one you use you can do
brooks> newgif=`ifconfig gif#`
brooks> gifconfig ${newgif} blah
brooks> ifconfig ${newgif} 10.0.0.1 10.0.0.2
brooks> You can also delete interfaces:
brooks> ifconfig -D gif783
NetBSD's ifconfig has `create' and `destroy' keyword for it.
You can create gif interface by
ifconfig gif0 create
or
ifconfig gif0 create tunnel 10.0.0.1 10.0.2.2
To destroy gif interface:
ifconfig gif0 destroy
BTW, gifconfig will be obsoleted soon as KAME and other BSDs did.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mozilla package dumps core
>>>>> On Sat, 21 Apr 2001 18:25:04 -0700 (PDT)
>>>>> Ian Kallen <[EMAIL PROTECTED]> said:
spidaman> Anyone noticed the mozilla-0.8.1 package core dumping on 4.2-RELEASE and
spidaman> have a fix for it?
You should upgrade your box to 4.3-RELEASE.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: good book or other source about socket programming
>>>>> On Sat, 24 Feb 2001 20:04:50 +0100
>>>>> "Marco van de Voort" <[EMAIL PROTECTED]> said:
marcov> I'm searching for a good book (or site/tutorial) about Unix socket
marcov> programming, preferably FreeBSD specific.
I recommend address family independent socket programming.
http://playground.iijlab.net/material/itojun-afisp-presen/
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: multiple IP addresses in /etc/hosts
>>>>> On Thu, 8 Feb 2001 18:51:50 +0200
>>>>> Peter Pentchev <[EMAIL PROTECTED]> said:
roam> I do not think that any of the applications in the base system have
roam> this ability. The only place I've seen it (and am using it in several
roam> home-grown apps) is in DJB's ucspi-tcp package (sysutils/ucspi-tcp, or
roam> http://cr.yp.to/ucspi-tcp.html), in the 'tcpclient' utility.
IPv6 aware applications in base system such as telnet, ssh... do
round-robbin so that it can be fall back to use IPv4 if IPv6
connection is fail.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: removing setgid kmem from top, collecting per-device swap stats
>>>>> On Thu, 1 Feb 2001 17:11:35 +
>>>>> Tony Finch <[EMAIL PROTECTED]> said:
dot> Thomas Moestl <[EMAIL PROTECTED]> wrote:
>
>Most kmem_read calls are easy to replace (the variables are already
>exported as sysctls), the only exception is nextproc (for which I might
>add a sysctl, or just leave it out [anyone out there who needs the
>lastpid display?]).
dot> It's useful for seeing how fast the machine is forking.
I beleive it's not meaningful if randompid is enabled. You can see
vm.stats.vm.v_[vr]?forks instead.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: When IPv6 Firewall was added to FreeBSD?
>>>>> On Wed, 17 Jan 2001 18:06:57 +0300
>>>>> "Andrey Simonenko" <[EMAIL PROTECTED]> said:
simon> When IPv6 Firewall was added to FreeBSD release? Please tell
simon> __FreeBSD_version of that release.
Since 4.0-RELEASE.
simon> I'm going to add IPv6 Firewall support to IP Accounting Daemon
simon> (ports/sysutils/ipa) and when I added it, I found out that there is bug in
simon> IPv6 Firewall implementation. I sent bug report kern/24248, but don't
simon> receive any answers on it. I think that this is bug, because I can block
simon> (lock) whole system with ip6fw command (how I did it on FreeBSD-4.1-STABLE
simon> and FreeBSD-4.2-STABLE is described in my bug report).
Sorry, I've mieesd to see it. I'll take a look it later.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
[CFR] number of processes forked since boot
Hi,
I received the patch to add counter for fork() set from Paul. I've
tested it on my -CURRENT and -STABLE boxes, and it seems fine for me.
So, I post his patch for review.
Thanks, Paul.
fork.patch.gz
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
number of processes forked since boot
Hi,
I wish to obtain number of processes forked since boot from userland.
So, I made a patch to intend to commit.
Any comment?
Index: lib/libc/gen/sysctl.3
diff -u lib/libc/gen/sysctl.3.orig lib/libc/gen/sysctl.3
--- lib/libc/gen/sysctl.3.orig Fri Jan 12 02:39:22 2001
+++ lib/libc/gen/sysctl.3 Tue Jan 16 02:13:19 2001
@@ -294,6 +294,7 @@
.It "KERN\_UPDATEINTERVAL integer no"
.It "KERN\_VERSION string no"
.It "KERN\_VNODE struct vnodeno"
+.It "KERN\_NFORKS integer no"
.El
.Pp
.Bl -tag -width 6n
@@ -445,6 +446,8 @@
.Va struct vnode *
followed by the vnode itself
.Va struct vnode .
+.It Li KERN_NFORKS
+Number of processes forked.
.El
.Ss CTL_MACHDEP
The set of variables defined is architecture dependent.
Index: sbin/sysctl/sysctl.8
diff -u sbin/sysctl/sysctl.8.orig sbin/sysctl/sysctl.8
--- sbin/sysctl/sysctl.8.orig Fri Jan 12 02:42:23 2001
+++ sbin/sysctl/sysctl.8Tue Jan 16 02:13:19 2001
@@ -145,6 +145,7 @@
.It "kern.bootfile string yes
.It "kern.corefile string yes
.It "kern.logsigexit integer yes
+.It "kern.nforks integer no
.It "vm.loadavgstruct no
.It "hw.machinestring no
.It "hw.model string no
Index: sys/kern/kern_fork.c
diff -u sys/kern/kern_fork.c.orig sys/kern/kern_fork.c
--- sys/kern/kern_fork.c.orig Fri Jan 12 02:46:53 2001
+++ sys/kern/kern_fork.cTue Jan 16 02:30:26 2001
@@ -146,6 +146,9 @@
intnprocs = 1; /* process 0 */
static int nextpid = 0;
+static unsigned int nforks = 0;
+SYSCTL_UINT(_kern, KERN_NFORKS, nforks, CTLFLAG_RD, &nforks, 0, "");
+
/*
* Random component to nextpid generation. We mix in a random factor to make
* it a little harder to predict. We sanity check the modulus value to avoid
@@ -277,6 +280,8 @@
}
newproc->p_vmspace = NULL;
+
+ nforks++;
/*
* Find an unused process ID. We remember a range of unused IDs
Index: sys/sys/sysctl.h
diff -u sys/sys/sysctl.h.orig sys/sys/sysctl.h
--- sys/sys/sysctl.h.orig Fri Jan 12 02:48:41 2001
+++ sys/sys/sysctl.hTue Jan 16 02:13:19 2001
@@ -328,7 +328,8 @@
#defineKERN_PS_STRINGS 32 /* int: address of PS_STRINGS */
#defineKERN_USRSTACK 33 /* int: address of USRSTACK */
#defineKERN_LOGSIGEXIT 34 /* int: do we log sigexit procs? */
-#define KERN_MAXID 35 /* number of valid kern ids */
+#define KERN_NFORKS35 /* uint: number of forked */
+#define KERN_MAXID 36 /* number of valid kern ids */
#define CTL_KERN_NAMES { \
{ 0, 0 }, \
@@ -366,6 +367,7 @@
{ "ps_strings", CTLTYPE_INT }, \
{ "usrstack", CTLTYPE_INT }, \
{ "logsigexit", CTLTYPE_INT }, \
+ { "nforks", CTLTYPE_UINT }, \
}
/*
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Import and merge of TI-RPC from NetBSD
>>>>> On Fri, 15 Dec 2000 10:42:45 +0100 (CET)
>>>>> Martin Blapp <[EMAIL PROTECTED]> said:
mb> I'd like to import the NetBSD RPC-Interface, based on Sun's TI-RPC code.
Oh, it's great! I heared TI-RPC is required to support IPv6 for NFS.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: New 4.2 complaint.
>>>>> On Mon, 4 Dec 2000 10:16:29 -0600
>>>>> "Chuck Rock" <[EMAIL PROTECTED]> said:
carock> I just upgraded our main server to 4.2
carock> I would like to know why nslookup is complaining about being deprecated and
carock> may be removed from future releases. (why someone would remove it)
I guess you are using BIND9 version of nslookup. It's not a FreeBSD
shipped version.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Testers wanted: nsswitch
>>>>> On Sat, 19 Aug 2000 16:30:17 -0500 >>>>> "Jacques A. Vidrine" <[EMAIL PROTECTED]> said: n> I've made a port of NetBSD's nsswitch code. This allows one to n> configure various databases such as passwd(5) to use files, NIS, n> or Hesiod. I like bringing nsswitch into FreeBSD. It will reduce maintainance cost around resolver related routins. When I merged KAME effort around fixing DNS query order problem from NetBSD, I was forced to work with nsswitch -> host.conf issue. Your nsswith support in getaddrinfo.c is quite different from NetBSD's one. (maybe name6.c, too?) Why don't you simply bring the code from NetBSD? The origin of getadrinfo.c and name6.c is KAME, and basically these files are same between NetBSD and FreeBSD except some OS depend part such as reading host.conf. We should keep close these files to NetBSD as possible. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: localhost cannot be resolved
>>>>> On Sat, 12 Aug 2000 10:47:43 -0400 (EDT) >>>>> Alexander Anderson <[EMAIL PROTECTED]> said: > Which version of FreeBSD are you using? cactoss> 4.0-RELEASE Please update to 4.1-RELEASE. 4.0-RELEASE's getaddrinfo(3) has DNS query order problem and it was fixed in 4.1-RELEASE. Or, at least you should update libc/net/getaddrinfo.c and libc/net/name6.c I don't know why getaddrinfo(3) fails for localhost query, exactly. However, probably updating to 4.1-RELEASE fixes your problem. cactoss> I tried to look at the sources for telnet. In file commands.c:2292, there's cactoss> an assignment of variable "family". I couldn't understand where the variable cactoss> is coming from. The variable `family' is came from command line of telnet. If -4 is specified, telnet tries only AF_INET. If -6 is specified, telnet tries only AF_INET6. Default is AF_UNSPEC, that is try both IPv6 and IPv4. cactoss> Could you please take a look at `ifconfig lo0`: cactoss> lo0: flags=8049 mtu 16384 cactoss>inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 cactoss>inet6 ::1 prefixlen 128 cactoss>inet 127.0.0.1 netmask 0xff00 cactoss> Does it look okay? It seems fine. cactoss> One question. Firewall rules apply to both IPv4 and IPv6, right? There cactoss> shouldn't be separate rules to IPv6, should there? No. Rules for IPv6 is set separately by ip6fw. Firewall for IPv6 is enabled by specifying `options IPV6FIREWALL' in your kernel config. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: localhost cannot be resolved
>>>>> On Fri, 11 Aug 2000 21:57:50 -0400 (EDT) >>>>> Alexander Anderson <[EMAIL PROTECTED]> said: cactoss> I'm having trouble resolving "localhost" for telnet and fetchmail. All cactoss> other programs (ftp, rlogin, rsh, ping, lynx) seem to understand cactoss> "localhost". Which version of FreeBSD are you using? cactoss> I'm going to include my configuration files. Please tell me if you'd like cactoss> to get more info on something. cactoss> > cat /etc/hosts cactoss> 127.0.0.1 localhost localhost.my.domain myname.my.domain cactoss> ::1 localhost localhost.my.domain myname.my.domain cactoss> > cat /etc/host.conf cactoss> hosts cactoss> bind cactoss> > cat /etc/resolv.conf cactoss> nameserver 209.226.175.224 cactoss> nameserver 204.101.251.2 cactoss> All looks right, does it? It seems right for me. cactoss> Now, when I run telnet or fetchmail, they complain. > telnet localhost cactoss> localhost: No address associated with hostname > echo $? cactoss> 1 It seems getaddrinfo(3) was failed. What's curious. Rlogin, rsh and ftp call getaddrinfo(3), too. Why is it only telnet and fetchmail? cactoss> > fetchmail cactoss> 9 messages for MYUSERNAME at pop.mail.yahoo.com (64648 octets). cactoss> reading message 1 of 9 (13403 octets) .fetchmail: SMTP connect to cactoss> localhost failed cactoss> fetchmail: SMTP transaction error while fetching from pop.mail.yahoo.com cactoss> fetchmail: Query status=SMTP > echo $? cactoss> 10 cactoss> At the same time fetchmail causes ipfw to produce these messages: cactoss> Aug 11 21:41:47 mydomain /kernel: Connection attempt to TCP ::0001:25 from cactoss> ::0001:1063 cactoss> Aug 11 21:41:47 mydomain /kernel: Connection attempt to TCP 127.0.0.1:113 cactoss> from 127.0.0.1:1065 cactoss> Aug 11 21:41:47 mydomain /kernel: Connection attempt to TCP ::0001:25 from cactoss> ::0001:1066 cactoss> Aug 11 21:41:47 mydomain /kernel: Connection attempt to TCP 127.0.0.1:113 cactoss> from 127.0.0.1:1067 You don't have SMTP/IPv6 listen. This should be OK. So, SMTP connection to ::1 was fail. Then, SMTP connection to 127.0.0.1 was tried. It seems IDENT query was made in correspondings to SMTP connection to 127.0.0.1. I think you have SMTP/IPv4 listen. cactoss> Actually, could someone tell me, what does ::0001 mean? Should this be in cactoss> /etc/hosts with an alias of localhost? ::0001 is same as ::1. Leading zero can be omittled in IPv6 address format. cactoss> These strange things started to happen soon after I cvsup'ed ports-all and cactoss> reinstalled libtool. I also compiled firewall support into the kernel a cactoss> few days ago. Just in case any of this might be related to the problem. I think libtool has no relation with this problem. It may rely on firewall rule. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl interface for apm?
>>>>> On Mon, 17 Jul 2000 13:45:29 -0600 >>>>> Warner Losh <[EMAIL PROTECTED]> said: imp> It is sufficient for APMIO_GETINFO, but it will introduce a security imp> hole as the apm ioctls aren't careful enough about their sanity imp> checking. I've added such sanity checking in my local copy of apm and imp> will test it tonight when I have access to my laptop. imp> The holes are introduced by the chmod 664 /dev/apm, not by doing the imp> open rdonly :-). Oh, I see. It's a security hole. imp> If you'll send me a pointer to gkrellm, I'll see about putting it up imp> on my laptop and making sure that my stuff works with it. ports/sysutils/gkrellm/ :-) -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl interface for apm?
>>>>> On Mon, 17 Jul 2000 13:14:24 -0600 >>>>> Warner Losh <[EMAIL PROTECTED]> said: imp> In message <[EMAIL PROTECTED]> Hajimu UMEMOTO writes: imp> : nsayer> The "why bother" is easy -- one should not have to belong to group imp> : nsayer> operator to determine the current battery state. Too many things imp> : nsayer> already have to be sgid (at least) without making this another reason. imp> : I love this feature. imp> Don't worry, he's not going to change this feature. I use it and will imp> fix it back if someone "breaks" it.. I means sysctl doesn't require extra privilege to obtain required information. Sorry for my ambiguity. imp> : nsayer> I took a middle ground. I have two ints, machdep.apm_battlevel imp> : nsayer> and machdep.apm_powerstate. The power state number is imp> : nsayer> -1 to 5 for unknown, critical, low, medium, high (which four imply imp> : nsayer> battery power), AC or charging (which two imply AC power). imp> : imp> : Then, I cannot switch to use sysctl. Actually, GKrellM requires imp> : ai_batt_stat, ai_acline, ai_batt_life and ai_batt_time members of imp> : struct apm_info. imp> Yes. The right answer isn't to kludge this through a sysctl, but imp> instead it is to fix apm to that it is safe to make it world read imp> only. Is there a way inside a ioctl to see if you have something open imp> for write access? Indeed, I wish to have a method to obtain required information without extra privilege. We need safety way. Currentry, GKrellM opens /dev/apm with O_RDWR. I just tried to open with O_RDONLY and see it is sufficient for APMIO_GETINFO. I'll send the change to the author of GKrellM. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl interface for apm?
>>>>> On Mon, 17 Jul 2000 11:15:18 -0700 >>>>> Nick Sayer <[EMAIL PROTECTED]> said: nsayer> The "why bother" is easy -- one should not have to belong to group nsayer> operator to determine the current battery state. Too many things nsayer> already have to be sgid (at least) without making this another reason. I love this feature. nsayer> I took a middle ground. I have two ints, machdep.apm_battlevel nsayer> and machdep.apm_powerstate. The power state number is nsayer> -1 to 5 for unknown, critical, low, medium, high (which four imply nsayer> battery power), AC or charging (which two imply AC power). Then, I cannot switch to use sysctl. Actually, GKrellM requires ai_batt_stat, ai_acline, ai_batt_life and ai_batt_time members of struct apm_info. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.imasy.org/~ume/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
