Ticket #206 (WorksForMe)Mon Jun 22 12:36:39 UTC 2009
EtherK: setting non-default MTU stops packets being sent
| Reported by: | Dave Higton (281) | Severity: | Normal |
| Part: | RISC OS: Module | Release: | |
| Milestone: | Status | WorksForMe |
Details by Dave Higton (281):
I’ve discovered that setting the MTU to a non-default value (e.g. 1492) causes packets of that length not to be sent. Ref. recent messages on the Iyonix mailing list and in comp.sys.acorn.programmer. EtherK 0.20, RISC OS 5.14 softload.
Changelog:
Modified by Theo Markettos (89) Wed, June 24 2009 - 17:31:23 GMT
Iyonix list thread:
http://www.freelists.org/post/iyonix-support/Do…
csap thread:
http://groups.google.co.uk/group/comp.sys.acorn…
Modified by Sprow (202) Tue, September 13 2011 - 19:51:45 GMT
- Severity changed from Critical to Major
Modified by Sprow (202) Sun, November 02 2014 - 13:55:02 GMT
- Severity changed from Major to Normal
Testing with EtherK 0.25.
.44 is an Iyonix.
.2 is a Windows PC.
*ifconfig ek0 10.0.0.44 mtu 1400
*ping -s 1500 10.0.0.2
Wireshark running on the PC shows ICMP packets received fragmented as 1410+166, the Iyonix receives the replies OK.
*lmconnect Test WindowsPC MountPoint guest guest
Connecting via LanManFS using IP transport (not NetBEUI).
Copied a few 4MB files from the PC.
Wireshark running on the PC shows the raw read request part of the SMB transaction as 1414 byte chunks. Files received OK.
Set the MTU back to 1500, disconnected and reconnected to the PC (so the NetBIOS session was changed).
Wireshark running on the PC shows ICMP packets received fragmented as 1514+62, the Iyonix receives the replies OK.
Wireshark running on the PC shows the raw read request part of the SMB transaction as 1514 byte chunks. Files received OK.
SYS"EtherK_GetNetworkMTU",0,0 TO,,mtu%:PRINT mtu%
shows the number matching ifconfig in both cases.
Modified by Sprow (202) Fri, November 07 2014 - 08:55:31 GMT
- Status changed from Open to WorksForMe
Followup after an email to the original reporter, they also encountered problems contacting/resolving via Google’s public DNS (8.8.8.8).
With EtherK 0.25, and an MTU of 1400 again, the following worked fine when tested on a machine with no boot sequence:
As before
.44 is the Iyonix
.2 is a Windows PC (not involved in this test)
.99 is the router, a 3Com model 3CRWDR-100A-72
*ifconfig ek0 10.0.0.44 mtu 1400
*ifconfig a <- just to confirm
*route add default 10.0.0.99
*ping 8.8.8.8 <— check can access a computer outside the local subnet
*set Inet$Resolvers 8.8.8.8
*resolverconfig <— reread the resolver address
*ping riscosopen.org
All worked as expected, can resolve external names via Google DNS.
Concluding that this is some non compliance either with the original reporter’s DNS or some intermediate equipment like a switch that can’t fragment packets properly? The Wireshark captures and empirical evidence using ICMP and LanManFS doesn’t point to any problem with EtherK or the Internet module.
