I have a Cisco ASA 5506-X running version 9.9(2). I recently upgraded my internet to gigabit speeds (in reality about 750 - 850 Mbps). However, my ASA was only allowing throughput of about 200Mbps. I thought that the ASA would allow throughput up to 750Mbps.
Troubleshooting steps:
Reset ASA and setup basic config.
Tested internet speed and received somewhere near 200Mbps.
Disabled FirePower service and tested speed again to get near 300Mbps
Connected PC directly to cable modem and was able to get speeds of 800Mbps - 850Mbps (three attempts).
Re-connected ASA and still get only 300Mbps (maybe 310).
Can you help me figure out why I'm not getting better throughput?
Show Version:
Cisco Adaptive Security Appliance Software Version 9.9(2)36
Firepower Extensible Operating System Version 2.3(1.122)
Device Manager Version 7.16(1)150
Compiled on Wed 12-Dec-18 16:53 PST by builders
System image file is "disk0:/asa992-36-lfbff-k8.SPA"
Config file at boot was "startup-config"
ciscoasa up 16 secs
Hardware: ASA5506, 4096 MB RAM, CPU Atom C2000 series 1250 MHz, 1 CPU (4 cores)
Internal ATA Compact Flash, 8000MB
BIOS Flash M25P64 # 0xfed01000, 16384KB
Encryption hardware device : Cisco ASA Crypto on-board accelerator (revision 0x1)
Number of accelerators: 1
1: Ext: GigabitEthernet1/1 : address is b0c5.3cfa.25d8, irq 255
2: Ext: GigabitEthernet1/2 : address is b0c5.3cfa.25d9, irq 255
3: Ext: GigabitEthernet1/3 : address is b0c5.3cfa.25da, irq 255
4: Ext: GigabitEthernet1/4 : address is b0c5.3cfa.25db, irq 255
5: Ext: GigabitEthernet1/5 : address is b0c5.3cfa.25dc, irq 255
6: Ext: GigabitEthernet1/6 : address is b0c5.3cfa.25dd, irq 255
7: Ext: GigabitEthernet1/7 : address is b0c5.3cfa.25de, irq 255
8: Ext: GigabitEthernet1/8 : address is b0c5.3cfa.25df, irq 255
9: Int: Internal-Data1/1 : address is b0c5.3cfa.25d7, irq 255
10: Int: Internal-Data1/2 : address is 0000.0001.0002, irq 0
11: Int: Internal-Control1/1 : address is 0000.0001.0001, irq 0
12: Int: Internal-Data1/3 : address is 0000.0001.0003, irq 0
13: Ext: Management1/1 : address is b0c5.3cfa.25d7, irq 0
14: Int: Internal-Data1/4 : address is 0000.0100.0001, irq 0
Licensed features for this platform:
Maximum Physical Interfaces : Unlimited perpetual
Maximum VLANs : 30 perpetual
Inside Hosts : Unlimited perpetual
Failover : Active/Standby perpetual
Encryption-DES : Enabled perpetual
Encryption-3DES-AES : Enabled perpetual
Carrier : Disabled perpetual
AnyConnect Premium Peers : 4 perpetual
AnyConnect Essentials : Disabled perpetual
Other VPN Peers : 50 perpetual
Total VPN Peers : 50 perpetual
AnyConnect for Mobile : Disabled perpetual
AnyConnect for Cisco VPN Phone : Disabled perpetual
Advanced Endpoint Assessment : Disabled perpetual
Shared License : Disabled perpetual
Total TLS Proxy Sessions : 160 perpetual
Botnet Traffic Filter : Disabled perpetual
Cluster : Disabled perpetual
This platform has an ASA 5506 Security Plus license.
Serial Number: JXXXXXXXXXX
Running Permanent Activation Key: 0x1A1A1A1A 0x2B2B2B2B 0x3C3C3C3C 0x4D4D4D4D 0x5E5E5E5E
Configuration register is 0x1
Image type : Release
Key Version : A
Configuration has not been modified since last system restart.
Config
ASA Version 9.9(2)36
!
hostname ciscoasa
enable password xxxxxxxxxxxxxxxxxxxxxxx pbkdf2
passwd xxxxxxxxxxxx. encrypted
names
!
interface GigabitEthernet1/1
nameif outside
security-level 0
ip address dhcp setroute
!
interface GigabitEthernet1/2
nameif inside
security-level 100
ip address 172.16.254.1 255.255.255.0
!
interface GigabitEthernet1/3
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1/4
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1/5
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1/6
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1/7
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet1/8
shutdown
no nameif
no security-level
no ip address
!
interface Management1/1
management-only
shutdown
no nameif
no security-level
no ip address
!
ftp mode passive
access-list INBOUND extended permit icmp any any echo-reply
pager lines 24
mtu outside 1500
mtu inside 1500
no failover
no monitor-interface service-module
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
no arp permit-nonconnected
arp rate-limit 16384
!
nat (inside,outside) after-auto source dynamic any interface
access-group INBOUND in interface outside
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 sctp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
timeout conn-holddown 0:00:15
timeout igp stale-route 0:01:10
user-identity default-domain LOCAL
aaa authentication ssh console LOCAL
aaa authentication login-history
no snmp-server location
no snmp-server contact
service sw-reset-button
crypto ipsec security-association pmtu-aging infinite
crypto ca trustpool policy
telnet timeout 5
ssh stricthostkeycheck
ssh 172.16.254.0 255.255.255.0 inside
ssh timeout 30
ssh version 2
ssh key-exchange group dh-group1-sha1
console timeout 0
dhcpd dns <my ISP DNS server 1> <my ISP DNS server 2>
dhcpd option 3 ip 172.16.254.1
!
dhcpd address 172.16.254.33-172.16.254.221 inside
dhcpd enable inside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
dynamic-access-policy-record DfltAccessPolicy
username myuser password xxxxxxxxxxxx pbkdf2
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
policy-map global_policy
class inspection_default
inspect ftp
inspect h323 h225
inspect h323 ras
inspect ip-options
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
inspect dns preset_dns_map
policy-map type inspect dns migrated_dns_map_2
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
policy-map type inspect dns migrated_dns_map_1
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
!
service-policy global_policy global
prompt hostname context
no call-home reporting anonymous
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome#cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:7bf6464dd03896f00321926e98426397
what is the CPU usage ?
also post here show interface gi1/1
Also try configuring manually on outside duplex full and speed auto or speed 1000
but before doing that post the stats of the outside interface first
Related
I connected the MHz19 sensor to the D1 mini and want to flash it via ESP-Home.
I followed the following guide:
https://esphome.io/components/sensor/mhz19.html
I used the code
esphome:
name: co2-sensor
esp8266:
board: esp01_1m
# Enable logging
#logger:
# Enable Home Assistant API
api:
ota:
password: "xxxxxx"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Co2-Sensor Fallback Hotspot"
password: "xxxxx"
captive_portal:
uart:
rx_pin: GPIO3
tx_pin: GPIO1
baud_rate: 9600
sensor:
- platform: mhz19
co2:
name: "CO2 Value"
temperature:
name: "MH-Z19 Temperature"
update_interval: 60s
automatic_baseline_calibration: false
But cannot flash, I get the following error
======================== [SUCCESS] Took 305.85 seconds ========================
INFO Successfully compiled program.
esptool.py v3.2
Serial port /dev/ttyUSB0
Connecting......................................
A fatal error occurred: Failed to connect to ESP8266: No serial data received.
For troubleshooting steps visit: https://github.com/espressif/esptool#troubleshooting
INFO Upload with baud rate 460800 failed. Trying again with baud rate 115200.
esptool.py v3.2
Serial port /dev/ttyUSB0
Connecting......................................
A fatal error occurred: Failed to connect to ESP8266: No serial data received.
For troubleshooting steps visit: https://github.com/espressif/esptool#troubleshooting
I can however flash it and it comes online if I disconnect the sensor, of course it publishes no data. So I assume it's something to do with UART. I also tried disabling the logging, which did nothing.
It seems the UART pins used by default for debug logging, even though I thought I had disabled the logging option. I used pin 4 and 5 and it worked.
https://esphome.io/components/uart.html#uart
Note that the value I got was 5000 ppm at first, when it was plugged into the Pi on which I'm running HA. When connecting to another PSU I got 'normal' looking values. I assume it simply did not get enough power from the PI.
i have created a linux tun interface, set ipaddr, broadcast etc.. using open/ioctl apis.
This is how the tun interface looks like,
TEST_TUN: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 45.45.45.1/24 scope global TEST_TUN
valid_lft forever preferred_lft forever
Any message written by a virtual host(binded on addr 45.45.45.1:udp=7070) is received by tun_fd(fd returned during tun device creation).
If tun_fd writes an msg ( IP(dst=45.45.45.1)+transport(udp_dst=7070)+payload) is not received on the virtual host. wireshark capture shows that the packet is being received on the kernel side, but virtual host doesnot received any packet.
what could be the reasons for kernel not forwarding the packet to virtual host ?
Had turned your tun device in up state?
if not then you can simply do that via..
$sudo ifconfig tun0 up
and you also can do that via ioctle commands..
if your device is already in a up state then you linux destro must have forwarding on..
you can do this via..
#echo "1" > /proc/sys/net/ipv4/ip_forwarding
or
$sudo sysctl net.ipv4.ip_forward=1
$sudo sysctl -p
then it comes to routing rules..you must have to set routing rule so that all the traffic is captured via your virtual interface..
$sudo ip route 128/1 dev tun
this command will add a route in you kernel routing table and all the traffic will flow through your virtual interface..
If I understood you correctly then may be this will be helpful for you..
What is the purpose of the "destination address" for a TAP/TUN device?
Pytun lets you easily set parameters of a tap/tun device:
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.1'
tun.dstaddr = '10.66.66.2'
tun.netmask = '255.255.255.0'
tun.up()
Doing this will result in a device configured as such:
$ ifconfig mytun
mytun: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.66.66.1 netmask 255.255.255.0 destination 10.66.66.2
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I understand that the system now has a virtual interface with IP 10.66.66.1. And it's presumable that in this scenario, the TUN device would be "connected" to a (e.g. VPN gateway) device whose IP address is 10.66.66.2.
But what purpose specifically, does it serve for the kernel to know that this is a "point-to-point" interface, and the IP address of the destination? Does it impact routing in some way that simply configuring the route table would not achieve?
Setting the dstaddr property results in a SIOCSIFDSTADDR ioctl.
The netdevice(7) man page simply says:
SIOCGIFDSTADDR, SIOCSIFDSTADDR
Get or set the destination address of a point-to-point device
using ifr_dstaddr. For compatibility, only AF_INET addresses
are accepted or returned. Setting the destination address is
a privileged operation.
I don't care about all this I want to configure my interface
You don't need to set a destination address. If you want to configure 10.66.66.1/24 on the interface, you can do:
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.1'
tun.netmask = '255.255.255.0'
tun.up()
This interface only connects two hosts, so you don't actually need a whole /24. You can only say that 10.66.66.1 is connected to 10.66.66.2 (10.66.66.1 peer 10.66.66.2):
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.1'
tun.dstaddr = '10.66.66.2'
tun.netmask = '255.255.255.255'
tun.up()
In this setup, the two IP addresses do not need to be in the same range at all.
Alternatively, you could use a /31, RFC3021:
tun = TapTunDevice(name='mytun')
tun.addr = '10.66.66.2'
tun.dstaddr = '10.66.66.3'
tun.netmask = '255.255.255.254'
tun.up()
Notice, how I had to change the IP addresses in order for them to be in the same /31.
What is a POINTOPOINT device?
The POINTOPOINT means that on this interface there is no Layer 2 addressing (no MAC address) on this interface:
no ARP requests (IPv4);
no NDP requests (IPv6);
the neighbour table is useless for this interface (ip neighbour);
in routing table entries for this interface the via directive is ignored;
packets on this interface are always send to the same (only) next-hop.
Examples of POINTOPOINT devices
PPP interfaces: There is not Layer 2 address for PPP as this type of interface connects a single host to another host (hence the name "point-to-point protocol")
TUN interfaces: They are IP only interfaces without a Layer 2.
POINTOPOINT means that this is a point-to-point interface (surprise!) which means that there can be only one peer connected at the other-side of the interface: you have one neighbor on this interface and you do not need to use ARP/NDP for mapping IP address to link-layer address (and you do not have link layer address at all).
In contrast, an Ethernet device is not a point-to-point interface because multiple hosts can be directly reacheable via this interface. When you send an IP packet to such a device, the network stack has to find a layer 2 identifier (using ARP, NDP) for the intended IP address and send the message to this link-layer address.
Say this, is your routing table (in Ethernet):
default via 192.0.2.1 dev eth0 proto static metric 100
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.2 metric 100
Multiple hosts can be directly connected to you via the eth0 interface. If you want to send a packet to 198.51.100.1, this route is selected:
default via 192.0.2.1 dev eth0 proto static metric 100
which means that among all your neighbors on the eth0 device, you have to send the packet to 192.0.2.1. In order to to that, your network stack has to find the MAC address of 192.0.2.1 by using ARP.
On a POINTOPOINT device, there is always only one neighbor so you don't need to do ARP, you only need to send the packet.
TUN and PPP interfaces are POINTOPOINT devices. Ethernet, Ethernet TAP devices and Wifi interfaces are not POINTOPOINT.
What is the destination (peer) address?
Usually the IP configuration of an interface is in the form: 192.0.2.1/24. This means that the ip address of this interface is 192.0.2.1 and that all IP in the 192.0.2.0/24 subnet are directly reachable via this interface: this adds a routing rule 192.0.2.0/24 dev tun0.
The Linux kernel supports another type of configuration when the local IP address and the peer address does not belong to the same IP subnet: 192.0.2.1 peer 198.51.100.1. This means that the IP address of this interface is 192.0.2.1 and that the IP address of the peer is 198.51.100.1: this adds a routing rule 198.51.100.1 dev tun0. A more general form can be used: 192.0.2.1 peer 198.51.100.1/24.
$ ip address show tun0
14: tun0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 192.0.2.1 198.51.100.1/24 scope global tun0
valid_lft forever preferred_lft forever
The dstaddr parameter (and the SIOCSIFDSTADDR) can be used to set such as destination address.
This is useful if you don't want to allocate a common subnet for the two peers. You don't have to use a special destination address with point to point interface. You could use a standard IP subnet. Or you could allocate a /31. Using the destination address/peer configuration, you can avoid allocating a subnet for this point-to-point link.
What is the relation between the peer/destination address and POINTOPOINT devices?
These are independant. You don't have top set a destination address on a POINTOPOINT interface. You can set a destination address on a POINTOPOINT and you can do it on a normal one as well.
However, using a peer destination address is especially/mostly useful for POINTOPOINT interfaces.
If you add an interface with
inet 10.66.66.1 netmask 255.255.255.0
No matter if you create it as point to point, or not- a new routing entry will be added to the kernel for 10.66.66.1/24 with destination of the new interface.
So I don't think that there is a difference there.
As a stop-gap until Google supports native IPv6 on Google Compute Engine, I'd like to configure a 6in4 (IP protocol 41) tunnel.
I added a firewall rule to allow protocol 41 on my VM's network:
Name Source tag / IP range Allowed protocols / ports Target tags
allow-6in4 216.66.xxx.xxx 41 Apply to all targets
And configured the tunnel in /etc/network/interfaces:
auto 6in4
iface 6in4 inet6 v4tunnel
address 2001:470:xxxx:xxxx::2
netmask 64
endpoint 216.66.xxx.xxx
gateway 2001:470:xxxx:xxxx::1
ttl 64
up ip link set mtu 1280 dev $IFACE
And ping6 2001:470:xxxx:xxxx::1 and verified that 6in4 traffic was outbound:
$ sudo tcpdump -pni eth0 host 216.66.xxx.xxx
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:52:03.732841 IP 10.240.xxx.xxx > 216.66.xxx.xxx: IP6 2001:470:xxxx:xxxx::2 > 2001:470:xxxx:xxxx::1: ICMP6, echo request, seq 1, length 64
22:52:04.740726 IP 10.240.xxx.xxx > 216.66.xxx.xxx: IP6 2001:470:xxxx:xxxx::2 > 2001:470:xxxx:xxxx::1: ICMP6, echo request, seq 2, length 64
22:52:05.748690 IP 10.240.xxx.xxx > 216.66.xxx.xxx: IP6 2001:470:xxxx:xxxx::2 > 2001:470:xxxx:xxxx::1: ICMP6, echo request, seq 3, length 64
I changed the endpoint temporarily to an address where I can run tcpdump, and confirmed that packets are not arriving at the destination. I even tried NAT myself in case GCE wasn't doing this for 6in4 packets, but no luck (iptables -t nat -A POSTROUTING -p ipv6 -j SNAT --to-source 130.211.xxx.xxx).
Has anyone gotten a 6in4 tunnel to work on a GCE VM? Is there some magic setting I missed somewhere?
TL;DR: You can't.
Per Networking and Firewalls:
Traffic that uses a protocol other than TCP, UDP, and ICMP is blocked, unless explicitly allowed through Protocol Forwarding.
Per Protocol Forwarding:
Google Compute Engine supports protocol forwarding for the following
protocols:
AH: Specifies the IP Authentication Header protocol.
ESP: Specifies the IP Encapsulating Security Payload protocol.
SCTP: Specifies the Stream Control Transmission Protocol.
TCP: Specifies the Transmission Control Protocol.
UDP: Specifies the User Datagram Protocol.
Hence, a Protocol Forwarding rule needs to be for one of the following IP protocol numbers:
51 (AH)
50 (ESP)
132 (SCTP)
6 (TCP)
17 (UDP)
The Protocol Forwarding page makes it clear that other protocol numbers, such as 41 (6in4) are not supported:
Note: This is an exhaustive list of supported protocols. Only protocols that appear here are supported for protocol forwarding.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I've been installing multiple versions of ubunutu over years and now I better understand why I faced always problems with wifi configuration on these different baselines : Debian root of course.
Issue
Now on Debian 7.4 :
The Broadcom BCM4313 driver is not loaded by default (not free product) for my wifi card. This is stated thru the UNCLAIMED declaration when looking at the network hardware status excerpt :
sudo lshw -c network
*-network UNCLAIMED
description: Network controller
product: BCM4313 802.11b/g/n Wireless LAN Controller
vendor: Broadcom Corporation
physical id: 0
bus info: pci#0000:03:00.0
version: 01
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress cap_list
configuration: latency=0
resources: memory:f1100000-f1103fff
Unclaimed means : no driver found (no kernel association)
So I installed the driver located in the non-free backports by adding this target into the local packages repository /etc/apt/sources.list
deb http://http.debian.net/debian/ wheezy main contrib non-free
and install :
sudo apt-get update && sudo apt-get install firmware-brcm80211
sudo modprobe brcm80211
and restart
sudo shutdown now -r
Check seems OK :
sudo lshw -c network
*-network
description: Wireless interface
product: BCM4313 802.11b/g/n Wireless LAN Controller
vendor: Broadcom Corporation
physical id: 0
bus info: pci#0000:03:00.0
logical name: wlan0
version: 01
serial: 78:e4:00:4e:49:a3
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=brcmsmac driverversion=3.2.0-4-amd64 firmware=N/A latency=0 link=no multicast=yes wireless=IEEE 802.11bgn
resources: irq:19 memory:f1100000-f1103fff
Network Configuration
minimal /etc/network/interfaces as required by NetworManager
auto lo
iface lo inet loopback
.. and restart
Failure
No wifi network is detected and of course I can't connect using wlan0
it doesn't work.
I found informations here regarding WPA2/PSK wifi configuration on debian :
http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_wireless_lan_interface_with_wpa_wpa2
so I added this setup to my interfaces file an got :
auto lo
iface lo inet loopback
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid Hznteam-Datacenter
# hexadecimal psk is encoded from a plaintext passphrase
wpa-psk 12345678901234567890123456
Same as above no wifi network detected and ifconfig gives no allocated ip address :
wlan0 Link encap:Ethernet HWaddr 78:e4:00:4e:49:a3
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0:avahi Link encap:Ethernet HWaddr 78:e4:00:4e:49:a3
inet addr:169.254.7.34 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
Note that my required WPA2/PSK AES key length is 26 chars as requested on my other PC that connect successfully to my wifi router
Any idea ? it's boring wasting hours on the same problem again ..
Help welcome ...
Wrong wifi kernel module selected
I should have installed the brcmsmac module instead of the brcm80211 one. The latter is the Squeeze version kernel module. Wheezy needs the brcmsmac module as mentioned here
Althouhg the package is named brcm80211 the kernel module to load for Wheezy is brcmsmac instead of brcm80211 for the Squeeze version
more detail in this StackoverFlow post and a summary is also available here
Interfaces
I also set the /etc/network/interfaces conf file to only
$ sudo nano /etc/network/interfaces
auto lo
iface lo inet loopback
this seems to allow Network-Manager to take any discovered interfaces in account.
Everything's OK. Wifi up and running now.
.. And so much wasted time for a stupid version error !