<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Scott,<br>
<br>
Thanks for the reply.<br>
<br>
Firstly the illegal MAC address issue could be resolved by
implementing a correct "locally administered MAC address":<br>
<br>
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/MAC_address">https://en.wikipedia.org/wiki/MAC_address</a><br>
<br>
so starting the MAC with 0x02 or 0x06 etc. an example might be 0x06
0x06 0x06 0x06 0x06 0x06<br>
<br>
<br>
Next, I have tried the Angelia in several configurations here's what
I have found:<br>
<br>
a) single Netgear FS108 switch with SDR PC, Angelia, DHCP server
- works<br>
<br>
b) single Netgear FS116 switch with SDR PC, Angelia, DHCP server
- works<br>
<br>
c) multiple Netgear GS724 switch with SDR PC, Angelia, DHCP
server distributed - doesn't work<br>
<br>
d) single Netgear GS724 switch with SDR PC, Angelia, DHCP server
- doesn't work<br>
<br>
e) distributed system with PC on one GS724, DHCP server on
another GS724 (connected via trunk) and Angelia connected to either
switch - doesn't work<br>
<br>
f) distributed system with PC on one GS724, DHCP server on
another GS724 (connected via trunk) and Angelia connected to an
FS108 that was already powered on (before the Angelia) and connected
to one of the other two switches - works most of the time (works 7
times in 10)<br>
<br>
From what I can fathom, the Angelia appears to be happy with
un-manaeged 100Mbps links but either there is a problem with managed
switches, link attributes or timing ...?<br>
<br>
Does the Hermes/Angelia/Orion correctly detect link-down and link-up
events? I ask because I am not sure that un-plugging and
re-plugging the Ethernet on the Angelia causes a DHCP 'DISCOVER'
message and renegotiation to occur?<br>
<br>
I also note that the DHCP request send by Angelia (when it is sent)
is devoid of options ... it appears to be a "local lan" only
implementation since it doesn't ask for netmask and default
gateway... this suggests that the Ethernet and IP stack in Angelia
is "minimal" and assumes that it is only going to run on a
point-to-point on the same network segment? If so then tis is a
shame... I have two LANs 192.168.144.0/24 at my end of the house and
192.168.145.0/24 at the other end of the house. My firewall/server
box deals with this.<br>
<br>
To use my Angelia fully it needs to recognise if an IP address is
"outside" the netmask and send it to the default gateway instead ...
this shouldn't be terribly hard to implement with 32-bit work
comparisons in modern FPGAs ... just not sure anyone's bothered?<br>
<br>
<br>
Mike G8TIC<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 9/28/2016 11:22 PM, Scott Traurig
wrote:<br>
</div>
<blockquote
cite="mid:CAGK9zXppKzURvDeMQT=GOUrr3nWGmeZ3K4j=kibOT1a+5xMtXg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>Note: I had to trim the history on this reply because the
HPSDR list has an antiquated 12KB message size limit before
moderation...</div>
<div><br>
</div>
<div>~~</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">OK, thanks for throwing me under the bus,
Bryan--just kidding ;-)
<div><br>
</div>
<div>First, a point of clarification: the illegal MAC
address problem only happens when Hermes, Angelia or Orion
boards are in Bootloader mode. The Bootloader MAC
implementation advertises a MAC address of
11:22:33:44:55:66. I believe the intent of the developers
was to use a common MAC address in this mode as a
conservative measure in case anyone ever "lost" track of
their radio on the LAN and needed to find it by that
means. Unfortunately, they chose a MAC address that is not
legal and hence is refused by any Layer 2 or Layer 3
managed switch that I am aware of. So if you need to use
Bootloader mode you will have to make a direct connection
to the PC or use an un-managed switch. As, much like Mike,
I use all managed switches in my house, this is a huge
pain for me as I have to go to the switch and patch the PC
directly to the radio when using Bootloader. This can be a
frequent affair when testing beta firmware!</div>
<div><br>
</div>
<div>Now, when the radio is in a normal operational mode,
the MAC address is that associated with the manufacturer
of the PHY chip used on the Hermes/Angelia/Orion board,
and it is, of course, unique for every radio. It is a
completely legal MAC address in every respect.</div>
<div><br>
</div>
<div>As for the completeness of the MAC and IP layer
implementations in the firmware, I can't say for sure. I
can say that it has not failed to successfully negotiate
DHCP for me on my network on either the Angelia or the
Orion (I've not had the opportunity to try the Hermes).
Again, my network is similar to Mike's in that I have a
managed L2 Cisco switch in the shack which uplinks to an
L2 managed TP-Link switch at my server rack. DHCP comes
from my Ubiquiti Edgerouter also at the server rack.</div>
<div><br>
</div>
<div>Mike--might I suggest you take a look at the MAC
address tables in your switches (they are managed, after
all, so you should be able to) and see if the tables are
at least populating properly and that the MAC is
propagating correctly. You might find some obscure MAC
related setting in the switches is preventing this.
Another debug step might be to move the radio to the
switch near your DHCP server and see if it works there.</div>
<div><br>
</div>
<div>Let us know how you make out with those ideas.</div>
<div><br>
</div>
<div>73!</div>
<div><br>
</div>
<div>Scott/w-u-2-o</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>