Adam Sampson <ats@xxxxxxxxx> writes: > Very nice! I've got it chiming away happily in the background Same here :-) > -- now, if it'd produce MIDI output... Well, if I get the underlying frequency chooser correctly the tones used aren't exactly midi notes. But apart from that, it should be about 30 minutes work for someone without active alsa seq knowhow :-). > Mario Lang <mlang@xxxxxxxxxxx> writes: >> P.S.: Soooo, who knows how to easily decode a IP packets protocol >> number? Wouldnt it be sweet to have a separate instrument for >> each protocol? > > Have a look at RFC 790 and the following RFCs. Essentially you're just > after iphdr[9] -- although it won't be very exciting unless you're > running more protocols than just TCP and UDP. Well, there is at least ICMP, and I run other stuff like ipv6-in-ipv4, so it would be at least 4 protocols here :). Oh, and not to forget ARP which is something which would be interesting to highlight too. > Different instruments for different TCP/UDP ports would be more > interesting, and not much harder; I am not sure if I can process 65535 possible instruments :-) > you just need to figure out how long the options section in the IP > header is to know where the data starts, then look at the right > field in the UDP or TCP header depending on the IP protocol > number. > You'll need to chop the Ethernet header off the start of the packet > too, since libpcap includes it. Yeah, pcap_datalink() is probably a more robust way to check how long it actually is. > Here's a bit of messy code that'll do what you want in packet_handler > -- you'll probably want some more error checking: Thanks for this, I'll look into it. -- CYa, Mario
