I ran into a strange problem with IP65 running on Apple //e with
Uthernet-II. The IP65 code hard-codes the Uthernet-II MAC in the file
drivers/w5100.s to value 00:08:DC:A2:A2:A2. However, when I run an IP65
program such as DATE65, it sometimes makes its DHCP request with this MAC
and sometimes some other MAC (usually 00:08:DC:11:11:11, which just so
happens to be the default for Contiki. I don't see anything fishy in the
code, and I can't explain this behaviour.

In an effort to investigate I ran the PLASMA 2.0 'httpd' demo, which has
it's own IP stack and uses some other value for the MAC. After running the
PLASMA httpd, I then ran IP65 and it used MAC 00:08:DC:A2:A2:A2, as coded.
A few runs later it was back to :11:11:11. Could be random, I don't have
enough datapoints to know for sure.

The reason I am messing with this is I have more than one Apple II with
Uthernet II on my LAN, and I can't have them using the same MAC ;) I was
thinking to add the MAC address to the ETHERNET.SLOT file that IP65 uses.
However, first I need to get it using the correct MAC as coded.

Hoping Oliver Schmidt gets to read this and can give me an idea what is
going on.

All the best,
Bobbi
(this message sent with Emai//er, using IP65)

Hi,

> However, when I run an IP65
> program such as DATE65, it sometimes makes its DHCP request with this MAC
> and sometimes some other MAC (usually 00:08:DC:11:11:11, which just so
> happens to be the default for Contiki.

This isn't a question of IP65 vs Contiki but a question of old vs. new.
Both IP65 and Contiki use the exact same driver. At some point I changed
the MAC from ...:11 to ...:A2. So you have an old Contiki and a new IP65.

> I don't see anything fishy in the
> code, and I can't explain this behaviour.

I can't explain this too. I must admit that I question that your experience
is EXACTLY the one you describe - but that doesn't matter after all.

> The reason I am messing with this is I have more than one Apple II with
> Uthernet II on my LAN, and I can't have them using the same MAC ;) I was
> thinking to add the MAC address to the ETHERNET.SLOT file that IP65 uses.

There's no need to hack that driver to do that. On initialization the
driver checks the W5100 register $001A (which has the power-up default $55)
for the value $06. If that value is found it does not use its own MAC
address but the one found in the W5100 registers $0009-$000E (and leaves
$001A at $06).

Please note that the driver does NOT(!) set the register $001A to $06 when
it finds it to have the power-up default $55. Rather it sets it to $1A.

So the driver will never enter this "MAC re-use" mode by itself. You need
to explicitly set it before initializing the driver once e.g. with a
specific MAC-Set program. But then the driver will stay in that MAC re-use
mode over several initializations - until a Ctrl-Reset or power cycle.

> Hoping Oliver Schmidt gets to read this and can give me an idea what is
> going on.

The usual way to contact a person is to write an email - but I guess that
you as an author of SMTP / POP3 software know that ;-)

Regards,
Oliver

Hi Oliver - thanks for your detailed reply! I would have emailled, but I
couldn't find your address!

I guess I will write a little MAC-set program using the info you provided.
Sounds like I should update my Contiki too!

All the best,
Bobbi

Oliver Schmidt <ol.sc@web.de> wrote:

>Hi,
>
>> However, when I run an IP65
>> program such as DATE65, it sometimes makes its DHCP request with this MAC
>> and sometimes some other MAC (usually 00:08:DC:11:11:11, which just so
>> happens to be the default for Contiki.
>
>This isn't a question of IP65 vs Contiki but a question of old vs. new.
>Both IP65 and Contiki use the exact same driver. At some point I changed
>the MAC from ...:11 to ...:A2. So you have an old Contiki and a new IP65.
>
>> I don't see anything fishy in the
>> code, and I can't explain this behaviour.
>
>I can't explain this too. I must admit that I question that your experience
>is EXACTLY the one you describe - but that doesn't matter after all.
>
>> The reason I am messing with this is I have more than one Apple II with
>> Uthernet II on my LAN, and I can't have them using the same MAC ;) I was
>> thinking to add the MAC address to the ETHERNET.SLOT file that IP65 uses.
>
>There's no need to hack that driver to do that. On initialization the
>driver checks the W5100 register $001A (which has the power-up default $55)
>for the value $06. If that value is found it does not use its own MAC
>address but the one found in the W5100 registers $0009-$000E (and leaves
>$001A at $06).
>
>Please note that the driver does NOT(!) set the register $001A to $06 when
>it finds it to have the power-up default $55. Rather it sets it to $1A.
>
>So the driver will never enter this "MAC re-use" mode by itself. You need
>to explicitly set it before initializing the driver once e.g. with a
>specific MAC-Set program. But then the driver will stay in that MAC re-use
>mode over several initializations - until a Ctrl-Reset or power cycle.
>
>> Hoping Oliver Schmidt gets to read this and can give me an idea what is
>> going on.
>
>The usual way to contact a person is to write an email - but I guess that
>you as an author of SMTP / POP3 software know that ;-)
>
>Regards,
>Oliver
>
>
>
>.
>

Hi again Oliver,

Setting the MAC and setting register $001a to $06 works perfectly with
IP65. However with Contiki I am still getting :11:11:11. I tested with
WEBBROWS.SYSTEM.

I checked the version of Contiki I am running and it is the release from
2019-05-08. I am not sure if there is a more recent one -- if so, I wasn't
able to find it.

Is there a newer build I can grab from somewhere?

All the best,
Bobbi

Oliver Schmidt <ol.sc@web.de> wrote:

>Hi,
>
>> However, when I run an IP65
>> program such as DATE65, it sometimes makes its DHCP request with this MAC
>> and sometimes some other MAC (usually 00:08:DC:11:11:11, which just so
>> happens to be the default for Contiki.
>
>This isn't a question of IP65 vs Contiki but a question of old vs. new.
>Both IP65 and Contiki use the exact same driver. At some point I changed
>the MAC from ...:11 to ...:A2. So you have an old Contiki and a new IP65.
>
>> I don't see anything fishy in the
>> code, and I can't explain this behaviour.
>
>I can't explain this too. I must admit that I question that your experience
>is EXACTLY the one you describe - but that doesn't matter after all.
>
>> The reason I am messing with this is I have more than one Apple II with
>> Uthernet II on my LAN, and I can't have them using the same MAC ;) I was
>> thinking to add the MAC address to the ETHERNET.SLOT file that IP65 uses.
>
>There's no need to hack that driver to do that. On initialization the
>driver checks the W5100 register $001A (which has the power-up default $55)
>for the value $06. If that value is found it does not use its own MAC
>address but the one found in the W5100 registers $0009-$000E (and leaves
>$001A at $06).
>
>Please note that the driver does NOT(!) set the register $001A to $06 when
>it finds it to have the power-up default $55. Rather it sets it to $1A.
>
>So the driver will never enter this "MAC re-use" mode by itself. You need
>to explicitly set it before initializing the driver once e.g. with a
>specific MAC-Set program. But then the driver will stay in that MAC re-use
>mode over several initializations - until a Ctrl-Reset or power cycle.
>
>> Hoping Oliver Schmidt gets to read this and can give me an idea what is
>> going on.
>
>The usual way to contact a person is to write an email - but I guess that
>you as an author of SMTP / POP3 software know that ;-)
>
>Regards,
>Oliver
>
>
>
>.
>

Hi,

>Setting the MAC and setting register $001a to $06 works perfectly with
>IP65.

Great :-)

>However with Contiki I am still getting :11:11:11. I tested with
>WEBBROWS.SYSTEM.
>
>I checked the version of Contiki I am running and it is the release from
>2019-05-08. I am not sure if there is a more recent one -- if so, I wasn't
>able to find it.

No, that's the right one. It contains a file W5100.ETH which contains
at offset $6E the sequence 00:08:DC:A2:A2:A2.

Do you happen to use ADTPro VEDRIVE
(http://adtpro.sourceforge.net/vedrive.html)? It sets the W5100
register $001A to $06
(https://github.com/ADTPro/adtpro/blob/master/src/client/prodos/ethernet/drive/vedrive_high.asm#L1062)
thus causing subsequently loaded IP65/Contiki programs to not use
"their" MAC address.

Regards,
Oliver

I made a little utility for setting the MAC of the Uthernet-II, which I am
calling SETMAC.SYSTEM. It can be installed in the volume directory (ie:
the top level dir) of a ProDOS boot volume and it will automatically run on
startup, and chain the next .SYSTEM file in the same way as
NS.CLOCK.SYSTEM.

You can find docs here:
https://github.com/bobbimanners/emailler/apps/setmac/README-setmac.md

The software is included in the Emai//er 2.1.5 release here:
https://github.com/bobbimanners/emailler/releases

Oliver - you are right that ADTPro (and VEDRIVE) does not currently support
this convention. I am hoping that this may be fixed in the next release of
ADT though :)

All the best,
Bobbi

ol.sc@web.de (Oliver Schmidt) wrote:

>Hi,
>
>>Setting the MAC and setting register $001a to $06 works perfectly with
>>IP65.
>
>Great :-)
>
>>However with Contiki I am still getting :11:11:11. I tested with
>>WEBBROWS.SYSTEM.
>>
>>I checked the version of Contiki I am running and it is the release from
>>2019-05-08. I am not sure if there is a more recent one -- if so, I wasn't
>>able to find it.
>
>No, that's the right one. It contains a file W5100.ETH which contains
>at offset $6E the sequence 00:08:DC:A2:A2:A2.
>
>Do you happen to use ADTPro VEDRIVE
>(http://adtpro.sourceforge.net/vedrive.html)? It sets the W5100
>register $001A to $06
>
>
>
>
>
>
>
>

Hi,

>Oliver - you are right that ADTPro (and VEDRIVE) does not currently support
>this convention.

ADTPro is using IP65 - and as such it is supposed to support the
convention. The last time I fiddled with ADTPro, it did for sure.

VEDRIVE is the very reason, why I introduced the convention in the
first place. The convention allows any program following it to use the
Uthernet II card simultaneously with VEDRIVE.

That something like your SETMAC is possible is a bare side effect I
noticed afterwards.

>I am hoping that this may be fixed in the next release of
>ADT though :)

As far as I see it is conceptually possible to make VEDRIVE support
something like your SETMAC. However, I don't see me - the author of
VEDRIVE - making any changes to it in the foreseeable future.

Regards,
Oliver