Linux - Wireless Networking This forum is for the discussion of wireless networking in Linux. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
10-29-2004, 02:15 AM
|
#1
|
Member
Registered: Aug 2003
Location: Sweden
Distribution: Debian
Posts: 52
Rep:
|
"Frame check sequence"-error (802.11b Ad hoc)
I get "Frame check sequence"-error on broadcast packets between two host in a simple 2 node Ad hoc network using 802.11b and Debian/Linux. This FCS error does not appear when the packets are sent using unicast.
Here is the packet captured by Ethereal (but never delivered to my application):
(The ident is corrupted when submitting the post, tried to make it more readable)
------------------------------------------------------------
No. Time Source Destination Protocol Info
5 4.039653 10.0.4.2 255.255.255.255 UDP Source port: x11 Destination port: x11
--> Frame 5 (74 bytes on wire, 74 bytes captured)
Arrival Time: Oct 29, 2004 08:04:05.984378000
Time delta from previous packet: 1.009917000 seconds
Time since reference or first frame: 4.039653000 seconds
Frame Number: 5
Packet Length: 74 bytes
Capture Length: 74 bytes
--> Ethernet II, Src: 00:60:1d:f2:be:7c, Dst: ff:ff:ff:ff:ff:ff
Destination: ff:ff:ff:ff:ff:ff (Broadcast)
Source: 00:60:1d:f2:be:7c (10.0.3.2)
Type: IP (0x0800)
Trailer: 38FF05002100A0010030000000000000
/*** BELOW IS THE INCORRECT FCS (this line added by me) ***/
Frame check sequence: 0x00000000 (incorrect, should be 0xec31f260)
--> Internet Protocol, Src Addr: 10.0.4.2 (10.0.4.2), Dst Addr: 255.255.255.255 (255.255.255.255)
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: 40
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x2cc4 (correct)
Source: 10.0.4.2 (10.0.4.2)
Destination: 255.255.255.255 (255.255.255.255)
--> User Datagram Protocol, Src Port: x11 (6000), Dst Port: x11 (6000)
Source port: x11 (6000)
Destination port: x11 (6000)
Length: 20
Checksum: 0xf060 (correct)
Data (12 bytes)
0000 48 65 6c 6c 6f 21 20 5b 31 35 5d 00 Hello! [15].
--------------------------------------------------------------------
See that the FCS is 0x00000000? Why is this? The UDP checksum seems to be correct. This FCS eroor does not happend when using unicast! Both sockets are bound to INADDR_ANY and set to allow broadcasts.
Is it the FCS that is my problem or is it Ethereal the makes a mistake? Should ethereal be able to see packets with FCS error? Shouldnt they have been retransmitted on the hardware level without the knowledge from the software?
ADDED:
I have noticed that the FCS error does not matter, I can receive that packets even if these error are present. What matters is if there is a route back to the sending node, if it is, the packets are delivered, else not, why???
All feedback is very appreciated, I'm becoming frustrated over this problem!
Best regards
Rickard
Last edited by rickthemick; 10-29-2004 at 03:15 AM.
|
|
|
10-15-2007, 03:13 AM
|
#2
|
LQ Newbie
Registered: Oct 2007
Posts: 1
Rep:
|
Hi rickthemick
Are you got solution of this problem.
I am also going through same kind of problem.
Could you help me.
Regards
Amandeep
Quote:
Originally Posted by rickthemick
I get "Frame check sequence"-error on broadcast packets between two host in a simple 2 node Ad hoc network using 802.11b and Debian/Linux. This FCS error does not appear when the packets are sent using unicast.
Here is the packet captured by Ethereal (but never delivered to my application):
(The ident is corrupted when submitting the post, tried to make it more readable)
------------------------------------------------------------
No. Time Source Destination Protocol Info
5 4.039653 10.0.4.2 255.255.255.255 UDP Source port: x11 Destination port: x11
--> Frame 5 (74 bytes on wire, 74 bytes captured)
Arrival Time: Oct 29, 2004 08:04:05.984378000
Time delta from previous packet: 1.009917000 seconds
Time since reference or first frame: 4.039653000 seconds
Frame Number: 5
Packet Length: 74 bytes
Capture Length: 74 bytes
--> Ethernet II, Src: 00:60:1d:f2:be:7c, Dst: ff:ff:ff:ff:ff:ff
Destination: ff:ff:ff:ff:ff:ff (Broadcast)
Source: 00:60:1d:f2:be:7c (10.0.3.2)
Type: IP (0x0800)
Trailer: 38FF05002100A0010030000000000000
/*** BELOW IS THE INCORRECT FCS (this line added by me) ***/
Frame check sequence: 0x00000000 (incorrect, should be 0xec31f260)
--> Internet Protocol, Src Addr: 10.0.4.2 (10.0.4.2), Dst Addr: 255.255.255.255 (255.255.255.255)
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: 40
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x2cc4 (correct)
Source: 10.0.4.2 (10.0.4.2)
Destination: 255.255.255.255 (255.255.255.255)
--> User Datagram Protocol, Src Port: x11 (6000), Dst Port: x11 (6000)
Source port: x11 (6000)
Destination port: x11 (6000)
Length: 20
Checksum: 0xf060 (correct)
Data (12 bytes)
0000 48 65 6c 6c 6f 21 20 5b 31 35 5d 00 Hello! [15].
--------------------------------------------------------------------
See that the FCS is 0x00000000? Why is this? The UDP checksum seems to be correct. This FCS eroor does not happend when using unicast! Both sockets are bound to INADDR_ANY and set to allow broadcasts.
Is it the FCS that is my problem or is it Ethereal the makes a mistake? Should ethereal be able to see packets with FCS error? Shouldnt they have been retransmitted on the hardware level without the knowledge from the software?
ADDED:
I have noticed that the FCS error does not matter, I can receive that packets even if these error are present. What matters is if there is a route back to the sending node, if it is, the packets are delivered, else not, why???
All feedback is very appreciated, I'm becoming frustrated over this problem!
Best regards
Rickard
|
|
|
|
08-21-2008, 11:04 AM
|
#3
|
LQ Newbie
Registered: Sep 2007
Posts: 2
Rep:
|
Sounds like a switch error
Try disabling "Spanning Tree" on the switch.
|
|
|
All times are GMT -5. The time now is 11:14 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|