Malformed packets

Hi,
Thanks in advance for your help.
Let me describe the issue briefly.
-Our system is configured with Video Streamer (winsend on PC),
Cisco 7609 and DSLAM with ATM traffic.
-Video streamer is connected to Cisco 7609 FE port.
-The video traffic is routed to ATM port and distributed to DSLAM.
-I could see that the video traffic is forwarded to ATM side but for some reason the packet is malformed and could not see
the video on ATM side.
I am connecting the routers the following way:
The DSLAM is connected to the 7609.
FE ATM
PC (winsend)------Cisco 7500--------DSLAM-----DSL
|
|
PC (winsend)------Cisco 7609------------+
FE ATM
-I also ran video traffic from Cisco 7500 to Cisco 7609.
The video traffic comming from Cisco 7500 works fine. (video stream is created winsend as well). The above problem happens only on video origninating from Cisco 7609.
-I Captured the video traffic on ATM by ethereal, noticed followings.
-Video traffic through Cisco 7500 is working fine, I could see Source and Destiation with proper IP address. Protocol shows UDP properly.
-Video traffic originating on Cisco 7609 has packet malformed.
The sniffer (Ethereal) showed the packet in strange status. Source and Destination shows MAC address, Protocol shows it as "0x1f64" which is not understandable.
I would appreciate any input.

correction on packet count - 200+ malformed out of 20k total packets
captured.
>>> On 12/17/2009 at 10:10 AM, Mysterious<[email protected]> wrote:
> On 12/17/2009 05:09 PM, John wrote:
>> some packet examples
>>
>> 3770 7.278536 00.00.00 04.00.00 FC Unknown frame[Malformed Packet]
>> Ethernet II, Src: 00:00:00_00:40:00 (00:00:00:00:40:00), Dst:
>> 20:00:00:00:8b:72 (20:00:00:00:8b:72)
>>
>> 4933 8.959812 00.00.00 31.00.00 FC Unknown frame[Malformed Packet]
>> Ethernet II, Src: 00:00:00_00:40:00 (00:00:00:00:40:00), Dst:
>> 20:00:00:00:b7:81 (20:00:00:00:b7:81)
>>
>> 9441 13.559633 72.82.b8 20.00.1b FC Unknown frame[Malformed Packet]
>> Ethernet II, Src: 00:00:00_00:40:00 (00:00:00:00:40:00), Dst:
>> 00:00:00_00:8b:63 (00:00:00:00:8b:63)
>>
>> 9443 13.559657 72.82.b8 07.00.1b FC Unknown frame[Malformed Packet]
>> Ethernet II, Src: 00:00:00_00:40:00 (00:00:00:00:40:00), Dst:
>> 00:00:00_00:96:41 (00:00:00:00:96:41)
>
> does your server use the bx2.lan driver?

Similar Messages

  • Malformed packets - slow web page loading

    I'm running bm3.9 sp2 with some post bm sp2 files as provided by Novell
    support on a nw6.5 server.
    I've noticed that on IE and Fireforx browsers, that web pages will often
    take a long time to load and typically if I hit the 'stop' button on the
    browser and do a 'reload' or 'refresh' for that web page, it will
    immediately load fine.
    I've been looking at the tcp stats but don't notice anything strange there.
    I ran pktscan and the only thing standing out is about 200+ malformed
    packets out of about 3000 packets. I've run pktscan a few different times on
    different days and still noticing these malformed packets.
    I was wondering if this could be a problem or any other suggestions on what
    to look at.
    TIA

    correction on packet count - 200+ malformed out of 20k total packets
    captured.
    >>> On 12/17/2009 at 10:10 AM, Mysterious<[email protected]> wrote:
    > On 12/17/2009 05:09 PM, John wrote:
    >> some packet examples
    >>
    >> 3770 7.278536 00.00.00 04.00.00 FC Unknown frame[Malformed Packet]
    >> Ethernet II, Src: 00:00:00_00:40:00 (00:00:00:00:40:00), Dst:
    >> 20:00:00:00:8b:72 (20:00:00:00:8b:72)
    >>
    >> 4933 8.959812 00.00.00 31.00.00 FC Unknown frame[Malformed Packet]
    >> Ethernet II, Src: 00:00:00_00:40:00 (00:00:00:00:40:00), Dst:
    >> 20:00:00:00:b7:81 (20:00:00:00:b7:81)
    >>
    >> 9441 13.559633 72.82.b8 20.00.1b FC Unknown frame[Malformed Packet]
    >> Ethernet II, Src: 00:00:00_00:40:00 (00:00:00:00:40:00), Dst:
    >> 00:00:00_00:8b:63 (00:00:00:00:8b:63)
    >>
    >> 9443 13.559657 72.82.b8 07.00.1b FC Unknown frame[Malformed Packet]
    >> Ethernet II, Src: 00:00:00_00:40:00 (00:00:00:00:40:00), Dst:
    >> 00:00:00_00:96:41 (00:00:00:00:96:41)
    >
    > does your server use the bx2.lan driver?

  • SSID=Broadcast Malformed Packet cause switch CPU increase 90 %

    I have a Wirelles LAN composed of 4 WISM controllers mounted on 2 6513 catalyst . On the ACCESS switch I can see a lot of abnormal traffic that are in use in the port . After sniffing this traffic I have clear that was WIRELESS broacast traffic in particular : SSID=Broadcast Malformed Packet.
    How to reduce this traffic ? I have to proceed in the WISM or just cut all the broacast strom over the switch ?
    thank for any help

    For that do disable the broadcast SSID. It may help you .

  • Cisco 7960G malformed packets

    I have two 7960G phones which were using SCCP
    I have just upgraded them to POS3-05-3-00 to work for SIP
    SInce upgrading both phones are now sending malformed packets and a wireshark trace show no checksum on the packet.
    Can anyone suggest how I might change the firmware as TFTP is the only option, currently using 3CDeamon.
    Thanks
    John

    hello - I have just moved your post to the Topic forums - you had posted your question in an obscure, non-visible, promotional community.  Hopefully our community users will see your question now.

  • Malformed packets found in packet captures

    While running a packet capture I noticed SEVERAL lines with Malformed Packets. The line contained the MACs of the laptop and AP that the laptop was connected.
    Is this something I should worry about or what is going on here?
    I added a print shot of the packet capture if that helps.
    Thank you, Gary

    The malformed packets aren't LWAPP but seen in IEEE's association request packet.These messages aren't bad. All it is is that Ethereal could not fully decode the content of the packet because there wasn't enough information in it to decode.As these messages are sent from wireless clients to AP, as long as the clients are able to associate, shouldn't be a concern.

  • Malformed Packets and Bad Checksums

    ..I have a customer who uses MPLS to connect to all remote locations. The MPLS carrier has recently merged with another carrier, and they are in the middle of making changes to their MPLS network(s). As a result, some (but not all) of my customer's sites that have gone through these changes are having problems with one particular application only. Wireshark packet captures at the remote location and at the affected application server shows the following, among other things:
    - Bad IP Checksum
    - Malformed TDS Packets
    - Malformed SSL Packets
    - Malformed GSM over IP Packets
    - Malformed ASAP Packets
    - TCP Sequence out of order
    - ACKed lost TCP segment
    - Previous TCP segment lost
    - Fast TCP retransmission suspected
    This is only a subset of the problems that Wireshark shows. The strange thing is that only a subset of the remote sites are affected, and it really is only one particular application of a large suite of applications. All other applications work acceptably. In addition, other sites that have been converted work just fine as well. There are about 15 of 80 sites having thus problem. The MPLS provider of have reviewed their equipment and configurations. Unfortunately, after the changes were made, we have no visibility into the MPLS network (it just shows one hop), so I have no way of helping them to troubleshoot.
    We have the ability to test the application using a site that is connected via Fiber, and the application works just fine. Of course, we have moved PCs, etc from site to site. The problem seems to stay with the site, rather than the computers.
    Any advice or ideas on what I can do to test would be appreciated.
    Sent from Cisco Technical Support iPad App

    Jason,
    there is lot of interesting troubleshooting to be done  Yours is the type of case I loved when I was in the TAC as I enjoyed using creative ways to investigate and tackle similar problems.
    there might be so many approaches for this that I have difficulties to list them all.
    I am afraid that a CSC post is not the right place for that as this can be time comsuming and lot of effort is needed.
    I suggest you to open a TAC case where you can find some engineer with the right mind set for this CSI type of troubleshooting.
    cheers,
    Riccardo

  • 6509 SYS-4-SUPERVISOR_ERR: How can I trace to a port ?

    Hi, I seeing these errors daily on one of my 6509's
    SYS-4-SUPERVISOR_ERR:
    Forwarding engine IP length error counter = 93
    This is caused by a malformed packet from a bad nic or app etc being dropped by the supervisor.
    My question is how can I troubleshoot this, I mean how can I catch it with a sniffer. I have alot of ports on the 6509.
    I do have a Cisco Nam-1 in the 6509, if there's something I could do with that then any pointers would help.
    I just can't think how I can isolate this to the port / nic that's causing the problem.
    Thanks for any ideas

    hi
    Do check this note taken from CCO..
    %SYS-4-SUPERVISOR_ERR:
    Problem
    These error messages appear in the syslog:
    %SYS-4-SUPERVISOR_ERR:Forwarding engine IP length error counter =4
    %SYS-4-SUPERVISOR_ERR:Forwarding engine IP too short error counter =1
    %SYS-4-SUPERVISOR_ERR:Forwarding engine IP check sum error counter = 38 Description
    These messages indicate that the switch forwarding engine receives an IP packet of a length that is less than the minimum allowed length and then drops the packet. In code versions that are earlier than 7.x, the forwarding engine silently drops the packet and counts the packet in the forwarding engine statistics. In code versions that are 7.x or later, this message is recorded in the syslog once every 30 minutes.
    There is no effect on the switch side. The switch side drops the bad packet, which the receiving device would have dropped consequently. The only concern is that there is a device that sends bad packets. The possible causes include a bad NIC driver, a NIC driver bug, or a bad application. The Supervisor Engine does not keep track of the source IP address of the device that sends the bad packets. The only way to detect these devices is to use a sniffer in order to track down the source address.
    This message is only an informational message and warning from the switch. Issue the set errordetection portcounters disable command on the switch in order to disable these error messages.
    regds

  • RV180W - problem with connection

    Hi,
    recently we bought RV180W router to replace our old zyxell. We are small company with about 10-15 workstations and maybe 10 wifi devices. We have DSL modem with 20/5mbit/s internet connection. 
    Problem that we have concern a connection quality. The connection is really slow and usually we have a problem on opening single web page. Sometimes it loads without problems, next time it doesn't load at all.
    It seems like number of connection per client is too low but on settings it's set-up at 128 (Maximum Unidentified Sessions). In these moments it's also difficult to open administrator interface. Maybe it's a memory problem?
    We turned off all advanced functionalities (VPN, firewall filtering, logging, ecc) but without any improvements.
    Any suggestions, ideas? Maybe it's hardware problem (memory?) but how to check that?

    Hello Ricardo,
    Do both of your RV routers have public IPs on their WAN interfaces?  Because if not you are going to have a bit of trouble getting this working.
    I know you said you put the RVs int he DMZ, but that is not the same as bridging the modem and putting the public IP directly on our device.  The routers use the WAN IP to identify themselves and communicate, so with private address that process is usually messed up.
    A payload malform could also just be a mismatch in configuration somewhere, make sure all of your encryption settings match.  I have also seen an incorrect MTU size cause malformed packets.
    However, the biggest thing would be making sure the public IP is on the WAN of the RVs, I wouldn't look into anything else until that is done.
    Hope that helps some,
    Christopher Ebert - Advanced Network Support Engineer
    Cisco Small Business Support Center
    *please rate helpful posts*

  • Sync with iCloud while charging crashes WiFi

    When i try to sync to iCloud while charging my iPhone 5 my WiFi goes down, not the phone but the router. After restarting the router it works again. Syncing manually while running phone on battery and wifi everyting works fine. Anyone else got this problem? Discoverd this because phone hadn't made any nightly backups for two weeks. Thats when i installed iOS 8.

    Gee, why didn't I think of that?  For those that may be keeping track this is a dlink Dir-655 (ON LATEST FIRMWARE). 
    I had no problems with my iPhone 5.  I have no problems with my iPhone 6 EXCEPT when I let the phone attempt a full iCloud backup.  I don't know what encryption or protocol this fires up but whatever it is it crashes the router.  I am hoping others with router crashing can benefit. The seemingly random crashing some have may be when the phone attempts a backup. 
    Because i use I jumped phones and iOS versions at the same time I don't know for sure which is to blame but I suspect it is the iOS creating malformed packets. My router wont packet capture and I don't have $2000 for a wifi N capture adapter. So there is not much more troubleshooting I can do. 
    MY Apple fanboy co-workers have airports and don't have iphone connectivity issues. so maybe routers do need to catch up with some wonky thing Apple is doing. I am not against buying a new router if I knew it would fix the issue but I don't have spare cash to spend right now just to make the attempt. If a new router doesn't help I will have spent money for nothing on a non-returnable item.

  • EAP-TLS authentication failure

    We've been struggling with this problem for weeks without a solution yet. Maybe someone can help us.
    Note: some information below has been redacted and the IP addresses are not the original ones. They have been changed to fictional IP addresses but they have been adjusted to reflect an equivalent situation.
    This situation is as follows:
    WLAN infrastructure with:
    1 x
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:"";
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin:0cm;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-fareast-font-family:"Times New Roman";
    mso-fareast-theme-font:minor-fareast;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;
    mso-bidi-font-family:"Times New Roman";
    mso-bidi-theme-font:minor-bidi;}
    AIR-WLC2112-K9 (IP address = 10.10.10.10)
    8 x
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:"";
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin:0cm;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-fareast-font-family:"Times New Roman";
    mso-fareast-theme-font:minor-fareast;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;
    mso-bidi-font-family:"Times New Roman";
    mso-bidi-theme-font:minor-bidi;}
    AIR-LAP1142N-E-K9
    Data for the WLC:
    Product Version.................................. 6.0.199.4
    RTOS Version..................................... 6.0.199.4
    Bootloader Version.............................. 4.0.191.0
    Emergency Image Version................... 6.0.199.4
    The WLC is connected to a switch, Cisco Catalyst model WS-C3750X-24, sw version 12.2(53)SE2.
    The idea is to have the clients/supplicants (Windows XP), who have a valid certificate, authenticate against a RADIUS server. The authentication is configured as 802.1x over EAP-TLS.
    The RADIUS server is a Windows 2003 Server with IAS (IP address = 15.15.15.15). This server is accessed via a WAN link. We don't manage this server.
    The problem: no wireless client (Windows XP) is able to go past the initial authentication.
    I should add that the WLC and the APs were working perfectly and clients were connecting correctly to them. However this setup was moved to a new building and, since then, nothing has worked. I must add that the configuration on the WLC and APs has not changed, since the network configuration (IP subnets, etc) was migrated from the previous building to this new one. But something has changed: the WAN router (connected to the Internet and with a VPN established to the corporate network) and the LAN equipment (switches), which are all brand new.
    On the RADIUS side we find these error messages:
    Fully-Qualified-User-Name = XXXXXXXXXXXX/XXXX/XXXXX/XXXX/XXXXX (it shows the correct information)
    NAS-IP-Address = 10.10.10.10
    NAS-Identifier = XX-002_WLAN
    Called-Station-Identifier = f0-25-72-70-65-xx:WLAN-XX
    Calling-Station-Identifier = 00-1c-bf-7b-08-xx
    Client-Friendly-Name = xxxxxxx_10.10.10.10
    Client-IP-Address = 10.10.10.10
    NAS-Port-Type = Wireless - IEEE 802.11
    NAS-Port = 2
    Proxy-Policy-Name = Use Windows authentication for all users
    Authentication-Provider = Windows
    Authentication-Server = <undetermined>
    Policy-Name = Wireless LAN Access
    Authentication-Type = EAP
    EAP-Type = <undetermined>
    Reason-Code = 22
    Reason = The client could not be authenticated  because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.
    On the WLC side, the error messages are:
    TRAP log:
    RADIUS server 15.15.15.15:1812 failed to respond to request (ID 42) for client 00:27:10:a3:1b:xx / user 'unknown'
    SYSLOG:
    Jan 06 10:16:35 10.10.10.10 XX-002_WLAN: *Jan 06 10:16:32.709: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (3) exceeded for client 00:19:d2:02:76:xx
    Jan 06 10:17:05 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:02.960: %DOT1X-3-ABORT_AUTH: 1x_bauth_sm.c:447 Authentication aborted for client 00:19:d2:02:76:xx
    Jan 06 10:17:05 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:02.961: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (3) exceeded for client 00:19:d2:02:76:xx
    Jan 06 10:17:36 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:34.110: %DOT1X-3-ABORT_AUTH: 1x_bauth_sm.c:447 Authentication aborted for client 00:19:d2:02:76:xx
    Jan 06 10:17:36 10.10.10.10 PT-002_WLAN: *Jan 06 10:17:34.110: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (3) exceeded for client 00:19:d2:02:76:xx
    WLC Debug:
    *Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 Station 58:94:6b:15:f5:d0 setting dot1x reauth timeout = 1800
    *Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 dot1x - moving mobile 58:94:6b:15:f5:d0 into Connecting state
    *Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 Sending EAP-Request/Identity to mobile 58:94:6b:15:f5:d0 (EAP Id 1)
    *Jan 07 19:31:42.708: 58:94:6b:15:f5:d0 Received EAPOL START from mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.709: 58:94:6b:15:f5:d0 dot1x - moving mobile 58:94:6b:15:f5:d0 into Connecting state
    *Jan 07 19:31:42.709: 58:94:6b:15:f5:d0 Sending EAP-Request/Identity to mobile 58:94:6b:15:f5:d0 (EAP Id 2)
    *Jan 07 19:31:42.710: 58:94:6b:15:f5:d0 Received EAPOL EAPPKT from mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.710: 58:94:6b:15:f5:d0 Received EAP Response packet with mismatching id (currentid=2, eapid=1) from mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 Received EAPOL EAPPKT from mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 Received Identity Response (count=2) from mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 EAP State update from Connecting to Authenticating for mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 dot1x - moving mobile 58:94:6b:15:f5:d0 into Authenticating state
    *Jan 07 19:31:42.711: 58:94:6b:15:f5:d0 Entering Backend Auth Response state for mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.711: AuthenticationRequest: 0xd1bc104
    *Jan 07 19:31:42.711:     Callback.....................................0x87e1870
    *Jan 07 19:31:42.712:     protocolType.................................0x00140001
    *Jan 07 19:31:42.712:     proxyState...................................58:94:6B:15:F5:D0-9B:00
    *Jan 07 19:31:42.712:     Packet contains 12 AVPs (not shown)
    *Jan 07 19:31:42.712: apfVapRadiusInfoGet: WLAN(1) dynamic int attributes srcAddr:0x0, gw:0x0, mask:0x0, vlan:0, dpPort:0, srcPort:0
    *Jan 07 19:31:42.712: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 231) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00
    *Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Access-Challenge received from RADIUS server 15.15.15.15 for mobile 58:94:6b:15:f5:d0 receiveId = 155
    *Jan 07 19:31:42.788: AuthorizationResponse: 0xa345700
    *Jan 07 19:31:42.788:     structureSize................................145
    *Jan 07 19:31:42.788:     resultCode...................................255
    *Jan 07 19:31:42.788:     protocolUsed.................................0x00000001
    *Jan 07 19:31:42.788:     proxyState...................................58:94:6B:15:F5:D0-9B:00
    *Jan 07 19:31:42.788:     Packet contains 4 AVPs (not shown)
    *Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Processing Access-Challenge for mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Entering Backend Auth Req state (id=3) for mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.788: 58:94:6b:15:f5:d0 Sending EAP Request from AAA to mobile 58:94:6b:15:f5:d0 (EAP Id 3)
    *Jan 07 19:31:42.805: 58:94:6b:15:f5:d0 Received EAPOL EAPPKT from mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.805: 58:94:6b:15:f5:d0 Received EAP Response from mobile 58:94:6b:15:f5:d0 (EAP Id 3, EAP Type 13)
    *Jan 07 19:31:42.806: 58:94:6b:15:f5:d0 Entering Backend Auth Response state for mobile 58:94:6b:15:f5:d0
    *Jan 07 19:31:42.806: AuthenticationRequest: 0xd1bc104
    *Jan 07 19:31:42.806:     Callback.....................................0x87e1870
    *Jan 07 19:31:42.806:     protocolType.................................0x00140001
    *Jan 07 19:31:42.807:     proxyState...................................58:94:6B:15:F5:D0-9B:01
    *Jan 07 19:31:42.807:     Packet contains 13 AVPs (not shown)
    *Jan 07 19:31:42.807: apfVapRadiusInfoGet: WLAN(1) dynamic int attributes srcAddr:0x0, gw:0x0, mask:0x0, vlan:0, dpPort:0, srcPort:0
    *Jan 07 19:31:42.807: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 232) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00
    *Jan 07 19:31:52.531: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 228) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00                               ..
    *Jan 07 19:31:52.808: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 232) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00
    *Jan 07 19:32:02.531: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 228) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00
    *Jan 07 19:32:02.808: 58:94:6b:15:f5:d0 Successful transmission of Authentication Packet (id 232) to 15.15.15.15:1812, proxy state 58:94:6b:15:f5:d0-00:00
    *Jan 07 19:32:12.532: 58:94:6b:15:f5:d0 Max retransmission of Access-Request (id 228) to 15.15.15.15 reached for mobile 58:94:6b:15:f5:d0
    *Jan 07 19:32:12.532: 58:94:6b:15:f5:d0 [Error] Client requested no retries for mobile 58:94:6B:15:F5:D0
    *Jan 07 19:32:12.533: 58:94:6b:15:f5:d0 Returning AAA Error 'Timeout' (-5) for mobile 58:94:6b:15:f5:d0
    *Jan 07 19:32:12.533: AuthorizationResponse: 0xb99ff864
    Finally, we've also done some packet sniffing, using Wireshark and Commview. These appear to suggest that something is wrong with one of the packets and this leads to the authentication process to fail and restart again and again:
    ******************** WIRESHARK CAPTURE ********************
    No.     Time        Source                Destination           Protocol Info
          1 0.000000    10.10.10.10        15.15.15.15           RADIUS   Access-Request(1) (id=125, l=280)
    Frame 1: 322 bytes on wire (2576 bits), 322 bytes captured (2576 bits)
    Ethernet II, Src: Cisco_62:63:00 (f8:66:f2:62:63:00), Dst: Cisco_55:20:41 (1c:df:0f:55:20:41)
    Internet Protocol, Src: 10.10.10.10 (10.10.10.10), Dst: 15.15.15.15 (15.15.15.15)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated Services Codepoint: Default (0x00)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 308
        Identification: 0x501f (20511)
        Flags: 0x02 (Don't Fragment)
        Fragment offset: 0
        Time to live: 64
        Protocol: UDP (17)
        Header checksum: 0x4aee [correct]
        Source: 10.10.10.10 (10.10.10.10)
        Destination: 15.15.15.15 (15.15.15.15)
    User Datagram Protocol, Src Port: filenet-rpc (32769), Dst Port: radius (1812)
        Source port: filenet-rpc (32769)
        Destination port: radius (1812)
        Length: 288
        Checksum: 0xe8e0 [validation disabled]
            [Good Checksum: False]
            [Bad Checksum: False]
    Radius Protocol
        Code: Access-Request (1)
        Packet identifier: 0x7d (125)
        Length: 280
        Authenticator: 79b2f31c7e67d6fdaa7e15f362ecb025
        Attribute Value Pairs
            AVP: l=27  t=User-Name(1): XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (username is correct!!!)
            AVP: l=19  t=Calling-Station-Id(31): 00-21-6a-29-80-xx
            AVP: l=27  t=Called-Station-Id(30): f0-25-72-70-65-c0:WLAN-XX
            AVP: l=6  t=NAS-Port(5): 2
            AVP: l=6  t=NAS-IP-Address(4): 10.10.10.10
            AVP: l=13  t=NAS-Identifier(32): XX-002_WLAN
            AVP: l=12  t=Vendor-Specific(26) v=Airespace(14179)
            AVP: l=6  t=Service-Type(6): Framed(2)
            AVP: l=6  t=Framed-MTU(12): 1300
            AVP: l=6  t=NAS-Port-Type(61): Wireless-802.11(19)
            AVP: l=89  t=EAP-Message(79) Last Segment[1]
                EAP fragment
                Extensible Authentication Protocol
                    Code: Response (2)
                    Id: 3
                    Length: 87
                    Type: EAP-TLS [RFC5216] [Aboba] (13)
                    Flags(0x80): Length
                    Length: 77
                    Secure Socket Layer
            AVP: l=25  t=State(24): 1d68036a000001370001828b38990000000318a3088c00
            AVP: l=18  t=Message-Authenticator(80): 9fe1bfac02df3293ae2f8efc95de2d5d
    No.     Time        Source                Destination           Protocol Info
          2 0.060373    15.15.15.15        10.10.10.10          IP       Fragmented IP protocol (proto=UDP 0x11, off=0, ID=2935) [Reassembled in #3]
    Frame 2: 62 bytes on wire (496 bits), 62 bytes captured (496 bits)
    Ethernet II, Src: Cisco_55:20:41 (1c:df:0f:55:20:41), Dst: Cisco_62:63:00 (f8:66:f2:62:63:00)
    Internet Protocol, Src: 15.15.15.15 (15.15.15.15), Dst: 10.10.10.10 (10.10.10.10)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated Services Codepoint: Default (0x00)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 44
        Identification: 0x2935 (10549)
        Flags: 0x01 (More Fragments)
        Fragment offset: 0
        Time to live: 122
        Protocol: UDP (17)
        Header checksum: 0x58e0 [correct]
        Source: 15.15.15.15 (15.15.15.15)
        Destination: 10.10.10.10 (10.10.10.10)
        Reassembled IP in frame: 3
    Data (24 bytes)
    0000  07 14 80 01 05 69 e8 f5 0b 7d 05 61 6c 83 00 ae   .....i...}.al...
    0010  d0 75 05 c3 56 29 a7 b1                           .u..V)..
    No.     Time        Source                Destination           Protocol Info
          3 0.060671    15.15.15.15        10.10.10.10          RADIUS   Access-challenge(11) (id=125, l=1377)
    Frame 3: 1395 bytes on wire (11160 bits), 1395 bytes captured (11160 bits)
    Ethernet II, Src: Cisco_55:20:41 (1c:df:0f:55:20:41), Dst: Cisco_62:63:00 (f8:66:f2:62:63:00)
    Internet Protocol, Src: 15.15.15.15 (15.15.15.15), Dst: 10.10.10.10 (10.10.10.10)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated Services Codepoint: Default (0x00)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 1381
        Identification: 0x2935 (10549)
        Flags: 0x00
        Fragment offset: 24
        Time to live: 122
        Protocol: UDP (17)
        Header checksum: 0x73a4 [correct]
        Source: 15.15.15.15 (15.15.15.15)
        Destination: 10.10.10.10 (10.10.10.10)
        [IP Fragments (1385 bytes): #2(24), #3(1361)]
    User Datagram Protocol, Src Port: radius (1812), Dst Port: filenet-rpc (32769)
        Source port: radius (1812)
        Destination port: filenet-rpc (32769)
        Length: 1385
        Checksum: 0xe8f5 [validation disabled]
            [Good Checksum: False]
            [Bad Checksum: False]
    Radius Protocol
        Code: Access-challenge (11)
        Packet identifier: 0x7d (125)
        Length: 1377
        Authenticator: 6c8300aed07505c35629a7b14de483be
        Attribute Value Pairs
            AVP: l=6  t=Session-Timeout(27): 30
                Session-Timeout: 30
            AVP: l=255  t=EAP-Message(79) Segment[1]
                EAP fragment
            AVP: l=255  t=EAP-Message(79) Segment[2]
                EAP fragment
            AVP: l=255  t=EAP-Message(79) Segment[3]
                EAP fragment
            AVP: l=255  t=EAP-Message(79) Segment[4]
                EAP fragment
            AVP: l=255  t=EAP-Message(79) Segment[5]
                EAP fragment
            AVP: l=33  t=EAP-Message(79) Last Segment[6]
                EAP fragment
                Extensible Authentication Protocol
                    Code: Request (1)
                    Id: 4
                    Length: 1296
                    Type: EAP-TLS [RFC5216] [Aboba] (13)
                    Flags(0xC0): Length More
                    Length: 8184
                    Secure Socket Layer
    [Malformed Packet: SSL]
        [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
            [Message: Malformed Packet (Exception occurred)]
            [Severity level: Error]
            [Group: Malformed]
    ******************** COMMVIEW CAPTURE ******************
    Packet #6, Direction: Pass-through, Time:11:27:35,251292, Size: 323
    Ethernet II
        Destination MAC: 1C:DF:0F:55:20:xx
        Source MAC: F8:66:F2:62:63:xx
        Ethertype: 0x0800 (2048) - IP
    IP
        IP version: 0x04 (4)
        Header length: 0x05 (5) - 20 bytes
        Differentiated Services Field: 0x00 (0)
            Differentiated Services Code Point: 000000 - Default
            ECN-ECT: 0
            ECN-CE: 0
        Total length: 0x0135 (309)
        ID: 0x2B26 (11046)
        Flags
            Don't fragment bit: 1 - Don't fragment
            More fragments bit: 0 - Last fragment
        Fragment offset: 0x0000 (0)
        Time to live: 0x40 (64)
        Protocol: 0x11 (17) - UDP
        Checksum: 0x6FE6 (28646) - correct
        Source IP: 161.86.66.49
        Destination IP: 15.15.15.15
        IP Options: None
    UDP
        Source port: 32769
        Destination port: 1812
        Length: 0x0121 (289)
        Checksum: 0x5824 (22564) - correct
    Radius
        Code: 0x01 (1) - Access-Request
        Identifier: 0x8D (141)
        Packet Length: 0x0119 (281)
        Authenticator: 60 4E A6 58 A8 88 A2 33 4E 56 D0 E9 3B E0 62 18
        Attributes
            Attribute
                Type: 0x01 (1) - User-Name
                Length: 0x1A (26)
                Username: XXXXXXXXXXXXXXXXXXXXXXX (username is correct!!!)
            Attribute
                Type: 0x1F (31) - Calling-Station-Id
                Length: 0x11 (17)
                Calling id: 58-94-6b-15-5f-xx
            Attribute
                Type: 0x1E (30) - Called-Station-Id
                Length: 0x19 (25)
                Called id: f0-25-72-70-65-c0:WLAN-XX
            Attribute
                Type: 0x05 (5) - NAS-Port
                Length: 0x04 (4)
                Port: 0x00000002 (2)
            Attribute
                Type: 0x04 (4) - NAS-IP-Address
                Length: 0x04 (4)
                Address: 10.10.10.10
            Attribute
                Type: 0x20 (32) - NAS-Identifier
                Length: 0x0B (11)
                NAS identifier: XX-002_WLAN
            Attribute
                Type: 0x1A (26) - Vendor-Specific
                Length: 0x0A (10)
                Vendor id: 0x00003763 (14179)
                Vendor specific:  
            Attribute
                Type: 0x06 (6) - Service-Type
                Length: 0x04 (4)
                Service type: 0x00000002 (2) - Framed
            Attribute
                Type: 0x0C (12) - Framed-MTU
                Length: 0x04 (4)
                Framed MTU: 0x00000514 (1300)
            Attribute
                Type: 0x3D (61) - NAS-Port-Type
                Length: 0x04 (4)
                NAS port type: 0x00000013 (19) - Wireless - IEEE 802.11
            Attribute
                Type: 0x4F (79) - EAP-Message
                Length: 0x57 (87)
                EAP-Message
            Attribute
                Type: 0x18 (24) - State
                Length: 0x17 (23)
                State: 1F 38 04 12 00 00 01 37 00 01 82 8B 38 99 00 00 00 03 18 A6 82 B7 00
            Attribute
                Type: 0x50 (80) - Message-Authenticator
                Length: 0x10 (16)
                Message-Authenticator: 4F 13 92 9C 10 29 C5 3A B9 AE 92 CA 74 11 6C B5
    Packet #28, Direction: Pass-through, Time:11:27:36,523743, Size: 62
    Ethernet II
        Destination MAC: F8:66:F2:62:63:xx
        Source MAC: 1C:DF:0F:55:20:xx
        Ethertype: 0x0800 (2048) - IP
    IP
        IP version: 0x04 (4)
        Header length: 0x05 (5) - 20 bytes
        Differentiated Services Field: 0x00 (0)
            Differentiated Services Code Point: 000000 - Default
            ECN-ECT: 0
            ECN-CE: 0
        Total length: 0x002C (44)
        ID: 0x4896 (18582)
        Flags
            Don't fragment bit: 0 - May fragment
            More fragments bit: 1 - More fragments
        Fragment offset: 0x0000 (0)
        Time to live: 0x7A (122)
        Protocol: 0x11 (17) - UDP
        Checksum: 0x397F (14719) - correct
        Source IP: 15.15.15.15
        Destination IP: 10.10.10.10
        IP Options: None
    UDP
        Source port: 1812
        Destination port: 32769
        Length: 0x0569 (1385)
        Checksum: 0x2FE4 (12260) - incorrect

    Hi,
    We spent many hours trying to solve this problem.
    Our setup:
    Cisco wireless setup, using windows NPS for 802.1x authentication.
    Certificate base auth, with an internal PKI sending out client machine certs, and also the server cert.
    Auth was failing with "reason code 22, The client could not be authenticated  because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server."
    It turned out to be a GPO setting on the server, that was enforcing key protection.
    There is this note on the below technet article:
    Requiring the use of strong private key protection and user prompting on all new and imported keys will disable some applications, such as Encrypting File System (EFS) and wireless (802.1X) authentication that cannot display UI. For more information, see article 320828 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115037).
    http://technet.microsoft.com/en-us/library/cc725621(v=WS.10).aspx
    Hopefully this helps someone out, if you have the same annoying error.

  • DCNM Discovery

    Hi
    I'm having issues with DCNM discovering some Nexus 7K's.  Shallow discovery seems fine.  I enter the Nexus and its snmpv3 credentials in
    DCNM> Admin>Data Sources>LAN
    I enter the device as a single device in a switch list and it finds it as manageable.  I select the device and it goes into Discovering.
    Sometimes it completes this part and allows me to go to Deep discovery.  Other times I get snmp timeout messages.  I have had it complete a deep discovery and show up on my topology map only for it to disappear a day later again with snmp timeout errors.  I've confirmed the snmpv3 credentials work with a 3rd party MIB browser which lets me test credentials and all is ok with them.
    My first question is
    The DCNM server seems to have an incorrect time.  Is this a possible issue ? If so how do I set the time ?  I've looked all over the GUI and can't find any place to set it.  Is it taken from the VM platform or is it set independently ?
    Are there any other issues that may cause discovery problems ?
    Thanks, Stuart.

    Further troubleshooting has led me to put a capture on the Nexus to see if that sheds any light on what's going on.  I get the following output from the capture.
    172.31.1.1 -> 172.30.1.1     SNMP Source port: 59596  Destination port: snmp[Malformed Packet]
    That's from the DCNM server to the Nexus.
    Stuart

  • Hstnn-cx04 3 in 1 docking station

    I'm looking for a firmware update for
    Model: hstnn-cx04
    Pn: em537ut#aba
    commonly called the 3 in1 docking station
    This dock has a hard drive and a NAS inside it.
    Nessus finds the following vulnerabilities in the firmware:
    128.128.20.133
    Scan Time
    Start time :
    Wed Mar 17 14:08:01 2010
    End time :
    Wed Mar 17 14:09:23 2010
    Number of vulnerabilities
    Open ports :
    2
    High :
    4
    Medium :
    0
    Low :
    0
    Remote host information
    Operating System :
    Linux Kernel 2.4
    NetBIOS name :
    HPNAS
    DNS name :
    [^] Back to 128.128.20.133
    Port smb (139/tcp)
    [-/+]
    Samba Multiple Remote Vulnerabilities
    Synopsis:
    The remote service is vulnerable to several flaws.
    Description:
    The remote Samba server, according to its version number, is affected by a remote denial of service vulnerability as well as a buffer overflow. The Wild Card DoS vulnerability may allow an attacker to make the remote server consume excessive CPU cycles. The QFILEPATHINFO Remote buffer overflow vulnerability may allow an attacker to execute code on the server. An attacker needs a valid account or enough credentials to exploit those flaws.
    Risk factor:
    High
    CVSS Base Score:7.5
    CVSS2#AV:N/AC:L/Au:N/C/I/A
    See also:
    http://www.samba.org/samba/security/CVE-2004-0882.​html
    See also:
    http://www.samba.org/samba/security/CVE-2004-0930.​html
    Solution:
    Upgrade to Samba 3.0.8 or later.
    Plugin ID:
    15705
    CVE:
    CVE-2004-0882, CVE-2004-0930
    BID:
    11624, 11678
    Other references:
    OSVDB:11555, OSVDB:11782
    Samba smbd Security Descriptor Parsing Remote Overflow
    Synopsis:
    Remote code may be run on the remote server.
    Description:
    The remote Samba server, according to its version number, is vulnerable to a remote buffer overrun resulting from an integer overflow vulnerability. To exploit this flaw, an attacker would need to send to the remote host a malformed packet containing hundreds of thousands of ACLs, which would in turn cause an integer overflow resulting in a small pointer being allocated. An attacker needs a valid account or enough credentials to exploit this flaw.
    Risk factor:
    Critical
    CVSS Base Score:10.0
    CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C
    Solution:
    Upgrade to Samba 3.0.10 or later.
    Plugin ID:
    15985
    CVE:
    CVE-2004-1154
    BID:
    11973
    Other references:
    OSVDB:12422
    Port cifs (445/tcp)
    [-/+]
    Microsoft Windows SMB Shares Unprivileged Access
    Synopsis:
    It is possible to access a network share.
    Description:
    The remote has one or more Windows shares that can be accessed through the network with the given credentials. Depending on the share rights, it may allow an attacker to read/write confidential data.
    Risk factor:
    High
    CVSS Base Score:7.5
    CVSS2#AV:N/AC:L/Au:N/C/I/A
    Solution:
    To restrict access under Windows, open Explorer, do a right click on each share, go to the 'sharing' tab, and click on 'permissions'.
    Plugin output:
    The following shares can be accessed as wirnbzxm : - Public_Share - (readable,writable) + Content of this share : .. samba_symlink_dir_traversal.nasl-1268160037 samba_symlink_dir_traversal.nasl-1268763650 samba_symlink_dir_traversal.nasl-1268833297 samba_symlink_dir_traversal.nasl-1266944554 samba_symlink_dir_traversal.nasl-1267201281 samba_symlink_dir_traversal.nasl-1267203250 - config - (readable) + Content of this share : .. Configuration.html
    Plugin ID:
    42411
    CVE:
    CVE-1999-0519, CVE-1999-0520
    BID:
    8026
    Other references:
    OSVDB:299
    Samba NDR MS-RPC Request Heap-Based Remote Buffer Overflow
    Synopsis:
    It is possible to execute code on the remote host through Samba.
    Description:
    The version of the Samba server installed on the remote host is affected by multiple heap overflow vulnerabilities, which can be exploited remotely to execute code with the privileges of the Samba daemon.
    Risk factor:
    Critical
    CVSS Base Score:10.0
    CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C
    See also:
    http://www.samba.org/samba/security/CVE-2007-2446.​html
    Solution:
    Upgrade to Samba version 3.0.25 or later.
    Plugin ID:
    25216
    CVE:
    CVE-2007-2446
    BID:
    23973, 24195, 24196, 24197, 24198
    Other references:
    OSVDB:34699, OSVDB:34731, OSVDB:34732, OSVDB:34733

    Hy WhiteWiz,
    i have bought a 3-in-1 nas docking station model HSTNN-CX04 together with a NX9420 notebook at ebay. After installing Windows 7 on the notebook, i tried to get the NAS docking station alive. Unfortunately i haven't any software-cd for the docking station. I found a firmeware update at http://h18000.www1.hp.com/support/files/hpcpqnk/gr​/download/23962.html
    ,  but what means HTTP://"your_machine_name" in the following statement :
      In the Address bar, type HTTP://"your_machine_name", where "your_machine_name" is the name you created during initial setup.
    How can i run an initial setup ? Any help would be appreciated.
    Best Regards
    Uwe

  • Dcnm - 6500 snmpv3 discovery timeout

    Hi DC Experts,
    I'm trying to fullfill a new install for our new DC with DCNM 6.2 (win2k8 64-bit). N5K, N1K are easily imported via the DCNM discovery
    with SMNP v3 auth. Now i've run into problems with the 6500/sup2t.
    SNMP v2 gives no problems but i'm not able to achieve this with v3. From the windows server cmd it's possible to do a snmpwalk with the
    snmpv3 username/pass.
    Does anybody have an clue wat the problem can be?
    Cheers,
    Alex

    Further troubleshooting has led me to put a capture on the Nexus to see if that sheds any light on what's going on.  I get the following output from the capture.
    172.31.1.1 -> 172.30.1.1     SNMP Source port: 59596  Destination port: snmp[Malformed Packet]
    That's from the DCNM server to the Nexus.
    Stuart

  • Time Capsule unexpectedly reboots.

    Over the past year I have been experiencing random unexpected reboots of my Time Capsule.   There is no rhyme or reason why or when it is occurring.  It can happen every other day or it can happen once a month.  However, lately it is happening more often.  Are other people experiencing the following?
    I believe the reboots started occurring after the 7.6.4 firmware update released on 8/13/2013 which is the latest for my 4th Gen Time Capsule.  I set up remote syslog from all my Airport devices using the old version of Airport Utility on my old iMac but never found the "silver bullet" in the logs.  With the upgrade to Yosemite, it seems like the frequency of unexpected reboots has increased and my syslog configuration got blown away on the Mac I was using as the syslog server.
    I'm wildly guessing now this is a result of more uses of IPv6 beyond device discovery which is how the current version of the Airport Utility finds Airport devices.  However, it doesn't always work correctly as the screen capture below shows.  And switching to "Local-Link Only" per http://support.apple.com/en-us/TS4597 doesn't solve the issue.
    It is also possible that malformed packets are coming in from my ISP and my Time Capsule which is directly connected via Ethernet can't handle it and reboots.  (I have no other router in the mix.)  I have no way of determining that since Apple deprecated logging in Airport Utility version 6.XXX.
    I have contacted Apple Support.  They have no idea why the Airport Utility device discovery doesn't work all the time and their only suggestion for my Time Capsule was doing a hard reset which I have done but it failed to solve the problem.  Any advice or suggestions would be much appreciated.  Or any advise on configuring ASL which is Apple's replacement for syslog.

    Thanks .. your picture has displayed.. it has a Yosemite look to it.. and there is mDNS responder issues with it.
    See OS X: How to disable Bonjour service advertising without disabling DNS - Apple Support
    I can tell you what you are seeing is something I see nearly everyday.. The wretched airport utility v6 is a toybox version utility for toyland.
    I am sticking to older OS and can simultaneously run v5 airport utility which.. surprise surprise.. has no issues whatsoever discovering the network.
    Your APE-Office appears to be wired.. is that the case??
    The only one that doesn't have issues is my office airport express that is so old that it isn't even supported by 7.6 or the current version of airport utility.
    If it is wired that will keep it out of the wireless repeater voodoo graveyard.
    So what are your concerns about 7.6.4?
    My experience is that extend wireless works poorly.. as in he chose... poorly.. see https://www.youtube.com/watch?v=Ubw5N8iVDHI
    I have a temporary wireless extend from downstairs to upstairs.. using a Gen4TC downstairs.. and a gen4AE upstairs.
    When I change the firmware to 7.6.4 the link is poor and often drops out.. when I take both of them back to 7.6.1 it works properly again.. I can reproduce this over and over.. downgrade works great.. upgrade which accidentally happens now and then.. the whole thing turns to rubbish.
    In a v5 utility I can see the wireless links and track them.. It is easy to see the link from each device.. (I repair these things so I have no less than 3 or 4 running at one time).
    But 7.6.4 has lots of other issues like port forwarding and wan port controls also giving issues. It is buggy but not many people seem to hit the issue I guess.
    the Gen4 TC has a nasty issue where it dies.. the whole series was poor to begin with lasting only about 18months before power supplies gave out.. ran too hot.. apple fixed that in later ones but I would not recommend keeping them beyond 3 years.. as with most domestic level electronics goods now running 24/7, the effective lifetime is 3years.. (and 1 day to get beyond warranty claims) ..
    See https://sites.google.com/site/lapastenague/a-deconstruction-of-routers-and-modem s/apple-time-capsule-repair
    With a link at the bottom to Gen 4 issues.

  • E-70 WLAN Issues

    I have following problems with my new E70 WLAN connectivity:
    I defined an access point (AP) for home (w/ WEP Key) and another one for University campus (Open). It connects at home but always ask me to enter WEP Key. If I change browser settings to user defined AP and select message is: Access Point Not found or sometimes Gateway Disconnected. The connection gets establish if I change browser AP settings to "Always Ask", but I have to enter WEP key for every new page/session. Even so the connectivity drops out in about every 2 minutes. (I have a DLINK DI-524 at home)
    The story at university campus AP is totally different - there at some AP it keeps showing connecting bar forever, but never connects. At some other APs it will make the screen blanc and then the Nokia logo aprears, after about a minute of freezing out, I get a promp that "New Voicemail". No new voicemail is there - attempt to connect to the WLAN is malfunctioning.
    Firmware: 1.0610.05.07 30-05-06 RM-10 Nokia E70
    What do I need to do? Is there any firmware patch for this problem from Nokia? I do not want to pay subscription to birdstep.com. The WLAN feature should work on all popular AP and Router models.
    Any help/pointers/software/firware is appreciated. Thanks a lot.
    Nokia E-70 Firmware ver 1.0610.05.07 30-05-06 RM-10

    Hi,
    Just to confirm that there _IS_ something wrong with the E70 and Linksys AP's
    I've got myself E70 UK edition yesterday, the firmware claims: 1.0610.05.07 30-05-06 RM-10.
    To describe the problem:
    At work I have a Linksys WAG54G (Firmware ver 1.02.1 apparently newest), connectivity works, but it takes a good 10-15minutes to get logged in. Since when the E70 starts to try and access the (WEP 128 encrypted AP) I see the MAC in the Linksys's ARP table, while the phone does not respond on any Wifi Applications. To see when it works typically for me I would use the browser and make it try it will get stuck on "Connecting" and after about 10-15minutes the page would show up, from then on the VOIP, etc. would work without a problem.
    At home I have a DD-WRT (newest SP1) flashed Linksys WRT54GS v.4 with no encryption, I have _exactly_ the same behaviour logging in to it as above. I also have a WAP54G (v3.1) Firmware v3.05 (dec 28 2005) which has _exactly_ the same symptoms.
    I also have a Belkin Wireless G (model: F5D7230-4) and at Firmware ver F5D7230v4_UK_6.00.21 at home which lets my E70 log in about 3 seconds (including displaying of a webpage).
    All 3 AP's at my home are Open (no WEP), on the same LAN and uses the same DHCP server, etc, all of them work fine (tested individually) with multiple machines connecting to them without a hitch, I'm blaming the E70 not being "happy" with the Linksys gear.
    I read today on http://www.voip-info.org/wiki/view/Nokia that the modified WRT54G can be "fixed" by making the router ignore packets in a invalid state, I can only think that the E70 sends malformed packets which the Linksys routers usually drop, it is strange though that after 10-15minutes it _does_ log in and it seems pretty much usable from then onwards.
    So, IMHO I hope Nokia will look into this and come out with some firmware after they fixed their wifi ip stack issues.

Maybe you are looking for