Am 01.04.21 um 14:37 schrieb Gert Doering:
> Hi,
>
> On Thu, Apr 01, 2021 at 02:16:25PM +0200, Antonio Quartulli wrote:
>>> (Of course it makes lots of sense to defer this to iptables etc. on
>>> all platforms that have DCO *and* a reasonable firewall layer... dco-win
>>> will be interesting)
>>
>
Hi,
On 01/04/2021 14:37, Gert Doering wrote:
> Which is actually interesting for mssfix, as that is "on by default",
> so "all configs are incompatible with DCO", by that definition :-)
hehe Arne can confirm, but I think defaults are adapted to what DCO
expects, so mssfix is just disabled by defa
Hi,
On Thu, Apr 01, 2021 at 02:16:25PM +0200, Antonio Quartulli wrote:
> > (Of course it makes lots of sense to defer this to iptables etc. on
> > all platforms that have DCO *and* a reasonable firewall layer... dco-win
> > will be interesting)
>
> Features that are not compatible with DCO are be
Hi,
On 01/04/2021 14:10, Gert Doering wrote:
> Hi,
>
> On Thu, Apr 01, 2021 at 12:47:46PM +0200, Arne Schwabe wrote:
>> In your dco to dco setup you probably
>> don't have mssfix on either side unless you explicitly added iptables
>> rules for that.
>
> Ah, this is interesting and needs to be do
Hi,
On Thu, Apr 01, 2021 at 12:47:46PM +0200, Arne Schwabe wrote:
> In your dco to dco setup you probably
> don't have mssfix on either side unless you explicitly added iptables
> rules for that.
Ah, this is interesting and needs to be documented - "if you want feature
, , together with DCO, it
Am 01.04.21 um 04:38 schrieb Tony He:
> Hi Antonio, Arne,
>
> According to the dump, this issue is caused by fragment. If I set
> link-mtu to 1472 in the condition of encryption "none", it's gone.
> I also can reproduce the fragment in my Linux x86-64 PC and Linux VM .
> They use kernel 5.4. Fragm
On 01/04/2021 09:07, Antonio Quartulli wrote:
> Tony, in the meantime, setting the link-mtu to something lower than 1500
> is the proper workaround.
Sorry I take this last sentence back.
What I was talking all time long was the "tun-mtu".
To fix the MTU issue when there is encapsulation, it's
Hi,
Thanks for providing the info.
On 01/04/2021 09:01, Tony He wrote:
> % ifconfig ovpn-dco0
> ovpn-dco0: flags=81 mtu 1500
> % ifconfig ovpn-dco0
> ovpn-dco0: flags=81 mtu 1500
These values are not what ovpn-dco would set by default.
> log from openvpn client:
> 2021-04-01 14:57:31 net_if
sorry, update transport interface.
% ifconfig enx00e04c680a44
enx00e04c680a44: flags=4163 mtu 1500
inet 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::ec9b:2258:82ec:3cdb prefixlen 64 scopeid 0x20
ether 00:e0:4c:68:0a:44 txqueuelen 1000 (Ether
Antonio Quartulli 于2021年4月1日周四 下午2:35写道：
> Hi Tony,
>
> On 01/04/2021 04:38, Tony He wrote:
> > Hi Antonio, Arne,
> >
> > According to the dump, this issue is caused by fragment. If I set
> > link-mtu to 1472 in the condition of encryption "none", it's gone.
> > I also can reproduce the fragment
Hi Tony,
On 01/04/2021 04:38, Tony He wrote:
> Hi Antonio, Arne,
>
> According to the dump, this issue is caused by fragment. If I set
> link-mtu to 1472 in the condition of encryption "none", it's gone.
> I also can reproduce the fragment in my Linux x86-64 PC and Linux VM .
> They use kernel 5.
Hi Antonio, Arne,
According to the dump, this issue is caused by fragment. If I set link-mtu
to 1472 in the condition of encryption "none", it's gone.
I also can reproduce the fragment in my Linux x86-64 PC and Linux VM . They
use kernel 5.4. Fragment affects the performance
in the low-end devices
Antonio Quartulli 于2021年3月31日周三 下午2:32写道：
> Hi,
>
> On 31/03/2021 08:29, Antonio Quartulli wrote:
> > A packet dump of the whole session may also help.
>
> Before taking the dump, I would switch to encryption "none", as it will
> help understanding what is going on at all levels. (Assuming the pr
Am 31.03.21 um 09:56 schrieb Tony He:
>
>
> Antonio Quartulli 于2021年3月31日周三 下午3:32写道：
>
> Hi,
>
> On 31/03/2021 09:29, Tony He wrote:
> > Hi Arne,
> >
> > I'm going to test encryption "none" to narrow down this issue, but I
> > found your dco branch doesn't support this
Antonio Quartulli 于2021年3月31日周三 下午3:32写道：
> Hi,
>
> On 31/03/2021 09:29, Tony He wrote:
> > Hi Arne,
> >
> > I'm going to test encryption "none" to narrow down this issue, but I
> > found your dco branch doesn't support this.
> > Can you support?
>
> For the sake of this test, could you use the o
Hi,
On 31/03/2021 09:29, Tony He wrote:
> Hi Arne,
>
> I'm going to test encryption "none" to narrow down this issue, but I
> found your dco branch doesn't support this.
> Can you support?
For the sake of this test, could you use the ovpn-cli.c tool in the
ovpn-dco/tests folder? Or that's not a
Hi Arne,
I'm going to test encryption "none" to narrow down this issue, but I found
your dco branch doesn't support this.
Can you support?
Tony
Antonio Quartulli 于2021年3月31日周三 下午2:32写道：
> Hi,
>
> On 31/03/2021 08:29, Antonio Quartulli wrote:
> > A packet dump of the whole session may also help
Hi,
On 31/03/2021 08:29, Antonio Quartulli wrote:
> A packet dump of the whole session may also help.
Before taking the dump, I would switch to encryption "none", as it will
help understanding what is going on at all levels. (Assuming the problem
will still appear)
Cheers,
--
Antonio Quartull
Hi,
On 31/03/2021 07:21, Simon Matter wrote:
>> Hi Antonio,
>>
>> As you know I am porting opvn-dco to my router whose kernel is V4.14.76.
>> After solving AF_NETLINK group issue we discussed
>> yesterday. It finally works. But I encounter another issue :-( . When
>> testing the performance with
Hi,
On 31/03/2021 06:22, Tony He wrote:
> [36981.631546] ovpn_udp_encap_recv: cannot handle incoming packet: -28
> [36982.692005] ovpn_udp_encap_recv: cannot handle incoming packet: -28
Are these the only two lines from ovpn-dco? or is this a "summary"?
The problem might be related to the router
> Hi Antonio,
>
> As you know I am porting opvn-dco to my router whose kernel is V4.14.76.
> After solving AF_NETLINK group issue we discussed
> yesterday. It finally works. But I encounter another issue :-( . When
> testing the performance with iperf3, disconnection occurs
> and recovers after a
Hi Antonio,
As you know I am porting opvn-dco to my router whose kernel is V4.14.76.
After solving AF_NETLINK group issue we discussed
yesterday. It finally works. But I encounter another issue :-( . When
testing the performance with iperf3, disconnection occurs
and recovers after a few seconds
22 matches
Mail list logo
