getnetbyname broken for DNS case?
Hi, I am trying to debug a problem that I have with /etc/exports. I cannot put in the symbolic name for my network (10.26.0.0) without putting it in /etc/networks. It is currently in DNS, but it looks like the getnetbyname is not working correctly for the DNS case. The functions that are broken is _getnetbydnsname() and getnetanswer(). The _getnetbydnsname() is easily fixed by changing T_PTR to T_A in res_query(), but getnetanswer() is harder to solve. It is not parsing the format of the result correctly. First I had to put some code in to test "type" being T_PTR only if "net_i" is set to BYADDR and T_A if "net_i" is set to BYNAME. When I go into the res_hnok() test, it is assumed by the code that it IP address is in ascii format, which it is not (it is in network binary order). If I remove the res_hnok() test, then it does not load the netent.n_net address correctly. The code is broken for both -CURRENT and -STABLE. So my question is then, can I rewrite getnetbyname() to use gethostbyname() call and massage the result to a netent entry? This would solve the DNS result parsing problem and would also get us T_AAA (IPv6) network name addresses. I would also implement getnetbyaddr() in terms of gethostbyaddr() too. - JimP --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o [EMAIL PROTECTED] --- _'\<,_ (*)/ (*) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: SMP strange behaviour [HELP]
I tries it , but it does not solve the problem however when doing this I noticed the lge0 interface goes down because when I do an ifconfig lge0 up I can log in again on the lge0 interface. Any other ideas ? On Tue, 17 Sep 2002 13:13:48 -0400 Barney Wolff <[EMAIL PROTECTED]> wrote: > Do (as root) > sysctl net.inet.tcp.path_mtu_discovery=0 > on the side sending the big data and see if the problem goes away. > tcpdump -v should show the DF flag set if pmtud is in use. > > On Tue, Sep 17, 2002 at 06:29:21PM +0200, Christophe Prevotaux wrote: > > uhmm how can i find out about this ? > > When I do a tcpdump I see nothing related to this > > > > I will use ethereal to look at it and I'll let you know > > -- > Barney Wolff > I'm available by contract or FT: http://www.databus.com/bwresume.pdf > -- -- === Christophe Prevotaux Email: [EMAIL PROTECTED] HEXANET SARLURL: http://www.hexanet.fr/ Z.A.C Les CharmillesTel: +33 (0)3 26 79 30 05 3 Allée Thierry Sabine Direct: +33 (0)3 26 61 77 72 BP202 Fax: +33 (0)3 26 79 30 06 51686 Reims Cedex 2 FRANCE HEXANET Network Operation Center === To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
socket buffers
I played around adjusting udp socket buffers for a while and noticed that if the input buffer is set to a value, packets start getting dropped when npkt*MTU > SO_RCVBUF so if a socket receives 100 byte packets over an ethernet interface of 1500 byte MTU and receive buffer of 100k the packets start dropping at less than 10k received data in a buffer. Is this a feature or a bug? I'm running RELENG_4 from a few weeks ago. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: socket buffers
On Wednesday, September 18, 2002, at 08:03 AM, Petri Helenius wrote: > > I played around adjusting udp socket buffers for a while and noticed > that if the input buffer is set to a value, packets start getting > dropped > when npkt*MTU > SO_RCVBUF so if a socket receives 100 byte packets over > an ethernet interface of 1500 byte MTU and receive buffer of 100k the > packets > start dropping at less than 10k received data in a buffer. This is, I think, normal behavior. Check Wright/Stevens (TCP/IP Illustrated, V2), Ch. 2, where this is discussed (as I recall). A socket buffer counts not only the valid data bytes enqueued, but also the size of the mbufs used. The reasoning is clear: in order to avoid having all the mbufs in the system end up on a single queue, because very small packets are being received, counting mbuf space limits the number of mbufs that can be sucked up by one direction for one socket. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| It's not whether you win or lose... | It's whether *I* win or lose. *--*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
MPD as a PPTP server
I am not currently on freebsd-net so if you could cc me in replies it would be appreciated. I have a FreeBSD 4.6.2-RELEASE running mpd 3.9 serving as a PPTP server. I have setup PPTP boxes using MPD before but have run into a problem this time. In the past I would use set ipcp ranges 1.2.3.4/32 192.168.1.100/32 where 1.2.3.4 was the external interface of the machine. This worked with multiple links under 3.7, but doesn't seem to under 3.9 Do I have to set a different address for every client connection in tehe first part of the ipcp ranges like this? set ipcp ranges 192.168.1.1/32 192.168.1.100/32 set ipcp ranges 192.168.1.2/32 192.168.1.101/32 and if so, do the first addresses have to corespond to an existing interface requiring me to alias the interface with more than 1 IP. TIA [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
More on MPD PPTP problem
Please cc me on responses sorry fo rthe second post, I realised afterwards I should be posting logs and configs if i am going to ask people for help with the problem. It seems as though I can only setup mpd to listen for one inbound connection. No ng interfaces are present prior to initializing mpd, which I make sure of using ngctl when the links are not shutdown after killing mpd. In the mpd.conf file I have posted below, I have used both the 172.22.4.1/32 address listed and 1.2.3.4/32 as the first number in the ipcp ranges statement. I get the same result each time. 172.22.4.1/32 is an actual interface on the machine. Here is a snip from my log file to show the problem I am having Sep 18 14:21:34 gw mpd: mpd: pid 37673, version 3.9 (root@localhost 18:08 12-Sep-2002) Sep 18 14:21:34 gw mpd: [moveable1] ppp node is "mpd37673-moveab" Sep 18 14:21:34 gw mpd: mpd: local IP address for PPTP is 1.2.3.4 Sep 18 14:21:34 gw mpd: [moveable1] using interface ng0 Sep 18 14:21:34 gw mpd: [moveable2] can't name ppp node: Address already in use Sep 18 14:21:34 gw mpd: [moveable2] netgraph initialization failed Sep 18 14:21:34 gw mpd: [moveable3] can't name ppp node: Address already in use Sep 18 14:21:34 gw mpd: [moveable3] netgraph initialization failed Sep 18 14:21:34 gw mpd: [moveable4] can't name ppp node: Address already in use Sep 18 14:21:34 gw mpd: [moveable4] netgraph initialization failed Sep 18 14:21:34 gw mpd: [moveable5] can't name ppp node: Address already in use Sep 18 14:21:34 gw mpd: [moveable5] netgraph initialization failed My mpd.links file moveable1: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate moveable2: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate moveable3: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate moveable4: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originate moveable5: set link type pptp set pptp self 1.2.3.4 set pptp enable incoming set pptp disable originatedefault: and my mpd.conf file default: load moveable1 load moveable2 load moveable3 load moveable4 load moveable5 moveable1: new -i ng0 moveable1 moveable1 set ipcp ranges 172.22.4.1/32 172.22.4.105/32 load client_standard moveable2: new -i ng1 moveable2 moveable2 set ipcp ranges 172.22.4.1/32 172.22.4.106/32 load client_standard moveable3: new -i ng2 moveable3 moveable3 set ipcp ranges 172.22.4.1/32 172.22.4.107/32 load client_standard moveable4: new -i ng3 moveable4 moveable4 set ipcp ranges 172.22.4.1/32 172.22.4.108/32 load client_standard moveable5: new -i ng4 moveable5 moveable5 set ipcp ranges 172.22.4.1/32 172.22.4.109/32 load client_standard client_standard: set iface disable on-demand set iface enable proxy-arp set iface route 172.22.16.0/23 set iface idle 1800 set bundle enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link mtu 1460 set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 172.22.4.51 set bundle enable compression set ccp yes mppc set bundle enable crypt-reqd set ccp yes mpp-e128 set ccp yes mpp-stateless Any hints? Cheers, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Broken IPv4 in IPv6 on -current?
FreeBSD femme.sapphite.org 5.0-CURRENT FreeBSD 5.0-CURRENT #16: Mon Sep 9 10:23:22 EDT 2002 [EMAIL PROTECTED]:/admins/obj/admins/src/sys/FEMME i386 foo.c: #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { struct sockaddr_in6 addr; struct hostent *hostinfo; int sock; memset(&addr, 0, sizeof(struct sockaddr_in6)); addr.sin6_addr = in6addr_any; addr.sin6_family = AF_INET6; if(argc < 2) return 0; hostinfo = gethostbyname2(argv[1], AF_INET6); memcpy((char *)&addr.sin6_addr, hostinfo->h_addr, hostinfo->h_length); addr.sin6_family = hostinfo->h_addrtype; addr.sin6_port = htons((u_short)); sock = socket(AF_INET6, SOCK_STREAM, 0); bind(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr_in6)); listen(sock, 5); sleep(60); return 0; } femme:~#strace ./foo :::127.0.0.1 execve(0xbfbff5c0, [0xbfbffaa4], [/* 0 vars */]) = 0 mmap(0, 2664, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2805f000 munmap(0x2805f000, 2664)= 0 __sysctl([...], 0x2805e4c8, 0xbfbff864, NULL, 0) = 0 mmap(0, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0x2805f000 geteuid(0) = 0 getuid()= 0 (euid 0) getegid(0) = 0 getgid()= 0 (egid 0) open("/var/run/ld-elf.so.hints", O_RDONLY) = 3 read(3, "ins/src/libexec/rtld-elf/rtld.c:"..., 128) = 128 lseek(3, 549755813888, SEEK_SET)= 128 read(3, "/usr/lib:/usr/lib/compat:/usr/X1"..., 145) = 145 close(3)= 0 access("/usr/lib/libc.so.5", F_OK) = 0 open("/usr/lib/libc.so.5", O_RDONLY)= 3 fstat(3, {st_mode=0, st_size=0, ...}) = 0 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096 mmap(0, 741376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x28067000 mmap(0x28103000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x9b000) = 0x28103000 mmap(0x28108000, 81920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0x28108000 close(3)= 0 mmap(0, 184, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2811c000 munmap(0x2811c000, 184) = 0 mprotect(0x28067000, 638976, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mmap(0, 18856, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2811c000 munmap(0x2811c000, 18856) = 0 mprotect(0x28067000, 638976, PROT_READ|PROT_EXEC) = 0 sigaction(SIGILL, {SIG_DFL}, {SIG_DFL}) = 0 sigprocmask(SIG_BLOCK, NULL, [])= 0 sigaction(SIGILL, {SIG_DFL}, NULL) = 0 sigprocmask(SIG_BLOCK, ~[ILL TRAP ABRT EMT FPE BUS SEGV SYS], []) = 0 sigprocmask(SIG_SETMASK, [], NULL) = 0 stat("/etc/nsswitch.conf", {st_mode=S_IFBLK|S_ISGID|0554, st_rdev=makedev(40, 2037645344), ...}) = 0 open("/etc/nsswitch.conf", O_RDONLY)= 3 readlink("/etc/malloc.conf", 0xbfbff830, 63) = -1 ENOENT (No such file or directory) mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0x2811c000 break(0x804b000)= 0 break(0x804c000)= 0 break(0x804d000)= 0 break(0x804e000)= 0 break(0x804f000)= 0 ioctl(3, TIOCGETA, 0xbfbff800) = -1 ENOTTY (Inappropriate ioctl for device) fstat(3, {st_mode=0177350, st_size=18446461400436899560, ...}) = 0 break(0x8051000)= 0 read(3, "hosts: files dns \n", 8192)= 18 read(3, "", 8192) = 0 break(0x8052000)= 0 break(0x8053000)= 0 ioctl(3, TIOCGETA, 0xbfbff7f0) = -1 ENOTTY (Inappropriate ioctl for device) close(3)= 0 open("/etc/hosts", O_RDONLY)= 3 gettimeofday({1869638985, 1651078003}, NULL) = 0 getpid()= 97560 (ppid 97559) issetugid(0x7ae)= 0 open("/etc/resolv.conf", O_RDONLY) = 4 fstat(4, {st_mode=S_IFBLK|S_ISGID|0566, st_rdev=makedev(114, 543490165), ...}) = 0 read(4, "search sapphite.org\nnameserver 6"..., 8192) = 86 read(4, "", 8192) = 0 close(4)= 0 issetugid(0x7ae)= 0 fstat(3, {st_mode=0150320, st_size=15046755950319947984, ...}) = 0 read(3, "# $FreeBSD: src/etc/hosts,v 1.11"..., 8192) = 1360 read(3, "", 8192) = 0 close(3)= 0 socket(PF_INET6, SOCK_STREAM, 0)= 3 bind(3, {sin_family=0xd0 /* AF_??? */, {sa_family=208, sa_data="\320\320\320\320\320\320\320\320\320\320\320\320\320\320"...}, 28) = -1 EADDRNOTAVAIL (Can't assign requested address) listen(3, 5)= 0 nanosleep(0xbfbff9f8, 0xbfbff9f0^C its pretty bizarre -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] Key f
Broken IPv4 in IPv6 on -current (addendum)
THis works fine on DP-1. So it broke somewhere between then and now. -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
ipv4 in ipv6 issue solved
sysctl net.inet6.ip6.v6only=0 -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ipv4 in ipv6 issue solved
> On Wed, 18 Sep 2002 21:44:33 -0400 (EDT), > Trish Lynch <[EMAIL PROTECTED]> said: > sysctl net.inet6.ip6.v6only=0 This should also work: *** foo.c.orig Thu Sep 19 12:05:04 2002 --- foo.c Thu Sep 19 12:05:56 2002 *** *** 14,19 --- 14,20 struct sockaddr_in6 addr; struct hostent *hostinfo; int sock; + int off; memset(&addr, 0, sizeof(struct sockaddr_in6)); *** *** 30,35 --- 31,40 addr.sin6_port = htons((u_short)); sock = socket(AF_INET6, SOCK_STREAM, 0); + #ifdef IPV6_V6ONLY + off = 0; + setsockopt(sock, IPPROTO_IPV6, &off, sizeof(off)); + #endif bind(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr_in6)); listen(sock, 5); I'd recommend this approach rather than to use sysctl, particularly for new applications built from the scratch, because we can control the policy per-socket basis. You may have to note that draft-ietf-ipngwg-rfc2553bis-06.txt specifies 0 as the default value of the option while FreeBSD does not follow the specification. Even though the clear specification, there is a certain amount of stack developers who have a different opinion on this and intentionally reverse the default. So, the safest way is to set the value explicitly. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Network Transfer Speed Issues - Tweaks/Advice?
I really appreciate everyone who offered up a few ideas and answers. One of the first things I finally figured out was that the adapter was failing... hmmm doesn't make sense - it didn't fail completely, but I swapped it out with a different adapter (same thing 2940UW) and the performance change was quite remarkable. That still didn't solve the huge discrepancy in speed difference between my other SCSI (internal) drives and the ones I am working with, however. My next test will be to build a system from the ground up w/ a 500 MHz processor and a 133 MHz FSB. I am also wondering if I really missed the boat on the drives, too. They are "older" 5400 RPM SCSI drives (HUGE drives physically) but I don't see how they would be any slower than an IDE 5400 RPM drive - which they are and quite a bit so. As for all of the other stuff, the CPU load is usually at a steady 15% (nfsd). Since that is the only service running (besides the required daemons on a somewhat vanilla system) and the only load that the "server" is under, I don't think that is an issue. I am going to test system performance with the suggested programs (that was another thing I was looking for in the answer, although I guess I didn't say it...) and see what happens. I am starting to think that this is a combination of controller and system not having the performance I was expecting. Everything on the net end seems to be functioning without problem - no lost packets, broken communication, etc. Well, the testing goes on. Please continue to comment if you have any ideas (especially with regards to kernel tweaks, etc). Thanks, Steve On Tuesday, September 17, 2002, at 07:55 , David Burns wrote: > Steve Fettig wrote: >> I recently set up an NFS server to run daily backups on. The server >> was built using an old P150 w/ 90 MB of ram and a 6GB hard drive. >> (All servers in this experiment are set up using FBSD 4.6.2 and the >> client is a Mac PowerBook G4 running Mac OS X.) Attached to it is an >> external SCSI hard drive enclosure with 4 47GB SCSI drives running off >> an AHA-2490UW SCSI adapter. I am getting really odd performance when >> doing an NFS transfer (I also get odd performance out of scp) from the >> machine I am trying to back up. I will get a burst of 20Mbps for >> about 30 seconds, then it will ramp down to 1 Mbps for about 2 >> minutes, ramp backup to 20 Mbps, then back down to 1 Mbps and so on. > You need to break the problem down ... Is the system CPU and/or IO > bound during the backup? Also try some quick benchmarks to verify basic > system performance levels: Network IO - use ttcp (or netperf etc), and > Disk IO - use bonnie (or similar). > > NB Of course you can't simply take such benchmarks results and put them > together - but you will gain a better understanding of where the > potential slowdowns may be. > > Lastly, performance issues on older Pentiums can also result from poor > memory bandwidth and/or PCI chipset problems. I recently replaced a > P120 with a Celeron 333 - the performance improvement was surprising. > > Regards, > David > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Network Transfer Speed Issues - Tweaks/Advice?
Steve, your setup is way to complex. As David suggested, first try to establish whether the network connection between the two machines is the problem or not. Forget about NFS for now, just benchmark TCP and UDP (which do you NFS mount over, by the way?) If network performance is erratic, isolate the setup from cross traffic, and swap out NICs, hubs and or switches. Only after you've ruled out the network would I start worrying about disks, controllers and NFS settings. The idea here is to change ONE parameter in the setup at a time, and rerun your benchmark of choice. Steve Fettig wrote: > I really appreciate everyone who offered up a few ideas and answers. > One of the first things I finally figured out was that the adapter was > failing... hmmm doesn't make sense - it didn't fail completely, but I > swapped it out with a different adapter (same thing 2940UW) and the > performance change was quite remarkable. That still didn't solve the > huge discrepancy in speed difference between my other SCSI (internal) > drives and the ones I am working with, however. My next test will be to > build a system from the ground up w/ a 500 MHz processor and a 133 MHz > FSB. I am also wondering if I really missed the boat on the drives, > too. They are "older" 5400 RPM SCSI drives (HUGE drives physically) but > I don't see how they would be any slower than an IDE 5400 RPM drive - > which they are and quite a bit so. > As for all of the other stuff, the CPU load is usually at a steady 15% > (nfsd). Since that is the only service running (besides the required > daemons on a somewhat vanilla system) and the only load that the > "server" is under, I don't think that is an issue. I am going to test > system performance with the suggested programs (that was another thing I > was looking for in the answer, although I guess I didn't say it...) and > see what happens. I am starting to think that this is a combination of > controller and system not having the performance I was expecting. > Everything on the net end seems to be functioning without problem - no > lost packets, broken communication, etc. > > Well, the testing goes on. Please continue to comment if you have any > ideas (especially with regards to kernel tweaks, etc). > > Thanks, > Steve > > On Tuesday, September 17, 2002, at 07:55 , David Burns wrote: > >> Steve Fettig wrote: >> >>> I recently set up an NFS server to run daily backups on. The server >>> was built using an old P150 w/ 90 MB of ram and a 6GB hard drive. >>> (All servers in this experiment are set up using FBSD 4.6.2 and the >>> client is a Mac PowerBook G4 running Mac OS X.) Attached to it is an >>> external SCSI hard drive enclosure with 4 47GB SCSI drives running >>> off an AHA-2490UW SCSI adapter. I am getting really odd performance >>> when doing an NFS transfer (I also get odd performance out of scp) >>> from the machine I am trying to back up. I will get a burst of >>> 20Mbps for about 30 seconds, then it will ramp down to 1 Mbps for >>> about 2 minutes, ramp backup to 20 Mbps, then back down to 1 Mbps and >>> so on. >> >> You need to break the problem down ... Is the system CPU and/or IO >> bound during the backup? Also try some quick benchmarks to verify >> basic system performance levels: Network IO - use ttcp (or netperf >> etc), and Disk IO - use bonnie (or similar). >> >> NB Of course you can't simply take such benchmarks results and put >> them together - but you will gain a better understanding of where the >> potential slowdowns may be. >> >> Lastly, performance issues on older Pentiums can also result from poor >> memory bandwidth and/or PCI chipset problems. I recently replaced a >> P120 with a Celeron 333 - the performance improvement was surprising. >> >> Regards, >> David >> > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature