How to stop wanproxy combining multiple small TCP packets into a larger packet ...

Tue May 27 18:05:22 PDT 2014

John,

You need some sort of framing layer in WANProxy itself, and even then you
can't rely on WANProxy to do that work.  The former may be coming, the
latter thing is harder, y'see: it's really up to the TCP stack when to send
data and how much.  You may have better luck tuning segment sizes and such
in your TCP stack than trying to do it in WANProxy.  You *can* get clever
with this stuff at the application layer, but it's really a wrong approach.

Let me know if you need any additional help or pointers; apologies if this
doesn't respond to the whole of your message.  I'm on the road and wanted
to respond to you immediately.

Thanks,
Juli.

On Tue, May 27, 2014 at 3:55 PM, John Nix <jnix at vobal.com> wrote:

> Hi,
>
>
>
> I have a quick question.  We’ve been using wanproxy for our satellite
> application for a couple of months (version 0.8) and it works pretty well.
> However, we have run into a small issue for our particular application when
> wanproxy on the client side merges combines TCP payload into packets that
> are larger than the maximum transmission unit (MTU).
>
>
>
> Specifically, we have to use an application (for example, built on
> Windows) looking for a stop byte (say 7E) at the end of the TCP payload.
> We can’t readily change the application, so we are stuck working around the
> limitations of the application.  Assume the MTU is for TCP data payload is
> 1400 bytes for the satellite network we work with.
>
>
>
> When wanproxy on the client merges two PSH, ACK packet of say payload 650
> bytes into a single packet with data payload of 1300 bytes, everything is
> OK because the new, single, combined PSH, ACK packet of data payload of
> 1300 bytes ends in the stop byte (7E).
>
>
>
> But, if wanproxy on the client receives three PSH, ACK packets of say 650
> bytes and merges them into 2 packets with data payload of (i) 1400 bytes
> and (ii) 550 bytes, then the application doesn’t see a stop byte of 7E at
> the end of the first, 1400 byte packet.  The application gets “confused”
> and starts to not work properly.  I know the application should be able to
> handle the packets combined properly at the TCP layer the way wanproxy is
> doing it, but the application simply refuses to work with packets where the
> data payload on any TCP packet doesn’t end in the stop byte (7E).
>
>
>
> So, my question is this: how can we either change the wanproxy code or
> configuration so that wanproxy on the client side won’t combine multiple
> PSH, ACK packets received into larger packets?
>
>
>
> Thanks, John
>
>
>
> *From:* Juli Mallett [mailto:juli at clockworksquid.com]
> *Sent:* Sunday, April 13, 2014 9:28 PM
> *To:* John Nix
> *Cc:* wanproxy at lists.wanproxy.org
> *Subject:* Re: How to set peer0 to eth0 and not loopback?
>
>
>
> John,
>
>
>
> Would it be possible for you to try the latest code from Subversion?
>
>
>
> Thanks,
>
> Juli.
>
>
>
> On Sun, Apr 13, 2014 at 5:21 PM, John Nix <jnix at vobal.com> wrote:
>
> Hi Juli,
>
>
>
> After some more “tweaking” and experimenting, I got wanproxy working on my
> systems (client and server).
>
>
>
> But, now the system is not very stable, like crashing after >~10 - <~20
> TCP connections that are very small with about 1 KB of data transfer each
> after about an hour or so.
>
>
>
> I have intentionally disabled the wanproxy compression codec on both the
> client and the peer, since I am less concerned about the compression.  The
> main purpose for now is to send back a syn-ack rapidly on a location that
> is behind a satellite connection with a lot of delay.
>
>
>
> I have a crash file that I could share on a non-public basis, if that
> would be helpful.  Again, the strange thing is the system works for a short
> period of time, but then crashes.
>
>
>
> Thanks, John
>
>
>
> *From:* Juli Mallett [mailto:juli at clockworksquid.com]
> *Sent:* Saturday, April 12, 2014 1:58 PM
>
>
> *To:* John Nix
> *Cc:* wanproxy at lists.wanproxy.org
> *Subject:* Re: How to set peer0 to eth0 and not loopback?
>
>
>
> Thanks, John.
>
>
>
> So you're not having connectivity problems between the WANProxy client and
> server, but between the WANProxy server and the actual upstream server at
> 107.206.YY.ZZ.55123, it seems like?  Obviously WANProxy is working fine on
> your OS, then, in terms of being able to use sockets properly, etc.
>
>
>
> I wonder if there's some other configuration issue.  Is there any chance
> that your WANProxy server, shuttle-XS35, could itself be misconfigured?
>  That is, can you using nc or telnet (or curl) connect to
> 107.206.YY.ZZ.55123 from that system?  Because it's the OS that's deciding
> to use the loopback interface, not WANProxy.  Common causes for this might
> be having the 107.206.0.0/16 network configured on loopback rather than
> on a physical interface, or having 107.206.YY.ZZ as an alias on that
> system, or perhaps a misconfigured routing table.  Because WANProxy should
> be connecting just like anything else would, and it really seems like it
> must be some kind of network stack misconfiguration, but one I'd like for
> us to figure out just to be sure.
>
>
>
> Thanks,
>
> Juli.
>
>
>
> On Sat, Apr 12, 2014 at 11:44 AM, John Nix <jnix at vobal.com> wrote:
>
> Sorry, on clarification is that I test the system from the client by
> issuing the command:
>
>
>
> wget 127.0.0.1:3300
>
>
>
> Instead of using the port number with wget that I mentioned below.
>
>
>
> Thanks, John
>
>
>
> *From:* John Nix [mailto:jnix at vobal.com]
> *Sent:* Saturday, April 12, 2014 1:43 PM
> *To:* 'Juli Mallett'
> *Cc:* 'wanproxy at lists.wanproxy.org'
> *Subject:* RE: How to set peer0 to eth0 and not loopback?
>
>
>
> Hi Juli,
>
>
>
> Thanks for the quick feedback.  My setup/goal is relatively simple, so I
> didn’t expect this issue.  Attached is the client configuration, and the
> server configuration (with slightly redacted/changed IP addresses/port
> numbers).
>
>
>
> So, when I have both the client and server running, and then test the
> system by issuing the command on the client:  wget 127.0.0.1:55123
>
>
>
> I can see wanproxy on the server is sending out the loopback interface
> (not eth0) to reach the server peer, which is my problem.
>
>
>
> Below is an example from tcpdump on the loopback interface of the server
> (again IP addresses slightly redacted), when I issue the wget command from
> the client above.  So, this shows the traffic from wanproxy on the server
> is going back out the loopback interface, but I need eth0. The only
> difference from the standard installation was that since I am on Ubuntu
> 12.04 I had to compile with “poll” and not “epoll” on the server, but I
> doubt that is related.
>
>
>
> I could give you access to the server if that would help.
>
>
>
> Thanks, John
>
>
>
> root at shuttle-XS35:/usr/src/wanproxy-0.8.0/programs/wanproxy#<root at shuttle-XS35:/usr/src/wanproxy-0.8.0/programs/wanproxy>tcpdump -i lo -U -n
>
>
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>
> listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
>
>
>
> 13:29:25.237409 IP 107.206.YY.XX.53699 > 107.206.YY.ZZ.55123: Flags [S],
> seq 212899101, win 43690, options [mss 65495,sackOK,TS val 19955781 ecr
> 0,nop,wscale 7], length 0
>
> 1397327365.237644 [/wanproxy/proxy/proxy0/connector] INFO: Connect failed:
> <Error>/0 [Success]
>
> 13:29:25.237449 IP 107.206.YY.ZZ.55123 > 107.206.YY.XX.53699: Flags [R.],
> seq 0, ack 212899102, win 0, length 0
>
>
>
>
>
>
>
>
>
> *From:* Juli Mallett [mailto:juli at clockworksquid.com<juli at clockworksquid.com>]
>
> *Sent:* Saturday, April 12, 2014 12:42 PM
> *To:* John Nix
> *Cc:* wanproxy at lists.wanproxy.org
> *Subject:* Re: How to set peer0 to eth0 and not loopback?
>
>
>
> You absolutely should not need to go over loopback to connect to a remote
> peer.  Can I ask how you're encountering that behaviour?  Can you include
> your full configuration (redacting IPs if you feel it's necessary) and how
> you're verifying that it's not going out over the external interface?  I
> ask on the last point because it's certainly the case that in some cases
> you may see traffic when doing tcpdump on a loopback interface if that
> traffic originates locally.
>
>
>
> Really, every useful configuration not involving an exterior tunnelling
> system should include at least one non-local peer, so I'm a little confused
> as to what your configuration must be that you're only seeing local
> traffic, or have gotten the impression that WANProxy cannot make
> connections across a network interface.  If you've only looked at a
> configuration which uses SSH as a tunnel mechanism, such as the first
> configuration on http://wanproxy.org/examples.shtml, I'd encourage you to
> look at the second configuration, which connects directly over a WAN, or at
> the SSH optimization examples on http://wanproxy.org/ssh.shtml, for
> inspiration.
>
>
>
> It should be enough to simply modify the peer0 definition to use a
> non-local IP to which you have a route.  If something else is going wrong,
> I'd guess it's some kind of portability bug that I'd like to fix urgently,
> so would appreciate any more information you can give.
>
>
>
> Thanks very much for the report!
>
> Juli.
>
>
>
> On Sat, Apr 12, 2014 at 10:31 AM, John Nix <jnix at vobal.com> wrote:
>
> Hi,
>
>
>
> The wanproxy software looks like a good fit for our equipment connected
> over satellite links.
>
>
>
> Setting it up was straightforward, but I do have a basic question that
> doesn’t seem to be addressed in the documentation or through several
> searches on Google.
>
>
>
> For various reasons, I need peer0 to be on eth0 and not the loopback
> interface.  For example, when use the command ‘set peer0.host “x.y.z.q” ‘,
> and look  at tcpdump wanproxy is sending to x.y.z.q on the loopback
> interface, which won’t readily work for our particular application.
>
>
>
> I expect there are workarounds (like trying to use iptables to redirect
> from lo to eth0, or running redir to listen on loopback, etc.), but the
> simplest would be to have the wanproxy peer on eth0.  In case it matters,
> I’m using Ubuntu 12.04.
>
>
>
> Thanks, John
>
>
>
> -------------------
> John Nix
> Founder and CEO
> Vobal Technologies
> +1-847-350-9998 (o)
> +1-847-452-3754 (m)
> www.vobal.com
>
>
>
>
> _______________________________________________
> wanproxy mailing list
> wanproxy at lists.wanproxy.org
> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>
>
>
>
>
>
>
> _______________________________________________
> wanproxy mailing list
> wanproxy at lists.wanproxy.org
> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wanproxy.org/pipermail/wanproxy-wanproxy.org/attachments/20140527/503081a6/attachment-0001.htm>