[no subject]
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
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, &res); > > + > > + c = blobmsg_open_table(&status, NULL); > > + if (res.set.network_selection_preference) { > > + blobmsg_add_string(&status, "mode", > > modes[res.data.network_selection_preference]); > > + } > > + if (res.set.manual_network_selection) { > > + blobmsg_add_u32(&status, "mcc", > > res.data.manual_network_selection.mcc); > > + blobmsg_add_u32(&status, "mnc", > > res.data.manual_network_selection.mnc); > > + } > > + > > + blobmsg_close_table(&status, 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
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
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
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
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
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
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
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 wrote: > > Philip Prindeville 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?
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
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 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
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 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
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
[OpenWrt-Devel] [PATCH v2] 6in4: Corrected tunnelbroker tunnel update URL
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 Signed-off-by: Sami Olmari --- 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=$password&hostname=$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] [PATCH] 6in4: Corrected tunnelbroker tunnel update URL
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 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 > Signed-off-by: Sami Olmari > --- > 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=$password&hostname=$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
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 Signed-off-by: Sami Olmari --- 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=$password&hostname=$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
-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 wrote: > * Michael Richardson [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
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" 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] [PATCH 0/2] Add ATI IXP PATA driver to x86/64 target
More so, in general x86 (be it 64 or 32) is diffirent in that way that there is endless possibilities of devices and configurations, we never can achieve system that supports everything, nor we want to, in mine opinion... Instead one can use buildroot (if not imagebuilder) to include just the stuff one needs to his/hers openwrt build... Granted, that sometimes involves even tinkering with make kernel_menuconfig or so, but I don't know muchh better way myself.. As not everything can be "exported" into normal openwrt menuconfig either... Sami Olmari On Fri, Sep 25, 2015 at 12:36 PM, Imre Kaloz wrote: > On Fri, 25 Sep 2015 10:02:07 +0200, Felix Kaechele < > hef...@fedoraproject.org> wrote: > > Hi list, >> >> within the Freifunk project in Germany we currently use very low cost >> thin-clients (FSC Futro S550) for VPN offloading. >> Those thin-clients have an internal CF card (1GB) attached to the >> chipset's PATA controller that uses the arcane pata_atiixp driver. >> This seems like an ideal storage option for booting the device from. >> >> I would like to enable OpenWrt to boot from this CF card and therefor >> would need this driver to be built into the kernel. >> >> If changes like these to the generic x86_64 target are not desireable the >> other option would be to create an own subtarget specifically for this >> device. >> >> What do you think? >> > > NAK. The x86-64 subtarget is free from legacy stuff and should remain that > way. Looking at the specs of that thin client it can have either 1 or 2GB > of ram, so it doesn't make much sense to use it in 64bits anyways. If > changes are needed to run the generic x86 taget on it, please send patches > for that. > > > Cheers, > > Imre > > ___ > 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
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 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
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 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 > --- > 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" > + }, > + "connect": "AT!SCA
Re: [OpenWrt-Devel] how to build two sub target simultaneously under same target
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 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
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 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
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
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
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 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] RFC: adding 'traceroute6' to busybox / base
Mine opinion is that if there is IPv4 version per default then IPv6 version should be there too... Whole another thing is to decide what there should be at default installation :) Sami Olmari On Aug 1, 2015 13:54, "Bastian Bittorf" wrote: > i build it for ar71xx, and these are the numbers [bytes]: > > before: > 359736 build_dir/target-mips_34kc_musl-1.1.10/busybox-1.23.2/busybox > 208071 bin/ar71xx/packages/base/busybox_1.23.2-1_ar71xx.ipk > > after: > 359884 build_dir/target-mips_34kc_musl-1.1.10/busybox-1.23.2/busybox > 209115 bin/ar71xx/packages/base/busybox_1.23.2-1_ar71xx.ipk > > so it adds ~1k to the image. (strange that uncompressed ~148 bytes) > it's as simple as adding CONFIG_BUSYBOX_CONFIG_TRACEROUTE6=y > what do you think? > > 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] Dynamically generate custom files before building?
isn't it quite self-explanatory? with "./scripts/env new " 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 wrote: > Hi > > On Wed, Mar 25, 2015 at 12:33 AM, Sami Olmari 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] [arguments] > Commands: > help This help text > list List environments > clear Delete all environment and revert to flat > config/files > new Create a new environment > switch Switch to a different environment > delete Delete an environment > rename 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?
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" 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?
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" 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
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
I can do basic testing too, if wanted to :) Sami Olmari On Feb 12, 2015 1:50 PM, "John Crispin" 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
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 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
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" 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] Fwd: Donating TL-Archer C7 v2 for developer
I want this in mailinlist too, hopefully forward is okay and correct: -- Forwarded message -- From: Ben Franske Date: Sun, Nov 30, 2014 at 3:34 AM Subject: Re: [OpenWrt-Devel] Donating TL-Archer C7 v2 for developer To: Sami Olmari 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] Donating TL-Archer C7 v2 for developer
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 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
Re: [OpenWrt-Devel] Donating TL-Archer C7 v2 for developer
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 wrote: > Sent one, let's hope everything goes okay :) > > Sami > > On Sun, Nov 30, 2014 at 2:45 AM, Sami Olmari 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 >> wrote: >>> Yupp, okay Ill bite... but im in Australia :) >>> >>> On Sun, Nov 30, 2014 at 12:11 AM, 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] Donating TL-Archer C7 v2 for developer
Sent one, let's hope everything goes okay :) Sami On Sun, Nov 30, 2014 at 2:45 AM, Sami Olmari 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 wrote: >> Yupp, okay Ill bite... but im in Australia :) >> >> On Sun, Nov 30, 2014 at 12:11 AM, 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] Donating TL-Archer C7 v2 for developer
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 wrote: > Yupp, okay Ill bite... but im in Australia :) > > On Sun, Nov 30, 2014 at 12:11 AM, 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] Donating TL-Archer C7 v2 for developer
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] [PATCH] comgt: add ncm proto support
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 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 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
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 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 > ___ > 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
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 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 &g
Re: [OpenWrt-Devel] [PATCH] comgt: add ncm proto support
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 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 >> <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote: >>> >/ Sami Olmari >> ><https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>
Re: [OpenWrt-Devel] [PATCH] comgt: add ncm proto support
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 wrote: > Sami Olmari 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] [PATCH] comgt: add ncm proto support
I wonder would this thread reach most of interested persons, not just John whom I've talked with plenty :) I have Huawei e3276, latest openwrt trunk, used kernel 3.14 (ar71xx target), I have chosen proper drivers and comgt-ncm etc, but for any reason when wan is set to assumedly proper settings, literally nothing happends... logread has no new lines etc... I wonder what I miss still or what is in error :) /etc/config/network: config interface 'wan' option device '/dev/cdc-wdm0' #Tried with and without this option proto 'wwan' option apn 'opengate' Logread shows device is there end regonised, but neither "ifup wan" nor "etc/init.d/network restart" doesn't make it work, not single line relating to this comes into log... Any debug I could do or please ask if additional info needed. Sami Olmari On Thu, Oct 9, 2014 at 5:47 PM, Bjørn Mork wrote: > John Crispin writes: > >> i am currently using a vodafone k5105 which is a huawei rebrand. at >> 150 euro its very expensive. any other good ones ? > > I find it impossible to recommend any specific modems because important > firmware features like MBIM depend on both operator branding and > geographical target area. But I can list the MBIM modems I have: > > - Huawei E367 with MBIM firmware. I have no idea whether this is > available anywhere in the world today. I know most of the E367s were > QMI only. That's of course only a firmware issue, but that doesn't > help much as long as the firmware isn't available. > > - D-Link DWM-156 rev A7. This might be a safer bet on the cheap side. > I haven't seen any non MBIM variants for that specific revision. But > I wouldn't be suprised if they exist either, so the usual warnings > apply. > > The rest of my MBIM modems are mini-PCIe or m.2, and also very > expensive: > > - Ericsson H5321gw (with newer firmware), halfsize mini-PCIe > > - Sierra Wireless MC7710 (with newer firmware, depending on cfg), > fullsize mini-PCIe > > - Sierra Wireless EM7345, m.2 (3042) > > > Bjørn > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Minicom - wrong Download
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, wrote: > Am Mon, 20 Oct 2014 06:38:36 +0200 > schrieb Jiří Šlachta : > >> -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
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" 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" > <mailto:blo...@openwrt.org>> wrote: > > > > Hi, > > please send it to .. > > > > > > > > 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" > <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" > <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
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" 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" > <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] 4g NCM modem huawei e3276
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" 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] [PATCH] add NCM support to openwrt
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 Tested-by: Sami Olmari Acked-by: Sami Olmari On Thu, Nov 28, 2013 at 7:02 PM, Oskari Rauta 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 > +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 > +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
Re: [OpenWrt-Devel] OpenSSL vulnerability
And this bug is particularly nasty one, should be fixed ASAP. On Tue, Apr 8, 2014 at 2:10 AM, Ben West 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
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 Tested-by: Sami Olmari --- --- 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=update&hostname=[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
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 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 in nat_reflection_out SNAT tcp -- 192.168.1.0/24 192.168.1.2 tcp dpt:443 /* wan */ to:192.168.69.1and now I see in zone_lan_postrouting (w.x.y.z is my WAN IP address) SNAT tcp -- 192.168.1.0/24 192.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?
On Wed, 06 Mar 2013 21:22:46 +0200, 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
From: 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 Tested-by: Sami Olmari --- --- 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=update&hostname=[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