Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage

[Stefan Lippers-Hollmann]

Hi

On 2018-08-21, Jo-Philipp Wich wrote:
> Hi,
> 
> > RAS_VERSION := "V1.99(OWRT.$$(shell echo $(REVISION) | sed s/^r//))C0"  

While this passes the version check, the appended git hash does break 
later on in the flashing process - so at the moment only the numerical
revision (of DISTRIB_REVISION='r7890-40eb9bda44') seems to be safe:

RAS_VERSION := "V1.99(OWRT.$$(shell echo $(REVISION) | sed -e s/^r// -e 
s/\\-.*//))C0"

# hexdump -C /dev/mmcblk0p6 
  00 00 b4 bc 01 47 18 00  56 31 2e 39 39 28 4f 57  |.G..V1.99(OW|
0010  52 54 2e 37 38 39 30 29  43 30 00 ff ff ff ff ff  |RT.7890)C0..|
0020  ff ff ff ff ff ff ff ff  00 00 d4 1d 4e 42 47 36  |NBG6|
0030  38 31 37 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |817.|
0040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*
0060  ff ff ff ff ff ff ff ff  ff ff ff ff 00 00 98 e5  ||
0070  00 40 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |.@..|
0080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*
0001  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0010

> make that  RAS_VERSION := "V1.99(OWRT.$(patsubst r%,%,$(REVISION)))C0"
> to avoid spawning a shell + sed process.

I'll have a look at improving this tonight, thanks.

Regards
Stefan Lippers-Hollmann

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage

[Jo-Philipp Wich]

Hi,

> RAS_VERSION := "V1.99(OWRT.$$(shell echo $(REVISION) | sed s/^r//))C0"

make that  RAS_VERSION := "V1.99(OWRT.$(patsubst r%,%,$(REVISION)))C0"
to avoid spawning a shell + sed process.

~ Jo



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

Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage

[Stefan Lippers-Hollmann]

On 2018-08-21, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On 2018-08-21, Stefan Lippers-Hollmann wrote:
> > On 2018-08-20, David Bauer wrote:  
> [...]
> > For now, I've supplied a valid/ future firmware version for testing
> > 
> > RAS_VERSION := "V1.00(ABCS.9)C0"  
> 
> While perhaps not ideal yet, this is accepted by the OEM webinterface 
> and should be safe to use for the time being.
> 
> RAS_VERSION := "V1.99(OWRT.7890)C0"

Sorry, this was meant to read:

RAS_VERSION := "V1.99(OWRT.$$(shell echo $(REVISION) | sed s/^r//))C0"

# hexdump -C /dev/mmcblk0p3
  00 00 c4 38 01 47 18 00  56 31 2e 39 39 28 4f 57  |...8.G..V1.99(OW|
0010  52 54 2e 37 38 39 30 2d  34 30 65 62 39 62 64 61  |RT.7890-40eb9bda|
0020  34 34 29 43 30 00 ff ff  00 00 cb 60 4e 42 47 36  |44)C0..`NBG6|
0030  38 31 37 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |817.|
0040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*
0060  ff ff ff ff ff ff ff ff  ff ff ff ff 00 00 98 e5  ||
0070  00 40 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |.@..|
0080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*
0001  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0010

Regards
Stefan Lippers-Hollmann


pgpUy1INt3ylP.pgp
Description: Digitale Signatur von OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage

[Stefan Lippers-Hollmann]

Hi

On 2018-08-21, Stefan Lippers-Hollmann wrote:
> On 2018-08-20, David Bauer wrote:
[...]
> For now, I've supplied a valid/ future firmware version for testing
> 
> RAS_VERSION := "V1.00(ABCS.9)C0"

While perhaps not ideal yet, this is accepted by the OEM webinterface 
and should be safe to use for the time being.

RAS_VERSION := "V1.99(OWRT.7890)C0"

# hexdump -C /dev/mmcblk0p6 
  00 00 b8 49 01 47 18 00  56 31 2e 39 39 28 4f 57  |...I.G..V1.99(OW|
0010  52 54 2e 37 38 39 30 29  43 30 00 ff ff ff ff ff  |RT.7890)C0..|
0020  ff ff ff ff ff ff ff ff  00 00 d3 3f 4e 42 47 36  |...?NBG6|
0030  38 31 37 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |817.|
0040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*
0060  ff ff ff ff ff ff ff ff  ff ff ff ff 00 00 98 e5  ||
0070  00 40 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |.@..|
0080  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*
0001  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0010

Regards
Stefan Lippers-Hollmann


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 0/4] base-files: add new backup options

[Luiz Angelo Daros de Luca]

Hi Tom,

> Unrelated to upgrade. I have dnsmasq and ntpd script disabled, i make a 
> backup, then reset my device to defaults or flash some other image without 
> keeping settings. After flashing back image version from which the backup was 
> made and restoring backup, dnsmasq and ntpd are enabled again. So these 
> settings were not backed up. Not even after your changes. I've checked backup 
> file and there are no initscripts inside it.

It's an interesting situation. init system, from sysv to systemd (and
including procd) uses symlinks for service activation. If there is a
link starting with "S" at /etc/rc.d/ and it is executable, service is
enabled and it will run. When you disable a service, you get that link
removed. You can check /etc/rc.common for code.

A backup is just a tarball with files. It does not make sense to have
tarball that removes a file when extracted.

As a (not tested) suggestion, you could replace thoses link with a
broken ones, like:

ln -sf disabled /etc/rc.d/S19dnsmasq
ln -sf disabled /etc/rc.d/K19dnsmasq
ln -sf disabled /etc/rc.d/S98sysntpd
ln -sf disabled /etc/rc.d/K98sysntpd

(maybe this should be the default behavior of rccommon disable())

Another alternative is to create a startup script that tries to
disable those services on every boot.

Both might work.

> I did not apply your patch 4 that concerns packages auto installation. I 
> think you should drop that one.

It does not autoinstall packages. If a user asked for it, it only
saves a list of installed packages to help reinstalling them.

Regards,
---
 Luiz Angelo Daros de Luca
luizl...@gmail.com

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage

[Stefan Lippers-Hollmann]

Hi

On 2018-08-20, David Bauer wrote:
> The current make-ras.sh image generation script for the ZyXEL NBG6617
> has portability issues with bash. Because of this, factory images are
> currently not built correctly by the OpenWRT buildbots.
> 
> This commit replaces the make-ras.sh by C-written mkrasimage. The old
> script is still kept but can be deleted in the future.
> 
> The new mkrasimage is also compatible with other ZyXEL devices using
> the ras image-format. This is not tested with a OpenWRT build but
> it correctly builds the header for ZyXEL factory images for all devices
> it is added to.
> 
> Signed-off-by: David Bauer 

with the caveat explained below:
Tested-by: Stefan Lippers-Hollmann 

> v2 changes:
>  - Rework image-generation code
>  - Add factory image for NBG6616
>  - Add factory image for NBG6817

Thanks a lot for looking into this!
I've given this a test on my ZyXEL NBG6817 and it's basically working, 
ZyXEL just decided to prevent downgrades from the firmware upgrade
functionality of their webinterface, which means it parses the 
RAS_VERSION and rejects the currently chosen version number.
Flashing this image from a tftpd avoids the strict version 
requirements and can flash the image as-is (press WPS key while 
power-on, have the factory image renamed to "ras.bin" available from a 
tftpd at 192.168.1.99).

[...]
> diff --git a/target/linux/ipq806x/image/Makefile 
> b/target/linux/ipq806x/image/Makefile
> index 2902af3231..cbb03272fb 100644
> --- a/target/linux/ipq806x/image/Makefile
> +++ b/target/linux/ipq806x/image/Makefile
[...]
> @@ -245,6 +246,9 @@ define Device/zyxel_nbg6817
>   KERNEL_SIZE := 4096k
>   BLOCKSIZE := 64k
>   BOARD_NAME := nbg6817
> + RAS_BOARD := NBG6817
> + RAS_ROOTFS_SIZE := 20934k
> + RAS_VERSION := "$(VERSION_DIST) $(REVISION)"
[...]

For now, I've supplied a valid/ future firmware version for testing

RAS_VERSION := "V1.00(ABCS.9)C0"

and it flashes nicely from the webinterface (until ZyXEL actually 
releases this version, which is next in line). I'll have a look if I
can track down the version check and supply something that's both a
bit closer to OpenWrt and more future safe, but I'd suggest to go 
with "V1.00(ABCS.9)C0" for now, as that has been confirmed to work
for the next couple of weeks.

Flashed OpenWrt master image via web-interface, with a fake ZyXEL version
number:

# hexdump -C /dev/mmcblk0p6 | head -n6
  00 00 7a 9f 01 47 18 00  56 31 2e 30 30 28 41 42  |..z..G..V1.00(AB|
0010  43 53 2e 39 29 43 30 00  ff ff ff ff ff ff ff ff  |CS.9)C0.|
0020  ff ff ff ff ff ff ff ff  00 00 d5 73 4e 42 47 36  |...sNBG6|
0030  38 31 37 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |817.|
0040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*

Flashed via tftpd, using OpenWrt's preliminary version info:

# hexdump -C /dev/mmcblk0p3 | head -n6
  00 00 7a 9f 01 47 18 00  4f 70 65 6e 57 72 74 20  |..z..G..OpenWrt |
0010  72 37 38 38 33 2d 66 63  39 63 62 66 33 62 63 30  |r7883-fc9cbf3bc0|
0020  00 ff ff ff ff ff ff ff  00 00 d0 e0 4e 42 47 36  |NBG6|
0030  38 31 37 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |817.|
0040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*

Regards, thank you very much!
Stefan Lippers-Hollmann


pgpF8_kF_K18G.pgp
Description: Digitale Signatur von OpenPGP
___
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

[Michael Richardson]

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

[Michael Holstein]

> 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

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.


brctl addbr bt2
brctl addif br2 usb0
ifconfig br2 up

tcpdump -i bt2 (yada)

Michael Holstein CISSP
moholst...@gmail.com

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Read-only copy of Wiki?

[Thomas Endt]

Von: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] Im Auftrag 
von Nguy?n H?ng Quân
Gesendet: Sonntag, 29. Juli 2018 04:30
An: OpenWrt Development List
Betreff: [OpenWrt-Devel] Read-only copy of Wiki?

>Hi
>
>The OpenWrt wiki is sometimes too slow to access from my country.

Which wiki are you talking about:

1) wiki.openwrt.org (that's the old wiki)
2) openwrt.org (that's the new wiki)


> So I would like to host a read-only copy of it, to serve as reference 
> documentation.
>Is this possible? Can you help export the wiki?

There are several ways to get the wiki content without any wiki admin action.
Have you tried e.g. an offline-reader plugin for your browser already?

Regards,

Thomas





___
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

[Michael Richardson]

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]

Michael Richardson  writes:
> 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 agree that most users won't need it. The problem is the high threshold
for those few who do.

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.

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?

> I (as m...@tcpdump.org) don't understand why you are seeing a build failure
> that causes you to want to patch the file.

The build failure is in version 1.8.1 used by OpenWrt 18.06.  The fix
being discussed is a backport of this upstream patch:

 
https://github.com/the-tcpdump-group/libpcap/commit/aafa3512b7b742f5e66a5543e41974cc5e7eebfa

> 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.



Bjørn

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] GPL Violation to chase + Engenius/Senao firmware non-update

[Michael Holstein]

I'll get you the citations, but I know the busybox (vs various) one
set precedent, and another held that GPL was an enforceable contract.
Several companies have been dinged for it and offered settlements to
purchasers (IIRC Cisco being one of them) .. if you pull their filings
from Edgar and/or import records from USCIS you'll get an idea of how
many you're talking about .. and don't forget the EU either, people
live there also.

You'll clearly have >75k, multiple states, federal matter (copyright),
and California is about the most liberal district you could ask for to
file, although Texas would be better as long as you've project
developers there as forum shopping has ended. It'll never get that
far. The lawyer will get 40% original plaintiffs $10k each, and
everyone else a claim to a coupon for $100 and they'll publish the
code and agree not to do it again, long before it gets to using
LinkedIn for Voir Dere to find a couple nerds to explain it to the
other 11. It really couldn't be any clearer they've done it though.

It'd be expensive to loose, they'd settle .. If anyone has the
background (legal and technical) and desire to persue this get ahold
me of off-list, I can put you in touch with people that can further
the process for you. It's not that anyone really cares about the law,
but they do care about that 40% enough to look it up.

-Mike.

On Mon, Aug 20, 2018 at 10:32 AM, Robert Marko  wrote:
> Well, Engenious or Senao have been ignoring GPL source request for a while.
> And completely violating the GPL licence.
>
> On 20 August 2018 at 16:26, Chuanhong Guo  wrote:
>>
>> GPL doesn't prevent the manufacturer from blocking third-party
>> firmware being installed on their router.
>> They just need to provide GPL code for their firmware (and they don't
>> need to explicitly submit their device support to OpenWrt project.)
>> BTW: It seemed that the bootrom of Qualcomm IPQ40xx comes from other
>> Qualcomm Android chips and contains some security features that
>> preventing unauthorized firmware to be installed on their router. An
>> RSA pubkey can be burnt in to SoC and SoC bootrom will verify contents
>> on flash before booting it. If this feature is used by the
>> manufacturer you'll be impossible to flash any third-party firmware on
>> this router.
>> Michael Holstein  于2018年8月20日周一 下午9:41写道：
>> >
>> > I was finally frustrated at these Engenus/Saneo units and found the
>> > serial port and got into uBoot and looked at the image .. it's yours
>> > .. but oddly, you don't support it all.
>> >
>> > Well gee, that's curious, it seems somebody's breaking the rules, and
>> > it isn't you.
>> >
>> > I'd nastygram Engenius and make them post the GPL contrib so you have
>> > the BLOB for the Broacdom IPQ4019 that's in there. This is the
>> > EAP1250/1300 (identical except for where RJ45 port is) .. there are
>> > 100 others that use this board (I ran the board ID through the FCC API
>> > if you want all the makes/models).
>> >
>> > Here's your goods let me know if you want anything else .. I'm going
>> > to build the image for it and flash but since they broke the rules to
>> > begin with I'm dumping the flash and using the FDT to help modernize.
>> >
>> > These are cool because they are dual radio soft APs that are PoE and
>> > AC wave 2. A 3 pack is $160 on Amazon. With OpenWISP you can do most
>> > anything shy of a college campus
>> >
>> > ahywho ..here's all the proof you need. They didn't even bother to
>> > change the name.
>> >
>> > I'm not a contributor I just do lots of embedded work and this made me
>> > mad. Note that the you've already noticed this on the Engenius 300
>> > (the wiki poings out the factory firmware is openwrt)
>> >
>> > Company contact/owner is easiest found via their FCC filings : most
>> > recent one from
>> > company president
>> >
>> > https://fccid.io/A8J-EAP1300/Letter/Confidentiality-Request-3409208
>> >
>> > Cheers,
>> >
>> > -Michael.
>> >
>> > PS: It looks like they locked the UART from which I obtained this in
>> > u-boot from allowing interrupt so I'm going to poke about and find out
>> > how to get in there. I know this can be done  but it's first I've seen
>> > it done .. The uBoot is reworked from Saneo, per the version string.
>> >
>> > Anyone have a clever tip on that work-around? .. If I can get console
>> > at u-Boot I can skip a couple steps.
>> >
>> > ---snip---.
>> >
>> > bootm 0x8400#configÉ4
>> >
>> > ## Booting kernel from FIT Image at 8400 ...
>> >Using 'configÉ4' configuration
>> >Trying 'kernelÉ1' kernel subimage
>> >  Description:  ARM OpenWrt Linux-3.14.43  LOL OKAY COUGH IT
>> > UP
>> >  Type: Kernel Image
>> >  Compression:  gzip compressed
>> >  Data Start:   0x84e4
>> >  Data Size:3180186 Bytes = 3 MiB
>> >  Architecture: ARM
>> >  OS:  tLinux
>> >  Load Address: 0x80208000
>> >  Entry Point:  0x80208000
>> >  Hash algo:crc32
>> >  Hash value:   34c16a

Re: [OpenWrt-Devel] GPL Violation to chase + Engenius/Senao firmware non-update

[Chuanhong Guo]

A small correction: IPQ40xx is made by Qualcomm not Broadcom and that
feature is called QSEE instead. :)
If my memory is right, Qualcomm verify SBL (SBL is a binary provided
by Qualcomm to bootstrap some basic modules like RAM controller and
load U-boot) in their bootrom before bootrom starts SBL, SBL will then
verify U-boot and refuse to boot if U-boot doesn't pass the signature
checking. As for how U-boot verify firmware this depends on
implementation of the manufacturer. Since the RSA pubkey is burnt into
SoC instead of an external flash, this guaranteed that anyone can't
replace the U-boot with an unsigned one.

(I agree that this is an unrelated topic here and I'll just stop
further discussion about this.
Michael Holstein  于2018年8月20日周一 下午11:08写道：
>
> that feature is called TXE (it's also in the Pi's Broadcom SoC) and it
> doesn't "prevent" it "complicates", particularly in this
> implementation.
> You're correct on your GPL comment. But they did it before and didn't
> release source either, so whoever has ownership should at least ask
> them pretty-please.
>
> There's a workaround to this little problem (wearing the work hat, I'd
> call that a decent security problem in how TXE and uBoot interact in
> Broadcom's implementation), this being another discussion, and
> unrelated.
>
> -Michael.
>
> On Mon, Aug 20, 2018 at 10:26 AM, Chuanhong Guo  wrote:
> > GPL doesn't prevent the manufacturer from blocking third-party
> > firmware being installed on their router.
> > They just need to provide GPL code for their firmware (and they don't
> > need to explicitly submit their device support to OpenWrt project.)
> > BTW: It seemed that the bootrom of Qualcomm IPQ40xx comes from other
> > Qualcomm Android chips and contains some security features that
> > preventing unauthorized firmware to be installed on their router. An
> > RSA pubkey can be burnt in to SoC and SoC bootrom will verify contents
> > on flash before booting it. If this feature is used by the
> > manufacturer you'll be impossible to flash any third-party firmware on
> > this router.
> > Michael Holstein  于2018年8月20日周一 下午9:41写道：
> >>
> >> I was finally frustrated at these Engenus/Saneo units and found the
> >> serial port and got into uBoot and looked at the image .. it's yours
> >> .. but oddly, you don't support it all.
> >>
> >> Well gee, that's curious, it seems somebody's breaking the rules, and
> >> it isn't you.
> >>
> >> I'd nastygram Engenius and make them post the GPL contrib so you have
> >> the BLOB for the Broacdom IPQ4019 that's in there. This is the
> >> EAP1250/1300 (identical except for where RJ45 port is) .. there are
> >> 100 others that use this board (I ran the board ID through the FCC API
> >> if you want all the makes/models).
> >>
> >> Here's your goods let me know if you want anything else .. I'm going
> >> to build the image for it and flash but since they broke the rules to
> >> begin with I'm dumping the flash and using the FDT to help modernize.
> >>
> >> These are cool because they are dual radio soft APs that are PoE and
> >> AC wave 2. A 3 pack is $160 on Amazon. With OpenWISP you can do most
> >> anything shy of a college campus
> >>
> >> ahywho ..here's all the proof you need. They didn't even bother to
> >> change the name.
> >>
> >> I'm not a contributor I just do lots of embedded work and this made me
> >> mad. Note that the you've already noticed this on the Engenius 300
> >> (the wiki poings out the factory firmware is openwrt)
> >>
> >> Company contact/owner is easiest found via their FCC filings : most
> >> recent one from
> >> company president
> >>
> >> https://fccid.io/A8J-EAP1300/Letter/Confidentiality-Request-3409208
> >>
> >> Cheers,
> >>
> >> -Michael.
> >>
> >> PS: It looks like they locked the UART from which I obtained this in
> >> u-boot from allowing interrupt so I'm going to poke about and find out
> >> how to get in there. I know this can be done  but it's first I've seen
> >> it done .. The uBoot is reworked from Saneo, per the version string.
> >>
> >> Anyone have a clever tip on that work-around? .. If I can get console
> >> at u-Boot I can skip a couple steps.
> >>
> >> ---snip---.
> >>
> >> bootm 0x8400#configÉ4
> >>
> >> ## Booting kernel from FIT Image at 8400 ...
> >>Using 'configÉ4' configuration
> >>Trying 'kernelÉ1' kernel subimage
> >>  Description:  ARM OpenWrt Linux-3.14.43  LOL OKAY COUGH IT UP
> >>  Type: Kernel Image
> >>  Compression:  gzip compressed
> >>  Data Start:   0x84e4
> >>  Data Size:3180186 Bytes = 3 MiB
> >>  Architecture: ARM
> >>  OS:  tLinux
> >>  Load Address: 0x80208000
> >>  Entry Point:  0x80208000
> >>  Hash algo:crc32
> >>  Hash value:   34c16a99
> >>  Hash algo:sha1
> >>  Hash value:   620a666c88729f60ee5b3f90fa261ed2bb3de6cb
> >>Verifying Hash Integrity ... crc32+ sha1+ OK
> >>
> >> ## Flattened Device Tree from FIT Image at 8400
> >>

Re: [OpenWrt-Devel] GPL Violation to chase + Engenius/Senao firmware non-update

[Michael Holstein]

So sure them in small claims all over California to get their
attention at whatever the max is per pop.
Were it me I'd file a Federal one as they've subject and personal
jurisdiction and if you've really the balls, as class action allowing
anyone who bought one and was unable to upgrade, claim to damages ..
as that's true and been done in other cases, and that will absolutely
get their attention.
The request for preservation of ESI in conjunction with that filing
alone would be a hell of a battle of attrition (this I've done for
defense of employer for years, to appellate level) and you'll get your
source code, you just haven't asked in language  they understand.

So maybe get a lawyer friend from Dewey and Howe to write them, surely
one of you in Cali knows one.

-Michael.

On Mon, Aug 20, 2018 at 10:32 AM, Robert Marko  wrote:
> Well, Engenious or Senao have been ignoring GPL source request for a while.
> And completely violating the GPL licence.
>
> On 20 August 2018 at 16:26, Chuanhong Guo  wrote:
>>
>> GPL doesn't prevent the manufacturer from blocking third-party
>> firmware being installed on their router.
>> They just need to provide GPL code for their firmware (and they don't
>> need to explicitly submit their device support to OpenWrt project.)
>> BTW: It seemed that the bootrom of Qualcomm IPQ40xx comes from other
>> Qualcomm Android chips and contains some security features that
>> preventing unauthorized firmware to be installed on their router. An
>> RSA pubkey can be burnt in to SoC and SoC bootrom will verify contents
>> on flash before booting it. If this feature is used by the
>> manufacturer you'll be impossible to flash any third-party firmware on
>> this router.
>> Michael Holstein  于2018年8月20日周一 下午9:41写道：
>> >
>> > I was finally frustrated at these Engenus/Saneo units and found the
>> > serial port and got into uBoot and looked at the image .. it's yours
>> > .. but oddly, you don't support it all.
>> >
>> > Well gee, that's curious, it seems somebody's breaking the rules, and
>> > it isn't you.
>> >
>> > I'd nastygram Engenius and make them post the GPL contrib so you have
>> > the BLOB for the Broacdom IPQ4019 that's in there. This is the
>> > EAP1250/1300 (identical except for where RJ45 port is) .. there are
>> > 100 others that use this board (I ran the board ID through the FCC API
>> > if you want all the makes/models).
>> >
>> > Here's your goods let me know if you want anything else .. I'm going
>> > to build the image for it and flash but since they broke the rules to
>> > begin with I'm dumping the flash and using the FDT to help modernize.
>> >
>> > These are cool because they are dual radio soft APs that are PoE and
>> > AC wave 2. A 3 pack is $160 on Amazon. With OpenWISP you can do most
>> > anything shy of a college campus
>> >
>> > ahywho ..here's all the proof you need. They didn't even bother to
>> > change the name.
>> >
>> > I'm not a contributor I just do lots of embedded work and this made me
>> > mad. Note that the you've already noticed this on the Engenius 300
>> > (the wiki poings out the factory firmware is openwrt)
>> >
>> > Company contact/owner is easiest found via their FCC filings : most
>> > recent one from
>> > company president
>> >
>> > https://fccid.io/A8J-EAP1300/Letter/Confidentiality-Request-3409208
>> >
>> > Cheers,
>> >
>> > -Michael.
>> >
>> > PS: It looks like they locked the UART from which I obtained this in
>> > u-boot from allowing interrupt so I'm going to poke about and find out
>> > how to get in there. I know this can be done  but it's first I've seen
>> > it done .. The uBoot is reworked from Saneo, per the version string.
>> >
>> > Anyone have a clever tip on that work-around? .. If I can get console
>> > at u-Boot I can skip a couple steps.
>> >
>> > ---snip---.
>> >
>> > bootm 0x8400#configÉ4
>> >
>> > ## Booting kernel from FIT Image at 8400 ...
>> >Using 'configÉ4' configuration
>> >Trying 'kernelÉ1' kernel subimage
>> >  Description:  ARM OpenWrt Linux-3.14.43  LOL OKAY COUGH IT
>> > UP
>> >  Type: Kernel Image
>> >  Compression:  gzip compressed
>> >  Data Start:   0x84e4
>> >  Data Size:3180186 Bytes = 3 MiB
>> >  Architecture: ARM
>> >  OS:  tLinux
>> >  Load Address: 0x80208000
>> >  Entry Point:  0x80208000
>> >  Hash algo:crc32
>> >  Hash value:   34c16a99
>> >  Hash algo:sha1
>> >  Hash value:   620a666c88729f60ee5b3f90fa261ed2bb3de6cb
>> >Verifying Hash Integrity ... crc32+ sha1+ OK
>> >
>> > ## Flattened Device Tree from FIT Image at 8400
>> >Using 'configÉ4' configuration
>> >Trying 'fdtÉ4' FDT blob subimage
>> >  Description:  ARM OpenWrt qcom-ipq40xx-ap.dkxx device tree blob
>> >  Type: Flat Device Tree
>> >  Compression:  uncompressed
>> >  Data Start:   0x84325520
>> >  Data Size:33495 Bytes = 32.7 KiB
>> >  Architecture: ARM
>> >  Hash algo:crc32

Re: [OpenWrt-Devel] GPL Violation to chase + Engenius/Senao firmware non-update

[Michael Holstein]

that feature is called TXE (it's also in the Pi's Broadcom SoC) and it
doesn't "prevent" it "complicates", particularly in this
implementation.
You're correct on your GPL comment. But they did it before and didn't
release source either, so whoever has ownership should at least ask
them pretty-please.

There's a workaround to this little problem (wearing the work hat, I'd
call that a decent security problem in how TXE and uBoot interact in
Broadcom's implementation), this being another discussion, and
unrelated.

-Michael.

On Mon, Aug 20, 2018 at 10:26 AM, Chuanhong Guo  wrote:
> GPL doesn't prevent the manufacturer from blocking third-party
> firmware being installed on their router.
> They just need to provide GPL code for their firmware (and they don't
> need to explicitly submit their device support to OpenWrt project.)
> BTW: It seemed that the bootrom of Qualcomm IPQ40xx comes from other
> Qualcomm Android chips and contains some security features that
> preventing unauthorized firmware to be installed on their router. An
> RSA pubkey can be burnt in to SoC and SoC bootrom will verify contents
> on flash before booting it. If this feature is used by the
> manufacturer you'll be impossible to flash any third-party firmware on
> this router.
> Michael Holstein  于2018年8月20日周一 下午9:41写道：
>>
>> I was finally frustrated at these Engenus/Saneo units and found the
>> serial port and got into uBoot and looked at the image .. it's yours
>> .. but oddly, you don't support it all.
>>
>> Well gee, that's curious, it seems somebody's breaking the rules, and
>> it isn't you.
>>
>> I'd nastygram Engenius and make them post the GPL contrib so you have
>> the BLOB for the Broacdom IPQ4019 that's in there. This is the
>> EAP1250/1300 (identical except for where RJ45 port is) .. there are
>> 100 others that use this board (I ran the board ID through the FCC API
>> if you want all the makes/models).
>>
>> Here's your goods let me know if you want anything else .. I'm going
>> to build the image for it and flash but since they broke the rules to
>> begin with I'm dumping the flash and using the FDT to help modernize.
>>
>> These are cool because they are dual radio soft APs that are PoE and
>> AC wave 2. A 3 pack is $160 on Amazon. With OpenWISP you can do most
>> anything shy of a college campus
>>
>> ahywho ..here's all the proof you need. They didn't even bother to
>> change the name.
>>
>> I'm not a contributor I just do lots of embedded work and this made me
>> mad. Note that the you've already noticed this on the Engenius 300
>> (the wiki poings out the factory firmware is openwrt)
>>
>> Company contact/owner is easiest found via their FCC filings : most
>> recent one from
>> company president
>>
>> https://fccid.io/A8J-EAP1300/Letter/Confidentiality-Request-3409208
>>
>> Cheers,
>>
>> -Michael.
>>
>> PS: It looks like they locked the UART from which I obtained this in
>> u-boot from allowing interrupt so I'm going to poke about and find out
>> how to get in there. I know this can be done  but it's first I've seen
>> it done .. The uBoot is reworked from Saneo, per the version string.
>>
>> Anyone have a clever tip on that work-around? .. If I can get console
>> at u-Boot I can skip a couple steps.
>>
>> ---snip---.
>>
>> bootm 0x8400#configÉ4
>>
>> ## Booting kernel from FIT Image at 8400 ...
>>Using 'configÉ4' configuration
>>Trying 'kernelÉ1' kernel subimage
>>  Description:  ARM OpenWrt Linux-3.14.43  LOL OKAY COUGH IT UP
>>  Type: Kernel Image
>>  Compression:  gzip compressed
>>  Data Start:   0x84e4
>>  Data Size:3180186 Bytes = 3 MiB
>>  Architecture: ARM
>>  OS:  tLinux
>>  Load Address: 0x80208000
>>  Entry Point:  0x80208000
>>  Hash algo:crc32
>>  Hash value:   34c16a99
>>  Hash algo:sha1
>>  Hash value:   620a666c88729f60ee5b3f90fa261ed2bb3de6cb
>>Verifying Hash Integrity ... crc32+ sha1+ OK
>>
>> ## Flattened Device Tree from FIT Image at 8400
>>Using 'configÉ4' configuration
>>Trying 'fdtÉ4' FDT blob subimage
>>  Description:  ARM OpenWrt qcom-ipq40xx-ap.dkxx device tree blob
>>  Type: Flat Device Tree
>>  Compression:  uncompressed
>>  Data Start:   0x84325520
>>  Data Size:33495 Bytes = 32.7 KiB
>>  Architecture: ARM
>>  Hash algo:crc32
>>  Hash value:   19be728a
>>  Hash algo:sha1
>>  Hash value:   633f6dbf948179ecf1f72f737981d2b38fabe6ee
>>Verifying Hash Integrity ... crc32+ sha1+ OK
>>Booting using the fdt blob at 0x84325520
>>Uncompressing Kernel Image ... OK
>>
>>Loading Device Tree to 86ff4000, end 86fff2d6 ...
>>
>> And guilty party :
>>
>> Linux version 3.14.43 (root@liwei) (gcc version 4.8.3 20140106
>> (prerelease) (Linaro GCC 4.8-2014.01) ) #1 SMP PREEMPT Tue Jan 30
>> 18:20:10 CST 2018
>>
>> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), 
>> cr=10c5387d
>>
>> [0.00

Re: [OpenWrt-Devel] GPL Violation to chase + Engenius/Senao firmware non-update

[Chuanhong Guo]

GPL doesn't prevent the manufacturer from blocking third-party
firmware being installed on their router.
They just need to provide GPL code for their firmware (and they don't
need to explicitly submit their device support to OpenWrt project.)
BTW: It seemed that the bootrom of Qualcomm IPQ40xx comes from other
Qualcomm Android chips and contains some security features that
preventing unauthorized firmware to be installed on their router. An
RSA pubkey can be burnt in to SoC and SoC bootrom will verify contents
on flash before booting it. If this feature is used by the
manufacturer you'll be impossible to flash any third-party firmware on
this router.
Michael Holstein  于2018年8月20日周一 下午9:41写道：
>
> I was finally frustrated at these Engenus/Saneo units and found the
> serial port and got into uBoot and looked at the image .. it's yours
> .. but oddly, you don't support it all.
>
> Well gee, that's curious, it seems somebody's breaking the rules, and
> it isn't you.
>
> I'd nastygram Engenius and make them post the GPL contrib so you have
> the BLOB for the Broacdom IPQ4019 that's in there. This is the
> EAP1250/1300 (identical except for where RJ45 port is) .. there are
> 100 others that use this board (I ran the board ID through the FCC API
> if you want all the makes/models).
>
> Here's your goods let me know if you want anything else .. I'm going
> to build the image for it and flash but since they broke the rules to
> begin with I'm dumping the flash and using the FDT to help modernize.
>
> These are cool because they are dual radio soft APs that are PoE and
> AC wave 2. A 3 pack is $160 on Amazon. With OpenWISP you can do most
> anything shy of a college campus
>
> ahywho ..here's all the proof you need. They didn't even bother to
> change the name.
>
> I'm not a contributor I just do lots of embedded work and this made me
> mad. Note that the you've already noticed this on the Engenius 300
> (the wiki poings out the factory firmware is openwrt)
>
> Company contact/owner is easiest found via their FCC filings : most
> recent one from
> company president
>
> https://fccid.io/A8J-EAP1300/Letter/Confidentiality-Request-3409208
>
> Cheers,
>
> -Michael.
>
> PS: It looks like they locked the UART from which I obtained this in
> u-boot from allowing interrupt so I'm going to poke about and find out
> how to get in there. I know this can be done  but it's first I've seen
> it done .. The uBoot is reworked from Saneo, per the version string.
>
> Anyone have a clever tip on that work-around? .. If I can get console
> at u-Boot I can skip a couple steps.
>
> ---snip---.
>
> bootm 0x8400#configÉ4
>
> ## Booting kernel from FIT Image at 8400 ...
>Using 'configÉ4' configuration
>Trying 'kernelÉ1' kernel subimage
>  Description:  ARM OpenWrt Linux-3.14.43  LOL OKAY COUGH IT UP
>  Type: Kernel Image
>  Compression:  gzip compressed
>  Data Start:   0x84e4
>  Data Size:3180186 Bytes = 3 MiB
>  Architecture: ARM
>  OS:  tLinux
>  Load Address: 0x80208000
>  Entry Point:  0x80208000
>  Hash algo:crc32
>  Hash value:   34c16a99
>  Hash algo:sha1
>  Hash value:   620a666c88729f60ee5b3f90fa261ed2bb3de6cb
>Verifying Hash Integrity ... crc32+ sha1+ OK
>
> ## Flattened Device Tree from FIT Image at 8400
>Using 'configÉ4' configuration
>Trying 'fdtÉ4' FDT blob subimage
>  Description:  ARM OpenWrt qcom-ipq40xx-ap.dkxx device tree blob
>  Type: Flat Device Tree
>  Compression:  uncompressed
>  Data Start:   0x84325520
>  Data Size:33495 Bytes = 32.7 KiB
>  Architecture: ARM
>  Hash algo:crc32
>  Hash value:   19be728a
>  Hash algo:sha1
>  Hash value:   633f6dbf948179ecf1f72f737981d2b38fabe6ee
>Verifying Hash Integrity ... crc32+ sha1+ OK
>Booting using the fdt blob at 0x84325520
>Uncompressing Kernel Image ... OK
>
>Loading Device Tree to 86ff4000, end 86fff2d6 ...
>
> And guilty party :
>
> Linux version 3.14.43 (root@liwei) (gcc version 4.8.3 20140106
> (prerelease) (Linaro GCC 4.8-2014.01) ) #1 SMP PREEMPT Tue Jan 30
> 18:20:10 CST 2018
>
> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
>
> [0.00] Machine model: Qualcomm Technologies, Inc. IPQ40xx/EAP1250
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
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

[Michael Richardson]

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] [PATCH v2] build: Unset CDPATH to avoid problems

[Hans Dedecker]

On Mon, Aug 20, 2018 at 12:13 PM Hauke Mehrtens
 wrote:
>
> From: Thomas Langer 
>
> In some places the output of commands, which include "cd" are used.
> In case of CDPATH the new path is printed, which might not be expected.
> Disable the variable to avoid these problem.
>
> When CDPATH was set by the user to some value like "export CDPATH=."
> the git checkout done by the build system did not work anymore, the
> git cloning aborted with such an error message for example:
> 
> Packing checkout...
> tar: 
> /disk/fs1/tmp2/mehrtens/pon-ugw/ugw-haps/openwrt/tmp/dl/ppa-drv-1.0\n@1534240258:
>  Cannot stat: No such file or directory
> tar: Date sample file not found
> Try 'tar --help' or 'tar --usage' for more information.
> .
>
> To avoid this, this patch makes the build system unset CDPATH inside
> the build system, so the build system will still work even when the
> user set this variable in his local environment.
>
> Signed-off-by: Thomas Langer 
> Signed-off-by: Hauke Mehrtens 
Acked-by: Hans Dedecker 
> ---
>  Makefile | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index e38d44a8..5301883 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -27,6 +27,8 @@ ifneq ($(OPENWRT_BUILD),1)
>export OPENWRT_BUILD
>GREP_OPTIONS=
>export GREP_OPTIONS
> +  CDPATH=
> +  export CDPATH
>include $(TOPDIR)/include/debug.mk
>include $(TOPDIR)/include/depends.mk
>include $(TOPDIR)/include/toplevel.mk
> --
> 2.10.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] GPL Violation to chase + Engenius/Senao firmware non-update

[Michael Holstein]

I was finally frustrated at these Engenus/Saneo units and found the
serial port and got into uBoot and looked at the image .. it's yours
.. but oddly, you don't support it all.

Well gee, that's curious, it seems somebody's breaking the rules, and
it isn't you.

I'd nastygram Engenius and make them post the GPL contrib so you have
the BLOB for the Broacdom IPQ4019 that's in there. This is the
EAP1250/1300 (identical except for where RJ45 port is) .. there are
100 others that use this board (I ran the board ID through the FCC API
if you want all the makes/models).

Here's your goods let me know if you want anything else .. I'm going
to build the image for it and flash but since they broke the rules to
begin with I'm dumping the flash and using the FDT to help modernize.

These are cool because they are dual radio soft APs that are PoE and
AC wave 2. A 3 pack is $160 on Amazon. With OpenWISP you can do most
anything shy of a college campus

ahywho ..here's all the proof you need. They didn't even bother to
change the name.

I'm not a contributor I just do lots of embedded work and this made me
mad. Note that the you've already noticed this on the Engenius 300
(the wiki poings out the factory firmware is openwrt)

Company contact/owner is easiest found via their FCC filings : most
recent one from
company president

https://fccid.io/A8J-EAP1300/Letter/Confidentiality-Request-3409208

Cheers,

-Michael.

PS: It looks like they locked the UART from which I obtained this in
u-boot from allowing interrupt so I'm going to poke about and find out
how to get in there. I know this can be done  but it's first I've seen
it done .. The uBoot is reworked from Saneo, per the version string.

Anyone have a clever tip on that work-around? .. If I can get console
at u-Boot I can skip a couple steps.

---snip---.

bootm 0x8400#configÉ4

## Booting kernel from FIT Image at 8400 ...
   Using 'configÉ4' configuration
   Trying 'kernelÉ1' kernel subimage
 Description:  ARM OpenWrt Linux-3.14.43  LOL OKAY COUGH IT UP
 Type: Kernel Image
 Compression:  gzip compressed
 Data Start:   0x84e4
 Data Size:3180186 Bytes = 3 MiB
 Architecture: ARM
 OS:  tLinux
 Load Address: 0x80208000
 Entry Point:  0x80208000
 Hash algo:crc32
 Hash value:   34c16a99
 Hash algo:sha1
 Hash value:   620a666c88729f60ee5b3f90fa261ed2bb3de6cb
   Verifying Hash Integrity ... crc32+ sha1+ OK

## Flattened Device Tree from FIT Image at 8400
   Using 'configÉ4' configuration
   Trying 'fdtÉ4' FDT blob subimage
 Description:  ARM OpenWrt qcom-ipq40xx-ap.dkxx device tree blob
 Type: Flat Device Tree
 Compression:  uncompressed
 Data Start:   0x84325520
 Data Size:33495 Bytes = 32.7 KiB
 Architecture: ARM
 Hash algo:crc32
 Hash value:   19be728a
 Hash algo:sha1
 Hash value:   633f6dbf948179ecf1f72f737981d2b38fabe6ee
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x84325520
   Uncompressing Kernel Image ... OK

   Loading Device Tree to 86ff4000, end 86fff2d6 ...

And guilty party :

Linux version 3.14.43 (root@liwei) (gcc version 4.8.3 20140106
(prerelease) (Linaro GCC 4.8-2014.01) ) #1 SMP PREEMPT Tue Jan 30
18:20:10 CST 2018

[0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d

[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache

[0.00] Machine model: Qualcomm Technologies, Inc. IPQ40xx/EAP1250

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Is there an Open Issues list for openwrt-18.06.0-rc1

[Aaron Z]

On Mon, Aug 20, 2018 at 6:43 AM Craig Miller  wrote:
> Sorry if this has been answered else where. Is there a "known issues list" or 
> tracker for issues for 18.06-rc1?
> Thought I'd try openwrt-18.06.0-rc1 on my Netgear R6100 today.
> Noted that the 5Ghz wireless radio wasn't even detected (after reseting to 
> defaults). Nothing in the /etc/config/wireless about it. Under 17.01.4, it 
> lists the radio as Qualcomm Atheros QCA9880 802.11nac (and the radio works 
> normally).
>  thanks,
> Craig...
The service release 18.06.1 (which supersedes 18.06-rc1 and 18.06) was
released on Friday, so I would try that:
https://downloads.openwrt.org/releases/18.06.1/targets/
Looking at the changelogs for 18.06(1) and 18.06.01(2), It looks like
there were a fair number of changes for the QCA988x related boards, so
your issue may be fixed on 18.06.01.

(1): https://openwrt.org/releases/18.06/changelog-18.06.0
(2): https://openwrt.org/releases/18.06/changelog-18.06.1

Aaron Z

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] How to install old version of openvswitch on openwrt

[Outback Dingo]

Not sure why your linked a yocto project into an openwrt forum list,
they are surely not the same

as for building openvswitch on openwrt it is included in the project feeds
On Mon, Aug 20, 2018 at 12:56 PM Tshu Shi  wrote:
>
> We are trying to install old version of openvswitch on openwrt, but the 
> method in here : 
> http://git.yoctoproject.org/cgit/cgit.cgi/opkg/commit/?id=9da784d5508157cb327d53eb9abcf54e9926a5a5
>  seems not working. Could you give us some advises?
> The router we used is TL-wr1043nd v2, and the flash we used is 
> openwrt-18.06.0-ar71xx-generic-tl-wr1043nd-v2-squashfs-factory.bin, which is 
> offered by openwrt offical website( 
> https://openwrt.org/toh/tp-link/tl-wr1043nd ).
> And the version of opkg is 3b417b9f41b4ceb5912d82f867dd5534e5675b5c 
> (2017-12-07).
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
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]

Eneas Ulir de Queiroz via openwrt-devel
 writes:

> 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.

The argument for changing the default is that it would make life a hell
of a lot easier for anyone doing USB driver development, saving quite a
few round-trip times trying to get USB captures from ordinary OpenWrt
end users. So I'd like to see CONFIG_PCAP_HAS_USB enabled
unconditionally, and rather have an optional libpcap-mini package with
less features if necessary.  Which I am not convinced it is


Bjørn

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] We want to know how to modify Makefile

[Tom Psyborg]

Hi

Browse for openvswitch in git tree history
(https://git.openwrt.org/?p=feed/packages.git;a=tree;f=net/openvswitch;hb=refs/heads/openwrt-18.06)
and look for changeset of v2.3.1. then simply copy package folder
including files, makefile and patches of your desired version to your
local buildroot (feeds/packages/net/openvswitch)

On 19/08/2018, Tshu Shi  wrote:
>  Hello,we are students from National Cheng Kung University in Taiwan.
> We want to pack package of openvswitch v2.3.1 for openwrt-18.06, but it
> seems like there are lots of differences in Makefile between v2.3.1 and
> v2.9.2.
> If we want to modify a Makefile for openvswitch v2.3.1 by the Makefile
> offered by the openwrt offical github, where should we modify?
> And if we want to download the openvswitch-2.8.2.tar.gz file from local
> host instead of from https://www.openwrt.org/release/, are there anything
> we should modify besides PKG_SOURCE_URL and PKG_HASH?
> Looking forward to your reply.
>
> Yours fairthfully,Li-Jen Hsu
>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] uhttpd: add support for mutual authentication (mTLS)

[Jo-Philipp Wich]

Hi,

comments inline.
> From: Nuno Morais 
> 
> Optional mutual authentication (mTLS)
> by providing a CA certificate through a new new flag "-M"
> in order to verify client's identity.
> 
> For B2B applications.
> 
> This patch depends on patch
> "[OpenWrt-Devel] [PATCH] ustream-ssl: add optional mutual authentication 
> (mTLS)"
> ---
>  main.c | 19 +++
>  tls.c  | 38 ++
>  tls.h  |  6 ++
>  3 files changed, 59 insertions(+), 4 deletions(-)
> 
> diff --git a/main.c b/main.c
> index fb27665..178d710 100644
> --- a/main.c
> +++ b/main.c
> @@ -134,6 +134,7 @@ static int usage(const char *name)
>   "   -s [addr:]port  Like -p but provide HTTPS on this 
> port\n"
>   "   -C file ASN.1 server certificate file\n"
>   "   -K file ASN.1 server private key file\n"
> + "   -M file ASN.1 certificate authority certificate 
> file\n"
>   "   -q  Redirect all HTTP requests to HTTPS\n"
>  #endif
>   "   -h directorySpecify the document root, default is 
> '.'\n"
> @@ -223,7 +224,8 @@ int main(int argc, char **argv)
>   int bound = 0;
>  #ifdef HAVE_TLS
>   int n_tls = 0;
> - const char *tls_key = NULL, *tls_crt = NULL;
> + int n_mtls = 0;
> + const char *tls_key = NULL, *tls_crt = NULL, *ca_crt = NULL;
>  #endif
>  
>   BUILD_BUG_ON(sizeof(uh_buf) < PATH_MAX);
> @@ -232,7 +234,7 @@ int main(int argc, char **argv)
>   init_defaults_pre();
>   signal(SIGPIPE, SIG_IGN);
>  
> - while ((ch = getopt(argc, argv, 
> "A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
> + while ((ch = getopt(argc, argv, 
> "A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:M:m:N:n:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
>   switch(ch) {
>  #ifdef HAVE_TLS
>   case 'C':
> @@ -242,6 +244,11 @@ int main(int argc, char **argv)
>   case 'K':
>   tls_key = optarg;
>   break;
> +
> +case 'M':
> +ca_crt = optarg;
> +n_mtls++;
> +break;
>  
>   case 'q':
>   conf.tls_redirect = 1;
> @@ -477,8 +484,12 @@ int main(int argc, char **argv)
>   return 1;
>   }
>  
> - if (uh_tls_init(tls_key, tls_crt))
> - return 1;
> + if (n_mtls){
> +if (uh_mtls_init(tls_key, tls_crt, ca_crt))
> +return 1;
> +} else if (uh_tls_init(tls_key, tls_crt))
> +return 1;

Tabs. vs. space

> +
>   }
>  #endif
>  
> diff --git a/tls.c b/tls.c
> index d969b82..bc1a19d 100644
> --- a/tls.c
> +++ b/tls.c
> @@ -66,6 +66,44 @@ int uh_tls_init(const char *key, const char *crt)
>   return 0;
>  }
>  
> +int uh_mtls_init(const char *key, const char *crt, const char *ca_crt)
> +{

Is the duplication of the TLS init code really required? Can't you
simply make the 3rd parameter optional and decide based on it whether to
enable the mutual TLS stuff or not?

> + static bool _init = false;
> +
> + if (_init)
> + return 0;
> +
> + _init = true;
> + dlh = dlopen("libustream-ssl." LIB_EXT, RTLD_LAZY | RTLD_LOCAL);
> + if (!dlh) {
> + fprintf(stderr, "Failed to load ustream-ssl library: %s\n", 
> dlerror());
> + return -ENOENT;
> + }
> +
> + ops = dlsym(dlh, "ustream_ssl_ops");
> + if (!ops) {
> + fprintf(stderr, "Could not find required symbol 
> 'ustream_ssl_ops' in ustream-ssl library\n");
> + return -ENOENT;
> + }
> +
> + ctx = ops->context_new(true);
> +
> + if (!ctx) {
> + fprintf(stderr, "Failed to initialize ustream-ssl\n");
> + return -EINVAL;
> + }
> +
> + if (ops->context_set_crt_file(ctx, crt) ||
> + ops->context_set_key_file(ctx, key) ||
> +ops->context_add_ca_crt_file(ctx, ca_crt) || 
> +ops->context_set_mutual_auth(ctx, 1)) {

Tabs vs. space

> + fprintf(stderr, "Failed to load certificates/key files\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
>  static void tls_ustream_read_cb(struct ustream *s, int bytes)
>  {
>   struct client *cl = container_of(s, struct client, ssl.stream);
> diff --git a/tls.h b/tls.h
> index 9be74ba..620ba8f 100644
> --- a/tls.h
> +++ b/tls.h
> @@ -22,12 +22,18 @@
>  
>  #ifdef HAVE_TLS
>  
> +int uh_mtls_init(const char *key, const char *crt, const char *ca_crt);
>  int uh_tls_init(const char *key, const char *crt);
>  void uh_tls_client_attach(struct client *cl);
>  void uh_tls_client_detach(struct client *cl);
>  
>  #else
>  
> +static inline int uh_mtls_init(const char *key, const char *crt, const char 
> *ca_crt)
> +{
> + return -1;
> +}
> +
>  static inline int uh_tls_init(const char *key, const char *crt)
>  {
>   return -1

[OpenWrt-Devel] [PATCH] uhttpd: add support for mutual authentication (mTLS)

[Nuno Morais]

From: Nuno Morais 

Optional mutual authentication (mTLS)
by providing a CA certificate through a new new flag "-M"
in order to verify client's identity.

For B2B applications.

This patch depends on patch
"[OpenWrt-Devel] [PATCH] ustream-ssl: add optional mutual authentication (mTLS)"
---
 main.c | 19 +++
 tls.c  | 38 ++
 tls.h  |  6 ++
 3 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/main.c b/main.c
index fb27665..178d710 100644
--- a/main.c
+++ b/main.c
@@ -134,6 +134,7 @@ static int usage(const char *name)
"   -s [addr:]port  Like -p but provide HTTPS on this 
port\n"
"   -C file ASN.1 server certificate file\n"
"   -K file ASN.1 server private key file\n"
+   "   -M file ASN.1 certificate authority certificate 
file\n"
"   -q  Redirect all HTTP requests to HTTPS\n"
 #endif
"   -h directorySpecify the document root, default is 
'.'\n"
@@ -223,7 +224,8 @@ int main(int argc, char **argv)
int bound = 0;
 #ifdef HAVE_TLS
int n_tls = 0;
-   const char *tls_key = NULL, *tls_crt = NULL;
+   int n_mtls = 0;
+   const char *tls_key = NULL, *tls_crt = NULL, *ca_crt = NULL;
 #endif
 
BUILD_BUG_ON(sizeof(uh_buf) < PATH_MAX);
@@ -232,7 +234,7 @@ int main(int argc, char **argv)
init_defaults_pre();
signal(SIGPIPE, SIG_IGN);
 
-   while ((ch = getopt(argc, argv, 
"A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
+   while ((ch = getopt(argc, argv, 
"A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:M:m:N:n:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
switch(ch) {
 #ifdef HAVE_TLS
case 'C':
@@ -242,6 +244,11 @@ int main(int argc, char **argv)
case 'K':
tls_key = optarg;
break;
+
+case 'M':
+ca_crt = optarg;
+n_mtls++;
+break;
 
case 'q':
conf.tls_redirect = 1;
@@ -477,8 +484,12 @@ int main(int argc, char **argv)
return 1;
}
 
-   if (uh_tls_init(tls_key, tls_crt))
-   return 1;
+   if (n_mtls){
+if (uh_mtls_init(tls_key, tls_crt, ca_crt))
+return 1;
+} else if (uh_tls_init(tls_key, tls_crt))
+return 1;
+
}
 #endif
 
diff --git a/tls.c b/tls.c
index d969b82..bc1a19d 100644
--- a/tls.c
+++ b/tls.c
@@ -66,6 +66,44 @@ int uh_tls_init(const char *key, const char *crt)
return 0;
 }
 
+int uh_mtls_init(const char *key, const char *crt, const char *ca_crt)
+{
+   static bool _init = false;
+
+   if (_init)
+   return 0;
+
+   _init = true;
+   dlh = dlopen("libustream-ssl." LIB_EXT, RTLD_LAZY | RTLD_LOCAL);
+   if (!dlh) {
+   fprintf(stderr, "Failed to load ustream-ssl library: %s\n", 
dlerror());
+   return -ENOENT;
+   }
+
+   ops = dlsym(dlh, "ustream_ssl_ops");
+   if (!ops) {
+   fprintf(stderr, "Could not find required symbol 
'ustream_ssl_ops' in ustream-ssl library\n");
+   return -ENOENT;
+   }
+
+   ctx = ops->context_new(true);
+
+   if (!ctx) {
+   fprintf(stderr, "Failed to initialize ustream-ssl\n");
+   return -EINVAL;
+   }
+
+   if (ops->context_set_crt_file(ctx, crt) ||
+   ops->context_set_key_file(ctx, key) ||
+ops->context_add_ca_crt_file(ctx, ca_crt) || 
+ops->context_set_mutual_auth(ctx, 1)) {
+   fprintf(stderr, "Failed to load certificates/key files\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static void tls_ustream_read_cb(struct ustream *s, int bytes)
 {
struct client *cl = container_of(s, struct client, ssl.stream);
diff --git a/tls.h b/tls.h
index 9be74ba..620ba8f 100644
--- a/tls.h
+++ b/tls.h
@@ -22,12 +22,18 @@
 
 #ifdef HAVE_TLS
 
+int uh_mtls_init(const char *key, const char *crt, const char *ca_crt);
 int uh_tls_init(const char *key, const char *crt);
 void uh_tls_client_attach(struct client *cl);
 void uh_tls_client_detach(struct client *cl);
 
 #else
 
+static inline int uh_mtls_init(const char *key, const char *crt, const char 
*ca_crt)
+{
+   return -1;
+}
+
 static inline int uh_tls_init(const char *key, const char *crt)
 {
return -1;
-- 
2.18.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFT: ar71xx/mac80211 update

[Tom Psyborg]

Why dropping 4.9 support right away?!? I've already tried 4.14 without
mac80211 update and got approximately 20Mbps less throughput on wifi than
with 4.9. If the 4.18 mac80211 update doesn't bring in some of the
peformance lost, I wouldn't even consider 4.14 kernel as a baseline for
anything.

On 13 August 2018 at 17:14, John Crispin  wrote:

> Hi,
>
> as 19.01 will probably use v4.14 as baseline and ath79 wont be a full
> replacement for ar71xx by then we decided to bump ar71xx to v4.14. This is
> available for testing inside my staging tree ->
>
> https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shor
> tlog;h=refs/heads/staging
>
> The tree also holds an update to mac80211, bumping it to the v4.18 wifi
> drivers. If anyone would like to test ar71xx and/or mac80211, feel free to
> do so.
>
> John
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] How to install old version of openvswitch on openwrt

[Tshu Shi]

We are trying to install old version of openvswitch on openwrt, but the
method in here : http://git.yoctoproject.org/cgit/cgit.cgi/opkg/commit/?id=
9da784d5508157cb327d53eb9abcf54e9926a5a5 seems not working. Could you give
us some advises?
The router we used is TL-wr1043nd v2, and the flash we used
is openwrt-18.06.0-ar71xx-generic-tl-wr1043nd-v2-squashfs-factory.bin,
which is offered by openwrt offical website( https://openwrt.org/toh/tp-
link/tl-wr1043nd ).
And the version of opkg is 3b417b9f41b4ceb5912d82f867dd5534e5675b5c
(2017-12-07).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] add Support For Anonabox

[Tom Psyborg]

Hi

correction:

QCA9531 is HoneyBee not Dragonfly

On 19/08/2018, ɹɐɯɹǝפ ʇsnƃn∀  wrote:
> This commit adds support for the Anonabox Pro WiFi-router.
>
> SoC:   Qualcomm Atheros QCA9531 (Dragonfly) 650MHz
> RAM:   128mb
> FLASH: 16mb
> WiFi:  QCA9531 b/g/n
> USB:   1x USB 2.0
>
> Tested and working:
>  - Ethernet (LAN + WAN)
>  - WiFi
>  - OpenWRT sysupgrade
>  - Reset Button
>  - 1 x Green LED
> -USB Port
> This device was part of trunk before the LEDE fork. This is the patch that
> worked on that version for reference:
> https://raw.githubusercontent.com/anonabox/openwrt/master/anonabox_pro.patch
> Which no longer worked after the LEDE/Openwrt merge. The source for this
> new version is this:
> https://github.com/augustgermar/misc/blob/master/anonabox-proLEDEpatch2.patch
> Which I modified to comply with standards for pull requests for trunk.
>
> For the actual pull request as it currently stands please view here:
> https://github.com/openwrt/openwrt/pull/1306
>
> I have been working on getting this hardware back into Trunk for almost a
> year. Any and all feedback on this is welcome.
>
> This compiles under Centos7 and flashes to the hardware properly with all
> functionality working.
>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] We want to know how to modify Makefile

[Tshu Shi]

 Hello,we are students from National Cheng Kung University in Taiwan.
We want to pack package of openvswitch v2.3.1 for openwrt-18.06, but it
seems like there are lots of differences in Makefile between v2.3.1 and
v2.9.2.
If we want to modify a Makefile for openvswitch v2.3.1 by the Makefile
offered by the openwrt offical github, where should we modify?
And if we want to download the openvswitch-2.8.2.tar.gz file from local
host instead of from https://www.openwrt.org/release/, are there anything
we should modify besides PKG_SOURCE_URL and PKG_HASH?
Looking forward to your reply.

Yours fairthfully,Li-Jen Hsu
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Read-only copy of Wiki?

[Nguyễn Hồng Quân]

Hi

The OpenWrt wiki is sometimes too slow to access from my country. So I
would like to host a read-only copy of it, to serve as reference
documentation.

Is this possible? Can you help export the wiki?

Thanks

-- 
Quân

quan.hoabinh.vn  agriconnect.vn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Release 17.01.5 is broken for everyone with IPv6 tunnels

[Alexander E. Patrakov]

Hello.

Due to my work duties, I had to guide the customer how to install OpenWRT
on his router (Linksys WRT1900AC v2) and how to configure it. The customer
requires pretty boring tasks such as setting up PPPoE, updating dynamic
DNS, doing IPv4 NAT, port forwarding, and getting IPv6 from Hurricane
Electric for devices in his network. Why OpenWRT - the need to keep two LAN
segments separate, and the fact that the stock firmware does not support
his dynamic DNS provider. And, as a bonus, the ability to troubleshoot
everything easily with tcpdump.

So, we installed OpenWRT 17.01.5. Everything worked well except IPv6. I
could ping devices in his network from a server in Malaysia, but not from
home. Ssh over IPv6 worked but took a lot of time to set up the connection.
Some IPv6 connections also failed. Tcpdumping shows that the packets come
correctly from Hurricane Electric on pppoe-wan, but do not show up in
6in4-wan6. And there are lots of "sit: non-ECT from ... with TOS=..."
messages.

This is https://bugs.openwrt.org/index.php?do=details&task_id=1541

I have looked at the kernel source here. The bug is that the first part of
the incoming IPv6 header (containing the flow label) is misparsed as IPv4
ToS field. Then it is compared to the ECN field of the outer IPv4 packet.
Every time the message is printed, the packet is dropped. And, because this
comparison of the flow label to ECN is meaningless, it is dropped for no
good reason.

Turris Omnia users have also hit this bug:
https://forum.turris.cz/t/performance-issue-with-ipv6-6rd-on-turris-omnia/7505

As this is a kernel bug, it is impossible to fix by publishing updated
packages for the same OpenWRT release. So, we decided to downgrade the
router to 17.01.4, and so far it works flawlessly.

Given the severity of this problem (essentially, broken IPv6), a large base
of affected customers (everybody who uses 6to4, 6rd, or 6in4 tunnel), and
impossibility to fix by publishing a single updated package, I propose that
the 17.01.5 release is retracted.

Please put something like this on the download page:

"""
Users who rely on IPv6 tunnels (6to4, 6rd, 6in4) should not use this
release due to a bug (
https://bugs.openwrt.org/index.php?do=details&task_id=1541) that makes such
tunnels drop packets for no good reason. Such users should download release
17.01.4 instead.
"""

-- 
Alexander E. Patrakov
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Marty E. Plummer]

On Wed, May 30, 2018 at 10:42:27AM +0800, Clark Wang wrote:
> On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer 
> wrote:
> 
> > > If people are willing to do the conversion between patch formats for
> > their
> > > own purposes, more power to them. I don't see any compelling reason to
> > > change the format I use.
> > >
> > Could I at least convince you to start doing -p1, if not unified?
> >
> 
> I think the cost is too high. All bash package maintainers on different
> *nix systems will have to change accordingly.
> 
> -clark
Well how about this; we ask the downstreams. List taken from repology,
hopefully these are still all active and accurate. So, to reiterate the
original premise of this thread for the newly added, I suggest the
following:

1. Change the official upstream bash patch format to be -p1 applicable,
as a number of major linux distros either convert the patches in their
own source repo to -p1 (debian and its children, fedora and its children),
or have to take an explicit deviation from their default patch
application method (gentoo) in order to apply -p0 patches.

Optional:
2. Change the format of the patch from a context diff to a unified diff,
for the following reasons:
a. unified diffs are generally smaller than an equivalent context
diff, while encoding the same information.
*** a/lib/readline/history.c2015-12-28 13:50:31.0 -0500
--- b/lib/readline/history.c2016-09-30 14:28:40.0 -0400
***
*** 308,312 
{
  if (history_stifled && history_max_entries > 0)
!   history_size = history_max_entries + 2;
  else
history_size = DEFAULT_HISTORY_INITIAL_SIZE;
--- 310,316 
{
  if (history_stifled && history_max_entries > 0)
!   history_size = (history_max_entries > MAX_HISTORY_INITIAL_SIZE)
!   ? MAX_HISTORY_INITIAL_SIZE
!   : history_max_entries + 2;
  else
history_size = DEFAULT_HISTORY_INITIAL_SIZE;

--- a/lib/readline/history.c2015-12-28 13:50:31.0 -0500
+++ b/lib/readline/history.c2016-09-30 14:28:40.0 -0400
@@ -308,5 +310,7 @@
{
  if (history_stifled && history_max_entries > 0)
-   history_size = history_max_entries + 2;
+   history_size = (history_max_entries > MAX_HISTORY_INITIAL_SIZE)
+   ? MAX_HISTORY_INITIAL_SIZE
+   : history_max_entries + 2;
  else
history_size = DEFAULT_HISTORY_INITIAL_SIZE;

b.  unified diffs are easier to size up at a glance than
context diffs.

c.  unified diffs are the
standard for a host of foss projects, especially those using git as a
vcs solution as it produces context diffs by default and you have to
purposely change it to do otherwise.

Maintainers, I'd really like to hear your thoughts on this matter. If
the diffs are produced as -p1 unified diffs, then downstreams who do
convert from -p0 context won't have to, and distros who work around it
won't either.

Regards,

Marty

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Packaging multi-version package (Openwrt Makefile)

[Tomer Eliyahu]

Hi,

What is the correct way to package a multi-version application in Openwrt?
We are using git, so each version differs only in the PKG_SOURCE_VERSION.

I initially added a choice to select the package version (out of 3
supported versions) in the package/config section, but this stopped working
once one version had different dependencies (apparently the config section
is called after the DEPENDS section is parsed).

I would very much like to avoid using different package Makefiles, but for
now it looks like the only way.

Help please:)

Thanks,
Tomer
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4 v1] net: dsa: Add bindings for Realtek SMI DSAs

[Rob Herring]

On Tue, Jul 17, 2018 at 08:55:51AM +0200, Linus Walleij wrote:
> On Mon, Jul 16, 2018 at 10:45 PM Rob Herring  wrote:
> > On Sat, Jul 14, 2018 at 11:45:54AM +0200, Linus Walleij wrote:
> 
> > > +The SMI "Simple Management Interface" is a two-wire protocol using
> >
> > At least for some other Realtek chips, the documentation I find says the
> > S stands for Serial. And Wikipedia says SMI is the same thing as MDIO.
> 
> The only datasheet we have mentions both:
> http://realtek.info/pdf/rtl8366_8369_datasheet_1-1.pdf
> calling it serial management interface when talking to an EEPROM
> calling it systems management interface when talking to a
> PHY.
> 
> (BTW that datsheet has no relation to this driver, that is for
> ASICs 8366 and 8369 which of course have nothing to do with
> RTL8366RB "revision B" that we are running here, which adds
> even more to the confusion.)
> 
> Sadly it would not surprise me if Realtek doesn't even know
> which one it is themselves, given the state of the code and
> documentation that came out of the company.
> 
> I just have to pick something. I can rename it the
> "S Management Interface" if you prefer, OpenWRT called it
> Systems Management Interface.
> 
> > Just want to make sure we don't define GPIOs directly when there should
> > be a layer of abstraction like mdio-gpio.
> 
> OK let's look at it we read a single register with each protocol:
> 
> 1. MDIO: drivers/net/phy/mdio-bitbang.c
>   send_bit is setting data and cycling clock 1-0 (falling edge)
>   begins transactions by sending 32 1:s (well 33 for safe measure)
>   then sends a start bit 01
>   then sends the opcode 10 (read)
>   then sends the PHY address (5 bits)
>   then sends the register address (5 bits)
>   turn around (switch MDIO to input)
>   read 16 bit register value
>   read stop bit
> 
> 2. SMI:
>sends the sequence "101" to start transactions. (No initial ones)
>writes a whole byte which is the "command" read is 0xa9
>on RTL8366RB and apparently something else on other chips
>writes low byte of 16bit address
>writes high byte of 16bit address
>turn around (switch MDIO to input)
>reads the low byte of the 16bit data
>reads the high byte of the 16bit data
>sends the stop sequence 01
>then an extra clock pulse
> 
> As you can see those are pretty different. PHY always being
> addressed in MDIO (the switch chips has PHYs but this
> protocol is not defined exclusively for that) and both phy and
> reg being 5 bits addressing at most 10 address bits is the most
> obvious deviation then 8 bits for command instead of 2 etc.
> 
> It's just very different.

Okay. Just wanted to make sure.

Reviewed-by: Rob Herring 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4 v1] net: dsa: Add bindings for Realtek SMI DSAs

[Rob Herring]

On Sat, Jul 14, 2018 at 11:45:54AM +0200, Linus Walleij wrote:
> The Realtek SMI family is a set of DSA chips that provide
> switching in routers. This binding just follows the pattern
> set by other switches but with the introduction of an embedded
> irqchip to demux and handle the interrupts fired by the single
> line from the chip.
> 
> This interrupt construction is similar to how we handle
> interrupt controllers inside PCI bridges etc.
> 
> Cc: Antti Seppälä 
> Cc: Roman Yeryomin 
> Cc: Colin Leitner 
> Cc: Gabor Juhos 
> Cc: Florian Fainelli 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog RFCv2->v1:
> - No changes, we agree on these bindings.
> ChangeLog RFCv1->RFCv2:
> - Switch to Andrew's suggestion to have a local MDIO bus
>   definition inside of the DSA device node
> - Add realtek,disabled-leds
> - Correct WAN IRQ to 12 in the example
> ---
>  .../bindings/net/dsa/realtek-smi.txt  | 153 ++
>  1 file changed, 153 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt 
> b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
> new file mode 100644
> index ..b6ae8541bd55
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
> @@ -0,0 +1,153 @@
> +Realtek SMI-based Switches
> +==
> +
> +The SMI "Simple Management Interface" is a two-wire protocol using

At least for some other Realtek chips, the documentation I find says the 
S stands for Serial. And Wikipedia says SMI is the same thing as MDIO.

Just want to make sure we don't define GPIOs directly when there should 
be a layer of abstraction like mdio-gpio.

> +bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
> +not use the MDIO protocol. This binding defines how to specify the
> +SMI-based Realtek devices.
> +
> +Required properties:
> +
> +- compatible: must be exactly one of:
> +  "realtek,rtl8366"
> +  "realtek,rtl8366rb" (4+1 ports)
> +  "realtek,rtl8366s"  (4+1 ports)
> +  "realtek,rtl8367"
> +  "realtek,rtl8367b"
> +  "realtek,rtl8368s"  (8 port)
> +  "realtek,rtl8369"
> +  "realtek,rtl8370"   (8 port)
> +
> +Required properties:
> +- mdc-gpios: GPIO line for the MDC clock line.
> +- mdio-gpios: GPIO line for the MDIO data line.
> +- reset-gpios: GPIO line for the reset signal.
> +
> +Optional properties:
> +- realtek,disable-leds: if the LED drivers are not used in the
> +  hardware design this will disable them so they are not turned on
> +  and wasting power.
> +
> +Required subnodes:
> +
> +- interrupt-controller
> +
> +  This defines an interrupt controller with an IRQ line (typically
> +  a GPIO) that will demultiplex and handle the interrupt from the single
> +  interrupt line coming out of one of the SMI-based chips. It most
> +  importantly provides link up/down interrupts to the PHY blocks inside
> +  the ASIC.
> +
> +Required properties of interrupt-controller:
> +
> +- interrupt: parent interrupt, see interrupt-controller/interrupts.txt
> +- interrupt-controller: see interrupt-controller/interrupts.txt
> +- #address-cells: should be <0>
> +- #interrupt-cells: should be <1>
> +
> +- mdio
> +
> +  This defines the internal MDIO bus of the SMI device, mostly for the
> +  purpose of being able to hook the interrupts to the right PHY and
> +  the right PHY to the corresponding port.
> +
> +Required properties of mdio:
> +
> +- compatible: should be set to "realtek,smi-mdio" for all SMI devices
> +
> +See net/mdio.txt for additional MDIO bus properties.
> +
> +See net/dsa/dsa.txt for a list of additional required and optional properties
> +and subnodes of DSA switches.
> +
> +Examples:
> +
> +switch {
> + compatible = "realtek,rtl8366rb";
> + /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
> + mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
> + mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
> +
> + switch_intc: interrupt-controller {
> + /* GPIO 15 provides the interrupt */
> + interrupt-parent = <&gpio0>;
> + interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + port@0 {
> + reg = <0>;
> + label = "lan0";
> + phy-handle = <&phy0>;
> + };
> + port@1 {
> + reg = <1>;
> + label = "lan1";
> + phy-handle = <&phy1>;
> + };
> + port@2 {
> + reg = <2>;
> + label = "lan2";
> +

Re: [OpenWrt-Devel] MR24 sysupgrade seems to be broken

[Russell Senior]

Updating to a current ubi-utils seems to fix it.  It looks like the version
number didn't change with the fix though, so I needed to use
--force-reinstall to overwrite ubi-info 2.0.2-1.

On Mon, Jul 2, 2018 at 4:42 AM, Christian Lamparter 
wrote:

> On Sunday, July 1, 2018 2:26:35 AM CEST Russell Senior wrote:
> > Here is what shows during sysupgrade:
> >
> > https://pastebin.com/YfbQZ5fB
> >
> Have you tried the aforementioned fix for the buggy mtd-utils on
> your old/existing installation or not?
>
> > On Sat, Jun 30, 2018 at 6:49 AM, Christian Lamparter  >
> > wrote:
> > > On Saturday, June 30, 2018 10:06:21 AM CEST Russell Senior wrote:
> > > > I just tried updating a Meraki MR24 to current master, from an image
> a
> > > few
> > > > months old and it broke.  I get a new kernel, but an old rootfs.  I
> have
> > > > some of these deployed where a serial connection is awkward.  It
> would be
> > > > nice if sysupgrade worked.
> > > >
> > > Any idea what broke it? From your description "new kernel, old rootfs"
> it
> > > could be the mtd-utils update to 2.0.2 that broke it:
> > >
> > >  > > f37f63f38ccb706b196fe4934d0d9d92537eb832>
> > >
> > > and this was fixed by me just this month:
> > >
> > >  > > daf19649dbf101ce7ae17abf84eeed7a30b41275>
> > > (also upstream  > > 0f833ac73ad631248826386e2918d8571ecf0347>)
> > >
> > > so I think you would need to somehow update the mtd-utils
> > > package (ubinfo, ubimkvol, ubirmvol, ...)  on your old routers
> > > before performing sysupgrading in order to fix this.
>
>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MR24 sysupgrade seems to be broken

[Russell Senior]

Here is what shows during sysupgrade:

https://pastebin.com/YfbQZ5fB

On Sat, Jun 30, 2018 at 6:49 AM, Christian Lamparter 
wrote:

> On Saturday, June 30, 2018 10:06:21 AM CEST Russell Senior wrote:
> > I just tried updating a Meraki MR24 to current master, from an image a
> few
> > months old and it broke.  I get a new kernel, but an old rootfs.  I have
> > some of these deployed where a serial connection is awkward.  It would be
> > nice if sysupgrade worked.
> >
> Any idea what broke it? From your description "new kernel, old rootfs" it
> could be the mtd-utils update to 2.0.2 that broke it:
>
>  f37f63f38ccb706b196fe4934d0d9d92537eb832>
>
> and this was fixed by me just this month:
>
>  daf19649dbf101ce7ae17abf84eeed7a30b41275>
> (also upstream  0f833ac73ad631248826386e2918d8571ecf0347>)
>
> so I think you would need to somehow update the mtd-utils
> package (ubinfo, ubimkvol, ubirmvol, ...)  on your old routers
> before performing sysupgrading in order to fix this.
>
> Regards,
> Christian
>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] MR24 sysupgrade seems to be broken

[Russell Senior]

I just tried updating a Meraki MR24 to current master, from an image a few
months old and it broke.  I get a new kernel, but an old rootfs.  I have
some of these deployed where a serial connection is awkward.  It would be
nice if sysupgrade worked.

-- 
Russell Senior
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Rainer Müller]

On 2018-05-30 09:04, Marty E. Plummer wrote:
> Maintainers, I'd really like to hear your thoughts on this matter. If
> the diffs are produced as -p1 unified diffs, then downstreams who do
> convert from -p0 context won't have to, and distros who work around it
> won't either.

Speaking as maintainer of bash in MacPorts, I never had problems with
the format of the bash patches. I have no preference whether patches
need -p0 or -p1, as long as all patches are published with the same level.

I think unified diffs are more common than context diffs these days.
However, as long as the bash patches can be applied cleanly with
patch(1), I see no reason to change anything.

Rainer

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath79: DSA with qca8k

[Robert Marko]

You are missing  CONFIG_NET_DSA_TAG_QCA

On 20 June 2018 at 09:21, Lucian Cristian  wrote:

> I tried the example found in bindings and in qca8k staging but I don't
> have any output when the device starts or when the module is loaded, if is
> built as module.
>
> Tried with a qca9563+qca8337n switch and also with a qca9558+qca8327n
> switch with id added to qca8k driver, I also enabled printk on every
> function in the driver but nothing is printed.
>
> I added a new dsa subtarget with this kernel options
>
> # CONFIG_AG71XX is not set
> # CONFIG_AG71XX_DEBUG is not set
> # CONFIG_AG71XX_DEBUG_FS is not set
> # CONFIG_AR8216_PHY is not set
> # CONFIG_AR8216_PHY_LEDS is not set
> # CONFIG_RTL8366RB_PHY is not set
> # CONFIG_RTL8366S_PHY is not set
> # CONFIG_RTL8366_SMI is not set
> # CONFIG_SWCONFIG is not set
> # CONFIG_SWCONFIG_LEDS is not set
> CONFIG_NET_DSA=y
> CONFIG_NET_DSA_RTK_SMI=y
> CONFIG_NET_DSA_QCA8K=y
> CONFIG_NET_NS=y
> CONFIG_NET_PACKET_ENGINE=y
> CONFIG_NET_SWITCHDEV=y
>
> Is there something missing or the problem should be in dts file ?
>
>
> Regards
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] iwinfo: add channel survey

[Nick]

Do u think we could add the channel utilization in the cmd tool?
You would have to do some averaging over a time period...

On 26.06.2018 21:14, Nick wrote:
> Here is the patch. It compiles.
> How can I test this? I'm not sure if I did everything correct.
> I never used lua. :/
>
> From 50ca15c4efcc35b58bc635f6c0fbda4532a519fc Mon Sep 17 00:00:00 2001
> From: PolynomialDivision 
> Date: Tue, 29 May 2018 00:10:01 +0200
> Subject: [PATCH] iwinfo: add channel survey
>
> Add channel survey data.
>
> Signed-off-by: Nick Hainke 
> ---
>  include/iwinfo.h | 11 +++
>  iwinfo_cli.c | 37 +-
>  iwinfo_lua.c | 42 +++
>  iwinfo_nl80211.c | 60
> +++-
>  4 files changed, 148 insertions(+), 2 deletions(-)
>
> diff --git a/include/iwinfo.h b/include/iwinfo.h
> index 929f697..c5db9b6 100644
> --- a/include/iwinfo.h
> +++ b/include/iwinfo.h
> @@ -157,6 +157,16 @@ struct iwinfo_scanlist_entry {
>  struct iwinfo_crypto_entry crypto;
>  };
>  
> +struct iwinfo_survey_entry {
> +    uint32_t frequency;
> +    int8_t noise;
> +    uint64_t channel_time;
> +    uint64_t channel_time_busy;
> +    uint64_t channel_time_ext_busy;
> +    uint64_t channel_time_rx;
> +    uint64_t channel_time_tx;
> +};
> +
>  struct iwinfo_country_entry {
>  uint16_t iso3166;
>  char ccode[4];
> @@ -203,6 +213,7 @@ struct iwinfo_ops {
>  int (*bitrate)(const char *, int *);
>  int (*signal)(const char *, int *);
>  int (*noise)(const char *, int *);
> +    int (*survey)(const char *, struct iwinfo_survey_entry *);
>  int (*quality)(const char *, int *);
>  int (*quality_max)(const char *, int *);
>  int (*mbssid_support)(const char *, int *);
> diff --git a/iwinfo_cli.c b/iwinfo_cli.c
> index 49c9035..2d30fdd 100644
> --- a/iwinfo_cli.c
> +++ b/iwinfo_cli.c
> @@ -116,6 +116,18 @@ static char * format_signal(int sig)
>  return buf;
>  }
>  
> +static char * format_channel_time(uint64_t time)
> +{
> +    static char buf[30];
> +
> +    if (!time)
> +        snprintf(buf, sizeof(buf), "unknown");
> +    else
> +        snprintf(buf, sizeof(buf), "%llu ms", time);
> +
> +    return buf;
> +}
> +
>  static char * format_noise(int noise)
>  {
>  static char buf[10];
> @@ -531,6 +543,25 @@ static char * print_phyname(const struct iwinfo_ops
> *iw, const char *ifname)
>  return "?";
>  }
>  
> +static void print_survey(const struct iwinfo_ops *iw, const char *ifname)
> +{
> +    struct iwinfo_survey_entry entry;
> +    iw->survey(ifname, &entry);
> +
> +    if(iw->survey == NULL){
> +        printf("No survey information available\n");
> +        return;
> +    }
> +
> +    printf("%s\tESSID:\t\t\t\t%s\n", ifname, print_ssid(iw, ifname));
> +    printf("\tChannel:\t\t\t%s (%s)\n", print_channel(iw, ifname),
> format_frequency(entry.frequency));
> +    printf("\tNoise:\t\t\t\t%s\n", format_noise(entry.noise));
> +    printf("\tchannel Active Time:\t\t%s\n",
> format_channel_time(entry.channel_time));
> +    printf("\tChannel Busy
> Time:\t\t%s\n",format_channel_time(entry.channel_time_busy));
> +    printf("\tExtension Channel Busy
> Time:\t%s\n",format_channel_time(entry.channel_time_ext_busy));
> +    printf("\tChannel Receive
> Time:\t\t%s\n",format_channel_time(entry.channel_time_rx));
> +    printf("\tChannel Transmit
> Time:\t\t%s\n",format_channel_time(entry.channel_time_tx));
> +}
>  
>  static void print_info(const struct iwinfo_ops *iw, const char *ifname)
>  {
> @@ -805,6 +836,7 @@ int main(int argc, char **argv)
>          "Usage:\n"
>          "    iwinfo  info\n"
>          "    iwinfo  scan\n"
> +            "    iwinfo  survey\n"
>          "    iwinfo  txpowerlist\n"
>          "    iwinfo  freqlist\n"
>          "    iwinfo  assoclist\n" @@ -883,7 +915,10 @@ int 
> main(int argc, char **argv)         
>         break;                case 's': -                   
> print_scanlist(iw, argv[1]); +                    if(argv[i][1] ==
> 'c') +                        print_scanlist(iw, argv[1]); +       
>             else +                        print_survey(iw, argv[1]);
>                  break;                case 't': diff --git
> a/iwinfo_lua.c b/iwinfo_lua.c index eebab8e..6ed6ffd 100644 ---
> a/iwinfo_lua.c +++ b/iwinfo_lua.c @@ -439,6 +439,46 @@ static int
> iwinfo_L_scanlist(lua_State *L, int (*func)(const char *, char *, int
>  return 1;  }   +/* Wrapper for survey info */ +static int
> iwinfo_L_survey(lua_State *L, int (*func)(const char *, struct
> iwinfo_survey_entry *)) +{ +    const char *ifname =
> luaL_checkstring(L, 1); +    struct iwinfo_survey_entry e; + +    if
> (!(*func)(ifname, &e)) +    { +        lua_newtable(L); + +        /*
> Channel */ +        lua_pushinteger(L, e.frequency); +       
> lua_setfield(L, -2, "frequency");
> +
> +        /* Quality, Signal */
> +        lua_pushinteger(L, e.nois

[OpenWrt-Devel] Openwrt on NetApp FAS3020?

[Steven Mercurio]

I have a few NetApp FAS3020 units which basically are dual Intel Xeon
boards that I wanted to use but can't figure out how to build an OS image
or get it to network boot anything.

The hardware uses a modded version of Broadcom's CFE.  From my
understanding NetApp used the CFE source to get it to run on their x86
platform.

The hardware is GREAT and would be really useful if I can just figure out
how to create a OS image for it or get it to boot from the network.

I saw mentions of the Broadcom CFE and elsewhere that there is x86 support
in openwrt so hoping someone can help me get openwrt running on this HW.

NetApp licenses are a train wreck but the hardware itself is FANTASTIC.
Once I get the OS on it I can see what I need to do next to add things like
SCST, tgtd, NFS, etc.

Would be super cool to extend openwrt into San filer head space.  :-D
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Natanael Copa]

"Marty E. Plummer"  wrote:

> Maintainers, I'd really like to hear your thoughts on this matter. If
> the diffs are produced as -p1 unified diffs, then downstreams who do
> convert from -p0 context won't have to, and distros who work around it
> won't either.  

Alpine Linux uses -p1 and unified diffs for almost everything. I
personally find unified diffs easier to read, but I don't have any
strong opinion what bash should use. It is trivial for us to adapt.

I vote for whatever makes Chet's work easier.

-nc


pgp1UDq8wrzhj.pgp
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Openwrt Query

[Preeti Sethi]

Sir,

I am a B.Tech student currently doing research on co-existence of WiFi and
LTE as an intern at IIT Hyderabad.
I have installed Openwrt in *Buffalo WZR-HP-AG300H* which is used as an
access point for this project. As an intermediate step, I need to
fetch the *queue
status *of WiFi which will help me converge them accordingly.
I found that the *xmit.c* file in the directory '
openwrt/build_dir/toolchain-mips_24kc_gcc-7.3.0_musl/
linux/drivers/net/wireless/ath/ath9k' gives the data about these queues.
So accordingly, I ran the command cat /sys/kernel/debug/ieee80211/
phy0/ath9k/xmit which gave me data about the four queues(VO,VI,BE,BK). I
want to use this output to get the current queue status.

Now to make any change in this file, the only way I could figure out is to
find the corresponding patch file and edit it which is followed by a
rebuild.
And since I am using *Atheros AR7161 *driver,  the modified ath.ko has to
be copied after which I'll reboot the access point as per my knowledge.

This whole process in itself is really tedious and doesn't seem feasible to
extract the working logic of this file. So I request you to guide me on the
same. Kindly tell me if there is an alternative approach to modify and
build files in openwrt or if at all, there is an alternative way to know
the queue status of my access point.

Thanks and Regards,
Preeti Sethi
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Christian Weisgerber]

Marty E. Plummer:

> Maintainers, I'd really like to hear your thoughts on this matter. If
> the diffs are produced as -p1 unified diffs, then downstreams who do
> convert from -p0 context won't have to, and distros who work around it
> won't either.

Speaking in my capacity as the OpenBSD packager for bash, either
way is fine.  We use the upstream patches as provided ("distribution
patches").  These are applied with -p0 by default, but it's utterly
trivial to specify -p1 if necessary.  The choice of context vs.
unified diffs is immaterial; patch(1) handles both formats.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Vladimir Marek]

> > > > If people are willing to do the conversion between patch formats for
> > > their
> > > > own purposes, more power to them. I don't see any compelling reason to
> > > > change the format I use.
> > > >
> > > Could I at least convince you to start doing -p1, if not unified?
> > >
> > 
> > I think the cost is too high. All bash package maintainers on different
> > *nix systems will have to change accordingly.
> > 
> Well how about this; we ask the downstreams. List taken from repology,
> hopefully these are still all active and accurate. So, to reiterate the
> original premise of this thread for the newly added, I suggest the
> following:

Speaking for myself, as a bash maintainer in Solaris, I'm glad for
Chet's work in any shape or form. And I vote for anything which makes
his work easier.

The rest can be scripted

Thank you
-- 
Vlad

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] dnscrypt-proxy package missing in snapshot

[Maciej Soltysiak]

Hi,

It doesn't look like there are any takers for this task.
Can anyone guide me to a 101 tutorial on making a brand new package?
dnscrypt-proxy 2 is completely different from its predecessor. There are
sources, as well as pre-build binaries for 20+ architectures.
go is required to build.

I'd very much appreciate for helping do this,
Maciej

On Sun, Feb 18, 2018 at 12:24 AM, Maciej Soltysiak 
wrote:

> On my MIPS32 (WNDR3800) system, I noticed the C binary was <100k.
> The GO binary is 6.5MB, I ran upx on it and it went down to 1.5M.
> It incurs about 1s of delay for unpacking, but it works.
>
> I don't know much about packaging this around the uci scripting, etc, but
> I hope this helps the maintainer a bit.
>
> Best regards,
> Maciej
>
> On Sat, Feb 17, 2018 at 11:40 PM, Maciej Soltysiak 
> wrote:
>
>> The OpenWrt Makefile aims to get dnscrypt-proxy 1.9.5 from a mirror at
>> https://github.com/dyne/dnscrypt-proxy
>>
>> However, the upstream (Frank Denis) recently released a 2.0 which is
>> significantly different.
>> It's now written in go, instead of C and it support the new version of
>> the protocol (v2).
>>
>> If we're going to get this package fixed we should see if we can get the
>> new one to run.
>> Probably should come from upstream at: https://github.com/jedisct1/dn
>> scrypt-proxy
>>
>> Best regards,
>> Maciej
>>
>> On Mon, May 1, 2017 at 12:48 PM, Alexandru Ardelean <
>> ardeleana...@gmail.com> wrote:
>>
>>> On Mon, May 1, 2017 at 12:04 PM, Mangesh Bhamre 
>>> wrote:
>>> >
>>> > Hello,
>>> >
>>> > Last time I reported this issue was for MT7620.  dnscrypt-proxy now
>>> failing for MT7621.
>>> >
>>> > http://buildbot.openwrt.org:8010/broken_packages/ramips.mt76
>>> 21/dnscrypt-proxy/compile.txt
>>> >
>>> > I am not sure what was the fix made. Likely was related to SSL cert
>>> check. Can anyone please look at this and fix it same way as MT7620 ?
>>> >
>>> > Regards,
>>> > Mangesh
>>> >
>>> > --
>>> > Regards,
>>> >
>>> > Mangesh Bhamre
>>> > Co-founder & CTO | Open Netware
>>> > +91-8879735272 | LinkedIn
>>> >
>>> >
>>> > On Mon, Feb 13, 2017 at 9:33 PM, Ralph Sennhauser <
>>> ralph.sennhau...@gmail.com> wrote:
>>> >>
>>> >> On Mon, 13 Feb 2017 21:03:07 +0530
>>> >> Mangesh Bhamre  wrote:
>>> >>
>>> >> > Hi Alex,
>>> >> >
>>> >> > Looking at build log -
>>> >> > http://buildbot.openwrt.org:8010/broken_packages/ramips.mt76
>>> 20/dnscrypt-proxy/compile.txt
>>> >> >
>>> >> > Tar ball is available on download.dnscrypt.org . Build download
>>> fails
>>> >> > for some SSL issue.
>>> >>
>>> >> The site has HSTS enabled. Might that be the issue?
>>> >>
>>> >> Maybe just updating PKG_SOURCE_URL to use https might be all that
>>> >> is needed. There was another user having issues with a redirect and
>>> >> samba. I think he was using Ubuntu.
>>> >>
>>> >> Ralph
>>> >>
>>> >> >
>>> >> > Also, tar ball is missing on mirror2.openwrt.org and
>>> >> > downloads.openwrt.org/sources
>>> >> >
>>> >> > Not sure, how mirror2 or download.openwrt.org gets updated.  Any
>>> help
>>> >> > in getting is appreciated.
>>> >> >
>>> >> > Regards,
>>> >> > Mangesh
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>> Looks like the package wasn't found on OpenWrt mirrors.
>>> Maybe some intermittent failure.
>>>
>>> You could try to setup your own cache/mirror [for packages/tarballs]
>>> and point your build to use that as primary, and only then fallback to
>>> OpenWrt's official repos.
>>> ___
>>> 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/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Kernel 4.4 readded in Kernel bump

[Adrian Schmutzler]

Hi,

 

the latest kernel bump in openwrt-18.06 reintroduces the kernel 4.4:

 

https://github.com/openwrt/openwrt/commit/ca3174e4e9dedb3990a37800799b72562016a
706

 

Best

 

Adrian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 bug: Flow Offload Active Connections

[Lucian Cristian]

On 29.05.2018 19:55, Jaap Buurman wrote:

Dear all,

Whenever flow offload is enabled (either software or hardware) I can
see many many active connections on the Luci overview page. It can go
up to thousands of active connections. Looking in the "connections"
part of the "realtime graphs" in Luci shows me that even connections
with devices that turned off hours ago are still active. So for some
reasons old connections are not leaving the conntrack table. Turning
off flow offload fixes these issues right away. I am currently running
the latest 18.06 snapshot on a dir-860l. Hopefully this is useful
information for debugging.

Yours sincerely,

Jaap Buurman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel


I also saw this yesterday but on mwan3 scenario, people where 
complaining and didn't understand why this happened but I fixed it by 
rising the conntrack table, by a *lot and I mean a lot!*


Regards

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4 v1] net: dsa: Add bindings for Realtek SMI DSAs

[Linus Walleij]

On Fri, Jul 20, 2018 at 6:17 PM Rob Herring  wrote:
> On Tue, Jul 17, 2018 at 08:55:51AM +0200, Linus Walleij wrote:

> > It's just very different.
>
> Okay. Just wanted to make sure.
>
> Reviewed-by: Rob Herring 

Thanks Rob! And thanks for asking the critical questions, more
often than not I am wrong (like that TPO screen with "custom"
wire protocol that turned out to be an SPI dialect), so it's good
to take this time to go back and check things over.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4 v1] net: dsa: Add bindings for Realtek SMI DSAs

[Linus Walleij]

On Mon, Jul 16, 2018 at 10:45 PM Rob Herring  wrote:
> On Sat, Jul 14, 2018 at 11:45:54AM +0200, Linus Walleij wrote:

> > +The SMI "Simple Management Interface" is a two-wire protocol using
>
> At least for some other Realtek chips, the documentation I find says the
> S stands for Serial. And Wikipedia says SMI is the same thing as MDIO.

The only datasheet we have mentions both:
http://realtek.info/pdf/rtl8366_8369_datasheet_1-1.pdf
calling it serial management interface when talking to an EEPROM
calling it systems management interface when talking to a
PHY.

(BTW that datsheet has no relation to this driver, that is for
ASICs 8366 and 8369 which of course have nothing to do with
RTL8366RB "revision B" that we are running here, which adds
even more to the confusion.)

Sadly it would not surprise me if Realtek doesn't even know
which one it is themselves, given the state of the code and
documentation that came out of the company.

I just have to pick something. I can rename it the
"S Management Interface" if you prefer, OpenWRT called it
Systems Management Interface.

> Just want to make sure we don't define GPIOs directly when there should
> be a layer of abstraction like mdio-gpio.

OK let's look at it we read a single register with each protocol:

1. MDIO: drivers/net/phy/mdio-bitbang.c
  send_bit is setting data and cycling clock 1-0 (falling edge)
  begins transactions by sending 32 1:s (well 33 for safe measure)
  then sends a start bit 01
  then sends the opcode 10 (read)
  then sends the PHY address (5 bits)
  then sends the register address (5 bits)
  turn around (switch MDIO to input)
  read 16 bit register value
  read stop bit

2. SMI:
   sends the sequence "101" to start transactions. (No initial ones)
   writes a whole byte which is the "command" read is 0xa9
   on RTL8366RB and apparently something else on other chips
   writes low byte of 16bit address
   writes high byte of 16bit address
   turn around (switch MDIO to input)
   reads the low byte of the 16bit data
   reads the high byte of the 16bit data
   sends the stop sequence 01
   then an extra clock pulse

As you can see those are pretty different. PHY always being
addressed in MDIO (the switch chips has PHYs but this
protocol is not defined exclusively for that) and both phy and
reg being 5 bits addressing at most 10 address bits is the most
obvious deviation then 8 bits for command instead of 2 etc.

It's just very different.

Yours,
Linus Walleij

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 3/4 v1] net: dsa: realtek-smi: Add Realtek SMI driver

[Linus Walleij]

This adds a driver core for the Realtek SMI chips and a
subdriver for the RTL8366RB. I just added this chip simply
because it is all I can test.

The code is a massaged variant of the code that has been
sitting out-of-tree in OpenWRT for years in the absence of
a proper switch subsystem. This creates a DSA driver for it.
I have tried to credit the original authors wherever
possible.

The main changes I've done from the OpenWRT code:

- Added an IRQ chip inside the RTL8366RB switch to demux and
  handle the line state IRQs.

- Distributed the phy handling out to the PHY driver.

- Added some RTL8366RB code that was missing in the driver at
  the time, such as setting up "green ethernet" with a funny
  jam table and forcing MAC5 (the CPU port) into 1 GBit.

- Select jam table and add the default jam table from the
  vendor driver, also for ASIC "version 0" if need be.

- Do not store jam tables in the device tree, store them
  in the driver.

- Pick in the "initvals" jam tables from OpenWRT's driver
  and make those get selected per compatible for the
  whole system. It's apparently about electrical settings
  for this system and whatnot, not really configuration
  from device tree.

- Implemented LED control: beware of bugs because there are
  no LEDs on the device I am using!

We do not implement custom DSA tags. This is explained in
a comment in the driver as well: this "tagging protocol" is
not simply a few extra bytes tagged on to the ethernet
frame as DSA is used to. Instead, enabling the CPU tags
will make the switch start talking Realtek RRCP internally.
For example a simple ping will make this kind of packets
appear inside the switch:

   ff ff ff ff ff ff bc ae c5 6b a8 3d 88 99 a2 00
0010   08 06 00 01 08 00 06 04 00 01 bc ae c5 6b a8 3d
0020   a9 fe 01 01 00 00 00 00 00 00 a9 fe 01 02 00 00
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

As you can see a custom "8899" tagged packet using the
protocol 0xa2. Norm RRCP appears to always have this
protocol set to 0x01 according to OpenRRCP. You can also
see that this is not a ping packet at all, instead the
switch is starting to talk network management issues
with the CPU port.

So for now custom "tagging" is disabled.

This was tested on the D-Link DIR-685 with initramfs and
OpenWRT userspaces and works fine on all the LAN ports
(lan0 .. lan3). The WAN port is yet not working.

Cc: Antti Seppälä 
Cc: Roman Yeryomin 
Cc: Colin Leitner 
Cc: Gabor Juhos 
Cc: Florian Fainelli 
Signed-off-by: Linus Walleij 
---
ChangeLog RFCv2->v1
- Drop the debugfs leftovers in the state container.
- Use strncpy() to get the MIB strings.
- Renamed Kconfig symbol to NET_DSA_REALTEK_SMI to match
  the PHY symbol better.
- Fixed a ton of checkpatch warnings and errors.
ChangeLog RFCv1->RFCv2:
- Create the internal MDIO bus from the new MDIO node in
  the device tree
- Support disabling all LEDs and LED setup
- Run the per-device "jam tables" to set up registers to
  initial predictable states.
- Fix a bunch of warnings from the static checkers that
  picked up the RFC patch for test immediately
---
 MAINTAINERS   |7 +
 drivers/net/dsa/Kconfig   |   11 +
 drivers/net/dsa/Makefile  |2 +
 drivers/net/dsa/realtek-smi.c |  487 +++
 drivers/net/dsa/realtek-smi.h |  144 
 drivers/net/dsa/rtl8366.c |  516 
 drivers/net/dsa/rtl8366rb.c   | 1424 +
 7 files changed, 2591 insertions(+)
 create mode 100644 drivers/net/dsa/realtek-smi.c
 create mode 100644 drivers/net/dsa/realtek-smi.h
 create mode 100644 drivers/net/dsa/rtl8366.c
 create mode 100644 drivers/net/dsa/rtl8366rb.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9d5eeff51b5f..174749b9ef96 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12048,6 +12048,13 @@ S: Maintained
 F: sound/soc/codecs/rt*
 F: include/sound/rt*.h
 
+REALTEK RTL83xx SMI DSA ROUTER CHIPS
+M: Linus Walleij 
+S: Maintained
+F: Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
+F: drivers/net/dsa/realtek-smi*
+F: drivers/net/dsa/rtl83*
+
 REGISTER MAP ABSTRACTION
 M: Mark Brown 
 L: linux-ker...@vger.kernel.org
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 2b81b97e994f..6bf4de83b34c 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -52,6 +52,17 @@ config NET_DSA_QCA8K
  This enables support for the Qualcomm Atheros QCA8K Ethernet
  switch chips.
 
+config NET_DSA_REALTEK_SMI
+   tristate "Realtek SMI Ethernet switch family support"
+   depends on NET_DSA
+   select FIXED_PHY
+   select IRQ_DOMAIN
+   select REALTEK_PHY
+   select REGMAP
+   ---help---
+ This enables support for the Realtek SMI-based switch
+ chips, currently only RTL8366RB.
+
 config NET_DSA_SMSC_LAN9303
tristate
select NET_DSA_TAG_LAN9303
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index 15c2a831edf1..8989

[OpenWrt-Devel] [PATCH 2/4 v1] net: dsa: Add bindings for Realtek SMI DSAs

[Linus Walleij]

The Realtek SMI family is a set of DSA chips that provide
switching in routers. This binding just follows the pattern
set by other switches but with the introduction of an embedded
irqchip to demux and handle the interrupts fired by the single
line from the chip.

This interrupt construction is similar to how we handle
interrupt controllers inside PCI bridges etc.

Cc: Antti Seppälä 
Cc: Roman Yeryomin 
Cc: Colin Leitner 
Cc: Gabor Juhos 
Cc: Florian Fainelli 
Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij 
---
ChangeLog RFCv2->v1:
- No changes, we agree on these bindings.
ChangeLog RFCv1->RFCv2:
- Switch to Andrew's suggestion to have a local MDIO bus
  definition inside of the DSA device node
- Add realtek,disabled-leds
- Correct WAN IRQ to 12 in the example
---
 .../bindings/net/dsa/realtek-smi.txt  | 153 ++
 1 file changed, 153 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt

diff --git a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt 
b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
new file mode 100644
index ..b6ae8541bd55
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
@@ -0,0 +1,153 @@
+Realtek SMI-based Switches
+==
+
+The SMI "Simple Management Interface" is a two-wire protocol using
+bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
+not use the MDIO protocol. This binding defines how to specify the
+SMI-based Realtek devices.
+
+Required properties:
+
+- compatible: must be exactly one of:
+  "realtek,rtl8366"
+  "realtek,rtl8366rb" (4+1 ports)
+  "realtek,rtl8366s"  (4+1 ports)
+  "realtek,rtl8367"
+  "realtek,rtl8367b"
+  "realtek,rtl8368s"  (8 port)
+  "realtek,rtl8369"
+  "realtek,rtl8370"   (8 port)
+
+Required properties:
+- mdc-gpios: GPIO line for the MDC clock line.
+- mdio-gpios: GPIO line for the MDIO data line.
+- reset-gpios: GPIO line for the reset signal.
+
+Optional properties:
+- realtek,disable-leds: if the LED drivers are not used in the
+  hardware design this will disable them so they are not turned on
+  and wasting power.
+
+Required subnodes:
+
+- interrupt-controller
+
+  This defines an interrupt controller with an IRQ line (typically
+  a GPIO) that will demultiplex and handle the interrupt from the single
+  interrupt line coming out of one of the SMI-based chips. It most
+  importantly provides link up/down interrupts to the PHY blocks inside
+  the ASIC.
+
+Required properties of interrupt-controller:
+
+- interrupt: parent interrupt, see interrupt-controller/interrupts.txt
+- interrupt-controller: see interrupt-controller/interrupts.txt
+- #address-cells: should be <0>
+- #interrupt-cells: should be <1>
+
+- mdio
+
+  This defines the internal MDIO bus of the SMI device, mostly for the
+  purpose of being able to hook the interrupts to the right PHY and
+  the right PHY to the corresponding port.
+
+Required properties of mdio:
+
+- compatible: should be set to "realtek,smi-mdio" for all SMI devices
+
+See net/mdio.txt for additional MDIO bus properties.
+
+See net/dsa/dsa.txt for a list of additional required and optional properties
+and subnodes of DSA switches.
+
+Examples:
+
+switch {
+   compatible = "realtek,rtl8366rb";
+   /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
+   mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
+   mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+   reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
+
+   switch_intc: interrupt-controller {
+   /* GPIO 15 provides the interrupt */
+   interrupt-parent = <&gpio0>;
+   interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   };
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+   port@0 {
+   reg = <0>;
+   label = "lan0";
+   phy-handle = <&phy0>;
+   };
+   port@1 {
+   reg = <1>;
+   label = "lan1";
+   phy-handle = <&phy1>;
+   };
+   port@2 {
+   reg = <2>;
+   label = "lan2";
+   phy-handle = <&phy2>;
+   };
+   port@3 {
+   reg = <3>;
+   label = "lan3";
+   phy-handle = <&phy3>;
+   };
+   port@4 {
+   reg = <4>;
+   label = "wan";
+   phy-handle = <&phy4>;
+   };
+   port@5 {
+   reg = <5>;
+   label = "cpu";
+   ethernet = <&gmac0>;
+

Re: [OpenWrt-Devel] broken link

[Juergen Kimmel]

No, it is not!

David Woodhouse  schrieb am Mi., 27. Juni 2018, 09:38:

> On Wed, 2018-06-27 at 00:52 +0200, Lev wrote:
> > Please note that this link is broken:
> >
> > https://lists.openwrt.org/listinfo/openwrt-devel
>
> Should be fixed now. Thanks.___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/4 v1] net: phy: realtek: Support RTL8366RB variant

[Linus Walleij]

The RTL8366RB is an ASIC with five internal PHYs for
LAN0..LAN3 and WAN. The PHYs are spawn off the main
device so they can be handled in a distributed manner
by the Realtek PHY driver. All that is really needed
is the power save feature enablement and letting the
PHY driver core pick up the IRQ from the switch chip.

Cc: Antti Seppälä 
Cc: Roman Yeryomin 
Cc: Colin Leitner 
Cc: Gabor Juhos 
Cc: Florian Fainelli 
Signed-off-by: Linus Walleij 
---
ChangeLog RFCv2->v1
- Correct the PHY power save register from 0x21 to 0x15
  as it should be.
- Drop the comment about the DSA switch.
- Use BIT(12) for power save bit define
- Use phy_set_bits() to simplify code
- Skip assigning genphy_config_aneg() and
  genphy_read_status() as this is default anyway
ChangeLog RFCv1->RFCv2:
- No real changes.
---
 drivers/net/phy/realtek.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 082fb40c656d..d0d07f22df1f 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -37,6 +37,9 @@
 #define RTL8201F_ISR   0x1e
 #define RTL8201F_IER   0x13
 
+#define RTL8366RB_POWER_SAVE   0x15
+#define RTL8366RB_POWER_SAVE_ONBIT(12)
+
 MODULE_DESCRIPTION("Realtek PHY driver");
 MODULE_AUTHOR("Johnson Leung");
 MODULE_LICENSE("GPL");
@@ -159,6 +162,24 @@ static int rtl8211b_resume(struct phy_device *phydev)
return genphy_resume(phydev);
 }
 
+static int rtl8366rb_config_init(struct phy_device *phydev)
+{
+   int ret;
+
+   ret = genphy_config_init(phydev);
+   if (ret < 0)
+   return ret;
+
+   ret = phy_set_bits(phydev, RTL8366RB_POWER_SAVE,
+  RTL8366RB_POWER_SAVE_ON);
+   if (ret) {
+   dev_err(&phydev->mdio.dev,
+   "error enabling power management\n");
+   }
+
+   return ret;
+}
+
 static struct phy_driver realtek_drvs[] = {
{
.phy_id = 0x8201,
@@ -223,6 +244,15 @@ static struct phy_driver realtek_drvs[] = {
.resume = genphy_resume,
.read_page  = rtl821x_read_page,
.write_page = rtl821x_write_page,
+   }, {
+   .phy_id = 0x001cc961,
+   .name   = "RTL8366RB Gigabit Ethernet",
+   .phy_id_mask= 0x001f,
+   .features   = PHY_GBIT_FEATURES,
+   .flags  = PHY_HAS_INTERRUPT,
+   .config_init= &rtl8366rb_config_init,
+   .suspend= genphy_suspend,
+   .resume = genphy_resume,
},
 };
 
@@ -234,6 +264,7 @@ static struct mdio_device_id __maybe_unused realtek_tbl[] = 
{
{ 0x001cc914, 0x001f },
{ 0x001cc915, 0x001f },
{ 0x001cc916, 0x001f },
+   { 0x001cc961, 0x001f },
{ }
 };
 
-- 
2.17.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [1/4, RFCv2] net: phy: realtek: Support RTL8366RB variant

[Linus Walleij]

On Tue, May 29, 2018 at 8:51 PM, Heiner Kallweit  wrote:

>> +#define RTL8366RB_POWER_SAVE 0x21

> Typically PHY register addresses are 5 bits wide, is 0x21 correct
> and I miss something?

If it is correct I don't know, but it appears in the vendor
code:

/*Power Saving*/
#define RTL8368S_POWER_SAVING_PAGE  0
#define RTL8368S_POWER_SAVING_REG   21
#define RTL8368S_POWER_SAVING_BIT_MSK   0x1000

Then:

phySmiAddr = 0x8000 | (1<<(phyNo +RTL8368S_PHY_NO_OFFSET)) |

((RTL8368S_POWER_SAVING_PAGE

[OpenWrt-Devel] support on netis 2880

[Jan Bělohlávek]

Hello 
can you help me please ? 

i could not find version of owrt, which fit to router netis 2880 

i checked specs and it would be able to run it 
64 MB RAM and 16 MB flash, Mediatek cpu



i founded only buid for 2780 and 2881 and this is different


thank you very much

Have a nice day 

Jan Bělohlávek



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Matt Housh via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On 5/30/2018 02:04, Marty E. Plummer wrote:
> On Wed, May 30, 2018 at 10:42:27AM +0800, Clark Wang wrote:
>> On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer 
>> wrote:
>>
 If people are willing to do the conversion between patch formats for
>>> their
 own purposes, more power to them. I don't see any compelling reason to
 change the format I use.

>>> Could I at least convince you to start doing -p1, if not unified?
>>>
>>
>> I think the cost is too high. All bash package maintainers on different
>> *nix systems will have to change accordingly.
>>
>> -clark
> Well how about this; we ask the downstreams. List taken from repology,
> hopefully these are still all active and accurate. So, to reiterate the
> original premise of this thread for the newly added, I suggest the
> following:
> 
> 1. Change the official upstream bash patch format to be -p1 applicable,
> as a number of major linux distros either convert the patches in their
> own source repo to -p1 (debian and its children, fedora and its children),
> or have to take an explicit deviation from their default patch
> application method (gentoo) in order to apply -p0 patches.
> 
> Optional:
> 2. Change the format of the patch from a context diff to a unified diff,
> for the following reasons:
> a. unified diffs are generally smaller than an equivalent context
> diff, while encoding the same information.
> *** a/lib/readline/history.c2015-12-28 13:50:31.0 -0500
> --- b/lib/readline/history.c2016-09-30 14:28:40.0 -0400
> ***
> *** 308,312 
>   {
> if (history_stifled && history_max_entries > 0)
> !   history_size = history_max_entries + 2;
> else
>   history_size = DEFAULT_HISTORY_INITIAL_SIZE;
> --- 310,316 
>   {
> if (history_stifled && history_max_entries > 0)
> !   history_size = (history_max_entries > 
> MAX_HISTORY_INITIAL_SIZE)
> !   ? MAX_HISTORY_INITIAL_SIZE
> !   : history_max_entries + 2;
> else
>   history_size = DEFAULT_HISTORY_INITIAL_SIZE;
> 
> --- a/lib/readline/history.c2015-12-28 13:50:31.0 -0500
> +++ b/lib/readline/history.c2016-09-30 14:28:40.0 -0400
> @@ -308,5 +310,7 @@
>   {
> if (history_stifled && history_max_entries > 0)
> -   history_size = history_max_entries + 2;
> +   history_size = (history_max_entries > 
> MAX_HISTORY_INITIAL_SIZE)
> +   ? MAX_HISTORY_INITIAL_SIZE
> +   : history_max_entries + 2;
> else
>   history_size = DEFAULT_HISTORY_INITIAL_SIZE;
> 
> b.  unified diffs are easier to size up at a glance than
> context diffs.
> 
> c.  unified diffs are the
> standard for a host of foss projects, especially those using git as a
> vcs solution as it produces context diffs by default and you have to
> purposely change it to do otherwise.
> 
> Maintainers, I'd really like to hear your thoughts on this matter. If
> the diffs are produced as -p1 unified diffs, then downstreams who do
> convert from -p0 context won't have to, and distros who work around it
> won't either.
> 
> Regards,
> 
> Marty
> 

Greetings,

Speaking for the CRUX maintainers, we don't have a preference. Whatever
works best for upstream.

Regards,
Matt


pEpkey.asc
Description: application/pgp-keys
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [1/4, RFCv2] net: phy: realtek: Support RTL8366RB variant

[Heiner Kallweit]

Am 29.05.2018 um 22:01 schrieb Linus Walleij:
> On Tue, May 29, 2018 at 8:51 PM, Heiner Kallweit  wrote:
> 
>>> +#define RTL8366RB_POWER_SAVE 0x21
> 
>> Typically PHY register addresses are 5 bits wide, is 0x21 correct
>> and I miss something?
> 
> If it is correct I don't know, but it appears in the vendor
> code:
> 
> /*Power Saving*/
> #define RTL8368S_POWER_SAVING_PAGE  0
> #define RTL8368S_POWER_SAVING_REG   21
This is a decimal number .. You use 0x21.


> #define RTL8368S_POWER_SAVING_BIT_MSK   0x1000
> 
> Then:
> 
> phySmiAddr = 0x8000 | (1<<(phyNo +RTL8368S_PHY_NO_OFFSET)) |
> 
> ((RTL8368S_POWER_SAVING_PAGE< |
> (RTL8368S_POWER_SAVING_REG&RTL8368S_PHY_REG_MASK);
> 
> retVal = rtl8368s_setAsicReg(phySmiAddr, 0);
> if (retVal !=  SUCCESS)
> return retVal;
> 
> The PHYs are accessed here in memory area 0x8000.
> 
> Fixed the rest, thanks!
> 
> Yours,
> Linus Walleij
> 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4 RFCv2] net: dsa: Add bindings for Realtek SMI DSAs

[Florian Fainelli]

On 05/28/2018 10:47 AM, Linus Walleij wrote:
> The Realtek SMI family is a set of DSA chips that provide
> switching in routers. This binding just follows the pattern
> set by other switches but with the introduction of an embedded
> irqchip to demux and handle the interrupts fired by the single
> line from the chip.
> 
> This interrupt construction is similar to how we handle
> interrupt controllers inside PCI bridges etc.
> 
> Cc: Antti Seppälä 
> Cc: Roman Yeryomin 
> Cc: Colin Leitner 
> Cc: Gabor Juhos 
> Cc: Florian Fainelli 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---

> +
> + mdio {
> + compatible = "realtek,smi-mdio", "dsa-mdio";

You should drop the "dsa-mdio" compatible string here since it both non
documented and not matched either.

Other than that, this looks great, with that fixed:

Reviewed-by: Florian Fainelli 
-- 
Florian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] build failure on 18.06 from git (usbip)

[Eneas Queiroz via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
 Try 
this:https://patch-diff.githubusercontent.com/raw/openwrt/packages/pull/6062.patch

This was merged in master, but not in 18.06.  It will compile, but I wasn't 
able to make it run myself.  I have no experience with the package to know if 
it's a build/configuration failure, or plain incompatibility with any library 
used in openwrt.  The changes I proposed should not break it, in theory anyway. 
 You might want to test it with 18.06, and either make a new PR, or just ask 
for a straight cherry-pick, as @hnyman suggested.
https://patch-diff.githubusercontent.com/raw/openwrt/packages/pull/6062

I hope this helps.  It might be better to discuss this in the package feed 
repo, as this list is for the main openwrt development.
Cheers,
Eneas
Em sábado, 28 de julho de 2018 11:07:00 BRT, Torbjorn Jansson 
 escreveu:  
 
 Hello

i tried building openwrt 18.06 branch today but i got stuck due to a build 
failure on this:

-
Applying ./patches-2.0/100-musl-compat.patch using plaintext:
patching file src/usbipd.c
Hunk #1 FAILED at 453.
1 out of 1 hunk FAILED -- saving rejects to file src/usbipd.c.rej
Patch failed!  Please fix ./patches-2.0/100-musl-compat.patch!
-

any idea whats wrong and how to fix it?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
  --- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [1/4, RFCv2] net: phy: realtek: Support RTL8366RB variant

[Heiner Kallweit]

Am 28.05.2018 um 19:47 schrieb Linus Walleij:
> The RTL8366RB is an ASIC with five internal PHYs for
> LAN0..LAN3 and WAN. The PHYs are spawn off the main
> device so they can be handled in a distributed manner
> by the Realtek PHY driver. All that is really needed
> is the power save feature enablement and letting the
> PHY driver core pick up the IRQ from the switch chip.
> 
> Cc: Antti Seppälä 
> Cc: Roman Yeryomin 
> Cc: Colin Leitner 
> Cc: Gabor Juhos 
> Cc: Florian Fainelli 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog RFCv1->RFCv2:
> - No real changes.
> ---
>  drivers/net/phy/realtek.c | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index 9f48ecf9c627..21624d1c9d38 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -37,6 +37,9 @@
>  #define RTL8201F_ISR 0x1e
>  #define RTL8201F_IER 0x13
>  
> +#define RTL8366RB_POWER_SAVE 0x21
Typically PHY register addresses are 5 bits wide, is 0x21 correct
and I miss something?

> +#define RTL8366RB_POWER_SAVE_ON 0x1000
Use BIT(12) instead?

> +
>  MODULE_DESCRIPTION("Realtek PHY driver");
>  MODULE_AUTHOR("Johnson Leung");
>  MODULE_LICENSE("GPL");
> @@ -145,6 +148,22 @@ static int rtl8211f_config_init(struct phy_device 
> *phydev)
>   return phy_modify_paged(phydev, 0xd08, 0x11, RTL8211F_TX_DELAY, val);
>  }
>  
> +static int rtl8366rb_config_init(struct phy_device *phydev)
> +{
> + int ret;
> + u16 reg;
> +
> + ret = genphy_config_init(phydev);
> + if (ret < 0)
> + return ret;
> +
> + reg = phy_read(phydev, RTL8366RB_POWER_SAVE);
> + reg |= RTL8366RB_POWER_SAVE_ON;
> + phy_write(phydev, RTL8366RB_POWER_SAVE, reg);
return phy_set_bits(phydev, RTL8366RB_POWER_SAVE, RTL8366RB_POWER_SAVE_ON);
would be easier.

> +
> + return 0;
> +}
> +
>  static struct phy_driver realtek_drvs[] = {
>   {
>   .phy_id = 0x8201,
> @@ -207,6 +226,18 @@ static struct phy_driver realtek_drvs[] = {
>   .resume = genphy_resume,
>   .read_page  = rtl821x_read_page,
>   .write_page = rtl821x_write_page,
> + }, {
> + /* The main part of this DSA is in drivers/net/dsa */
> + .phy_id = 0x001cc961,
> + .name   = "RTL8366RB Gigabit Ethernet",
> + .phy_id_mask= 0x001f,
> + .features   = PHY_GBIT_FEATURES,
> + .flags  = PHY_HAS_INTERRUPT,
> + .config_aneg= &genphy_config_aneg,
Can be omitted, genphy_config_aneg is the default since 00fde79532d6
"net: phy: core: use genphy version of callbacks read_status and
config_aneg per default".

> + .config_init= &rtl8366rb_config_init,
> + .read_status= &genphy_read_status,
Can be omitted, genphy_read_status is the default.

> + .suspend= genphy_suspend,
> + .resume = genphy_resume,
>   },
>  };
>  
> @@ -218,6 +249,7 @@ static struct mdio_device_id __maybe_unused realtek_tbl[] 
> = {
>   { 0x001cc914, 0x001f },
>   { 0x001cc915, 0x001f },
>   { 0x001cc916, 0x001f },
> + { 0x001cc961, 0x001f },
>   { }
>  };
>  
> 


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] clearfog pro - build eMMC with openwrt, not SDCARD

[Darrell Jung - Hanshin Vision]

Hi,

I found out below link and download 
openwrt-mvebu-cortexa9-armada-388-clearfog-base-ext4.img from the site.
And flashing it to eMMC in clearfog pro. It is booted without problem.
https://www.lteforum.at/mobilfunk/clearfog-base.9718/

I build openwrt and check ext4 when make menuconfig with below openwrt github.
https://github.com/SolidRun/openwrt.

but I can see only 
openwrt-mvebu-cortexa9-armada-388-clearfog-pro-ext4-sdcard.img.gz which looks 
only for SDCARD!
When I flashing it to clearfog pro, it is not booted properly. it looks SDCARD 
version which is not working on eMMC.

Do you know how to make the 
openwrt-mvebu-cortexa9-armada-388-clearfog-base-ext4.img, not 
openwrt-mvebu-cortexa9-armada-388-clearfog-pro-ext4-sdcard.img.gz on openwrt?

It looks it is related with target/linux/mvebu folder but I guess it is just 
made for SDCARD version.

Please let me know how to make the 
openwrt-mvebu-cortexa9-armada-388-clearfog-base-ext4.img, not 
openwrt-mvebu-cortexa9-armada-388-clearfog-pro-ext4-sdcard.img.gz on openwrt if 
you can.

Always thank you for all your help and I think I have a good progress and 
almost last point to make it work.

Thanks
Regards
Darrell Jung

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Eric Blake]

On 05/30/2018 02:04 AM, Marty E. Plummer wrote:


Maintainers, I'd really like to hear your thoughts on this matter. If
the diffs are produced as -p1 unified diffs, then downstreams who do
convert from -p0 context won't have to, and distros who work around it
won't either.


Makes no real difference to me on the Cygwin port.  -p1 is slightly 
nicer, but it's a scripted solution to apply patches, and very easy to 
tweak the script to match whatever the patches look like.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Current status of support for RB953GS-5HnT-RP

[David Johnson]

The last patch I saw was from gui in Jan 2017 but I haven't seen this patch
added to the latest openwrt code

https://lists.openwrt.org/pipermail/openwrt-devel/2017-January/005212.html

It appeared that there were issues with the Ethernet ports - was that the
only problem left for full support?

Thanks
David
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Marty E. Plummer]

On Wed, May 30, 2018 at 04:59:15PM +0200, Christian Weisgerber wrote:
> Marty E. Plummer:
> 
> > Maintainers, I'd really like to hear your thoughts on this matter. If
> > the diffs are produced as -p1 unified diffs, then downstreams who do
> > convert from -p0 context won't have to, and distros who work around it
> > won't either.
> 
> Speaking in my capacity as the OpenBSD packager for bash, either
> way is fine.  We use the upstream patches as provided ("distribution
> patches").  These are applied with -p0 by default, but it's utterly
> trivial to specify -p1 if necessary.  The choice of context vs.
> unified diffs is immaterial; patch(1) handles both formats.
> 
Are they -p0 by default for all packages, or just for bash?
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Emanuel Haupt]

"Marty E. Plummer"  wrote:
> On Wed, May 30, 2018 at 10:42:27AM +0800, Clark Wang wrote:
> > On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer
> >  wrote:
> > 
> > > > If people are willing to do the conversion between patch
> > > > formats for
> > > their
> > > > own purposes, more power to them. I don't see any compelling
> > > > reason to change the format I use.
> > > >
> > > Could I at least convince you to start doing -p1, if not unified?
> > >
> > 
> > I think the cost is too high. All bash package maintainers on
> > different *nix systems will have to change accordingly.
> > 
> > -clark
> Well how about this; we ask the downstreams. List taken from repology,
> hopefully these are still all active and accurate. So, to reiterate
> the original premise of this thread for the newly added, I suggest the
> following:
> 
> 1. Change the official upstream bash patch format to be -p1
> applicable, as a number of major linux distros either convert the
> patches in their own source repo to -p1 (debian and its children,
> fedora and its children), or have to take an explicit deviation from
> their default patch application method (gentoo) in order to apply -p0
> patches.
> 
> Optional:
> 2. Change the format of the patch from a context diff to a unified
> diff, for the following reasons:
> a. unified diffs are generally smaller than an equivalent context
> diff, while encoding the same information.
> *** a/lib/readline/history.c2015-12-28 13:50:31.0
> -0500
> --- b/lib/readline/history.c2016-09-30 14:28:40.0
> -0400 ***
> *** 308,312 
>   {
> if (history_stifled && history_max_entries > 0)
> !   history_size = history_max_entries + 2;
> else
>   history_size = DEFAULT_HISTORY_INITIAL_SIZE;
> --- 310,316 
>   {
> if (history_stifled && history_max_entries > 0)
> !   history_size = (history_max_entries >
> MAX_HISTORY_INITIAL_SIZE) !   ?
> MAX_HISTORY_INITIAL_SIZE !   :
> history_max_entries + 2; else
>   history_size = DEFAULT_HISTORY_INITIAL_SIZE;
> 
> --- a/lib/readline/history.c2015-12-28 13:50:31.0
> -0500 +++ b/lib/readline/history.c2016-09-30 14:28:40.0
> -0400 @@ -308,5 +310,7 @@
>   {
> if (history_stifled && history_max_entries > 0)
> -   history_size = history_max_entries + 2;
> +   history_size = (history_max_entries >
> MAX_HISTORY_INITIAL_SIZE)
> +   ? MAX_HISTORY_INITIAL_SIZE
> +   : history_max_entries + 2;
> else
>   history_size = DEFAULT_HISTORY_INITIAL_SIZE;
> 
> b.  unified diffs are easier to size up at a glance than
> context diffs.
> 
> c.  unified diffs are
> the standard for a host of foss projects, especially those using git
> as a vcs solution as it produces context diffs by default and you
> have to purposely change it to do otherwise.
> 
> Maintainers, I'd really like to hear your thoughts on this matter. If
> the diffs are produced as -p1 unified diffs, then downstreams who do
> convert from -p0 context won't have to, and distros who work around it
> won't either.

FreeBSD ports/package maintainer here.

The FreeBSD ports framework uses -p0 by default:

# make -VPATCH_STRIP -C /usr/ports/shells/bash
-p0

As long as all patches come with the same patch strip level I could
simply change the PATCH_STRIP variable.

Our porters handbook advertises unified diffs:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html

Personally I find unified diffs easier to read. From a FreeBSD
viewpoint I don't see a need to switch from -p0 to -p1.

Then again I have no strong feelings one way or the other.

Emanuel


pgp5pgeZ9nOHF.pgp
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Marty E. Plummer]

On Wed, May 30, 2018 at 10:30:10AM +0200, Emanuel Haupt wrote:
> "Marty E. Plummer"  wrote:
> > On Wed, May 30, 2018 at 10:42:27AM +0800, Clark Wang wrote:
> > > On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer
> > >  wrote:
> > > 
> > > > > If people are willing to do the conversion between patch
> > > > > formats for
> > > > their
> > > > > own purposes, more power to them. I don't see any compelling
> > > > > reason to change the format I use.
> > > > >
> > > > Could I at least convince you to start doing -p1, if not unified?
> > > >
> > > 
> > > I think the cost is too high. All bash package maintainers on
> > > different *nix systems will have to change accordingly.
> > > 
> > > -clark
> > Well how about this; we ask the downstreams. List taken from repology,
> > hopefully these are still all active and accurate. So, to reiterate
> > the original premise of this thread for the newly added, I suggest the
> > following:
> > 
> > 1. Change the official upstream bash patch format to be -p1
> > applicable, as a number of major linux distros either convert the
> > patches in their own source repo to -p1 (debian and its children,
> > fedora and its children), or have to take an explicit deviation from
> > their default patch application method (gentoo) in order to apply -p0
> > patches.
> > 
> > Optional:
> > 2. Change the format of the patch from a context diff to a unified
> > diff, for the following reasons:
> > a. unified diffs are generally smaller than an equivalent context
> > diff, while encoding the same information.
> > *** a/lib/readline/history.c2015-12-28 13:50:31.0
> > -0500
> > --- b/lib/readline/history.c2016-09-30 14:28:40.0
> > -0400 ***
> > *** 308,312 
> > {
> >   if (history_stifled && history_max_entries > 0)
> > !   history_size = history_max_entries + 2;
> >   else
> > history_size = DEFAULT_HISTORY_INITIAL_SIZE;
> > --- 310,316 
> > {
> >   if (history_stifled && history_max_entries > 0)
> > !   history_size = (history_max_entries >
> > MAX_HISTORY_INITIAL_SIZE) !   ?
> > MAX_HISTORY_INITIAL_SIZE !   :
> > history_max_entries + 2; else
> > history_size = DEFAULT_HISTORY_INITIAL_SIZE;
> > 
> > --- a/lib/readline/history.c2015-12-28 13:50:31.0
> > -0500 +++ b/lib/readline/history.c2016-09-30 14:28:40.0
> > -0400 @@ -308,5 +310,7 @@
> > {
> >   if (history_stifled && history_max_entries > 0)
> > -   history_size = history_max_entries + 2;
> > +   history_size = (history_max_entries >
> > MAX_HISTORY_INITIAL_SIZE)
> > +   ? MAX_HISTORY_INITIAL_SIZE
> > +   : history_max_entries + 2;
> >   else
> > history_size = DEFAULT_HISTORY_INITIAL_SIZE;
> > 
> > b.  unified diffs are easier to size up at a glance than
> > context diffs.
> > 
> > c.  unified diffs are
> > the standard for a host of foss projects, especially those using git
> > as a vcs solution as it produces context diffs by default and you
> > have to purposely change it to do otherwise.
> > 
> > Maintainers, I'd really like to hear your thoughts on this matter. If
> > the diffs are produced as -p1 unified diffs, then downstreams who do
> > convert from -p0 context won't have to, and distros who work around it
> > won't either.
> 
> FreeBSD ports/package maintainer here.
> 
> The FreeBSD ports framework uses -p0 by default:
> 
> # make -VPATCH_STRIP -C /usr/ports/shells/bash
> -p0
> 
> As long as all patches come with the same patch strip level I could
> simply change the PATCH_STRIP variable.
> 
> Our porters handbook advertises unified diffs:
> 
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html
Interesting, but this document seems to be about makign patches yourself
and not official upstream patches; unless I'm missing something.
> 
> Personally I find unified diffs easier to read. From a FreeBSD
> viewpoint I don't see a need to switch from -p0 to -p1.
> 
> Then again I have no strong feelings one way or the other.
> 
> Emanuel



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Is there an Open Issues list for openwrt-18.06.0-rc1

[Craig Miller]

Sorry if this has been answered else where. Is there a "known issues 
list" or tracker for issues for 18.06-rc1?


Thought I'd try |openwrt-18.06.0-rc1 |on my Netgear R6100 today.|

|Noted that the 5Ghz wireless radio wasn't even detected (after reseting 
to defaults). Nothing in the /etc/config/wireless about it.||Under 
17.01.4, it lists the radio as Qualcomm Atheros QCA9880 802.11nac (and 
the radio works normally).


 thanks,

Craig...|

|

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211: pass hostapd control socket to mesh-mode supplicant

[Daniel Hernandez]

So some quick feedback on the snapshot from yesterday . It seems to work  I 
uninstall wpad-mini and in the new version I installed. wpad-mesh-openssl



I noticed this Stack Dump via Serial port however its brief and seems to still 
work.



[cid:image001.png@01D3FCCB.CECB58B0]



-Original Message-
From: Sven Eckelmann [mailto:sven.eckelm...@openmesh.com]
Sent: Monday, June 4, 2018 8:19 AM
To: Daniel Hernandez 
Cc: openwrt-devel@lists.openwrt.org; Daniel Golle ; 
lede-...@lists.infradead.org
Subject: Re: [OpenWrt-Devel] [PATCH] mac80211: pass hostapd control socket to 
mesh-mode supplicant



On Montag, 4. Juni 2018 13:17:10 CEST Daniel Hernandez wrote:

> Hello

>

> Any clue if these fixes are going to make it into Openwrt / LEDE  18.06 . So 
> I can begin testing.



They are part of openwrt-18.06-snapshot.



Kind regards,

Sven
___
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

[Eneas Ulir de Queiroz via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
 I will repost the patch with a cover letter explaining all this, and with a 
better commit message.  I made the wrong assumption that the commit id on top 
of the patch would be enough to identify its origin.  I'm still learning, and 
shall do it right next time.

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.

Cheers,
Eneas
Em quarta-feira, 1 de agosto de 2018 06:01:58 BRT, John Crispin 
 escreveu:  
 
 none of the buildservers seem to break without this patch. please repost 
explaining how the build breaks without this patch. also reference the 
place where you copied the patch from
     John
  --- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 1/4] openssl: Upgrade to 1.1.0h

[Eneas Ulir de Queiroz via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
 Sorry about the typos and spacing changes.  This should have never happened.  
Thank you for pointing them out.  I have corrected them in the PR I've opened 
on github.  Since I'm new to the mailing list and don't know what the best way 
to proceed, please advise me.  I have 4 patches all related to the openssl 
upgrade.  John asked me earlier to send the whole bundle, so that people 
wouldn't need to search for them all over the list.  Now I have to change just 
one of them.  Should I repost all 4, or is it OK to do a V3 for just the 
openssl patch?
Since it's only the text I'm changing, I don't feel the need to do it right 
away--I still have plenty of pull requests to send to the packages feed.  I 
will change the PR I've opened in github right away, but I feel like I'm 
polluting the mailing list if I do it just for some typos in the text.  If 
there are nothing else to change, my intent is to repost the patch after I'm 
finished with the packages feed.
By the way, here's the progress with the packages that depend on openssl 
(packages that were added or removed after I posted the patch are not tallied):
 Global Progress
---
Total packages 152    100,00%
Packages that worked right away    109 71,71%
Packages working now   122 80,26%
Packages that still need changes    30 19,74%
    
PR Progress
---
Total packages that needed changes  43    100,00%
PRs created 32 74,42%
Merged PRs  13 30,23%
Open PRs    19 44,19%
PRs to open 11 25,58%

As for the comment about dropping  the engines:  I'm removing the patch that 
dropped the engines, and adding some options to control their installation, not 
ditching the engines.
Cheers,
Eneas

Em domingo, 3 de junho de 2018 14:58:42 BRT, Philip Prindeville 
 escreveu:  
 
 Inline… but generally, please spellcheck yourself.

> On May 30, 2018, at 8:35 PM, Eneas U de Queiroz via openwrt-devel 
>  wrote:
> 
> From: Eneas U de Queiroz 
> Subject: [PATCH v2 1/4] openssl: Upgrade to 1.1.0h
> Date: May 30, 2018 at 8:18:34 PM MDT
> To: openwrt-devel@lists.openwrt.org
> Cc: Eneas U de Queiroz 
> 
> 
> This version brings major changes to the API, so many packages will need
> adjustments or version bumps.
> Separated the individual engines in place of the generic "hardware
> support" option.
> 
> Signed-off-by: Eneas U de Queiroz 
> ---
> package/libs/openssl/Config.in                    |  45 ++---
> package/libs/openssl/Makefile                      |  80 -
> .../patches/100-Configure-afalg-support.patch      |  13 ++
> .../libs/openssl/patches/110-openwrt_targets.patch |  26 +++
> .../openssl/patches/110-optimize-for-size.patch    |  16 --
> ..._segfault.patch => 120-fix_link_segfault.patch} |  16 +-
> package/libs/openssl/patches/130-perl-path.patch  |  64 ---
> .../libs/openssl/patches/140-makefile-dirs.patch  |  11 --
> package/libs/openssl/patches/150-no_engines.patch  |  81 -
> .../openssl/patches/160-disable_doc_tests.patch    |  58 ---
> package/libs/openssl/patches/170-bash_path.patch  |  8 -
> .../patches/190-remove_timestamp_check.patch      |  23 ---
> .../libs/openssl/patches/200-parallel_build.patch  | 184 -
> 13 files changed, 107 insertions(+), 518 deletions(-)
> create mode 100644 
> package/libs/openssl/patches/100-Configure-afalg-support.patch
> create mode 100644 package/libs/openssl/patches/110-openwrt_targets.patch
> delete mode 100644 package/libs/openssl/patches/110-optimize-for-size.patch
> rename package/libs/openssl/patches/{180-fix_link_segfault.patch => 
> 120-fix_link_segfault.patch} (52%)
> delete mode 100644 package/libs/openssl/patches/130-perl-path.patch
> delete mode 100644 package/libs/openssl/patches/140-makefile-dirs.patch
> delete mode 100644 package/libs/openssl/patches/150-no_engines.patch
> delete mode 100644 package/libs/openssl/patches/160-disable_doc_tests.patch
> delete mode 100644 package/libs/openssl/patches/170-bash_path.patch
> delete mode 100644 
> package/libs/openssl/patches/190-remove_timestamp_check.patch
> delete mode 100644 package/libs/openssl/patches/200-parallel_build.patch
> 
> diff --git a/package/libs/openssl/Config.in b/package/libs/openssl/Config.in
> index 96d3ba3e9d..a705aa741c 100644
> --- a/package/libs/openssl/Config.in
> +++ b/package/libs/openssl/Config.in
> @@ -10,11 +10,6 @@ config OPENSSL_WITH_EC2M
>        depends on OPENSSL_WITH_EC
>        prompt "Enable ec2m support"
> 
> -config OPENSSL_WITH_SSL3
> -    bool
> -    default n
> -    prompt "Enable sslv3 support"
> -
> config OPENSSL_WITH_DEPRECATED
>     bool
>    

Re: [OpenWrt-Devel] [PATCH] brcm2708: Add support for CYW43455

[Christo Nedev]

Hello,
In my opinion the name is good. Similar to other packages:
package/firmware/linux-firmware/ <->  package/firmware/firmware-nonfree/ 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git <-> 
https://github.com/RPi-Distro/firmware-nonfree.git
Actually the repository name is firmware-nonfree or my be I'm wrong. In the 
raspberry pi and debian community this name is known I think.
It is possible in future to be added firmwares not from brcmfmac family. So 
brcmfmac-firmware-nonfree not be suitable.
Thanks!

Sent from iPhone!

> On 1 Jun 2018, at 16:27, Christo Nedev  wrote:
> 
> Hello,
> In my opinion the name is good. Similar to other packages:
> package/firmware/linux-firmware/ <->  package/firmware/firmware-nonfree/ 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git 
> <-> https://github.com/RPi-Distro/firmware-nonfree.git
> Actually the repository name is firmware-nonfree or my be I'm wrong. In the 
> raspberry pi and debian community this name is known I think.
> It is possible in future to be added firmwares not from brcmfmac family. So 
> brcmfmac-firmware-nonfree not be suitable.
> Thanks!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Bash patches format

[Bartłomiej Piotrowski]

On 2018-05-30 09:04, Marty E. Plummer wrote:
> Maintainers, I'd really like to hear your thoughts on this matter. If
> the diffs are produced as -p1 unified diffs, then downstreams who do
> convert from -p0 context won't have to, and distros who work around it
> won't either.
> 
> Regards,
> 
> Marty
> 

From the perspective of Arch Linux maintainer, it does not make any
difference whether patches are unified or -p1. Whatever works for Chet.

Bartłomiej

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ustream-ssl: add optional mutual authentication (mTLS)

[Nuno Morais]

For B2B applications, mutual authentication of peers is a requirement.

Add operation to enable / disable peer authentication
adding a new operation to the ustream_ssl_ops struct
using "SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT", 
and "MBEDTLS_SSL_VERIFY_REQUIRED".

Signed-off-by: Nuno Morais 
---
 ustream-internal.h |  1 +
 ustream-mbedtls.c  | 10 ++
 ustream-openssl.c  | 12 
 ustream-ssl.c  |  1 +
 ustream-ssl.h  |  2 ++
 5 files changed, 26 insertions(+)

diff --git a/ustream-internal.h b/ustream-internal.h
index a8c534f..923e9d2 100644
--- a/ustream-internal.h
+++ b/ustream-internal.h
@@ -41,6 +41,7 @@ struct ustream_ssl_ctx *__ustream_ssl_context_new(bool 
server);
 int __ustream_ssl_add_ca_crt_file(struct ustream_ssl_ctx *ctx, const char 
*file);
 int __ustream_ssl_set_crt_file(struct ustream_ssl_ctx *ctx, const char *file);
 int __ustream_ssl_set_key_file(struct ustream_ssl_ctx *ctx, const char *file);
+int __ustream_ssl_set_mutual_auth(struct ustream_ssl_ctx *ctx, int 
mutual_auth);
 void __ustream_ssl_context_free(struct ustream_ssl_ctx *ctx);
 enum ssl_conn_status __ustream_ssl_connect(struct ustream_ssl *us);
 int __ustream_ssl_read(struct ustream_ssl *us, char *buf, int len);
diff --git a/ustream-mbedtls.c b/ustream-mbedtls.c
index 347c600..d859a08 100644
--- a/ustream-mbedtls.c
+++ b/ustream-mbedtls.c
@@ -217,6 +217,16 @@ __hidden int __ustream_ssl_set_key_file(struct 
ustream_ssl_ctx *ctx, const char
return 0;
 }
 
+__hidden int __ustream_ssl_set_mutual_auth(struct ustream_ssl_ctx *ctx, int 
mutual_auth)
+{
+   if(mutual_auth)
+   mbedtls_ssl_conf_authmode(&ctx->conf, 
MBEDTLS_SSL_VERIFY_REQUIRED);
+   else
+   mbedtls_ssl_conf_authmode(&ctx->conf, 
MBEDTLS_SSL_VERIFY_OPTIONAL);
+
+   return 0;
+}
+
 __hidden void __ustream_ssl_context_free(struct ustream_ssl_ctx *ctx)
 {
 #if defined(MBEDTLS_SSL_CACHE_C)
diff --git a/ustream-openssl.c b/ustream-openssl.c
index 7c72ce1..585e526 100644
--- a/ustream-openssl.c
+++ b/ustream-openssl.c
@@ -154,6 +154,18 @@ __hidden int __ustream_ssl_set_key_file(struct 
ustream_ssl_ctx *ctx, const char
return 0;
 }
 
+__hidden int __ustream_ssl_set_mutual_auth(struct ustream_ssl_ctx *ctx, int 
mutual_auth)
+{
+
+   if(mutual_auth)
+   SSL_CTX_set_verify((void *) ctx, SSL_VERIFY_PEER | 
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL);
+   else
+   SSL_CTX_set_verify((void *) ctx, SSL_VERIFY_NONE, NULL);
+
+   return 0;
+
+}
+
 __hidden void __ustream_ssl_context_free(struct ustream_ssl_ctx *ctx)
 {
SSL_CTX_free((void *) ctx);
diff --git a/ustream-ssl.c b/ustream-ssl.c
index dd0faf9..ad80925 100644
--- a/ustream-ssl.c
+++ b/ustream-ssl.c
@@ -208,6 +208,7 @@ const struct ustream_ssl_ops ustream_ssl_ops = {
.context_set_crt_file = __ustream_ssl_set_crt_file,
.context_set_key_file = __ustream_ssl_set_key_file,
.context_add_ca_crt_file = __ustream_ssl_add_ca_crt_file,
+   .context_set_mutual_auth = __ustream_ssl_set_mutual_auth,
.context_free = __ustream_ssl_context_free,
.init = _ustream_ssl_init,
.set_peer_cn = _ustream_ssl_set_peer_cn,
diff --git a/ustream-ssl.h b/ustream-ssl.h
index 7787788..3eb24ae 100644
--- a/ustream-ssl.h
+++ b/ustream-ssl.h
@@ -52,6 +52,7 @@ struct ustream_ssl_ops {
int (*context_set_crt_file)(struct ustream_ssl_ctx *ctx, const char 
*file);
int (*context_set_key_file)(struct ustream_ssl_ctx *ctx, const char 
*file);
int (*context_add_ca_crt_file)(struct ustream_ssl_ctx *ctx, const char 
*file);
+   int (*context_set_mutual_auth)(struct ustream_ssl_ctx *ctx, int 
mutual_auth);
void (*context_free)(struct ustream_ssl_ctx *ctx);
 
int (*init)(struct ustream_ssl *us, struct ustream *conn, struct 
ustream_ssl_ctx *ctx, bool server);
@@ -64,6 +65,7 @@ extern const struct ustream_ssl_ops ustream_ssl_ops;
 #define ustream_ssl_context_set_crt_file   
ustream_ssl_ops.context_set_crt_file
 #define ustream_ssl_context_set_key_file   
ustream_ssl_ops.context_set_key_file
 #define ustream_ssl_context_add_ca_crt_file
ustream_ssl_ops.context_add_ca_crt_file
+#define ustream_ssl_context_set_mutual_auth
ustream_ssl_ops.context_set_mutual_auth
 #define ustream_ssl_context_free   ustream_ssl_ops.context_free
 #define ustream_ssl_init   ustream_ssl_ops.init
 #define ustream_ssl_set_peer_cn
ustream_ssl_ops.set_peer_cn
-- 
2.15.2 (Apple Git-101.1)


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/4 v1] net: dsa: Add bindings for Realtek SMI DSAs

[Andrew Lunn]

> > +Realtek SMI-based Switches
> > +==
> > +
> > +The SMI "Simple Management Interface" is a two-wire protocol using
> 
> At least for some other Realtek chips, the documentation I find says the 
> S stands for Serial. And Wikipedia says SMI is the same thing as MDIO.
> 
> Just want to make sure we don't define GPIOs directly when there should 
> be a layer of abstraction like mdio-gpio.

Hi Rob

There was a bit of discussion about this with the RFC patches. The bit
stream protocol used here is not that used by SMI in MDIO. It is
something proprietary to Realtek. I don't expect we will be re-using
the code with other vendors. The only real reason to abstract this out
is if there happens to be other Realtek switches which uses the same
SMI bitstream, but have completely different registers, meaning a
separate DSA driver would be needed. The SMI code is well structured,
so it should not be too hard to turn it into a library which drivers
can share.

So i personally don't see a problem with this.

   Andrew

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/4 RFCv2] net: phy: realtek: Support RTL8366RB variant

[Andrew Lunn]

On Mon, May 28, 2018 at 07:47:49PM +0200, Linus Walleij wrote:
> The RTL8366RB is an ASIC with five internal PHYs for
> LAN0..LAN3 and WAN. The PHYs are spawn off the main
> device so they can be handled in a distributed manner
> by the Realtek PHY driver. All that is really needed
> is the power save feature enablement and letting the
> PHY driver core pick up the IRQ from the switch chip.
> 
> Cc: Antti Seppälä 
> Cc: Roman Yeryomin 
> Cc: Colin Leitner 
> Cc: Gabor Juhos 
> Cc: Florian Fainelli 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog RFCv1->RFCv2:
> - No real changes.
> ---
>  drivers/net/phy/realtek.c | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index 9f48ecf9c627..21624d1c9d38 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -37,6 +37,9 @@
>  #define RTL8201F_ISR 0x1e
>  #define RTL8201F_IER 0x13
>  
> +#define RTL8366RB_POWER_SAVE 0x21
> +#define RTL8366RB_POWER_SAVE_ON 0x1000
> +
>  MODULE_DESCRIPTION("Realtek PHY driver");
>  MODULE_AUTHOR("Johnson Leung");
>  MODULE_LICENSE("GPL");
> @@ -145,6 +148,22 @@ static int rtl8211f_config_init(struct phy_device 
> *phydev)
>   return phy_modify_paged(phydev, 0xd08, 0x11, RTL8211F_TX_DELAY, val);
>  }
>  
> +static int rtl8366rb_config_init(struct phy_device *phydev)
> +{
> + int ret;
> + u16 reg;
> +
> + ret = genphy_config_init(phydev);
> + if (ret < 0)
> + return ret;
> +
> + reg = phy_read(phydev, RTL8366RB_POWER_SAVE);
> + reg |= RTL8366RB_POWER_SAVE_ON;
> + phy_write(phydev, RTL8366RB_POWER_SAVE, reg);
> +
> + return 0;
> +}
> +
>  static struct phy_driver realtek_drvs[] = {
>   {
>   .phy_id = 0x8201,
> @@ -207,6 +226,18 @@ static struct phy_driver realtek_drvs[] = {
>   .resume = genphy_resume,
>   .read_page  = rtl821x_read_page,
>   .write_page = rtl821x_write_page,
> + }, {
> + /* The main part of this DSA is in drivers/net/dsa */

Hi Linus

I would not bother with this comment. We don't say, The main part of
this driver is in drivers/net/ethernet/... PHY drivers should be
completely separate to MAC drivers.

Otherwise this looks good.

Andrew



> + .phy_id = 0x001cc961,
> + .name   = "RTL8366RB Gigabit Ethernet",
> + .phy_id_mask= 0x001f,
> + .features   = PHY_GBIT_FEATURES,
> + .flags  = PHY_HAS_INTERRUPT,
> + .config_aneg= &genphy_config_aneg,
> + .config_init= &rtl8366rb_config_init,
> + .read_status= &genphy_read_status,
> + .suspend= genphy_suspend,
> + .resume = genphy_resume,
>   },
>  };
>  
> @@ -218,6 +249,7 @@ static struct mdio_device_id __maybe_unused realtek_tbl[] 
> = {
>   { 0x001cc914, 0x001f },
>   { 0x001cc915, 0x001f },
>   { 0x001cc916, 0x001f },
> + { 0x001cc961, 0x001f },
>   { }
>  };
>  
> -- 
> 2.17.0
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [1/4, RFCv2] net: phy: realtek: Support RTL8366RB variant

[Andrew Lunn]

On Tue, May 29, 2018 at 10:01:14PM +0200, Linus Walleij wrote:
> On Tue, May 29, 2018 at 8:51 PM, Heiner Kallweit  wrote:
> 
> >> +#define RTL8366RB_POWER_SAVE 0x21
> 
> > Typically PHY register addresses are 5 bits wide, is 0x21 correct
> > and I miss something?

Heiner is correct, MDIO only supports 32 register, when using clause
22. However, your device is not clause 22, it is its own thing. So one
danger you have is that we put some checks in the generic code testing
for values > 31, and return -EINVAL.

I think you have two choices:

1) A comment explaining what is going on here, how 0x21 is valid in
this context. And check the return value and give out a good warning
which will point somebody in the right direction to notice this 0x21.

2) Move this into the DSA driver, which does not have this
restriction.

Andrew

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] MIPS32 cross-compile problem - unknown symbol

[Andrew LaCroix]

Hello -

I'm new to OpenWRT development and I'm in the process of porting an
application from Ubuntu x86 to OpenWRT.

The target platform is MIPS32 (GL-AR150):

   CONFIG_TARGET_ar71xx_generic_Default=y

I have my package compiling and the desired .ko file is produced, but when
I flash the image and attempt to insmod on the target device, I get the
following error:

   Unknown symbol __sync_val_compare_and_swap_4 (err 0)

This makes sense given the warning I see in the compile log:

WARNING: "__sync_val_compare_and_swap_4" [...] undefined!

I've done a fair bit of googling on this, and I can see that this is a
problem with the atomic builtins as described here:

  https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html

"Not all operations are supported by all target processors. If a particular
operation cannot be implemented on the target processor, a warning will be
generated and a call an external function will be generated. The external
function will carry the same name as the builtin, with an additional suffix
`_n' where n is the size of the data type."

Can anyone suggest a solution?  I have tried adding "-latomic" and "-lgcc"
to my linker flags, but that is not helping (first option doesn't change
anything, latter option fails).

Thank you,

- Andrew
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] add Support For Anonabox

[ɹɐɯɹǝפ ʇsnƃn∀]

This commit adds support for the Anonabox Pro WiFi-router.

SoC:   Qualcomm Atheros QCA9531 (Dragonfly) 650MHz
RAM:   128mb
FLASH: 16mb
WiFi:  QCA9531 b/g/n
USB:   1x USB 2.0

Tested and working:
 - Ethernet (LAN + WAN)
 - WiFi
 - OpenWRT sysupgrade
 - Reset Button
 - 1 x Green LED
-USB Port
This device was part of trunk before the LEDE fork. This is the patch that
worked on that version for reference:
https://raw.githubusercontent.com/anonabox/openwrt/master/anonabox_pro.patch
Which no longer worked after the LEDE/Openwrt merge. The source for this
new version is this:
https://github.com/augustgermar/misc/blob/master/anonabox-proLEDEpatch2.patch
Which I modified to comply with standards for pull requests for trunk.

For the actual pull request as it currently stands please view here:
https://github.com/openwrt/openwrt/pull/1306

I have been working on getting this hardware back into Trunk for almost a
year. Any and all feedback on this is welcome.

This compiles under Centos7 and flashes to the hardware properly with all
functionality working.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] build: Unset CDPATH to avoid problems

[Hauke Mehrtens]

From: Thomas Langer 

In some places the output of commands, which include "cd" are used.
In case of CDPATH the new path is printed, which might not be expected.
Disable the variable to avoid these problem.

When CDPATH was set by the user to some value like "export CDPATH=."
the git checkout done by the build system did not work anymore, the
git cloning aborted with such an error message for example:

Packing checkout...
tar: 
/disk/fs1/tmp2/mehrtens/pon-ugw/ugw-haps/openwrt/tmp/dl/ppa-drv-1.0\n@1534240258:
 Cannot stat: No such file or directory
tar: Date sample file not found
Try 'tar --help' or 'tar --usage' for more information.
.

To avoid this, this patch makes the build system unset CDPATH inside
the build system, so the build system will still work even when the
user set this variable in his local environment.

Signed-off-by: Thomas Langer 
Signed-off-by: Hauke Mehrtens 
---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index e38d44a8..5301883 100644
--- a/Makefile
+++ b/Makefile
@@ -27,6 +27,8 @@ ifneq ($(OPENWRT_BUILD),1)
   export OPENWRT_BUILD
   GREP_OPTIONS=
   export GREP_OPTIONS
+  CDPATH=
+  export CDPATH
   include $(TOPDIR)/include/debug.mk
   include $(TOPDIR)/include/depends.mk
   include $(TOPDIR)/include/toplevel.mk
-- 
2.10.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: add mkrasimage

[Karl Palsson]

David Bauer  wrote:
> The current make-ras.sh image generation script for the ZyXEL
> NBG6617 has portability issues with bash. Because of this,
> factory images are currently not built correctly by the OpenWRT
> buildbots.
> 
> This commit replaces the make-ras.sh by C-written mkrasimage.
> The old script is still kept but can be deleted in the future.

You need to update your commit message, this is no longer the
case.

> 
> The new mkrasimage is also compatible with other ZyXEL devices
> using the ras image-format. This is not tested with a OpenWRT
> build but it correctly builds the header for ZyXEL factory
> images for all devices it is added to.
> 
> Signed-off-by: David Bauer 
> ---
> 
> v2 changes:
>  - Rework image-generation code
>  - Add factory image for NBG6616
>  - Add factory image for NBG6817
> 
>  include/image-commands.mk |  18 +-
>  scripts/make-ras.sh   | 196 ---
>  target/linux/ar71xx/image/generic.mk  |   6 +-
>  target/linux/ipq40xx/image/Makefile   |   2 +-
>  target/linux/ipq806x/image/Makefile   |   6 +-
>  tools/firmware-utils/Makefile |   1 +
>  tools/firmware-utils/src/mkrasimage.c | 474 ++
>  7 files changed, 495 insertions(+), 208 deletions(-)
>  delete mode 100755 scripts/make-ras.sh
>  create mode 100644 tools/firmware-utils/src/mkrasimage.c
> 
> diff --git a/include/image-commands.mk
> b/include/image-commands.mk index 3cc5dc21e1..61ba49de51 100644
> --- a/include/image-commands.mk
> +++ b/include/image-commands.mk
> @@ -49,17 +49,17 @@ define Build/eva-image
>   mv $@.new $@
>  endef
>  
> -define Build/make-ras
> +define Build/zyxel-ras-image
>   let \
>   newsize="$(subst k,* 1024,$(RAS_ROOTFS_SIZE))"; \
> - $(TOPDIR)/scripts/make-ras.sh \
> - --board $(RAS_BOARD) \
> - --version $(RAS_VERSION) \
> - --kernel $(call 
> param_get_default,kernel,$(1),$(IMAGE_KERNEL)) \
> - --rootfs $@ \
> - --rootfssize $$newsize \
> - $@.new
> - @mv $@.new $@
> + $(STAGING_DIR_HOST)/bin/mkrasimage \
> + -b $(RAS_BOARD) \
> + -v $(RAS_VERSION) \
> + -r $@ \
> + -s $$newsize \
> + -o $@.new \
> + $(if $(findstring seperate-kernel,$(word 1,$(1))),-k 
> $(IMAGE_KERNEL)) \
> + && mv $@.new $@
>  endef
>  
>  define Build/mkbuffaloimg
> diff --git a/scripts/make-ras.sh b/scripts/make-ras.sh deleted
> file mode 100755 index ccddaa0016..00
> --- a/scripts/make-ras.sh
> +++ /dev/null
> @@ -1,196 +0,0 @@
> -#!/usr/bin/env bash
> -#
> -# --- ZyXEL header format ---
> -# Original Version by Benjamin Berg 
> -#
> -# The firmware image prefixed with a header (which is written into the MTD 
> device).
> -# The header is one erase block (~64KiB) in size, but the checksum only 
> convers the
> -# first 2KiB. Padding is 0xff. All integers are in big-endian.
> -#
> -# The checksum is always a 16-Bit System V checksum (sum -s) stored in a 
> 32-Bit integer.
> -#
> -#   4 bytes:  checksum of the rootfs image
> -#   4 bytes:  length of the contained rootfs image file (big endian)
> -#  32 bytes:  Firmware Version string (NUL terminated, 0xff padded)
> -#   4 bytes:  checksum over the header partition (big endian - see below)
> -#  32 bytes:  Model (e.g. "NBG6617", NUL termiated, 0xff padded)
> -#   4 bytes:  checksum of the kernel partition
> -#   4 bytes:  length of the contained kernel image file (big endian)
> -#  rest: 0xff padding
> -#
> -# The checksums are calculated by adding up all bytes and if a 16bit
> -# overflow occurs, one is added and the sum is masked to 16 bit:
> -#   csum = csum + databyte; if (csum > 0x) { csum += 1; csum &= 0x };
> -# Should the file have an odd number of bytes then the byte len-0x800 is
> -# used additionally.
> -#
> -# The checksum for the header is calculated over the first 2048 bytes with
> -# the rootfs image checksum as the placeholder during calculation.
> -#
> -# The header is padded with 0xff to the erase block size of the device.
> -#
> -board=""
> -version=""
> -kernel=""
> -rootfs=""
> -outfile=""
> -err=""
> -
> -while [ "$1" ]; do
> - case "$1" in
> - "--board")
> - board="$2"
> - shift
> - shift
> - continue
> - ;;
> - "--version")
> - version="$2"
> - shift
> - shift
> - continue
> - ;;
> - "--kernel")
> - kernel="$2"
> - shift
> - shift
> - continue
> - ;;
> - "--rootfs")
> - rootfs="$2"
> - shift
> - shift
> - continue
> - ;;
> - "--rootfssize")
> - rootfssize="$2"
> - shift
> - 

Re: [OpenWrt-Devel] Including other .json in hotplug.json

[John Crispin]

On 20/08/18 10:43, Daniel F. Dickinson wrote:

Hi all,

For /etc/hotplug.json is it possible to include another .json file
conditionally (that is if /etc/hotplug.json.d/30-nut-usbhid-ups.json
exists, include it)?

Regards,

Daniel



such a feature does not exist,
    John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Including other .json in hotplug.json

[Daniel F. Dickinson]

Hi all,

For /etc/hotplug.json is it possible to include another .json file
conditionally (that is if /etc/hotplug.json.d/30-nut-usbhid-ups.json
exists, include it)?

Regards,

Daniel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel