Re: [MirageOS-devel] More troubles with tcp on ARM

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 11 Apr 2015, at 23:13, Magnus Skjegstad <magnus@xxxxx> wrote:
> 
> On Fri, 10 Apr 2015, at 05:29, Magnus Therning wrote:
>> On Thu, Apr 09, 2015 at 10:18:53PM +0200, Magnus Therning wrote:
>> [...]
>> I did a little bit more testing of this just now, and found something
>> surprising.  This is against a VM on ARM:
>> 
>> ~~~
>> % echo thisisalongerstring | ncat -4 192.168.0.33 18080
>> alongerstring
>> 
>> ->
>> 
>> tcp: 192.168.0.11:48731
>> 6 - 
>> 14 - alongerstring
>> ~~~
>> 
>> and
>> 
>> ~~~
>> % echo thisisalongerstringandthisislongerstill | ncat -4 192.168.0.33
>> 18080
>> alongerstringandthisislongerstill
>> 
>> ->
>> 
>> tcp: 192.168.0.11:48732
>> 6 - 
>> 34 - alongerstringandthisislongerstill
>> ~~~
>> 
>> and if I send a string that is shorter than 6 characters (I'm guessing
>> including the trailing \r\n), then `ncat` hangs and on the ARM I only
>> see a single line of "length - content":
>> 
>> ~~~
>> tcp: 192.168.0.11:48766
>> 6 -
>> ~~~
>> 
>> I do wonder where those initial 6 characters go...
>> 
> 
> Hm - I am able to reproduce this. I have a cubieboard and an x86 Xen
> server connected to the same switch. If I run the unikernel above on the
> x86 server I can access it remotely and from dom0 without problems. It
> also works fine if I run the unikernel in Xen on the cubieboard and try
> to access it from dom0:
> 
<snip>

> I am using tcpip 2.3.1 and mirage-net-xen 1.4.1. 

Can you bisect backwards a few versions to check if this goes away?
I'm a few thousands miles away from my Cubies until Tuesday, so can't
try this out myself.  The usual culprit for such problems is TCP
offload, but this sounds like more of a physical driver issue.  As
another datapoint, does a Linux domU VM have networking?

-anil

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel