tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Subtle NFS incompatibility with SunOS 4.1.1 on 68K
> On Mar 17, 2020, at 4:54 PM, Chris Hanson <cmhanson%eschatologist.net@localhost> wrote:
>
>> Yah, that's completely weird why it would be passing a negative number to write(). Almost like it got a bad value from stat() or something?
>
> Interesting that you mention that, since this is the output of df on my Sun-3:
>
> ferrari% df
> Filesystem kbytes used avail capacity Mounted on
> pi3bsd:/export/sun/root/ferrari.sun3.sunos.4.1.1
> -1619144 -3584 -486024 65% /
> pi3bsd:/export/sun/exec/sun3.sunos.4.1.1
> -1619144 -3584 -486024 65% /usr
> pi3bsd:/export/sun/exec/kvm/sun3.sunos.4.1.1
> -1619144 -3584 -486024 65% /usr/kvm
> pi3bsd:/export/sun/exec/share/sunos.4.1.1/man
> -1619144 -3584 -486024 65% /usr/share/man
> pi3bsd:/export/sun/exec/local/sun3.sunos.4.1.x
> -1619144 -3584 -486024 65% /usr/local
> pi3bsd:/export/sun/home
> -1619144 -3584 -486024 65% /home
> ferrari%
How big is the file system that you're sharing to the Sun 3? Is it larger than 2GB? (Probably...)
SunOS 4.1.1 is definitely going to be using NFSv2, and that's probably not an oft-exercised code path in the server these days.
> I wonder if something is getting screwed up by the obvious integer overflows in computing filesystem size.
>
>>>> Can you get a tcpdump of the failure from the RPI?
>>>
>>> I'll try! I'll have to figure out how, but I expect it should be straightforward, right?
>>
>> On the RPI:
>>
>> sudo tcpdump -w nfs-fail.pcap port 2049
>>
>> ...ought to do it. Run that command on the RPI, attempt the test case on the Sun, ^C the tcpdump on the RPI, and the .pcap file should have a packet capture that can be easily sliced and diced in Wireshark.
>
> I don't have WireShark handy, I can share the pcap with you if you want though. I figure I'll spare the rest of the list that 8KB attachment.
>
> -- Chris
>
-- thorpej
Home |
Main Index |
Thread Index |
Old Index