I found a cool site with some great stuff for summer, I thought it may be helpful to you too, here is the link https://clck.ru/BanUr
Looking forward, Cliff McDiarmid
From: connman [mailto:email@example.com]
Sent: Tuesday, August 08, 2017 11:49 PM
Subject: I demand more Josephine.
These are the only iems in this price range that I have tried. I have seen recommendations for Shure SE215 (I think there is a version with a mic/volume control), which are reported to have slightly more bass emphasis. You could also try the Hifiman RE-400i which many have said are very neutral but may be light on bass.
Sent from Mail for Windows 10
I work for a company that makes a "router"-like product with 2 ethernet
interfaces (WAN+LAN). When the product is shipped to customer, it is setup
with dhcp on WAN (eth0) and static IP on LAN (eth1).
The customer is free to reconfigure the network settings, the above is
just the factory default.
Today we use /etc/network/interfaces+ifup/ifdown to achieve this. It works
fine, but it's a hassle for the customer because they don't like editing
cryptic textfiles. We would like to migrate to connman and offer the
customer the ability to configure the device through a webinterface that
apply network changes through the connman DBUS API.
We've been able to get connman running and we can configure it through its
API, it's great. The issue we're facing now is how to setup factory
defaults. We've tried to provision services with configs, but as
provisioned services are immutable it does not fit our use-case.
One could write updates to the service config files since connman monitors
and reloads these, but then we might aswell continue using
/etc/network/interfaces since the whole point of migrating to connman was
to configure through the DBUS API.
Is there a way to provide a "factory default" for each Ethernet-interface,
without making the services immutable?
Hi Daniel, Patrick, et al,
This email is to try and convince you to spend some more time on the discussion that started back in January , and ended with .
The background of the patch is this: our devices, running ConnMan, are unattended. And of course one could argue that customers should always use Ethernet for making things robust, but they don't. Therefore we also need our wifi setup to be as rock solid as ever possible.
And by design that is a bit difficult with wifi, as the client can't always distinguish between wrong password and no signal. Currently ConnMan will give up after a few retries, on assumption that the password must be wrong and because it doesn't want to keep retrying. Since -some- APs might block it then. I've never had my phone, nor my laptop, forget a wifi password. And, at least before we applied the RFC-d patch, we, and our customers, have seen ConnMan 'forgetting' the password..
So, can we reopen this discussion? Last status was:
> Daniel wrote:
>> So that means we have three options:
>> 1) connman.conf, global knob
>> 2) config file no D-Bus API
>> 3) D-Bus API
>> All of them have their downside. Patrik what is your stand?
> To me, 2) has the distinct downside of not being useful.
To me, 1) would be most simple to use, implement, document and understand. And (of course) the default behavior should not be changed.