Description

We're lacking a style guideline both for the C# code and the Sphinx doc generation.

Impact

It will keep the code clean and concise for all devs

Proposed solutions

• provide a document with the desired guidelines
• settle upon a .editorconfig for all file types
• create appropriate resharper code formatter
• define linter / formatter rules as appropriate
• run linter as part of build step

We're lacking a PR template, we should create one

Description

Gulliver has a new version out. Arcus should use it.

Impact

Keep things up to date.

Description

Need to add a security.md file as described: https://snyk.io/blog/ten-git-hub-security-best-practices/

Impact

A tab will be added to our repository on Github with this information.

Additional context

See electrons: https://github.com/electron/electron/security/policy

After discovering stackoverflow "NuGet Package Icon Not getting Displayed" it appears that the PackageIcon csproj directive is not respected by the Nuget PackageManager within Visual Studio a documented issue that appears to be getting attention.

• In theory icon and iconUrl are deprecated, but supported by both NuGet site and Nuget PackageManager within Visual Studio
• Embedded icon, packageIcon is not supported by Nuget PackageManager within Visual Studio, but is supported by the NuGet site.

I would have to assume embedding and iconUrl will conflict, but experimentation is required.

use psake to create basic build

Description

Arcus should :

• Provide the ability to determine if a given IPAddress is in private or public space (boolen)
• Provide the ability to determine if a given IIPAddressRange is entirely in public, private space, or both public and private space.

See

• wikipedia private network
• IANA IPv4 address space
• IANA IPv6 address space

Warnings are generated on packing due to deprecated configuration

• warning NU5125: The 'licenseUrl' element will be deprecated. Consider using the 'license' element instead. [XXXX\Arcus\src\Arcus\Arcus.csproj]
• warning NU5048: The 'PackageIconUrl'/'iconUrl' element is deprecated. Consider using the 'PackageIcon'/'icon' element instead. Learn more at https://aka.ms/deprecateIconUrl [XXX\Arcus\src\Arcus\Arcus.csproj]

Description

Arcus should

• Provide a MAC Address (MAC-48, and EUI-48) object
  • contains a byte array
  • implement IFormattable stringifying to common MAC Address formats
  • constructed via byte array
  • constructed via parsing recognized string formats
  • be serializable
  • provide basic mac information as seen fit / applicable

see wikipedia mac address

Source is not available in Visual Studio 2019 community edition.

Description

A legacy use of a MAC Address is to convert it to a EUI-64.

This will allow us to also support the legacy modification of a EUI-64 as the least-significant 64 bits of a unicast network address or link-local address when stateless address autoconfiguration is used.

Eg. MAC Address to IPv6

Proposed solutions

There are several sources that say several things about this mapping; it is unclear which is "most" correct, or what the variants imply.

It seems odd that each of the 3 below mentioned very specifically outlining differing rules for what would seem to be the same operation. While IEEE is the definitive source, I'd like to determine the reasoning of the other implementations before moving forward. The differing schemes may be perfectly valid in the appropriate place.

All this for a known legacy operation 🤷

Networking Engineering StackExchange

(current implementation)
Answer to "What are EUI-48 and EUI-64?"
states that the insertion bytes should be [0xFF, 0xFE] and 7th bit should be inverted.

Wikipedia entry for "Mac Address"

Mac Address. Citation Note 6
states that the insertion bytes should be [0xFF, 0xFE] if the source is a EUI-48
and that the insertion bytes should be [0xFF, 0xFF] if the source is a MAC-48
(no inversion of any bits mentioned)

IEE

IEEE in "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)" section "Mapping an EUI-48 to an EUI-64" (pg 15)
states that the insertion bytes should be [0xFF, 0xFE] or [0xFF, 0xFF]
(no inversion of any bits mentioned)

Can you help?

Maybe? Gotta clear some things up and do some research

Code

What follows is the "StackExchange" implementation. This exists simply because it is what I first encountered before researching further. By no means is it the "correct" solution, it is simply correct as to the implied spec.

/// <summary>Gets a mapping of the Mac Address as a EUI-64</summary>
/// <remarks><para>Note that this mapping is considered deprecated, and is implemented for legacy needs</para></remarks>
/// <remarks><para>The implementation of this method is under question</para></remarks>
/// <returns>an array of bytes representing the EUI-64 of the MAC Address</returns>
[NotNull]
[Obsolete("This method is obsolete until the desired output can be verified")]
public byte[] GetEui64AddressBytes()
{
   // To generate a EUI-64 from the EUI-48
   // - divided EUI-48 int two 3-byte parts; OUI & CID
   // - insert the value 0xFFFE between the two parts (24th bit)
   // - Invert the 7th bit of the result

   var eui64 = new byte[8];
   Array.Copy(this._address, 0, eui64, 0, 3);  // first 3 bytes od address
   eui64[3] = 0xFF;
   eui64[4] = 0xFE;
   Array.Copy(this._address, 3, eui64, 5, 3);  // last 3 bytes of address

   // invert the 7th bit
   if ((eui64[0] & 0b0000_0010) != 0)  // 7th bit (big-endian) is set, it should be cleared
   {
         eui64[0] &= 0b1111_1101;    // clear the 7th bit
   }
   else  // 7th bit (big-endian) is not set, it should be set
   {
         eui64[0] |= 0b0000_0010;    // set the 7th bit
   }

   return eui64;
}

Tests

public static IEnumerable<object[]> GetEui64AddressBytes_Test_Values()
{
   yield return new object[] { new byte[] { 0x02, 0x21, 0x86, 0xFF, 0xFE, 0xB5, 0x6E, 0x10 }, MacAddress.Parse("00:21:86:B5:6E:10") };
   yield return new object[] { new byte[] { 0xFD, 0x21, 0x86, 0xFF, 0xFE, 0xB5, 0x6E, 0x10 }, MacAddress.Parse("FF:21:86:B5:6E:10") };
   yield return new object[] { new byte[] { 0xC2, 0xFF, 0xEE, 0xFF, 0xFE, 0xCA, 0xFE, 0x00 }, MacAddress.Parse("C0:FF:EE:CA:FE:00") };
}

[Theory]
[MemberData(nameof(GetEui64AddressBytes_Test_Values))]
public void GetEui64AddressBytes_Test(byte[] expected, MacAddress input)
{
   // Arrange
   // Act
   var result = input.GetEui64AddressBytes();

   // Assert
   Assert.IsType<byte[]>(result);
   var addressBytes = input.GetAddressBytes();

   Assert.Equal(8, result.Length);
   Assert.NotEqual(expected[0] & 0b10, addressBytes[0] & 0b10);
   Assert.Equal(0xFF, result[3]);
   Assert.Equal(0xFE, result[4]);
   Assert.Equal(0, ByteArrayUtils.CompareUnsignedBigEndian(expected, result));
}

Describe the bug

Iconography PR broke readme:

Expected behavior

An icon not a broken image tag

Describe the bug

Expected behavior

For the shield to not be borked so frequently

Example of how to Reproduce

Load the readme in GitHub

Description

Arcus is missing in-the-box support for Subnets defined by and expressing traits of the accepted IPv4 Classful Network. It is desired that Arcus should provide legacy support for A, B, C, with a possibility for D (multicasting) and E classful networks.

Arcus should:

• Allow the Subnet object to be constructed, either via constructor or a factory, by issuing an appropriate IP Address and class specifier
• Subnet should have a property dictating its class if it is IP4 and meets the appropriate class
• It should be possible to translate between IP Address netmasks and class A, B, and C

Describe the bug

When going through the release process the .snupkg file fails to upload to NuGet

Expected behavior

I expect to be able to deploy w/o issue.

Subnet and IPAddressRange should implement ISerializable, be decorated by SerializableAttribute and have custom serialize logic.

Subnet should serialize head address bytes and routing prefix
IPAddressRange should serialize head address bytes and tail address bytes

CA1036 states that IPAddressRange and Subnet should override the comparison operators, specifically op_Equality, op_Inequality, op_LessThan and op_GreaterThan.

Add less than or equal to and greater than or equal to so as not to disappoint

create read the docs documentation with Sphinx

Description

"The Internet Engineering Task Force (IETF) points out that "Master-slave is an oppressive metaphor that will and should never become fully detached from history" as well as "In addition to being inappropriate and arcane, the master-slave metaphor is both technically and historically inaccurate." There's lots of more accurate options depending on context and it costs me nothing to change my vocabulary, especially if it is one less little speed bump to getting a new person excited about tech." - Scott Hanselman

Impact

This can/will affect builds and document generation. All external items pointing to master branch should be updated.

Description

Markdown 1. numbering fails when actually making the PR.

Impact

Looks stupid

Proposed solutions

While not conveneient when reordering markdown will respect human numbered lists:

etc.

Can you help?

I can

Readme should include the Arcus icon and link to Gulliver. Also the copyright notice is in a code block and looks ugly. License might also be code and need to change too.

Describe the bug

the RegEx

^(?:[0-9A-Fa-f]{2}([-: ]?))(?:[0-9A-Fa-f]{2}\1){4}[0-9A-Fa-f]{2}$|^(?:[0-9A-Fa-f]{4}\.){2}[0-9A-Fa-f]{4}$|^(?:[0-9A-Fa-f]{3}\.){3}[0-9A-Fa-f]{3}$

was (poorly) optimized to

^[\dA-F]{2}([ -:]?)(?:[\dA-F]{2}\1){4}[\dA-F]{2}$|^(?:[\dA-F]{4}\.){2}[\dA-F]{4}$|^(?:[\dA-F]{3}\.){3}[\dA-F]{3}$`

RegEx to Strings
regexp-tree

It is matching things like

48%57%82%1A%3A%E5
DA8698328B383C858
8F+23+1F+7D+C2+D8
7D6426E367C6F163A
65)E9)E0)5C)21)51
A9&4A&8D&E1&6A&48
200F70CB0250260CD
8F36E30A34936732D
C2$06$7C$6C$7F$0B

Expected behavior

It should match (and only match)

I’ve reviewed common formats and standards and I believe the following regex to be correct for the following formats

• IEEE 802 format for printing MAC-48 addresses in six groups of two hexadecimal digits, separated by hyphens -
• six groups of two hexadecimal digits separated by colons :
• six groups of two hexadecimal digits separated by spaces
• 12 hexadecimal digits with no separation
• Cisco three groups of four hexadecimal digits separated by dots .
• Cisco four groups of three hexadecimal digits separated by dots .

Bonus points if it groups the Hexadecimal Digits

More info may be found on Network Engineering Stackexchange What are the various standard and industry practice ways to express a 48-bit MAC address?

Proposed solutions

I'll figure something out

Can you help?

I'll figure something out