Re: tuntap apparently misbehaving on osx

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

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))
)

-anil

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 10.0.0.1?
> IPv4: dropping proto 2
> IPv4: dropping proto 2
> IPv4: dropping proto 2
> ARP: transmitting probe -> 10.0.0.1
> EXN: Failure("tap: partial write")
> ARP: updating 10.0.0.1 -> 1e:81:8c:9d:18:0c
> EXN: Failure("tap: partial write")
> EXN: Failure("tap: partial write")
> 
> via "tcpdump -i tap0", pinging 10.0.0.1 from a terminal gets me nothing;
> pinging 10.0.0.255 shows echo requests from 10.0.0.1 -> 10.0.0.255, and
> responses from 0.0.0.0 -> 10.0.0.1 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?!)