Possible problem ?

While trying to troubleshoot a RH type 2 header blackholing with scapy6
following directions from nautilus6 the responder ( Cisco IOs 12.4.1T4 )
reports parameter problem when my MN sends BUs.

Attached is the wireshark marked packet with the potentional problem.

Regards,
Dimitris

-- 
--
Dimitrios K. Kalogeras

Electrical Engineer, Ph.D.
Network Engineer
NTUA/GR-Net Network Management Center
_____________________________________
icq:   11887484
voice: +30-210-772 1863
fax:     +30-210-772 1866
e-mail: D.Kalogeras <at> noc.ntua.gr
pub   1024D/0E421B50 2007-01-17 [expires: 2008-01-17] Dimitrios
Kalogeras (dkalo) <D.Kalogeras <at> noc.ntua.gr>
      Key fingerprint = F8C8 7B67 74A4 1F82 CDDF 8554 E1EF 7FAE 0E42 1B50
PGP-KEY: http://ajax.noc.ntua.gr/~dkalo/dkalo_pgp.txt

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Re: Possible problem ?

Hi,

> While trying to troubleshoot a RH type 2 header blackholing with  
> scapy6
> following directions from nautilus6 the responder ( Cisco IOs  
> 12.4.1T4 )
> reports parameter problem when my MN sends BUs.

Could you be more specific ? As such, I do not see any Scapy related  
issue.

Guillaume

--
Guillaume Valadon / ギョーム バラドン
guedou <at> hongo.wide.ad.jp

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Performance problem

Hi there!

I am still enjoying scapy, but found another problem (apart from the
still-existing promiscious bug).

I see more than 20% cpu usage when scapy runs (command below). As I need
to monitor more than 1 GBit/sec of traffic and need a lot of CPU power
on that machine, I like to see scapy run with less CPU usage. I think
this could be related to the promiscious bug? Is there a better way to
filter for the packets I need?

I am looking for UDP packets of the form "UDP port unreachable"
(specific to port UDP 1234, if that helps).

r = sniff(lfilter=lambda x : x.haslayer(UDPerror), filter="icmp[0] = 3",timeout=2)

Thanks,
--

-- 
Carsten Otto
c-otto <at> gmx.de
www.c-otto.de

Re: Performance problem

Carsten Otto schrieb:
> I am looking for UDP packets of the form "UDP port unreachable"
> (specific to port UDP 1234, if that helps).
> r = sniff(lfilter=lambda x : x.haslayer(UDPerror), filter="icmp[0] = 3",timeout=2)

You could try to tighten your BPF filter a bit further, i.e. add 
expressions to look for
- ICMP code "port unreachables" (icmp[1] = 3)
- UDP port 1234 in the ICMP payload. (This may make your lfilter 
unneccessary.)

But honestly, I haven't tested this and I don't know if it will make 
much difference.

Regards
Dirk

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Issue with passing hex value into Scapy IP Options field

Hi,
    I wonder if you can help me. I am trying to use Scapy to pass ICMP
packets with an incrementing IP Option.

To do this I am:
a=IP()
b=ICMP()

What I want to do from here is to pass on to a.options the value in hex,
starting with "\x00\x00\x00\x00"

My problem is that if I set a.option="\x00\x00\x00\x00", this works fine.
However, If I attempt to make each octet a variable and create this option,
When I send the packet, it comes out as "\\x00\\x00\\x00\\x00", and does not
get translated correctly.

Here is a simplified version of my script, with all looping taken out.
################################
a=IP()
b=ICMP()

a.dst='10.211.55.2'

#Set int variables to increment
O1 = 0

O2 = 0

O3 = 0

Re: Issue with passing hex value into Scapy IP Options field

On Jun 27, 2008, at 11:13 AM, Colin Ross wrote:
> What I want to do from here is to pass on to a.options the value in  
> hex,
> starting with "\x00\x00\x00\x00"
>
> My problem is that if I set a.option="\x00\x00\x00\x00", this works  
> fine.
> However, If I attempt to make each octet a variable and create this  
> option,
> When I send the packet, it comes out as "\\x00\\x00\\x00\\x00", and  
> does not
> get translated correctly.
[code snipped]
>
> In my actual IP Packet on the wire, my hex output is the ASCII  
> equivalent to
> the string (beginning with 5c 78 30 30, which is the hex ASCII of  
> \x00),
> when my goal at this point is to have it 00 00 00 00

To convert a Python integer into a 1-byte-long string with that byte  
value, use the chr() function. Using '%x' will (as you've discovered)  
produce a string with an ascii hexadecimal representation of the  
integer.

    >>> chr(0)
    '\x00'

You could also look into the "struct" module which will do some more  

Re: Issue with passing hex value into Scapy IP Options field

Hi Colin,

I'm not sure if this is the most elegant solution to your problem, but
it should work. You can use the struct module to fill in values into
the options field.

>>> struct.pack("B", 1) + struct.pack("B", 2) + struct.pack("B", 3) +
struct.pack("B", 4)
'\x01\x02\x03\x04'
>>> struct.pack("B", 1) + struct.pack("B", 4) + struct.pack("B", 3) +
struct.pack("B", 4)
'\x01\x04\x03\x04'
>>> struct.pack("B", 0) + struct.pack("B", 0) + struct.pack("B", 0) +
struct.pack("B", 0)
'\x00\x00\x00\x00'
>>> struct.pack("B", 4) + struct.pack("B", 3) + struct.pack("B", 2) +
struct.pack("B", 1)
'\x04\x03\x02\x01'
>>> a=struct.pack("B", 4) + struct.pack("B", 3) + struct.pack("B", 2) +
struct.pack("B", 1)
>>> pkt = IP()
>>> pkt.options
''
>>> pkt.options = struct.pack("B", 4) + struct.pack("B", 3) +
struct.pack("B", 2) + struct.pack("B", 1)
>>> pkt.show2()
###[ IP ]###
  version= 4L
  ihl= 6L
  tos= 0x0

Re: Issue with passing hex value into Scapy IP Options field

Colin Ross wrote:
> I am trying to use Scapy to pass ICMP packets with an incrementing IP Option.

As Wim and Jochen have already suggested, using the struct module and a 
for loop may be the easiest way to do it.

But remember that IP options have an internal type-length-value 
structure and can be of variable length. So just cycling through a fixed 
4 byte field -- which would generate more than 4 billion packets -- 
might not be exactly what you want... See RFC 791 and [1] for more 
details. At least, I suggest using little-endian integers 
(struct.pack("<I", val)), so that the first bytes start changing first.

Best regards
Dirk

[1] http://www.iana.org/assignments/ip-parameters

---------------------------------------------------------------------
To unsubscribe, send a mail to scapy.ml-unsubscribe <at> secdev.org

Re: Issue with passing hex value into Scapy IP Options field