MAC address matching with M5223X

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

MAC address matching with M5223X

5,122 次查看
mjbcswitzerland
Specialist V

Hi All

I was playing around with the M52235EVB today.

I set several MAC addresses and checked that ARP, ping  and an embedded web server were working correctly.

These are the addresses which I used:

00-00-00-00-00-00
00-00-00-00-00-11
00-00-00-00-11-22
00-00-11-22-33-44
00-11-22-33-44-55
11-22-33-44-55-66
66-55-44-33-22-11

In each case ARP works fine. The device responds to the broadcast with its MAC address (as shown in the list) and the PC then displays the IP/MAC combination in its ARP table (I delete the ARP table in the PC with arp -d between tests)

In each case pings and the web browser operate correctly with the exception of the MAC address 11-22-33-44-55-66. No frames are received with the MAC destination, only broadcasts.

Can any one reproduce this or explain why the one address (or some sort of combinations) would not work?

Many thanks for ideas.

Regards
 
Mark Butcher


标签 (1)
0 项奖励
回复
4 回复数

1,193 次查看
DrSeuss
Contributor I
This is a multicast address, and the syptoms are consistent with this.
The address really should not be used. To be safe, always make the first octet a zero (never odd!)
0 项奖励
回复

1,193 次查看
mjbcswitzerland
Specialist V

Thanks Doc

But has this to do with the operation of the MAC compare unit, even when all unicast and multcast features are disabled in the EMAC? I was expecting it to simply do a compare of the 48 bit MAC and either match it with the value programmed or reject it. This must mean that it is more than just a 48 bit comparator working there...(?).

Regards

Mark
www.mjbc.ch

0 项奖励
回复

1,193 次查看
DrSeuss
Contributor I

I misspoke in that I was thinking of pause frames  (01:80:C2:00:00:01).

Perhaps, this is an error that has been worked around for a long time. It is possible that the FEC trashes ANY frame with an odd first oclet.

I am referring to sec 18.4.8 in the specification. Per flow chart it appears that ANY odd first oclet is assumed to be a pause frame. There is more going one than a simple compare.

Can you run your test again to determine if all odd first oclets are trashed?

What about the pause frame above?

0 项奖励
回复

1,193 次查看
DrSeuss
Contributor I
I spoke this the experts this morning and it was explained to me that the pause frames are just special forms of the mulitcast.
 
The ColdFire_lite stack does not use the Group Hash table so any address with the odd first oclet is ignored. This configuration is in the ifec.c driver.
0 项奖励
回复