[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tuntap apparently misbehaving on osx

I've fixed this -- I introduced the bug when "tidying" up the use file
descriptors in the UNIX backend, and missed a conversion from bits to
bytes when unpacking the bitstring.

At leaat this is the exactly the sort of bug that your regress test will
find :-)

Regarding configuring IP addresses, until the Network interface is
converted to use the new device API (which permits plumbing through
configurations from the environment), you need to add it directly
into the source code by adding a Net.Manager.configure line. You can
replace `IPv4 with `DHCP also.

let ip = 
  let open Net.Nettypes in
  ( ipv4_addr_of_tuple (10l,0l,0l,2l),
    ipv4_addr_of_tuple (255l,255l,255l,0l),
   [ipv4_addr_of_tuple (10l,0l,0l,1l)]

Net.Manager.create (fun mgr interface id ->
  let src = None, port in
  Net.Manager.configure interface (`IPv4 ip) >>
  Http.Server.listen mgr (`TCPv4 (src, spec))


On Sat, Sep 17, 2011 at 11:57:12PM +0100, Richard Mortier wrote:
> i'm porting the dns perf suite over to the new regress/ setup.  with the
> unix-socket build, i don't seem to be able to contact it at all - and
> netstat doesn't show anything listening on 53/UDP as i'd expect.  with
> unix-direct then i see the usual startup but then start seeing many
> failed writes:
> : mort@greyjay:net$; sudo _build/unix-direct/deens.bin 
> Password:
> Main: startup
> [00000] 2011/08/17T22:06:39Z  info                Deens: starting server, 
> port 53 
> Manager: create
> opendev: /dev/tap0
> Netif: plug tap0
> Manager: plug tap0
> Manager: plug done, to listener
> Manager: init done
> Devices: starting provider Unix.Blkif
> Main: entering runloop
> ARP: who-has
> IPv4: dropping proto 2
> IPv4: dropping proto 2
> IPv4: dropping proto 2
> ARP: transmitting probe ->
> EXN: Failure("tap: partial write")
> ARP: updating -> 1e:81:8c:9d:18:0c
> EXN: Failure("tap: partial write")
> EXN: Failure("tap: partial write")
> via "tcpdump -i tap0", pinging from a terminal gets me nothing;
> pinging shows echo requests from ->, and
> responses from -> which seems odd.
> similar behaviour if i build the tutorial slideset with unix-direct,
> although with unix-socket it works just fine.
> so- is this a broken setup on my part, or something that's become broken
> due to eg., new device model?  (or am i just missing something really
> obvious?!)



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.