Re: tap interface address

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Mon, 11 Aug 2008, der Mouse wrote:

> >> I... doubt that.  tap_dev_ioctl() returns ENOTTY (as it should).
> > Mm, maybe you are right, but the program shows no error (is ENOTTY
> > rewritten to something else in the dev code?)
>
> More likely, it seems to me, is that userland recognizes ENOTTY
> specially and doesn't report any error in that case.
>
> Or is "the program" custom code?  This guess is based on the assumption
> that it's a stock tool like ifconfig or netstat.

"the program" was the minimal test code attached :)

The other program I'm working on is more complex but not quite ready (a
Bluetooth PAN daemon - its fairly complete and I'm using it now, am just
tidying up some loose ends)

This 'implements some of the features of an ethernet bridge' according to
the spec, and I wanted the address of the interface so I can do some half
intelligent routing. Currently, the tap channel is '00:00:00:00:00:00'
which actually doesn't cause much trouble (If I don't see a unicast
address, I broadcast the packet all around) but its not very clean.

Also I was considering rewriting the address and hiding the MAC address of
the tap from the bluetooth clients (with more than one radio, you can't
just set it to the bluetooth MAC address). This would solve a slight
problem where (with my windows mobile phone) the remote device won't seem
to talk to the tap, it will only speak to the 'directly connected' device
address, but I'm not sure that its 'proper' to rewrite addresses in this
way?

iain