Re: mirage-www

[David Scott <scott.dj@xxxxxxxxx>]

Heh, no problem. While I was debugging this I did a bit of "yak shaving" and now have a nice bit of code which can capture packets to a block device-- this may be useful in future.

On Tuesday, September 11, 2012, Anil Madhavapeddy  wrote:
> That was my fault, sorry! This sort of thing should be fixed soon when
> we can share C bindings more easily among the cross-compilation targets.
>
> -anil
>
> On 10 Sep 2012, at 22:31, David Scott <scott.dj@xxxxxxxxx> wrote:
>
> > Right, problem solved: TCP checksum on xen was slightly broken. There
> > was a fix made to Unix to cope with odd-length packets, this needed to
> > be applied to xen as well. Many of the packets had valid checksums,
> > and linux would ACK up to the sequence number in the last one of
> > those.
> >
> > Now that the TCP bug is squashed, I can get back to writing my blog
> > post -- all just a day in the life of a mirage hacker :-)
> >
> > On Sat, Sep 8, 2012 at 9:06 AM, Dave Scott <Dave.Scott@xxxxxxxxxxxxx> wrote:
> >>
> >>
> >> On Sep 7, 2012, at 5:59 PM, "Anil Madhavapeddy" <anil@xxxxxxxxxx> wrote:
> >>
> >>> On Fri, Sep 07, 2012 at 02:02:45PM +0100, David Scott wrote:
> >>>> Hi,
> >>>>
> >>>> I've built mirage-www for xen and modified the static IP to fit my
> >>>> environment. (I tried DHCP first but this didn't work -- if I get the
> >>>> time I'll try to debug).
> >>>>
> >>>> I can ping the server fine, and it's certainly receiving a lot of
> >>>> traffic on my (probably fairly busy) local network. When I try to
> >>>> fetch a URL the TCP connection hangs. On the console I get:
> >>>>
> >>>> Dispatch: dynamic URL /
> >>>> ... irrelevant spam
> >>>> TCP retransmission on timer seq = -889321980
> >>>>
> >>>> I've attached a small tcpdump of the conversation. I started with ping
> >>>> and then tried HTTP. According to tcpdump/wireshark it went like this:
> >>>>
> >>>> $ tcpdump -r mirage.pcap -n
> >>>> reading from file mirage.pcap, link-type EN10MB (Ethernet)
> >>>> 13:47:07.543119 IP 10.80.2.32 > 10.80.239.140: ICMP echo request, id
> >>>> 9300, seq 1, length 64
> >>>> 13:47:07.543756 IP 10.80.239.140 > 10.80.2.32: ICMP echo reply, id
> >>>> 9300, seq 1, length 64
> >>>> 13:47:08.542112 IP 10.80.2.32 > 10.80.239.140: ICMP echo request, id
> >>>> 9300, seq 2, length 64
> >>>> 13:47:08.542422 IP 10.80.239.140 > 10.80.2.32: ICMP echo reply, id
> >>>> 9300, seq 2, length 64
> >>>> 13:47:09.541288 IP 10.80.2.32 > 10.80.239.140: ICMP echo request, id
> >>>> 9300, seq 3, length 64
> >>>> 13:47:09.541609 IP 10.80.239.140 > 10.80.2.32: ICMP echo reply, id
> >>>> 9300, seq 3, length 64
> >>>> 13:47:10.541286 IP 10.80.2.32 > 10.80.239.140: ICMP echo request, id
> >>>> 9300, seq 4, length 64
> >>>> 13:47:10.541580 IP 10.80.239.140 > 10.80.2.32: ICMP echo reply, id
> >>>> 9300, seq 4, length 64
> >>>> 13:47:11.541286 IP 10.80.2.32 > 10.80.239.140: ICMP echo request, id
> >>>> 9300, seq 5, length 64
> >>>> 13:47:11.541932 IP 10.80.239.140 > 10.80.2.32: ICMP echo reply, id
> >>>> 9300, seq 5, length 64
> >>>>
> >>>> -- so far so good, this is just my initial pings. Switching to 'wget
> >>>> http://10.80.239.140/'
> >>>>
> >>>> 13:47:14.241216 IP 10.80.2.32.37158 > 10.80.239.140.80: Flags [S], seq
> >>>> 2284582709, win 5840, options [mss 1460,sackOK,TS val 909789846 ecr
> >>>> 0,nop,wscale 6], length 0
> >>>> 13:47:14.242365 IP 10.80.239.140.80 > 10.80.2.32.37158: Flags [S.],
> >>>> seq 3536243828, ack 2284582710, win 65535, options [mss 1380,wscale
> >>>> 2,eol], length 0
> >>>> 13:47:14.242387 IP 10.80.2.32.37158 > 10.80.239.140.80: Flags [.], ack
> >>>> 1, win 92, length 0
> >>>>
> >>>> -- TCP connection established
> >>>>
> >>>> 13:


-- 
Dave Scott