> > - Some protocols use locally set MAC addresses as per specification
>
> I am completely ignorant on this. If you have some pointers
> for reading up that would be really appreciated. Thanks.
The classic example is DECnet. The mac is set based upon the DECnet
node number. Its an uncommon but a
> Personally I think assigning a random MAC address in the driver
> is...unwise. I can't imagine having any success getting that
> changed, though, especially now that addr_assign_type is used
> properly.
Address assignment isn't "random" as such - it's using the ranges
specified for local alloc
> > of /var/lib/connman/settings had no effect; connman still brought
> > eth0 up.
>
> Unfortunately, the AutoConnect setting is per device and stored under
> /var/lib/connman/ethernet_MAC_ADDR_cable/settings.
Thats a fundamental breakage because
- MAC addresses are only required to be unique *
> > I believe you can set the MAC address from the bootloader if this
> > is an option?
>
> AFAIK you can't. In earlier versions of OpenEmbedded the kernel
> (3.0.0 at the time) had been patched to provide the MAC address
> through a module parameter, but the patch was rejected upstream and
> is
> Interesting. Do we get any RTNL messages in the case the MAC address
> gets assigned by user space? Currently ConnMan relies on the fact that
> RTNL is able to tell us whenever something interesting happens with
> interface, and picks it up from there.
I don't know the answer to that one, althou
On Fri, 24 Aug 2012 10:30:44 +0300
Patrik Flykt wrote:
> On Thu, 2012-08-23 at 15:52 +0100, Stavros Vagionitis wrote:
> > With it I mean ConnMan. As far as I remember the rest of the
> > services didn't work, but it's been a while now and I am not 100%
> > sure.
>
> With the patch I proposed de
> Archaic as PID files might be, this patch provides zero overhead for
> those who don't want to or need to use the functionality it provides
> and provides a valuable system integration hook for those that do.
PIDs wrap, PID files are not reliable. At the very least take a lock on
the pid file an
> My take on SIM PINs is that they are pointless.
I would disagree somewhat.
In an embedded environment they are of some value because
- the fs may well be crypted or otherwise protected and is probably on
flash
- the average car thief doesn't talk JTAG anyway
The average car thief however do
> I fully agree here. We try to avoid a Symbian inspired design as much
> as possible. That old way of doing things is not where we wanna go.
Surely an application should be asking for properties it understands -
latency/bandwidth/costing
So a game can ask for "200Kbit, low latency", while an aut
