High RxBadPkt on TL-SG108E

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

High RxBadPkt on TL-SG108E

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
33 Reply
Re:High RxBadPkt on TL-SG108E
2017-06-08 05:19:01
Same problems for me on SG108E V2.....
Hoping for a firmware update because i bought 2 of them.
  0  
  0  
#13
Options
Re:High RxBadPkt on TL-SG108E
2017-08-01 19:13:52
Same here on:










Firmware Version 1.0.0 Build 20160722 Rel.50167
Hardware Version TL-SG108E 3.0






  0  
  0  
#14
Options
Re:High RxBadPkt on TL-SG108E
2017-08-02 11:05:42
I have a 1.0, 2.0 and 3.0 version of this switch and all 3 are giving the same issue when VLANs are being used
  1  
  1  
#15
Options
Re:High RxBadPkt on TL-SG108E
2017-08-10 14:16:18

edegrave wrote

Model : TL-SG108E

Hardware Version : V1

Firmware Version : 1.1.2 Build 20141017 Rel. 50749

ISP :

I'm getting very high RxBadPkt on ports configured as VLAN access port. Setup is Router - Cisco switch - TP-Link01 - TP-Link02. Cisco shows no errors or dropped packages. On the trunk ports (Tagged) of the TP-link switches the RXBadPkt is the total count of the RxBadPkt packages connected to a configured access port ( Untagged 802.1Q PVID). Connecting the same device (laptop or AP) to a port without a configured PVID (so default PVID1) on either switch the RxBadPkt is 0 and stays 0. I'm not noticing bad performance on the access ports but the high RxBadPkt seems really strange. What could be the cause of this?



I asked tp-link for this problem some months ago.My model number is 108E V2. They said need not worry about this, This is the Statistical mechanism of chipset.
If the packet size is 64Byte, if this packet is untag, this packet is RxGoodPkt. If this packet is tagged, this packet is RxGoodPkt and Rx BadPkt.
In a word, every tagged packets, if the size is 64byte, will be be identified as bad packet. [B][/B]
  2  
  2  
#16
Options
Re:High RxBadPkt on TL-SG108E
2017-08-10 18:41:54

TPTHZ wrote

I asked tp-link for this problem some months ago.My model number is 108E V2. They said need not worry about this, This is the Statistical mechanism of chipset.
If the packet size is 64Byte, if this packet is untag, this packet is RxGoodPkt. If this packet is tagged, this packet is RxGoodPkt and Rx BadPkt.


If it is statistical only, they should change the column names to "RxTotalPkt" and "RxTaggedPkt" instead of "RxGoodPkt/RxBadPkt".
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#17
Options
Re:High RxBadPkt on TL-SG108E
2017-08-10 19:22:53

R1D2 wrote

If it is statistical only, they should change the column names to "RxTotalPkt" and "RxTaggedPkt" instead of "RxGoodPkt/RxBadPkt".

:(
They said the tagged 64byte packets be thought to be small packet(less than 64byte), So this packet is bad packet.....
The value of port statistic is get from register in chipset,so they can't change them.
The chipset of TL-SG108E V2 is RTL8370N. If other switch use this chipset,meybe will meet the same problem.
[h=2][/h]
  1  
  1  
#18
Options
Re:High RxBadPkt on TL-SG108E
2017-08-10 19:30:04
Hi


I have the same problem.


V 3.0














:mad:
  0  
  0  
#19
Options
Re:High RxBadPkt on TL-SG108E
2017-08-11 00:47:59

TPTHZ wrote


They said the tagged 64byte packets be thought to be small packet(less than 64byte), So this packet is bad packet.....


64 byte is the minimum required size for an Ethernet frame so that collision detect (CSMA/CD) will work. If a frame is tagged, additional 4 bytes for the VLAN will be appended to the frame header.

If an Ethernet frame is smaller than 60 bytes + 4 bytes frame checksum, it's a bad "packet" (actually, it's an Ethernet frame, not a packet!), no matter wether it is tagged or not. If RxBadPkt shows untagged Ethernet frames less than 60 bytes or tagged frames less than 64 bytes, than those are not only considered bad frames, but they actually are bad frames. Any NIC sending out data ensures, that smaller frames get padded to 60 bytes (without the 4 bytes FCS) at least. If such frames wouldn't be padded, CSMA/CD could not work properly.

See also: https://serverfault.com/questions/510657/is-the-64-byte-minimal-ethernet-packet-rule-respected-in-practice
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#20
Options
Re:High RxBadPkt on TL-SG108E
2019-10-27 20:45:16

Checking in on this one. I have the same problem on the TL-SG108PE. However, I think the comment that this is an erronisous error is incorrect. I also have a Unifi setup, and when ever a bad rx frame is recorded on the TPLINK, a bogus MAC is logged in the Unifi as 08:00:45:00:01:XX. Unifi says this is a bad IP header, (https://community.ui.com/questions/strange-MAC-addresses-in-insight-report/321e6759-0af5-4ef2-a3b9-985a7e5b1457#answer/0f1921c1-0394-4595-8939-38106a9c6d5e) so the TL-SG108PE is handling this packet poorly. By using the port monitoring on the TL-SG108PE interface I can see when a bad rx packet is logged and almost immidiately after the bogus MAC is logged in the Unifi interface.

 

TPLINK please resolve this issue.

 

Firmware Version 1.0.0 Build 20181120 Rel.40990
Hardware Version TL-SG108PE 2.0
  1  
  1  
#21
Options
Re:High RxBadPkt on TL-SG108E
2019-10-28 09:27:22

 

cool1two wrote

I also have a Unifi setup, and when ever a bad rx frame is recorded on the TPLINK, a bogus MAC is logged in the Unifi as 08:00:45:00:01:XX. Unifi says this is a bad IP header,

 

Of course a bogus MAC will be counted as a bad RX frame, nothing wrong with this. Which device does emit the bogus MAC in your network? According to the OUI it must be a device using a NIC produced from CONCURRENT COMPUTER CORP.

 

Anyway, the original discussion was about a bad RX frame count when using VLANs for frames with a valid MAC and this can be safely ignored according to TP-Link R&D.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
  0  
  0  
#22
Options