Re: [OpenWrt-Devel] [PATCH] geos: Add PC speaker to kernel definitions

On Thu, 14 Apr 2011 20:31:14 -0600 Philip Prindeville wrote: > Add the PC speaker back to the Geos platform. > > Signed-off-by: Philip Prindeville > --- > Index: target/linux/x86/geos/config-default > === > --- target/linux/x86/geo

Re: [OpenWrt-Devel] [PATCH] geos: uci-defaults updates

On Thu, 14 Apr 2011 22:05:27 -0600 Philip Prindeville wrote: > Punch firewall holes for ISAKMP (udp port 500) and IPsec ESP. > > Set system.foreground to 1 to force scripts to complete before > starting console shell. > > Signed-off-by: Philip Prindeville > --- I don't think making ISAKMP (IP

Re: [OpenWrt-Devel] [PATCH v2 1/1] geos: Add PC speaker to kernel definitions

On Thu, 14 Apr 2011 22:33:11 -0600 Philip Prindeville wrote: > Add the PC speaker back to the Geos platform. > > Add DMI support in BIOS. > > Signed-off-by: Philip Prindeville > Committed. -- hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can

[OpenWrt-Devel] [PATCH v2 1/1] geos: Add PC speaker to kernel definitions

Add the PC speaker back to the Geos platform. Add DMI support in BIOS. Signed-off-by: Philip Prindeville Index: target/linux/x86/geos/config-default === --- target/linux/x86/geos/config-default(revision 26677) +++ target/li

[OpenWrt-Devel] [PATCH] geos: uci-defaults updates

Punch firewall holes for ISAKMP (udp port 500) and IPsec ESP. Set system.foreground to 1 to force scripts to complete before starting console shell. Signed-off-by: Philip Prindeville --- Index: target/linux/x86/geos/base-files/etc/uci-defaults/firewall ==

[OpenWrt-Devel] [PATCH] geos: Add PC speaker to kernel definitions

Add the PC speaker back to the Geos platform. Signed-off-by: Philip Prindeville --- Index: target/linux/x86/geos/config-default === --- target/linux/x86/geos/config-default(revision 26677) +++ target/linux/x86/geos/config-default

Re: [OpenWrt-Devel] [OpenWrt] #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with regdomain=US

The AR9280 radio is pretty sensitive. I've seen it register a noise floor below -100dBm in 20mhz-wide 11g channels. I don't know what it'd look like in 900mhz mode. Adrian On 15 April 2011 08:18, Larry Vaden wrote: > On Thu, Apr 14, 2011 at 7:08 PM, OpenWrt > wrote: > > #9207: txpower may be

Re: [OpenWrt-Devel] [OpenWrt] #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with regdomain=US

On 2011-04-15 2:18 AM, Larry Vaden wrote: On Thu, Apr 14, 2011 at 7:08 PM, OpenWrt wrote: #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with regdomain=US ---+ Reporter: vaden@… | Ow

Re: [OpenWrt-Devel] [OpenWrt] #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with regdomain=US

On Thu, Apr 14, 2011 at 7:08 PM, OpenWrt wrote: > #9207: txpower may be limited to 20 dBm on Ubiquiti M900 series with > regdomain=US > ---+ >  Reporter:  vaden@…           |       Owner:  developers >      Type:  defect    

[OpenWrt-Devel] learning moment bitte: what are the advantages of deauthenticating due to inactivity?

I ask because this STA never came back. The STA is running AirOS v3.6, which was forked so long ago that the completion of its bitrot will be announced shortly :) Said STAs are hit once every five minutes by smokeping. jv-2400-ap1/2011-04-14.log:<30>1 2011-04-14T19:25:35+00:00 jv-2400-ap1 hostap

Re: [OpenWrt-Devel] [OpenWrt-Commits] r26654 - packages/utils/hdparm

On Wed, Apr 13, 2011 at 04:38:16PM -0600, Philip Prindeville wrote: > I actually think the older description was a lot more informative. I agree. But I thought that description supposed to be like on the tools home page. I mean you should not learn how to use a tool from OpenWrt description. Or am

Re: [OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?

On 2011-04-14 5:59 PM, Larry Vaden wrote: On Thu, Apr 14, 2011 at 10:47 AM, Felix Fietkau wrote: On 2011-04-14 5:41 PM, Larry Vaden wrote: On Thu, Apr 14, 2011 at 10:25 AM, Jo-Philipp Wich wrote: I think the current situation of enforcing ETSI limits on US machines flies in the f

Re: [OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?

On Thu, Apr 14, 2011 at 10:47 AM, Felix Fietkau wrote: > On 2011-04-14 5:41 PM, Larry Vaden wrote: >> >> On Thu, Apr 14, 2011 at 10:25 AM, Jo-Philipp Wich >>  wrote:  I think the current situation of enforcing ETSI limits on US machines  flies in the face of "WIRELESS FREEDOM." >>>

Re: [OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?

On 2011-04-14 5:41 PM, Larry Vaden wrote: On Thu, Apr 14, 2011 at 10:25 AM, Jo-Philipp Wich wrote: I think the current situation of enforcing ETSI limits on US machines flies in the face of "WIRELESS FREEDOM." In the interest of collaboration Atheros specifically wants OpenWrt to not publ

Re: [OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?

On Thu, Apr 14, 2011 at 10:25 AM, Jo-Philipp Wich wrote: >> I think the current situation of enforcing ETSI limits on US machines >> flies in the face of "WIRELESS FREEDOM." > > In the interest of collaboration Atheros specifically wants OpenWrt to > not publish unregulated binaries. One prerequis

Re: [OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?

> I think the current situation of enforcing ETSI limits on US machines > flies in the face of "WIRELESS FREEDOM." In the interest of collaboration Atheros specifically wants OpenWrt to not publish unregulated binaries. One prerequisite for publishing a fully open driver was the ability to enforce

[OpenWrt-Devel] [PATCH v3 2/2] 802.1Q VLAN support for ADM6996M/ADM6996FC

This patch, when applied on top of [PATCH v3 1/2], will enable VLAN support for the ADM6996FC. It updates the whole to be identical to the patch I sent in on April 12, though that patch also includes a board fix for the Ubiquiti RouterStation PHY masks that is not here. And it was against backfire

[OpenWrt-Devel] [PATCH v3 1/2] 802.1Q VLAN support for ADM6996M/ADM6996FC

This patch adds 802.1Q VLAN support for the ADM6996M chip. The driver is loaded for both the FC and M model. It will detect which of the two chips is connected. The FC model is initialised, but no further functionality is offered. The PHY driver will always report "100 Mbit/s, link up", for both

[OpenWrt-Devel] [PATCH v3 0/2] 802.1Q VLAN support for ADM6996M/ADM6996FC

These patches add support for 802.1Q VLANs on ADM6996M and ADM6996FC. It is called version 3; version 2 wasn't explicitly called as such, but the version I sent April 3 would be it. I am submitting for inclusion in OpenWRT the driver for the M chip. Since I don't have the FC chip, I cannot test if

[OpenWrt-Devel] Shouldn't CONFIG_ATH_USER_REGD=y by default?

THANK YOU, OP! I think the current situation of enforcing ETSI limits on US machines flies in the face of "WIRELESS FREEDOM." The FCC is quite capable of enforcing the limits. e.g., see , which says, in part: [quote] We conclude that Utah Broa

Re: [OpenWrt-Devel] How to recognize if a default route is active

Il 14/04/2011 16:19, ZioPRoTo (Saverio Proto) ha scritto: in the OLSR routing protocol implementation, we have a dynamic gateway plugin. It checks (with policy routing) if connectivity with the Internet is actually working, before the router advertises a default route. this would be very useful

Re: [OpenWrt-Devel] How to recognize if a default route is active

> I have however a designed issue. At the moment a bash daemon periodically > checks if the wan interface is up. If the check is positive then the mesh > daemon > advertise this gateway, otherwise the mesh interface is set as default > route. in the OLSR routing protocol implementation, we have a

Re: [OpenWrt-Devel] How to recognize if a default route is active

Il 14/04/2011 12:03, Jo-Philipp Wich ha scritto: I'd suggest to use "ip route list exact 0.0.0.0/0" to find the device and then the find_config() shell function to map the device to an uci interface name. Thanks very much for the quick answer. I did not know about the find_config() function. How

Re: [OpenWrt-Devel] How to recognize if a default route is active

I'd suggest to use "ip route list exact 0.0.0.0/0" to find the device and then the find_config() shell function to map the device to an uci interface name. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mai

Re: [OpenWrt-Devel] How to recognize if a default route is active

Il 14/04/2011 11:17, Jo-Philipp Wich ha scritto: Hi, hi please do not do dirty hacks like relying on an interface called "wan" in your scripts. You should develop a hotplug handler which is invoked for "ifup" events on any interface. As soon as one interface appears which carries as 0/0 route,

Re: [OpenWrt-Devel] How to recognize if a default route is active

Hi, please do not do dirty hacks like relying on an interface called "wan" in your scripts. You should develop a hotplug handler which is invoked for "ifup" events on any interface. As soon as one interface appears which carries as 0/0 route, you have your "wan". See the "6in4" and "6to4" package

[OpenWrt-Devel] How to recognize if a default route is active

Hi, I've developed a routing daemon for wireless mesh networking. The package for openwrt accordingly defines a new type of protocol so that the mesh interface can be activate simply using ifup mesh (if of course a section with that name is available and properly configured in /etc/config/netwo