Strange rpm packet length error.

[William Unruh]

On a number of machines I got similar to the following in dmesg

[227555.637768] RPC: fragment too large: 1195725856
[227584.772471] RPC: fragment too large: 1212501072
[227713.488566] RPC: fragment too large: 1533112946
[233878.914281] RPC: fragment too large: 67174480
[281316.636572] RPC: fragment too large: 1195725856
[281551.041798] RPC: fragment too large: 1195725856
[285306.096704] RPC: fragment too large: 84017154
[285306.610466] RPC: fragment too large: 67174480
[285841.209315] RPC: fragment too large: 84017154
[285841.722115] RPC: fragment too large: 67174480
[437286.441704] RPC: fragment too large: 1195725856


Clearly 1GB is too large a packet:-). What could be going on here? Is
this some sort of attack, or just completely messed up packets?
That a number have the same "size" suggests that this is not just an
accident.

[Bit Twister]

On Wed, 18 Nov 2015 19:35:44 -0000 (UTC), William Unruh wrote:
> On a number of machines I got similar to the following in dmesg
>
> [227555.637768] RPC: fragment too large: 1195725856
> [227584.772471] RPC: fragment too large: 1212501072

Just curious, from a root terminal, does a
journalctl -b | grep -i RPC:
show the originating ip address.

Maybe you could look via lsof to see the offender.

[William Unruh]

On 2015-11-18, Bit Twister <BitTw...@mouse-potato.com> wrote:
> On Wed, 18 Nov 2015 19:35:44 -0000 (UTC), William Unruh wrote:
>> On a number of machines I got similar to the following in dmesg
>>
>> [227555.637768] RPC: fragment too large: 1195725856
>> [227584.772471] RPC: fragment too large: 1212501072
>
> Just curious, from a root terminal, does a
> journalctl -b | grep -i RPC:
> show the originating ip address.

Nope.
Nov 14 12:20:01 bh0.phas.ubc.ca kernel: RPC: fragment too large: 1195725856

as an example.
At least it gives me the time instead of "seconds since boot".
(Note that bh0.... is the local machine and is just telling me it comes
from teh kernel of the local machine.)

>
> Maybe you could look via lsof to see the offender.

Not clear how lsof could do that.

[Bit Twister]

Frap, wrong command, this should work better
netstat -tupan

[J G Miller]

On Wednesday, November 18th, 2015, at 19:35:44h +0000, William Unruh wrote:

> Clearly 1GB is too large a packet:-). What could be going on here? Is
> this some sort of attack, or just completely messed up packets?
> That a number have the same "size" suggests that this is not just an
> accident.

Could be an attack but is your RPC open to Internet or LAN attacks?

From a quick web search, it would appear more probable that it is
related to NFS issues.

Are you running NFS between the affected machines?

If so, have a look at

<https://www.reddit.COM/r/sysadmin/comments/36rz17/rpc_fragment_too_large_1432183632_cannot_figure/>

and

<https://lkml.ORG/lkml/2012/6/13/338>

More recently

<http://marc.INFO/?t=133957990000002&r=1&w=2>

[David W. Hodgins]

On Wed, 18 Nov 2015 14:35:44 -0500, William Unruh <un...@invalid.ca> wrote:

> On a number of machines I got similar to the following in dmesg
> [227555.637768] RPC: fragment too large: 1195725856

Not sure how to fix it, but it appears to be related to nfs mounts.
https://lkml.org/lkml/2012/6/13/338

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

[William Unruh]

On 2015-11-18, David W. Hodgins <dwho...@nomail.afraid.org> wrote:
> On Wed, 18 Nov 2015 14:35:44 -0500, William Unruh <un...@invalid.ca> wrote:
>
>> On a number of machines I got similar to the following in dmesg
>> [227555.637768] RPC: fragment too large: 1195725856
>
> Not sure how to fix it, but it appears to be related to nfs mounts.
> https://lkml.org/lkml/2012/6/13/338

Yes, I am pretty sure that is what it is. But the fragment size is
simply absurd in my case-- over 1GB so it is not simply a bad rsize of
wsize.


I am also getting massive number of
[516137.906560] nfs: server bh1 not responding, still trying
[546657.822748] nfs: server bh1 OK
type messages.

So something is certainly wrong on the nfs front.

Also mounting stuff from bh1 takes a LONG time to mount, and df takes a
long time return.

[J.O. Aho]

NIC near death or cable issues?

--

//Aho

[William Unruh]

Well I see no evidence in ping-- times are all reasonable and consistant
and no dropped packets. So it is possible, but not where I would look
first I guess.

>

[Bit Twister]

error counts seen in ifconfig has been an indicator for me.
Note: nic cable in/out causes errors so do not count those as a problem.

I had problems and one of my routers was having problems. Suggestion
was to use iperf to throughput. You run tests between a server and a client.
Here you see what I would run between two nodes.

comment command
network_testing_server_wb iperf3 -s
network_testing_client_mtv iperf3 -c wb
network_testing_client_tb iperf3 -c wb

[William Unruh]

Well, I did a sort of network test with it-- I transfered 250GB of data
between it and another machine. Usually the rate on large files was
about 30MB/s, but occasionally it would drop to about 3MB/s (they are
both with gigabit cards) I did not watch it continuously for the hour
and a half the trasfer took.

Doing iperf3 tests just now, I am getting 933Mb/s which is pretty close
to Gb trasfer rate :-)
iJust did 20 in a row and got consistant results. But if I try to do an
nfs mount, it takes forever.
One of the machines is Mageia 4 and the other is Centos 6.7

Dound a
mount -v c1:/home /d/c1/home
I once got that it camplained that rpc.statd was not running-- it is on
both machines, the centos server and the local machine.

Other times it has trouble with nfs v4

mount.nfs: trying text-based options
'vers=4,addr=142.103.xxx.xx1,clientaddr=142.103.xxx.xx2'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=142.103.xxx.xx1'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 142.103.xxx.xx1 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 142.103.xxx.xx1 prog 100005 vers 3 prot UDP port 892

The server is centos 6.7 which certainly has nfsv4

[F8BOE]

Hello,

I have also problems with NFS AND FTP transfert rates on a 64 bits MGA5,
that I do not have on my 32 bits systems (they only have serious suspend
to RAM/disk problems).

The NFS + FTP server is NAS4Free 10.2.0.2003 which works well with other
systems (MDV 2010.2, MGA4, Android 5.1.1)

Honestly I never had so many problems with an OS as I have with MGA5.
After 5 months it's still pre-beta testing crap, nothing works
correctly: CUPS and printing, ACPI, WiFi, Okular Akonadi, Kontact and
perhaps other good stuff I was used to work with but haven't use it yet
on my fresh installed system (1 week ago)!

And the folks at MGA want what? A new release every 18 months???

No sorry, not that way...

--
Ciao @+

< Sony VGN-FW54M powered by Mageia 4 x86-64 >

[William Unruh]

On 2015-11-21, F8BOE <f8...@bluemail.ch> wrote:
> Le 18/11/2015 20:35, William Unruh a ?crit :

>> On a number of machines I got similar to the following in dmesg
>>
>> [227555.637768] RPC: fragment too large: 1195725856
>> [227584.772471] RPC: fragment too large: 1212501072
>> [227713.488566] RPC: fragment too large: 1533112946
>> [233878.914281] RPC: fragment too large: 67174480
>> [281316.636572] RPC: fragment too large: 1195725856
>> [281551.041798] RPC: fragment too large: 1195725856
>> [285306.096704] RPC: fragment too large: 84017154
>> [285306.610466] RPC: fragment too large: 67174480
>> [285841.209315] RPC: fragment too large: 84017154
>> [285841.722115] RPC: fragment too large: 67174480
>> [437286.441704] RPC: fragment too large: 1195725856
>>
>>
>> Clearly 1GB is too large a packet:-). What could be going on here? Is
>> this some sort of attack, or just completely messed up packets?
>> That a number have the same "size" suggests that this is not just an
>> accident.
>>
>
> Hello,
>
> I have also problems with NFS AND FTP transfert rates on a 64 bits MGA5,
> that I do not have on my 32 bits systems (they only have serious suspend
> to RAM/disk problems).

Mine is mga4 to a centos 6.7 server.

>
> The NFS + FTP server is NAS4Free 10.2.0.2003 which works well with other
> systems (MDV 2010.2, MGA4, Android 5.1.1)

No idea what that is.

>
> Honestly I never had so many problems with an OS as I have with MGA5.
> After 5 months it's still pre-beta testing crap, nothing works
> correctly: CUPS and printing, ACPI, WiFi, Okular Akonadi, Kontact and

Cups has changed significantly. What problems do you have?
What wifi are you using ( wifi card, and which program-- networkmanager,
Mageia's Network center, systemd networking?

And have you updated your system?

[Bobbie Sellers]

NAS4Free 10.2.0.2.2003 - A freely distributed and open source Network
Attached Storage (NAS) operating system. NAS4Free is an open source BSD
operating system based on the highly acclaimed and award winning FreeBSD
project and designed from the ground up to provide users with an
easy-to-use, stable, powerful and reliable NAS (Network-Attached
Storage) distribution.
Mandriva 2010.2
Mageia 4
Android Lolipop
All are FOSS and all but the first is Linux.

>
> No idea what that is.
>
>>
>> Honestly I never had so many problems with an OS as I have with MGA5.
>> After 5 months it's still pre-beta testing crap, nothing works
>> correctly: CUPS and printing, ACPI, WiFi, Okular Akonadi, Kontact and

Strangely I don't have that many problems but I have a
HP_15N225NRc a Pavilion notebook with AMD A-10 4 core.

I would think that your problems are due to hardware that
is a bit different from what the Mandriva 5 expects to find.
I being a ignoramus on many topics would check what
MCC finds in your hardware and try to locate better drivers
which might help with your suspend problems.

>
> Cups has changed significantly. What problems do you have?

CUPS works fine for me.
I see other people complaining that it has changed and
is not working well with their systems. I wonder what went wrong
with their updates.

> What wifi are you using ( wifi card, and which program-- networkmanager,
> Mageia's Network center, systemd networking?
>
> And have you updated your system?

And did you do a clean install?

Are you using UEFI tools or MBR tools?

>
>
>> perhaps other good stuff I was used to work with but haven't use it yet
>> on my fresh installed system (1 week ago)!
>>
>> And the folks at MGA want what? A new release every 18 months???
>>
>> No sorry, not that way...
>>

I think it is every 12 months but due to unforeseen problems it
went out to about 18 months this year. I would be happy with a rolling
release with a double install in case of problems. New clean isos every
couple of years.

[William Unruh]

Nothing went wrong with their update. Something changed in cups.
Cups now uses cups-browsed to do remote printers, and their
defaults in cups-files have changed (no more errors printed to
/var/log/cups/error.log) aand the page log prints nothing because of a
PageLogFormat default change (it is now put as an active option into
cupsd.conf but with nothing to be printed out, which thus disables page
logging).

Of course if you do not do browsing, or error logging or page logging
those will not bother you.

[bho...@redhat.com]

On Wednesday, November 18, 2015 at 2:38:05 PM UTC-5, William Unruh wrote:
===

> On a number of machines I got similar to the following in dmesg
>
> [227555.637768] RPC: fragment too large: 1195725856
> [227584.772471] RPC: fragment too large: 1212501072

===

I just ran across a very similar situation on a RHEL 6.9 NFS client and a NetApp running Ontap 9.1R12. Looks like someone is being cute with error codes:


$ printf %x\\n 1195725856
47455420

$ ascii 0x47 0x45 0x54 0x20
ASCII 4/7 is decimal 071, hex 47, octal 107, bits 01000111: prints as `G'
Official name: Majuscule G
Other names: Capital G, Uppercase G
ASCII 4/5 is decimal 069, hex 45, octal 105, bits 01000101: prints as `E'
Official name: Majuscule E
Other names: Capital E, Uppercase E
ASCII 5/4 is decimal 084, hex 54, octal 124, bits 01010100: prints as `T'
Official name: Majuscule T
Other names: Capital T, Uppercase T
ASCII 2/0 is decimal 032, hex 20, octal 040, bits 00100000: prints as ` '
Official name: SP
Other names: Space, Blank

$ printf %x\\n 1212501072
48454c50

$ ascii 0x48 0x45 0x4c 0x50
ASCII 4/8 is decimal 072, hex 48, octal 110, bits 01001000: prints as `H'
Official name: Majuscule H
Other names: Capital H, Uppercase H

ASCII 4/5 is decimal 069, hex 45, octal 105, bits 01000101: prints as `E'
Official name: Majuscule E
Other names: Capital E, Uppercase E

ASCII 4/12 is decimal 076, hex 4c, octal 114, bits 01001100: prints as `L'
Official name: Majuscule L
Other names: Capital L, Uppercase L

ASCII 5/0 is decimal 080, hex 50, octal 120, bits 01010000: prints as `P'
Official name: Majuscule P
Other names: Capital P, Uppercase P


(Kudos to F. Sorenson for seeing this.)

[jimbob]

Note: We were able to correlate these log messages with Nessus/Security Center scans.