---
title: "Networking issues"
url: "https://docs.adyen.com/point-of-sale/design-your-integration/network-and-connectivity/networking-issues"
source_url: "https://docs.adyen.com/point-of-sale/design-your-integration/network-and-connectivity/networking-issues.md"
canonical: "https://docs.adyen.com/point-of-sale/design-your-integration/network-and-connectivity/networking-issues"
last_modified: "2020-10-07T09:28:00+02:00"
language: "en"
---

# Networking issues

[View source](/point-of-sale/design-your-integration/network-and-connectivity/networking-issues.md)

On this page we discuss issues that are not covered in the other pages related to your [network infrastructure](/point-of-sale/design-your-integration/network-and-connectivity).

## Dropped network packets when the internet connection is available

#### Symptom

The internet connection is available, but still you notice issues that seem to point to a problem with the network connectivity:

* A high number of `AuthorisedPending` or unauthorized payments.
* Payment terminals that fail to go online or that switch to Store and Forward transactions.
* Terminal applications intermittently failing to load.

#### Cause

The cause can be payment packets being dropped because the **Maximum Transmission Unit (MTU)** is exceeded. The MTU is the largest size packet that can be sent over a network connection. Routers will fragment or drop packets that are bigger.

The MTU for the terminal is shown in the [Endpoints connection test](/point-of-sale/pos-troubleshooting/connection-tests).

The default MTU for payment terminals is 1500 bytes. Part of the MTU is reserved for the Transmission Control Protocol (TCP) and Internet Protocol (IP) headers of the connection. This leaves 1460 bytes for the **Maximum Segment Size (MSS)**. The MSS is the maximum amount of data in bytes that is accepted in a TCP session.

As a packet travels along its network path, more header bytes may be added, for example by PPPoE, VPN, or MPLS network protocols you are using. The terminal is not aware of those additional headers and continues to transfer packets with the default MTU. The network router at your store or data center cannot fragment the packet because the terminal marks payment packets as "Do not fragment". As a result, your router drops the packet even though the internet connection is available.

#### Solution

A good technique to avoid packets being fragmented or dropped, is to lower the MSS. Network vendors refer to this as *TCP MSS clamping*, *TPC MSS ceiling*, or *TCP MSS adjustment*. Here are some resources to help you understand this technique:

* [Cisco - ip tcp adjust-mss](https://www.cisco.com/en/US/docs/ios-xml/ios/ipapp/command/ip_tcp_adjust-mss_through_ip_wccp_web-cache_accelerated.html#GUID-68044D35-A53E-42C1-A7AB-9236333DA8C4)
* [Juniper - Configuring TCP MSS for Session Negotiation](https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/tcp-mss-configuring.html)
* [Linux - Circumventing Path MTU Discovery issues wiuth MSS Clamping](https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html)

Changing the MSS value affects all your network traffic. So before you start lowering the MSS, contact your network support team or the support center of your network vendor.

The standard technique to avoid packets being fragmented or dropped, is [Path MTU Discovery (PMTUD)](https://en.wikipedia.org/wiki/Path_MTU_Discovery). This technique allows network hosts to determine the MTU on a network path. In practice however, most networks do not allow the Internet Control Messages Protocol (ICMP) that this technique relies on.
