[OpenWrt-Devel] Lantiq xrx200: PTM issues

[Martin Schiller]

Just for reference:
I've opened a pull request with a fix here:
https://github.com/openwrt/openwrt/pull/2707

- Martin

On 2020-01-21 06:28, Martin Schiller wrote:
> Ok, I think I've got it:
> 
> The "sk_wmem_alloc" is decremented in sock_wfree() which is called
> by kfree_skb.
> 
> But in ptm_hard_start_xmit() of the ifxmips_ptm_vdsl.c, the skb
> only gets freed immediately, if the skb_headroom is to small or
> the skb is cloned. In this case the skb is copied to a new one and
> the original skb gets freed.
> 
> Otherwise the skb only gets freed after a complete round through
> the TX descriptor table.
> 
> My suggestion would be, to always copy the skb.
> 
> - Martin
> 
> On 2020-01-20 13:45, Martin Schiller wrote:
>> Update:
>> 
>> I've found out now that the ENOBUFS is set by __ip_append_data,
>> because sk_wmem_alloc "overflows".
>> 
>> Martin
>> 
>> 
>> On 2020-01-20 07:09, Martin Schiller wrote:
>>> Hi!
>>> 
>>> I have discovered the following problem:
>>> 
>>> If you have established a PPPoE session via VDSL / PTM connection 
>>> incl.
>>> VLAN tagging and send data with a relatively small send buffer
>>> (SO_SNDBUF), then an ENOBUFS always comes back.
>>> 
>>> We first noticed this with stagnating data transfers over an OpenVPN
>>> connection.
>>> 
>>> Also with iputils-ping, since by default the send buffer is 
>>> relatively
>>> small.
>>> 
>>> You can also force this with busybox ping by using
>>> 
>>> echo "5000"> / proc / sys / net / core / wmem_default
>>> 
>>> minimizes the system default value.
>>> 
>>> Then you send pings with a packet size of e.g. 4000 bytes and the
>>> second package is already in the pants:
>>> 
>>> ------------------------------------------------------------
>>> root @ OpenWrt: ~ # ping -s4000 10.200.1.142
>>> PING 10.200.1.142 (10.200.1.142): 4000 data bytes
>>> 4008 bytes from 10.200.1.142: seq = 0 ttl = 63 time = 20.519 ms
>>> ping: sendto: No buffer space available
>>> root @ OpenWrt: ~ #
>>> ------------------------------------------------------------
>>> 
>>> So it should be easily reproducible for everyone.
>>> 
>>> Traffic that is only routed through the router is not affected.
>>> 
>>> The manpage of sendto says:
>>> -----------------------------------------------------------------------
>>> ENOBUFS
>>>     The output queue for a network interface was full. This generally
>>>     indicates that the interface has stopped sending, but may be 
>>> caused
>>>     by transient congestion. (Normally, this does not occur in Linux.
>>>     Packets are just silently dropped when a device queue overflows.)
>>> -----------------------------------------------------------------------
>>> 
>>> But all former packets have already been transmitted.
>>> 
>>> This issue seems to be in there since lede-17.01.
>>> 
>>> I can't reproduce it with owrt-15.05.
>>> 
>>> Does anyone have any idea how to solve the problem?
>>> 
>>> Martin
>>> 
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> 
>> 
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel