Assigning Spinneret MAC addresses

Phil Pilgrim (PhiPi) · 2011-03-13 14:48

When I programmed my first Spinneret, I used the MAC address that Beau provided in his SimpleServer example. When I got the second one, I knew it needed a different MAC address, so I just added one to the first one. Now I assume, if the Spinneret is not visible outside my local network (except via NAT), that it doesn't really matter what MAC address is used, so long as each MAC on the local network is unique. Right? Or is there more to it than that?

-Phil

schill · 2011-03-13 15:06

My Spinnerets have a sticker on the bottom that looks like a MAC address.

I don't know how they are determined.

Anyway, as long as they are distinct I think you can get away with anything within your own network.

Mike G · 2011-03-13 15:07

As I understand, the MAC address should be unique to the network. I use the ID printed on the under side of the Spinneret as the MAC address.

Phil Pilgrim (PhiPi) · 2011-03-13 15:12

My Spinnerets have a sticker on the bottom that looks like a MAC address.

Oh. You're right. My first one was an early proto and did not have that sticker. So I never looked for it on the new one. That being the case, why does the W5100 initAddresses method require one to specify a MAC address if one is already hardwired in? And what does it really change, in that case?

-Phil

Mike G · 2011-03-13 15:19

I wondered that too. Since the sticker had the MAC, I just assumed that's the way Parallax ordered the W5100 chips. Or that's just the way the W5100 ships.

schill · 2011-03-13 15:29

A search on the net indicates that the 00:08:DC prefix is allocated to Wiznet. Both the Spinnerets in front of me have those first 3 bytes on the sticker. I didn't think Wiznet assigned MAC addresses but I guess they do provide them.

mindrobots · 2011-03-13 18:26

MAC addresses are meaningless outside of a physical network segment. They are used to map an IP address to a network interface and are used to resolved addressing on the physical layer. ONce you leave your network segment (get routed), you should be unique by your IP address. IP addresses need to be unique on an internet. Providing unique MAC addresses assigned by vendor should prevent the problem of having two hardware interfaces with the same MAC address on the same segment - if this happens, then the layer2 protocol can't resolve the addresses to individual hardware interfaces.

You can plug any MAC address into your device you want as long as you keep track on your physical segment and don't duplicate MAC addresses....but it's easier to use your assigned addresses.... much less chance of conflict.

Hope this helps.

Rick

Ariba · 2011-03-15 03:58

Phil Pilgrim (PhiPi) wrote: »

...That being the case, why does the W5100 initAddresses method require one to specify a MAC address if one is already hardwired in? And what does it really change, in that case?
-Phil

The MAC address is not hardwired in the W5100 chip. You need to write it to the W5100 in the init phase of the program. They just provide you a personal worldwide unique address on the sticker.

Andy

Beau Schwabe · 2011-03-18 23:53

Phil Pilgrim (PhiPi)

When I programmed my first Spinneret, I used the MAC address that Beau provided in his SimpleServer example.

... No wonder I keep seeing everything your testing ... I got so many partial strip charts, it's not even funny .... j/k

Ok, yeah, use the MAC address labeled on the bottom of your spinneret ... if you have an older version that doesn't have a MAC label, I would 'borrow' one from an old PC that has been retired (...or just an old Ethernet card I don't plan on using anytime soon. Personally I have a few lying around.)

xanadu · 2011-03-19 16:22

I would just like to add (sorry if someone else did and I missed it) this about MAC addressing on your LAN, and how important it is for any communication to take place, and its configuration.

When you assign your Spinneret an IP and/or MAC, you MAY need to flush your ARP cache **especially when changing its MAC**. Here is a great way to check:

Run this command from command prompt without quotes "arp -a xxx.xxx.xxx.xxx" where x = Spinneret IP and please make absolutely sure that the same MAC you assign to your Spinneret is displayed in the output of the arp -a command. That should mean at least your workstation can talk to the Spinneret, that's all it means since you're running the command from the workstation.

There are many different devices on a network that utilize ARP cache. Most router/switches just need to be powered off to flush it. Computers, operating systems, other network devices just google how to clear their ARP cache. IF you do not see a MAC associated with the IP, you may experience comm failure.

PLEASE just reboot everything on your network every time you make changes to the Spinneret, you have to make sure those changes propagate on the network.

Here is the working output from mine-

\Users\xanadu>arp -a 192.168.3.33

Interface: 192.168.3.148 --- 0x8
Internet Address Physical Address Type
192.168.3.33 00-08-dc-16-ef-81 dynamic

Chip Cox · 2011-03-19 21:02

put this in the category of nice to have for the next version of the spinneret. Could we have a switch that would allow us to either use a pre-configured known unique vendor supplies mac address, or in the other position, allow us to assign our own through our code ( trying to get the best of both worlds here )? If this got sent out to users, I could see it being a pain for them having to assign a mac address. For some of the ideas being bounced around in the forum, it would not be unusual to have several of these in a house. Having the code have a hard coded default MAC would be problematic. We can get around the IP address issue by using DHCP for addresses, but I don't know of a MAC server where we can get dynamic known good addresses on the fly <grin>.

Mike G · 2011-03-19 22:09

Could we have a switch that would allow us to either use a pre-configured known unique vendor supplies mac address, or in the other position, allow us to assign our own through our code ( trying to get the best of both worlds here )?

It would be nice if WIZNet assigned the MAC. It could be that WIZNet expected the OEM to handle the MAC.

We can get around the IP address issue by using DHCP for addresses, but I don't know of a MAC server where we can get dynamic known good addresses on the fly

MAC addresses are assigned by hardware manufacturers.

kuisma · 2011-03-20 00:00

Don't bother so much about the MAC addresses. Only make sure the first byte is even, i.e. the address begins with 00, 02, 04 or so, and then chose whatever random numbers.

jstjohnz · 2011-03-30 18:36

My solution to the MAC problem is as follows. Since my project could involve many WIZ modules on the same lan, I need a MAC-assigning system that's fairly foolproof and automatic. I use the prefix 4A:49:4D on all my MAC addresses. The MAC address is stored in the eeprom (I use 64KB eeproms) above $8000. At bootup, I check the 1st 3 bytes to see if they match the expected 4A:49:4D sequence. If not, I fire up a cog to run the random number generator from the OBEX, and I use it to generate 3 random numbers, for the last 3 bytes of the MAC address; and then I write the full 6-byte mac address (4A:49:4D + 3 randoms) to the eeprom.

This gives me a total of 16 million possible MACs, so even with dozens of WIZ modules on a LAN there is a very low probability of duplication. It's also automatic in that whenever I use a new eeprom, it gets a mac assigned at the first bootup.

          if mac[0]==$4A                'test 1st 3 bytes to see if this is one of ours
            if mac[1]==$49
              if mac[2]==$4D
                return                       'return, existing mac from eeprom is legit 
                                                 'else we need to make a new mac address
          macbyte:=rr.start            'start the rng
          mac[0]:=$4A                   'set 1st 3 bytes to our pre-defined randomly selected sequence
          mac[1]:=$49
          mac[2]:=$4D
          mac[3]:=rr.random          'get the last 3 bytes from the rng
          mac[4]:=rr.random
          mac[5]:=rr.random
          rr.stop                             'then shut it down to free the cog
                                                 'now write the new mac address to the eeprom before returning
          repeat macbyte from 0 to 5
               eeprom.writelong (_eeprompin,_eepromsel,_eeprombase+_eeprommacadd+macbyte*4,mac[macbyte]) 'write a byte of the mac
               delay5

xanadu · 2011-03-31 00:30

Pardon me if I'm mistaken but what about subsequent bootups? Is this in conjunction with DHCP or a static IP?

You'll have a stale ARP cache if you use dynamic MAC addressing without using an ARP look-up to assign it. That applies to any layer 2 device.

jstjohnz · 2011-03-31 13:37

xanadu wrote: »

Pardon me if I'm mistaken but what about subsequent bootups? Is this in conjunction with DHCP or a static IP?

You'll have a stale ARP cache if you use dynamic MAC addressing without using an ARP look-up to assign it. That applies to any layer 2 device.

On subsequent bootups the code sees that a valid mac address already exists and leaves it alone. It's only the 1st time the program runs with a blank eeprom that a mac address is created. I guess it's a bit confusing as I posted it since I didn't show that, prior to the code segment shown, the mac address is read from the eeprom into the MAC array.

Assigning Spinneret MAC addresses

Comments