Wrong data size when reading from TUN device\wrong size of data buffers

[zehome]

Wrong data size when reading from TUN device\wrong size of data buffers

[zehome]

Hi, thank you very much for the bug report.

I'll look into it as soon as possible to fix this.

I noticed yesterday you're working in the same area. Maybe we can share our results, I think this would be interresting :-)

ps: my english is bad too :-)

[rstanislav]

Yeah vtrunkd is also great project but i don't really like how its "done" -
its using only tcp connections and shared memory and based on old vpn
project...way too overloaded and complicated, but it has some great algo's
in it..for speed control and other things
I like your project more, because i think that for aggregation udp is way
more better (yeah its more complicated but at same time it allows to get
max of all avail bw on any channel, where tcp will not allow this because
of sliding window thing...)
I'm working on 3g\slow speed\unstable connections aggregation solution, the
only thing that your project is missing atm is automatic speed control per
channel\ACK of data (so for example when packet lost on 1 channel server
reports that using other channels and client resends it using other
channel) - i'm currently working on this algo and when it will be ready i
will send details with source code to you.

btw also i have found 1 more bug - if REORDER_MAX_SEQ sets low and in
reorder.c code its notices that it segfaults on fprintf

fprintf("[reorder] buffer size can't be more t....

....very strange, i think somewhere in reorder code there is problem with
memory allocation

2013/1/4 Laurent Coustet [email protected]

Hi, thank you very much for the bug report.

I'll look into it as soon as possible to fix this.

I noticed yesterday you're working in the same area. Maybe we can share
our results, I think this would be interresting :-)

ps: my english is bad too :-)

ps(bis): thank you for vtrunkd I'm going to look into it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-11882927.

[zehome]

Yeah ok.

MLVPN was designer for "high speed" lowjitter like ADSL,SDSL as a first goal.

I tried working for 3G/slowspeed/unstable connections with the reorder branch, but without success. There are probably many mistakes on the reorder branch. It was just an unstable experiment.

If you need help debugging or understanding the think, don't hesitate, I'll write as much documentation as needed.

For example, keep in mind MLVPN is using privsep, and the first process launched is the privileged one.
So when you're using gdb, don't forget to "set follow-fork-mode child".

[zehome]

There is a system to dynamically change most parameters (speed included) by modifying the configuration, and reloading mlvpn (SIGHUP).

It is planned to add this feature through the control socket (control.c). Should be trivial to do.

[rstanislav]

I have tried reorder branch with last fixes from master branch and fix for
flush (on timeout do not flush buffer but instead find next packet in seq
and write to tundev) - i'm working now on this part but so far it works
perfectly :) I will commit when finish it.
Also reorder means no need for delay of packets because if packet with high
ms but lower seq not yet arrived next packet will be delayed automaticaly
by reorder logic.

For 3g and unstable connections retransmission of lost packets, reordering
and on the fly weight calculations for channels is key features.

2013/1/4 Laurent Coustet [email protected]

There is a system to dynamically change most parameters (speed included)
by modifying the configuration, and reloading mlvpn (SIGHUP).

It is planned to add this feature through the control socket (control.c).
Should be trivial to do.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-11885036.

[zehome]

Sorry for the delay, still have not checked this.. Will try tonight

[zehome]

I've checked the code and I don't think there is anything wrong. As I am using IF_NO_PI I should never have more than standard 1500 bytes MTU of data.

Let me know if I'm wrong