Re: measured boot / fTPM and OpenWrt One
Daniel Golle wrote: >> Well, that's certainly true. It is not always possible to talk to the >> outside world from inside that initial boot enclave. That's the detail that >> we need. >> Do we even have a spare GPI(o) pin that can be used for this? >> (It can't be used for anything else) > While I see your point and believe this is generally possible, it's more > than just one bit needed here: It would mean to move the whole GPIO controller > into secure land and then make all the other bits again available to non-secure > land via SMC calls or something like that... Since it would be polled once during boot, I don't think that would be necessary, but I could wrong. What I am concerned about is some way to program it as an output and/or change the way pull-ups are done, and then do a reboot. That's something that reading the details would produce. >> >> > The only option of having secure boot enabled would be to allow users to >> > permanently disable it, otherwise the resulting hardware would not be >> > worth being called "Open", as it would, in fact, be closed. >> >> The board could ship with it disabled, and the user could blow the fuse to >> enable it. > If the fuse was documented or the tool for doing this available without > signing an NDA with MediaTek, then yes. Both is currently not the case. That would be my goal of signing the NDA: then prepare a statement and get MediaTek to approve it. >> Some would argue that a board that ships with a private key in storage that >> is not, at ship-time, protected, is worthless, but I disagree. It's a >> risks/benefits tradeoff. >> (Note: I'm the lead editor for RFC9334) >> >> I've been down this road a few times with other boards, and the supply chain is >> generally very difficult to work with on this. This is one reason I would >> really like to make some progress here. It helps us get in front of the >> situation, providing a good reference on how to do this sanely. >> >> And because I think that many of our (other) platforms will find themselves >> thinking they are forced down the secureboot path by recent UK, USA >> legislation: probably not quite literally by the legislation, but the lawyers >> and PHBs will think it. > It's a bit funny that the blame for that curse commonly goes to the > FCC and UK authorities, because the discussion started with the ETSI > Radio Emissions Directive (RED) 10 years ago... Yes. I don't think that the CRA and RED are gonna push the same thing at this point. >> > dealing with it kinda means living in denial and darkness. Hence, >> > despite all the critizism, I do appreciate your work and effort to allow >> > people to get their hands on OP-TEE, fTPM, ... on the OpenWrt One. >> >> Yes, so this one place that is very hard for people to learn about, because >> the pre-uboot steps are hidden :-( > ARM TrustedFirmware-A is easy to understand code and released under an > Open Source license, we build it from source in OpenWrt for that platform. > OP-TEE is an Open Source project as well, and so is Microsoft's fTPM. > Just got to put the pieces together, but the pink elephant are the missing > documentation and tools for the efuses to make the BootROM validate bl2 > signature... I've read the source (OPTEE) code, compiled it, sat at IETF Hackathons with ARM core people at hackathons who work on this stuff, but *their* test hardware is almost always virtual. So, it's exactly that pink elephant is what I'm after. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
measured boot / fTPM and OpenWrt One
Daniel Golle wrote:
> On Mon, Apr 29, 2024 at 03:04:37PM -0400, Michael Richardson wrote:
>>
>> {sorry for the long delay, been unwell}
>>
>> Bjørn Mork wrote:
>> > Maybe it is possible to deploy the system with secure boot and a
>> > protected IDevId key by default, but allowing the user/owner to erase
>> > the key and disable secure boot? This way all use cases could be
>> > supported, including playing with the BL2 code etc.
>>
>> It won't work that way. If someone can easily turn off secure boot,
then so can malware.
> Malware cannot remove or add a physical jumper or press a physical button
> on the board (we got a jumper to write-protect the SPI-NOR flash).
Well, that's certainly true. It is not always possible to talk to the
outside world from inside that initial boot enclave. That's the detail that
we need.
Do we even have a spare GPI(o) pin that can be used for this?
(It can't be used for anything else)
> The only option of having secure boot enabled would be to allow users to
> permanently disable it, otherwise the resulting hardware would not be
> worth being called "Open", as it would, in fact, be closed.
The board could ship with it disabled, and the user could blow the fuse to
enable it.
I am not really a fan of secure boot, I prefer measured boot.
To get that, we need to have a possible fTPM enabled, and this generally has
to happen before u-boot. This is annoying, I agree.
If you look at the diagram at:
https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/master/sw/yocto/boot.html
which is *not* our CPU/SOC, but is probably consistent with things, then you
see that to get fTPM, it happens before u-boot.
Some would argue that a board that ships with a private key in storage that
is not, at ship-time, protected, is worthless, but I disagree. It's a
risks/benefits tradeoff.
(Note: I'm the lead editor for RFC9334)
I've been down this road a few times with other boards, and the supply chain is
generally very difficult to work with on this. This is one reason I would
really like to make some progress here. It helps us get in front of the
situation, providing a good reference on how to do this sanely.
And because I think that many of our (other) platforms will find themselves
thinking they are forced down the secureboot path by recent UK, USA
legislation: probably not quite literally by the legislation, but the lawyers
and PHBs will think it.
I've removed the rest of your well-thought discussion about minimal security.
What I care about it getting an initial credential into the device, and to be
able to leverage that to get HTTPS for the admin interface, and for that to
lead to APIs for managing IoT devices.
> dealing with it kinda means living in denial and darkness. Hence,
> despite all the critizism, I do appreciate your work and effort to allow
> people to get their hands on OP-TEE, fTPM, ... on the OpenWrt One.
Yes, so this one place that is very hard for people to learn about, because
the pre-uboot steps are hidden :-(
>> I hope we can go the other way.
>>
>> I'm willing to do the legwork, and I can sign an NDA if necessary, and
then
>> communicate what needs to be said.
> NDA with whom? MediaTek?
Yes, probably it is required. I'd rather not, but if necessary someone has
to figure out how to leverage the details out.
> When it comes to OpenWrt and the OpenWrt One: As a first step we would
> have to come up with the methods to run the necessary PKI infrastructure
> in a democratic and distributed way, without requiring any NDAs and
> without any single point of responsibility or potential bus-factor.
Yes. I think that there are some reasonable options.
I had hoped to chat about this over beer at the summit, but in the end,
I've had to cancel my travel ;-(
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
{sorry for the long delay, been unwell}
Bjørn Mork wrote:
> Maybe it is possible to deploy the system with secure boot and a
> protected IDevId key by default, but allowing the user/owner to erase
> the key and disable secure boot? This way all use cases could be
> supported, including playing with the BL2 code etc.
It won't work that way. If someone can easily turn off secure boot, then so
can malware.
I hope we can go the other way.
I'm willing to do the legwork, and I can sign an NDA if necessary, and then
communicate what needs to be said.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Bjørn Mork wrote: > Michael Richardson writes: >> Having orange and red pieces "secured" *does* mean that u-boot updates would >> have to come from openwrt. > Does it? Is it possible to modify the BL2 to verify signatures of the > BL31 and BL32 stages only? I don't know. > If not, is it feasible to deploy an automated fip.bin signer, taking an > any unverified U-Boot binary as input and building a signed fip.bin for > the OpenWrt One using verified BL31 and BL32 blobs? I wouldn't want to do this in too automated a fashion. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
John Crispin wrote: >> using OP-TEE and fTPM. > pretty high on my list once we find the time > https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html > https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/optee-dispatcher.html Where you thinking about OP-TEE as the BL32, or were you thinking that we could attempt this: OP-TEE OS after boot via an SMC call by enabling the option for OPTEE_ALLOW_SMC_LOAD my reading of this is that it only works if you securely boot a linux kernel. If we had a securely boot (the u-boot checks the signature) linux kernel, then nobody could change their kernel. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Daniel Golle wrote: >> In the first PDF, there is mention of: >> Security Support 2 * 256-bit multi-key on OTP eFuse >> Support 64 version OTP eFuse for anti-rollback > Those features require proprietary tools provided by MediaTek only to > clients under NDA. Unless some 3rd-party reverse-engineers those > tools, we won't ever use those features. Also note that those 256-bit > keys are *symmetric* keys probably, so not that useful for IDevID. Yes, I know they are symmetrical. Typically, the way that a 256-bit seed is used is that it is blown in the MediaTek fab with a strong random number. This seed is then provided via secure storage to the OEM (us). [You ought to be thinking Johnny Nmemonic, but in practive, I think it's a USB drive with a password protected .xlsx file, sigh] Our factory then uses the seed to generate a (256-bit ECDSA) keypair, for which a CSR and then certificate are generated. The private key is securely erased, and the certificate is loaded into the device. The device "simultaenously" uses the seed to generate the same keypair, and it now has the private key that goes with the certificate. This process has become common, but it doesn't have a good name. https://www.ietf.org/archive/id/draft-irtf-t2trg-taxonomy-manufacturer-anchors-03.html#name-carrot-method-key-setup-bas (I tried to rename the methods: (A)vocado, (B)amboo, and (C)arrot, but that was considered too whimsical by some) >> which is often the key to getting IDevID deployed, but I didn't find further >> mention of that in the three datasheets. > Another option for deploying IDevID is using MMU to prevent access to > the SPI-NOR I/O range from non-secure land and handling cryptographic > operations entirely in the secure enclave, e.g. using OP-TEE and fTPM. > This is possible without burning any fuses and without any proprietary > tools (but will probably not be implemented in time for the firmware > which will ship with the device -- however, it can be done after, I > can help and point who ever wants to do it to the right directions.) If we are going to use OP-TEE to get an fTPM enabled, then that can be used for IDevID, and it's much faster (and rather more secure) than i2c interfaced discreet chips. But, it means more factory work for us. Usually, the ARM TrustZone must be initialized pretty early, at the latest in our u-boot. https://mediatek.gitlab.io/aiot/doc/aiot-dev-guide/master/sw/yocto/secure-boot.html Has a nice picture of how the various *SECURE BOOT* goes together. This is not for this CPU/SOC, but the Genio eval cards. My guess is that it's probably pretty common across their line, and it's within epsilon of other ARM processors. The issue is that we don't want SECURE BOOT, at least not past u-boot, because that would get in the way of the people who want to use this board. We might want the orange, and red pieces in the diagram. My suggestion (which I think is feasible) is that we put a signed u-boot onto the board, but that we turn u-boot verification of Linux-kernel/initramfs (the "FIT" stuff) *off*. Owners can install their own signing keys and sign their images if they want to do that. Probably, we can leave measure boot on. Measured boot collects the hashes (into the fTPM usually), and then asks a third party if they are okay. https://www.rfc-editor.org/rfc/rfc9334#name-two-types-of-environments-o Having orange and red pieces "secured" *does* mean that u-boot updates would have to come from openwrt. That's descending into a thresherous way < https://www.gnu.org/philosophy/can-you-trust.html > a bit. Probably we can offer to sign other people's u-boot images; but probably there won't be more than a dozen such requests. An alternative is that we find a way not to sign or initialize the BROM/TF-A secured boot, leaving those fuses unblown, and leave this to end owners to do. That might be impossible, and my experience with other ARM boards is that unless they get the fTPM loaded by the OAM board manufacturer, it just doesn't work out. ps: I'm willing to operate and secure the PK *I* junk that is needed to make this all work. It won't pass PCI on round one, but I'm sure if that was important, it could be done. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
John Crispin wrote: > On 12.04.24 15:30, Michael Richardson wrote: >> Is the MT7981B specification available publically at this point? >> >> I can find a 7986 sheet on hackaday, but who knows how it differs (marketing >> people and their numbers) >> > Hi > http://mirror2.openwrt.org/docs/ Thank you, I'm reading through now. I didn't grok all the GPIO pin sharing, there are a lot of choices there which I think you've already made when you listed the high-level specs. Will we be able to support the: "the hardware-based NAT engine with QoS embedded in MT7981B" Any IPv6 support down there? Yes, for various tunnel protocols even. Is it the "NEON"? I see 64 Tx queues for wired ethernet, but I imagine Dave Taht will want to know if there are per-host queues for the wireless. Hmm. Well, it looks like there are at least 4, but I could have mis-understood. In the first PDF, there is mention of: Security Support 2 * 256-bit multi-key on OTP eFuse Support 64 version OTP eFuse for anti-rollback which is often the key to getting IDevID deployed, but I didn't find further mention of that in the three datasheets. I found: 11008014 GLOBAL_SEC_EN, but I think it has to do with locking down the timers, or some I2C thing. (I turned on hypothes.is while reading the PDFs, if someone wants to see my notes) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Is the MT7981B specification available publically at this point? I can find a 7986 sheet on hackaday, but who knows how it differs (marketing people and their numbers) signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Bjørn Mork wrote: > Michael Richardson writes: >> I'd really like to find a way to work with your manufacturer to get an >> IDevID certificate into each unit as it is manufacturered. > For those of us who are not going to pay USD 100 for a document we > won't be able to comprehend anyway: Do you have a pointer to a "IDevID > howto for dummies"? Hi. The IEEE is rather daft, the 2018 version of 802.1AR is available free of charge, but it does require hoops. There isn't much content in it that you can't find in RFC5280. > I assume the private key must be protected on the device. What are the > hardware requirements? There are no hard and fast rules. It certainly would be best if it's in some enclave. But, my take is that something is better than nothing > What's the root of the IDevID, and why do I trust it? It's a private PKI root that we'd have to establish. > What's the lifetime of an IDevID certificate? Unlimited? The spec says: notAfter: 1231 > Are there any special constraints to consider when validating an IDevID > certificate? They don't tend to contain fqdn SAN, so the rules of RFC6125 (now RFC9525) do not tend to apply. > What's the typical usecase on a device like this? Signing short lived > device generated TLS server certificates for e.g a local https server? > Signing client certificates for CPE management (tr-x69 etc)? That's one. Or establishing a mutual TLS connection to a CA (RFC7030 for instance) that would then be able to provision a WebPKI anchored cert. > Do you ever use the IDevID certificate directly, or is it always just > an intermediate CA? Depends upon the use case. In the RFC8995 onboarding situation, it would be used directly during bootstrap, but then probably replaced with an LDevID with a more accessible private key. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One / project update
Thank you for the update. I'd really like to find a way to work with your manufacturer to get an IDevID certificate into each unit as it is manufacturered. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Bjørn Mork wrote: > antennas. I realize that such a case will be relatively expensive. But > without it all you have is yet another midrange dev board. This is > your chance to make a device which shouts "OpenWrt!!!" whenever someone > sees it. Just like the original WRT did. Not that that design was > something to brag about beauty wise :-) I'm now imaging a case, literally in the shape of the letters "OpenWRT!!!". (The !!! are the three antenna) signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Dave Taht wrote: > So I at least do not feel a huge urge to get on the 6ghz bandwagon at > this time. I would actually, be happy cutting even more multiplexing > latency out of the ath9k chips, and there is much fat left to be cut > from the mt79 also, and the benefits of many people focused on building > on top of a single stable *inexpensive* platform and working all the > bugs out of it - that has a lot of shared characteristics with the > higher end gear - cannot be underestimated. I still have wndr3800s > running for years at a time, running openwrt. +1. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Chuanhong Guo wrote: >> * What is the purpose of the console USB-C port? >> - Holtek UART to USB bridge with CDC-ACM support on USB-C makes the >> device ultra easy to communicate with. No extra hardware or drivers will >> be required. Android for example has CDC-ACM support enabled by default > There are several MCU-based CMSIS-DAP projects out there. They can > provide a CDC-ACM serial with a JTAG interface. It may be a bit slow if a > USB1.1 MCU is picked, but it should be enough to start a bootloader to > unbrick the device. I don't quite understand the difference; as long as it still has a USB-C it's fine. My take on this is that while *I* can unbrick most things, there is still a mental overhead in doing so... I think that for many of that would buy a few (dozen), that one thing many us will do is locate the device at a neighbour/relative/community-space that we "support" in order to reduce the burden to us. Being able to walk someone else through plugging something in is a big win. "When you hit enter, does it say openwrt#"? and if the answer is no, then we have to do that 100km drive to visit the device. I would appreciate a switch chip, since that lets us do DSA and different things with different ports, but I can live without it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: bcm27xx: squashf/f2fs sysupgrade broken because overlay is not padded/erased
Lukas Zeller wrote: > I really need help to even figure out a feasible idea to fix this, let > alone implement it in a clean way. What comes to my mind so far is: > - trying to just zero out enough blocks after the squashfs data in > `target/linux/bcm27xx/base-files/lib/upgrade/platform.sh` > platform_do_upgrade() to make sure a subsequent mount_root will NOT > attempt to mount broken remains of an f2fs. However, as this function > also still handles ext4-only case and even multiple partition images, > I'm not understanding this well enough to see how to do that properly. I'm not really clued in to the subtlies here, but it seems like a TRIM is missing that would have told the SDcard that there was just no data after the new image. That should result in zeros being returned rather than garbage. > - rearranging things to separate the squashfs/f2fs case from the > platform specific ext4 case, i.e. using the standard way of creating > the empty or restored overlay f2fs right after writing the new > squashfs, as default_do_upgrade() does. Only on bcm27xx, there's no > mtd, but mmc. So this would require even more in detail knowledge I > don't have. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Ethernet switch with linux/openwrt and DSA
Janusz Dziedzic wrote: >> > Finally buy: D-LINK DGS-1210-48 G1. >> > Also - HP 1920-24G JG924A works correctly. > But what about future? Is there any new device we can buy and use > openwrt there? Or even 2.5Gbps/5Gbps? > So far just buy used/older devices. mcr> Is this a device that is still for sale? I have some control plane mcr> things that I'd like to test on a variety of switches. I using the mcr> Zyxel GS1900 now. My testing is way behind. > ZyXEL GS1900-48-EU0102F (new one) will be also fine? Assuming it boots openwrt, more ports is more interesting to me than faster ports. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Ethernet switch with linux/openwrt and DSA
> Finally buy: D-LINK DGS-1210-48 G1. Is this a device that is still for sale? I have some control plane things that I'd like to test on a variety of switches. I using the Zyxel GS1900 now. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Security changes - restricting uhttpd addresses
Peter Naulls wrote: > Nevertheless, the security people are looking at this config > statically, and not seeing that it's bound to the LAN interface IP > only. I don't think they are really security people, but... > For my use, I've changed the default binding to the LAN IP, and also > added another init.d script to check the current LAN address, and > update the uhttpd config if need be and then restart it (and add > a config hook to the network config). Obviously this isn't > very satisfactory, open to better suggestions here. So, it needs to bound to *all* the IPv6 "LAN" IPs. That means: a) the ULA that is created. b) the LL-IPv6 that are always present c) the GUA IPv6 that is delegated And when we make guest LANs, we may also need to bind it to that, because there are things that guests might need to know, such as seeing the status page to see if the network is up. > It might also be better if uhttpd could be configured to bind > to a specific interface rather than knowing its IP upfront, but > that might be impractical. It's totally impractical. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: qoriq: Problem with u-boot compilation (dual arch issue)
Paweł Dembicki wrote: > I am preparing support for the T4240RDB board. But I'm stuck with one > problem: > Qoriq target is powerpc64. But T4240RDB in u-boot is supported as > mpc85xx family and requires a 32-bit compiler. Seems like you might need to just use two build trees. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Jo-Philipp Wich wrote: > Bluntly speaking, DSA is the thing that gives you one Linux network > device per switch port and bridge VLAN filtering is the stuff that > allows you declaring swconfig-esque VLAN port groups on top of an > arbitrary bridge interface. .. > Another conceptual issue I see is that people came to expect a > dedicated "switch" configuration ui which is something that does not > really work with DSA devices anymore since there is no dedicated switch > hardware entity to interact with anymore (DSA takes care of completely > abstracting this away from the user point of view) and that > bridge-vlans just happen to be a configuration detail of a bridge, and > that there happens to be a bridge "br-lan" by default, but a system > could have multiple bridges, or none at all. > So we should also explain why there is no central "switch > configuration" anymore and that this does not translate into a loss of > functionality, but that the former semi opague swconfig switch > configuration entity was dissolved into a bunch of ethernet devices > inside a bridge... +1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: Don't enable ULA IPv6 addresses by default in new config
>>>>> Baptiste Jonglez writes: > - there have been various bug reports [1, 2, 3] in 19.07 and 21.02 > where ULA addresses basically break global IPv6 connectivity. These > bugs have not been solved in several years, indicating a probable lack > of interest for ULA from the OpenWrt developer community. Seems to be a) a bug in MacOS. b) a bug reported in french, where my reading is that an he.net tunnel is involved. I don't see anything about ULAs here. c) a bug where a client didn't get a GUA, and not surprisingly, couldn't ping the internet. "so I suppose IP assignment is fine." But they weren't because the router didn't assign a v6 prefix to the LAN. Having ULAs available is critical to efforts to do HTTPS to the router. Please do not change this default. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: Don't enable ULA IPv6 addresses by default in new config
> Baptiste Jonglez writes: > ULA IPv6 prefixes (Unique Local Addresses, RFC 4193) are not routable > on the Internet. As such, they have very limited use, and enabling > them by default causes more problems than it solves: > - if an OpenWrt device already has external IPv6 connectivity with > globally routable addresses, then ULA addresses are not useful. That's just not the case. ULAs are intended to be the IPv6 version of RFC1918, useable for local communications. Please go read RFC7084. ULAs are required, and OpenWRT has been a leader here. I strongly object to this proposal. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH/RFC] kernel-defaults.mk: get rid of BuildID
please forgive me stupidity, I couldn't understand the last part of your recommendation: Daniel Golle wrote: > Hence, to achieve reproducible builds we will either have to resort to > identical containers/VMs for building or get rid of the BuildID hash > alltogether (or use a different build-id style) A) identical containers/VMs B) get rid of BuildID C) use a different build-id style > At this point, this seems to be what Debian is doing as well in order > to achieve reproducible kernel builds, see[1]. And which is Debian doing? :-) > [1]: https://wiki.debian.org/SameKernel#How_this_works I read this page and I think it's temporarily (B), but unclear if they are going to (A). (I prefer a path that leads to the build-id meaning that the same versions of the same compilers on the same host OS were used, but it would be nice not to require the same compile of those compilers...) signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Paul Spooren wrote: >> "Codeberg e.V. is a registered non-profit association based in Berlin, >> Germany" So, this makes me feel better. > I’ll write them an email asking for their long term ideas of > maintaining Gitea. Just because is a “e.V.” and in Germany doesn’t make > it super sustainable, trustworthy or anything. Agreed, but at least it might have a governance model that does not depend upon three guys doing it only their spare time as a lark. (And then getting bored or married or having childen.) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
Thank you for this great report! I did not know codeberg existed, but when I looked, discovered I already had a login! I would go with codeberg. It's okay that many community repos are on git, git makes cloning easy. Who is funding codeberg, and how stable is that funding? "Codeberg is not a corporation" <- maybe they mean "not a VC sponsored for-profit corporation" Because even Greenpeace is incorporated, and therefore has a clear governance model, and set of bylaws. "Codeberg e.V. is a registered non-profit association based in Berlin, Germany" So, this makes me feel better. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Support for Google Onhub devices
Thomas Deselaers wrote: > I have an Onhub router and some Google Wifi repeaters. Google recently > announced that they are going to shut down the support for Onhub > (effectively bricking them) by end of 2022. :-( https://killedbygoogle.com/ > I have done a bit of research and it seems like there was some > preliminary support for OpenWRT on these devices at some point. I guess > there will be a lot of Onhubs that would be pretty good OpenwRT routers > in about a year - which otherwise, are probably going to the trash. It would be nice, if as part of Google's commitment to reducing waste, https://sustainability.google/ "We do everything with the Earth in mind. Building on our leadership position as the world’s largest annual corporate purchaser of renewable energy, we continue to innovate ways to make our operations more sustainable, inspiring others to follow. " if Google could just turn over/upstream their code base. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: uml: drop target
I haven't used the UML target in the past year, but I have used it a lot before. The ability to do hostfs mounts is very nice. If it went away, I'd be sad, it's not a disaster as you say. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Rich Brown wrote: > - Having a firm feature freeze date decreases stress. If a particular > feature is done/substantially working, it goes in. If it's not quite > ready, it can skip this release, and get into the next release. (The > alternative is what I think happened with DSA. It was a big change: > there were a large number of problems that took a long time to iron > out. That kept pushing out the date...) I think you are bang on here. And it needs to be socially acceptable to skip. And yet the release is the forcing function. In order to get things sorted for things like DSA, in an ideal world it would be a choice of two different packages. The safe one as the default, and the unstable one as a patch. Of course, that's hard to do for many things. In working backwards on dates, identifying the things that might be a problem and having a "developer beta" from an easily rebased branch would help for stuff like DSA. > - Customers (our users, our industry partners) gain confidence in > projects that can meet their deadlines. Imre noted that "industry is > using the snapshots..." but I suspect the extended schedule just > worries other vendors. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: edgerouter-x DSA switch does not forward bridge-in-bridge packets correctly
{I'm ignorant about most things DSA, and I'm asking for clarification}
Fabian Bläse wrote:
> In the above configuration, frames between Ethernet port eth0 (vlan2
> untagged) and port eth4 (vlan2 tagged) are not
> forwarded. Interestingly, the router itself is able to reach devices
> connected to eth0 and eth4, when pinging on the 'bridge2' interface.
> Frames between untagged ports (e.g. eth0 and eth1) are forwarded
> correctly and frames between tagged ports (eg. eth3 and eth4) are
> forwarded correctly.
It sounds like the hardware bridge expects the host to do the bridging
between tagged and untagged ports. That's my guess.
> Also, tagged frames are incorrectly forwarded on untagged ports, so it
> is possible to reach a device connected to eth3 (tagged) on eth2
> (tagged).
This is rather concerning.
It sounds like the hardware bridge is completely unaware of the tagging.
> This issue does not appear, if the 'bridge1.4' interface is configured
> without an additional bridge, so the second bridge seems to be
> interfering with the hardware offloading.
Why do you configure this with two layers of bridge?
I think that bridge1 is hardware offloaded, right?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
Enrico Mioso wrote: > As you may guess from the thread, the community doesn't want or like to > have this feature "easily" accessible due to it's security > implications. As someone who worries a lot about this, I prefer to include this feature rather than having people make up worse options. > Still, for me having this feature would be very very helfpul. I agree. I don't think we'd ever want it in an official build, but for anyone doing their own builds, this is useful. This also will help when/if we can come to some agreement on how to do better/secure onboarding. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
Alberto Bursi wrote: > "unique" per-device passwords like most vendors are doing are low security > and relatively easy to brute force once someone has disassembled the firmware > and learned the algorithm used to generate them. They rely on obscurity for > most of their security, which is not really a thing for an open source > project. If they devices are shipped with such derivable passwords, then they violate the California (now US) regulations, and also the come UK ones. We can do better, and we are doing better. > They are also completely useless for DYI users that are just flashing a > couple devices. > With much less effort you can just ship a pre-made wifi config file with your > own settings and passwords, and that's what many are already doing. Many devices have USB ports, and I'd suggest having a standard names .json file that can be fed into uci in some way. I think that this solves a lot problems. Have to make sure that vfat support is included in the base image because... users. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
for this pointer... but can you give us the whole URL for those of us who don't speak Portugese (and google translate doesn't seem to have helped). > [2] not really: openwrt sysugrade *does not help* in that there is no way to > add variable information to an already *finished* image file, to be used on > first-boot only, and which would *survive a factory reset*. Nishant Sharma wrote: >> So, to safely and responsibly enable wireless by default in a device (or >> firmware) you're delivering to a third-party, you need that "per-unit >> unique wireless password" per device thing most vendors are doing. >> >> [2] not really: openwrt sysugrade *does not help* in that there is no >> way to add variable information to an already *finished* image file, to >> be used on first-boot only, and which would *survive a factory reset*. >> > How about a first-boot script that enables the Wi-Fi if it is disabled > and then sets the password (if not already set) using the first MAC > address it finds on the device? The MAC address is considered public information. This process will not satisfy the UK and US regulations on it's own. Would a (secret) key hash of the MAC address satisfy it? The UK https://www.ncsc.gov.uk/ people I spoke with said that it would technically satisfy https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf but not the spirit of it. And that this was a compromise position when preparing EN303645. And, in a source-code available system, we really have no way to keep the secret we'd need... secret. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Enabling Wi-Fi on First boot
Enrico Mioso wrote: > I wasn't sure about uci-defaults being the correct way to do it - I was > under the impression it could happen that my script gets ran when it's > too early and /etc/config/wireless hasn't been generated yet. > If this isn't the case, then I think it's fine! I haven't tried uci-defaults for the SHG project. Working on Turris MOX, we had two things we needed to tweak: 1) onboard eth0 needs to be WAN port (it has many modes due to different way MOX can be assembled) 2) enable PCIe wifi with an unencrypted ESSID, and with only a very select set of ports open (DNS, 443) so that our app could connect and take control on a TOFU basis. To be sure that we got it all, we booted up, tweaked a bunch of UCI things, and then rebooted to make sure that all the right things happened. signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [19.07.7] failed to sysupgrade the newifi router
zhengfish wrote: > Hello, Guys Today I build one image for newifi router using 19.07.7 > release. However while I try to reflash the router, it fails. >Seems it cannot read one key, I don't know what's this key? And how > to correct it? It means that the image is signed by a key that your device does not recognize. The possibilities are: 1) your current image was self-built, and did not include the release keys 2) your new image was self-built, and did not include the release keys. 3) some other failure. If you are self-building, then you should ahve the public key you can copy over. I think that sysupgrade also an option to skip the check, but I can't double check that from my laptop at the moment. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 3/3] realtek: add support for ZyXEL GS1900-8HP.
Stijn Segers wrote: > Op woensdag 6 januari 2021 om 11u22 schreef Michael Richardson > : >> The 1900-8/8HP are discontinued by ZyXEL, but the GS1900-16 and 24E seem to >> still be in production. > How do you know? At least the 8 and 8HP are still being sold (doesn't say > anything > about production). They aren't listed as discontinued on their sit either, > from > what I can tell. https://www.zyxelguard.com/GS1900-8HP.asp says so. (was first google hit) https://www.zyxel.com/us/en/products_services/8-10-16-24-48-port-GbE-Smart-Managed-Switch-GS1900-Series/specification does not say anything though. I can find the GS1900-10HP on amazon still though. >> Do you think that they might be similar? >> How is the switch function managed? DSA? or? > Realtek is a DSA target on OpenWrt. On my 10HP e.g. I have lan1 through lan10 > and > a bridge interface for the LAN. Cool, this is exactly the view that I'm looking for, as I need to do different L3 things on each interface. I am acquring a device... so I'll be able to give you feedback on the code. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: 20.xx: postponse LuCI HTTPS per default
Paul Spooren wrote: > The current list of release goals for 20.xx states[0] that LuCI should > use HTTPS per default. This works by creating on-device a self-signed > certificate. Self-signed certificates result in warnings and may cause > more harm than good, multiple discussion are found in the mail archive. > As no clean solution seems in reach while 20.xx seems close, I'd like to > suggest to postponse HTTPS LuCI (`luci-ssl` vs `luci`) per default. > This isn't a vote but a request for developer/user opinions. I agree with postponing this. I think that we need to do some work on this problem. This is a subset (an easier subset actually) of a general IoT onboarding problem. I would like to form a design-team to figure out what we can do in practice, and I would be happy to lead/act-as-convenor it via a series online working meetings if the group wants. The need for a PPPoE username/password is one of the challenges. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SAD DNS cache poisoning attack
better if dnsmasq just implemented https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 which alas, has never become an RFC, AFAIK. Alternatively, DNSSEC was designed to deal with the entire gamut of DNS cache poisioning. More fiddling with ICMP source ports is not going to help in the long run. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Bas Mevissen wrote: > A security conscious user/administrator would install a router without any > untrusted computers connected to the LAN side and setup the device properly > before allowing others to connect. The WAN side connection is not important, > as Luci is not listening there by default. sure. What do security unconcious people do? > previous OpenWRT install. Then the user can setup the WAN side if needed and > upload (from local PC), generate (self-signed) or acquire (e.g. Let's > Encrypt) the certificates for Luci. After that, the connection is switched to > HTTPS and HTTP switched off. This is a a good story, but it doesn't have to be the only story. > The only issue I see, is how to transfer admin, WAN and WiFi passwords at > first boot in a secure way. Even though the user/admin should be alone on the > connection, sending those unencrypted over the line is not desirable. Maybe > those can be encrypted using client side javascript. There is nothing you can with javascript here that wouldn't just be security threatre. If you had anchors you could trust, then it would be done. > The challenges IMHO are being able to safely retain previously installed > certificates over OpenWRT reflashes/upgrades and having user friendly tools > to get new certificates uploaded, generated or acquired. For the latter part, > some configurable service to periodically download and install certificates > from an external host might be desirable (that's how I do it with my NAS > boxes at home). You need a name is DNS, then it's just a dns-01 challenge. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Alberto Bursi wrote: >> Fernando Frediani wrote: > I am not sure click >> though certificate warning is that much of a > security issue in this >> context neither OpenWrt should have certificates > issued by default >> if I understood it correctly. >> >> > Most people accessing OpenWrt LuCI interface knows what it is and >> would > not find it strange to have to accept a self-signed >> certificate. Also > OpenWrt devices mostly are accessible from >> internal and restricted > networks and not exposed to the >> Internet. Still if necessary it is > still possible to add its own >> valid certificate to it on those cases > where necessary. >> >> So, let me invert your logic to explain the issue. >> >> Because of the lack of certificates, and the hassle with click-through >> issues with self-signed certificates, access to the OpenWRT LuCI >> interfaces are restricted to people who know what it is. Only highly >> trained people know how to accept a self-signed certificate. > I think calling "highly trained people" someone that knows how to click > on two buttons on a web browser interface is a bit too much. That's not the point. in fact, it's entirely opposite of the point. The *training* is knowing when you can click on the two+ buttons, and when it is imprudent to do so. The mechanics of the clicking is entirely irrelevant. Training users to click through those warnings is exactly what browser makers are trying to avoid, and browser makers have been trying to make the exception harder and harder to find. Many would like it removed. And, for good reason, because it is almost always inappropriate for most non-technical users to do that. [Children, (grand)parents, etc...] So, honestly, anyone that needs screenshots to figure it out, should never be clicking through the links. > I mean, someone goes to the length of installing a custom firmware on a > router/AP/nas/whatever, which involves finding the firmware file, > finding the procedure to flash it (and in many devices you must use So, just to be clear, are you saying that we should design openwrt to only be useable by developers? Home routers are critical parts of the home IoT ecosystem. OpenWRT is shipped in millions of devices by manufacturers too lazy to bother doing much. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Fernando Frediani wrote: > I am not sure click though certificate warning is that much of a > security issue in this context neither OpenWrt should have certificates > issued by default if I understood it correctly. > Most people accessing OpenWrt LuCI interface knows what it is and would > not find it strange to have to accept a self-signed certificate. Also > OpenWrt devices mostly are accessible from internal and restricted > networks and not exposed to the Internet. Still if necessary it is > still possible to add its own valid certificate to it on those cases > where necessary. So, let me invert your logic to explain the issue. Because of the lack of certificates, and the hassle with click-through issues with self-signed certificates, access to the OpenWRT LuCI interfaces are restricted to people who know what it is. Only highly trained people know how to accept a self-signed certificate. As a result, most devices are accessibly only from internal networks, and usually never exposed to the Internet. Default passwords remain unchanged, and malware infected a vulnerable PC easily attacks the OpenWRT LuCI interface. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
Stefan Lippers-Hollmann wrote: > On 2020-10-04, abnoeh wrote: >> Few months ago there was some debate for how we handle certificate for >> luci page: make user to click though certificate warning is not that >> great for security so here is a proposal for autometically assign a >> worldwide unique subdomain and how to make valid certificate for it, >> and make sure we and connect to the device he is expecting. > […] > The elephant in the room remains, how do you propose to deal with > firstboot conditions? Not every internet connection can be > auto-detected, the most common examples would include having to > configure VLAN tagging on WAN or adding PPPoE credentials. > For these, > the user will have to accept a self-signed certificate at least once > for doing the initial configuration - at which point they can just > stick to the already accepted self-signed certificate as well. There are really three use cases. 1) hardware that comes with openwrt. There is a manufacturer controlled first boot. (This is relatively easy, and I have running code) if we can build that subordinate CA that issues for longer than the 90 days that the device is likely going to be in a box (in a warehouse). 2) hardware that didn't come with (this version) of openwrt, but is first flashed. This probably a common case for most readers of this list, and yes, we are probably smart enough to deal with self-signed certificate the first time. But, we are a small group. 3) hardware that was running a version of openwrt with certificates, but had to be factory default'ed. It would be nice to keep some identity things across such events. (The MOX has a private key that is stored across such events, for instance) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A proposal of https certificate assignment system for luci
abnoeh wrote:
> Openwrt as project get a CA certificate with name constrained to only
> able to sign subdomains of [luci.openwrt.org]. this makes we
> Technically Constrained Subordinate CA, (from let's encrypt or
> digicert), let's call it the Openwrt CA here (CA ) this makes we don't
> create too much load to normal CA like let's encrypt, and as we have
> complete control of this zone we can give subdomains as we want like,
> and don't need full audit like fully pledged CA and handled like a
> wildcard cert for them, but the CA system can be hosted by us and
> request won't offloaded to upper CA's server. (except OCSP request, but
> it can be cashed)
While this is a technically correct solution, it may be politically impossible.
The CABForum insists that any Subordinate CA that we might get has to be
constrained by the CABForum rules.
If we don't comply, then Mozilla/Google/Apple will force whatever root CA
that signs us to revoke the subCA. (I think that this really really sucks)
That's essentially why Enterprise subordinate CAs have gone away.
The CAs now offer to host Enterprise CAs in their cloud, where they can do
all the right things to remain compliant. Most enterprises find that
annoying and expensive, and so they go the way of generating their own
private CA.
If we can live with the constraints, and can find a CA willing to delegate a
subordinate CA to us, then let's try.
> {everything below will be done on https or otherwise encrypted channel}
> 1. on first boot, router want to get it's luci certificate send its ssh
> host key to Openwrt CA reserve subdomain base32(hash of public
> key).luci.openwrt.org (like onion v3 addressed does)
> 2. Openwrt CA sends nonce to our router
> 3. router signs nonce+timestamp+[hash of CSR] with sent ssh host key,
> and send back to openwrt CA send this signed message with CSR
> 4. Openwrt CA verify other end controls host key match
> with hash and confirmed the CSR, sign the certificate with (key from
> CSR/SAN with domain we derived from host key) and sent back to router
> 5. router now has valid cerfiticate, redirect 192.168.1.1 or openwrt
> lan to https version of signed subdomain
This an interesting process, leveraging the SSH key as part of the unique part.
I prefer to use ULA, and to find a way to store ULA in eeprom.
However, I think you are assuming a RA/DHCP-based WAN connection.
For PPPoE (which is still a thing in a lot of places, including developing
world, where last mile is often wifi), this won't work that well.
> now user only have to check :
> 1. page has valid certificate
> 2. the subdomain is match with device's ssh host key
> and this verify it's the device we wanted.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] self-signed certificates for LuCI
Stijn Tintel wrote: >> The question came up if we really want RSA certificates for LuCI or if >> the faster and "more modern" ECC P-256 wouldn't be a better choice. >> >> If px5g is added to the next release, certificates are generated on >> first boot and most users are unlikely to manually recreate RSA ones, >> not? >> >> So the question, shouldn't we drop all crypto options from the new >> px5g implementation and _only_ offer P-256? Whoever wants something >> else than the default may use px5g-mbedtls or some OpenSSL based tool? > I'm no expert, but I recently came across this article: > https://gravitational.com/blog/comparing-ssh-keys/ > While it is about SSH keys, it talks mostly about algorithms used, and > the article suggests using either RSA or Ed25519, not DSA or ECDSA. Yes, both DSA and some forms of ECDSA require a good random number. If the random number can be predicted, then an observer can actually derive the *private* key from the signature! Scared the pants off me when I learnt this 20 years ago. There are ways to use ECDSA where the number input is derived in a way that is not subject to this attack, and most libraries do that now. DSA/DSS has all sorts of other stupid things that make it way worse than RSA (despite what the GNUPG team said for a few years a decade ago) > Additionally, https://safecurves.cr.yp.to/ claims neither P-256 nor > P-384 are safe. Bernstein has maintained for sometime that the NIST/Certicom curves were derived in a specific way that permitted some secret factorization. I understand his concern, and given the choice, I would use EdDSA in new work rather than ECDSA. But, browsers do not support EdDSA well yet, so ECDSA it is for now. However, to date (despite Snowden) only the NSA knows what they did to P256/P384, if they did anything. I would suspect that if they can do something, it's not that cheap, and they can't undo all communication magically. (Like in the movie _Sneakers_) > Based on this information, I would NAK this. Unless an expert proves me > wrong. I would NAK on _only_ P256. I am fine with P-256 by default. I see no reason to support RSA. I would always want a second curve deployed, and for that I'd pick one of the brainpool curves: will browsers support them, I have no idea. EdDSA is really a different algorithm, and browsers do not support them yet. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] self-signed certificates for LuCI
Bjørn Mork wrote: >> I have running code that deploys LetsEncrypt certificates to devices in the >> "factory". This requires a DNS name for dns-01 challenge. >> That's clearly not feasible for random end-users who flash openwrt on their own. >> I would like to explore some additional options here. > Do you set up the device to periodically renew this certificate? Or do > you let your managment system renew and push? What if the device is > disconnected for longer periods? Will the certifcate be renewed on next > boot? Both are problems and todos. Do don't push certificates, we will pull them when we write the renewal code. If the device is disconnected for a long period, and then is reconnected, then it will be renewed on next boot. The *challenge* is that the device might get connectivity until a human puts a correct PPPoE username/password into it. This is not a problem in every environment. In some places, PPPoE is on the wane because of FTTH, in others, it is used even more thanks to FTTN deployments... Often TPIA is only meaningfully deployable when there is PPPoE. That might not be possible until the device has a valid certificate on it... I am considering if we can retrieve the valid certificate using an App, (via LTE) and then push it to the device using HTTP. It's public info, and it's easy to validate if the device got a correct certificate. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] self-signed certificates for LuCI
Paul Spooren wrote: > On 30.08.20 12:32, Michael Richardson wrote: >> Paul Spooren wrote: >> > I recently rewrote px5g[1] to use WolfSSL instead of MbedTLS, as the former >> > will be included in OpenWrt 20.x per default. >> >> > Both implementations support the generation of RSA and ECC keys, where uhttpd >> > currently defaults to RSA with 2048 keys. >> >> > The question came up if we really want RSA certificates for LuCI or if the >> > faster and "more modern" ECC P-256 wouldn't be a better choice. >> >> Yes, it would be better. >> >> > If px5g is added to the next release, certificates are generated on first >> > boot and most users are unlikely to manually recreate RSA ones, not? >> >> But, this will result in a security warning for a self-signed key, and then >> we'd be training users to click through them. >> I am divided on whether this is better or worse than unencrypted. >> browsers are making doing that security exception more and more difficult, >> with the desire to eliminating it entirely. > I think we should write a bit of documentation explaining that a cert should > be accepted only once or a router reset is required. That seems more save > than sticking to unencrypted connections. If browsers decide to block > self-signed certs, most UBNT devices will break, too. Yes, many many many devices will break. But browser makers don't really care about that. This is a no-win situation until we can find a way to give proper names and certificates to devices. >> I have running code that deploys LetsEncrypt certificates to devices in the >> "factory". This requires a DNS name for dns-01 challenge. >> That's clearly not feasible for random end-users who flash openwrt on their own. >> I would like to explore some additional options here. > Mind sharing this code? Me (and Daniel) had the same idea, so some ACME > support for px5g would be interesting. Sent my private email. >> > So the question, shouldn't we drop all crypto options from the new px5g >> > implementation and _only_ offer P-256? Whoever wants something else than the >> > default may use px5g-mbedtls or some OpenSSL based tool? >> >> uhm, okay. I can live with that for sure. >> I care more about what's in the certificate than the algorithm. > Fair, however this question is about the algorithm :) Picking the algorithm is a detail that will change every five to eight years. figuring out how to populate the SubjectDN and SubjectAltName is more important. As long as users are being trained to override certificate exceptions, then the certificate provides very little benefit. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] self-signed certificates for LuCI
Paul Spooren wrote: > I recently rewrote px5g[1] to use WolfSSL instead of MbedTLS, as the former > will be included in OpenWrt 20.x per default. > Both implementations support the generation of RSA and ECC keys, where uhttpd > currently defaults to RSA with 2048 keys. > The question came up if we really want RSA certificates for LuCI or if the > faster and "more modern" ECC P-256 wouldn't be a better choice. Yes, it would be better. > If px5g is added to the next release, certificates are generated on first > boot and most users are unlikely to manually recreate RSA ones, not? But, this will result in a security warning for a self-signed key, and then we'd be training users to click through them. I am divided on whether this is better or worse than unencrypted. browsers are making doing that security exception more and more difficult, with the desire to eliminating it entirely. I have running code that deploys LetsEncrypt certificates to devices in the "factory". This requires a DNS name for dns-01 challenge. That's clearly not feasible for random end-users who flash openwrt on their own. I would like to explore some additional options here. > So the question, shouldn't we drop all crypto options from the new px5g > implementation and _only_ offer P-256? Whoever wants something else than the > default may use px5g-mbedtls or some OpenSSL based tool? uhm, okay. I can live with that for sure. I care more about what's in the certificate than the algorithm. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
documenting proc_add_mdns for multiple things
It seems that proc_add_mdns is unable to add multiple entries for a process. For instance, if lighttpd is enabled for TLS/HTTPS and HTTP, then one might want to say: procd_add_mdns "http" "tcp" "80" "daemon=lighttpd" procd_add_mdns "https" "tcp" "443" "daemon=lighttpd" But, this doesn't work. Putting them both results in neither being announced. Looking at the JSON that is created by procd_add_mdns_service (setting PROCD_DEBUG) I can't quite understand this. It seems that it ought to announce the second one. Removing either line allows the other to work. The _procd_ shell scripts are indeed deep and twisty. I would be happy to attempt to document them if there isn't already a document somewhere. I understand it is using shell variables to assemble the data and then pass it to jshn to assemble it. Nifty. A bit odd that jshn and libubox comes from omcproxy package, even though I recognize that's just where libubox is built. If there documentation on jshn, I can't find it. It feels like this shell script ought to be in the procd package, since the procd.sh can't operate with the /usr/share/libubox/jshn.sh. But, whatever. In the end, I've managed to create a file for /etc/umdns/foo.json which does what I needed, and I'd like to document that better. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Simplified LuCI interface project: dashboard, quick setup, configuration
Thank you kindly for this work. Baptiste Jonglez wrote: > The student project of Biyun and Zhao has just finished. > The goal was to develop a simplified web interface for OpenWrt, integrated > in LuCI and complementary to the current LuCI interface. I watched the video. I have some questions. Maybe I didn't pay enough attention though, so I read the report a bit too. :-) I now understand what the goals were, and I think that you did a good job making the dashboard better. From watching the video the two tasks that you were attempting to improve were (in laymens terms): 1) changing the WIFI password 2) creating a port-forward (I guess I missed the static-IP part in the video) I think that this could be just a bit easier to do: in particular I think that the average person needs just a bit more friendly text to connect between what they want to do, with our terminology as to what we are doing. > Feedback on the results of the project is welcome, preferably in the pull > requests (see below). Zhao and Biyun are still available for a few weeks > to improve the code and the interface, so that it can hopefully be > integrated in LuCI. It was one of the goals of the project, so it would > be good to accomplish it. > Demo video: https://youtu.be/usFHV2WYvMw or https://gricad-gitlab.univ-grenoble-alpes.fr/projet-ter-m1-wic-openwrt/documentation/-/blob/master/demonstration.mp4 > Project report: https://gricad-gitlab.univ-grenoble-alpes.fr/projet-ter-m1-wic-openwrt/documentation/-/blob/master/Report.pdf > Github pull requests to integrate the modules in LuCI: > - dashboard: https://github.com/openwrt/luci/pull/4185 > - quick setup: https://github.com/openwrt/luci/pull/4141 > - configuration: https://github.com/openwrt/luci/pull/4186 > Wiki pages with screenshots: > - dashboard: https://openwrt.org/docs/guide-user/luci/dashboard > - quick setup: https://openwrt.org/docs/guide-user/luci/quick_setup > - static leases: https://openwrt.org/docs/guide-user/luci/static_ip > - port forwards: https://openwrt.org/docs/guide-user/luci/port_forwards > Thanks, > Baptiste > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > http://lists.infradead.org/mailman/listinfo/openwrt-devel signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade and Failed to kill all processes
Philip Prindeville wrote: >> In general, I think that this decision needs to up-leveled to as a >> build option. There are many cases where I would agree: you want the >> box to die rather than potentially come up insecurely. > A while ago I posted an option to “bake in” a default root password but > it was nixed. > https://github.com/openwrt/openwrt/pull/622 > Too bad. Such a thing would violate the California, UK and coming Australian and US laws. We are also going to have to deal with admin/admin; maybe there are already plans for that. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade and Failed to kill all processes
Philip Prindeville wrote: >> A reboot with some logging on disk would allow for remote sysupgrades >> to have some kind of recoverability. > What if the failure left the box in a partially compromised state? > Would you want your firewall to “fail open”? I wouldn’t. It depends a lot on the relative cost of sending a service person there to repair the device (push the button, reflash or replace the device), vs the risk of the box not operating at all. In the NAT44 home router situation, the lack of an iptables to do MASQ or port forwarding results in the "firewall" failing closed. No packets traverse, but the box might be accessible by network for repairs from one side or the other. In the IPv6 and routed IPv4 situation, if packet forwarding is enabled, then the box might continue to provide critical functionality, and it might be possible to repair it remotely. In the case where this isn't a router, but a NAS, or some other IoT device, then the lack of a firewall, if the device has multiple layers of security (no stupid default passwords, or no passwords at all) result in a lowered level of security, but not zero security. In general, I think that this decision needs to up-leveled to as a build option. There are many cases where I would agree: you want the box to die rather than potentially come up insecurely. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] building python3 packages outside of lang/python3
Alexandru Ardelean wrote: > you'll have to settle for some sort of absolute path if you need those > files from the packages feed in some other feed if you take a look at > https://github.com/openwrt/packages/blob/master/lang/python/README.md > there's a suggestion: PYTHON3_PACKAGE_MK:=$(wildcard > $(TOPDIR)/feeds/*/lang/python/python3-package.mk) [ similar can be done > for pypi.mk ] I guess the wildcard is because one can't depend upon the name by which each of the feeds is included in the feeds.conf. >> I tried the whole thing, but that didn't work. >> >> I settled on: include >> $(INCLUDE_DIR)/../feeds/packages/lang/python/python3-package.mk >> >> which I found ugly, but it worked. > yes & no; you can choose to do a direct include like [1] If the Makefile include path were to include all the top levels of all the feeds (feeds/* ), then: include lang/python/python3-package.mk would work, and it would pick up whichever one was first in the list of feeds. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Proposal: Differentiating "skinny" platforms from others...
I think that CONFIG_SKINNY is a good concept, but for all the reasons you cite: Abuse Department wrote: > Some of us work with more current machines that are also more capable, > realizing that eventually machines with 32MB of DRAM and 128MB of Flash > will “age out” through failure and scarcity. > By then we’ll have a new “normal” about what the minimum expectations > are, and the conversation will continue, but with different > parameters. > Understanding that the definition of a “skinny” machine isn’t today > what it was 5 years ago, and that it won’t be the same again in another > 5 years, I’d like to proposal a CONFIG_ symbol that denotes that a > platform is in a class of constrained architectures. it seems that SKINNY should be an integer of some kind, not a boolean. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] building python3 packages outside of lang/python3
hi, python packages include ../python3-package.mk, and pypi.mk But I can't do that from my own feed directory. I don't want to copy the file!! Is there a relative path that would get me to feeds/packages/lang/python3? I tried the whole thing, but that didn't work. I settled on: include $(INCLUDE_DIR)/../feeds/packages/lang/python/python3-package.mk which I found ugly, but it worked. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWRT Summit.... 2019????
Are there any plans to host an OpenWRT summit in 2019? I learnt of the 2018 summit in Lisbon the week after :-( and I'd like to make better plans, if it will happen. I notice that prplFoundation is planning an event in October in Berlin. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] moving firewall package to nftables
There are some features in nft that we'd like to use in CIRALabs' SecureHomeGateway project. In particular, it's much easier to get statistics out of nft in JSON. nft is easy to install, but it seemed that we really needed the updated iptables commands, and I upgraded that (and libnftnl, which seems to require a git head to work with iptables iptables 1.8.2. 1.1.2 is not new enough) I had a small hope that /sbin/fw3 was shelling out to /sbin/iptables to do it's work, but I see now that it's not the case. It uses libiptc and ip6tc directly.I have not yet investigated how hard it will be to upgrade to the nft libraries to do this. Before I continue, I wanted to check if someone else has been down this path already and determined it is premature, or if there are larger architectural issues that need to be resolved of which I am ignorant. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Mathias Kresin wrote: > I would like to start to reject patches for adding boards with only 32 MByte > of RAM and 4 MByte of flash [0]. These boards barely work with todays OpenWrt > default builds and require quite some modifications to be useful at all > [1]. So, no new boards that have <4M flash, or <32M ram, or no patches providing fixes for existing targets that are at that level? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] libpcap: patch to add limits.h to pcap-usb-linux.c
bj...@mork.no wrote: >> I've been into the LTE modem driver business for a while. Captures >> from end users with some modem hardware/firmware specific issue have >> often been the only way to fully understand a problem Michael Holstein wrote: > why not just create a bridge and tcpdump that. That code is far lower > in the kernel than the ability to put a USB device in promisc mode (and > I should point out that promic isn't going to matter since Verizon > isn't treating your either end of the IP interface as a switchport > where you'd see L2 traffic in promisc fashion. That won't capture USB level things. LTE modems look like async modems, and run PPP over a serial layer. Many device need stupid USB-based unlock sequences that have nothing to do with networking. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] libpcap: patch to add limits.h to pcap-usb-linux.c
Bjørn Mork wrote: > I've been into the LTE modem driver business for a while. Captures from > end users with some modem hardware/firmware specific issue have often > been the only way to fully understand a problem. Changing an option > hidden deep inside the OpenWrt build config is out of the question > unless the reporter already is familiar with that build system. It is > about as convenient as a kernel debug patch for most end users. The > lack of a pre-built usbmon capture tool makes bug reports from OpenWrt > users much harder to debug. That's definitely a reason to include USB capture then! > BTW: I tried to figure out which additional libraries the feature > requires. It doesn't seem to be any? pcap-usb-linux.c uses the Linux > kernel support directly. Or am I missing something? It requires libusb. >> Also, the latest libpcap (1.9.0) has cmake support, which might make >> things easier? > Maybe? All these questions are of course up to the maintainer. Adding > Felix to the CC list. Some love cmake, some hate it. When it works, I find I like it. but, determining how to tweak options is really arcane. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] libpcap: patch to add limits.h to pcap-usb-linux.c
Bjørn Mork wrote: >> The reason why the buildservers don't fail is that they're probably >> not setting CONFIG_PCAP_HAS_USB (default is OFF), so the patched file >> does not get compiled. I will add that info in the cover letter. > Not directly related But I wonder if maybe this default could be > changed? > I realize that this is a space thing, but having an optional feature > defaulting to off means that practically nobody uses the feature. And > this one is particularily useful. At least to me :-) Which of course > is no argument since I can easily build my own images with the feature > enabled. I also agree, but turning in USB requires additional libraries, and I'm not sure that many will need USB captures on openwrt. I (as m...@tcpdump.org) don't understand why you are seeing a build failure that causes you to want to patch the file. Also, the latest libpcap (1.9.0) has cmake support, which might make things easier? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Good suggestion for Openwrt router board with 2x mini pci-express
David Johnson wrote: > It seems its quite hard to find a board that is fully supported by > openwrt that has 2x mini pci-express, 2x ethernet ports (WAN, LAN), > > 64M flash The Turris Omnia has three mini pci-express. Two have radios already in them, and the third is open. I have booted the openwrt 18.x build on it now, and so far it seems fine. > I want to plug in ath10k supported 802.11ac mini pci-e radios I can't recall which radio is already there. Not cheap though. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
Bruno Randolf <b...@einfach.org> wrote: > On 03/05/16 18:59, Jo-Philipp Wich wrote: >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> ... >> Jo-Philipp Wich, >> John Crispin, >> Daniel Golle, >> Felix Fietkau, >> Hauke Mehrtens >> John Crispin >> Matthias Schiffer, >> Steven Barth > While a fresh start and a more open process is good move, given this > list of supporters it sounds a bit ridiculous... who is left in the > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? I read the rest of the thread before replying. I understand the need for a reboot and rename. I also don't know who is left, or is being pushed out, or... maybe they left already and didn't leave the keys? Given the FCC-inspired lockdowns, I wonder if one has interest in GPLv3-like statements about keys. I don't much like the name LEDE; it will be hard to explain to end users. Reminds me too much of: https://en.wikipedia.org/wiki/Leadership_in_Energy_and_Environmental_Design and http://www.leedsunited.com/ Maybe do an Apple on the case lEDE, or leDE (en francais!) or something. asciidoc for the web site content is okay; maybe someone will contribute a snazier style sheet (but not me; I'm pathetic at CSS too) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Monitoring Downlink Queue
Nimantha Baranasuriya <nimant...@gmail.com> wrote: > Thanks, Javier for the quick response. > I was thinking of tapping into OpenWRT where the code would process outgoing > frames and queue them to be transmitted to the clients for which they The point of telling you that it's a linux system is to say that there isn't anyu "OpenWRT where the code would process". It's the Linux kernel. tc would let you introduce new qdisc's and you could perhaps create some counters, but it will likely be before the hardware TX queue. (if BQL / fq_codel are doing their thing, the hardware TX queue will be very short... but maybe that's what you are trying to determine) I suggest that you probably need to get into the ath9k driver, and add some counters, or perhaps you'll find counters that are already there. > destined. Do you think I am better off using a tool like tc > (http://linux.die.net/man/8/tc) rather than doing the former? > -Nimantha > On Jan 28, 2016, at 10:47 PM, Javier Domingo Cansino > <javier...@gmail.com> wrote: > That is a linux thing, I mean, you need to know how to do that in > standard linux. Openwrt is just a normal linux system. The only > difference is that you are provided with a toolchain to generate > customized images. > On Thu, Jan 28, 2016 at 5:10 PM Nimantha Baranasuriya > <nimant...@gmail.com> wrote: > Hi, > I am new to OpenWRT and I am working on a research project for which > I need to monitor and log the number of frames in the downlink queue > of the WiFi interface of the router every so often. Can someone > please help me to get this done? > Thank you, > Nimantha > ___ > 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 -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files utils/busybox: Make requiring login in console default for easily accessed devices
Sami Olmari <s...@olmari.fi> wrote: >> at the moment the user *is* used to a key mismatch, because >> every box comes up with 192.168.1.1 and another key. > No need to generate another weak point just because there can be another > similar one... And, there is work at the IETF and the IEEE that could make this much less of a problem, and IPv6 link-local addresses are not all 192.168.1.1. > More general, should a bad guy have physical access to an device, be it > embedded router or full server, the game is mostly lost at that point > already... He can allways take out the hard disk and boot own linux and read > the contents etc... True, but given wifi, the attacker doesn't have to have physical access to the device. Given that people want to put devices in all sort of places where physical access may be easy... > So, to recap, bad guy + physical access = game over, no matter what you try > to do... probably. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files utils/busybox: Make requiring login in console default for easily accessed devices
Bastian Bittorf <bitt...@bluebottle.com> wrote: >> >while we are at it: what about including default private keys for SSH >> >till the real keys are generated? it can last several minutes on some >> >routers and it feels like the box is broken. also: if really something >> >goes wrong during key generating we can at least login. >> >> So make it double unsafe - great idea ;) > please say more about this. the initial keygenerating is only > active when the password is still unset. i dont see an unsecure > thing here, do you? 1) when the "default" key is being used, the box can be impersonated. 2) if the user is "used" to a key mismatch, and they type their password in, the password has just been compromised. 3) if the user accepts the default keys, when the correct ones are generated, the user then has a key mismatch, again opening the possibility of an impersonation. A better approach is that the ssh daemon should start, open port 22, and then do SSHv2 transport mode up to the key-exchange, and then just respond to keep alives, ideally with a message to "Please stand by", if we can find a way to do that in-protocol. (wow. it's been 18 years since I worked at ssh...) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files utils/busybox: Make requiring login in console default for easily accessed devices
Bastian Bittorf <bitt...@bluebottle.com> wrote: >> > while we are at it: what about including default private keys for SSH >> > till the real keys are generated? it can last several minutes on some >> > routers and it feels like the box is broken. also: if really something >> > goes wrong during key generating we can at least login. >> >> you have a very bizarre understanding of securing a device. > in this stage the box is still without password. okay. So the impersonator machine lets the user in without a password, and the impersonator machine has ALREADY connected to the new machine with no password, and trojan'ed some binaries. > the only issue i can think of is, that one can > read on the wire to which password somebody changes > with 'passwd' - but i'am pretty sure this is not > the case, because each session has it's own privacy. No, since the impersonator (MITM) has involved itself with the session. Effectively, the MITM creates: ssh mitm 'tee /badguy | ssh target' (but, bidirectionally, and inside the SSH transport layer) A new ICMP port-unreachable code would be nice to have here. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files utils/busybox: Make requiring login in console default for easily accessed devices
Daniel Dickinson <open...@daniel.thecshore.com> wrote: > At the present time it is actually not possible to using /bin/login from > within the preinit context and therefore making passwords required during > failsafe is not currently possible. It sounds like we really need /bin/singleuserlogin. Could we use a password (or hash) stored in eeprom? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] HTTPS with 'letsencrypt.org' on OpenWrt
Joris de Vries <j.s.de.vr...@gmail.com> wrote: > I would be interested in this as well, although I'm not sure how useful > this is without configuring a good hostname for routers, also maybe > automatically. Fundamentally, this is the problem for devices without names. I just don't think that Lets Encrypt is going to be at all helpful for the users that are most vulnerable. This applies to openwrt routers, but also to things like ILOMs (e.g. Dell iDRAC systems) and also things like a home NAS appliance. What we need is a variation on the Extended Valiation Cert: a cert that the browser recognizes having a DN that binds to the devices' MAC address. The browser would then put that into the Location bar. Of course this is an entirely new beast, but I don't see another way to intelligently get a certificate for a router without a name. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Link detection - TP-Link Archer C7 v2
Richard Clark rich...@kerkhofftech.ca wrote: Hi Richard, the link status is not propagated to the netdev because there's an external switch chip between the CPU and the RJ45 plug on the outside. There currently is no mechanism to propagate switch port states to Linux netdev link states as such an mechanism has various implications. Ok, that makes sense. Just my dumb luck that the little portable GL-Inet I was developing on happens to not have an internal switch, so everything was fine there. So currently it looks like good chunk of routers seem to follow the same block diagram as the original WRT54g and are going to have the same issue. All the netifd handling to start/stop services on link state never gets used. So, just to realize that you probably want active DNA[1] anyway, as even on a device that has directly connected ports, plugging in a dumb switch will give you link, yet there is really nothing beyond it. [1]- https://tools.ietf.org/wg/dna/ Detecting Network Attachment ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc1
Steven Barth cy...@openwrt.org wrote: Steven Barth cy...@openwrt.org wrote: - Added support for 464XLAT (CLAT) Is this signaled in some way by DHCPv6? If so, I imagine that there is an RFC# which says how it works, could be listed here, so that google will find CC when people look for it... There seems to be no standardized RFC for this yet, as Bjorn pointed out. All I'm suggesting is that it say: - Added support for 464XLAT (CLAT) based upon RFC6877 (includes using heuristic to discover the PLAT side) if one supported the new DHCPv6 option, then one would say instead: - Added support for 464XLAT (CLAT) based upon RFC6877 (includes using heuristic to discover the PLAT side, and supporting DHCPv6 option in draft-cui-intarea-464xlat-prefix-dhcp-00) it's just google fodder so that IETF people can find the code, and OpenWRT people can find the specification :-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc1
Steven Barth cy...@openwrt.org wrote: - Added support for 464XLAT (CLAT) Is this signaled in some way by DHCPv6? If so, I imagine that there is an RFC# which says how it works, could be listed here, so that google will find CC when people look for it... I actually think that this is a terribly important feature set. Thank you for all the work! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Designated Driver
Imre Kaloz ka...@openwrt.org wrote: Designated Driver fits the best as a name, but it's a mocktail (but at least tastes good). +1 And, it would be be nice if all the drivers were up-to-date... :- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is PPPoE broken in Barrier Breaker?
valent.turko...@gmail.com valent.turko...@gmail.com wrote: I don't see lots of people using PPPoE with OpenWrt, at least PPPoE is not mentioned much on forums. I have definitely tested the PPPoE in BB, (as I work on a PPPoE gateway). I did have to move to CC in order to get certain IPv6 things to work right, but the base PPPoE worked for me. I run PPPoE in CeroWRT at home which is approximately BB, but not exactly. It looks like pppd after sending request for IP address instead getting response with IP data instead package to terminate LCP is received. Does somebody have ideas why is this happening? That's not a PPPoE thing. That's a PPP thing, and it sounds like you have a problem with your ISP. It might sound like I'm splitting hairs, but it means the problem is not in the same place. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
valent.turko...@gmail.com valent.turko...@gmail.com wrote: Why it OpenWrt slower than stock firmware? I can help by shining a bit of light onto this subject. I'm developing custom firwmares based on I'm curious about this claim to begin with. Of the people who say this, how many of them actually know how to measure such a thing? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why OpenWrt sucks?
Alpha Sparc alphasp...@gmail.com wrote: I believe it is due to the hardware NAT not supported. So, really, nothing to do with wifi drivers at all. You don't need (hardware) NAT if you run IPv6... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] General questions about the direction of switch drivers
Joel Wirāmu Pauling j...@aenertia.net wrote: I for one would love to see brctl and vconfig disappear completely in favour of ovs-* based standard toolchain for all switch interaction. When I say, brctl/vconfig, I really mean that I want the kernel API to be the same as for a hardware switch, and really so does everyone else. I am a little less concerned about whether the hardware underneath is under the kernel, or beside the kernel, as long as it speaks the same API. The IETF FORCES (basically, netlink over IP) model is the most model to me. Having the hardware underneath would also be cool. I guess the biggest issue is getting ovs- offload to switch chipsets rather than CPU bound softswitch. Maybe some sort of flag where unsupported operations/modes which would end up being done on the CPU are flagged/masked? That's what it winds up meaning having the hardware under the kernel, rather than next to the kernel. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] General questions about the direction of switch drivers
First, there are a lot of discussions and papers at netdev01.org about the various hardware switch management systems. I point specifically to a talk this morning: https://www.netdev01.org/sessions/19 I have stumbed my toe on 3800 with trying to build tagged switch ports where I have a few ports with explicit VLAN tagging, joined together in the switch, and also exposed to the host. I think it should work, but I mostly just wound up screwing up my CPU port. I have some 3800 with serial consoles now so I should try this out. What would be ideal, and my impression is that this is where the industry wants to go, is that one would use brctl and vconfig to build the switch configuration that you want, and the drivers below would realize that the switch can do that work, and would program things correctly. openvswitch is about creating a virtual switch fabric in the CPU, which can spread elsewhere --- the trend is though, that this too would be subject to hardware offload. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] I'd like to donate a Netgear N150 WNR1000 v3
Russell Senior russ...@personaltelco.net wrote: Everyone should have one. At this price (or similar), there isn't a good reason to not have several: http://www.ebay.com/itm/USB-To-RS232-TTL-UART-PL2303HX-Auto-Converter-USB-to-COM-Cable-Adapter-Module-/310676792112 ... particularly if you've got some lead time, since coming from china might mean you need to wait a while. And if you are near Ottawa, ON (Toronto, Montreal), I bought like 30 of them, and I'd be happy to mail you one, since they fit in a standard Canada Post envelope. Unicast me. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Richard Mortimer richm+open...@oldelvet.org.uk wrote: I think I saw something similar when I was using an ADSL connection. When the connection was under full load (I don't remember whether it was upstream, downstream or both) the LCP echo requests that PPPD does seem to get dropped somewhere in the ADSL infrastructure. The link is however working fine passing real traffic. Sounds like the something a proper BQL limit on the etherne/ATM part of the PPPoE coud fix. For PPPoE, traffic shapping should occur on the PPP interface and should probably run at no more than 99% of the real link capacity (if you can determine it...sigh), the LCP messages should bypass that part. DSL with the modem built-in ought to auto-adjust the bandwdth viaBQL perfectly... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Sebastian Moeller moell...@gmx.de wrote: Sounds like the something a proper BQL limit on the etherne/ATM part of the PPPoE coud fix. For PPPoE, traffic shapping should occur on the PPP interface Note SQM does not care too much where you put the shaper,but if you shape one the pppoe device the pop maintenance packets are never seen by SQM so they will not be dropped. Shaping on the raw ATM device (in your case) should also work (never tested this myself as I have no open dsl-router), but almost all packets will end up in the default queue (I think) as the packet classification can not see through the pop My point was that BQL running on the raw interface would see the LCP packets, and therefore would take them into account. I would except to do the various SQM on the ppp interface, with the BQL on the underlying interface (for the PPPoE case) providing the push back so that queing works. DSL with the modem built-in ought to auto-adjust the bandwdth viaBQL perfectly… For egress/upstream (I really hope we will get something like that in the future); bit for ingress/downlink you still need a properly configured shaper until the DSLAMs/MSANs/BRASs learn BQL fq_codel (which might take a while) Yes, I was ignoring that part. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
How do you know it's not the DSLAM being unstable? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WeIO - Web of Things Platform
Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: WeIO (http://we-io.net/) is new OpenWrt (Barrier Breaker) powered development board for rapid prototyping and IoT, based on Carambola 2 module (Atheros AR9331 CPU). It has a good Indiegogo success so far: https://www.indiegogo.com/projects/weio-platform-for-web-of-things, and source code of the main app is here: https://github.com/nodesign/weio, while BSP is here: https://github.com/nodesign/openwrt (currently working on set of patches to be pushed to upstream soon). We hope that this project will lead to further popularization of OpenWrt, as so far we are quite satisfied with results and performance. So, 400Mhz ARM, single wired ethernet that needs to be populated, as far as I can see. Lots of I/O... Yes, a nice IoT platform. Any battery management? The AR9331 uses the Ath9K wifi driver? I'm thinking about ease of sticking it in a tree with a solar panel. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WeIO - Web of Things Platform
Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: In this sense any external battery, like the ones used as extra batteries for mobile phones and tables, should work without problems. That's a good idea. There are even some with built-in solar panels, but the general conclusion is from my solar power gurus that the solar panel is mostly a joke... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] TI/Intel Puma5 target.
José Vázquez ppvazquez...@gmail.com wrote: According to the info i could find the cpu is a 400MHz arm1176 (ARMv6k) with VFP and C55x DSP for VoIP, that runs in big endian mode; seems that shares some features with TI Davinci, OMAP2 and/or Sitara. Seems to be too slow to operate enough counters for fq_codel, even if somehow it's fast enough to move 100Mb/s+ of traffic. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] TI/Intel Puma5 target.
José Vázquez ppvazquez...@gmail.com wrote: José Vázquez ppvazquez...@gmail.com wrote: According to the info i could find the cpu is a 400MHz arm1176 (ARMv6k) with VFP and C55x DSP for VoIP, that runs in big endian mode; seems that shares some features with TI Davinci, OMAP2 and/or Sitara. Seems to be too slow to operate enough counters for fq_codel, even if somehow it's fast enough to move 100Mb/s+ of traffic. I have no idea how much fast it is, and you are right about unable to move more than 100Mbps, but take in mind that OpenWRT is very versatile and a lot of people use routers for other purposes than routing, as you know. If i had enough skills i would try to port it to kernel 3.3 or 3.10, but i hadn't (mainly because i don't have enough knowledge of ARM and the Puma5 code is a bit strange with a lot of Pal files that i don't know what they are). Sorry, wrong list!!! Over on the cerowrt-devel list, we are looking for the replacement for the Netgear 3800 on which to focus fq_codel/bufferbloat work, as the 3800 can't reach much beyond 50Mb/s, which has become a problem as many have VDSL2/FTTH. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
