[OpenWrt-Devel] Any hit on how to mount vfat u-disk as "async" option ?

[Tymon]

Hi all,
   I can not mount my vfat format u-disk as "rw, async" option under 
OpenWRT 14.07,
   No matter use shell command 'mount /dev/sda1 /mnt/sda1 -o rw,async' or 
edit the /etc/fstab,
   none of the methods can archive my aim.


   Any hit will be appreciate!!


--
Regards,

banglang huang
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt] Project proposal: The GNUnet of autonomous Things

[Drasko DRASKOVIC]

Hi Daniel,
Very interesting project!

On Thu, Nov 17, 2016 at 12:39 PM, Daniel Golle  wrote:
> Project schedule
>
> (I)
> As a first step towards better integration of typical IoT USE-cases
> into OpenWrt/LEDE, a ubus service allowing access to low-bandwidth
> peripherals shall be created. It's modular design shall allow for
> plugins providing access to various different APIs and low-level
> busses. Plugins may expose read and write access to datastructures
> and emmitt event notifications.
> The ubus API shall be sound and well-documented. Sample plugins
> including verbose comments utilizing and demonstrating that
> infrastructure shall be implemented.

Do we really need this phase? I.e. is ubus the best solution?

We at WeIO (http://we-io.net) used something that we called  IoTPy
(https://github.com/nodesign/weio/tree/master/IoTPy),
but I think today besto solution is to use Intel's MRAA
(https://github.com/intel-iot-devkit/mraa) in combination with UPM
(https://github.com/intel-iot-devkit/upm).

This way user get a bunch of drivers for various sensors and actuators
in different language bindings.

>
> (II)
> Once sensors and actores are available via the local ubus instance,
> a ubus rpc proxy which operates as a GNUnet service shall be implemented
> to allow secure and privacy-aware pairing of OpenWrt/LEDE devices and
> remote access to ubus using GNUnet.

Looks like a sane solution to me. I have started some months ago
working on a centralized solution called Electrolink -
https://github.com/projectiota/electrolink.
It uses MQTT or CoAP to pack and send RPC messages in JSON or CBOR.

Currently we are working on MRAA<->Electrolink integration.

For decentralization - this is worh loking:
https://safenetforum.org/t/maidsafe-and-gnunet-comparison/2779.

Maybe some of scalable blockchain solution (Tendermint? Blockstack?)
are also worth investigating.

Telehash (http://telehash.org/) looks like a great candidate also.

BR,
Drasko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things

[Carlos Ferreira]

Hi Daniel,

I would like to ask you if the Vehicular networks is something that
could also be added in the future to this project of yours.
I mean, there's already alot of development towards 802.11p / DSRC / WAVE.
The linux kernel already supports OCB but despite the existent work
towards providing the atk5k and ath9k support for 802.11p,
ath5k -> https://github.com/Componentality/openwrt-compat-wireless
ath9k -> https://github.com/CTU-IIG/802.11p-linux
there were no merges or patches additions to OpenWRT in the past.

Since Vehicular networks do belong to the IoT context, In my opinion,
it could be something to at least be discussed in the context of your
project proposal.

What do you think?

On 17 November 2016 at 11:39, Daniel Golle  wrote:
> Hi!
>
> I want to suggest a project to be (partially) funded by prpl's OpenWrt
> project grant.
>
> Abstract:
> Implement a secure autotonomous IoT hub using OpenWrt/LEDE's ubus
> service and the GNUnet P2P framework.
>
> Introduction:
> Despite the ongoing hype about the so-called Internet of Things, the
> current practise is rather chaotic and severe structural flaws of IoT
> devices became a common occurance, including easy-to-remote-exploit
> vulnerabilities and brain-dead mistakes such as a hard-coded DNS server
> address rendering thousands of IoT connected devices unusable now that
> the server is no longer being operated.
> Given the continous history of quite predictable security and
> privacy-related catastrophies in the still quite infantile IoT-sphere,
> taking a step back, a radical shift of praradigms, away from the
> patterns of Web/Cloud-based infrastrucure will help providing a much
> more secure and reliable user experience and thereby increase trust in
> future networked applications.
>
> Recent examples of typical problems related to the missing security
> model and centralized control servers:
> http://metropolitan.fi/entry/ddos-attack-halts-heating-in-finland-amidst-winter
>
> Or hard-coded server addresses:
> http://www.out-law.com/en/articles/2016/october/singapore-telco-visits-customers-homes-to-secure-devices-after-cyberattack/
>
> Or missing security by default:
> http://www.bbc.com/news/technology-37750798
>
> From a coders point of view, the lack of a vendor-neutral abstraction
> of low-bandwidth peripherals makes it hard to develop general purpose
> applications which do not depend on a specific hardware or middleware.
>
> This projects suggest a from bottom-to-top redesign addressing the
> diversity of components and local access methods (ranging from
> in-kernel-only drivers to almost pure userland implementations),
> connectivity (NAT traversal, discovery, ...) as well as security and
> privacy-related concerns. As a first measure, a generic integration of
> low-bandwidth peripherals such as simple sensors and actors using the
> OpenWrt/LEDE core infrastructure will provide a great improvement to
> access and manage local IoT features. This may then be used by
> various higher level applications, such as data-logging/monitoring,
> WebUI or machine-to-machine communication.
>
> As dependence on centralized services providing remote access has
> shown to be problematic in terms of security and privacy as well as
> reliability, direct connectivity or application-agnostic indirect
> routing using well-known P2P techniques can bring about more
> interoperatibility and sustainability. GNUnet provides (among with
> many other things) a modular toolkit for P2P, ranging from a
> NAT-aware multi-transport, cryptographically addressed general purpose
> overlay network to pub/sub, filesharing and real-time conversation
> services. In a second phase of the project, this core infrastructure
> is going to be used to provide secure, reliable and privacy-aware
> remote access to IoT features on typical OpenWrt/LEDE target hardware.
> Using GNUnet implies inheriting all the advantages of a secure P2P
> infrastructure which has seen  12 years of intense research and
> several iterations of architectural revolutions within that long time.
> Having a remote-access method for ubus which already provides it's
> own set tools to work in a wide range of environments (think: behind
> NAT, using low-level transports such as UDP, TCP, HTTP and proper
> HTTPS over IPv4/v6 as well as raw bluetooth and wifi injection sockets
> for local area coverage) and got it's own built-in security mechanisms
> as well as management structures (think: a distributed personal PKI)
> also seems to be a very good match, especially due to the modular
> nature of GNUnet which allows using only the parts needed on resource
> constraint hardware. Obviously this may be also very useful for any
> kind of remote-management or other sort of remote-access to ubus
> and/or rpcd.
>
> GNUnet is extremely portable, works on a great variety UNIX-like
> systems as well as Windows and can be compiled using LLVM, thus be
> turned into a in-browser JavaScript-monster 

[OpenWrt-Devel] image.mk prepare sets permissions

[Maciej Skrzypek]

Hey all,

I've added one ssh key to image that needs permissions 0600 (and they are in 
ipk) but I've discovered that final rootfs have 0644 permissions.

Following code (include/image.mk) breaks permissions:

 270 define Image/mkfs/prepare/default
 271 # Use symbolic permissions to avoid clobbering SUID/SGID/sticky 
bits
 272 - $(FIND) $(TARGET_DIR) -type f -not -perm /0100 -not -name 
'ssh_host*' -not -name 'shadow' -print0 | $(XARGS) -0 chmod u+rw,g+r,o+r
 273 - $(FIND) $(TARGET_DIR) -type f -perm /0100 -print0 | $(XARGS) -0 
chmod u+rwx,g+rx,o+rx
 274 - $(FIND) $(TARGET_DIR) -type d -print0 | $(XARGS) -0 chmod 
u+rwx,g+rx,o+rx
 275 $(INSTALL_DIR) $(TARGET_DIR)/tmp $(TARGET_DIR)/overlay
 276 chmod 1777 $(TARGET_DIR)/tmp
 277 endef

I've back tracked this to commit from 2007: 
12c49b6 ("build system cleanup/restructuring as described in 
http://lists.openwrt.org/pipermail/openwrt-devel/2007-August/001159.html;, 
2007-08-07)

Does anyone know why this is needed? I think this wrong for many reasons 
including security.

-- 
Maciej Skrzypek
R Engineer
Information Security Officer
maciej.skrzy...@flytronic.pl
+48 697 550 199
Flytronic sp. z o.o.
www.flytronic.pl
tel. +48 32 461 23 50
fax  +48 32 461 23 54
ul. Bojkowska 43, 44-100 Gliwice
NIP:969 151 39 93, REGON:  240851769, KRS  298330, Sąd Rejonowy w 
Gliwicach, X Wydział Gospodarczy Krajowego Rejestru Sądowego

--
Niniejsza wiadomość jest przeznaczona tylko dla jej adresata i nie może być 
ujawniona osobom trzecim. Jeśli nie jest Pan/i zamierzonym adresatem niniejszej 
wiadomości bądź osobą przez niego upoważnioną do jej odbioru lub przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, dystrybucja, kopiowanie lub 
inne działanie o podobnym charakterze jest zabronione. Jeżeli wiadomość dotarła 
do Pan/i omyłkowo, prosimy o poinformowanie nadawcy oraz usunięcie wiadomości z 
poczty bez otwierania załączników. Dziękujemy.

This e-mail is intended solely for the addressee(s) and must not be disclosed 
to third parties. If you are not the addressee of this e-mail or has not been 
authorized by the addressee to receive or forward this message, we inform that 
its disclosure, distribution, copying or any other similar action is unlawful. 
If you have received this e-mail in error, please notify the sender immediately 
by return e-mail. Please then delete the e-mail from your mail box without 
opening attachments. Thank you.
--



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel