low mtu

assuming you are talking about FreeBSD, what does ifconfig show for you wired interface? It should have an mtu value.
What is your connection? bsd box ethernet to hub VDSL to provider? Is the "to provider" maybe doing PPPoE?
 
Not certain , i think PPPoE behind the hood.

ifconfig -a | grep mtu
Code: 
em0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1448
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
 
Your carrier might be using some kind of tunnel somewhere. Some of my clients use encryption tunnels on private circuits between two cities. MTU is about 1450.
 
Well em0 says mtu of 1448; if that is not specifically set, then that is negotiated upstream of em0.
Not much you can do about it.
But: it may become important/interesting if you are trying to serve data that can't/should not be fragmented (perhaps video, UDP packets).
If you were serving video over udp you should set the video converter to output no more than 1400 otherwise fragementation and packet loss at a receiver

Normally an application would "write data to a socket" and the chunking down to wire size happens at kernel level. UDP is often different.
 
I'm not the sysctl hero but here,
cat /etc/sysctl.conf
Code: 
# net.inet.tcp.pmtud_blackhole_mss=1400
net.inet.ip.maxfragpackets=0             #15762
net.inet.ip.maxfragsperpacket=0          #16
net.inet.ip.random_id=1
net.inet.tcp.cc.algorithm=cubic          #newreno #Congestion control newreno,CDG,CHD,CUBIC,DCTCP,HD,H-TCP,VEGAS
net.inet.tcp.path_mtu_discovery=1
net.inet.tcp.pmtud_blackhole_detection=1
Internet seems to fine however.
 
None of those specifically relate to "ping with a specified data size".
Ping with specified data size above mtu is probably failing because the icmp request is fragmented on way out which mucks up return processing.
Normal Internet traffic works because application presents outbound data > mtu size so kernel fragments, upstream deals with fragments.
Return data > mtu is already fragmented and receiver (kernel) reassembles fragments into whole packet before handing off to application.

My take/moral of the story is ping, icmp traffic above mtu size simply informs you the maximum mtu size. maximum mtu size is of little interest until it gets in the range of 512 bytes. Why? That means every 1500 byte packet (typical ethernet size) gets chunked into 3 fragments on the wire which is more processing reassembling/transmitting.
So your ping failure is moderately interesting and consistent with the wiresize mtu.
 
most of the time "link level fragmentation" is your friend, not your enemy. It allows packets to navigate through heterogenous network links that you have no control over. So the question is whether the loss of large packet pings is an academic curiosity for you, or is something actually broken.

As to ping specifically, it depends on whether the OS is setting the DF (don't fragment) flag. if BSD ping sets DF by default then the ping will fail.
 
Indeed.
- I kow little
-Connected to a hub
- Connected to VSDL router
- Connected to twisted wire
- Connected to fiber
- Probably ATM
But most important, have no connection difficulties.
But it would be nice to know exact answer from provider.
You get mostly very stupid A.I. system , who don't know what MTU is.
 
Jumbo packets are great until they aren't. As kent_dorfman766 implies, the physical layer controls that. Start out with your home network supporting jumbo (64K) packets. That only matters if you are sending data that big or greater. Now you are sending that out to the "World" that supports only 1500B packets. That means if you send a 64K packet out it will get chunked into roughly 43 1500B chunks (rough approximation). anyone of those chunks gets lost and the packet can't be reassembled on the far end.
If the transport is udp: losing one 1500B chunk on 64KB data means the whole packet is lost.
If the transport is tcp, same thing but TCP will retransmit the whole 64KB packet meaning everything in the path will toss existing fragments and restart everything over on the whole packet.
The DF bit: if set and you transmit a 64KB packet on a like only supporting 1500B, hardware says "bye bye" and typically drops it.

Networking is governed by the smallest MTU on the complete path. Anything bigger will get fragmented and reassembled (assuming DF is not set) Fragments lost/dropped means can't reassemble means packet is dropped and TCP or application resends.

If one assumes basic "ethernet" as the path, MTU is roughly 1500bytes. If something needs to add header like PPPoE or VPN, wire MTU may still be 1500 but the user data gets reduced by the extra header space. You see this with your em0 mtu being 1448. that mean "total of 1448B of user data because we still have to put 52B of our header on the packet". User data of 1448 includes any/all tcp or udp headers, so we start to hit that "real user data of 1400B".
 
properly configured networks can engage in path-mtu discovery by way of exchanging ICMP Fragmentation Needed But DF Set messages. Unfortunately this breaks on networks where people just flat out block all ICMP out of some bogus notion of security. Also if your ISP is PPPoE you have to use pf to lower the MSS on translated packets or else you'll run into cool failure modes. :)
 
I'm almost certain my VSDL router uses PPoE. I use IPFW not PF. I like it more.
Once i setup internet configuration to make 4 tunnels PPPoE through my router, this worked. Not one port was blocked, but then i use FreeBSD, not Windows ...
Now i'm going to try to ask question to ISP, this can be difficult...

& there we go, We are sorry, something went wrong! We encountered a technical issue while trying to log you into your MyProximus account with itsme. Please try again later.

Your question:
“why is my mtu 1448”

Our answer:
Sorry, no results were found.


Hello, Alain! I’m Proximus Assistant 🤖 I can use artificial intelligence to answer your questions.

bot :
How can I help you today?


user :
why is my mtu 1448
17:01
Proximus Assistant
I'm not sure if I understand your question correctly. Can you please rephrase it?


user :
why is my mtu 1448, should i rephrase stupid ai
17:01
Proximus Assistant
I'm not sure if I understand your question correctly. Can you please rephrase it?
user :
fuck of
17:02

Proximus Assistant
To make sure I offer you the right colleague, please select one of the options below 👇 17:02

user :
Technical issues
17:02
Proximus Assistant
I'm looking for the right colleague for you. Right now, the average waiting time is less than 5 minutes.

user :
why is my mtu 1448
17:02
agent :
The conversation with the Proximus Assistant has ended.

You're now chatting with an employee from the Proximus Helpdesk.

HTen i was thrown in the bin
 
You must log in or register to reply here.
Back
Top