[hpsdr] Hermes/Angelia and Ethernet problems

Wed Sep 28 15:15:48 PDT 2016

OK, thanks for throwing me under the bus, Bryan--just kidding ;-)

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!

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.

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.

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.

Let us know how you make out with those ideas.

73!

Scott/w-u-2-o

On Wed, Sep 28, 2016 at 7:30 AM, Bryan Rambo <bryanr at bometals.com> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
>
> Hi Mike,
>
> 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.
>
> Same thing Scott?
>
> 73, Bryan W4WMT
>
> ------------------------------
> *From:* Hpsdr [mailto:hpsdr-bounces at lists.openhpsdr.org] *On Behalf Of *Mike
> Tubby
> *Sent:* Saturday, September 17, 2016 3:36 PM
> *To:* hpsdr at openhpsdr.org
> *Subject:* [hpsdr] Hermes/Angelia and Ethernet problems
>
> 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.
>
> Currently I use the Angelia primarily on RX with CuSDR as I like the UI
> design and display.
>
> 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.
>
> In my setup I have:
>
> �������� 1. my workstation PC - Dell T3610, 16Gb, 6-core Xeon, etc. with
> Gigabit Ethernet
> �������� 2. my Linux server which is my default gateway and DHCP server
> �������� 3. my Angelia board
> �������� 4. Ethernet switch
> �������� 5. Various other devices (computers, VoIP phones, etc)
>
> 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. after which running up CuSDR on the PC works
> when I hit 'Start' it performs auto-detect, finds the Angelia and comes
> up...
>
> 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.
>
> 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.
>
> 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?�� Is the Ethernet
> implementation in Hermes and Angelia 'fragile' or incomplete?�� Is there
> a problem with link partner attributes? or timing when talking to managed
> switches?�� Does Hermes/Angelia assume that the link comes up very
> quickly and transmit DHCP request(s) too soon or without retries?
>
> Is there something that can be done about this?
>
> 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.
>
> I'm happy to spend some time collecting diagnostics/debug if this would
> help.
>
>
> Regards
>
>
> Mike G8TIC
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/
> listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20160928/d337106e/attachment.htm>