<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><br></div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 7:30 AM, Bryan Rambo <span dir="ltr"><<a href="mailto:bryanr@bometals.com" target="_blank">bryanr@bometals.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">***** High Performance Software Defined Radio Discussion List *****<br>
<br>
<br><u></u>



<div bgcolor="#ffffff" text="#000000">
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"><span>Hi Mike,</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"><span></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"><span>Scott should jump in here with this one.  But I 
wonder if this has something to do with the "illegal Angelia MAC address" issue, 
reported here previously, that causes problems with managed switches that will 
reject such a MAC.  Apparently, cheaper less sophisticated, unmanaged 
switches will blissfully pass the illegal MAC and everything works fine 
again.</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"><span></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"><span>Same thing Scott?</span></font></div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"><span></span></font> </div>
<div dir="ltr" align="left"><font color="#0000ff" face="Arial"><span>73, Bryan W4WMT</span></font></div><br>
<div dir="ltr" lang="en-us" align="left">
<hr>
<font size="2" face="Tahoma"><b>From:</b> Hpsdr 
[mailto:<a href="mailto:hpsdr-bounces@lists.openhpsdr.org" target="_blank">hpsdr-bounces@lists.<wbr>openhpsdr.org</a>] <b>On Behalf Of </b>Mike 
Tubby<br><b>Sent:</b> Saturday, September 17, 2016 3:36 PM<br><b>To:</b> 
<a href="mailto:hpsdr@openhpsdr.org" target="_blank">hpsdr@openhpsdr.org</a><br><b>Subject:</b> [hpsdr] Hermes/Angelia and Ethernet 
problems<br></font><br></div>
<div></div>I have an Angelia board that I purchased from Anan about 18 months 
ago which I use as an SDR in my home 2m DX station on a 28MHz transverter IF and 
also use in the field with our contest group.<br><br>Currently I use the Angelia 
primarily on RX with CuSDR as I like the UI design and display.<br><br>The 
problem that I have with the Angelia is that it appears to be very 'touchy' 
(unreliable) with its Ethernet connection, obtaining a DHCP lease and talking to 
my PC.<br><br>In my setup I have:<br><u></u><u></u><br><span>�������� </span>1. my workstation PC - Dell T3610, 
16Gb, 6-core Xeon, etc. with Gigabit Ethernet<u></u><u></u><br><span>�������� </span>2. my Linux server which is my default 
gateway and DHCP server<u></u><u></u><br><span>�������� 
</span>3. my Angelia board<u></u><u></u><br><span>�������� </span>4. Ethernet switch<br>�������� 5. 
Various other devices (computers, VoIP phones, 
etc)<u></u><u></u><br><u></u><u></u><br>If I connect everything in the shack via an 
old Netgear FS116 unmanaged 10/100Mbps switch then everything works fine - the 
Angelia performs Ethernet link negotiation and comes up, sends DHCP request, 
gets reply, sets up IP address, etc.<span> after which 
</span>running up CuSDR on the PC works when I hit 'Start' it performs 
auto-detect, finds the Angelia and comes up...<u></u><u></u><br><br>However this 
network set-up isn't practical for a range of reasons...�� I have a rack of 
servers in the garage and that's also where the internet comes in.�� I have have 
a machine (called "gate") that provides network services, firewall, NAT, NTP, 
DHCP etc. in the garage.<br><br>I have my main PC, the wife's PC, network 
printers, VoIP phones, etc. in the study/shack.�� At both ends there's a Netgeat 
GSM724T 24-port switch and a Gigabit fibre trunk runs between the 
switches.<br><br>If I plug the Angelia and my shack PC in to two ports of the 
switch in the shack and watch the DHCP server on gate with "dhcpdump" then I see 
my PC perform DHCP request, get a reply and come up as expected but when I turn 
the Angelia on I see nothing?�� What gives?<span>�� 
</span>Is the Ethernet implementation in Hermes and Angelia 'fragile' or 
incomplete?<span>�� </span>Is there a problem with 
link partner attributes? or timing when talking to managed switches<span>?�� </span>Does Hermes/Angelia assume that the link 
comes up very quickly and transmit DHCP request(s) too soon or without 
retries?<u></u><u></u><u></u><u></u><br><br>Is there something that can be done about 
this?<span><br><br>I really want to be able to use the 
Angelia from one or other of two locations in the house on the same local 
(switched) Ethernet.<br></span><u></u><br>I'm happy to spend some time collecting 
diagnostics/debug if this would help.<br><br><br>Regards<br><br><br>Mike 
G8TIC<br><u></u></div>
<br>______________________________<wbr>_________________<br>
HPSDR Discussion List<br>
To post msg: <a href="mailto:hpsdr@openhpsdr.org">hpsdr@openhpsdr.org</a><br>
Subscription help: <a href="http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org" rel="noreferrer" target="_blank">http://lists.openhpsdr.org/<wbr>listinfo.cgi/hpsdr-openhpsdr.<wbr>org</a><br>
HPSDR web page: <a href="http://openhpsdr.org" rel="noreferrer" target="_blank">http://openhpsdr.org</a><br>
Archives: <a href="http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/" rel="noreferrer" target="_blank">http://lists.openhpsdr.org/<wbr>pipermail/hpsdr-openhpsdr.org/</a><br></blockquote></div><br></div></div></div>