the hard part. I assume the latter is what you were
>referring to in the lines below?
Yes. I do know there is some code in sys/rpc/rpc_generic.c (around
line# 320-340) which shows how an IP6 address is coded in ascii to
go on the wire. It basically uses inet_ntop() for the host address and
then
On 27 Sep 2019, at 21:52, Rick Macklem wrote:
Mihir Luthra wrote:
Hi Rick,
Rick wrote:
Although I'll admit it isn't something I am particularily fond of,
FreeBSD likes
utilities to build/work with only one of ipv4/ipv6.
To do this, "#ifdef INET" and "#ifdef INET6" is applied to the code
and
Mihir Luthra wrote:
>Hi Rick,
>Rick wrote:
>>Although I'll admit it isn't something I am particularily fond of, FreeBSD
>>likes
>>utilities to build/work with only one of ipv4/ipv6.
>>To do this, "#ifdef INET" and "#ifdef INET6" is applied to the code and the
>>Makefile is tweaked to define one or
>
>
> clnt_create() checks /etc/netconfig and tries all of the transport
> protocols with the specified class which are listed there, and then
> chooses the first usable one. So if IPv6 is available, "udp6" will
> be used because it is before "udp".
>
> statd.c handles the bind addresses on t
Hi Rick,
> Although I'll admit it isn't something I am particularily fond of, FreeBSD
> likes
> utilities to build/work with only one of ipv4/ipv6.
> To do this, "#ifdef INET" and "#ifdef INET6" is applied to the code and the
> Makefile is tweaked to define one or both of these.
> (You can look a
Mihir Luthra wrote
in :
lu> >
lu> >
lu> > I think you should learn TI-RPC API first. The nettype specifies a
lu> > class of transport protocol, not address family.
lu> >
lu> > Thanks, I did some more research on TI-RPC today.
lu> In `statd.c` what I see is in `create_service()`/`complete_ser
On 26 Sep 2019, at 15:25, Rick Macklem wrote:
Mihir Luthra wrote:
Hiroki Sato wrote:
I think you should learn TI-RPC API first. The nettype specifies a
class of transport protocol, not address family.
Thanks, I did some more research on TI-RPC today.
In `statd.c` what I see is in
`creat
Mihir Luthra wrote:
>Hiroki Sato wrote:
>>
>>
>> I think you should learn TI-RPC API first. The nettype specifies a
>> class of transport protocol, not address family.
>>
>> Thanks, I did some more research on TI-RPC today.
>In `statd.c` what I see is in `create_service()`/`complete_service()`,
>
>
> I think you should learn TI-RPC API first. The nettype specifies a
> class of transport protocol, not address family.
>
> Thanks, I did some more research on TI-RPC today.
In `statd.c` what I see is in `create_service()`/`complete_service()`,
transport info is being fetched through getnetc
Mihir Luthra wrote
in :
lu> > I think the project page has wrong information regarding rpc.statd.
lu> > Although it is not clean from the viewpoint of transport independent,
lu> > it works with IPv6.
lu> >
lu> >
lu> I see, in file.c/procs.c , clnt_create() c
>
>
> I think the project page has wrong information regarding rpc.statd.
> Although it is not clean from the viewpoint of transport independent,
> it works with IPv6.
>
>
I see, in file.c/procs.c , clnt_create() calls are hardcoded to "udp". Code
in `statd.c` i
Mihir Luthra wrote
in :
lu> Hi everyone,
lu>
lu> Just as mentioned in [1], rpc.statd is not ipv6 clean.
lu>
lu> Although I have been through the code, and didn't found any issues until
lu> now. The code conditionally checks for ipv6/ipv4 everywhere and uses ipv6
lu>
Hi everyone,
Just as mentioned in [1], rpc.statd is not ipv6 clean.
Although I have been through the code, and didn't found any issues until
now. The code conditionally checks for ipv6/ipv4 everywhere and uses ipv6
compatible functions.
As per one old commit [2], seems rpc.statd was al
Mihir Luthra wrote
in :
lu> Although I saw a test.c [1] file in the directory. I was wondering if this
lu> complete is the test suite for statd? I tried running `make test` but it
lu> said `No such file or dir: test.c`. Am I doing something wrong here?
No, it was broken. I fixed test.c in r3
Hi,
I was trying to make changes to usr.sbin/rpc.statd to make it ipv6 clean.
I am looking for some good ways to test my changes, would be great if I
could receive some help.
Till now what I planned is setting a NFS client on another system and NFS
server on FreeBSD machine and test its changes
On 03/30/2012 05:36 PM, Josh Beard wrote:
Hello,
snip
Whoops, realized freebsd-fs is probably a more appropriate list for
this. My apologies.
Josh
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To u
etc). After a while, NFS on the server runs into an issue
where (what I think happens) rpc.statd can't talk to rpc.lockd. Being
Mac clients, they all get a rather ugly dialog box stating that their
connection to the server has been lost.
It's worth mentioning that this server is a
Synopsis: [rpc] rpc.statd(8) conflict with cups over tcp and udp ports 631
Responsible-Changed-From-To: freebsd-net->matteo
Responsible-Changed-By: matteo
Responsible-Changed-When: Wed Mar 28 09:53:28 UTC 2007
Responsible-Changed-Why:
I'll work on a similar issue for rpc.lockd and I hope
Synopsis: [rpc] rpc.statd(8) conflict with cups over tcp and udp ports 631
Responsible-Changed-From-To: bms->freebsd-net
Responsible-Changed-By: bms
Responsible-Changed-When: Sun Mar 4 15:03:40 UTC 2007
Responsible-Changed-Why:
Someone else with Copious Free Time can do this -- not a prior
> Generally, sendmail uses flock() on the aliases file and related databases
> to ensure consistency. As far as I know, it's unrelated to redirection.
And for locking queue files.
> > Here is what Control-T does
> > load: 0.20 cmd: sendmail 292 [pause] 0.02u 0.04s 0% 2016k
>
> pause, eh? That
ar as I know, it's unrelated to redirection.
> I think a solution could be to make virecover called later on. Why are
> rpc.lockd and rpc.statd not started directly after rpcbind?
No idea. Moving virecover later is a possibility; probably the missing
piece is that sendmail should depend
This is when sendmail is ran from virecover.
Is this because sendmail is taking redirection,
and it needs to flock() for that?
I think a solution could be to make virecover called later on.
Why are rpc.lockd and rpc.statd not started directly after
rpcbind?
Here is some more output.
Recovering
arts before rpc.lockd and rpc.statd? This will
> cause diskless clients to hang? This is a nfs server and diskless
> client running 5.1-RELEASE. I'm running rpc.lockd and rpc.statd on the
> server and the client. Should rpc.lockd and rpc.statd be started before
> sendmail start
Jun 8 00:52:33 photon sendmail[293]: h584pRfm000293: SYSERR(root): cannot
flock(./tfh584pRfm000293, fd=5, type=6, omode=40001, euid=25^C.
NFS access cache time=2
Starting statd.
Starting lockd.
I should clarify that /etc/rc.d/virecover is calling sendmail.
Does virecover need to be called this ea
Jun 8 00:52:33 photon sendmail[293]: h584pRfm000293: SYSERR(root): cannot
flock(./tfh584pRfm000293, fd=5, type=6, omode=40001, euid=25^C.
NFS access cache time=2
Starting statd.
Starting lockd.
It looks like sendmail starts before rpc.lockd and rpc.statd? This will cause
diskless clients to
Tyler K McGeorge ([EMAIL PROTECTED]) wrote:
> After I set up my BIND name daemon, I started getting the following message:
>
> Jan 31 16:12:45 palisorrpc.statd: invalid hostname to sm_stat: (then a whole
>bunch of gibberish, I would transcribe it, but it uses strange characters
After I set up my BIND name daemon, I started
getting the following message:
Jan 31 16:12:45 palisor
rpc.statd: invalid hostname to sm_stat: (then a whole bunch of gibberish, I
would transcribe it, but it uses strange characters that aren't available in
Windows.)
I assume this
> Tyler K McGeorge wrote:
>
> After I set up my BIND name daemon, I started getting the following message:
>
> Jan 31 16:12:45 palisorrpc.statd: invalid hostname to sm_stat: (then a
> whole bunch of gibberish, I would transcribe it, but it uses strange
> characters tha
28 matches
Mail list logo
