[no subject]

[Sami Olmari 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 ---
This commit 
https://github.com/openwrt/openwrt/commit/064dc1e81bc85f6ef8becc38854292853a59d2c2
breaks all dnssec, it will never get enabled despite /etc/config/dhcp
enabling it. Reverting this commit made dnssec to work again. So this
needs either reverting, or some more elaborate fix.

Additionally I got this message when troubleshooting this at irc:
"While at it, ask please to fix trust-anchor match too (it's not an
option, the option just contains that word at the end)"

Thank you!

-- 
 Sami Olmari
 Oy Olmari Ab
 Vaasa Hacklab ry

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

Re: [OpenWrt-Devel] [PATCH uqmi] nas: add --get-plmn

[Sami Olmari 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 think the ideology behind proto handler there is to "do whatever
told" despite of what the state is currently,
maybe there is a reason for such behaviour (searches some stuff from
network etc).

-- 
 Sami Olmari

On Mon, Aug 26, 2019 at 1:48 PM Martin Schiller  wrote:
>
> Can somebody please take a look at this patch.
>
> It's really necessary to fix the problem in the qmi proto handler.
>
> Thanks,
> Martin
>
> On 2019-07-04 13:35, Martin Schiller wrote:
> > This command is needed in the qmi proto handler to check if the plmn
> > is already set to 'auto'.
> >
> > The reason for this is, that setting the plmn to 'auto' will implicitly
> > lead to a (delayed) network re-registration, which could further lead
> > to some timing related issues in the qmi proto handler.
> >
> > Signed-off-by: Martin Schiller 
> > ---
> >  commands-nas.c | 31 +++
> >  commands-nas.h |  2 ++
> >  2 files changed, 33 insertions(+)
> >
> > diff --git a/commands-nas.c b/commands-nas.c
> > index 5874bfb..1f7445d 100644
> > --- a/commands-nas.c
> > +++ b/commands-nas.c
> > @@ -293,6 +293,37 @@ cmd_nas_get_serving_system_prepare(struct qmi_dev
> > *qmi, struct qmi_request *req,
> >  }
> >
> >  static void
> > +cmd_nas_get_plmn_cb(struct qmi_dev *qmi, struct qmi_request *req,
> > struct qmi_msg *msg)
> > +{
> > + struct qmi_nas_get_system_selection_preference_response res;
> > + static const char *modes[] = {
> > + [QMI_NAS_NETWORK_SELECTION_PREFERENCE_AUTOMATIC] = 
> > "automatic",
> > + [QMI_NAS_NETWORK_SELECTION_PREFERENCE_MANUAL] = "manual",
> > + };
> > + void *c;
> > +
> > + qmi_parse_nas_get_system_selection_preference_response(msg, );
> > +
> > + c = blobmsg_open_table(, NULL);
> > + if (res.set.network_selection_preference) {
> > + blobmsg_add_string(, "mode",
> > modes[res.data.network_selection_preference]);
> > + }
> > + if (res.set.manual_network_selection) {
> > + blobmsg_add_u32(, "mcc",
> > res.data.manual_network_selection.mcc);
> > + blobmsg_add_u32(, "mnc",
> > res.data.manual_network_selection.mnc);
> > + }
> > +
> > + blobmsg_close_table(, c);
> > +}
> > +
> > +static enum qmi_cmd_result
> > +cmd_nas_get_plmn_prepare(struct qmi_dev *qmi, struct qmi_request
> > *req, struct qmi_msg *msg, char *arg)
> > +{
> > + qmi_set_nas_get_system_selection_preference_request(msg);
> > + return QMI_CMD_REQUEST;
> > +}
> > +
> > +static void
> >  cmd_nas_network_scan_cb(struct qmi_dev *qmi, struct qmi_request *req,
> > struct qmi_msg *msg)
> >  {
> >   static struct qmi_nas_network_scan_response res;
> > diff --git a/commands-nas.h b/commands-nas.h
> > index 9ebfa00..4b175f9 100644
> > --- a/commands-nas.h
> > +++ b/commands-nas.h
> > @@ -24,6 +24,7 @@
> >   __uqmi_command(nas_set_network_modes, set-network-modes, required,
> > CMD_TYPE_OPTION), \
> >   __uqmi_command(nas_initiate_network_register, network-register, no,
> > QMI_SERVICE_NAS), \
> >   __uqmi_command(nas_set_plmn, set-plmn, no, QMI_SERVICE_NAS), \
> > + __uqmi_command(nas_get_plmn, get-plmn, no, QMI_SERVICE_NAS), \
> >   __uqmi_command(nas_set_mcc, mcc, required, CMD_TYPE_OPTION), \
> >   __uqmi_command(nas_set_mnc, mnc, required, CMD_TYPE_OPTION), \
> >   __uqmi_command(nas_network_scan, network-scan, no, QMI_SERVICE_NAS),
> > \
> > @@ -44,6 +45,7 @@
> >   "  --set-plmn:   Register at specified
> > network\n" \
> >   "--mcc :Mobile Country Code (0 -
> > auto)\n" \
> >   "--mnc :Mobile Network Code\n" \
> > + "  --get-plmn:   Get preferred network
> > selection info\n" \
> >   "  --get-signal-info:Get signal strength 
> > info\n" \
> >   "  --get-serving-system: Get serving system 
> > info\n" \
>
>
> ___
> 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] [PATCH] ar71xx: add support for GL.iNet GL-X1200

[Sami Olmari 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 Thu, Apr 11, 2019 at 5:31 PM Jeff  wrote:

> Wow, I would have thought a simple
>
> "Thank you for your submission. We appreciate your commercial concerns.
> We look forward to your future submissions on the ath79 platform."
>
> would have been more than enough.
>
> GL.iNet is one of the few OEMs that commercially benefit from OpenWrt
> development that take the time to try to return patches and enhancements
> directly to the project. "Don't waste our time" comes through loud and
> clear. If I were an OEM, why should I bother submitting patches? There
> is real opportunity cost associated with doing so, and not very much
> tangible benefit compared to maintaining their own "private" branch.
>
> That the ath79 target on Linux 4.14 doesn't support NAND makes it
> challenging for a manufacturer to simply switch over their entire code
> development. Yes, patches for ath79 on Linux 4.19 dropped a week or two
> ago. However, a reputable manufacturer isn't going to ship product on an
> untested code line. So far I have seen that batman-adv won't even
> compile under ath79/4.19. Also, while the framework is supposedly
> present for NAND in Linux 4.19, as far as I know no devices have been
> demonstrated to be able to use it under OpenWrt. Not that I expect those
> things to magically happen, but they do make it challenging for a
> responsible OEM to switch over as easily as a hobbyist.
>
>
> Jeff
>

For what it's worth to say from "back here from the side", I don't think
the "waste our time" was meant as bad as it did indeed sounded... The thing
still is that AR71xx target is planned to be obsoleted after very next
OpenWrt stable version, so it doesn't make that much sense figuring out
anything major for that target.

Unfortunately, like Jeff pointed out too, ATH79 isn't 100% working in all
areas, but that can only change with developing...

There is also "clash" of new codebase and MFG releasing mature enough
stuff. That is something that allways will exist. All I can say to that is
that an device MFG builds and does whatever they deem to be best practice
(to them), if it is sticking to codebase that is on phase of being
obsolete, they can do so. It will work for current devices and even new
devices appearing in near-future, but it will not be long-term solution...

Also one should think that having new codebase that is deemed to be
overally better, everyone should focus on developing that instead of burden
of figuring out similar stuff for 2 codebases...

These kind of transitions are never painless...

Best regards,
-- 
 Sami Olmari
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Snort package

[Sami Olmari 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'd say maybe best approach for now would be to have snort3 being own
package on menuconfig instead replacing snort2 (and mutually excluside
relating to eachothers), especially as the they diffirent syntax and there
even isn't a stable release made yet. When snort3 matures enough then some
moves to pahse out snort2 could be made. Many packages has had it this way,
in general python 2 vs 3 is still a thing...

-- 
 Sami Olmari

On Sun, Mar 24, 2019 at 11:09 PM W. Michael Petullo  wrote:

> I have proposed two pull requests which together update the OpenWrt Snort
> package to 3.0.0-beta. I thought I might mention this here, because this
> will affect current Snort users, as the configuration and rule syntax
> has changed since the version-2 series.
>
> The first pull request updates libdaq to 2.2.2. This version appears
> incompatible with the version-2 series of Snort, but it is required
> for 3.0.0-beta. Merging this would render the current Snort package
> unable to build, but it would permit building my proposed Snort 3.0.0-beta
> package.
>
> The second pull request is for Snort itself. I packaged 3.0.0-beta because
> the folks behind Snort have not published a final release schedule,
> and 3.0.0-beta has existed for some time.
>
> I am interested in hearing from any OpenWrt/Snort users about the idea
> of jumping to 3.0.0.
>
> https://github.com/openwrt/packages/pull/8490 (libdaq)
> https://github.com/openwrt/packages/pull/8491 (snort)
>
> --
> Mike
>
> :wq
>
> ___
> 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] Trunk tl wdr4900 v1 boot fails on bootloader CRC check

[Sami Olmari 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 Sun, Mar 10, 2019 at 4:20 PM Alberto Bursi 
wrote:

>
> On 10/03/19 21:32, Sami Olmari via openwrt-devel wrote:
> > Okay it wasn't
> >
> https://github.com/openwrt/openwrt/commit/576c69938bb38c7edfa23f220eb30cb5c1d0a726
> > nor the immediately next one
> >
> https://github.com/openwrt/openwrt/commit/0fbd3d23aadee0d95beef4f077a866dae7f4841a
> > so it's still unclear what commit really breaks this... but I'll try
> > to keep looking.. :)
> >
> > --
> >  Sami Olmari
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
> The issue isn't a specific commit.
>
> The issue is the kernel is too big.
>
> The bootloader of this device only reads 0x29F000 bytes in hex or
>
> 2748416 bytes, around 2.6Mb in decimal.
>
>
> In the Github PR (1) they see they can only work around this by
>
> making an u-boot bootloader that can be loaded instead of the kernel.
>
> Then this u-boot will load the kernel with no limitations.
>
>
> -Alberto
>
>
> [1] https://github.com/openwrt/openwrt/pull/1773
>



Shouldn't this alleviate that?
https://github.com/openwrt/openwrt/commit/576c69938bb38c7edfa23f220eb30cb5c1d0a726

"

Currently, the image creation process for the TP-Link tl-wdr4900-v1
needs a fixed sized kernel and places the rootfs partition at a
fixed offset. With the upcoming move to 4.19 the kernel will no
longer fit into the existing allocated space for the kernel
partition.

This patch converts the device to utilize the established
tplink,firmware mtdsplitter, which can deal with a dynamic
kernel/rootfs size.

"

Not that I really know too good, I'm still just eager user more than
developer... Anyway, All I can then hope a fix is introduced... I am
more than willing to alpha/betatest :)

-- 

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

Re: [OpenWrt-Devel] Trunk tl wdr4900 v1 boot fails on bootloader CRC check

[Sami Olmari 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 ---
Okay it wasn't
https://github.com/openwrt/openwrt/commit/576c69938bb38c7edfa23f220eb30cb5c1d0a726
nor the immediately next one
https://github.com/openwrt/openwrt/commit/0fbd3d23aadee0d95beef4f077a866dae7f4841a
so it's still unclear what commit really breaks this... but I'll try to
keep looking.. :)

-- 
 Sami Olmari

On Sun, Mar 10, 2019 at 2:07 PM Sami Olmari via openwrt-devel <
openwrt-devel@lists.openwrt.org> wrote:

> 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.
>
>
> ------ Forwarded message --
> From: Sami Olmari 
> To: openwrt-devel ,
> paweldembi...@gmail.com, chunk...@gmail.com
> Cc:
> Bcc:
> Date: Sun, 10 Mar 2019 14:06:24 +0200
> Subject: Trunk tl wdr4900 v1 boot fails on bootloader CRC check
> So, current trunk for tp-link WDR4900 v1 fails to boot properly. It fails
> bootloader CRC check.
>
> Serial log:
>
> ## Booting kernel from Legacy Image at 0200 ...
>Image Name:   Linux-4.14.105
>Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>Data Size:2908775 Bytes = 2.8 MiB
>Load Address: 0100
>Entry Point:  01000588
>Verifying Checksum ... Bad Data CRC
> ERROR: can't get kernel image!
>
> This happends on snapshot downloadable from openwrt site as well as latest
> as of now buildroot trunk image. Also no matte do one upload an sysupgrade
> for updating workin openwrt image or throw in factory image with
> serial+tftp recovery, endresult is same.
>
> I'm trying to narrow down at what commit exactly this got broken, but this
> will take some time... My initial suspect would be around commit
> 576c69938bb38c7edfa23f220eb30cb5c1d0a726 but I might be wrong...
>
> Anyway I wanted to report this ASAP as it will brick any WDR4900 v1 out
> there still existing :)
>
> --
>  Sami Olmari
> ___
> 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

[OpenWrt-Devel] Trunk tl wdr4900 v1 boot fails on bootloader CRC check

[Sami Olmari 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 ---
So, current trunk for tp-link WDR4900 v1 fails to boot properly. It fails
bootloader CRC check.

Serial log:

## Booting kernel from Legacy Image at 0200 ...
   Image Name:   Linux-4.14.105
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:2908775 Bytes = 2.8 MiB
   Load Address: 0100
   Entry Point:  01000588
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!

This happends on snapshot downloadable from openwrt site as well as latest
as of now buildroot trunk image. Also no matte do one upload an sysupgrade
for updating workin openwrt image or throw in factory image with
serial+tftp recovery, endresult is same.

I'm trying to narrow down at what commit exactly this got broken, but this
will take some time... My initial suspect would be around commit
576c69938bb38c7edfa23f220eb30cb5c1d0a726 but I might be wrong...

Anyway I wanted to report this ASAP as it will brick any WDR4900 v1 out
there still existing :)

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

Re: [OpenWrt-Devel] Random PARTUUID on every rebuild

[Sami Olmari 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 ---
Should it then be that if there isn't existing image done, then generate
random PARTUUID, otherwise use same one(s) that exists (I don't know how to
determine that).

Then again that will not solve build reproducibility either... And I agree
that no PARTUUID should ever be same between 2 diffirent build(system), so
I don't know how to make 100% reproducibility and keep random (enough)
PARTUUID, might be impossible nad just leave it as is...

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

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Sami Olmari]

Just enthusiast users 2 cents..

I'm also in favour of staying/keep using passwordless login as default
behaviour, even for openssh. We can not stop _all_ of the bad things a
user _might_ do... As per default OpenWrt also doesn't allow much
anything from WAN side etc to keep that covered too... More involved
user can still do whatever they wish with their OpenWrt installations
or compiletime or so on...

-- 
 Sami Olmari

On Sat, Feb 17, 2018 at 3:53 PM, Karl Palsson <ka...@tweak.net.au> wrote:
>
> Philip Prindeville <phil...@redfish-solutions.com> wrote:
>>
>>
>> In a perfect world, no one should ever have to build with
>> patches, anything in files/, cherry-picked commits, etc.
>> Everything would be expressed in the .config (or
>> kernel-config).
>
> I think this is probably the root of all the discussion. I agree
> with you that most people shouldn't want patches, but I think
> it's rather silly to say that it should all be via .config.
> Putting things in files/ is vastly easier and more flexible than
> trying to create something for everyone in makefile and kconfig
> syntax!
>
> I'd generally rather see a lot _less_ of things created via an
> ever expanding .config and _more_ local customizations applied as
> local customizations :)
>
> Cheers,
> Karl Palsson
>
>
> ___
> 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] Is there a way I can restore balance to the force?

[Sami Olmari]

Long time lurker here. I personally wish we'd get things rolling again
nicely... I don't know what would be the ultimate doctorine for this, but
I'd hate OpenWrt, or whatever the name would be, to die because opinion
diffirences and personal argues etc...

-- 
 Sami Olmari

On Mon, Oct 24, 2016 at 6:01 AM, Daniel Dickinson <
open...@cshore.thecshore.com> wrote:

> Hi OpenWrt Developers,
>
> I've obviously done a lot of damage when I was dealing with the result
> of workplace issues combined with medical issues affecting the mind,
> combined with frustration of being ignored or getting flack for patches
> I tried to submit, without realistic changes that could be made to
> improve them.
>
> What I want to know is there a way I can improve the situation (I've
> become disillusioned with LEDE being a true change in openness etc
> rather than your suggestion of a purely political move on the part of
> certain players who convinced others with good intentions), or if those
> bridges are burned and I should go ahead with the fork I created (but
> never got the point where I was promoting it) before the LEDE fork, out
> of frustration with that status quo, and currently feel like all I did
> was lose six months where I could have been making progress on a way
> forward?
>
> I'd like to think there is something I can do to help bring OpenWrt
> back to viability and vibrance.  Is there?
>
> Regards,
>
> Daniel
> ___
> 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] Leaking packest in routing/firewall

[Sami Olmari]

Well, you are running old and obsolete version of OpenWrt, you should try
at least latest stable CC 15.05.1, or preferably even trunk.

-- 
 Sami Olmari

On Fri, Sep 23, 2016 at 8:39 PM, Farid Farid <farid21...@yahoo.com> wrote:

> Hello OpenWrt Team,
>
>
> I am experiencing an issue possibly firewall/routing layer in Openwrt AA
> running Linux 3.10.xx.
>
> In my unit there is a gateway interface with masq set to 1. There is wifi
> interface operating as AP running DHCP server. If clients connect to this
> device and run some IP traffic I can see once awhile some outgoing packets
> going out from gateway interface with source address of WIFI clients
> instead of the gateway interface address.
>
> It seems to me a bug in firewall layer.  Has anyone experienced this issue?
>
> I am running firewall version 2014-04-14 and  iptables version  1.4.21.-2.
>
>
> Thanks,
> Farid
>
>
> ___
> 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] SSL Cert

[Sami Olmari]

Would Lets encrypt be nice alternative nowadays? I have some experience
with it with Acme-tiny, I like that :) Not that this is really mine to
solve, but .02 I guess...

-- 
 Sami Olmari

On Sun, Jul 24, 2016 at 1:09 AM, Hauke Mehrtens <ha...@hauke-m.de> wrote:

> Hi Kaloz,
>
> could you please change the ssl certificate. With HSTS it is pretty hard
> to circumvent the warning.
>
> Hauke
>
> On 07/22/2016 11:19 PM, Eric Schultz wrote:
> > Just wanted to let folks know that the SSL cert expired on openwrt.org
> > <http://openwrt.org> which makes openwrt.org <http://openwrt.org>
> > inaccessible.
> >
> > Eric
> ___
> 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] Apologies

[Sami Olmari]

It might seem smallest of problems, but whitespace problems really causes
an problems many times... "half of" stuff rely on correct spaces/spacing
and so on, what takes spaces, what takes tabulator (take python for
example), this is one reason why folks are quite anal about it. It's not
because the looks, but because it makes the world of diffirence in
situations, we like it or not... And after all, we all want the code to be
perfect, don't we? Even if it oftentimes means to sound like jackass...

 Sami Olmari

On Sun, Jan 10, 2016 at 2:10 PM, Daniel Dickinson <
open...@daniel.thecshore.com> wrote:

> Hi all, especially John,
>
> Sorry for all the mail about whitespace, it is just very frustrating when
> things that I don't see the value in, and which I've not had to worry about
> before, are the cause for rejection.
>
> I understand that whitespace inconsistencies are a problem for git, I also
> think that's more a problem than a solution, and creates more hardship than
> whatever the supposed benefit is.
>
> I also don't like it when the tools I have not only don't warn me about
> the problem, but do annoying things like change whitespace without me
> asking them to (I hadn't been use it much anyway, but emacs has become the
> bane of my existence, for instance.
>
> It's been quite some time since I worked on open source projects, and the
> FOSS attitude to whitespace hasn't been part of my regime.
>
> In reality I remain unconvinced of value of this particular issue being
> the issue it is, and think that it 'the cause' more than it helps.
>
> The truth is that outside tools like make that do really nasty things with
> whitespace, whitespace shouldn't matter (and really that's a failing of
> make).
>
> The whole term whitespace stems from the fact that it should all amount
> the same thing except under special circumstances.
>
> Regards,
>
> Daniel
> ___
> 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] [PATCH] [PATCH] 6in4: Corrected tunnelbroker tunnel update URL

[Sami Olmari]

Okay you can disregard this, I'll submit another one... Nothing wrong with
patch itself, but I'll also bumb the PKG_RELEASE in Makefile in next patch

 Sami Olmari

On Sat, Dec 26, 2015 at 2:33 AM, Sami Olmari <s...@olmari.fi> wrote:

> Changed the tunnel update URL into format tunnelbrokers example has, that
> made it work again.
> Current method gives "Username/Password Authentication Failed." when I
> tried the wget line manually and logread eventually says also "6in4: update
> failed".
> With corrected URL it works fine: "good 111.222.333.444" or "nochg
> 111.222.333.444" and logread concurs with success, and tunnel actually
> updates.
>
> Tested-by: Vaasa Hacklab <i...@vaasa.hacklab.fi>
> Signed-off-by: Sami Olmari <s...@olmari.fi>
> ---
>  package/network/ipv6/6in4/files/6in4.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/network/ipv6/6in4/files/6in4.sh
> b/package/network/ipv6/6in4/files/6in4.sh
> index 59747a3..05471db 100755
> --- a/package/network/ipv6/6in4/files/6in4.sh
> +++ b/package/network/ipv6/6in4/files/6in4.sh
> @@ -108,7 +108,7 @@ proto_6in4_setup() {
> fi
> }
>
> -   local url="$
> http://ipv4.tunnelbroker.net/nic/update?username=$username=$password=$tunnelid
> "
> +   local url="$http://$username:$
> passw...@ipv4.tunnelbroker.net/nic/update?hostname=$tunnelid"
> local try=0
> local max=3
>
> --
> 1.9.1
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] 6in4: Corrected tunnelbroker tunnel update URL

[Sami Olmari]

Changed the tunnel update URL into format tunnelbrokers
example has, that made it work again. Current method gives "Username/Password
Authentication Failed." when I tried the wget line manually and logread
eventually says also "6in4: update failed". With corrected URL it works fine:
"good 111.222.333.444" or "nochg 111.222.333.444" and logread concurs with
success, and tunnel actually updates.

Tested-by: Vaasa Hacklab <i...@vaasa.hacklab.fi>
Signed-off-by: Sami Olmari <s...@olmari.fi>
---
 package/network/ipv6/6in4/Makefile  | 2 +-
 package/network/ipv6/6in4/files/6in4.sh | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/ipv6/6in4/Makefile 
b/package/network/ipv6/6in4/Makefile
index 9eca57a..b51b12d 100644
--- a/package/network/ipv6/6in4/Makefile
+++ b/package/network/ipv6/6in4/Makefile
@@ -8,7 +8,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=6in4
-PKG_VERSION:=22
+PKG_VERSION:=23
 PKG_RELEASE:=1
 PKG_LICENSE:=GPL-2.0
 
diff --git a/package/network/ipv6/6in4/files/6in4.sh 
b/package/network/ipv6/6in4/files/6in4.sh
index 59747a3..05471db 100755
--- a/package/network/ipv6/6in4/files/6in4.sh
+++ b/package/network/ipv6/6in4/files/6in4.sh
@@ -108,7 +108,7 @@ proto_6in4_setup() {
fi
}
 
-   local 
url="$http://ipv4.tunnelbroker.net/nic/update?username=$username=$password=$tunnelid;
+   local 
url="$http://$username:$passw...@ipv4.tunnelbroker.net/nic/update?hostname=$tunnelid;
local try=0
local max=3
 
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [PATCH] 6in4: Corrected tunnelbroker tunnel update URL

[Sami Olmari]

Changed the tunnel update URL into format tunnelbrokers example has, that made 
it work again.
Current method gives "Username/Password Authentication Failed." when I tried 
the wget line manually and logread eventually says also "6in4: update failed".
With corrected URL it works fine: "good 111.222.333.444" or "nochg 
111.222.333.444" and logread concurs with success, and tunnel actually updates.

Tested-by: Vaasa Hacklab <i...@vaasa.hacklab.fi>
Signed-off-by: Sami Olmari <s...@olmari.fi>
---
 package/network/ipv6/6in4/files/6in4.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/ipv6/6in4/files/6in4.sh 
b/package/network/ipv6/6in4/files/6in4.sh
index 59747a3..05471db 100755
--- a/package/network/ipv6/6in4/files/6in4.sh
+++ b/package/network/ipv6/6in4/files/6in4.sh
@@ -108,7 +108,7 @@ proto_6in4_setup() {
fi
}
 
-   local 
url="$http://ipv4.tunnelbroker.net/nic/update?username=$username=$password=$tunnelid;
+   local 
url="$http://$username:$passw...@ipv4.tunnelbroker.net/nic/update?hostname=$tunnelid;
local try=0
local max=3
 
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files utils/busybox: Make requiring login in console default for easily accessed devices

[Sami Olmari]

-1 to default key...

> at the moment the user *is* used to a key mismatch, because
> every box comes up with 192.168.1.1 and another key.

No need to generate another weak point just because there can be another
similar one...

More general, should a bad guy have physical access to an device, be it
embedded router or full server, the game is mostly lost at that point
already... He can allways take out the hard disk and boot own linux and
read the contents etc...

I could see the point of serial connection asking password in normal boot,
but no point with that in failsafe... for same reasons than above... mr bad
guy can even flash own bootloader to do stuff should he need access to
embedded device contents...

So, to recap, bad guy + physical access = game over, no matter what you try
to do...

 mine .02, Sami Olmari

On Thu, Dec 24, 2015 at 11:33 PM, Bastian Bittorf <bitt...@bluebottle.com>
wrote:

> * Michael Richardson <m...@sandelman.ca> [24.12.2015 22:14]:
> > >> > till the real keys are generated? it can last several minutes
> on some
> > >> > routers and it feels like the box is broken. also: if really
> something
> > >> > goes wrong during key generating we can at least login.
> > >>
> > >> you have a very bizarre understanding of securing a device.
> >
> > > in this stage the box is still without password.
> >
> > okay.  So the impersonator machine lets the user in without a password,
> and
> > the impersonator machine has ALREADY connected to the new machine with no
> > password, and trojan'ed some binaries.
>
> yes, if somebody wants to upload some binaries it's possible.
>
> > > the only issue i can think of is, that one can
> > > read on the wire to which password somebody changes
> > > with 'passwd' - but i'am pretty sure this is not
> > > the case, because each session has it's own privacy.
> >
> > No, since the impersonator (MITM) has involved itself with the session.
> > Effectively, the MITM creates:
> >
> >  ssh mitm 'tee /badguy | ssh target'
> >
> > (but, bidirectionally, and inside the SSH transport layer)
> >
> > A new ICMP port-unreachable code would be nice to have here.
>
> interesting idea, but this is also possible with the current
> approach. the user has to accept a new unknown key and has no
> idea from which box it comes from.
>
> but really, this is really hypothetical - normally you have
> 1 box on your desk and you are connected via wire to it. what
> is your usecase?
>
> bye, bastian
> ___
> 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] [PATCH] comgt-ncm: Add possibility to choose PDP context type

[Sami Olmari]

I suspect too that issue isn't ISP having IPv6 or not, as the error comes
instantly in the line... I'd suspect that this option "allows" for IPv6 to
be used, does it fail if no IPv6 is available (in IPV4V6) or not is issue
for further time... So does diffirent NCM-devices possibly have diffirent
option names or no support at all... Who knows... Talk about NCM being
scattered ;(

Sami Olmari
On Oct 7, 2015 10:08, "Lars Melin" <lars...@gmail.com> wrote:

> On 2015-10-07 04:12, Andreas Fritiofson wrote:
>
> I see the exact same error in the logs and I've verified that E3276
>> doesn't accept IPV6 (or IPV4V6, or ... ) as the second parameter by
>> manually echo -e 'AT+CGDCONT=1,"IPV6","internet.tele2.se
>> <http://internet.tele2.se>",""\r' > /dev/cdc-wdm0. Only "IP" works.
>>
>>
> The PDP type IPV6 is only valid for some Huawei firmwares, most likely
> based on what your mobile operator has asked Huawei to include in the
> dongles made for them.
>
> wbr
> Lars
> ___
> 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] HTTPS with 'letsencrypt.org' on OpenWrt

[Sami Olmari]

I have not, I am waiting eagerly to lets encrypt go fully public. That
being said I have no deep knowledge of inner workings of the tool(s), but I
do hope that some day openwrt would also have package for this, or some
method to achieve this :) Will allpha and beta test for sure should there
ever be baked something for this! Mine .2

 Sami Olmari

On Fri, Sep 25, 2015 at 11:32 AM, Bastian Bittorf <bitt...@bluebottle.com>
wrote:

> has anyone played with let's encrypt and their API?
> http://letsencrypt.readthedocs.org/en/latest/api.html
>
> at the moment they are doing really complicated stuff,
> but maybe it's possible to hack something simply with
> the built JSON-tools and curl?
>
> bye, bastian
> ___
> 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] [PATCH] comgt-ncm: Add possibility to choose PDP context type

[Sami Olmari]

This is not working with Huawei E3276, only "option pdptype 'IP' works,
IPV6 and IPV4V6... I do not have IPv6 offered from ISP currently, should it
matter. At attachment there is clips from the log using each option type,
most important clip here, same for IPV4V6 (aka no option set):

Sun Sep 20 20:32:10 2015 daemon.notice netifd: wan (2935): sending ->
AT+CGDCONT=1,"IPV6","opengate"
Sun Sep 20 20:32:11 2015 daemon.notice netifd: wan (2935): Error running
AT-command
Sun Sep 20 20:32:11 2015 daemon.notice netifd: wan (2935): Failed to
initialize modem

There is also some random other errors seen on log on _working_ connection,
I don't know do they bear any importance, as system works. Anything I could
do to make it work so that it wouldn't at least fail?

 Sami Olmari

P.S. I've updated wiki with this new option information :)

On Tue, Sep 8, 2015 at 7:06 PM, Matti Laakso <malaa...@elisanet.fi> wrote:

> By setting the option pdptype to IP, IPV6 or IPV4V6 the user can
> choose the context type between IPv4, IPv6 and dual stack,
> respectively. The default setting is dual stack, except if option
> ipv6=0 is specified, in which case IPv4 context is the default.
> This allows for an out-of-the-box IPv6 support with modems
> utilizing NCM-like protocols.
>
> While we are at it, also add commands for Sierra DirectIP modems
> (currently untested), which will allow us to drop the separate
> comgt-directip package (once tested and verified working).
>
> Signed-off-by: Matti Laakso <malaa...@elisanet.fi>
> ---
>  package/network/utils/comgt/Makefile   |  2 +-
>  package/network/utils/comgt/files/ncm.json | 26 +
>  package/network/utils/comgt/files/ncm.sh   | 36
> ++
>  3 files changed, 50 insertions(+), 14 deletions(-)
>
> diff --git a/package/network/utils/comgt/Makefile
> b/package/network/utils/comgt/Makefile
> index 18085a6..716bbbf 100644
> --- a/package/network/utils/comgt/Makefile
> +++ b/package/network/utils/comgt/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>
>  PKG_NAME:=comgt
>  PKG_VERSION:=0.32
> -PKG_RELEASE:=25
> +PKG_RELEASE:=26
>
>  PKG_SOURCE:=$(PKG_NAME).$(PKG_VERSION).tgz
>  PKG_SOURCE_URL:=@SF/comgt
> diff --git a/package/network/utils/comgt/files/ncm.json
> b/package/network/utils/comgt/files/ncm.json
> index ea4f984..d1f8699 100644
> --- a/package/network/utils/comgt/files/ncm.json
> +++ b/package/network/utils/comgt/files/ncm.json
> @@ -6,7 +6,8 @@
> "ATQ0",
> "ATV1",
> "ATE1",
> -   "ATS0=0"
> +   "ATS0=0",
> +   "AT+CGDCONT=1,\\\"${pdptype}\\\",\\\"${apn}\\\""
> ],
> "modes": {
> "preferlte":
> "AT^SYSCFGEX=\\\"030201\\\",3fff,2,4,7fff,,",
> @@ -25,7 +26,7 @@
> "AT+CGREG=2",
> "AT+CFUN=5",
> "AT+MODESELECT=3",
> -   "AT+CGDCONT=1,\\\"IP\\\",\\\"${apn}\\\""
> +   "AT+CGDCONT=1,\\\"${pdptype}\\\",\\\"${apn}\\\""
> ],
> "modes": {
> "umts": "AT+CHANGEALLPATH=1"
> @@ -33,10 +34,27 @@
> "connect": "AT+CGATT=1",
> "disconnect": "AT+CGATT=0"
> },
> -   "sony": {
> +   "sierra wireless, incorporated": {
> "initialize": [
> "AT+CFUN=1",
> -   "AT+CGDCONT=1,\\\"IP\\\",\\\"${apn}\\\"",
> +   "AT+CGDCONT=1,\\\"${pdptype}\\\",\\\"${apn}\\\"",
> +
>  
> "AT$QCPDPP=1${auth:+,$auth}${password:+,\\\"$password\\\"}${username:+,\\\"$username\\\"}"
> +   ],
> +   "modes": {
> +   "preferlte": "AT!SELRAT=07",
> +   "preferumts": "AT!SELRAT=05",
> +   "lte": "AT!SELRAT=06",
> +   "umts": "AT!SELRAT=01",
> +   "gsm": "AT!SELRAT=02",
> +   "auto": "AT!SELRAT=00"
> +   },
> +   "

Re: [OpenWrt-Devel] how to build two sub target simultaneously under same target

[Sami Olmari]

This is not an support channel... but I'll answer you best of mine
abilities: you do have thing called "env".. this allows you to use same
sourcecodes for multiple devices and their configurations. More info about
that http://wiki.openwrt.org/doc/devel/env

This allows you to build whatever targets (even multiple times same) with
whatever config each. Nothing does automatically build everything, but you
can make simple script that builds one, changes env, builds another... Best
thing I know to have currently, without modifying anything heavily.

 Sami Olmari

On Fri, Sep 18, 2015 at 7:56 PM, punith kumar <spk.pun...@gmail.com> wrote:

> Dear Openwrt-devel,
>
> I want to know if it is possible to setup build environment to compile
> two sub-target simultaneously which will use same toolchain options,
> build environment and etc.
> Simultaneously both sub-targets should be configurable as a prerequisite
>
> Thanks in advance for any sort of suggestion and direction
>
> Regards,
> Punith Kumar
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT www version banner a security risk

[Sami Olmari]

Mine vote for generally _not do anything_, Defaults are safe as pointed out
here few times... We can not start to babysit users from themselves... We
can guide, we can help and so on, but it's still end user responsibility
when opening port(s) to WAN, or securing access in a big LAN/VPN/VLAN/etc
-enviroment, we can't start pampering them...

 Sami Olmari

On Mon, Sep 14, 2015 at 6:30 PM, Joshua Judson Rosen <jro...@harvestai.com>
wrote:

> On 2015-09-13 10:21, MauritsVB wrote:
> > At the moment the OpenWRT www login screen provides *very* detailed
> version information before anyone has even entered a password. It displays
> not just “15.05” or “Chaos Calmer” but even the exact git version on the
> banner.
> >
> > While it’s not advised to open this login screen to the world, fact is
> that it does happen intentionally or accidentally. Just a Google search for
> “Powered by LuCI Master (git-“ will provide many accessible OpenWRT login
> screens, including exact version information.
> >
> > As soon as someone discovers a vulnerability in a OpenWRT version all an
> attacker needs to do is perform a Google search to find many installations
> with versions that are vulnerable (even if a patch is already available).
> >
> > In the interest of hardening the default OpenWRT install, can I suggest
> that by default OpenWRT doesn’t disclose the version (not even 15.05 or
> “Chaos Calmer”) on the login screen? For extra safety I would even suggest
> to leave “OpenWRT” off the login screen, the only people who should use
> this screen already know it’s running OpenWRT.
> >
> > Any thoughts?
>
> I think you'd also need to change a number of services to stop
> reporting detailed information in their protocol.
>
> For example: have you noticed that the ETag and Last-Modified
> values that uhttpd returns for a given path are identical
> across all installations of a given version of OpenWrt?
> It doesn't really matter if there's an OpenWrt version-number
> in the *content* fetched over HTTP--the client has already
> got that information before they even get the content.
>
> Another example: the version-info exchanged at the start
> of the SSH protocol.
>
> It's like deciding that you want to send an anonymous letter
> and so avoid signing your name on that letter, but still putting
> your name and return address on the outside of the envelope.
>
> --
> "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 mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Removing Telnet

[Sami Olmari]

IMHO no password is best method until a password is set (like it was with
telnet and now with new paswordless SSH). A default password is just false
sense of security, there is none! Otherwise "encouraging" to set one and
how can be discussed...

 Olmari

On Thu, Sep 10, 2015 at 3:14 AM, Ben Franske  wrote:

> I'm copying this to the list because it was sent directly to me... There
> are definitely many ways of "encouraging" people to change the password
> which could be explored, another example is the WAN interface could be
> disabled until the password is set. A few more thoughts on something like
> that or the WiFi disable proposed below though:
>
> -Don't just have a feature like WiFi die without an error message
> indicating the password must be changed, again bad user experience (and
> lots of support requests)
> -Make sure that the error is clear BOTH in LuCI and the CLI and provide
> instructions for changing the password (e.g. just sending an error to the
> console is not sufficient) LuCI already can detect the null password
> condition as it prompts the user with a banner to set a password, this
> could be adapted to check for a default password and the warn the user that
> some features are disabled until the password is changed
>
> -Ben
>
> On 9/9/2015 6:05 PM, Derek & Vicky wrote:
>
>> I agree no password is problematic, so is a default password that never
>> gets changed.  So what if the wifi startup script checks the md5sum of the
>> /etc/shadow file against the sum it created at startup Or predefined
>> value.  This way it won't enable the wifi unless the sum changes.
>>
>> Derek
>>
> ___
> 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] Fwd: Removing Telnet

[Sami Olmari]

Does Dropbeard support ether? I know OpenSSH does, but default installation
does not use that.

Olmari
On Sep 8, 2015 21:01, "Vittorio G (VittGam)"  wrote:

> Il 08.09.2015 18:31 Janusz Dziemidowicz ha scritto:
>
>> SSH time can be greatly reduced by using ECDSA host key. Dropbear can
>> be compiled with ECDSA support, however:
>> - it is disabled by default in OpenWRT
>> - startup script only generates RSA/DSA host keys, ECDSA host key must
>> be generated manually
>>
>> Using 256 bit ECDSA host key reduces SSH login time for me from 0.7s
>> down to 0.13s. Tested on Netgear WNDR3800, ar71xx/generic, I am not
>> sure about other architectures.
>>
>
> Also, I think ed25519 keys and chacha20-poly1305 encryption might be worth
> a try. They should be faster than ECDSA + AES on embedded processors, but
> they need a relatively recent version of the SSH client (read: possible
> problems on Windows and Macs).
> ___
> 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] Separate Default SSID for 2.4GHz and 5GHz

[Sami Olmari]

In openwrt you are free to configure each and every radio as own unit, so
use whatever SSID you see fit for each radio. This is default basic OpenWrt
stuff :)

 Sami Olmati

On Thu, Aug 6, 2015 at 6:59 PM, Afkar Rafique afkar...@gmail.com wrote:

 Hi Everyone,

 I am working on AR93XX openWrt project. I have to configure the wifi0 as
 2.4GHz and 5Ghz as per the selection of user. Mainly I have to add
 selection in the GUI to switch between 2.4GHz and 5GHz. I have to keep two
 separate default SSID for 2.4GHz and 5GHz.

 Could anyone can help me that how I can keep two separate configuration
 and how I can handle this in software.  I mean to say how I can thin into
 GUI and can handle backend.


 Thanks.

 ___
 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] Dynamically generate custom files before building?

[Sami Olmari]

isn't it quite self-explanatory? with ./scripts/env new name here you
generate new profile, where you can then have own configs and own set of
files/ etc. So... 10 devices, 10 profiles, each having own settings and
files... You get the idea.

 Sami Olmari

On Tue, Mar 24, 2015 at 6:44 PM, Nguyễn Hồng Quân ng.hong.q...@gmail.com
wrote:

 Hi

 On Wed, Mar 25, 2015 at 12:33 AM, Sami Olmari s...@olmari.fi wrote:

 Why not use ./scripts/env with your own batchfile? It has all the things
 you need for multiple hardware configurations on single buildroot... only
 thing you need to do is automate it with bash-script etc...

 I tried the script:

 $ ./scripts/env
 Usage: ./scripts/env [options] command [arguments]
 Commands:
 help  This help text
 list  List environments
 clear Delete all environment and revert to flat
 config/files
 new nameCreate a new environment
 switch name Switch to a different environment
 delete name Delete an environment
 rename newname  Rename the current environment
 diff  Show differences between current state and
 environment
 save  Save your changes to the environment
 revertRevert your changes since last save

 Options:


 and I don't understand what it can do :-(

 --
 Quân
 ***
 * Nguyễn Hồng Quân*
 * Y!M: ng_hquan_vn*
 * Facebook: ng.hong.quan  *
 * Web: quan.hoabinh.vn*
 ***

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

Re: [OpenWrt-Devel] Dynamically generate custom files before building?

[Sami Olmari]

Why not use ./scripts/env with your own batchfile? It has all the things
you need for multiple hardware configurations on single buildroot... only
thing you need to do is automate it with bash-script etc...

Sami Olmari
On Mar 24, 2015 6:15 PM, Nguyễn Hồng Quân ng.hong.q...@gmail.com wrote:

 Hi

 What I mean is each target device will have its own default config files.
 I'm thinking about /etc/config/network and /etc/config/wireless.

 I want to dynamically generate the custom files of those network,
 wireless and place in files/ folder. I want to find the default files,
 modify it and copy to files/ folder. The modification will be set SSID, set
 wireless password... Those actions are done by script.

 The problem is I don't know where those default files are.


 On Tue, Mar 24, 2015 at 12:11 PM, Christian Schoenebeck 
 christian.schoeneb...@gmail.com wrote:

 For me a shell script is doing the job. Calling parameter is the target.
 I use a separate configuration directory beside building directory.
 I copy the correct files for the target into the files directory
 and the correct .config into building directory
 and then call make. All inside the script.


 If I cannot know where those default are. I may have to use this approach.

 Thank nam228, when I look into the Makefile, I see it mentions target
 folder. This may be a hint to look for.

 --
 Quân
 ***
 * Nguyễn Hồng Quân*
 * Y!M: ng_hquan_vn*
 * Facebook: ng.hong.quan  *
 * Web: quan.hoabinh.vn*
 ***

 ___
 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] Dynamically generate custom files before building?

[Sami Olmari]

There is tool for that in buildroot... run ./scripts/env or look wiki for
more info. It's for having multiple device profiles in one buildroot.

  Sami Olmari

On Mar 23, 2015 6:11 PM, Nguyễn Hồng Quân ng.hong.q...@gmail.com wrote:

 Hello all

 If I want to build customized OpenWrt, I need to place all custom file
in files/ folder.
 The problem is that a set of custom files can only be applied to 1
device, i.e /etc/config/wireless file for TP Link router can not be used
for D-Link.

 Is there any way that I can use a script to modify the default config
file for each target device, create the one in files/ folder before
building? Where can I find the default /etc/config/wireless target device?

 Thanks

 --
 Quân
 ***
 * Nguyễn Hồng Quân*
 * Y!M: ng_hquan_vn*
 * Facebook: ng.hong.quan  *
 * Web: quan.hoabinh.vn*
 ***

 ___
 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] NCM fails to reconnect

[Sami Olmari]

It seems MCN protocol still has some quirks left... it seems that whenever
MCN connection gets disconnected for whatever reason, it can't be brought
back up... even yanking the dongle out and back in does not do basically
anything... it gets detected etc, but nothing else happends...

following logread it shows literally nothing. Like NCM-script isn't there
doing it's magic anymore... ifup wan... nothing.. etc.. Only full reboot
makes it to work again, until next ocnnection breakup happends...

What should we do?

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

Re: [OpenWrt-Devel] looking for a tl-wdr4900 tester

[Sami Olmari]

I can do basic testing too, if wanted to :)

Sami Olmari
On Feb 12, 2015 1:50 PM, John Crispin blo...@openwrt.org wrote:

 Hi Philipp,

 On 12/02/2015 12:41, Philipp Borgers wrote:
  I can test if you provide me with an image or an *easy* way to
  compile.
 
 i will mail you an initramfs and a flashable image after i had lunch

  Is there any testing procedure I should follow? Do we have some
  kind of tests I don't know of?

 i wish i had. best if you flash the image, see if wifi and ethernet
 work, thats the best we can do right now i guess :-)

 thanks,
 John


 
  Regards Philipp
 
  On Thu, Feb 12, 2015 at 12:31:07PM +0100, John Crispin wrote:
  Hi,
 
  just bumped the kernel for the tl-wdr4900. i don't actually have
  the unit. anyone around that feels like testing the images before
  i push the series to trunk ?
 
  John ___
  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] Wrong Network Configuration File Fails Everything

[Sami Olmari]

Set static IP for your computer, like 192.168.1.10, subnet
255.255.255.0 and try then.

 Sami Olmari

On Tue, Jan 13, 2015 at 5:06 PM, Yilun Zhou yilun.z...@duke.edu wrote:
 Hi,

 I am experimenting with OpenWRT Attitude Adjustment on NETGEAR WNDR3800. I
 accidentally wrote wrong network configuration file and committed it. Now I
 cannot interact with the router anymore. The wifi is still being created but
 there is no Internet. I tried to SSH into the router from device that is
 connected via Ethernet cable or wifi but neither works. Then I did a factory
 reset following https://forum.openwrt.org/viewtopic.php?pid=148789#p148789 .
 I can see the Power LED flashing green rapidly so I should be in FailSafe
 mode. However, I can't telnet into the router. On Windows taskbar (bottom
 right corner of desktop) I can see that the Ethernet connection is working
 in progress (a circle is rotating in front of the icon). Has anyone
 experienced this issue before and how can I solve it?

 Thanks,

 Yilun


 ___
 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 for ar7 test hw / 3.14 testing

[Sami Olmari]

Not to be stupid, but how new device would do? I might have some age old
ZyXEL P660-H hardware lying around our hackerspace for nothing, but old
they are indeed :)

Sami Olmari
On Dec 8, 2014 8:19 AM, John Crispin blo...@openwrt.org wrote:

 Hi,

 i just bumped ar7, it is only compile tested. i tried getting my hands
 on ar7 hw, managed to get 2 boards. one does not power up and the
 other one has a uart connector welded and not soldered to it and fails
 to give stable serial output.

 does anyone have a working ar7 board that they want to send me ?

 also if anyone feels like testing the 3.14 i would appreciate the effort.

 John
 ___
 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] Donating TL-Archer C7 v2 for developer

[Sami Olmari]

Hi

I'd like to donate an TP-Link Archer C7 v2 to keep for willing OpenWrt
developer in exchange for (trying to) make it more bugfree. There is
at least few known bugs, https://dev.openwrt.org/ticket/18362 and
https://dev.openwrt.org/ticket/18363

Then there is also matter of switch config which kinda doesn't make
any sense, nor editing it works as expected (too many ports, no sane
CPU port, can't do VLANs essentially).

Anyone interested?

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

Re: [OpenWrt-Devel] Donating TL-Archer C7 v2 for developer

[Sami Olmari]

Well, I could send one to you, Australia is no issue, How can I be
sure you are even remotely a developer? :P

 Sami Olmari

On Sun, Nov 30, 2014 at 2:29 AM, Outback Dingo outbackdi...@gmail.com wrote:
 Yupp, okay Ill bite... but im in Australia :)

 On Sun, Nov 30, 2014 at 12:11 AM, Sami Olmari s...@olmari.fi wrote:

 Hi

 I'd like to donate an TP-Link Archer C7 v2 to keep for willing OpenWrt
 developer in exchange for (trying to) make it more bugfree. There is
 at least few known bugs, https://dev.openwrt.org/ticket/18362 and
 https://dev.openwrt.org/ticket/18363

 Then there is also matter of switch config which kinda doesn't make
 any sense, nor editing it works as expected (too many ports, no sane
 CPU port, can't do VLANs essentially).

 Anyone interested?

  Sami Olmari
 ___
 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] Donating TL-Archer C7 v2 for developer

[Sami Olmari]

Sent one, let's hope everything goes okay :)

 Sami

On Sun, Nov 30, 2014 at 2:45 AM, Sami Olmari s...@olmari.fi wrote:
 Well, I could send one to you, Australia is no issue, How can I be
 sure you are even remotely a developer? :P

  Sami Olmari

 On Sun, Nov 30, 2014 at 2:29 AM, Outback Dingo outbackdi...@gmail.com wrote:
 Yupp, okay Ill bite... but im in Australia :)

 On Sun, Nov 30, 2014 at 12:11 AM, Sami Olmari s...@olmari.fi wrote:

 Hi

 I'd like to donate an TP-Link Archer C7 v2 to keep for willing OpenWrt
 developer in exchange for (trying to) make it more bugfree. There is
 at least few known bugs, https://dev.openwrt.org/ticket/18362 and
 https://dev.openwrt.org/ticket/18363

 Then there is also matter of switch config which kinda doesn't make
 any sense, nor editing it works as expected (too many ports, no sane
 CPU port, can't do VLANs essentially).

 Anyone interested?

  Sami Olmari
 ___
 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] Donating TL-Archer C7 v2 for developer

[Sami Olmari]

BTW, I'm still open to this if there is another developer interested
in this too :)

 Sami Olmari

On Sun, Nov 30, 2014 at 3:17 AM, Sami Olmari s...@olmari.fi wrote:
 Sent one, let's hope everything goes okay :)

  Sami

 On Sun, Nov 30, 2014 at 2:45 AM, Sami Olmari s...@olmari.fi wrote:
 Well, I could send one to you, Australia is no issue, How can I be
 sure you are even remotely a developer? :P

  Sami Olmari

 On Sun, Nov 30, 2014 at 2:29 AM, Outback Dingo outbackdi...@gmail.com 
 wrote:
 Yupp, okay Ill bite... but im in Australia :)

 On Sun, Nov 30, 2014 at 12:11 AM, Sami Olmari s...@olmari.fi wrote:

 Hi

 I'd like to donate an TP-Link Archer C7 v2 to keep for willing OpenWrt
 developer in exchange for (trying to) make it more bugfree. There is
 at least few known bugs, https://dev.openwrt.org/ticket/18362 and
 https://dev.openwrt.org/ticket/18363

 Then there is also matter of switch config which kinda doesn't make
 any sense, nor editing it works as expected (too many ports, no sane
 CPU port, can't do VLANs essentially).

 Anyone interested?

  Sami Olmari
 ___
 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] Donating TL-Archer C7 v2 for developer

[Sami Olmari]

Hmm... it does clarify it some :)

For defaults, wouldn't it be also better to have the eth 1 / switch
port 0 as tagged as default?

 Sami Olmari

On Sun, Nov 30, 2014 at 3:34 AM, Ben Franske ben.li...@franske.com wrote:
 Sami,
 I'm a very power user of OpenWRT and also a light developer of it. I happen
 to have one of the Archer C7 v2 units myself. I agree there are definitely
 some bugs there but the switch config is not something we can do much about
 I don't think. I agree it's quite different than other devices but that is
 because of the way the hardware is built and not because of OpenWRT. Once
 you actually figure out the switch configuration it's pretty flexible, just
 different than what you would expect. Because it's different than many
 devices the LuCI interface for configuring it is misleading and confusing. I
 find it less confusing to work with it in the /etc/config/network text file
 configuration. When I get some time I hope to do a better job of documenting
 it. You can definitely do VLANs though, in fact two VLANs are part of the
 default OpenWRT config on this device.

 Basically, it is a seven port switch. Each of the five physical Ethernet
 ports (WAN, LAN1, LAN2, LAN3, LAN4) are represented and it has TWO CPU
 ports. A table showing the relationship of the switch ports to the physical
 and CPU ports is on the wiki at
 http://wiki.openwrt.org/toh/tp-link/tl-wdr7500

 The default configuration is to use VLAN1 to carry the LAN traffic
 (connecting eth1 with LAN1, LAN2, LAN3, and LAN4) and VLAN2 to carry the WAN
 traffic (connecting eth0 with WAN). You can add extra VLANs if you so desire
 and change eth1 (switch port 0) to a tagged port. In this way it will
 operate just like any other OpenWRT controlled switch. The key difference is
 that you must always reserve one VLAN for connecting the WAN port (switch
 port 1) to the eth0 port (switch port 6).

 Hope this helps clarify!

 -Ben


 On 11/29/2014 6:11 PM, Sami Olmari wrote:

 Hi

 I'd like to donate an TP-Link Archer C7 v2 to keep for willing OpenWrt
 developer in exchange for (trying to) make it more bugfree. There is
 at least few known bugs, https://dev.openwrt.org/ticket/18362 and
 https://dev.openwrt.org/ticket/18363

 Then there is also matter of switch config which kinda doesn't make
 any sense, nor editing it works as expected (too many ports, no sane
 CPU port, can't do VLANs essentially).

 Anyone interested?

   Sami Olmari
 ___
 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] Fwd: Donating TL-Archer C7 v2 for developer

[Sami Olmari]

I want this in mailinlist too, hopefully forward is okay and correct:

-- Forwarded message --
From: Ben Franske ben.li...@franske.com
Date: Sun, Nov 30, 2014 at 3:34 AM
Subject: Re: [OpenWrt-Devel] Donating TL-Archer C7 v2 for developer
To: Sami Olmari s...@olmari.fi


Sami,
I'm a very power user of OpenWRT and also a light developer of it. I
happen to have one of the Archer C7 v2 units myself. I agree there are
definitely some bugs there but the switch config is not something we
can do much about I don't think. I agree it's quite different than
other devices but that is because of the way the hardware is built and
not because of OpenWRT. Once you actually figure out the switch
configuration it's pretty flexible, just different than what you would
expect. Because it's different than many devices the LuCI interface
for configuring it is misleading and confusing. I find it less
confusing to work with it in the /etc/config/network text file
configuration. When I get some time I hope to do a better job of
documenting it. You can definitely do VLANs though, in fact two VLANs
are part of the default OpenWRT config on this device.

Basically, it is a seven port switch. Each of the five physical
Ethernet ports (WAN, LAN1, LAN2, LAN3, LAN4) are represented and it
has TWO CPU ports. A table showing the relationship of the switch
ports to the physical and CPU ports is on the wiki at
http://wiki.openwrt.org/toh/tp-link/tl-wdr7500

The default configuration is to use VLAN1 to carry the LAN traffic
(connecting eth1 with LAN1, LAN2, LAN3, and LAN4) and VLAN2 to carry
the WAN traffic (connecting eth0 with WAN). You can add extra VLANs if
you so desire and change eth1 (switch port 0) to a tagged port. In
this way it will operate just like any other OpenWRT controlled
switch. The key difference is that you must always reserve one VLAN
for connecting the WAN port (switch port 1) to the eth0 port (switch
port 6).

Hope this helps clarify!

-Ben


On 11/29/2014 6:11 PM, Sami Olmari wrote:

 Hi

 I'd like to donate an TP-Link Archer C7 v2 to keep for willing OpenWrt
 developer in exchange for (trying to) make it more bugfree. There is
 at least few known bugs, https://dev.openwrt.org/ticket/18362 and
 https://dev.openwrt.org/ticket/18363

 Then there is also matter of switch config which kinda doesn't make
 any sense, nor editing it works as expected (too many ports, no sane
 CPU port, can't do VLANs essentially).

 Anyone interested?

   Sami Olmari
 ___
 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] [PATCH] comgt: add ncm proto support

[Sami Olmari]

Matti, would you like to have the Huawei e3276 for debugging this
after I get it back? Yours to keep if you want to :) Mine skills is
kinda not there with this, but need for working NCM is more than
needed for me :)

 Sami Olmari

On Sat, Nov 15, 2014 at 6:31 AM, John Crispin blo...@openwrt.org wrote:
 no and i will resend your device back to you next week

 On 14/11/2014 20:26, Sami Olmari wrote:
 I'm sorry to bother, but any luck with this? :) I have tried some
 stuff what Matti has suspected above the quirk is located at, but no
 good with mine coding skills :/

  Sami Olmari

 On Sun, Nov 9, 2014 at 11:49 AM, Matti Laakso malaa...@elisanet.fi wrote:
 Hi Jamie,

 On Thu, Oct 30, 2014 at 12:58:40PM +0200, Matti Laakso wrote:
 Hi Sami,

 Using John's version:

 config interface 'wan'
 option proto 'wwan'
 option apn 'opengate'
 #   option device '/dev/cdc-wdm0' (with or without commenting this)

 Does absolutely nothing, nothing in logread...

 However now when using

 config interface 'wan'
 option proto 'ncm'
 option apn 'opengate'
 option device '/dev/ttyUSB1'

 I believe that device should be /dev/cdc-wdm0 also here, at least
 when using huawei_cdc_ncm. The /dev/ttyUSBx terminals created by the
 option driver do not necessarily support all necessary AT-commands.
 Also, (at least when using proto ncm) you need to specify in
 addition

 option ifname wwan0

 That wasn't enough to get it to find the device for me for some
 reason. The following change to proto_ncm_setup does make it work:

   echo ncm[$$] Connected, starting DHCP
 - proto_init_update * 1
 + proto_init_update wwan0 1
   proto_send_update $interface

 For bringing the interface down the control device can't be found.
 The following change in proto_ncm_teardown makes that work:

   json_get_vars device
 +
 + device=/dev/ttyUSB0

   echo ncm[$$] Stopping network

 With the above two changes in place this all works fine. I don't know
 enough about how this is all meant to work to know why this is needed
 or why those configuration values are not making it to where they
 need to be.


 I suspect that the call to

 json_load $(cat /etc/gcom/ncm.json)

 in ncm.sh causes the interface information to get lost, so that subsequent
 json_* calls no longer work correctly. We should somehow unload ncm.json
 after the necessary AT-commands are read, and then restore normal
 interface information. Or can we read ncm.json into a separate namespace or
 something? Maybe Felix or Steven could give some advice?

 Matti
 ___
 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] [PATCH] comgt: add ncm proto support

[Sami Olmari]

Shouldn't there be declared proto_config_add_string ifname somewhere
at the /lib/netifd/proto/ncm.sh ? and use that as argument somewhere
in here:

echo ncm[$$] Connected, starting DHCP
proto_init_update * 1
proto_send_update $interface

And something similar for teardown?

Sami Olmari

On Sun, Nov 2, 2014 at 9:34 AM, Jamie Lenehan lene...@twibble.org wrote:
 On Thu, Oct 30, 2014 at 12:58:40PM +0200, Matti Laakso wrote:
 Hi Sami,

 Using John's version:
 
 config interface 'wan'
  option proto 'wwan'
  option apn 'opengate'
 #   option device '/dev/cdc-wdm0' (with or without commenting this)
 
 Does absolutely nothing, nothing in logread...
 
 However now when using
 
 config interface 'wan'
  option proto 'ncm'
  option apn 'opengate'
  option device '/dev/ttyUSB1'

 I believe that device should be /dev/cdc-wdm0 also here, at least
 when using huawei_cdc_ncm. The /dev/ttyUSBx terminals created by the
 option driver do not necessarily support all necessary AT-commands.
 Also, (at least when using proto ncm) you need to specify in
 addition

 option ifname wwan0

 That wasn't enough to get it to find the device for me for some
 reason. The following change to proto_ncm_setup does make it work:

 echo ncm[$$] Connected, starting DHCP
 -   proto_init_update * 1
 +   proto_init_update wwan0 1
 proto_send_update $interface

 For bringing the interface down the control device can't be found.
 The following change in proto_ncm_teardown makes that work:

 json_get_vars device
 +
 +   device=/dev/ttyUSB0

 echo ncm[$$] Stopping network

 With the above two changes in place this all works fine. I don't know
 enough about how this is all meant to work to know why this is needed
 or why those configuration values are not making it to where they
 need to be.

 This is the configuration:

 config interface optus
 option proto 'ncm'
 option ifname 'wwan0'
 option device '/dev/ttyUSB0'
 option apn 'connect'
 option ip4table 'optus'

 The ip4table part didn't work either. I added this to proto_ncm_setup
 when setting up the dhcp sub-interface parameters to make it work:

 +   json_add_string ip4table optus

 [...]
 --
  Jamie Lenehan lene...@twibble.org
 ___
 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] [PATCH] comgt: add ncm proto support

[Sami Olmari]

okay:

config interface 'wan'
option ifname 'wwan0'
option proto 'ncm'
option apn 'opengate'
option device '/dev/cdc-wdm0'

Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt
21:06:18 - -- Error Report --
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt
21:06:18 -    ^
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt
21:06:18 - Error @6, line 1, Can't control /dev/cdc-wdm0, please try
again.
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): . (1)
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446):
Thu Oct 30 21:06:18 2014 user.notice firewall: Reloading firewall due
to ifup of lan (br-lan)
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt
21:06:18 - -- Error Report --
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt
21:06:18 -    ^
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt
21:06:18 - Error @40, line 2, Can't control /dev/cdc-wdm0, please try
again.
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): . (1)
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446):
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): ncm[2446]
Failed to connect
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2502): Command
failed: Permission denied
Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2502): ncm[2502]
Stopping network
Thu Oct 30 21:06:19 2014 daemon.notice netifd: wan (2502): Can't open device .
Thu Oct 30 21:06:19 2014 daemon.notice netifd: wan (2502): ncm[2502]
Failed to disconnect
Thu Oct 30 21:06:19 2014 daemon.notice netifd: Interface 'wan' is now down

and no connection, then:

config interface 'wan'
option ifname 'wwan0'
option proto 'ncm'
option apn 'opengate'
option device '/dev/ttyUSB1' (this is correct port when
using Oskari Rauta's original code, running on main router)

Thu Oct 30 21:09:46 2014 daemon.notice netifd: Interface 'wan' is setting up now
Thu Oct 30 21:09:54 2014 daemon.notice netifd: wan (3253): ncm[3253]
Connected, starting DHCP
Thu Oct 30 21:09:54 2014 daemon.notice netifd: wan (3253): Command
failed: Invalid argument
Thu Oct 30 21:09:54 2014 daemon.notice netifd: wan (3253): Command
failed: Unknown error
Thu Oct 30 21:09:54 2014 daemon.notice netifd: wan (3253): Command
failed: Unknown error

Also behaviour is quite similar to mine previous email, Huawei's light
stays lit, but no wwan0 etc available...

Also, if I then run first ifconfig wwan0 up and then dhclient -i
wwan0 I get IP for wwan0 and internet works! can ping and use SSH to
remote location... So this must be something small typo or so
somewhere deep in scripts?!

 Sami Olmari


On Thu, Oct 30, 2014 at 12:58 PM, Matti Laakso malaa...@elisanet.fi wrote:
 Hi Sami,

 Using John's version:

 config interface 'wan'
  option proto 'wwan'
  option apn 'opengate'
 #   option device '/dev/cdc-wdm0' (with or without commenting this)

 Does absolutely nothing, nothing in logread...

 However now when using

 config interface 'wan'
  option proto 'ncm'
  option apn 'opengate'
  option device '/dev/ttyUSB1'


 I believe that device should be /dev/cdc-wdm0 also here, at least when using
 huawei_cdc_ncm. The /dev/ttyUSBx terminals created by the option driver do
 not necessarily support all necessary AT-commands. Also, (at least when
 using proto ncm) you need to specify in addition

 option ifname wwan0

 Missing this could lead to the errors below.

 Matti



 I see the Huawei dongle actually connects, as in the light lits up and
 stays, indicating connection is made, but no wwan0 nor any other
 interface at openwrt, also some erros still on logread:

 Wed Oct 29 18:50:34 2014 kern.info kernel: [ 1174.74] usb 1-1.3:
 new high-speed USB device number 5 using ehci-platform
 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.45] usb 1-1.3:
 USB disconnect, device number 5
 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.78] usb 1-1.3:
 new high-speed USB device number 6 using ehci-platform
 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.91] option
 1-1.3:1.0: GSM modem (1-port) converter detected
 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.92] usb 1-1.3:
 GSM modem (1-port) converter now attached to ttyUSB0
 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.93] option
 1-1.3:1.1: GSM modem (1-port) converter detected
 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.96] usb 1-1.3:
 GSM modem (1-port) converter now attached to ttyUSB1
 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.97]
 huawei_cdc_ncm 1-1.3:1.2: MAC-Address: 0c:5b:8f:27:9a:64
 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.98]
 huawei_cdc_ncm 1-1.3:1.2: cdc-wdm0: USB WDM device
 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.99]
 huawei_cdc_ncm 1-1.3:1.2 wwan0: register 'huawei_cdc_ncm' at
 usb-ehci-platform-1.3, Huawei CDC NCM device, 0c:5b:8f:27:9a:64

Re: [OpenWrt-Devel] [PATCH] comgt: add ncm proto support

[Sami Olmari]

Using John's version:

config interface 'wan'
option proto 'wwan'
option apn 'opengate'
#   option device '/dev/cdc-wdm0' (with or without commenting this)

Does absolutely nothing, nothing in logread...

However now when using

config interface 'wan'
option proto 'ncm'
option apn 'opengate'
option device '/dev/ttyUSB1'

I see the Huawei dongle actually connects, as in the light lits up and
stays, indicating connection is made, but no wwan0 nor any other
interface at openwrt, also some erros still on logread:

Wed Oct 29 18:50:34 2014 kern.info kernel: [ 1174.74] usb 1-1.3:
new high-speed USB device number 5 using ehci-platform
Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.45] usb 1-1.3:
USB disconnect, device number 5
Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.78] usb 1-1.3:
new high-speed USB device number 6 using ehci-platform
Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.91] option
1-1.3:1.0: GSM modem (1-port) converter detected
Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.92] usb 1-1.3:
GSM modem (1-port) converter now attached to ttyUSB0
Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.93] option
1-1.3:1.1: GSM modem (1-port) converter detected
Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.96] usb 1-1.3:
GSM modem (1-port) converter now attached to ttyUSB1
Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.97]
huawei_cdc_ncm 1-1.3:1.2: MAC-Address: 0c:5b:8f:27:9a:64
Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.98]
huawei_cdc_ncm 1-1.3:1.2: cdc-wdm0: USB WDM device
Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.99]
huawei_cdc_ncm 1-1.3:1.2 wwan0: register 'huawei_cdc_ncm' at
usb-ehci-platform-1.3, Huawei CDC NCM device, 0c:5b:8f:27:9a:64

(ifup wan here)

Wed Oct 29 18:51:00 2014 daemon.notice netifd: Interface 'wan' is setting up now

(somewhere close time to the next line the dongles light lits up steady)

Wed Oct 29 18:51:08 2014 daemon.notice netifd: wan (5097): ncm[5097]
Connected, starting DHCP
Wed Oct 29 18:51:08 2014 daemon.notice netifd: wan (5097): Command
failed: Invalid argument
Wed Oct 29 18:51:08 2014 daemon.notice netifd: wan (5097): Command
failed: Unknown error
Wed Oct 29 18:51:08 2014 daemon.notice netifd: wan (5097): Command
failed: Unknown error

No interface appears on openwrt...

Also after this, ifdown wan doesn't tear the connection down (light
stays up). So somethign works to the point dongle itself get's
connected, but clearly something doesn't work still... This is on
ar71xx platform with 3.14 kernel...

 Sami Olmari


On Sun, Oct 26, 2014 at 7:07 PM, John Crispin blo...@openwrt.org wrote:
 *cough* fixed in r43071

 On 26/10/2014 15:06, Matti Laakso wrote:
 Hi Sami,

 Well this is what John told me:

 try /dev/cdc-wdm0 as a device or simply do

 config interface
 option proto wwan
 option apn opengate

 the new wwan proto will automagically detect your needed prot and device


 I had also tried this and variations, but same resuls:

 config interface 'wan'
 option proto 'ncm'
 option apn 'opengate'
 option device '/dev/ttyUSB1'

 Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4251): Timeout
 running AT-command
 Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4251): ncm[4251]
 Failed to initialize modem
 Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4401): Command
 failed: Permission denied
 Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4401): ncm[4401]
 Stopping network
 Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4401): Can't open 
 device .
 Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4401): ncm[4401]
 Failed to disconnect
 Mon Oct 20 12:46:52 2014 daemon.notice netifd: Interface 'wan' is now down

 I think John introduced a typo when committing my patch:
 in file package/network/utils/comgt/files/runcommand.gcom on line 11
 there is

 send ^n

 which should be

 send ^m

 Try to change that.

 Matti


 On Thu, Oct 23, 2014 at 10:20 AM, Bjørn Mork bjorn at mork.no 
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel wrote:
 / Sami Olmari sami at olmari.fi 
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel writes:
 //
 // option proto 'wwan'
 //
 // I don't know much about how this is supposed to work (don't have any
 // Huawei NCM modem), but I do see this in the patch posted earlier in this
 // thread:
 //
 // diff --git a/package/network/utils/comgt/files/3g.usb
 // b/package/network/utils/comgt/files/3g.usb
 // index fd6837e..ac8326b 100644
 // --- a/package/network/utils/comgt/files/3g.usb
 // +++ b/package/network/utils/comgt/files/3g.usb
 // @@ -8,7 +8,7 @@ find_3g_iface() {
 //
 //   local proto
 //   config_get proto $cfg proto
 // - [ $proto = 3g ] || return 0
 // + [ $proto = 3g ] || [ $proto = ncm ] || return 0
 //
 //   # bypass state vars here because 00-netstate could clobber 
 .device
 //   local dev=$(uci_get network

Re: [OpenWrt-Devel] [PATCH] comgt: add ncm proto support

[Sami Olmari]

Well this is what John told me:

try /dev/cdc-wdm0 as a device or simply do

config interface
option proto wwan
option apn opengate

the new wwan proto will automagically detect your needed prot and device


I had also tried this and variations, but same resuls:

config interface 'wan'
option proto 'ncm'
option apn 'opengate'
option device '/dev/ttyUSB1'

Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4251): Timeout
running AT-command
Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4251): ncm[4251]
Failed to initialize modem
Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4401): Command
failed: Permission denied
Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4401): ncm[4401]
Stopping network
Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4401): Can't open device .
Mon Oct 20 12:46:52 2014 daemon.notice netifd: wan (4401): ncm[4401]
Failed to disconnect
Mon Oct 20 12:46:52 2014 daemon.notice netifd: Interface 'wan' is now down

 Sami Olmari

On Thu, Oct 23, 2014 at 10:20 AM, Bjørn Mork bj...@mork.no wrote:
 Sami Olmari s...@olmari.fi writes:

 option proto 'wwan'

 I don't know much about how this is supposed to work (don't have any
 Huawei NCM modem), but I do see this in the patch posted earlier in this
 thread:

 diff --git a/package/network/utils/comgt/files/3g.usb
 b/package/network/utils/comgt/files/3g.usb
 index fd6837e..ac8326b 100644
 --- a/package/network/utils/comgt/files/3g.usb
 +++ b/package/network/utils/comgt/files/3g.usb
 @@ -8,7 +8,7 @@ find_3g_iface() {

   local proto
   config_get proto $cfg proto
 - [ $proto = 3g ] || return 0
 + [ $proto = 3g ] || [ $proto = ncm ] || return 0

   # bypass state vars here because 00-netstate could clobber .device
   local dev=$(uci_get network $cfg device)


 which might explain stuff?


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

Re: [OpenWrt-Devel] Minicom - wrong Download

[Sami Olmari]

The link https://alioth.debian.org/frs/download.php/file/3977/ gives
minicom-2.7.tar.gz when I clicked it, so link seems to be correct...

 Sami Olmari

On Mon, Oct 20, 2014 at 7:23 PM,  smile...@gmail.com wrote:
 Am Mon, 20 Oct 2014 06:38:36 +0200
 schrieb Jiří Šlachta slac...@cesnet.cz:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 I have checked the package repositories and ..

 * the latest stable release contains minicom 2.7-1
 * the latest snapshots contains minicom 2.7-1

 I have also checked the package Makefiles and those are referring
 to version 2.7.

 Would you be so kind to refer what directory are you mentioning?

 I mean the entry in the Makefile:

 PKG_SOURCE_URL:=https://alioth.debian.org/frs/download.php/file/3977/

 Possible my makefile is too old?
 I make only this...
 ./scripts/feeds update



 Also do not forget to use opkg update!

 What is this?
 opkg update? in my repository? Dont work.



 Have a nice day!
 Jiri Slachta

 Dne 20/10/2014 v 00:26 smile...@gmail.com napsal(a):
  the download point to minicom-2.7.
  but in this directory exists only minicom-2.3.
 
  lg
 
 
 
  ___
  openwrt-devel mailing list
  openwrt-devel@lists.openwrt.org
  https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (MingW32)

 iQIcBAEBAgAGBQJURJHMAAoJECilMVBDttCP3uYQAI9muS77bae6B20ODM3FP+U2
 72gYNgwlPW+pLb4FS1uHPZImagXbLQTGGJMU+yVyaMsRpr8vpmo/xZ9m4ZgHM/jm
 2DpEAetTa3rG8RzeBelBI2hreidJFkqfsiRnhcTvsiBHmf0de1U5mcQRF3oP7cq3
 o7nJ2Jm6b29XCE4HJ0vhfODwgVy8hhw+6R7dvbuU8nDVOLy6hBbEYwnxpO6q/OOn
 feectwmlKoyO0IJASiD7uyxonmYz9ARa3H0d6Ncs39IRXNkStJ/QvyvplKYnZaSR
 IaU2M0qgQE/biiok1vDKyrlVxmqGy0t00vvxwES5iBlsGkCWA53jCn4WjEpDz1+n
 y9JiEprL6CkTUtlDETTEMH8ztecTccim6Pb0wa3VyTvdLVfkMdDkTEu/rKJZAOX3
 IwU72Lwjxq7lWpImJ+M8febBuiiF9S5dnOXt7hLuX1GOyEufkb+GKHhdg4qSW2nn
 5nJMeyaM6dpJrPNGyw+N+WfhTl9zDDVXlBo0dXkiwPa3ajLGmWq7j30E0z1kpPy0
 OghUBsKvFKJqft0zTYJtvNSqhfmPmglQxFN8pf++1+4YW7H82tP2dx4Z2B7Fhrwx
 FYUtYDGyyKq8V2+xFExuEq1AkKy9kj7OnjA2MUNoMOd8Gbscqv/UKdVWu7CqwxJf
 TvWOD83YWXK2pzsxHlhS
 =UjUA
 -END PGP SIGNATURE-


 ___
 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] 4g NCM modem huawei e3276

[Sami Olmari]

Sent. The lady at postoffice told that should take 4 days to arrive, so
friday or monday :-)

I did include return envelope (not paid tough), but I still urge you to
keep it for possible future troubleshooting :-P

Also, if/when there is patches available, I'd be more than willing to test
the stuff to the extreme, before you return the dongle even with me
resisting ;)

Sami Olmari

On Sep 16, 2014 9:06 AM, John Crispin blo...@openwrt.org wrote:

 that is very kind, however i do have ~30 different sticks here already :)

 i will send the stick back to you once it all works, it will just
 collect dust in my office

 Thanks,
 John


 On 15/09/2014 18:29, Sami Olmari wrote:
 
  The more I think about this, the more I am going to let you just keep
  the stick... In the future when I complain about some bug you can
  still test it ;) Lets consider it mine donation to OpenWrt, the thing
  I need to get working anyways :-)
 
  Sami Olmari
 
  On Sep 15, 2014 6:15 PM, John Crispin blo...@openwrt.org
  mailto:blo...@openwrt.org wrote:
 
  Hi,
  please send it to ..
 
 obfuscated
 
  once i have the dongle i will need less than 48 hours to test and
will
  return the stick via registered post. i just want to spare having to
  pay 100 euros to buy a stick, i already spent 350 euro last month
on a
  ecm, mbim anf qmi modem :) ncm is the last protocol on my list, once
  supported openwrt will be able to handle all of the 6 major 3g/4g
  protocols.
 
  Thanks for your support :)
  John
 
 
 
  On 15/09/2014 14:16, Sami Olmari wrote:
   Hmm, that could work, at least I do have old spare dongle to use
   with system in mean time :-) Tell me where I can send the thing
and
   I'll send the thing in a few days :-)
  
   Sami Olmari
  
   On Sep 15, 2014 3:11 PM, John Crispin blo...@openwrt.org
  mailto:blo...@openwrt.org
   mailto:blo...@openwrt.org mailto:blo...@openwrt.org wrote:
  
   Hi,
  
   my version of the scripts is based on Oskari patches and fixes a
   lot of the not perfect stuff
  
   however i am sure it wont work out of the box as i blindly
   reworked large parts of the code.
  
   i can send it back to you in finland when i am done testing.
  
   John
  
   On 15/09/2014 13:53, Sami Olmari wrote:
  
   I have 2 such devices, I do use Oskari Rauta's scripts to run
   it.. not perfect but works after manual labour... Maybe there
   would be at least some ideas... So.. I can definately help with
   testing! I have to think how I could donate one dongle to you...
  
   Sami Olmari
  
   On Sep 15, 2014 1:35 PM, John Crispin blo...@openwrt.org
  mailto:blo...@openwrt.org
   mailto:blo...@openwrt.org mailto:blo...@openwrt.org
   mailto:blo...@openwrt.org mailto:blo...@openwrt.org
  mailto:blo...@openwrt.org mailto:blo...@openwrt.org wrote:
  
   Hi,
  
   i would like to add 4g ncm support. there are a few version of
   a patc
   floating around that don't make use of dynamic_interface yet.
  
   anyone around that wants to 1) donate a huawei e3276 2) has a
   huawei e3276 and wants to help testing ?
  
   John ___
   openwrt-devel mailing list openwrt-devel@lists.openwrt.org
  mailto:openwrt-devel@lists.openwrt.org
   mailto:openwrt-devel@lists.openwrt.org
  mailto:openwrt-devel@lists.openwrt.org
   mailto:openwrt-devel@lists.openwrt.org
  mailto:openwrt-devel@lists.openwrt.org
   mailto:openwrt-devel@lists.openwrt.org
  mailto:openwrt-devel@lists.openwrt.org
   https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
  
  
  
  
   ___ openwrt-devel
   mailing list openwrt-devel@lists.openwrt.org
  mailto: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] 4g NCM modem huawei e3276

[Sami Olmari]

I have 2 such devices, I do use Oskari Rauta's scripts to run it.. not
perfect but works after manual labour... Maybe there would be at least some
ideas... So.. I can definately help with testing! I have to think how I
could donate one dongle to you...

Sami Olmari
On Sep 15, 2014 1:35 PM, John Crispin blo...@openwrt.org wrote:

 Hi,

 i would like to add 4g ncm support. there are a few version of a patc
 floating around that don't make use of dynamic_interface yet.

 anyone around that wants to
 1) donate a huawei e3276
 2) has a huawei e3276 and wants to help testing ?

 John
 ___
 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] 4g NCM modem huawei e3276

[Sami Olmari]

Hmm, that could work, at least I do have old spare dongle to use with
system in mean time :-) Tell me where I can send the thing and I'll send
the thing in a few days :-)

Sami Olmari
On Sep 15, 2014 3:11 PM, John Crispin blo...@openwrt.org wrote:

 Hi,

 my version of the scripts is based on Oskari patches and fixes a lot of
 the not perfect stuff

 however i am sure it wont work out of the box as i blindly reworked
 large parts of the code.

 i can send it back to you in finland when i am done testing.

 John

 On 15/09/2014 13:53, Sami Olmari wrote:
 
  I have 2 such devices, I do use Oskari Rauta's scripts to run it.. not
  perfect but works after manual labour... Maybe there would be at least
  some ideas... So.. I can definately help with testing! I have to think
  how I could donate one dongle to you...
 
  Sami Olmari
 
  On Sep 15, 2014 1:35 PM, John Crispin blo...@openwrt.org
  mailto:blo...@openwrt.org wrote:
 
  Hi,
 
  i would like to add 4g ncm support. there are a few version of a patc
  floating around that don't make use of dynamic_interface yet.
 
  anyone around that wants to
  1) donate a huawei e3276
  2) has a huawei e3276 and wants to help testing ?
 
  John
  ___
  openwrt-devel mailing list
  openwrt-devel@lists.openwrt.org
  mailto: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] [PATCH] add NCM support to openwrt

[Sami Olmari]

For me this NCM protocol has been irreplaceable. It makes the LTE
connection so much faster than traditional PPP link. So far I am
using Oskari's NCM set at cabin's data, and more importantly at Vaasa
Hacklab router. So far I haven't been able to spot any errors or
misworkings in today's trunk openwrt #40863. Used general instructions
from https://sites.google.com/site/variousopenwrt/huawei-e3267

+1 to this!

Reviewed-by: Sami Olmari s...@olmari.fi
Tested-by: Sami Olmari s...@olmari.fi
Acked-by: Sami Olmari s...@olmari.fi

On Thu, Nov 28, 2013 at 7:02 PM, Oskari Rauta oskari.ra...@gmail.com wrote:

 Shouldn't the patch be splitted because of different features?
 ( luci, non-luci stuff, hardware (huawai config))

 Here is version 2 of patch, that patches against packages and does not have 
 LuCI packages at all..

 diff --git a/net/ncm/Makefile b/net/ncm/Makefile
 new file mode 100644
 index 000..e4c5a85
 --- /dev/null
 +++ b/net/ncm/Makefile
 @@ -0,0 +1,94 @@
 +#
 +# Copyright (C) 2007-2013 OpenWrt.org
 +# Copyright (C) 2010 Vertical Communications
 +#
 +# This is free software, licensed under the GNU General Public License v2.
 +# See /LICENSE for more information.
 +#
 +
 +include $(TOPDIR)/rules.mk
 +
 +PKG_NAME:=ncm
 +PKG_VERSION:=1.0
 +PKG_RELEASE:=1
 +PKG_MAINTAINER:=Oskari Rauta oskari.ra...@gmail.com
 +PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)-$(PKG_RELEASE)
 +
 +include $(INCLUDE_DIR)/package.mk
 +
 +define Package/ncm/Default
 +  VERSION:=$(PKG_VERSION)-$(PKG_RELEASE)
 +  URL:=http://openwrt.org/
 +  MAINTAINER:=Oskari Rauta oskari.ra...@gmail.com
 +endef
 +
 +define Package/ncm
 +$(call Package/ncm/Default)
 +  SECTION:=net
 +  CATEGORY:=Network
 +  TITLE:=Protocol support for NCM
 +  DEPENDS:=+comgt +kmod-usb-net-cdc-ncm +kmod-usb-serial
 +endef
 +
 +define Package/ncm/description
 + This package contains protocol support for NCM.
 +endef
 +
 +define Package/ncm-huawei-e3276
 +$(call Package/ncm/Default)
 +  SECTION:=net
 +  CATEGORY:=Network
 +  TITLE:=Huawei E3276 support for NCM protocol
 +  DEPENDS:=+ncm +comgt +kmod-usb-serial
 +endef
 +
 +define Package/ncm-huawei-e3276/description
 + This package contains communication scripts for Huawei E3276
 +endef
 +
 +define Build/Prepare
 +   mkdir -p $(PKG_BUILD_DIR)
 +endef
 +
 +define Build/Configure
 +endef
 +
 +define Build/Compile/Default
 +endef
 +
 +Build/Compile = $(Build/Compile/Default)
 +
 +define Package/ncm/install
 +   $(INSTALL_DIR) $(1)/lib
 +   $(INSTALL_DIR) $(1)/lib/netifd
 +   $(INSTALL_DIR) $(1)/lib/netifd/proto
 +   $(INSTALL_DIR) $(1)/etc
 +   $(INSTALL_DIR) $(1)/etc/gcom
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm/signal
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm/carrier
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm/setmode
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm/connect
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm/initscripts
 +   $(INSTALL_BIN) ./files/lib/netifd/proto/ncm.sh $(1)/lib/netifd/proto/
 +   $(INSTALL_DATA) ./files/etc/gcom/ncm/getcardinfo.gcom 
 $(1)/etc/gcom/ncm/
 +endef
 +
 +define Package/ncm-huawei-e3276/install
 +   $(INSTALL_DIR) $(1)/etc
 +   $(INSTALL_DIR) $(1)/etc/gcom
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm/signal
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm/carrier
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm/setmode
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm/connect
 +   $(INSTALL_DIR) $(1)/etc/gcom/ncm/initscripts
 +   $(INSTALL_DATA) ./files/etc/gcom/ncm/signal/huawei_e3276.gcom 
 $(1)/etc/gcom/ncm/signal/
 +   $(INSTALL_DATA) ./files/etc/gcom/ncm/carrier/huawei_e3276.gcom 
 $(1)/etc/gcom/ncm/carrier/
 +   $(INSTALL_DATA) ./files/etc/gcom/ncm/setmode/huawei_e3276.gcom 
 $(1)/etc/gcom/ncm/setmode/
 +   $(INSTALL_DATA) ./files/etc/gcom/ncm/connect/huawei_e3276.gcom 
 $(1)/etc/gcom/ncm/connect/
 +   $(INSTALL_DATA) ./files/etc/gcom/ncm/initscripts/huawei_e3276.gcom 
 $(1)/etc/gcom/ncm/initscripts/
 +endef
 +
 +$(eval $(call BuildPackage,ncm))
 +$(eval $(call BuildPackage,ncm-huawei-e3276))
 diff --git a/net/ncm/files/etc/gcom/ncm/carrier/huawei_e3276.gcom 
 b/net/ncm/files/etc/gcom/ncm/carrier/huawei_e3276.gcom
 new file mode 100644
 index 000..58684fd
 --- /dev/null
 +++ b/net/ncm/files/etc/gcom/ncm/carrier/huawei_e3276.gcom
 @@ -0,0 +1,56 @@
 +opengt
 +set com 115200n81
 +set comecho off
 +set senddelay 0.02
 +waitquiet 0.2 0.2
 +flash 0.1
 +
 +:getprovider
 + send AT+COPS?^m
 + let $r=+COPS:
 + gosub readresult
 + system echo \+$x+\ | awk -F\[:,]\ '{print \provider \\x27\ $4 
 \\\x27\}'
 +
 +:getmode
 + send AT^^SYSCFGEX?^m
 + let $r=^^SYSCFGEX:
 + gosub readresult
 + system echo \+$x+\ | awk -F\[:,]\ '{ \\
 +   if ( $2 == \01\ ) print \mode \\x27\ \2G\\x27\; \\
 +   else if ( $2 == \02\ ) print \mode \\x27\ \3G\\x27\; \\
 +   else if ( $2 == \03\ ) print \mode \\x27\ \LTE\\x27\; \\
 +   else if ( $2 == \0201\ ) print \mode

Re: [OpenWrt-Devel] OpenSSL vulnerability

[Sami Olmari]

And this bug is particularly nasty one, should be fixed ASAP.

On Tue, Apr 8, 2014 at 2:10 AM, Ben West b...@gowasabi.net wrote:
 About the exploit:
 http://heartbleed.com/

 The fixed version (released recently) is 1.01g+:
 https://www.openssl.org/news/secadv_20140407.txt

 Trunk appears to be using 1.01f:
 https://dev.openwrt.org/browser/trunk/package/libs/openssl/Makefile

 AA is on 1.01e
 https://dev.openwrt.org/browser/tags/attitude_adjustment_12.09/package/openssl/Makefile?rev=40420

 --
 Ben West
 http://gowasabi.net
 b...@gowasabi.net
 314-246-9434

 ___
 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] [PATCH] [package] ddns-scripts: add dy.fi service and add [HTTPAUTH] to description

[Sami Olmari]

Add dy.fi ddns provider into ddns-scripts services file and add [HTTPAUTH] into 
description in top of the services file, the functionality has been added long 
ago, just description is missing.

Signed-off-by: Sami Olmari s...@olmari.fi
Tested-by: Sami Olmari s...@olmari.fi
---
--- package/feeds/packages/ddns-scripts/files/usr/lib/ddns/services.orig
2013-02-08 22:42:48.628443832 +0200
+++ package/feeds/packages/ddns-scripts/files/usr/lib/ddns/services 
2013-02-24 21:12:54.618384332 +0200
@@ -1,12 +1,13 @@
  # This file contains the update urls for various dynamic dns services.
  # Column one contains the service name, column two contains the update url.
-# within the update url there are 4 variables you can use: [USERNAME],
-# [PASSWORD], [DOMAIN] and [IP].  These are substituted for the username,
-# password, and domain name specified in the /etc/config/ddns file when an
-# update is performed.  The IP is substituted for the current ip address of the
-# router.  These variables are case sensitive, while urls generally are not, so
-# if you need to enter the same text in the url (which seems very unlikely) put
-# that text in lowercase, while the variables should remain in uppercase
+# within the update url there are 5 variables you can use: [USERNAME],
+# [PASSWORD], [HTTPAUTH], [DOMAIN] and [IP].  These are substituted for the
+# username, password, and domain name specified in the /etc/config/ddns file
+# when an update is performed.  The IP is substituted for the current ip
+# address of the router.  These variables are case sensitive, while urls
+# generally are not, so if you need to enter the same text in the url
+# (which seems very unlikely) put that text in lowercase, while the variables
+# should remain in uppercase

  dyndns.org
http://[USERNAME]:[PASSWORD]@members.dyndns.org/nic/update?hostname=[DOMAIN]myip=[IP];
  changeip.com  
http://[USERNAME]:[PASSWORD]@nic.changeip.com/nic/update?u=[USERNAME]p=[PASSWORD]cmd=updatehostname=[DOMAIN]ip=[IP];
@@ -57,3 +58,6 @@

  # easydns.com dynamic DNS
  easydns.com   
http://[USERNAME]:[PASSWORD]@api.cp.easydns.com/dyn/tomato.php?hostname=[DOMAIN]myip=[IP];
+
+# dy.fi Dynamic DNS for finnish users
+dy.fi  http://[HTTPAUTH]@www.dy.fi/nic/update?hostname=[DOMAIN];
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] firewall3: source address used for NAT reflection

[Sami Olmari]

AFAIK NAT reflection in openwrt was originally meant to stay "inside" LAN, and then one could use for example Split-DNS in order to make a DNS name "just the same" for a client, no matter in or outside the LAN...Sami OlmariOn Sun, 10 Mar 2013 23:17:36 +0200, Mark Mentovai m...@moxienet.com wrote:Has the source address used for NAT reflection changed with firewall3?At r35938, I’m seeing that when I attempt to connect from a host on my LAN to a redirected port on my main router’s WAN address, the router reflects the request back in to my LAN using its own WAN address as the source address. I noticed this because some of my internal hosts don’t have a route to this WAN address and can’t respond to requests reflected in this way.
Previously, I was running r35844, which didn’t have this problem. It used the router’s LAN address as the source address for these reflected packets.Looking through “iptables -t nat -L” confirms that there’s been a change. Previously I’d see innat_reflection_out
SNATtcp -- 192.168.1.0/24192.168.1.2 tcp dpt:443 /* wan */ to:192.168.69.1and now I see inzone_lan_postrouting (w.x.y.z is my WAN IP address)
SNATtcp -- 192.168.1.0/24192.168.1.2 tcp dpt:443 to:w.x.y.zIs it possible to configure the source address used for these reflected packets? I’d prefer to use the LAN address for this because all of my hosts have a route to it by virtue of being connected to this network, and because the LAN address is much less likely to change than the WAN address.

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

Re: [OpenWrt-Devel] TP-Link TL-WR841ND to replace WRT54GL?

[Sami Olmari]

On Wed, 06 Mar 2013 21:22:46 +0200, edgar.sol...@web.de wrote:


+1 on the 1043ND.

If you do not need 5GHz WiFi, this is a really good buy.  Using them with
various versions of OpenWRT as 1wire hub, OpenVPN client, server, 3G router
(using an USB UMTS dongle, with OpenVPN and IPv6 over OpenVPN), ...



out of interest. what would be a good 5ghz alternative?

..ede


Maybe an TP-Link WDR4300

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

[OpenWrt-Devel] [PATCH 001/001] [package] ddns-scripts: add dy.fi service and add [HTTPAUTH] to description

[Sami Olmari]

From: Sami Olmari s...@olmari.fi

Add dy.fi ddns provider into ddns-scripts services file and add [HTTPAUTH] into 
description in top of the services file, the functionality has been added long 
ago, just description is missing.

Signed-off-by: Sami Olmari s...@olmari.fi
Tested-by: Sami Olmari s...@olmari.fi
---
--- package/feeds/packages/ddns-scripts/files/usr/lib/ddns/services.orig
2013-02-08 22:42:48.628443832 +0200
+++ package/feeds/packages/ddns-scripts/files/usr/lib/ddns/services 
2013-02-24 21:12:54.618384332 +0200
@@ -1,12 +1,13 @@
 # This file contains the update urls for various dynamic dns services.
 # Column one contains the service name, column two contains the update url.
-# within the update url there are 4 variables you can use: [USERNAME],
-# [PASSWORD], [DOMAIN] and [IP].  These are substituted for the username,
-# password, and domain name specified in the /etc/config/ddns file when an
-# update is performed.  The IP is substituted for the current ip address of the
-# router.  These variables are case sensitive, while urls generally are not, so
-# if you need to enter the same text in the url (which seems very unlikely) put
-# that text in lowercase, while the variables should remain in uppercase
+# within the update url there are 5 variables you can use: [USERNAME],
+# [PASSWORD], [HTTPAUTH], [DOMAIN] and [IP].  These are substituted for the
+# username, password, and domain name specified in the /etc/config/ddns file
+# when an update is performed.  The IP is substituted for the current ip
+# address of the router.  These variables are case sensitive, while urls
+# generally are not, so if you need to enter the same text in the url
+# (which seems very unlikely) put that text in lowercase, while the variables
+# should remain in uppercase

 dyndns.org 
http://[USERNAME]:[PASSWORD]@members.dyndns.org/nic/update?hostname=[DOMAIN]myip=[IP];
 changeip.com   
http://[USERNAME]:[PASSWORD]@nic.changeip.com/nic/update?u=[USERNAME]p=[PASSWORD]cmd=updatehostname=[DOMAIN]ip=[IP];
@@ -57,3 +58,6 @@

 # easydns.com dynamic DNS
 easydns.com
http://[USERNAME]:[PASSWORD]@api.cp.easydns.com/dyn/tomato.php?hostname=[DOMAIN]myip=[IP];
+
+# dy.fi Dynamic DNS for finnish users
+dy.fi  http://[HTTPAUTH]@www.dy.fi/nic/update?hostname=[DOMAIN];
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel