teensyMAC compiler error

Status
Not open for further replies.

Maes2ro

Active member
I am using the onboard Ethernet controller of a teensy 4.1, with a connected Magjack.

This works OK for most of my tests (with some issues), but as part of my diagnostic process, I would like to use the native MAC address of the internal controller, as I have had some problems with my own made-up addresses

I have found a number of references to the teensyMAC() function, however if I try and use it, I get a compiler error saying that the function is not declared in the scope, which I guess means it's not in the library. I believe that I've included the correct libraries, so I'm a bit puzzled.

I'm attaching the code I am using my test, which is a really simple modification to the sendreceiveUDP example.

Any help would be greatly appreciated.
 

Attachments

  • UDPSendReceiveString_teensynac.ino
    3 KB · Views: 58
Hi Mark.
Thank you for the speedy reply.
Does that thread imply that the teensyMAC function is not actually in the library already, and I have to add it myself?
 
@Maes2ro:

I have not created any actual projects with the Ethernet stuff yet (it's on my "playlist", but has not quite bubbled to the top), but my quick read seems to concur that you have to add that function to your sketch. Sorry I don't have a more definitive answer, but maybe someone with more first-hand experience will chime in . . .

Mark J Culross
KD5RXT
 
The example ethernet code shows the register "ENET_TCR" being set with bit "ENET_TCR_ADDINS". (This tells the MAC whether to use the loaded MAC or leave the packet as loaded by you.)

The example also shows loading the MAC into the IC using the "ENET_PALR" and "ENET_PAUR" registers.

If you load your own MAC into the IC, and set the ADDINS bit, the MAC should step on the 6 bytes of the source MAC with what you loaded into ENET_PALR and ENET_PAUR.

Also, the field "ENET_TCR_ADDSEL(n)" needs to be set appropriately.

What sort of problems are you seeing?
 
My system comprises 20 PC's, plus 18 pieces of my own hardware, each of which contains a 4.1. The purpose of the hardware is to provide a physical interface to my application programmes running on the PC's, the data being conveyed from the HMI via UDP. My network is entirely isolated and does not have DHCP.

I based the UDP part of my Teensy code on the SendRecieveUDP example, which shows a user supplied MAC and IP, so I went with this. To create the MAC's I used an online random MAC generator tool, and made myself 18 numbers.

What I have found is that some of these randomly generated MAC codes prevent the Ethernet service from starting properly, with the indicated failure from the example being 'Ethernet Cable not connected'. If I change the MAC number, this problem goes away. Of the 18 codes I generated, around 5 have failed in this way.

During the course of researching this phenomenon, I came across references to the internal MAC address of the 4.1 built-in ethernet controller, which seemed like a much better idea. This then led me to the teensyMAC function, which seemed like the ideal solution, but as you can see from my original post, there seems to be more to using it than I realised.

looking at the various threads on this forum, it looks like Teensyduino installs a version of the vjmusik NativeEthernet library and his fork of FNET but determining whether the teensyMAC function is actually part of this library, or what I need to do to enable/add it is way beyond my current experience level.

I would still very much like to use the internal address, but need more help I think.
 
I wouldn't make up MAC numbers randomly. There always exists the possibly of creating broadcast-matching addresses.

I'm not sure why you can't just use something like 01:01:01:01:01:01 thru 01:01:01:01:01:26.

I used to build LAN analyzers and spoofed any MAC any time (even broadcast-matches) without any issues.

What are the values of the 5 failed MACs?

There is an organization which assigns vendors MAC address ranges. Perhaps you could go to that site, pick a vendor-assigned range, and just spoof those.

You should also go thru the init code for the MAC. There may be an address detecting function enabled or disabled that you need to change.
 
Last edited:
Status
Not open for further replies.
Back
Top