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

Similar Messages

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.

Netstat not reporting input errors with packets that have bad checksums ?

Greetings,
Is netstat not reporting any checksum errors ? I have a number of Macs reporting checksum errors when sniffing the local net. I would think that these should be reported by netstat as input errors, or collisions right ?
But it doesn't currently. See below for sample, its occurring across protocols, tcp, and udp. Usually this error is a bad ethernet port or cabling, and sometimes a sw issue. Working on eliminating the switches, router, and dsl modem by doing more testing.
But is netstat broke ? I havent seen any errors from netstat since @ 3yrs ago.
length 64, bad cksum 0 (->f9fe)!)
One other question, can one monitor firewire 400/800 ports or usb with netstat ? Its not listed with man pages or netstat -h
Thanks in advance

Im am using two commands to view the data;
netstat -I en0 2;
(no errors in or out)
and tcpdump with the verbose -v argument
( reports the cksum ( these are CRC's right, not IP header checksum ? )
At the very bottom is the netstat -s output, otherwise a snippet of tcpdump ; replaced the IP's with xxxx's to protect the innocent
Thanks for your help.....
===========================
18:13:37.101690 IP (tos 0x0, ttl 64, id 8134, offset 0, flags [DF], proto TCP (6), length 957, *bad cksum 0 (->68d8)!)* xxxxxxxxxx > xxxxxxxxxxxxxxx: P 8689:9594(905) ack 1 win 65535 <nop,nop,timestamp 1438111158 3084046213>
18:13:37.136653 IP (tos 0x0, ttl 57, id 26778, offset 0, flags [DF], proto TCP (6), length 52) xxxxxxxxxx > xxxxxxxxxxxxxxx: ., cksum 0xd4bc (correct), ack 5793 win 17376 <nop,nop,timestamp 3084046248 1438111158>
18:13:37.172381 IP (tos 0x0, ttl 57, id 26779, offset 0, flags [DF], proto TCP (6), length 52) xxxxxxxxxx > xxxxxxxxxxxxxxx: ., cksum 0xc3a0 (correct), ack 7241 win 20272 <nop,nop,timestamp 3084046284 1438111158>
18:13:37.207358 IP (tos 0x0, ttl 57, id 26780, offset 0, flags [DF], proto TCP (6), length 52) xxxxxxxxxx > xxxxxxxxxxxxxxx: ., cksum 0xb285 (correct), ack 8689 win 23168 <nop,nop,timestamp 3084046319 1438111158>
18:13:37.230968 IP (tos 0x0, ttl 57, id 26781, offset 0, flags [DF], proto TCP (6), length 52) xxxxxxxxxx > xxxxxxxxxxxxxxx: ., cksum 0xa395 (correct), ack 9594 win 26064 <nop,nop,timestamp 3084046342 1438111158>
18:13:37.313545 IP (tos 0x0, ttl 57, id 26782, offset 0, flags [DF], proto TCP (6), length 1500) xxxxxxxxxx > xxxxxxxxxxxxxxx: . 1:1449(1448) ack 9594 win 26064 <nop,nop,timestamp 3084046415 1438111158>
18:13:37.322422 IP (tos 0x0, ttl 57, id 26783, offset 0, flags [DF], proto TCP (6), length 1500) xxxxxxxxxx > xxxxxxxxxxxxxxx: . 1449:2897(1448) ack 9594 win 26064 <nop,nop,timestamp 3084046415 1438111158>
18:13:37.322440 IP (tos 0x0, ttl 64, id 8135, offset 0, flags [DF], proto TCP (6), length 52, *bad cksum 0 (->6c60)!)* xxxxxxxxxx > xxxxxxxxxxxxxxx ., *cksum 0xaec3 (incorrect (-> 0xff42)*, ack 2897 win 65160 <nop,nop,timestamp 1438111159 3084046415>
18:13:37.331285 IP (tos 0x0, ttl 57, id 26784, offset 0, flags [DF], proto TCP (6), length 1500) xxxxxxxxxx > xxxxxxxxxxxxxxx: . 2897:4345(1448) ack 9594 win 26064 <nop,nop,timestamp 3084046415 1438111158>
18:13:37.334407 IP (tos 0x0, ttl 57, id 26785, offset 0, flags [DF], proto TCP (6), length 646) xxxxxxxxxx > xxxxxxxxxxxxxxx: P 4345:4939(594) ack 9594 win 26064 <nop,nop,timestamp 3084046415 1438111158>
18:13:37.334421 IP (tos 0x0, ttl 64, id 8136, offset 0, flags [DF], proto TCP (6), length 52, *bad cksum 0 (->6c5f)!*) xxxxxxxxxx > xxxxxxxxxxxxxxx: ., *cksum 0xaec3 (incorrect (-> 0xf5d1)*, ack 4939 win 65535 <nop,nop,timestamp 1438111159 3084046415>
===============================
netstat -s
tcp:
7470 packets sent
2868 data packets (671900 bytes)
0 data packets (0 bytes) retransmitted
0 resends initiated by MTU discovery
3534 ack-only packets (101 delayed)
0 URG only packets
0 window probe packets
657 window update packets
411 control packets
7918 packets received
3225 acks (for 672008 bytes)
185 duplicate acks
0 acks for unsent data
4489 packets (2652174 bytes) received in-sequence
7 completely duplicate packets (7347 bytes)
0 old duplicate packets
0 packets with some dup. data (0 bytes duped)
291 out-of-order packets (412273 bytes)
0 packets (0 bytes) of data after window
0 window probes
1 window update packet
1 packet received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
207 connection requests
12 connection accepts
0 bad connection attempts
0 listen queue overflows
219 connections established (including accepts)
231 connections closed (including 9 drops)
2 connections updated cached RTT on close
2 connections updated cached RTT variance on close
0 connections updated cached ssthresh on close
0 embryonic connections dropped
3222 segments updated rtt (of 3193 attempts)
2 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 connections dropped by persist timeout
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
2199 correct ACK header predictions
4128 correct data packet header predictions
0 SACK recovery episodes
0 segment rexmits in SACK recovery episodes
0 byte rexmits in SACK recovery episodes
0 SACK options (SACK blocks) received
275 SACK options (SACK blocks) sent
0 SACK scoreboard overflow
udp:
360 datagrams received
0 with incomplete header
0 with bad data length field
0 with bad checksum
21 dropped due to no socket
65 broadcast/multicast datagrams dropped due to no socket
0 dropped due to full socket buffers
0 not for hashed pcb
274 delivered
390 datagrams output
ip:
8278 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with ip length > max ip packet size
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
0 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets reassembled ok
8278 packets for this host
0 packets for unknown/unsupported protocol
0 packets forwarded (0 packets fast forwarded)
0 packets not forwardable
0 packets received for unknown multicast group
0 redirects sent
7869 packets sent from this host
0 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
8 output packets discarded due to no route
0 output datagrams fragmented
0 fragments created
0 datagrams that can't be fragmented
0 tunneling packets that can't find gif
0 datagrams with bad address in header

Supplicant sent malformed PEAP message - bad record MAC

Hi all,
A specific kind of endpont, a device called Raspberry PI, is unable to connect or keep connected to our wireless network and the message generated by ISE is : Supplicant sent malformed PEAP message - bad record MAC
the WLAN accepts AES end TKIP and both have been tested.
I got some logs from WLC. Hope someone out there could help me.
*dot1xMsgTask: Aug 27 20:26:40.673: 00:e7:a6:56:86:8c dot1x - moving mobile 00:e7:a6:56:86:8c into Connecting state
*dot1xMsgTask: Aug 27 20:26:40.673: 00:e7:a6:56:86:8c Sending EAP-Request/Identity to mobile 00:e7:a6:56:86:8c (EAP Id 1)
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.699: 00:e7:a6:56:86:8c Received EAPOL EAPPKT from mobile 00:e7:a6:56:86:8c
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.699: 00:e7:a6:56:86:8c Received Identity Response (count=1) from mobile 00:e7:a6:56:86:8c
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.699: 00:e7:a6:56:86:8c EAP State update from Connecting to Authenticating for mobile 00:e7:a6:56:86:8c
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.699: 00:e7:a6:56:86:8c dot1x - moving mobile 00:e7:a6:56:86:8c into Authenticating state
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.699: 00:e7:a6:56:86:8c Entering Backend Auth Response state for mobile 00:e7:a6:56:86:8c
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.700: 00:e7:a6:56:86:8c Received EAPOL EAPPKT from mobile 00:e7:a6:56:86:8c
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.700: 00:e7:a6:56:86:8c Received Duplicate EAP Response Identity packet with eapid=1 from mobile 00:e7:a6:56:86:8c
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.702: 00:e7:a6:56:86:8c Received EAPOL EAPPKT from mobile 00:e7:a6:56:86:8c
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.702: 00:e7:a6:56:86:8c Received Duplicate EAP Response Identity packet with eapid=1 from mobile 00:e7:a6:56:86:8c
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.726: 00:e7:a6:56:86:8c Processing Access-Reject for mobile 00:e7:a6:56:86:8c
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.726: 00:e7:a6:56:86:8c Removing PMK cache due to EAP-Failure for mobile 00:e7:a6:56:86:8c (EAP Id -1)
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.726: 00:e7:a6:56:86:8c Sending EAP-Failure to mobile 00:e7:a6:56:86:8c (EAP Id -1)
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.726: 00:e7:a6:56:86:8c Entering Backend Auth Failure state (id=-1) for mobile 00:e7:a6:56:86:8c
*Dot1x_NW_MsgTask_4: Aug 27 20:26:40.726: 00:e7:a6:56:86:8c Setting quiet timer for 5 seconds for mobile 00:e7:a6:56:86:8c

Hi,
Thank you for your response!
Do you mean that there's something wrong with some version of the 'iaik_ssl.jar' ?
How do I determine which version we're running and what version is 'the older' version of the iaik_ssl.jar ?
Regards

Slow file transfer between Mac & PC Network - bad checksums?

Howdy all. I've been having a persistent issue with transferring files from my Mac to my Win2003 server. The transfers are always much slower than they should be (compared to the PCs on the network with lesser connections), but even more puzzling, is that it will often go to 95% (or thereabouts) and then take twice as long to finish the remaining percentage as it did to transfer the vast majority of the file.
It's all gigabit from point to point and I've swapped patch cables, router ports, etc.. with a known good performing WinXP box to see if that would make a difference, but it didn't.
I've searched the forums and found some mention of mysteriously slow file transfers using SMB, but nothing conclusive.
I ran a LAN monitoring util on the Mac during a xfer and below is a snippet of the results from the log. No dropped packets, but lots of bad checksums?
Any help would be greatly appreciated.
Thanks,
Ed T.
Start: 6/14/06 4:36:26 PM
16:36:41.676157 localhost.1017 > localhost.1033: P 367145920:367145992(72) ack 93878562 win 65535 <nop,nop,timestamp 2029087960 2029087900> (DF) (ttl 64, id 56412, bad cksum 0!)
16:36:41.676189 localhost.1033 > localhost.1017: . ack 72 win 65535 <nop,nop,timestamp 2029087960 2029087960> (DF) (ttl 64, id 56413, bad cksum 0!)
16:36:41.676207 localhost.1033 > localhost.1017: P 1:61(60) ack 72 win 65535 <nop,nop,timestamp 2029087960 2029087960> (DF) (ttl 64, id 56414, bad cksum 0!)
16:36:41.676224 localhost.1017 > localhost.1033: . ack 61 win 65535 <nop,nop,timestamp 2029087960 2029087960> (DF) (ttl 64, id 56415, bad cksum 0!)
16:36:49.676576 192.168.1.111.50949 > 255.255.255.255.2222: udp 152 (ttl 64, id 2189)
<SNIP MORE OF THE SAME>
320 Packets Received
0 Packets dropped.
• Monitor Completed •

While I have never tried it, Mac supports Firewire networking (TCP/IP over FW) and I know that some PCs do likewise. Mine does.
That being said, it's possible to link your Mac to your PC with a FW cable (both ends must be the large type of connector) and if so, you can transfer at 400 MB/s.
To enable FireWire networking on your Mac, in the Network preferences, at the bottom of the left pane, click the + sign and in the popup window, add Interface: Firewire.
As I said, I have never used it but in theory it would work. It's not at all like using the Target mode, this is a "hot" FW network link that can directly connect two computers.
IMO, it's worth a shot.

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.

TCP bad checksum

Hi
Could someone inform me how a CSS 11500 handles a packet with TCP invalid checksum. I have two loadbalanced svrs behind a CSS and im seeing the and ACK with a bad checksum hitting the server VLAN interface of the CSS which appears to send RST 200 micro seconds later to the server but not to the client, Is this normal behaviour ?.
Thanks in advance

Stephen,
don't look at the interval with just the last packet.
The CSS will mark a flow idle if the interval between 2 consecutives packet is bigger than the idle timeout.
At that time, no reset will be sent.
But during the garbage collection process, the CS may reclaim resources hold by connections that were marked idle.
Even if the connection was not idle anymore, the CSS will destroy it if it was marked idle anytime in the past.
Moreover, for http connection, the idle timeout is 8 sec and not 16.
Finally, you can also check with 'show dos' to see if the css consider the connection as illegal - which would trigger a reset as well.
Gilles.

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?

RMI over different subnets causing TCP BAD CHECKSUM

I have a customer that is trying to run my system over different subnets and is getting large performance hits due to a TCP BAD CHECKSUM error that they have been able to monitor when they have the RMI server on one subnet and the RMI client on another.
We don't see the problem on our systems (because we run on the same subnets) as do all of our other customers.
We've written a little program that just does some simple RMI calls over the different subnets and are still seeing the TCP BAD CHECKSUM errors.
Is there some reason that they are seeing these errors when the two are on different subnets? Is there any way to solve this problem (as it is causing a big hit in our performance)?

It is certainly nothing to do with RMI. The most probable culprit is bad hardware between the two subnets.

"Bad checksum in disk label" & "Can't open disk label package"

Hello,
I'm brand new to Sun/Solaris.
I have a Sun Blade 150, with SunOS 5.8.
I wanted to make a backup to prevent future data loss, so I put the disk in a normal PC with Windows XP to try to make a backup with Norton Ghost, the disk was detected, but not the file volume, so I place the disk on a desktop PC, and used Norton Ghost for DOS, the disk was recognized but once again not the file volume, so I wasn't able to make a disk backup, and I quit.
Put back the disk on the Sun Blade 150 PC, and then I was unable to startup the PC, showing the message "Bad checksum in disk label" and "Can't open disk label package".
What's wrong?
How can I solve this?
I need the data that's inside the hard-disk, so I cannot make a clean install, and i also don't have any install CD.
Thanks for any help,
JS

Thanks for the fast response,
i did't allow WindowsXP to write anythink to the disk, but somethink is written,and I don't know what. So now, the Spark-System dosn't boot from the HDD and the data on the disk is very important for me! When I format the disk all data are lost, right?
Is there a way to "rewrite" the Disk-Label-Checksum? I have an original Boot-CD-ROM, another HDD to install Solaris and so one, but I need the data of the corrupted HDD. And I also have not really a glue to use Solaris or any other UNIX, I'm a Windows-User.........

IP-3-TCP_BADCKSUM:TCP bad checksum error

On my Catalyst 6509 switch with MSFC cards I'm receiving the following error:-
2005 Aug 24 12:28:12 gmt +02:00 %IP-3-TCP_BADCKSUM:TCP bad checksum
Any reason why? I have attached the show version of the switch.
TEXT6500-S-SQP (enable) sh ver
WS-C6509 Software, Version NmpSW: 6.3(9)
Copyright (c) 1995-2002 by Cisco Systems
NMP S/W compiled on Sep 23 2002, 17:51:19
System Bootstrap Version: 5.3(1)
Hardware Version: 2.0 Model: WS-C6509 Serial #: SCA0423032D
PS1 Module: WS-CAC-1300W Serial #: SON04180245
PS2 Module: WS-CAC-1300W Serial #: SON04172006
Mod Port Model Serial # Versions
1 2 WS-X6K-SUP1A-2GE SAD04220A77 Hw : 3.1
Fw : 5.3(1)
Fw1: 5.1(1)CSX
Sw : 6.3(9)
Sw1: 6.3(9)
WS-F6K-PFC SAD042302ZZ Hw : 1.1
2 2 WS-X6K-SUP1A-2GE SAD04220B2H Hw : 3.1
Fw : 5.3(1)
Fw1: 5.1(1)CSX
Sw : 6.3(9)
Sw1: 6.3(9)
WS-F6K-PFC SAD042206UG Hw : 1.1
3 8 WS-X6408A-GBIC SAD042102X8 Hw : 1.1
Fw : 5.1(1)CSX
Sw : 6.3(9)
4 48 WS-X6348-RJ-45 SAD04190CRC Hw : 1.1
Fw : 5.3(1)
Sw : 6.3(9)
5 8 WS-X6408A-GBIC SAL08486F97 Hw : 3.1
Fw : 5.4(2)
Sw : 6.3(9)
15 1 WS-F6K-MSFC SAD042202F4 Hw : 1.4
Fw : 12.1(8b)E13
Sw : 12.1(8b)E13
16 1 WS-F6K-MSFC SAD042202WH Hw : 1.4
Fw : 12.1(8b)E13
Sw : 12.1(8b)E13
DRAM FLASH NVRAM
Module Total Used Free Total Used Free Total Used Free
1 65408K 47468K 17940K 16384K 9514K 6870K 512K 276K 236K

IP-3-TCP_BADCKSUM:TCP bad checksum
This message is informative only. The problem is caused by a device in the network that is sending bad packets to the switch.
IP-3-TCP_BADCKSUM:TCP bad checksum
Explanation: This message indicates that the system has received a TCP packet with a bad checksum from another device on the administrative VLAN. The packet will be discarded.
Action: This message is provided for information only.
Also, if you have Cisco ACS, check out the following bug
http://www.cisco.com/cgi-bin/bugtool/onebug.pl?bugid=CSCeh32487

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?

Satellite Pro U200 - Bad Checksum (ROM (Data Block) ) error

Hello when i start my Toahiba Satellite Pro U200
I have a Error
Bad Checksum (ROM (Data Block) )
PRESS ANY KEY TO CONINUE.
Pleas Help

The most common cause for "Bad Checksum" errors is the CMOS battery malfunction on the motherboard.
The battery could be empty or could simply be dead. But its really not easy to say whats wrong exactly!
Therefore I would recommend firstly to access the BIOS and to set it to default settings. Dont forget to save the changes.
Furthermore you should connect the AC adaptor and should let it connected for about 24hours to recharge the CMOS battery.
Maybe it helps to get rid of this error message.
If it doesnt help, then you should contact a notebook technician!

870A/870U-G55 Bad Checksum

i know i know, reset the CMOS. i did that. i reset the date/time...still bad checksum. replace with a battery that you know works from an older motherboard, same thing...
going to buy a new battery and try again... but if it still happens... why am i not able to clear the Bad Checksum error? is the board bad after 30 days brand spanking new?
EDIT: whoops. sorry bout that... *fires up Speccy*
Operating System
   MS Windows 7 Ultimate 64-bit
CPU
   AMD Phenom II X2 555
   Callisto 45nm Technology
RAM
   4.0GB Dual-Channel DDR3 @ 668MHz (9-9-9-24)
Motherboard
   MSI 870U-G55 (MS-7599) (CPU1)
Graphics
   ASUS VW193T @ 1440x900
   512MB GeForce 9800 GT (PNY)
Hard Drives
   313GB Western Digital WDC WD3200AAKS-00L9A0 ATA Device (Unknown)
Optical Drives
   DMTWJM 5YBSP2V SCSI CdRom Device
   SONY DVD RW DRU-865S ATA Device
Audio
   Creative X-Fi Audio Processor (WDM)

Quote from: Jack on 21-February-11, 03:14:06
>>Posting Guide<<
This happend just suddenly out of the blue or did you do something (like performing a BIOS Update via MSI Live Update)?
out of the blue... i was playing an MMO, and my Windows Explorer reset itself back to default color (my custom color is red, it reset back to light blue)...and it ran the game slow. so i rebooted the computer, and bam, bad checksum. this was yesterday. been getting it ever since.

Ordered Iphoto calendar. One picture is blurred and bad. Can I get a new calendar?

Ordered an iphoto calendar for 2015. One picture is blurred and bad. Can I get a new calendar? To whom do I report this problem?
Joan

Maybe - did you preview the calendar -
Before ordering your calendar preview it using this method - http://support.apple.com/kb/HT1040 - and save the resulting PDF for reference - the delivered calendar will match it.
What is the printed size of the image and what are it's pixel dimensions - it need to be no less than 150 DPI for a good, clear print
You can contact Apple at the address included in your order confirmation email and see what they will do - but if the picture is too small reprinting will not help
LN

Malformed Packets and Bad Checksums

Similar Messages

Maybe you are looking for