[OpenWrt-Devel] OpenWrt DD release name v2

[edgar . soldin]

ok, took the freedom to set up another vote, incl. the third option. let's see 
what the numbers say in a few days. 
http://doodle.com/9d262b569bh4r7kv

it'd make sense that everybody retakes the vote to have the truest election 
result.

regards ..ede
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] mbim / Sierra Wireless AirCard 340U

[Bjørn Mork]

David Hutchison  writes:

> Hello John,
>
> One of our customers use the 340U, and the latest firmware revision
> that fixes Windows 8 support.. broke linux support (
> http://mtekk.us/archives/guides/netgear-aircard-340u-linux/ ) We had
> to downgrade the firmware on the 340u itself.

Is this broken on linux with libmbim+ModemManager, or only with umbim?
Or is it just that the new version forces MBIM mode, while the older
allows QMI?  Or is the problem related to the QMI issues discussed here:
http://lists.freedesktop.org/archives/libqmi-devel/2014-August/000883.html

I don't know if that thread ever concluded with something that worked

In any case:  Please provide more details.  Are you using QMI or MBIM?
Which firmware revisions are working? not working?  Are there any
visible differences in USB descriptors or other device configuration
data that could explain the problems.  How does it break?  Errors? Plain
dead?  Connecting OK, but not forwarding traffic?  Other???

I'd prefer that we make Linux work with *any* firmware available to the
general public instead of requiring specific firmware revisions.  If at
all possible.  And if it works with Windows8, then it should be possible
to make it work with Linux as well :-)

I don't have any Aircard 340U, but I recently got an EM7305 which should
be pretty similar (same Qualcomm chipset and Sierra firmware codebase).
So I might be able to reproduce the problem if I know what to look for.
Especially the firmware revisions involved...



Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info

[Daniel Golle]

Hi Martin,

thanks for diggin' in the proprietary dirt and extracting all the
legally possible info for each firmware file.
I also got some VRX200 boards flying around here, most of them in
productive use on VDSL2 lines. However, I might give your updated
driver a try once I'm awake during less critical daytimes.

On lantiq-xdsl-firmware-info:
What about having BITH hashes or even magnet:-links next to the file
names? That would surely increase the sustainability of your work ;)

On updating the driver:
>From what I understood we already got two seperate versions of the
driver, one for Danube/ADSL and one for xRX/VDSL...?

On ISP settings:
Most ISPs use the ITU recommended enumeration of VLANs on PTM/VDSL.
However, some don't, thus having some reference on that would
definitely make things easier for new users. We should list VLANs,
PPP settings and status of IPv6 support (native DS, DS-Lite, 6rd, ...
as well as the length of the prefix the ISP delegates to the users
router). Quite often this is not consistent and we might need a
couple of entries for some ISPs offering quite different services
depending on the region and the date of the initial subscription.

About your questions:
Yes, VDSL(2) only makes sense with PTM.
No, nothing useful on the wiki for now afaik.
Yes, happy to fill the missing info where ever I can.


Once again, thank you for doing this!


Cheers


Daniel

On Tue, Apr 07, 2015 at 12:00:57AM +0200, Martin Blumenstingl wrote:
> Hello,
> 
> I recently purchased a TP-Link TD-W8970 on which I have installed OpenWrt.
> My goal is to use it as my main "DSL router", so it has to connect to
> the internet.
> For the reference: at the moment I'm using a "AVM FritzBox" for this
> purpose, which is connected directly to the phone jack (the web
> interface tells me it's using "B43", which should be Annex B).
> 
> Unfortunately the situation regarding the drivers and the
> (corresponding) firmware files is not as good as it could be.
> 
> There is no list of firmware files (I understand that those cannot be
> distributed) which could serve as a reference.
> Thus I decided to read the driver's source code and build a list of
> firmware files that I have stumbled across: [0]
> Feel free to send me the details how to get more versions into this
> list (please be aware that I need a link to a public hosted file that
> *everyone* can download).
> Reading all this information from binary files is not what I wanted,
> so I wrote a small script that does the job: [1]
> 
> While I was at it I researched if there was a newer driver version
> that the one we currently have in OpenWrt (v4.11.4).
> There was an update to v4.11.11 like 9 months ago, which was reverted
> because it was not working for everyone.
> Since I was not sure if the old driver could handle newer DSL
> firmwares I searched if I could find anything newer than v4.11.11 -
> and I found v4.15.2 in BT Home Hub 5A's sources (unfortunately with
> all build files stripped off).
> I published the updated drivers (with build files hacked back in) /
> userspace utility on github: [2], [3], [4], [5]
> 
> Noteworthy changes:
> - Danube support was stripped (ARX100 is now the first supported platform)
> - Vectoring support (might still require other kernel patches)
> 
> The patch to get the new drivers into OpenWrt can be found here: [6]
> (Please note that you need to create the tarballs yourself and put
> them in the dl/ directory).
> This updated driver works "as good" as the old one: I get to status
> 0x300 (HANDSHAKE) but not further (but that is probably "my own
> problem").
> 
> In the end I also have a question:
> Is there any list of recommended DSL settings per ISP?
> For example it seems that for VDSL you have to use PTM, with the
> correct Annex B firmware, etc. - but can that information be found on
> the wiki?
> If not then I'll look into creating a page in the next few days (which
> YOU, valued reader, need to fill with info :-)).
> 
> Please let me know if anyone is experimenting with my updated DSL driver.
> Also I'd like to hear if the firmware page is helpful and/or if you
> have firmware versions that work for you (which should obviously
> listed there as well).
> 
> 
> Regards,
> Martin
> 
> 
> 
> [0] https://xdarklight.github.io/lantiq-xdsl-firmware-info/
> [1] https://github.com/xdarklight/lantiq-xdsl-firmware-info
> [2] https://github.com/xdarklight/drv_mei_cpe
> [3] https://github.com/xdarklight/drv_dsl_cpe_api_vrx
> [4] https://github.com/xdarklight/lib_ifxos
> [5] https://github.com/xdarklight/dsl_cpe_control_vrx
> [6] https://gist.github.com/xdarklight/58fe9807594d5366e068/download
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] mbim / Sierra Wireless AirCard 340U

[John Crispin]

On 07/04/2015 12:31, Bjørn Mork wrote:
> David Hutchison  writes:
> 
>> Hello John,
>> 
>> One of our customers use the 340U, and the latest firmware
>> revision that fixes Windows 8 support.. broke linux support ( 
>> http://mtekk.us/archives/guides/netgear-aircard-340u-linux/ ) We
>> had to downgrade the firmware on the 340u itself.
> 
> Is this broken on linux with libmbim+ModemManager, or only with
> umbim? Or is it just that the new version forces MBIM mode, while
> the older allows QMI?  Or is the problem related to the QMI issues
> discussed here: 
> http://lists.freedesktop.org/archives/libqmi-devel/2014-August/000883.html
>
> 
the bug report comes from umbim it is a segfault that happens, not nice.

i found some unlocker cards on ebay.com for around 50$ + postage.
might bite the bullet and grab one.

John

> I don't know if that thread ever concluded with something that
> worked
> 
> In any case:  Please provide more details.  Are you using QMI or
> MBIM? Which firmware revisions are working? not working?  Are there
> any visible differences in USB descriptors or other device
> configuration data that could explain the problems.  How does it
> break?  Errors? Plain dead?  Connecting OK, but not forwarding
> traffic?  Other???
> 
> I'd prefer that we make Linux work with *any* firmware available to
> the general public instead of requiring specific firmware
> revisions.  If at all possible.  And if it works with Windows8,
> then it should be possible to make it work with Linux as well :-)
> 
> I don't have any Aircard 340U, but I recently got an EM7305 which
> should be pretty similar (same Qualcomm chipset and Sierra firmware
> codebase). So I might be able to reproduce the problem if I know
> what to look for. Especially the firmware revisions involved...
> 
> 
> 
> Bjørn ___ openwrt-devel
> mailing list openwrt-devel@lists.openwrt.org 
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] mbim / Sierra Wireless AirCard 340U

[Bjørn Mork]

John Crispin  writes:

> On 07/04/2015 12:31, Bjørn Mork wrote:
>> David Hutchison  writes:
>> 
>>> Hello John,
>>> 
>>> One of our customers use the 340U, and the latest firmware
>>> revision that fixes Windows 8 support.. broke linux support ( 
>>> http://mtekk.us/archives/guides/netgear-aircard-340u-linux/ ) We
>>> had to downgrade the firmware on the 340u itself.
>> 
>> Is this broken on linux with libmbim+ModemManager, or only with
>> umbim? Or is it just that the new version forces MBIM mode, while
>> the older allows QMI?  Or is the problem related to the QMI issues
>> discussed here: 
>> http://lists.freedesktop.org/archives/libqmi-devel/2014-August/000883.html
>>
>> 
> the bug report comes from umbim it is a segfault that happens, not nice.

Ah, see that now. But I don't think that segfault should prevent things
from working?  The "Subscriber Ready" command is not critical/mandatory
(unless you make it so in your scripts).

Looking briefly at umbim, I believe this might fix the segfault
(completely untested):

bjorn@nemi:/usr/local/src/git/umbim$ git diff
diff --git a/cli.c b/cli.c
index e6b34d7..6f496e1 100644
--- a/cli.c
+++ b/cli.c
@@ -152,7 +152,7 @@ mbim_subscriber_response(void *buffer, int len)
if (le32toh(state->readyinfo) & MBIM_READY_INFO_FLAG_PROTECT_UNIQUE_ID)
printf("  dont display subscriberID: 1\n");
for (nr = 0; nr < le32toh(state->telephonenumberscount); nr++) {
-   struct mbim_string *str = buffer + 
le32toh(state->telephonenumbers) + (nr * sizeof(struct mbim_string));
+   struct mbim_string *str = state->telephonenumbers + (nr * 
sizeof(struct mbim_string));
char *number = mbim_get_string(str, buffer);
printf("  number: %s\n", number);
}



Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] mbim / Sierra Wireless AirCard 340U

[Bjørn Mork]

John Crispin  writes:
> On 07/04/2015 12:31, Bjørn Mork wrote:
>> David Hutchison  writes:
>> 
>>> Hello John,
>>> 
>>> One of our customers use the 340U, and the latest firmware
>>> revision that fixes Windows 8 support.. broke linux support ( 
>>> http://mtekk.us/archives/guides/netgear-aircard-340u-linux/ ) We
>>> had to downgrade the firmware on the 340u itself.
>> 
>> Is this broken on linux with libmbim+ModemManager, or only with
>> umbim? Or is it just that the new version forces MBIM mode, while
>> the older allows QMI?  Or is the problem related to the QMI issues
>> discussed here: 
>> http://lists.freedesktop.org/archives/libqmi-devel/2014-August/000883.html
>>
>> 
> the bug report comes from umbim it is a segfault that happens, not nice.

Looking further into what seems to be the real problem there: The
attach + connect failing with "message not long enough" errors.

The error message is a side effect of the fixed buffer size approach
taken by umbim.  It assumes that a response to attach/connect always
will have a MBIM_PACKET_SERVICE_INFO data buffer.  But that depends on
the status code, as described in "10.5.10.8 STATUS CODES".

In this case, the connect message fails with:

MBIM_MESSAGE_HEADER
  MessageType:  0x8003 (MBIM_COMMAND_DONE)
  MessageLength:48
  TransactionId:2
MBIM_FRAGMENT_HEADER
  TotalFragments:   0x0001
  CurrentFragment:  0x
BASIC_CONNECT (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
MBIM_CID_CONNECT (12)
MBIM_STATUS_NOT_INITIALIZED (14)
InformationBuffer [0]:


which I assume happens because MBIM session was closed after
initialisation.  It could also be that we are missing some command
necessary to bring the modem up.




Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/3] fix subscriber response segfault

[Bjørn Mork]

Signed-off-by: Bjørn Mork 
---
 cli.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cli.c b/cli.c
index e6b34d7..cb107b7 100644
--- a/cli.c
+++ b/cli.c
@@ -152,7 +152,7 @@ mbim_subscriber_response(void *buffer, int len)
if (le32toh(state->readyinfo) & MBIM_READY_INFO_FLAG_PROTECT_UNIQUE_ID)
printf("  dont display subscriberID: 1\n");
for (nr = 0; nr < le32toh(state->telephonenumberscount); nr++) {
-   struct mbim_string *str = buffer + 
le32toh(state->telephonenumbers) + (nr * sizeof(struct mbim_string));
+   struct mbim_string *str = (void *)&state->telephonenumbers + 
(nr * sizeof(struct mbim_string));
char *number = mbim_get_string(str, buffer);
printf("  number: %s\n", number);
}
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] add command done status to verbose output

[Bjørn Mork]

Signed-off-by: Bjørn Mork 
---
 mbim-dev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mbim-dev.c b/mbim-dev.c
index 4c129b0..f4b26eb 100644
--- a/mbim-dev.c
+++ b/mbim-dev.c
@@ -76,7 +76,7 @@ mbim_recv(struct uloop_fd *u, unsigned int events)
 {
ssize_t cnt = read(u->fd, mbim_buffer, MBIM_BUFFER_SIZE);
struct mbim_message_header *hdr = (struct mbim_message_header *) 
mbim_buffer;
-   struct command_message *msg = (struct command_message *) mbim_buffer;
+   struct command_done_message *msg = (struct command_done_message *) 
mbim_buffer;
int i;
 
if (cnt < 0)
@@ -105,6 +105,8 @@ mbim_recv(struct uloop_fd *u, unsigned int events)
mbim_send_close_msg();
break;
case MBIM_MESSAGE_TYPE_COMMAND_DONE:
+   if (verbose)
+   printf("  status_code: %04X\n", 
le32toh(msg->status_code));
return_code = current_handler->response(msg->buffer, 
le32toh(msg->buffer_length));
if (return_code < 0)
no_close = 0;
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 0/3] umbim fixes (was: Re: mbim / Sierra Wireless AirCard 340U)

[Bjørn Mork]

That was a bit too quick of course.  Here's a small set of patches which
should fix both errors and help debugging similar issues.

Bjørn Mork (3):
  fix subscriber response segfault
  add command done status to verbose output
  avoid parsing InformationBuffer unless status is "success"

 cli.c  | 2 +-
 mbim-dev.c | 9 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)

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

[OpenWrt-Devel] [PATCH 3/3] avoid parsing InformationBuffer unless status is "success"

[Bjørn Mork]

The MBIM specification requires that the InformationBuffer
is empty unless the status field is MBIM_STATUS_SUCCESS,
except for 4 explicit combinations of status code and
command id.

Avoid calling the reply handler if the status code is
non-zero and the information buffer is empty.

Signed-off-by: Bjørn Mork 
---
 mbim-dev.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mbim-dev.c b/mbim-dev.c
index f4b26eb..c795666 100644
--- a/mbim-dev.c
+++ b/mbim-dev.c
@@ -107,7 +107,10 @@ mbim_recv(struct uloop_fd *u, unsigned int events)
case MBIM_MESSAGE_TYPE_COMMAND_DONE:
if (verbose)
printf("  status_code: %04X\n", 
le32toh(msg->status_code));
-   return_code = current_handler->response(msg->buffer, 
le32toh(msg->buffer_length));
+   if (msg->status_code && !msg->buffer_length)
+   return_code = -le32toh(msg->status_code);
+   else
+   return_code = current_handler->response(msg->buffer, 
le32toh(msg->buffer_length));
if (return_code < 0)
no_close = 0;
mbim_send_close_msg();
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Help required for LED toggling for SATA host controller

[Deepanjan Kar]

Dear All,

I have introduced a new file in the linux-3.10.49/drivers/leds directory for 
SATA LED toggling.
I however find that the callback registered for LED activity is not getting 
called.
Underneath is the snippet of code and the function in RED is the one that I am 
talking about.
I do see the print in the function satadev_trig_init onces the 
ledtrig-satadev.ko function is inmod.

static struct led_trigger satadev_led_trigger = {
.name   = "satadev-led",
.activate   = satadev_trig_activate,
.deactivate = satadev_trig_deactivate,
};

static int __init satadev_trig_init(void)
{
printk("SATA_LED %s\n", __func__);
return led_trigger_register(&satadev_led_trigger);
}

I have also made the following changes in the following files


1.   Makefile
obj-$(CONFIG_LEDS_FUSIV_SATADEV)   += ledtrig-satadev.o

2.   Kconfig

config LEDS_FUSIV_SATADEV

tristate "LED Support for FUSIV platforms"

help

  This file enables lED toggling for SATA on Fusiv platforms

3.   openwrt/package/kernel/linux/modules/leds.mk

define KernelPackage/ledtrig-satadev

  SUBMENU:=$(LEDS_MENU)

  TITLE:=Catshark SATA LED

  KCONFIG:=CONFIG_LEDS_FUSIV_SATADEV

  FILES:=$(LINUX_DIR)/drivers/leds/ledtrig-satadev.ko

  DEPENDS:=+kmod-ata-ahci

  AUTOLOAD:=$(call AutoLoad,81,satadev-led,0)

endef



define KernelPackage/KernelPackage/ledtrig-satadev/description

Support for Catshark SATA LED

endef



$(eval $(call KernelPackage,ledtrig-satadev))

4.   .config

The following LED macros are enabled in the config file

CONFIG_LEDS_GPIO_REGISTER=y

CONFIG_NEW_LEDS=y

CONFIG_LEDS_CLASS=y

#

# LED drivers

#

CONFIG_LEDS_GPIO=y

#

# LED Triggers

#

CONFIG_LEDS_TRIGGERS=y

Please let me know what else I need to do(/what I am missing) for the callback 
function satadev_trig_activate to get called.

Regards,
Deepanjan

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

Re: [OpenWrt-Devel] [PATCH 0/3] umbim fixes

[John Crispin]

On 07/04/2015 15:22, Bjørn Mork wrote:
> That was a bit too quick of course.  Here's a small set of patches which
> should fix both errors and help debugging similar issues.
> 
> Bjørn Mork (3):
>   fix subscriber response segfault
>   add command done status to verbose output
>   avoid parsing InformationBuffer unless status is "success"
> 
>  cli.c  | 2 +-
>  mbim-dev.c | 9 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 

ui, charming ... i had not even had time yet to look into this ;) i'll
continue fiddling with the CC-rc1 builder and then merge the patches
later today.

thanks a lot !
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Help required for LED toggling for SATA host controller

[John Crispin]

On 07/04/2015 15:50, Deepanjan Kar wrote:
> Dear All,
> 
>  
> 
> I have introduced a new file in the linux-3.10.49/drivers/leds directory
> for SATA LED toggling.
> 
> I however find that the callback registered for LED activity is not
> getting called.
> 
> Underneath is the snippet of code and the function in RED is the one
> that I am talking about.
> 
> I do see the print in the function satadev_trig_init onces the
> ledtrig-satadev.ko function is inmod.
> 
>  
> 
> static struct led_trigger satadev_led_trigger = {
> 
> .name   = "satadev-led",
> 
> .activate   = satadev_trig_activate,
> 
> .deactivate = satadev_trig_deactivate,
> 
> };
> 
>  
> 
> static int __init satadev_trig_init(void)
> 
> {
> 
> printk("SATA_LED %s\n", __func__);
> 
> return led_trigger_register(&satadev_led_trigger);
> 
> }
> 
>  
> 
> I have also made the following changes in the following files
> 
>  
> 
> 1.   Makefile
> 
> obj-$(CONFIG_LEDS_FUSIV_SATADEV)   += ledtrig-satadev.o
> 
> 2.   Kconfig
> 
> config LEDS_FUSIV_SATADEV
> 
> tristate "LED Support for FUSIV platforms"
> 
> help
> 
>   This file enables lED toggling for SATA on Fusiv platforms
> 
> 3.   openwrt/package/kernel/linux/modules/leds.mk
> 
> define KernelPackage/ledtrig-satadev
> 
>   SUBMENU:=$(LEDS_MENU)
> 
>   TITLE:=Catshark SATA LED
> 
>   KCONFIG:=CONFIG_LEDS_FUSIV_SATADEV
> 
>   FILES:=$(LINUX_DIR)/drivers/leds/ledtrig-satadev.ko
> 
>   DEPENDS:=+kmod-ata-ahci
> 
>   AUTOLOAD:=$(call AutoLoad,81,satadev-led,0)
> 
> endef
> 
>  
> 
> define KernelPackage/KernelPackage/ledtrig-satadev/description
> 
> Support for Catshark SATA LED
> 
> endef
> 
>  
> 
> $(eval $(call KernelPackage,ledtrig-satadev))
> 
> 4.   .config
> 
> The following LED macros are enabled in the config file
> 
> CONFIG_LEDS_GPIO_REGISTER=y
> 
> CONFIG_NEW_LEDS=y
> 
> CONFIG_LEDS_CLASS=y
> 
> #
> 
> # LED drivers
> 
> #
> 
> CONFIG_LEDS_GPIO=y
> 
> #
> 
> # LED Triggers
> 
> #
> 
> CONFIG_LEDS_TRIGGERS=y
> 
>  
> 
> Please let me know what else I need to do(/what I am missing) for the
> callback function satadev_trig_activate to get called.
> 
>  
> 
> Regards,
> 
> Deepanjan
> 
> 
Hi,

you need to define the default trigger either in the devicetree or int
eh code registering the gpio leds or via the /sysfs interface

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

Re: [OpenWrt-Devel] Alfa Hornet-UB no longer supports OpenWrt? (solved)

[Joshua Judson Rosen]

Apparently this was actually just some confusion at Data Alliance--
looks like they may have mistakenly tried to flash some 16/64 boards
with the procedure for the 8/32 boards (which doesn't port cleanly).

I got in touch with someone at Alfa who affirmed that the only change
that they've made was a switch to different--but compatible--DRAM chips
back in 2013. When I got did get the Hornet-UB 8/32 boards, OpenWrt 14.07/BB
turned out to work just fine on them.

So, happy hacking :)

On 2015-03-26 22:48, Joshua Judson Rosen wrote:
> I've been buying batches of Hornet-UB based routers with OpenWrt preinstalled
> from data-alliance.net for a while now; today I got a message from them that
> they were unable to install the OpenWrt image they'd been using on any
> of the Hornet-UB boards in the latest batch they received from Alfa.
> 
> From my initial discussion with them, it sounds like they were able to
> TFTP the image and write it to flash, but it didn't boot as expected
> after the "reset" command was issued in U-Boot. So we're trying to figure
> out what's going wrong right now; did Alfa make some change to the hardware
> in `recent' history ("recent" being a relative term--bearing in mind that
> sometimes it can take years to run through old stock, depending on how
> many old units exist and the rate at which they get sold...)? Something
> like...:
> 
>   - different flash layout?
> 
>   - different components?
> 
>   - something else?
> 
> Anything that would prevent the early Attitude Adjustment (pre-release)
> builds from booting on the newer Hornet-UB boards? And if there has been
> some sort of change, do newer builds of OpenWrt work on these boards?
> 
> I notice that there are actually two "hornet-ub" images for download
> these days--one of which is for "hornet-ub-x2"? What is that?
> There's no mention of it on in the wiki AFAICT, and I'm having
> trouble finding useful pages with that name on it elsewhere
> on the web
> 

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr."
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Enable LEDs on Hornet-UB X2

[Joshua Judson Rosen]

None of the LEDs are enabled by default on the Hornet-UB X2 board
(the 16/64MB version of the Hornet-UB), because it uses a different
board-name ("hornet-ub-x2"); but hornet-ub and hornet-ub-x2 boards
are equivalent WRT their LEDs.


Index: target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
===
--- target/linux/ar71xx/base-files/etc/uci-defaults/01_leds (revision 45030)
+++ target/linux/ar71xx/base-files/etc/uci-defaults/01_leds (working copy)
@@ -164,7 +164,8 @@
ucidef_set_led_wlan "wlan" "WLAN" "hiwifi:blue:wlan-2p4" "phy0tpt"
;;

-hornet-ub)
+hornet-ub | \
+hornet-ub-x2)
ucidef_set_led_netdev "lan" "LAN" "alfa:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "alfa:blue:wan" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "alfa:blue:wlan" "phy0tpt"
Index: target/linux/ar71xx/base-files/etc/diag.sh
===
--- target/linux/ar71xx/base-files/etc/diag.sh  (revision 45030)
+++ target/linux/ar71xx/base-files/etc/diag.sh  (working copy)
@@ -95,7 +95,8 @@
hiwifi-hc6361)
status_led="hiwifi:blue:system"
;;
-   hornet-ub)
+   hornet-ub | \
+   hornet-ub-x2)
status_led="alfa:blue:wps"
;;
ja76pf | \


-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr."
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Ath10k initialization in CC - questions

[Shankar Unni]

We have an openwrt build that we're working with, that has the most recent 
compat-wireless from the trunk (package/kernel/mac80211).

When we load the ath10k driver, it seems to pause for several seconds and write 
out a message about not finding a particular firmware file:

[6.418730] ath10k_pci :01:00.0: pci irq msi interrupts 1 irq_mode 0 
reset_mode 0
[6.548286] ath10k_pci :01:00.0: Direct firmware load failed with error 
-2
[6.555670] ath10k_pci :01:00.0: Falling back to user helper
procd: Could not find firmware /lib/firmware/ath10k/cal-pci-:01:00.0.bin
[   13.546479] ath10k_pci :01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) 
fw 10.2.4.45 api 4 htt 2.1 wmi 5 cal otp max_sta 128
[   13.558583] ath10k_pci :01:00.0: no channel configured; ignoring 
frame(s)!
[   13.566102] ath10k_pci :01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 
testmode 1
[   13.566109] ath10k_pci :01:00.0: no channel configured; ignoring 
frame(s)!

And of course, there is no such file 
(/lib/firmware/ath10k/cal-pci-:01:00.0.bin). Where do we get this file from 
(or how do we create it)? Is this something I should be worried about?  Also, 
what's this direct firmware load message? Is that for the same file (I'm 
expecting so).

Also, the 7 second pause.  But that, I guess, is because the ath10k driver load 
is now synchronous, right? 

Finally, should I worry about the "no channel configured; ignoring frame(s)" 
message? It gets emitted several times at driver load time, but stops after 
that.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Ath10k initialization in CC - questions

[Shankar Unni]

Oh, sorry, forgot to mention that.  It's a custom Intel-based platform (based 
on an Atom Rangeley reference design, with a PCIe Ath10k card from Compex, 
based on a QCA9880).

> On Apr 7, 2015, at 12:13 PM, Irfan Zia  wrote:
> 
> 
> Which platform ?  Is it a TP-Link device ?  We did some recent work on  
> Archer c7v2. &  DB-120(WDR4300)
> 
> -Irfan
> Paxym Inc.
> www.paxym.com 
> 
> 
> On Tue, Apr 7, 2015 at 11:34 AM, Shankar Unni  > wrote:
> We have an openwrt build that we're working with, that has the most recent 
> compat-wireless from the trunk (package/kernel/mac80211).
> 
> When we load the ath10k driver, it seems to pause for several seconds and 
> write out a message about not finding a particular firmware file:
> 
> [6.418730] ath10k_pci :01:00.0: pci irq msi interrupts 1 irq_mode 0 
> reset_mode 0
> [6.548286] ath10k_pci :01:00.0: Direct firmware load failed with 
> error -2
> [6.555670] ath10k_pci :01:00.0: Falling back to user helper
> procd: Could not find firmware /lib/firmware/ath10k/cal-pci-:01:00.0.bin
> [   13.546479] ath10k_pci :01:00.0: qca988x hw2.0 (0x4100016c, 
> 0x043202ff) fw 10.2.4.45 api 4 htt 2.1 wmi 5 cal otp max_sta 128
> [   13.558583] ath10k_pci :01:00.0: no channel configured; ignoring 
> frame(s)!
> [   13.566102] ath10k_pci :01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 
> testmode 1
> [   13.566109] ath10k_pci :01:00.0: no channel configured; ignoring 
> frame(s)!
> 
> And of course, there is no such file 
> (/lib/firmware/ath10k/cal-pci-:01:00.0.bin). Where do we get this file 
> from (or how do we create it)? Is this something I should be worried about?  
> Also, what's this direct firmware load message? Is that for the same file 
> (I'm expecting so).
> 
> Also, the 7 second pause.  But that, I guess, is because the ath10k driver 
> load is now synchronous, right?
> 
> Finally, should I worry about the "no channel configured; ignoring frame(s)" 
> message? It gets emitted several times at driver load time, but stops after 
> that.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org 
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel 
> 
> 

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

Re: [OpenWrt-Devel] Dark Destroyer

[Hartmut Knaack]

That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer "Dark Destroyer".
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dirty Diamond

[Hartmut Knaack]

That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer "Dirty Diamond".
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[Hartmut Knaack]

That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer "Designated Driver".
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dirty Diamond

[Fernando Frediani]

+1

On 07/04/2015 16:47, Hartmut Knaack wrote:

That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer "Dirty Diamond".
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] Designated Driver

[Aaron Z]

+1 for Designated Driver

Aaron Z
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects.
— Robert Heinlein, Time Enough for Love


On Tue, Apr 7, 2015 at 3:47 PM, Hartmut Knaack  wrote:
> That Doodle poll turned out to be spamed/trolled, and everyone could even
> change or delete other votes. Since this was just communicated over this
> mailing list, and subscribers are at least basically verified, why not have a
> good old fashioned poll?
>
> Give your +1 answer on this mail if you prefer "Designated Driver".
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[camden lindsay]

+1

On Tue, Apr 7, 2015 at 12:47 PM, Hartmut Knaack  wrote:

> That Doodle poll turned out to be spamed/trolled, and everyone could even
> change or delete other votes. Since this was just communicated over this
> mailing list, and subscribers are at least basically verified, why not
> have a
> good old fashioned poll?
>
> Give your +1 answer on this mail if you prefer "Designated Driver".
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[Hartmut Knaack]

+1

Hartmut Knaack schrieb am 07.04.2015 um 21:47:
> That Doodle poll turned out to be spamed/trolled, and everyone could even
> change or delete other votes. Since this was just communicated over this
> mailing list, and subscribers are at least basically verified, why not have a
> good old fashioned poll?
> 
> Give your +1 answer on this mail if you prefer "Designated Driver".
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[edgar . soldin]

hmm.. seems like all doodle polls, incl. the original one suffer from this 
weakness. hereby i declare defeat and hope you Hartmut will count the votes 
properly, manually as seems necessary.

+1 for Designated Driver

..ede

PS: i will deactivate the flawed doodle poll now

> On Tue, Apr 7, 2015 at 12:47 PM, Hartmut Knaack  wrote:
> 
>> That Doodle poll turned out to be spamed/trolled, and everyone could even
>> change or delete other votes. Since this was just communicated over this
>> mailing list, and subscribers are at least basically verified, why not
>> have a
>> good old fashioned poll?
>>
>> Give your +1 answer on this mail if you prefer "Designated Driver".
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> 
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dirty Diamond

[Christian Schoenebeck]

+1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[Joseph Marlin]

+1

- Original Message -
From: "edgar soldin" 
To: "OpenWrt Development List" 
Sent: Tuesday, April 7, 2015 4:10:20 PM
Subject: Re: [OpenWrt-Devel] Designated Driver

hmm.. seems like all doodle polls, incl. the original one suffer from this 
weakness. hereby i declare defeat and hope you Hartmut will count the votes 
properly, manually as seems necessary.

+1 for Designated Driver

..ede

PS: i will deactivate the flawed doodle poll now

> On Tue, Apr 7, 2015 at 12:47 PM, Hartmut Knaack  wrote:
> 
>> That Doodle poll turned out to be spamed/trolled, and everyone could even
>> change or delete other votes. Since this was just communicated over this
>> mailing list, and subscribers are at least basically verified, why not
>> have a
>> good old fashioned poll?
>>
>> Give your +1 answer on this mail if you prefer "Designated Driver".
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> 
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[David Lang]

+1

On Tue, 7 Apr 2015, Hartmut Knaack wrote:


Date: Tue, 07 Apr 2015 21:47:35 +0200
From: Hartmut Knaack 
To: edgar.sol...@web.de,
OpenWrt Development List 
Subject: Re: [OpenWrt-Devel] Designated Driver

That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer "Designated Driver".
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


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

Re: [OpenWrt-Devel] Designated Driver

[Bruno Randolf]

+1

On 04/07/2015 08:47 PM, Hartmut Knaack wrote:
> That Doodle poll turned out to be spamed/trolled, and everyone could even
> change or delete other votes. Since this was just communicated over this
> mailing list, and subscribers are at least basically verified, why not have a
> good old fashioned poll?
> 
> Give your +1 answer on this mail if you prefer "Designated Driver".
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dirty Diamond

[Daniel Golle]

+1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Designated Driver

[Daniel Petre]

+1

On 08/04/15 00:09, Bruno Randolf wrote:

+1

On 04/07/2015 08:47 PM, Hartmut Knaack wrote:

That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer "Designated Driver".
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


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


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

Re: [OpenWrt-Devel] Dirty Diamond

[Marc Nicholas]

+1

-- 
Marc Nicholas
CTO, Wimoto Technologies Inc.
Unit 2, 300 Don Park Road, Markham, Ontario L3R 3A1 CANADA
+1.416.414.6272

On April 7, 2015 at 5:11:55 PM, Daniel Golle (dan...@makrotopia.org) wrote:

+1  
___  
openwrt-devel mailing list  
openwrt-devel@lists.openwrt.org  
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel  
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[Luiz Angelo Daros de Luca]

+1

Em ter, 7 de abr de 2015 às 18:15, Daniel Petre 
escreveu:

> +1
>
> On 08/04/15 00:09, Bruno Randolf wrote:
> > +1
> >
> > On 04/07/2015 08:47 PM, Hartmut Knaack wrote:
> >> That Doodle poll turned out to be spamed/trolled, and everyone could
> even
> >> change or delete other votes. Since this was just communicated over this
> >> mailing list, and subscribers are at least basically verified, why not
> have a
> >> good old fashioned poll?
> >>
> >> Give your +1 answer on this mail if you prefer "Designated Driver".
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >>
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> >
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[thomas.langer]

+1

Hartmut Knaack  hat geschrieben:


That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer "Designated Driver".
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Request to submit patch for new route board.

[Stijn Tintel]

On 04-04-15 14:45, shengkai wrote:
> hi Maintainer and All,
>
> We are an open source hardware team come from china, and we developed
> an open source route board using MT7620A soc. In order to support this
> new board officially, we plan to sumbit the special code for our
> prodcut to openwrt branch.
>
> This is the first time to summbit code, maybe there is some error
> although read the wiki carefully, appreciat your commants. Thanks in
> advance.
>
Please (re-)read https://dev.openwrt.org/wiki/SubmittingPatches,
especially 6 and 10.

Kind regards,
Stijn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dark Destroyer

[Peter Lawler]

On 08/04/15 05:47, Hartmut Knaack wrote:

> Give your +1 answer on this mail if you prefer "Dark Destroyer".
How does that even work? You're not giving an option to vote for
anything else.

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

Re: [OpenWrt-Devel] Dark Destroyer

[David Lang]

On Wed, 8 Apr 2015, Peter Lawler wrote:


On 08/04/15 05:47, Hartmut Knaack wrote:


Give your +1 answer on this mail if you prefer "Dark Destroyer".

How does that even work? You're not giving an option to vote for
anything else.


There are three different subthreads, each looking for answers on that thread
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dark Destroyer

[edgar . soldin]

On 08.04.2015 00:33, Peter Lawler wrote:
> On 08/04/15 05:47, Hartmut Knaack wrote:
> 
>> Give your +1 answer on this mail if you prefer "Dark Destroyer".
> How does that even work? You're not giving an option to vote for
> anything else.
> 

simply write your vote in the subject and have a mail body that says '+1', 
easy. if you are following the list you should know the options by now. 
if you want to introduce a new one, speak up and don't forget to point it out 
to Hartmut, so he doesn't miss it on counting.

i am really wondering if the core devs are following this or even give a damn. 
didn't read anything after John's last mail declaring Dirty Diamond the winner. 
Felix, John, anybody?

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

Re: [OpenWrt-Devel] Dark Destroyer

[edgar . soldin]

On 08.04.2015 00:45, David Lang wrote:
> On Wed, 8 Apr 2015, Peter Lawler wrote:
> 
>> On 08/04/15 05:47, Hartmut Knaack wrote:
>>
>>> Give your +1 answer on this mail if you prefer "Dark Destroyer".
>> How does that even work? You're not giving an option to vote for
>> anything else.
> 
> There are three different subthreads, each looking for answers on that thread

right.. ignore my previous mail wrt. given choices ..ede
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dark Destroyer

[Imre Kaloz]

On Wed, 08 Apr 2015 00:51:11 +0200,  wrote:

i am really wondering if the core devs are following this or even give a  
damn. didn't read anything after John's last mail declaring Dirty  
Diamond the winner. Felix, John, anybody?


Well, given I'm the one to blame for all the older names except for  
Whiterussian, I rather not vote :)



Dark Destroyer sounds like a name a 12ish guy would come up with (not to  
mention how awful Malibu + SoCo sounds). And I don't think we want to  
destroy anything really, we're building here.


Dirty Diamond immediately lines up with the blood diamonds of  
Angola/Congo/etc for me.. Oh, and I actually tasted that recipe.. Well, go  
figure..


Designated Driver fits the best as a name, but it's a mocktail (but at  
least tastes good).


I would (for other obvious reasons) skip DD.



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

Re: [OpenWrt-Devel] Designated Driver

[Owen Kirby]

+1 for "Designated Driver"

On 15-04-07 12:47 PM, Hartmut Knaack wrote:

That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer "Designated Driver".
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] Designated Driver

[Andy Botting]

+1 for Designated Driver

On Wed, Apr 8, 2015 at 5:47 AM, Hartmut Knaack  wrote:

> That Doodle poll turned out to be spamed/trolled, and everyone could even
> change or delete other votes. Since this was just communicated over this
> mailing list, and subscribers are at least basically verified, why not
> have a
> good old fashioned poll?
>
> Give your +1 answer on this mail if you prefer "Designated Driver".
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dark Destroyer

[xxiao8]

+1

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

Re: [OpenWrt-Devel] Dark Destroyer

[xxiao8]

+1

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

[OpenWrt-Devel] Dirty Diamond

[Gerald Matzka]

+1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[Dmitri Bogomolov]

> That Doodle poll turned out to be spamed/trolled, and everyone could even
> change or delete other votes. Since this was just communicated over this
> mailing list, and subscribers are at least basically verified, why not have a
> good old fashioned poll?
>
> Give your +1 answer on this mail if you prefer "Designated Driver".
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
+1 for Designated Driver
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Designated Driver

[Claudio Thomas]

+1

On 07.04.2015 21:47, Hartmut Knaack wrote:
> That Doodle poll turned out to be spamed/trolled, and everyone could even
> change or delete other votes. Since this was just communicated over this
> mailing list, and subscribers are at least basically verified, why not have a
> good old fashioned poll?
>
> Give your +1 answer on this mail if you prefer "Designated Driver".
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] I'd like to donate a Linksys WRT300N V1

[Rafał Miłecki]

On 5 April 2015 at 01:01, Rafał Miłecki  wrote:
> On 30 March 2015 at 23:43, Rafał Miłecki  wrote:
>> On 17 March 2015 at 22:05, Alex Henrie  wrote:
>>> I just mailed the router. When it arrives, please send confirmation to
>>> me and to treasu...@spi-inc.org.
>>
>> I just got it today, thanks!
>>
>> I disassembled it, it's really a PCMCIA wireless card, nice :) Quite
>> an unique device!
>
> Well, it isn't that simple. It's actually CardBus, which is much
> closer to PCI rather than what I meant by PCMCIA.
>
>
>> I'll have to install serial console (requires soldering a header) and
>> doing more tests, so it may take me a bit more of time.
>
> I got serial working, unfortunately I discovered many problems with
> wireless card support.
> 1) ssb believes there isn't cardbus
> 2) ssb can't detect PCI is working in hostmode
> 3) forcing hostmode causes reboots during PCI init
> 4) fixing PCI init causes crash during first MMIO access
>
> That means a lot of problems, pretty hard to track & understand & fix.
> This simply wouldn't be possible to handle this device without having
> a physical access to it. It shares some bugs with WRT350N v1 which
> unresolved for more than 2 years:
> https://dev.openwrt.org/ticket/12682#comment:11
>
> So far I only sent generic support for detecting WRT300N v1.0:
> http://patchwork.linux-mips.org/patch/9656/
> I'll try to get some PCI patches after this long weekend.

WRT300N v1.0 is supported now. I did it even before CC release, hooray :)

For few minutes of testing I got a nice 20-22 Mb/s transfer using b43
driver (it doesn't support 802.11n features, so 802.11g speeds are
available only).

-- 
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] I'd like to donate a Linksys WRT300N V1

[Alex Henrie]

2015-04-08 0:01 GMT-06:00 Rafał Miłecki :
> WRT300N v1.0 is supported now. I did it even before CC release, hooray :)
>
> For few minutes of testing I got a nice 20-22 Mb/s transfer using b43
> driver (it doesn't support 802.11n features, so 802.11g speeds are
> available only).

Wow, that was fast. Thanks!

Make sure to get back to the linux-mips guys though, as they might
have ideas on how to improve this code further.

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