Linux doesn't like Access+ broadcasts anymore?
Stefan Bellon
Debian GNU/Linux box:
Jan 5 09:49:14 vici kernel: svc: bad direction 256, dropping request
Jan 5 09:49:14 vici kernel: svc: bad direction 512, dropping request
Jan 5 09:49:17 vici kernel: svc: bad direction 768, dropping request
Jan 5 09:49:17 vici kernel: svc: short len 4, dropping request
It's always those four lines in a row.
Then I started tcpdump and looked what's going on. I was astonished to
see what's happening at exactly those times:
09:49:14.518199 192.168.0.100.32770 > 192.168.0.255.32770: udp 24
09:49:14.518216 192.168.0.100.32770 > 192.168.0.255.32770: udp 40
09:49:17.199376 vidi.localnet.32770 > 192.168.0.255.32770: udp 44
09:49:17.199521 vidi.localnet.32770 > 192.168.0.255.32770: udp 20
Gosh, both, my Iyonix (192.168.0.100, the name cannot be looked up as
the RISC OS 5 DHCP client doesn't send it, the Select one does) and my
Risc PC are sending out Access+ broadcasts and they seem to confuse the
kernel NFS server on my GNU/Linux box.
I've never seen this before. Anybody any ideas?
--
Stefan Bellon
Ian Jeffray
> Jan 5 09:49:14 vici kernel: svc: bad direction 256, dropping request
> I've never seen this before. Anybody any ideas?
Yes. For years. It's bloody annoying. ShareFS/Freeway using the same
ports as NFS... 32770. An unfortunate clash and unfortunate debug.
Ways to solve it?
Don't run Freeway if you don't need it.
Firewall-off that port on the linux box if you don't need NFS.
Rebuild the offending spammer (I /think/ it's mountd, or portmapper).
HTH,
Ian.
Stefan Bellon
> Stefan Bellon wrote:
> > Jan 5 09:49:14 vici kernel: svc: bad direction 256, dropping
> > request
> > I've never seen this before. Anybody any ideas?
> Yes. For years.
Really? I've never seen it before and I do run my Debian GNU/Linux
notebook alongside my RISC OS machines for quite some years. It has
never before cluttered up the syslog like it does now. Something must
have changed.
> It's bloody annoying.
Indeed.
> ShareFS/Freeway using the same ports as NFS... 32770. An unfortunate
> clash and unfortunate debug.
I see.
> Ways to solve it?
> Don't run Freeway if you don't need it.
Unfortunately I need it.
> Firewall-off that port on the linux box if you don't need NFS.
I think I'll go that route. iptables is installed anyway, so I'll block
that port from those IPs.
Thanks for the ideas.
--
Stefan Bellon
James Byrne
There's a much easier answer. Add this to /etc/sysctl.conf:
# Change dynamic port range to avoid clash with ShareFS
net.ipv4.ip_local_port_range = 49152 61000
This works on my RedHat 7.3 machine anyway. The point is that some part
of NFS opens a dynamic port for RPC, and in some Linux distributions
dynamic ports default to start at 32768, hence it always ends up with
32770 and you get the clash. Moving the dynamic port range avoids the
problem. Note that different distributions/versions of Linux may have
different settings, so check what you have first.
James
Stefan Bellon
> There's a much easier answer. Add this to /etc/sysctl.conf:
> # Change dynamic port range to avoid clash with ShareFS
> net.ipv4.ip_local_port_range = 49152 61000
Nice! :-)
> This works on my RedHat 7.3 machine anyway. The point is that some
> part of NFS opens a dynamic port for RPC, and in some Linux
> distributions dynamic ports default to start at 32768, hence it
> always ends up with 32770 and you get the clash. Moving the dynamic
> port range avoids the problem. Note that different
> distributions/versions of Linux may have different settings, so
> check what you have first.
Yes, that explains why I have never in the past seen that problem.
Thanks a lot.
--
Stefan Bellon