| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
space, so a default route of ::/0 is more correct. Thanks Dave Taht
SVN-Revision: 26857
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reading of the PHY registers occasionally returns with bogus values
under heavy load. This misleads the PHY driver and thus causes false
link/speed change notifications which leads to performance loss.
This is easily noticable during an iperf session:
...
[ 3] 52.0-53.0 sec 11.3 MBytes 94.4 Mbits/sec
[ 3] 53.0-54.0 sec 11.4 MBytes 95.4 Mbits/sec
eth1: link down
br-lan: port 2(eth1) entering forwarding state
eth1: link up (100Mbps/Full duplex)
br-lan: port 2(eth1) entering forwarding state
br-lan: port 2(eth1) entering forwarding state
[ 3] 54.0-55.0 sec 6.75 MBytes 56.6 Mbits/sec
[ 3] 55.0-56.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 56.0-57.0 sec 10.5 MBytes 88.1 Mbits/sec
...
[ 3] 169.0-170.0 sec 11.4 MBytes 95.4 Mbits/sec
[ 3] 170.0-171.0 sec 11.4 MBytes 95.4 Mbits/sec
eth1: link up (10Mbps/Half duplex)
[ 3] 171.0-172.0 sec 7.63 MBytes 64.0 Mbits/sec
[ 3] 172.0-173.0 sec 9.38 MBytes 78.6 Mbits/sec
eth1: link up (100Mbps/Full duplex)
[ 3] 173.0-174.0 sec 11.3 MBytes 94.4 Mbits/sec
[ 3] 174.0-175.0 sec 11.4 MBytes 95.4 Mbits/sec
SVN-Revision: 26856
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function __devinit ag71xx_probe() references
a function __devexit ag71xx_phy_disconnect().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
ag71xx_phy_disconnect() so it may be used outside an exit section.
The function ag71xx_phy_disconnect() references a function in an exit
section.
Often the function ag71xx_ar7240_cleanup() has valid usage outside the
exit section
and the fix is to remove the __devexit annotation of
ag71xx_ar7240_cleanup.
SVN-Revision: 26855
|
|
|
|
| |
SVN-Revision: 26854
|
|
|
|
|
|
| |
usb_modeswitch on boot and possibly others (#9352)
SVN-Revision: 26848
|
|
|
|
| |
SVN-Revision: 26846
|
|
|
|
| |
SVN-Revision: 26845
|
|
|
|
| |
SVN-Revision: 26844
|
|
|
|
| |
SVN-Revision: 26843
|
|
|
|
| |
SVN-Revision: 26842
|
|
|
|
| |
SVN-Revision: 26841
|
|
|
|
| |
SVN-Revision: 26840
|
|
|
|
| |
SVN-Revision: 26837
|
|
|
|
| |
SVN-Revision: 26836
|
|
|
|
| |
SVN-Revision: 26833
|
|
|
|
| |
SVN-Revision: 26832
|
|
|
|
|
|
| |
sprom data from the platform device to the correct pointer.
SVN-Revision: 26829
|
|
|
|
| |
SVN-Revision: 26828
|
|
|
|
| |
SVN-Revision: 26827
|
|
|
|
| |
SVN-Revision: 26822
|
|
|
|
| |
SVN-Revision: 26819
|
|
|
|
| |
SVN-Revision: 26818
|
|
|
|
| |
SVN-Revision: 26817
|
|
|
|
| |
SVN-Revision: 26816
|
|
|
|
| |
SVN-Revision: 26815
|
|
|
|
|
|
|
|
| |
unprovided kernel crypto modules that are useful for IPSEC. This is an alternative to breaking these modules out into kmod-crypto-wq (crypto_wq.ko), kmod-crypto-rng (rng.ko and krng.ko), and kmod-crypto-iv (eseqiv.ko and chainiv.ko).
Signed-off-by: Lars Hjersted <lars@hjersted.com>
SVN-Revision: 26814
|
|
|
|
|
|
|
|
| |
kmod-ipsec. Also remove the extraneous kmod-crypto-core dependency to eliminate recursion.
Signed-off-by: Lars Hjersted <lars@hjersted.com>
SVN-Revision: 26813
|
|
|
|
|
|
|
|
|
|
|
|
| |
kmod-crypto-rng, and kmod-crypto-iv packages. These packages provide some missing kernel crypto modules which are required for IPSEC. The strongswan4, ipsec-tools, and possibly other IPSEC packages do not work properly without these modules.
NOTE: The KCONFIG associated with each of these modules gets selected
whenever CRYPTO_MANAGER (kmod-crypto-manager) is selected so these
modules are already being built.
Signed-off-by: Lars Hjersted <lars@hjersted.com>
SVN-Revision: 26812
|
|
|
|
|
|
| |
unneeded on the Geos platform.
SVN-Revision: 26811
|
|
|
|
|
|
| |
deadlocks
SVN-Revision: 26810
|
|
|
|
| |
SVN-Revision: 26809
|
|
|
|
| |
SVN-Revision: 26808
|
|
|
|
| |
SVN-Revision: 26807
|
|
|
|
| |
SVN-Revision: 26806
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
passthrough Two examples of potentially useful configurations (commented out, of course):
(a) map the ssh service running on the firewall to 22001 externally, without modifying the configuration of the daemon itself. this allows port 22 on the WAN side to then be port-forwarded to a
LAN-based machine if desired, or if not, simply obscures the port from external attack.
(b) allow IPsec/ESP and ISAKMP (UDP-based key exchange) to happen by default. useful for most modern VPN clients you might have on your WAN.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
SVN-Revision: 26805
|
|
|
|
|
|
| |
(standard in Debian). The modified patch reflects the current upstream: http://git.savannah.gnu.org/cgit/quilt.git/commit/?id=38df0b210c3df67f3e784af92232ae1946b98ecd
SVN-Revision: 26804
|
|
|
|
| |
SVN-Revision: 26803
|
|
|
|
|
|
| |
ethernet driver
SVN-Revision: 26802
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there is no sprom on an ssb based pci device on the brcm47xx
architecture ssb now asks the architecture code to look into the nvram
to get some sprom data for this device. Now we are able to read out
pci/1/1/ foo or pci/1/3/ foo config options.
This will fix some problems where the wireless devices does not got an
mac address and the following message was show:
ssb: WARNING: Invalid SPROM CRC (corrupt SPROM)
SVN-Revision: 26801
|
|
|
|
| |
SVN-Revision: 26798
|
|
|
|
|
|
| |
- fixes some issues with ath9k
SVN-Revision: 26797
|
|
|
|
|
|
| |
to fix connection hangs on some devices
SVN-Revision: 26795
|
|
|
|
| |
SVN-Revision: 26785
|
|
|
|
| |
SVN-Revision: 26781
|
|
|
|
|
|
| |
default network config
SVN-Revision: 26779
|
|
|
|
| |
SVN-Revision: 26778
|
|
|
|
| |
SVN-Revision: 26777
|
|
|
|
| |
SVN-Revision: 26776
|
|
|
|
| |
SVN-Revision: 26773
|
|
|
|
| |
SVN-Revision: 26772
|