MAC Address Change Buggy

[Altera_Forum]

Hi, 

I encounted a problem I had to commit I could not solve on my own: platform: Altera / Quartus FPGA with TSE (triple-speed ethernet) with Altera drivers which are supported by uCLinux.  problem description:  - after booting HOST: MAC address is initially set (eg: 00-50-c3-75-81-03), setting IP (192.168.3.10) and netmask (255.255.255.0) OK --> ping from devCP works fine, also telnet, etc! - then change MAC address by executing: eth0 down, "ifconfig eth0 hw ether 00-50-c3-75-81-04", eth0 up --> ifconfig shows perfect values: new MAC, IP, netmask, even Ping from HOST succeeds ( "192.168.3.10 is alive!") - BUT: ping from devPC works NOT! Neither can I use the other services provided by the interface (telnet, ftp, etc.) tried to fix:  - other hardware, same problem - when resetting MAC to original value: everything works fine again! - cleared devPC ARP cache: after ping fails, the NEW MAC of the host machine is listed correctly!  Any ideas? Thanks in advance!

[Altera_Forum]

Hi, 

   --- Quote Start ---   - cleared devPC ARP cache: after ping fails, the NEW MAC of the host machine is listed correctly!   --- Quote End ---    After the clearing of the ARP table in your devPC, ping fails ?  Kazu

[Altera_Forum]

Hi, 

it fails before and after, means clearing the ARP cache is no solutiuon. But funny is: I CAN ping the host from the host itself!

[Altera_Forum]

Hi, 

   --- Quote Start ---   it fails before and after, means clearing the ARP cache is no solutiuon. But funny is: I CAN ping the host from the host itself!  --- Quote End ---    I recommend you to use a packet analyzer like 'WireShark'  https://www.wireshark.org/  and check the ether packet header whether it has the new Mac number or not. If it has your correct new address, I recommend you to check your phy chip. (Generally, ping packets which are sent to itself will not use physical layer.)  Kazu

[Altera_Forum]

Kazu, 

you've lead the way: the problem is, that after changing the MAC on the HOST, the Ping triggered ARP response returns the OLD MAC as source within its ETHERNET frame. The driver was customized by 3rd-Party and it seems like was not tested thoroughly and the network stack is corrupt.  Thanks for youe time.