The BNG Blaster is a test tool to simulate thousands of PPPoE or IPoE subscribers including IPTV, traffic verification and convergence testing capabilities.

Overview

RtBrick BNG Blaster

Build

The BNG Blaster is a test tool to simulate thousands of PPPoE or IPoE subscribers including IPTV, traffic verification and convergence testing capabilities.

A short introduction can be found on YouTube or checkout the documentation for details.

BBL Interactive

License

BNG Blaster is licensed under the BSD 3-Clause License, which means that you are free to get and use it for commercial and non-commercial purposes as long as you fulfill its conditions.

See the LICENSE file for more details.

Copyright

Copyright (C) 2020-2021, RtBrick, Inc.

Comments
  • Changing start source MAC address and DUID so that multiple instances of bngblaster can be run towards the same BNG

    Changing start source MAC address and DUID so that multiple instances of bngblaster can be run towards the same BNG

    In order to scale test a BNG with a large number of dual-stack IPoE sessions, bngblaster may need to be run on more than one host if the CPU/network resouces of a single host are not enough. The host I am using supports up to about 25k sessions before packet loss occurs although the BNG supports up to 120k.

    The BNG under test rejects sessions with duplicate MACs / DHCPv6 DUIDs so they need to be unique between bngblaster instances.

    However, the src MAC address and IPv6 DUID appear to be hard coded such that two instances of bngblaster will use the same DUID/src MAC address as they interate over the session identifiers.

    I have not found a way to do this by configuration option or agument when calling bngblaster. There seem to be two access interface configuration options i1_start and i2_start which I was hoping could be used to configure an offset for the session ID for multiple bngblaster instances. The documentation at

    https://rtbrick.github.io/bngblaster/configuration/index.html#access-interfaces

    defines i1_start and i2_start as Iterator for usage in strings {i1} and Iterator for usage in strings {i2} respectively. It's not too clear what they are to be used for. Changing them from their defaults of 1 to something else does not appear to change the MAC src address, IPv6 DUID or other DHCPv6 parameters based on the bngblaster session_id.

    I have quickly tested that compiling a second bngblaster instance after changing session->client_mac[1] and session->dhcpv6_duid[3] from their defaults works.

    --- a/code/bngblaster/src/bbl_session.c
    +++ b/code/bngblaster/src/bbl_session.c
    @@ -559,7 +559,7 @@ bbl_sessions_init(bbl_ctx_s *ctx)
    
             /* Set client OUI to locally administered */
             session->client_mac[0] = 0x02;
    -        session->client_mac[1] = 0x00;
    +        session->client_mac[1] = 0x01;
             session->client_mac[2] = 0x00;
             /* Use session identifier for remaining bytes */
             session->client_mac[3] = i>>16;
    @@ -590,7 +590,7 @@ bbl_sessions_init(bbl_ctx_s *ctx)
    
             /* Set DHCPv6 DUID */
             session->dhcpv6_duid[1] = 3;
    -        session->dhcpv6_duid[3] = 1;
    +        session->dhcpv6_duid[3] = 2;
             memcpy(&session->dhcpv6_duid[4], session->client_mac, ETH_ADDR_LEN);
    
             /* Init string variables/iterators */
    

    If there's not a current way of doing this in the configuration, I believe there is a good use-case to add it as a feature and in such a way that other access interface configuration options such as inner-vlan-min that increment with session identifier work as before.

    Additional explanation for the configuration options i1_start and i2_start etc in the documentation would also probably be useful.

    enhancement ipoe scaling fixed 
    opened by mivsvit 12
  • No verified traffic flows

    No verified traffic flows

    Describe the bug

    When running the bngblaster against our DUT, the sessions get setup and traffic is being sent and received ok. The bngblaster is being hosted on a server with one Intel 810-C NIC. However, the bngblaster does not appear to match the RX flows to generate the verified traffic flows view.

    Sessions 1 (1 PPPoE / 0 IPoE)
    Established 1 [############################################################]
    ... Network Interface ( ens5f1 )
    Tx Packets 0 | 0 PPS 0 Kbps
    Rx Packets 8 | 0 PPS 0 Kbps
    Tx Multicast Packets 0 | 0 PPS

    Access Interface ( ens5f0 )
    Tx Packets 17 | 0 PPS 0 Kbps
    Rx Packets 14 | 0 PPS 0 Kbps

    When saving the packets to the pcap file, we see that the packets look correctly formed, and the header is present as well.

    TX RX

    Any clues on how to debug the issue further?

    Version (`bngblaster -v`):
    commit 8f8e53624a02d3f56631c99cca76ea0549c083ba (HEAD -> main, origin/main, origin/HEAD)
    Merge: fd1a4dd 4276acc
    Author: Christian Giese <[email protected]>
    Date:   Fri Apr 8 15:16:17 2022 +0200
    
        Merge branch 'dev' into main
    
    

    JSON configuration:

    {
        "interfaces": {
            "tx_interval": 0.1,
            "rx_interval": 0.1,
            "capture-include-streams": true,
            "access": {
                "interface": "ens5f0",
                "outer-vlan-min": 400,
                "outer-vlan-max": 400,
                "inner-vlan-min": 2,
                "inner-vlan-max": 2000,
                "vlan-mode": "1:1",
                "authentication-protocol": "CHAP",
                "type": "pppoe",
                "stream-group-id": 1,
                "address": "192.168.0.1",
                "network-interface": "ens5f1"
            },
            "network": {
                "interface": "ens5f1",
                "address": "10.0.0.1"
            }
        },
        "sessions": {
            "count": 1,
            "session-time": 0,
            "max-outstanding": 1000,
            "start-rate": 400,
            "stop-rate": 400
        },
        "pppoe": {
            "service-name": "bisdn",
            "reconnect": true,
            "discovery-timeout": 3,
            "discovery-retry": 10
        },
        "ppp": {
            "mru": 1382,
            "authentication": {
                    "username": "testing",
                    "password": "testing"
            },
        "ipcp": {
                    "enable": true,
                    "request-ip": true,
                    "request-dns1": false,
                    "request-dns2": false
        },
        "ip6cp": {
            "enable": false
        }
        },
        "streams": [
            {
                    "name": "BestEffort",
                    "stream-group-id": 1,
                    "type": "ipv4",
                    "direction": "upstream",
                    "pps": 1,
                    "length": 1000,
                    "destination-ipv4-address": "10.0.0.1",
                    "network-interface": "ens5f1"
            }
        ]
    }
    
    bug workaround available 
    opened by rubensfig 7
  • DHCPv6 - Is dhcpv6 working on v5.5?

    DHCPv6 - Is dhcpv6 working on v5.5?

    bng.txt Hi there, Quick question, we have a bng here configured with Dual-stack PPPoE. BNG configuration is working as we some other test clients with v4/v6 connected. Bngblaster, is also working but only for v4. DHCPv6 seems to be stuck in init, but doing a packet capture on the host I cannot see any v6 request generated.

    Also, seems that debug/logging not working (or I'm doing something wrong, most probably).

    The release we are using is 5.5, using the debian pre-build package.

    Version: 0.5.5 IO Modes: packet_mmap_raw (default), packet_mmap, raw

    [email protected]:/home/smartinez# bngblaster-cli /var/run/bng session-info session-id 1 { "status": "ok", "code": 200, "session-info": { "type": "pppoe", "session-id": 1, "session-state": "Established", "interface": "enp0s5f2", "outer-vlan": 100, "inner-vlan": 0, "mac": "02:00:00:00:00:01", "username": "test", "lcp-state": "Opened", "ipcp-state": "Opened", "ip6cp-state": "Opened", "ipv4-address": "203.0.13.83", "dhcpv6-state": "Init", "tx-packets": 16, "rx-packets": 13, "rx-fragmented-packets": 0 } }

    bug pppoe 
    opened by tatuzemdp 7
  • L2TP unhide with padding not working

    L2TP unhide with padding not working

    Describe the bug

    I'm using a Juniper MX with PPPoE PAP as LAC and BNGBlaster as LNS, but I get the error message, that AVP 33 cannot be decrypted. This seems to be related to this code: https://github.com/rtbrick/bngblaster/blob/2ba5a782d72b04f554a64c32cc4cc83c734e00e2/code/bngblaster/src/bbl_l2tp_avp.c#L207

    len contains the Original Attribute length. However, the AVP length must not be len + 2, because there can be a random padding as specified in RFC2661 https://www.rfc-editor.org/rfc/rfc2661.html#section-4.3. The issue occurs because the Juniper MX sends the AVP 33 with padding.

    image

    bug fixed 
    opened by SoerenBusse 6
  • Question about pps and i1-start

    Question about pps and i1-start

    Hello all,

    First of all thanks for this excellent project. Been using this for couple of days, and only have good words to describe the experience.

    While going through the documentation, there are some items which are not very clear:

    1. pps: PPS can be specified in two places: in { "streams": {} } and in { "session-traffic": {} }. Its not clear how they interact with each other and why its needed in two places.
    2. i1-start, i1-step, i2-start and i2-step along with address-iter, gateway-iter and group-iter
    3. monkey: What exactly happens when this option is enabled.

    A brief explanation and a small example would go a long way to help understand this bits!

    Thanks!

    documentation 
    opened by xuoguoto 6
  • BNG Blaster not responding to PADO

    BNG Blaster not responding to PADO

    Describe the bug

    A clear and concise description of what the bug is.

    To Reproduce

    Running on Ubuntu 20.04.4, installed version is bngblaster-0.7.1-ubuntu-20.04_amd64.deb

    Version (bngblaster -v):

    Version: 0.7.1
    IO Modes: packet_mmap_raw (default), packet_mmap, raw
    

    JSON configuration:

    {
        "interfaces": {
    	"qdisc-bypass": false,
            "io-mode": "packet_mmap_raw",
            "access": [
                {
                    "interface": "enp3s0f0",
                    "type": "pppoe",
    		"outer-vlan-min": 4,
                    "outer-vlan-max": 4,
                    "inner-vlan-min": 1,
                    "inner-vlan-max": 4094,
                    "authentication-protocol": "CHAP"
                }
            ]
        },
        "sessions": {
            "count": 10,
            "session-time": 0,
            "max-outstanding": 800,
            "start-rate": 400,
            "stop-rate": 400
        },
        "pppoe": {
            "reconnect": true,
            "discovery-timeout": 10,
            "discovery-retry": 10
        },
        "ppp": {
            "mru": 1492,
            "authentication": {
                "username": "mx10k3test{session-global}@zen",
                "password": "password",
                "timeout": 5,
                "retry": 30,
    	    "protocol": "CHAP"
            },
            "lcp": {
                "conf-request-timeout": 1,
                "conf-request-retry": 10,
                "keepalive-interval": 30,
                "keepalive-retry": 3
            },
            "ipcp": {
                "enable": true,
                "request-ip": true,
                "request-dns1": true,
                "request-dns2": true,
                "conf-request-timeout": 1,
                "conf-request-retry": 10
            },
            "ip6cp": {
                "enable": true,
                "conf-request-timeout": 1,
                "conf-request-retry": 10
            }
        },
        "dhcpv6": {
            "enable": true,
            "rapid-commit": true
        },
        "access-line": {
            "agent-remote-id": "DEU.RTBRICK.{session-global}",
            "agent-circuit-id": "0.0.0.0/0.0.0.0 eth 0:{session-global}",
            "rate-up": 1024,
            "rate-down": 16384
        }
    }
    

    Steps to reproduce the behavior:

    1. start BNG using "sudo bngblaster -C pppoe.json"

    Expected behavior

    I'd expect a PADR to be created. I do note that the PADI is double tagged on the PCAP, but the PADO appears single tagged, when PCAP'd using BNGBlaster, but when running the capture on the Arista switch (upstream from the server), the tagging is as expected

    Arista PCAP

    20:36:02.409429 02:00:00:00:00:01 > Broadcast, ethertype 802.1Q (0x8100), length 92: vlan 4, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype PPPoE D, PPPoE PADI [Service-Name] [Vendor-Specific "......0.0.0.0/0.0.0.0 eth 0:[email protected]"]

    20:36:02.477526 f2:7c:c7:af:77:f3 > 02:00:00:00:00:01, ethertype 802.1Q (0x8100), length 76: vlan 4, p 6, ethertype 802.1Q, vlan 1, p 6, ethertype PPPoE D, PPPoE PADO [AC-Name "BNG3.THN-LON.LAB-RE0"] [Service-Name] [AC-Cookie "G~...9.{t. ..7]c"]

    20:36:07.414196 02:00:00:00:00:01 > f2:7c:c7:af:77:f3, ethertype 802.1Q (0x8100), length 92: vlan 4, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype PPPoE D, PPPoE PADI [Service-Name] [Vendor-Specific "......0.0.0.0/0.0.0.0 eth 0:[email protected]"]

    bug pppoe fixed 
    opened by hazeyb 6
  • Slow session set up

    Slow session set up

    Describe the bug

    When setting up around 100 sessions, the session set up is very slow;

    Sessions 100 (100 PPPoE / 0 IPoE) Established 51 [############################### ] Outstanding 800 [############################################################] Terminated 0 [ ] Setup Time 13400 ms Setup Rate 3.81 CPS (MIN: 3.42 AVG: 4.02 MAX: 4.57) Flapped 823

    If I run a PCAP, and filter for a particular vlan (one that hasn't yet auth'd successfully). I can see that PPPOE has established, and PPP LCP has begun. Following the PPP CHAP challenge from our BNG bngblaster immediately responds with a PPP LCP terminate request. We then get the Termination ACK, PPPOE terminates, and the entire process starts again.

    We see that repeat over and over. Though eventually the other sessions get established. Sessions 100 (100 PPPoE / 0 IPoE) Established 61 [##################################### ] Outstanding 800 [############################################################] Terminated 0 [ ] Setup Time 198400 ms Setup Rate 0.31 CPS (MIN: 0.31 AVG: 2.57 MAX: 4.57) Flapped 1000

    We have tested the BNG with the same VLANs from a Spirent and set up of around 2000 sessions takes 10-20 seconds.

    To Reproduce

    Version (bngblaster -v):

    Version: 0.7.1
    IO Modes: packet_mmap_raw (default), packet_mmap, raw
    

    JSON configuration:

    {
        "interfaces": {
            "access": [
                {
                    "interface": "enp3s0f0",
                    "type": "pppoe",
    		"outer-vlan": 4,
                    "inner-vlan-min": 1,
                    "inner-vlan-max": 4094,
                    "authentication-protocol": "CHAP"
                }
            ]
        },
        "sessions": {
            "count": 100,
    	"session-time": 0,
            "max-outstanding": 800,
            "start-rate": 400,
            "stop-rate": 400
        },
        "pppoe": {
    	"service-name": "access",
            "reconnect": true,
            "discovery-timeout": 100,
            "discovery-retry": 1,
    	"host-uniq": true,
            "vlan-priority": 6
        },
        "ppp": {
            "mru": 1492,
            "authentication": {
                "username": "mx10k3test{session-global}@zen",
                "password": "password",
                "timeout": 5,
                "retry": 30,
    	    "protocol": "CHAP"
            },
            "lcp": {
                "conf-request-timeout": 5,
                "conf-request-retry": 10,
                "keepalive-interval": 30,
                "keepalive-retry": 3
            },
            "ipcp": {
                "enable": true,
                "request-ip": true,
                "request-dns1": true,
                "request-dns2": true,
                "conf-request-timeout": 1,
                "conf-request-retry": 10
            }
        },
        "access-line": {
            "agent-remote-id": "DEU.RTBRICK.{session-global}",
            "agent-circuit-id": "0.0.0.0/0.0.0.0 eth 0:{session-global}",
            "rate-up": 1024,
            "rate-down": 16384
    
    

    Steps to reproduce the behavior:

    1. sudo bngblaster -C pppoe.json -I

    Expected behavior

    We'd expect the session setup to be quite quick. PPPOE set up completes in a few seconds, but we don't understand why bngblaster is sending the PPP LCP terminate requests to the BNG. If we wait long enough, all the sessions will eventually come up.

    Screenshots

    image

    Access Interface Protocol Packet Stats: ARP TX: 0 RX: 0 PADI TX: 902 RX: 0 PADO TX: 0 RX: 902 PADR TX: 902 RX: 0 PADS TX: 0 RX: 902 PADT TX: 839 RX: 63 LCP TX: 2986 RX: 2970 PAP TX: 0 RX: 0 CHAP TX: 64 RX: 966 IPCP TX: 192 RX: 192 IP6CP TX: 129 RX: 129 IGMP TX: 0 RX: 0 ICMP TX: 0 RX: 0 DHCP TX: 0 RX: 0 DHCPv6 TX: 0 RX: 0 ICMPv6 TX: 64 RX: 169 IPv4 Fragmented RX: 0

    Access Interface Protocol Timeout Stats: LCP Echo Request: 0 LCP Request: 0 IPCP Request: 0 IP6CP Request: 0 PAP: 0 CHAP: 0 DHCP Request: 0 DHCPv6 Request: 0

    Additional context

    Add any other context about the problem here.

    bug pppoe fixed workaround available 
    opened by hazeyb 5
  • No response to IPv6 unicast reachability check NSs

    No response to IPv6 unicast reachability check NSs

    Our BNG under test has a feature where it tests IPoE subscriber host connectivity by using unicast IPv6 Neighbour Solicitations sent to the access interface address. If no NAs are received the BNG declares host connectivity is lost and tears down the IPoE session. These checks can be sent periodically or be event triggered.

    In our use-case, each bngblaster session receives an IA_PD via DHCPv6 and has only a locally generated fe80::/10 link local address for the access interface between it and the BNG. No DHCPv6 IA_NA is assigned.

    IPv6 NSs sent from the gateway address to the network interface are responded to successfully by bngblaster. However, NSs sent from the BNG to the bngblaster access interfaces (such as the packets fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 in the output below) appear in the pcap generated by bngblaster but are not responded to and the BNG brings the session down. The corresponding IPv4 host connectivity check which is an ARP request to the access interface address (assigned by DHCPv4) works fine. We are running bngblaster 0.7.8.

    Expected behaviour is an IPv6 NA reply is sent by bngblaster from a source of an address assigned to the access interface from which the NS was received and with a destination of the source address of the received NS.

    $ bngblaster -v
    Version: DEV
    Compiler: GNU (9.4.0)
    GIT:
      REF: main
      SHA: 0abdeaf2eed9fc3b78b90c2dadf92548dfd7dccf
    IO Modes: packet_mmap_raw (default), packet_mmap, raw
    
    Jun 19 19:29:21.047988 Resolve network interfaces
    Jun 19 19:29:21.048162 All network interfaces resolved
    Jun 19 19:29:21.075023 IPv6 (ID: 1) DHCPv6 IA_PD prefix 2001:db8:3400:1800::/56
    Jun 19 19:29:26.057986 IPv4 (ID: 1) address 100.66.0.11
    Jun 19 19:29:26.060320 ALL SESSIONS ESTABLISHED
    
    $ tshark -r ipv6-no-na.pcap icmpv6
        2   0.000000 2001:db8:2016::2 → ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:db8:2016::1 from 00:0c:29:de:e3:ef
        4   0.001257 2001:db8:2016::1 → 2001:db8:2016::2 ICMPv6 86 Neighbor Advertisement 2001:db8:2016::1 (rtr, sol, ovr) is at f0:0d:be:ef:5a:ba
        8   1.001388 2001:db8:2016::2 → ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:db8:2016::1 from 00:0c:29:de:e3:ef
       10   1.002855 2001:db8:2016::1 → 2001:db8:2016::2 ICMPv6 86 Neighbor Advertisement 2001:db8:2016::1 (rtr, sol, ovr) is at f0:0d:be:ef:5a:ba
       12   1.028243 fe80::ffff:ffff:ff00:1 → ff02::2      ICMPv6 70 Router Solicitation
       13   1.119500 fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 ICMPv6 82 Router Advertisement from f0:0d:be:ef:5b:32
       15   5.058367 2001:db8:2016::1 → 2001:db8:2016::2 ICMPv6 86 Neighbor Solicitation for 2001:db8:2016::2 from f0:0d:be:ef:5a:ba
       16   5.059570 2001:db8:2016::2 → 2001:db8:2016::1 ICMPv6 86 Neighbor Advertisement 2001:db8:2016::2 (sol, ovr) is at 00:0c:29:de:e3:ef
       26  60.659329 fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 ICMPv6 90 Neighbor Solicitation for fe80::ffff:ffff:ff00:1 from f0:0d:be:ef:5b:32
       31  90.659055 fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 ICMPv6 90 Neighbor Solicitation for fe80::ffff:ffff:ff00:1 from f0:0d:be:ef:5b:32
       34 120.658560 fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 ICMPv6 90 Neighbor Solicitation for fe80::ffff:ffff:ff00:1 from f0:0d:be:ef:5b:32
       37 150.658771 fe80::167b:acff:feac:8ebf → fe80::ffff:ffff:ff00:1 ICMPv6 90 Neighbor Solicitation for fe80::ffff:ffff:ff00:1 from f0:0d:be:ef:5b:32   
    

    IPv4 connectivity check:

       86 416.664069 f0:0d:be:ef:5b:32 → 02:00:00:00:00:01 ARP 60 Who has 100.66.0.11? Tell 100.66.0.1
       87 416.664144 02:00:00:00:00:01 → f0:0d:be:ef:5b:32 ARP 50 100.66.0.11 is at 02:00:00:00:00:01
    

    Config:

    {
        "interfaces": {
            "qdisc-bypass": true,
            "io-mode": "packet_mmap_raw",
             "network": {
             "interface": "ens160.2016",
             "address": "172.31.19.5",
             "gateway": "172.31.19.4",
            "capture-include-streams": false,
             "address-ipv6": "2001:db8:2016::2",
             "gateway-ipv6": "2001:db8:2016::1",
             "tx-interval": 1,
            "rx-interval": 1,
            "io-slots": 4096
            },
            "access": [
            {
                "interface": "ens224f1",
                "type": "ipoe",
                "qinq": "false",
                "outer-vlan-min": 2016,
                "outer-vlan-max": 2048,
                "inner-vlan-min": 2,
                "inner-vlan-max": 4094,
                "ipv4": true,
                "ipv6": true,
                "i1_start": "500",
                "i2_start": "1000",
                "vlan-mode": "1:1"
                        }
         ]
        },
        "sessions": {
            "count": 1,
            "session-time": 0,
            "max-outstanding": 16000,
            "start-rate": 1000,
            "stop-rate": 1000
        },
                "ipv4": true,
                "ipv6": true,
                "i1_start": "500",
                "i2_start": "1000",
                "vlan-mode": "1:1"
            }
         ]
        },
        "sessions": {
            "count": 1,
            "session-time": 0,
            "max-outstanding": 16000,
            "start-rate": 1000,
            "stop-rate": 1000
        },
        "ipoe": {
                "ipv4": true,
                "arp-timeout": 5,
                "arp-interval": 300,
                        "ipv6": true
        },
        "access-line": {
            "agent-remote-id": "ABCDEFGH{session-global}",
            "agent-circuit-id": "0.0.0.0/0.0.0.0 eth 0:{session-global}"
        },
        "dhcp": {
            "broadcast": true,
            "enable": true
        },
        "dhcpv6": {
            "enable": true,
            "rapid-commit": true
        },
       "session-traffic": {
            "ipv4-pps": 0,
            "ipv6pd-pps": 0
        }
    }
    

    A small amount of debugging verified that the condition at https://github.com/rtbrick/bngblaster/blob/c75a723bbe0a7bd4f96a00340b462e95144a3b8c/code/bngblaster/src/bbl_rx.c#L576 is passing when the IPv6 NSs are received.

    bug fixed 
    opened by mivsvit 4
  • RFC7084 compliant DHCPv6 behavior

    RFC7084 compliant DHCPv6 behavior

    Hey there,

    I haven't configured DHCPv6 yet, however I stumpled across the following section in your FAQ:

    The BNG Blaster expects an ICMPv6 router-advertisement with other-config flag before it starts sending DHCPv6 within a PPPoE session.

    Personally I think that the RFC4861 is a little bit misleading here, because it wasn't written with DHCPv6 in mind, so it's unclear if DHCPv6-PD should be started by receiving the O-flag or the M-flag.

    However RFC7084 states in WPD-4 the following:

    WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
               delegation when either the M or O flags are set to 1 in a
               received Router Advertisement (RA) message.  Behavior of the
               CE router to use DHCPv6 prefix delegation when the CE router
               has not received any RA or received an RA with the M and the
               O bits set to zero is out of scope for this document.
    

    So from my understanding DHCPv6-PD should also be instantiated when receiving the M-flag. Or is there a good reason not to do? :)

    Fun Fact: The obsoleted RFC6204 WPD-4 stated that DHCPv6-PD should always be initiated regardless if it receives a Router Advertisment with an O- or M-flag. So as soon as a CPE supports IPv6 it should request a prefix using DHCPv6 from the service provider. As far as a I rember is this still the default behavior of a Fritz!Box.

    bug pppoe low fixed 
    opened by SoerenBusse 4
  • Linking fails with GCC version 10

    Linking fails with GCC version 10

    Describe the bug

    When trying to compile bngblaster from source on a Debian bullseye, the linking fails with the following errors:

    /usr/bin/ld: CMakeFiles/bngblaster.dir/src/bbl_a10nsp.c.o (symbol from plugin): in function `log_win':
    (.text+0x0): multiple definition of `log_win'; CMakeFiles/bngblaster.dir/src/bbl.c.o (symbol from plugin):(.text+0x0): first defined here
    /usr/bin/ld: CMakeFiles/bngblaster.dir/src/bbl_a10nsp.c.o (symbol from plugin): in function `log_win':
    (.text+0x0): multiple definition of `stats_win'; CMakeFiles/bngblaster.dir/src/bbl.c.o (symbol from plugin):(.text+0x0): first defined here
    

    To Reproduce

    # Debian Bullseye 11.3
    mkdir build && cd build
    cmake /root/bngblaster-0.7.2 -DCMAKE_BUILD_TYPE=Release
    cmake --build . --config Release
    

    Workaround When using gcc-9 everything works fine.

    apt install gcc-9
    cmake /root/bngblaster-0.7.2 -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=/usr/bin/gcc-9
    cmake --build . --config Release
    
    bug fixed 
    opened by SoerenBusse 3
  • BNG Blaster ACKs Multi Link PPP Option during LCP

    BNG Blaster ACKs Multi Link PPP Option during LCP

    Hello,

    I'm running BNG Blaster against a LANCOM Systems Router which has an integrated PPPoE Server. The LANCOM PPPoE Server has support for Multi Link PPP which is not configurable and always active/advertised. BNG blaster seems to ACK the Multi Link Option in the LCP phase which results in the situation that the LANCOM PPPoE Server sends PPPoE frames with Multilink header and BNG Blaster does not. The BNG Blaster ACKs the Multilink MRRU and the Multilink Endpoint Discriminator (MAC) from the PPPoE Server.

    The result is that the IPCP phase does not finish. BNG Blaster should not ACK unsupported options like Multilink PPP.

    Best regards, John

    1 2

    bug 
    opened by JohnMiller7 3
  • Control Socket Connection Manager

    Control Socket Connection Manager

    The BNG Blaster control socket is an UNIX domain stream socket which allows to interactively communicate with the BNG Blaster via JSON RPC.

    This request is about to add connection management and further enhancements for the control socket.

    enhancement 
    opened by GIC-de 0
  • fix GitHub release action warning

    fix GitHub release action warning

    Warning see here: https://github.com/rtbrick/bngblaster/actions/runs/3379673696

    https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

    low 
    opened by GIC-de 0
  • Need support of high-rate subscriber traffic in Mbps for scaled subscribers

    Need support of high-rate subscriber traffic in Mbps for scaled subscribers

    Problem Statement:

    1. In Scaled Subscribers Scenario say 18K Subscribers, BngBlaster(including Bngblaster infra) need to support high rate traffic per subscriber.

    Description:

    Lets take example of 18K Subscribers with per subscriber 250Kbps rate downstream & 250Kbps upstream. 18K * 500Kbps ==> 9000Kbps ==> 9Gbps approximately.

    Thanks, Dharmendra

    enhancement scaling dpdk 
    opened by DharmendraShetty 1
  • In Scaled scenario,either Subscribers destined traffic or from subscribers traffic, need tracking of ipv4/ipv6 traffic flows in a paged approach

    In Scaled scenario,either Subscribers destined traffic or from subscribers traffic, need tracking of ipv4/ipv6 traffic flows in a paged approach

    Enhancement Request Description-:

    In scaled scenario, Subscribers Traffic Statistics Tracking (based on IPv4/IPv6 Destination Address, IPv4/IPv6 Source Address, IPv4-ToS, IPv6-TC) by listing the traffic flows of scaled subscribers in a paged manner.

    Probably exposing the traffic stats in a prometheus mode to Grafana Monitoring Tool to show in paged manner.

    Additional context attached for reference:

    Analogous reference attachment of Tester Tool where Subscriber Traffic Stats tracking is done in a scaled scenario. TesterTool_SubscriberTrafficStatsTrackingReference

    Thanks, Dharmendra

    enhancement 
    opened by DharmendraShetty 0
  • DHCPv6 LDRA behaviour

    DHCPv6 LDRA behaviour

    Currently it is possible to set the interface-id and remote-id via access-line for DHCPv6, but this results in adding option17/38 to the normal DHCPv6 packet.

    I would think that in most situations option17/38 are added by an LDRA-agent, and the original DHCP-request is encapsulated in the relay-message option (option9). Currently our Juniper BRAS is rejecting the SOLICITs, because the packet is not constructed as a non relay-packet. Reference: https://datatracker.ietf.org/doc/html/rfc6221

    In our set-up our L2 switches act as LDRA agent and add option17/18 information, which works fine. Unfortunately we currently cannot mimic this behaviour with bngblaster.

    Would it be possible to add DHCPv6 LDRA-emulation to BNGblaster?

    enhancement 
    opened by mancz 4
Releases(0.8.7)
A flexible tool for redirecting a given program's TCP traffic to SOCKS5 or HTTP proxy.

graftcp English | 简体中文 Introduction graftcp can redirect the TCP connection made by the given program [application, script, shell, etc.] to SOCKS5 or

mingang.he 1.3k Nov 19, 2022
pwru is an eBPF-based tool for tracing network packets in the Linux kernel with advanced filtering capabilities.

pwru (packet, where are you?) pwru is an eBPF-based tool for tracing network packets in the Linux kernel with advanced filtering capabilities. It allo

Cilium 1k Nov 26, 2022
Small utility that leverages eBPF to dump the traffic of a unix domain socket

UnixDump UnixDump is a small eBPF powered utility that can be used to dump unix socket traffic. System requirements This project was developed on a Ub

Guillaume Fournier 8 Nov 19, 2022
C++ networking library including UniConf and a convenient D-Bus API

This is wvstreams, a nominally platform-independent networking and utilities library for C++. Some documentation is in the Docs/ directory. If that

null 27 Dec 29, 2021
A collection of C++ HTTP libraries including an easy to use HTTP server.

Proxygen: Facebook's C++ HTTP Libraries This project comprises the core C++ HTTP abstractions used at Facebook. Internally, it is used as the basis fo

Facebook 7.7k Nov 25, 2022
T-Watch 2020 v1 compatible firmware providing WiFi and BLE testing tools (and also, a watch :D)

ESP-IDF template app This is a template application to be used with Espressif IoT Development Framework. Please check ESP-IDF docs for getting started

Damien Cauquil 47 Nov 8, 2022
Examples and test programs I made while learning the DPDK.

The DPDK Examples (WIP) Description A small repository I will be using to store my progress and test programs from the DPDK, a kernel bypass library v

Christian Deacon 23 Nov 21, 2022
The reference C++ unit testing framework (TDD, xUnit, C++03/11/14/17)

What is Boost.Test? Boost.Test is a C++03/11/14/17 unit testing library, available on a wide range of platforms and compilers. The library is part of

Boost.org 127 Nov 5, 2022
Fuzzing test lab

NYCU-Software-Testing-2021-Lab8 Fuzzing test lab 這是簡單的 bmp format 灰階轉換程式,裡面好像有隱藏的弱點會讓程式出問題,麻煩你用模糊測試找到問題,並幫我修復他。 繳交:學號.zip 內容: poc : 會造成問題的輸入 bmp_lib.c

Yuan 7 May 5, 2021
ipcbuf - test/report the size of an IPC kernel buffer

ipcbuf - test/report the size of an IPC kernel buffer Different forms of IPC utilize different in-kernel buffers, depending on a variety of possibly s

Jan Schaumann 6 Sep 7, 2022
A TCP / UDP program supporting multiple test scenarios

sock_test A TCP / UDP program supporting multiple test scenarios The current communication protocol only supports UDP. TCP will be supported later. Ho

null 4 Mar 8, 2022
(Test assignment) Transfer files over the network using a homegrown UDP protocol

Требования Linux x86_64 gcc >= 4.9 (C++11) Сборка $ make Запуск $ make run -j5 -j5 позволяет серверу и четырём клиентам запуститься одновременно. В

Alexander Batischev 2 Dec 18, 2021
A Hidden and Undetectable Remote Access Tool written in C++ and Server in Python3

Spyware-RAT A Hidden and Undetectable Remote Access Tool written in C++ and Server in Python3 This program utilizes the standard winsock library for s

null 43 Nov 15, 2022
Warp speed Data Transfer (WDT) is an embeddedable library (and command line tool) aiming to transfer data between 2 systems as fast as possible over multiple TCP paths.

WDT Warp speed Data Transfer Design philosophy/Overview Goal: Lowest possible total transfer time - to be only hardware limited (disc or network bandw

Facebook 2.7k Nov 14, 2022
LANDrop is a cross-platform tool that you can use to conveniently transfer photos, videos, and other types of files to other devices on the same local network.

LANDrop is a cross-platform tool that you can use to conveniently transfer photos, videos, and other types of files to other devices on the same local network.

LANDrop 3.2k Nov 27, 2022
ebpfkit-monitor is a tool that detects and protects against eBPF powered rootkits

ebpfkit-monitor ebpfkit-monitor is an utility that you can use to statically analyse eBPF bytecode or monitor suspicious eBPF activity at runtime. It

Guillaume Fournier 78 Nov 12, 2022
Winpcap-based network packet capture tool, support TLS (part), UDP, ICMP, TCP, ARP, DNS and other protocol analysis, interface reference wireshark.

Winpcap-based network packet capture tool, support TLS (part), UDP, ICMP, TCP, ARP, DNS and other protocol analysis, interface reference wireshark.

null 53 Nov 20, 2022
Port-Fin(port finder) is a tool which scans for open and closed port on a website/host.

Port-Fin(port finder) is a tool which scans for open and closed port on a website/host. This tool scans the state of the well known/common ports.

AnonabdulJ 4 Dec 14, 2021
Simple tool (and library) for checking IP camera hardware

IP camera hardware checking tool This basic concept belongs to Maxim Chertov (thank you for your original utility) and Nikita Orlov (for cute YAML for

OpenIPC 55 Nov 22, 2022