Date: Wed, 8 Jan 1997 22:49:01 +0100 (MET) From: grog@lemis.de To: peter@spinner.DIALix.COM (Peter Wemm) Cc: FreeBSD-current@FreeBSD.ORG (FreeBSD current users) Subject: Re: What's happened to nfsd and mountd? Message-ID: <199701082149.WAA07770@freebie.lemis.de> In-Reply-To: <199701082034.EAA06856@spinner.DIALix.COM> from Peter Wemm at "Jan 9, 97 04:34:34 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm writes:
> Bill Paul wrote:
>> Of all the gin joints in all the towns in all the world, Peter Wemm had
>> to walk into mine and say:
>>
>> [nfsd/mountd are fubared]
>>
>>>> It's most likely something in the RPC library in libc, not in the program
> s.
>>>
>>> The first thing that springs to mind is that it looks like it's happening
>>> here in clnt_udp.c:
>>> if (sendto(cu->cu_sock, cu->cu_outbuf, outlen, 0,
>>> (struct sockaddr *)&(cu->cu_raddr), cu->cu_rlen) != outlen) {
>>> cu->cu_error.re_errno = errno;
>>> if (fds != &readfds)
>>> free(fds);
>>> return (cu->cu_error.re_status = RPC_CANTSEND);
>>> }
>>>
>>> In this case, it looks to me like the socket is created and bound
>>> correctly, Hmm, I'll dig into it some more.
>>
>> I would be more inclined to check pmap_set() or get_myaddress(). (I think
>> you did frob get_myaddress().)
>
> Yes, but nothing that is likely to cause this problem. Before, it used to
> get the address of the first interface, which was a bit non-determinate.
> It could either be a loopback or real interface. The change was to make
> it return a "real" address always, but if none exist, it falls back to a
> loopback address.
Hmmm. I was going to complain about what Bill said, but now I'm not
so sure... Yes, I may have a few more interfaces than most people.
Let's see. tcpdump also goes for the first interface...
=== root@freebie (/dev/ttyp6) /var/spool/mqueue 69 -> tcpdump
tcpdump: listening on ep0
Looks good to me. How do I find the interface that get_myaddress is
attacking?
> get_myaddress() copies the entire sockaddr_in out from the SIOCGIFCONF
> data. Perhaps something is getting spammed there? pmap_set() uses that
> to create the address for the udp transport.
>
> For what it's worth, nfsd/mountd work for me. I just did a 'make world'
> and restarted all my rpc/yp/nfs*/etc and it seems to work fine still. I
> have not yet booted a new kernel after the if.h/if_var.h/etc changes from
> a little while back.
Well, I didn't expect it to be broke for everybody, or somebody else
would have complained first.
>> It would also help if we knew if these people
>> are doing funky things with virtual interfaces or multihomed hosts. (This
>> information is important people! When you describe a problem, you should
>> go into _excrutiating_ detail. What may seem unimportant to you may speak
>> volumes to us.)
>
> Agreed.. an 'ifconfig -a' would be useful.
=== root@freebie (/dev/ttyp6) /var/spool/mqueue 70 -> ifconfig -a
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
ep0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.109.197.137 netmask 0xffffff00 broadcast 192.109.197.255
ether 00:a0:24:37:0d:2b
ipi0: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.137 --> 194.163.31.4 netmask 0xffffffc0
ipi1: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.137 --> 194.64.112.1 netmask 0xffffff00
ipi2: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.137 --> 194.163.31.129 netmask 0xffffffc0
ipi3: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.37 --> 192.109.197.38 netmask 0xffffff00
ipi4: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.148 --> 194.77.2.34 netmask 0xffffff00
ipi5: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.137 --> 194.163.31.1 netmask 0xffffffc0
ipi6: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 192.109.197.137 --> 192.129.52.242 netmask 0xffffff00
ipi7: flags=810<POINTOPOINT,SIMPLEX> mtu 1500
ipi8: flags=810<POINTOPOINT,SIMPLEX> mtu 1500
ipi9: flags=811<UP,POINTOPOINT,SIMPLEX> mtu 1500
inet 194.97.201.66 --> 194.97.201.9 netmask 0xffffff00
ipi10: flags=810<POINTOPOINT,SIMPLEX> mtu 1500
ipi11: flags=810<POINTOPOINT,SIMPLEX> mtu 1500
ipi12: flags=810<POINTOPOINT,SIMPLEX> mtu 1500
ipi13: flags=810<POINTOPOINT,SIMPLEX> mtu 1500
ipi14: flags=810<POINTOPOINT,SIMPLEX> mtu 1500
ipi15: flags=810<POINTOPOINT,SIMPLEX> mtu 1500
tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
ppp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
Note that lp0 is the first interface. Currently it's not active, but
I was using it a bit last month. The ipi<x>s are ISDN interfaces, and
(with the exception of lo0, of course) I don't use the rest.
Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701082149.WAA07770>