# $FreeBSD: head/share/examples/netgraph/ngctl 222179 2011-05-22 14:23:48Z uqs $ # # This is an example that shows how to send ASCII formatted control # messages to a node using ngctl(8). # # What we will do here create a divert(4) tap. This simply dumps # out all packets diverted by some ipfw(8) divert rule to the console. # # Lines that begin with ``$'' (shell prompt) or ``+'' (ngctl prompt) # indicate user input # # First, start up ngctl in interactive mode: $ ngctl Available commands: connect Connects hook of the node at to debug Get/set debugging verbosity level help Show command summary or get more help on a specific command list Show information about all nodes mkpeer Create and connect a new node to the node at "path" msg Send a netgraph control message to the node at "path" name Assign name to the node at read Read and execute commands from a file rmhook Disconnect hook "hook" of the node at "path" show Show information about the node at shutdown Shutdown the node at status Get human readable status information from the node at types Show information about all installed node types quit Exit program + # Now let's create a ng_ksocket(4) node, in the family PF_INET, # of type SOCK_RAW, and protocol IPPROTO_DIVERT: + mkpeer ksocket foo inet/raw/divert # Note that ``foo'' is the hook name on the socket node, which can be # anything. The ``inet/raw/divert'' is the hook name on the ksocket # node, which tells it what kind of socket to create. # Lets give our ksocket node a global name. How about ``fred'': + name foo fred # Note that we used ngctl's ``name'' command to do this. However, # the following manually constructed netgraph message would have # accomplished the exact same thing: + msg foo name { name="fred" } # Here we are using the ASCII <-> binary control message conversion # routines. ngctl does this for us automatically when we use the # ``msg'' command. # Now lets bind the socket associated with the ksocket node to a port # supplied by the system. We do this by sending the ksocket node a # ``bind'' control message. Again, ngctl does the conversion of the # control message from ASCII to binary behind the scenes. + msg fred: bind inet/192.168.1.1 # The ksocket accepts arbitrary sockaddr structures, but also has # special support for the PF_LOCAL and PF_INET protocol families. # That is why we can specify the struct sockaddr argument to the # ``bind'' command as ``inet/192.168.1.1'' (since we didn't specify # a port number, it's assumed to be zero). We could have also # relied on the generic sockaddr syntax and instead said this: + msg fred: bind { family=2 len=16 data=[ 2=192 168 1 1 ] } # This is what you would have to do for protocol families other # that PF_INET and PF_LOCAL, at least until special handling for # new ones is added. # The reason for the ``2=192'' is to skip the two byte IP port number, # which causes it to be set to zero, the default value for integral # types when parsing. Now since we didn't ask for a specific port # number, we need to do a ``getname'' to see what port number we got: + msg fred: getname Rec'd response "getname" (5) from "fred:": Args: inet/192.168.1.1:1029 # As soon as we sent the message, we got back a response. Here # ngctl is telling us that it received a control message with the # NGF_RESP (response) flag set, the response was to a prior ``getname'' # control message, that the originator was the node addressable # as ``fred:''. The message arguments field is then displayed to # us in its ASCII form. In this case, what we get back is a struct # sockaddr, and there we see that our port number is 1029. # So now let's add the ipfw divert rule for whatever packets we # want to see. How about anything from 192.168.1.129. + ^Z Suspended $ ipfw add 100 divert 1029 ip from 192.168.1.129 to any 00100 divert 1029 ip from 192.168.1.129 to any $ fg # Now watch what happens when we try to ping from that machine: + Rec'd data packet on hook "foo": 0000: 45 00 00 3c 57 00 00 00 20 01 bf ee c0 a8 01 81 E..