Oversized packet

Last night I decided to try connecting a FAT32 formatted USB HDD to my BT SmartHub 6. I was able to back my RPi’s SSD up to it.

However, when I try any method to read anything back from the drive (which I am connecting to via LanMan98), I get an error message that is some variaion on “Oversized packet…”. For example, when I double click on a text file on the drive, I get “Oversized packet received nnnnnnnn, 16648” where the first number varies and the second number is always 16648.

Can anybody offer an explanation, and is there anything I can do to overcome it?

There must be others out there who have a BT SmartHub 6; have you tried doing the same thing? (I couldn’t work out how to connect to it until I noticed that the Linux box sees the share name as “shared_disk”. That isn’t visible anywhere on the SmartHub’s web pages. Thank you, BT.)

I’ve tried connecting via LanMan instead of LM98 and doing a copy at the command line. I had copied my ZeroPain file to the drive earlier today (several reboots ago!) and now tried to copy it back to the RAM disc. I got an AODT at &FC17F7F8. *where shows &FC17F7F8 to be at offset &0000C9AC in module ‘SharedCLibrary’.

In an earlier experiment I used WireSalmon to capture an attempt to copy the same file to the same place, using LM98. Wireshark showed that after the initial negotiation there were lots of NBSS TCP segments that would assemble to give data lengths of 65532.

Jumbo packet support enabled in the router?

The SmartHub is the router, but its user interface is so dumbed down that there is no access to any setting for jumbo frames.

I’ve found the ancient LanMan98 is very flaking on later versions of RISC OS and/or newer hardware. I’ve moved to LanmanFS on the ARMx6, which is far more reliable – but watch out there are a few more invalid characters in filename translations (from memory < and >). So you’ll need to rename any RISC OS files with those in them, or your backup software wont work properly.

I can’t find any obvious “oversized packet” error messages in the network stack (the closest I’ve found is “oversized message”). Which makes me think that it might be unrelated to jumbo frames, and is instead a LanMan98 / LanMan bug (similar to this one)

I’ve found the ancient LanMan98 is very flaking on later versions of RISC OS and/or newer hardware. I’ve moved to LanmanFS on the ARMx6, which is far more reliable

Well, all it gives me is an AODT. I just tried mounting the drive from the command line, in a taskwindow, then copying the ZeroPain file; the address of the AODT is different but that’s the only change.

The version of RISC OS I’m using on the RPi 3B+ is only a week old, and LanManFS is 2.62 (04 Jun 2019).

Here’s another curious finding. I repeated the command line test above but using LanMan98 instead, and it worked – the file was transferred to RAMFS in the blink of an eye, with no error message. I had to triple-check my command line to see that it really did reference the LanMan98 mount.

That’s LanMan98 2.06 (15 Oct 2015) CIFS client.