Develop Reference

what is the /sys/class/gpio/export and `/sys/class/gpio/unexport mechanism and what is the underlying sysfs functionality?

Using the legacy sysfs GPIO under Android and Linux the first step in the process is toe export the particular GPIO pins you want to use. And when you are done with the GPIO pin to unexport it.
I've been looking for an explanation of what the export command actually does however everything I've found is about the builtin bash command which has nothing to do with GPIO.
Then I realized the actual command from the command line was echo 938 > /sys/class/gpio/export and /sys/class/gpio/export is a special device file in folder /sys/class/gpio.
The only comment that I have found indicates that writing the GPIO pin number to /sys/class/gpio/export causes the GPIO special file associated with that GPIO pin to be "exported to user space" which then allows a user application to use the specified GPIO pin with file I/O to the special device file.
GPIO Sysfs Interface for Userspace
“export” …
Userspace may ask the kernel to export control of a GPIO to userspace
by writing its number to this file.
Example: “echo 19 > export” will create a “gpio19” node for GPIO #19,
if that’s not requested by kernel code.
“unexport” …
Reverses the effect of exporting to userspace.
Example: “echo 19 > unexport” will remove a “gpio19” node exported
using the “export” file.
So if I specify echo 938 > /sys/class/gpio/export then a special device file folder /sys/class/gpio/gpio938 with special device files /sys/class/gpio/gpio938/value and /sys/class/gpio/gpio938/direction are created. And when I do an echo 938 > /sys/class/gpio/unexport then those special device files are removed?
In researching about using GPIO pins with a DragonBoard 410C under Android 5.1 an online course about this device I am taking said to add the following lines to the boot initialization script.
set -A pins 938 915 1017 926 937 930 914 971 901 936 935
for i in 0 1 2 3 4 5 6 7 8 9 10
do
echo ${pins[i]} > /sys/class/gpio/export;
chmod 777 /sys/class/gpio/gpio${pins[i]};
chmod 777 /sys/class/gpio/gpio${pins[i]}/value;
chmod 777 /sys/class/gpio/gpio${pins[i]}/direction;
done
My understanding is that these commands create the special device files for GPIO pins 938, 915, 1017, 926, 937, 914, 901, 936, 935 so that an application can read and write to these GPIO pins to do something such as turning an LED on and off by writing values to, for instance /sys/class/gpio/gpio938/value.
My understanding about this boot initialization script is that this removes the need for a user to use the sudo command with each of the shell command lines in order to perform these commands by a user before running an application that accesses the GPIO pins using sysfs. Is that true?
My Questions
What are these special device files /sys/class/gpio/export and /sys/class/gpio/unexport and how are they connected to some kind of functionality in the Linux kernel which creates and destroys special device files in the /sys/class/gpio folder?
With the suggested change to the boot initialization script are the special device files representing the GPIO pins created with access by anyone so an application program can just use the pins and not bother with export or unexport? A user application can just perform read/write to the special device without having to use sudo echo 938 > /sys/class/gpio/export first?
What is the access and sharing permissions for these special files created by the boot initialization script and can multiple applications be manipulating the same GPIO pins simultaneously?

The pseudo-files in /sys/class/gpio are fairly thin wrappers around function calls in the kernel interface. There's a clue in the kernel documentation [1] about the purpose of the import/export functionality:
After a kernel driver requests a GPIO, it may only be made available
in the sysfs interface by gpiod_export(). The driver can control
whether the signal direction may change. This helps drivers prevent
userspace code from accidentally clobbering important system state.
This explicit exporting can help with debugging (by making some kinds
of experiments easier), or can provide an always-there interface
that’s suitable for documenting as part of a board support package.
So, essentially, this functionality exists to prevent user-space applications carelessly trampling on the state of I/O devices. How useful it is in practice, I don't know.
[1] https://www.kernel.org/doc/html/latest/admin-guide/gpio/sysfs.html

There are several directory structures within the Linux file system that are not actual disk file directories. Instead these directory structures and the "files" within them are pseudo files or Linux operating system services and data that are presented as files and can be accessed using file operations but are not actual files stored on a persistent store such as a hard disk or solid state disk.
A Study of Modern Linux API Usage and Compatibility: What to Support When You’re Supporting
In addition to the main system call table, Linux exports many
additional APIs through pseudo-file systems, such as /proc, /dev, and
/sys. These are called pseudo-file systems because they are not backed
by disk, but rather export the contents of kernel data structures to
an application or administrator as if they were stored in a file.
These pseudofile systems are a convenient location to export tuning
parameters, statistics, and other subsystem-specific or device
specific APIs. Although many of these pseudo-files are used on the
command line or in scripts by an administrator, a few are routinely
used by applications. In order to fully understand usage patterns of
the Linux kernel, pseudo-files must also be considered.
An analogy for pseudo files
A way to think about these pseudo files from a user perspective is they are a kind of Remote Procedure Call interface to the Linux kernel that uses file system semantics to request that some operation be done. The file system semantics map to the following generic actions and behavior:
open the pseudo file means to open a connection between the user application and some functionality within the Linux kernel
read the pseudo file means to read a block of data provided by some functionality within the Linux kernel through the connection
write the pseudo file means to send a request message to some functionality within the Linux kernel through the connection (the message may be a command with data, a command only, or data only)
close the pseudo file means to close a connection between the user application and some functionality within the Linux kernel
Different pseudo files expose different Linux kernel data and services which means that the interface specification as to how the file operations map to the Linux kernel functionality exposed through the pseudo file will vary depending not only on the Linux kernel functionality or handler for the pseudo file but also the Linux kernel version.
This StackOverFlow posting, Create sysfs entry from kernel module , contains a simple example of a handler for a pseudo file in /sys showing the basics of providing the function interfaces the Linux kernel needs to hook the handler for the new pseudo file into the Linux kernel.
This StackOverFlow posting, How to create proc entry under /proc/driver? , contains a simple example of a handler for a pseudo file in /proc.
Both of these simple examples have a similar structure to the source code. However these specific examples may be using deprecated Linux kernel interfaces so I provide these links only to illustrate the underlying functionality of a pseudo file handler.
export and unexport
Normally the GPIO pins of the underlying hardware on which Linux is running are not exposed to user applications. The pins are used by the Linux kernel using device drivers to interact with devices.
The purpose of export is to expose selected GPIO pins to user space as pseudo files allowing a user application to perform their own interactions with some hardware. Not all available or possible GPIO pins may be exposed. What pins can be exposed using export will depend on what /sys handlers have been inserted into the Linux kernel and what those handlers allow.
What pseudo files are actually exposed and how those pseudo files are used will depend on the function of the GPIO pin, e.g. a digital pin versus an analog pin versus a pin that supports PWM or has pullup or pulldown resistors. What files are exposed will also depend on what functionality the handler for /sys/class/gpio/ provides. A GPIO pin may have a pullup or pulldown resistor that could be used but the handler may not provide an interface to manipulate it.
A request to the export pseudo file will create a pseudo file directory representing the requested GPIO pin. This is done by writing a request to the export pseudo file with a message containing the data the export command needs in order to properly identify the GPIO pin requested. This message is then processed by the GPIO export sysfs handler in the Linux kernel to create the pseudo file folder representing the GPIO pin along with the pseudo files that provide the interface between the user application and the sysfs handler for the specified GPIO pin. The handler provides the layer between the physical GPIO pin and pin device driver and the pseudo file representation or interface.
The unexport pseudo file removes the GPIO pin pseudo file so that interacting with the represented GPIO pin from a user application is no longer available.
Note concerning PWM sysfs support: Just as there is support for GPIO pins through the sysfs interface and /sys there is also support for PWM pins. The root folder is /sys/class/pwm and the functionality is similar in architecture to that for GPIO pins. There is a similar export and unexport functionality to make the PWM pins available and using the exported PWM pseudo files are through standard file operations on a set of files associated with a pseudo file folder representing the PWM pin. See Using PMIC PWM on Dragonboard410c which describes the basics of "PWM is exposed via MPP_4 pin, which is pin 28 on the Low Speed Expansion Connector."
The boot script changes
The boot script changes use the /sys/class/gpio/export to create the requested GPIO pseudo file. However the created pseudo file has a set of default access permissions that are set when the pseudo file is created. Since the creation is during initialization with root privileges, the chmod command is used to allow any user application to interact with the created pseudo files and not just the user, root, which created them.
Since the export is being done during boot up and initialization, the intent is to create GPIO pin pseudo files which will stay in place while the device is powered up and to stay in place as long as the device is in use.
Each GPIO pins on the low power connector of the DragonBoard 410C are represented by several pseudo files, value which is used to communicate the value of the pin (whether it is high or low) and direction which is used to communicate the direction of the pin (whether it is an input pin or an output pin). So we need to do a chmod on each of these pseudo files we want the user application to access including the pseudo file folder in which these pseudo files are located, for example /sys/class/gpio/gpio938 which contains /sys/class/gpio/gpio938/value and /sys/class/gpio/gpio938/direction.

Android 7 reserved IP ports restriction

In Android 7, there is a range of reserved IP ports.
This is indicated in the file /proc/sys/net/ipv4/ip_local_reserved_ports:
32100-32600
My application uses a port in that range and I get an error "bind : address already used".
So, I wanted to know if there is a way around this restriction?
I thought to modify the file and exclude the port that I use. In fact I have rooted my device, modified the file but changes were not picked up by the kernel.
Even if the file has been modified, if I restart the device the changes are lost.
Is there a way to circumvent this restriction?
Or somehow force the kernel to take into account my changes?

From https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt:
ip_local_reserved_ports - list of comma separated ranges
Specify the ports which are reserved for known third-party
applications. These ports will not be used by automatic port
assignments (e.g. when calling connect() or bind() with port
number 0). Explicit port allocation behavior is unchanged.
The format used for both input and output is a comma separated
list of ranges (e.g. "1,2-4,10-10" for ports 1, 2, 3, 4 and
10). Writing to the file will clear all previously reserved
ports and update the current list with the one given in the
input.
Note that ip_local_port_range and ip_local_reserved_ports
settings are independent and both are considered by the kernel
when determining which ports are available for automatic port
assignments.
You can reserve ports which are not in the current
ip_local_port_range, e.g.:
$ cat /proc/sys/net/ipv4/ip_local_port_range
32000 60999
$ cat /proc/sys/net/ipv4/ip_local_reserved_ports
8080,9148
although this is redundant. However such a setting is useful
if later the port range is changed to a value that will
include the reserved ports.
Default: Empty
So, I wanted to know if there is a way around this restriction?
I suggest you to use a different port, or else your system may become unstable for a system service may be using a port in that reserved range.
Is there a way to circumvent this restriction? Or somehow force the kernel to take into account my changes?
Since you rooted your device you can try sysctl. These links may help: Android Edit Sysctl Settings and https://forum.xda-developers.com/showthread.php?t=1470125.

tcpdump - Bizarre output over 3G/mobile data on Android

I am capturing packets over 3G on Android and I get an output that is bizarre. I see mac addresses instead of IP addresses and have no clue how to decode it. I see the IP addresses when I run the same capture over WIFI. It appears as if the link type needs to be changed for 3G interface.
Currently, I only see "EN10MB (Ethernet)" option under the list of Data link types (tcpdump -L). I see different link types on tcpdump website (http://www.tcpdump.org/linktypes.html) and I think probably I somehow need to recompile the source, so that I get "LINKTYPE_GPRS_LLC" under Data link types to get the right capture.
Does anyone know how to do this? I have the source for libpcap (v0.9.8) and tcpdump (v3.9.8) (one that comes along with AOSP 4.2.1 source).
Thanks and I really look forward to hear from you guys.
Here is a sample output that I get for a capture over 3G interface:
ping google.com
tcpdump -vvvs 0
22:11:51.450906 40:00:40:11:12:18 (oui Unknown) > 45:00:00:38:66:22 (oui Unknown), ethertype Unknown (0x1528), length 56:
0x0000: 4a4b 4201 2107 bad2 0035 0024 5a5e 140c JKB.!.��.5.$Z^..
0x0010: 0100 0001 0000 0000 0000 0667 6f6f 676c ...........googl
0x0020: 6503 636f 6d00 0001 0001 e.com.....
22:11:52.363748 00:00:fd:11:0c:9c (oui Unknown) > 45:00:00:e8:ed:ed (oui Unknown), ethertype Unknown (0x4201), length 232:

So, here's what solved the problem.
Looks like when we explicitly specify the interface name (cdma_rmnet4 in my case) or do not specify any interface (in this case it automatically assumes the interface to be cdma_rmnet4), it gives the same garbled output.
But when we capture it with “-i any” flag, it does capture on some “LINUX_SLL” interface, which gives the correct output. I googled it and found out that LINUX_SLL is Linux cooked mode capture by libpcap to capture from the "any" device and to capture on some devices where the native link layer header isn't available or can't be used, which is the case with 3G/mobile packets.

If by "Currently, I only see "EN10MB (Ethernet)" option under the list of Data link types (tcpdump -L)." you mean that, when you run tcpdump -L, that means that, on the interface on which you're capturing, the only link-layer header type it claims that it can supply are Ethernet headers.
If that's what it's supplying, tcpdump should be reporting the right packet data.
If that's not what it's supplying, then the driver or networking stack on the version of the Linux kernel your mobile phone/tablet is running is broken - it's supplying the wrong ARPHRD_ value to libpcap, which is then passing that lie on to tcpdump or whatever other program is using libpcap.
The best way to fix this would be to fix the driver or whatever is supplying ARPHRD_ETHER. Unfortunately, a quick look at the 3.11 kernel's include/uapi/linux/if_arp.h doesn't show an ARPHRD_ value that appears to be intended for this.
Note, however, that this is NOT necessarily LINKTYPE_GPRS_LLC! That LINKTYPE_ value is for GPRS LLC frames, as described in 3GPP TS 04.64; those can encapsulate Subnetwork Dependent Convergence Protocol frames, which can encapsulate IP frames (at least according to the Wireshark dissector for GPRS LLC frames), but Android might be using some completely different link-layer headers. GPRS is NOT a 3G service; I think 3G data uses a different link layer.
Tcpdump does not know how to dissect GPRS LLC frames, so, IF that's what the driver is supplying, that wouldn't help without changes to tcpdump to understand GPRS LLC and the Subnetwork Dependent Convergence Protocol.
A quick look at tcpdump's output, and at this similar Wireshark question, suggests that the link-layer type might be LINKTYPE_RAW - the first octet of an Ethernet frame is the first octet of the destination address, so it appears that the first octet of those frames is 0x45, which is also the value that the first octet of an IPv4 frame without options would have (IP version 4, header length 5 32-bit words or 20 bytes).
Try, as an experiment, a version of tcpdump that treats DLT_EN10MB as if it were DLT_RAW; if that works with the 3G interface, then either the drivers or networking stack need to be changed to supply ARPHRD_NONE to libpcap or libpcap needs to look at the device name and, for the Android device or devices in question, map ARPHRD_ETHER to DLT_RAW rather than DLT_EN10MB. What's the name of the device on which you're capturing, i.e., the argument to the -i flag? If you didn't pass an argument to -i, what is the output of ifconfig -a on Android?

Add IMEI and MAC to wlan0 to Genymotion/AndroVM

Is there any way to add IMEI to AndroVM (now Genymotion) or any other Android Emulator. And also I want MAC address for wlan0 port. We already have emulators which contain MAC at lan0 port but not for wlan.
How can we do so?
if someone in your acquaintances has done so please ask them to contribute.
Details:
I am trying to build a cloud based Android App testing center as my pre final year college project for partial fulfillment towards my Bachelor of Technology (Computer Science) degree.
I am wondering how we can get more configurations for Genymotion.
Or if you can provide me with more device configurations and if it is possible to build configurations for genymotion for different devices very quickly.
Secondly, How to add MAC addresses and IMEI number to the builds?
We are trying to emulate a mobile device (non Google nexus) to make a cloud based testing centre.
For this we are trying to use androVM (Genymotion) and we are facing a few problems
What have we done so far
Building the androVm source code in "VBOX86tp-userdebug" mode from the scratch after following the steps given on official Android website.
After building the source code on a virtual ec2 server, typing the emulator command runs but its blank.
And if possible can AndroVm be run in "Fastboot" mode so that we can install it on the device.
We have been working on "building the androVm" from source code and trying to accomplish few tasks like
Running it with the img's available after the building process is complete.
Making it portable ie creating an iso/ova out of all the stuff found in the out directory.
What we have tried till now
Downloading of the AndroVm source code
initializing the repo using repo init
Downloading the source code using repo sync
choosing the lunch menu using lunch
choosing vbox86tp-userdebug
Other menus full-eng didn't work so discontinued
Few errors that came our way
Make errors: they were pretty straightforward so resolved
system.img was not being generated: resolved by making it again
bin/bash jar command error: happened to be the path error resolved by the exporting the path to jar command.
Few Questions
What an OVA file consits of and how can it be created? From what I have seen it contains few VMDK's and few configurations files attached to it,
How to convert the platform specific image files(system.img ramdisk.img userdata.img) into an OVA or ISO file.
If at all we are missing few files to give to the emulator, can you just name them.
Also how to add IMEI number
We already have MAC for eth0/1 port but we want it on wlan port
Now to make things interesting
This is the reply I got from Genymotion Team:
I want my project to cover various configurations but for starters if i can get something like Samsung Galaxy phones and tab or as a
start if I can get Samsung galaxy tab 2.
You can change the screen size and DPI for each virtual device. You
can toggle navigation bar and virtual keyboard. However, we cannot
provide virtual devices that contains proprietary applications like
Samsung.
Now here what we get is the MAC address of eth0/1 port. What if I need wlan MAC.
Unless one of the two network interface have been disabled, there
should be 2 interfaces, 2 IP, and 2 MAC addresses: adb shell ip a. 2:
eth0: mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 08:00:27:d4:fe:e0 brd ff:ff:ff:ff:ff:ff
inet 192.168.56.101/24 brd 192.168.56.255 scope global eth0
inet6 fe80::a00:27ff:fed4:fee0/64 scope link
valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:c8:37:e7 brd ff:ff:ff:ff:ff:ff
inet 10.0.3.15/24 brd 10.0.3.255 scope global eth1
inet6 fe80::a00:27ff:fec8:37e7/64 scope link .
Sorry, but we do not provide support for specific ROM. However, I
strongly recommend you to visit the community at:
https://groups.google.com/forum/#!forum/genymotion-users
1. What an OVA file consits of and how can it be created ?From what i have seen it contains few VMDK's and few configurations files
attached to it,
"The entire directory can be distributed as an OVA package, which is a
tar archive file with the OVF directory inside."
(http://en.wikipedia.org/wiki/Open_Virtualization_Format)
2. How to convert the platform specific image files(system.img ramdisk.img userdata.img) into an OVA or ISO file.
If at all we are missing few files to give to the emulator, can you just name them.
Please read the community tutorials
3. Also how to add IMEI number
There is currently no way to add IMEI number. This feature will come
in the near future
4. We already have MAC for eth0 port but we want it on wlan port
There is 2 interfaces: eth0 and eth1. Eth0 is used for Genymotion
application widgets. If this network connection is broken, Genymotion
would not be able to start anymore. Eth1 is used for network current
access (fake WiFi connection). You can change this network
configuration as you want.

It is a common practice for mobile applications to identify the user by IMSI number (associated with the SIM card) or IMEI number (unique ID of the device). Of course, it is also possible on Android:
TelehponyManager manager = (TelehponyManager)getSystemService(TELEPHONY_SERVICE);
String imei = manager.getDeviceId();
String imsi = manager.getSubscriberId();
This code works perfectly fine on a real device, however under emulator IMEI is always all-zero and it’s not configurable. It quickly becomes awkward when debugging a network-enabled application which uses IMEI as a user ID.
Trying to resolve the problem I first looked at the TelephonyManager service, just to find the following snippet:
private IPhoneSubInfo getSubscriberInfo() {
// get it each time because that process crashes a lot
return IPhoneSubInfo.Stub.asInterface(ServiceManager.getService("iphonesubinfo"));
}
Fair comment, isn’t it? It really made my day :)
Anyway, code analysis shows that IMEI/IMSI request goes down through all the telephony layers (see the diagram), eventually getting to the baseband device. In case of emulated system, rild daemon is used together with libreference-ril.so – reference Vendor RIL library which talks to the baseband modem device using plain, old AT commands.
The modem device itself is emulated outside the Android system, as part of qemu (which is the heart of the emulator). Details of the communication between the emulator and the Android system running inside the emulator are interesting on its own (all the communication goes through a virtual serial port, Android system’s qemud daemon is used to (de)multiplex the data). I’ll try to post a brief introduction to the topic soon.
Virtual modem implementation can be found in external/qemu/telephony/android_modem.c. The most important part of the file is this function:
const char* amodem_send( AModem modem, const char* cmd );
This function is called for each received AT command. For each command sDefaultResponses array is searched for a given command and either predefined response is sent, or a command handler is executed. The array itself looks like:
static const struct {
const char* cmd; /* command coming from libreference-ril.so, if first
character is '!', then the rest is a prefix only */
const char* answer; /* default answer, NULL if needs specific handling or
if OK is good enough */
ResponseHandler handler; /* specific handler, ignored if 'answer' is not NULL,
NULL if OK is good enough */
} sDefaultResponses[] =
{
/* ... */
{ "+CIMI", OPERATOR_HOME_MCCMNC "000000000", NULL }, /* request internation subscriber identification number */
{ "+CGSN", "000000000000000", NULL }, /* request model version */
/* ... */
};
Two array rows cited above are responsible for IMSI and IMEI retrieval. As you can see, both values are hardcoded and there is no chance to modify them without recompiling the emulator.
However, an old-school hack comes in handy. The emulator binary is not encrypted nor compressed, so the string literals should be visible inside the emulator binary. In fact they are, and IMEI number can be modified in a few simple steps:
** backup the emulator binary
** open the binary with your favourite hex editor
** search for +CGSN string followed by a null byte, it should be followed by 15 digits of the IMEI number
** edit the number, be careful not to change the number of digits
** save the file, that’s all!
Sure, it’s not a perfectly comfortable solution, yet better than nothing. In the next part I’ll explain how to make IMEI number a configurable option. Enjoy!

How to know the MTU size of Android Smartphone

Any command to know the MTU size of Android?

You should use the NetworkInterface class to query and obtain the network interfaces, then call getMTU().

Today, looking into the code of netcfg I saw that the configuration of the interfaces is located into /sys/class/net.. and then I thought of you! (I read your question yesterday)
If you have root access, open a terminal and run
cat /sys/class/net/<interface>/mtu

Methods to know the MTU size of Android:
from terminal: ifconfig $DEVICE | egrep addr\|MTU
through Android Debug Bridge (adb):
adb shell netcfg | grep UP to find the desired address and
adb shell ip addr show rmnet0 in case of rmnet0 or
adb shell cat /sys/class/net/rmnet0/mtu in case of rmnet0 (as described by #patedit)

Without ROOTING your phone, you may use a ping command from a Windows/Mac/Unix system. Though, the syntax of ping-options is very different for different OS.
For Windows
try this:
ping /l 1473 /f 10.68.34.75
/l <Size> — Specifies the length, in bytes, of the Data field in the echo Request messages sent. The default is 32.
/f — Specifies that echo Request messages are sent with the Do not Fragment flag in the IP header set to 1 (available on IPv4 only).
Adjust the payload using the -l command-line option. When you reach the higher limit, you will see this message and you will find the MTU size :
> The packet needs to be fragmented but DF set.
More details: https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router

1480, I believe, but you can check by using ifconfig $DEVICE with a rooted device, and checking the MTU there.

For most network access, MTU could be resolved by MTU Discovery. You can use Ping command with different payload size and don't fragment to find aChrysler value. Good luck

Without ROOTING your phone, you may use a ping command from a Windows/Mac/Unix system. Though, the syntax of ping-options is very different for different OS.
From most Unix/Linux/Mac systems (Without ROOTING the phone)
You might share the internet connection from your phone, and then from any PC connected to your android-phone run ping commands:
ping www.yahoo.com -s 1413 -M do
man ping says:
-s <packetsize> — Specifies the number of data bytes to be sent. The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data.
-M <pmtudisc_opt> — Select Path MTU Discovery strategy. <pmtudisc_option> may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag).
Adjust the payload using the -s command-line option (for example: 1200, 1300, 1400, 1500, 1450, 1425, 1440, ...). When you reach the higher limit, you will see a message like this and you will find the MTU size :
> From 192.168.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1500)
ping: local error: Message too long, mtu=1500
My answer is based on this one for windows: answer #25165641