DHCPv4 Renew source MAC is wrong

[BSpendlove]

Describe the bug

When we are testing DHCPv4 for IPoE sessions, it appears that the source MAC address in the ethernet layer 2 headers are wrong, while the client MAC address presented in the DHCP request packet is correct. It appears to be some kind of encoding issue since the last byte of the MAC address does appear in the layer 2 ethernet header, maybe just an oversight in the source code?

To Reproduce

Currently testing on dev build, however I suspect this also happens on stable since we've been testing for the past 3 weeks and run into the same problem where our sessions flap after the expire timer (because the source mac is wrong)

Version (bngblaster -v):

Version: DEV
Compiler: GNU (11.3.0)
IO Modes: packet_mmap_raw (default), packet_mmap, raw

JSON configuration:

{
        "interfaces": {
                "access": {
                        "interface": "ens21",
                        "type": "ipoe",
                        "outer-vlan-min": 1000,
                        "outer-vlan-max": 1002,
                        "inner-vlan-min": 1,
                        "inner-vlan-max": 4094,
                        "ipv4": true,
                        "ipv6": true,
                        "dhcp": true,
                        "dhcpv6": true
                }
        },
        "ipoe": {
        },
        "dhcp": {
                "enable": true,
                "timeout": 5,
                "retry": 30,
                "broadcast": true
        },
        "dhcpv6": {
                "enable": true,
                "timeout": 5,
                "retry": 30,
                "access-line": true,
                "rapid-commit": true,
                "ia-na": false,
                "ia-pd": true
        },
        "access-line": {
                "agent-remote-id": "bng-demo-{session-global}",
                "agent-circuit-id": "0.0.0.0/0.0.0.0 eth0:{session-global}"
        }
}

Steps to reproduce the behavior:

1. Create an IPoE session
2. Packet Capture either via the bngblaster CLI or on the incoming interface of the router connected to BNGBlaster
3. Wait for the lease time to expire (DHCP ACK is not sent back by our BNG because the DHCP session is identified by the client MAC address internally)
4. Notice source MAC address of the request is different to the client-id as per screenshot:

Expected behavior

Layer 2 Ethernet Header Source MAC Address should be the same as the original source generated for the subscriber/session in the DHCP Discover process (Client MAC Address which is encoded correctly)

For example, if the client MAC address in the DHCP discover/renew is: 02:00:00:00:00:44

Then I expect the Layer 2 Ethernet MAC Source Address to also be 02:00:00:00:00:44

Screenshots

DHCP Renew

Additional context

Packet Capture will be sent to the email with the issue # in the subject , thanks

[GIC-de]

In the picture the last 4 bytes of destination + first two bytes of source are the actual source address, so maybe just encoding in Wireshark is wrong for ethernet over MPLS...

DST: 48:0C:02:00:00:00 SRC: 00:44:81:00:03:e8

The source address is even followed by 0x8100 (ether type for VLAN).

Could you please start BNG Blaster with -P test.pcap and compare packet send out by Blaster with your capture including MPLS.

[BSpendlove]

You are correct, it appears that I had just decoded the single mpls header and not 2, hence why its shifting everything in the packet capture

That is fixed now, this leads me onto a different issue, would you like me to close this issue and open a new issue? We're seeing some very weird issues with the DHCP Renew messages when the Destination IP in the ipv4 packet is set to 0.0.0.0 (essentially the dhcp packet isn't being seen at all by the dhcp process on the BNG which is a Cisco ASR 9902), all of our CPEs we are testing with set their destination IP in the header itself (3 different vendors we are testing against our BNG) and this works on the CPEs but not on BNG blaster.

I'm not entirely sure if this is defined in the RFC but is there a reason why the destination IP is set to 0.0.0.0 for the DHCP renew messages from BNG Blaster?

[GIC-de]

This is a bug, will fix it.

[BSpendlove]

I'm seeing our BNG now process the DHCP requests and its renewing now, thanks so much for fixing this! Is there any chance I could request a feature we can enable in the config to allow this to be a unicast requests to the original server identifier sent during the DORA process? I'll be happy to open up a separate feature request if this is something you would consider

[GIC-de]

The Blaster will already send unicast if you set broadcast mode to false:

[BSpendlove]

The Blaster will already send unicast if you set broadcast mode to false:

It appears to break for me when I set broadcast false for the DHCP discover to reach the BNG, I will be able to check later tonight if maybe it was a configuration issue on our end but when I set to false, the DHCP discovers break, I will look into the packet level and report back information on a new issue, thanks again for all your help

[GIC-de]

Okay, will wait for your feedback. Changes in this part of the code are not that complex, so can be done quickly.

[GIC-de]

I have done a few more minor changes in regards to be compliant with RFC2131. Now all messages will be send to broadcast IP except of renew and release (https://www.rfc-editor.org/rfc/rfc2131#section-4.3.6).

[GIC-de]

Fixed with 0.8.12. Please verify and close!