[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GSoC - tcptest] - Regression Tests, Conformance Tests...
- To: Victor Hugo Bilouro <bilouro_(_at_)_bilouro_(_dot_)_com>
- Subject: Re: [GSoC - tcptest] - Regression Tests, Conformance Tests...
- From: "Bruce M. Simpson" <bms_(_at_)_FreeBSD_(_dot_)_org>
- Date: Tue, 03 Jun 2008 09:16:28 +0100
- Cc: net_(_at_)_freebsd_(_dot_)_org
Victor Hugo Bilouro wrote:
I've made a lot of changes to it; diffs are with him but I can send folk a
copy of my Mercurial repo.
I would appreciate that.
As an example of the new PCS syntax and expect() stuff, I'll forward you
the IGMPv2 test off-list. (Also sent.)
humm, track state is needed to make TCP tests.
It is something you'll have to build yourself around the expect()
The experimental IP reassembly code (in pcs/packets/ipv4sar.py) might be
a good place to start. It isn't finished, but it should demonstrate the
general principles -- i.e. you read packets in a loop and you pass them
to an object which knows what to do, in this case, ipv4sar.
One big problem I had was that the concept of fragmentation requires
deep copies of PCS objects. I imagine that's less of an issue for TCP
segmentation, as the situation is made somewhat easier by the fact
you're dealing with streams.
BTW: My snapshot of PCS fixes the IP and TCP option parsers. If you look
at the IGMP and DHCP decoders, there is an example of a dictionary
driven option parser. This could also be applied to TCP where it's
likely to be useful.
I believe most of the bugs have been shaken out of expect(). The main
problem is buffering and the fact that expect() depends on non-blocking
I/O. pcap can return more than one packet from the kernel every time you
call into the non-blocking dispatch function, so I did some internal
refactoring to allow expect() to deal with that.
So your code has to be able to deal with multiple matches from the
Connector, even if you only asked to match at *least* one packet.
"Count" is mostly about stopping expect() from hanging the flow of
The syntax and semantics are intentionally similar to PExpect for
Python. In fact the IGMPv2 test uses PExpect to drive a QEMU virtual
machine encapsulated as a Python object, for regression testing the IGMP
code. So my suggestion is check out PExpect too.
I didn't find his site, can you send me?
I've added some Scapy-like syntax to PCS which can make the code look a
freebsd-net_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-net-unsubscribe_(_at_)_freebsd_(_dot_)_org"