Future Work

More PDUs need to be supported. Currently we support Ethernet, ARP, MPLS, 802.1q, IP, IPv6, ICMP, ICMPv6, TCP, UDP, OSPF, BGP but more PDUs are definitely needed. In particular, DHCP and IKE would be extremely nice to have
The current way of defining PDUs relies on CLI switches, e.g. "send_network -ipv4 -D cisco.com -icmp-echo 0:1 -payload 1234567890abcdef". This is very cumbersome and kludgy. I think a better way would be to have something like "send_network ipv4(dst=cisco.com)/icmp-echo(0:1)/payload(123456790abcdef)" (DONE in the big PDU definition re-write that took place during December 2006/January 2007)
A replay command is needed because currently, replaying traffic relies on the send_network and the expect_network commands, which add a bit of complexity and performance hit
When creating a network listener (via spawn_network) that reads from a PCAP file there must be a switch that causes the timing in which packets were capture to be respected when reading from that listener. This is useful for replaying traffic (DONE)
Python/Perl/Ruby bindings - it'd be nice to be able to provide PDU builders in some of these languages so people that are not comfortable with C can expand NetworkExpect
Add support for a NetExpect Tcl package that can be invoked via "package require NetExpect"
Re-write (again!) the PDU definition code in libpdus so it doesn't take a rocket scientist with lots of free time to add new PDUs. Writing a parser that has grammar for each possibility is insane and representative of extremely poor design and bad taste.
Implement a traffic generator command similar to the send_network command but that goes into the background as soon as executed and that can be sent commands (to start and stop traffic, to change packet transmission delays, etc.) from the parent process
Implement passive fingerprinting (p0f)?
A port to Lua (but maintaining the Tcl version!) would be very nice