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.

Issues
  • 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
  • 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
  • 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
  • DHCP failing to Nokia BNG: bngblaster sends DHCPDISCOVER to siaddr rather than broadcast address

    DHCP failing to Nokia BNG: bngblaster sends DHCPDISCOVER to siaddr rather than broadcast address

    DHCP failing to Nokia BNG: bngblaster sends DHCPDISCOVER to siaddr rather than broadcast address

    We are testing bngblaster version 0.70 with IPoE sessions to a Nokia 7750 BNG (although the same behaviour/issue was also present using bngblaster version 0.6.6).

    The BNG accepts the DHCP discover and replies with an offer which from the debugs, is received and processed by the BNG. The BNG however does not send a DHCPACK to bngblaster. The DHCPREQUESTs are retried by bngblaster:

    # ./bngblaster -v
    GIT:
      REF: main
      SHA: 2ba5a782d72b04f554a64c32cc4cc83c734e00e2
    IO Modes: packet_mmap_raw (default), packet_mmap, raw
    
    Apr 06 18:10:25.943151 Resolve network interfaces
    Apr 06 18:10:25.943282 All network interfaces resolved
    Apr 06 18:10:25.943320 DHCP (ID: 1) Start DHCP
    Apr 06 18:10:25.948432 DHCP (ID: 1) DHCP-Discover send
    Apr 06 18:10:26.032631 DHCP (ID: 1) DHCP-Offer received
    Apr 06 18:10:26.035857 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:10:31.037336 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:10:36.041096 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:10:41.044076 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:10:46.048311 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:10:51.049583 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:10:56.050670 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:11:01.051205 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:11:06.056436 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:11:11.060699 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:11:16.060872 DHCP (ID: 1) Stop DHCP
    Apr 06 18:11:16.060967 DHCP (ID: 1) Start DHCP
    Apr 06 18:11:16.064548 DHCP (ID: 1) DHCP-Discover send
    Apr 06 18:11:16.069751 DHCP (ID: 1) DHCP-Offer received
    Apr 06 18:11:16.069832 DHCP (ID: 1) DHCP-Request send
    Apr 06 18:11:21.074295 DHCP (ID: 1) DHCP-Request send
    

    From a packet capture, the DHCP request is being sent by bngblaster to the siaddr in the received DHCPOFFER (the address 172.31.19.1 in the example below):

    # tshark -T fields  -e ip.src -e ip.dst  -e _ws.col.Info  -e dhcp.option.dhcp_server_id -e dhcp.ip.server -E header=y -r bngblaster-0.70.pcap dhcp
    
    ip.src  ip.dst  _ws.col.Info    dhcp.option.dhcp_server_id      dhcp.ip.server
    0.0.0.0 255.255.255.255 DHCP Discover - Transaction ID 0xe4ffd06c               0.0.0.0
    100.64.0.1      100.64.34.35    DHCP Offer    - Transaction ID 0xe4ffd06c       172.31.19.1     172.31.19.1
    0.0.0.0 172.31.19.1     DHCP Request  - Transaction ID 0xe4ffd06c       172.31.19.1     0.0.0.0
    0.0.0.0 172.31.19.1     DHCP Request  - Transaction ID 0xe4ffd06c       172.31.19.1     0.0.0.0
    0.0.0.0 172.31.19.1     DHCP Request  - Transaction ID 0xe4ffd06c       172.31.19.1     0.0.0.0
    0.0.0.0 172.31.19.1     DHCP Request  - Transaction ID 0xe4ffd06c       172.31.19.1     0.0.0.0
    

    RFC 2131 section 3.1 says

    the DHCPREQUEST message MUST use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as the original DHCPDISCOVER message.

    RFC 2131 Section 2 defines the intrepretation of the siaddr as:

    the address of the server to use in the next step of the client's bootstrap process. A DHCP server may return its own address in the 'siaddr' field, if the server is prepared to supply the next bootstrap service (e.g., delivery of an operating system executable image). A DHCP server always returns its own address in the 'server identifier' option.

    The above seems to imply that the behaviour should be to send the request to the broadcast address and not to the siaddr.

    If the source code is changed to send the DHCP Request to the broadcast address, the DHCP transaction is successful and the session is established.

    Diff:

    $ git diff
    diff --git a/code/bngblaster/src/bbl_tx.c b/code/bngblaster/src/bbl_tx.c
    index b2b7ea2..c7bdd50 100644
    --- a/code/bngblaster/src/bbl_tx.c
    +++ b/code/bngblaster/src/bbl_tx.c
    @@ -1367,6 +1367,8 @@ bbl_encode_packet_dhcp(bbl_session_s *session) {
                 dhcp.type = DHCP_MESSAGE_REQUEST;
                 session->stats.dhcp_tx_request++;
                 LOG(DHCP, "DHCP (ID: %u) DHCP-Request send\n", session->session_id);
    +           eth.dst = (uint8_t*)broadcast_mac;
    +            ipv4.dst = IPV4_BROADCAST;
                 dhcp.option_address = true;
                 dhcp.address = session->dhcp_address;
                 dhcp.option_server_identifier = true;
    

    Logs:

    Apr 06 17:48:53.339912 Resolve network interfaces
    Apr 06 17:48:53.340028 All network interfaces resolved
    Apr 06 17:48:53.340059 DHCP (ID: 1) Start DHCP
    Apr 06 17:48:53.341119 DHCP (ID: 1) DHCP-Discover send
    Apr 06 17:48:53.428681 DHCP (ID: 1) DHCP-Offer received
    Apr 06 17:48:53.433917 DHCP (ID: 1) DHCP-Request send
    Apr 06 17:48:53.439157 DHCP (ID: 1) DHCP-ACK received
    Apr 06 17:48:53.449498 ALL SESSIONS ESTABLISHED
    

    Packet trace

    # tshark -T fields  -e ip.src -e ip.dst  -e _ws.col.Info  -e dhcp.option.dhcp -e dhcp.option.dhcp_server_id -e dhcp.ip.server -E header=y -r ./bngblaster-0.70-broadcast.pcap dhcp
    ip.src  ip.dst  _ws.col.Info    dhcp.option.dhcp        dhcp.option.dhcp_server_id      dhcp.ip.server
    0.0.0.0 255.255.255.255 DHCP Discover - Transaction ID 0x31725964       1               0.0.0.0
    100.64.0.1      100.64.36.129   DHCP Offer    - Transaction ID 0x31725964       2       172.31.19.1     172.31.19.1
    0.0.0.0 255.255.255.255 DHCP Request  - Transaction ID 0x31725964       3       172.31.19.1     0.0.0.0
    100.64.0.1      100.64.36.129   DHCP ACK      - Transaction ID 0x31725964       5       172.31.19.1     172.31.19.1
    

    json:

    {
        "interfaces": {
            "qdisc-bypass": true,
            "io-mode": "packet_mmap_raw",
             "network": {
             "interface": "ens160.2016",
             "address": "172.31.19.5",
             "gateway": "172.31.19.4"
            },
            "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": false,
                "vlan-mode": "1:1"
            }
         ]
        },
        "sessions": {
            "count": 1,
            "session-time": 0,
            "max-outstanding": 16000,
            "start-rate": 1000,
            "stop-rate": 1000
        },
        "ipoe-line": {
                "ipv4": true,
                "arp-timeout": 5,
                "arp-interval": 300,
                "ipv6": false
        },
        "access-line": {
            "agent-remote-id": "ABCDEFGHIJKLMNOP",
            "agent-circuit-id": "0.0.0.0/0.0.0.0 eth 0:{session-global}"
        },
        "dhcp": {
            "enable": true
        },
        "dhcpv6": {
            "enable": true,
            "_enable": false,
            "rapid-commit": true
        },
       "session-traffic": {
            "ipv4-pps": 1,
            "ipv6-pps": 1,
            "ipv6pd-pps": 1
        }
    }
    bug 
    opened by mivsvit 2
  • Configuration of IPV6CP interface identifier

    Configuration of IPV6CP interface identifier

    Hello,

    Is there any way to influence or configure the PPP IPv6 Interface identifier of BNG Blaster, which is negotiated during IPV6CP? In my tests, the interface identifier seems to be always 00:00:00:00:00:00:00:00 for all sessions. Maybe the interface identifier could be based on the session number?

    Regards, John

    enhancement 
    opened by JohnMiller7 2
  • Sessions established count is zero when we bring up only with dhcpv6 and Traffic not starting

    Sessions established count is zero when we bring up only with dhcpv6 and Traffic not starting

    Describe the bug Sessions established count is zero when we bring up only with dhcpv6 and Traffic not starting A clear and concise description of what the bug is. Sessions established count is zero when we bring up only with dhcpv6 and Traffic not starting To Reproduce 1] Bring up only ipoe dhcpv6 Version (bngblaster -v): Latest bngblaster Version

    JSON configuration:

    {
        "interfaces": {
            "tx-interval": 1,
            "rx-interval": 1,
            "io-slots": 4096,
            "network": {
                "interface": "br-spine1-0",
                "address": "131.0.0.2",
                "gateway": "131.0.0.1",
                "address-ipv6": "fc66:1337:7331::2",
                "gateway-ipv6": "fc66:1337:7331::1"
            },	
            "access": [
            {
                "interface": "leaf1-1",
                "type": "ipoe",
                "outer-vlan-min": 1201,
                "outer-vlan-max": 1300,
                "inner-vlan-min": 1001,
                "inner-vlan-max": 1100
            }
         ]  
        },
        "sessions": {
            "count": 5,
            "session-time": 0,
            "max-outstanding": 800,
            "start-rate": 400,
            "stop-rate": 100
        },
        "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": 2000,
            "rate-down": 16384,
            "dsl-type": 5
        },
        "dhcp": {
            "enable": false
        },
        "dhcpv6": {
            "enable": true
        },
        "session-traffic": {
            "autostart": true,
            "ipv6-pps": 1,
            "ipv6pd-pps": 1
        }
    }
    
    

    Steps to reproduce the behavior:

    1. ...

    Expected behavior Sessions established count should not be zero and traffic should work A clear and concise description of what you expected to happen.

    Screenshots

    If applicable, add screenshots to help explain your problem.

    Additional context

    Add any other context about the problem here.

    bug 
    opened by kishore3739 2
  • Bngblaster session is not getting terminated with either Ctrl+c or 'terminate' command during longevity test

    Bngblaster session is not getting terminated with either Ctrl+c or 'terminate' command during longevity test

    Describe the bug Bngblaster session is running from past ~10hrs and When ctrl+c signal is sent to the running bngblaster session, session is not getting terminated. Same results, when I used command 'terminate' using cli.

    [00:38][[email protected]:~/bngblaster][main*]$date;sudo bngblaster -C ../srv2_zap_test_config_4.json -S test.socket;date Fri Apr 9 00:38:42 IST 2021 Apr 09 00:38:43.065249 Getting MAC address 3c:fd:fe:c2:06:48 for interface ens2f0 Apr 09 00:38:43.137562 Add interface ens2f0 Apr 09 00:38:43.209226 Getting MAC address 3c:fd:fe:c2:06:49 for interface ens2f1 Apr 09 00:38:43.289576 Add interface ens2f1 Apr 09 00:38:43.292030 Opened control socket test.socket Apr 09 00:38:44.403417 ALL SESSIONS ESTABLISHED ^CApr 09 09:10:02.636662 Received signal Interrupt (2), initiating teardown

    ^CApr 09 09:13:13.806373 Received signal Interrupt (2), initiating teardown Apr 09 09:21:43.816481 Teardown request

    Apr 09 09:26:44.015730 Teardown request

    Apr 09 09:26:55.626354 Teardown request


    [email protected]:~/bngblaster$ sudo ./cli.py test.socket terminate { "status": "ok", "code": 200, "message": "terminate all sessions" } [email protected]:~/bngblaster$ sudo ./cli.py test.socket terminate { "status": "ok", "code": 200, "message": "terminate all sessions" } [email protected]:~/bngblaster$ sudo ./cli.py test.socket session-info { "status": "warning", "code": 404, "message": "session not found" } [email protected]:~/bngblaster$

    A clear and concise description of what the bug is.

    To Reproduce

    Version (bngblaster -v):

    JSON configuration:

    {
    }
    

    Steps to reproduce the behavior:

    1. This is a longevity test

    Expected behavior bngblaster session must have terminated.

    A clear and concise description of what you expected to happen.

    Screenshots

    If applicable, add screenshots to help explain your problem.

    Additional context

    Add any other context about the problem here.

    bug 
    opened by bhishma-acharya 2
  • Service-name should be present in PADR

    Service-name should be present in PADR

    Describe the bug

    PPPoE Servers should check existing Service-name in PARD packed as described in https://tools.ietf.org/html/rfc2516#section-5.3 , but BNGBlasted does not use Service-name tags.

    bug pppoe 
    opened by DmitriyEshenko 2
  • 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 3
  • 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 
    opened by mivsvit 4
  • Add a cli command to fetch consolidated session-info

    Add a cli command to fetch consolidated session-info

    Currently, we can get the setup time/setup rate for the sessions from the report, once the instance is stopped

    Report:

    Sessions PPPoE: 10 IPoE: 0 Sessions established: 10/10 DHCPv6 sessions established: 10 Setup Time: 95 ms Setup Rate: 105.26 CPS (MIN: 105.26 AVG: 105.26 MAX: 105.26) Flapped: 0

    Please add a bngblaster-cli command to fetch the same before stopping the instance

    enhancement 
    opened by PraveenM94 0
  • A10NSP DHCPv4/v6 Support

    A10NSP DHCPv4/v6 Support

    Add support for DHCPv4 and DHCPv6 on A10NSP interfaces.

    • [x] DHCPv4
    • [x] ARP
    • [ ] DHCPv6
    • [ ] ICMPv6 ND

    PR: https://github.com/rtbrick/bngblaster/pull/88 Branch: https://github.com/rtbrick/bngblaster/tree/a10nsp_dhcp

    enhancement 
    opened by GIC-de 2
  • 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 3
  • Support ANCP

    Support ANCP

    Hey there,

    we really would like to use the BNGBlaster to test our L2BSA setup. However we currently use ANCP triggered subscriber interfaces on our Juniper BNGs as described there: https://www.juniper.net/documentation/us/en/software/junos/subscriber-mgmt-wholesale/topics/concept/ancp-layer2-bitstream-access-overview.html

    So the access node sends an ANCP port-up message, gets the appropriate A10-NSP from the radius and forwards the subscriber traffic to it.

    So to test like thousands of PPPoE client sessions we need to first trigger thousands of ANCP port-up messages. Currently I use your library https://github.com/GIC-de/PyANCP for it, which works absolutely great.

    So currently we've to maintain two configurations and can do it only after each other. First trigger all ANCP port-up messages and afterwards establish PPPoE sessions using BNGBlaster. An build-in feature to send an ANCP port-up before establishing a PPPoE session would be a lot easier and would create a more realistic scenario.

    Do you've any plans to support ANCP? Or is it already implemented and I didn't find it in the documentation.

    Maybe you've an idea for a more elegant solution, like calling BNGBlaster from a Python script which also sends the ANCP port-up messages.

    Thank you very much!

    enhancement 
    opened by SoerenBusse 4
Releases(0.7.8)
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.2k Jul 3, 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 788 Jun 28, 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 5 Dec 1, 2021
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.5k Jun 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 37 Jun 15, 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 12 May 31, 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 126 May 11, 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 4 Nov 24, 2021
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 25 Jun 17, 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 Jun 27, 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 2.8k Jul 1, 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 57 Jun 27, 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 35 Jun 25, 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 34 Jun 21, 2022