Stephen Fisher | 1 Aug 21:53 2011

Re: certificates and HTTPS pdus

On Tue, Jul 05, 2011 at 03:19:45AM +0200, Andrej van der Zee wrote:
> Thanks for your email.
> 
> > You need the private key from the server ('PEM' format private key or a
> > PKCS#12 keystore.) as perĀ http://wiki.wireshark.org/SSL
> 
> And I assume their is no way to obtain the server's private key
> without contacting the server's system administrators and become
> really good friends first ;)
> 
> Is there absolutely no way around this?

There was some work (completed?) to make Firefox be able to dump certain 
types of SSL keys for export into Wireshark.  I can't find the info now, 
but it was discussed either in a Wirshark bug and/or the -dev mailing 
list.
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

Stephen Fisher | 1 Aug 21:54 2011

Re: Ethernet FCS not verified


On Mon, Jul 04, 2011 at 06:10:31PM +0200, Martin Isaksson wrote:

> here are two packets - one packet with incorrect FCS and the other 
> with correct FCS (according to version 1.4.2).

Better yet, please open a bug at https://bugs.wireshark.org/ if you 
haven't already, so we don't forget about it.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

damker | 2 Aug 08:24 2011

question about RSL(radio signalling link)

Hi all:

 

In the "Channel Identification IE" in RSL, 3Gpp TS 48058 said that:

 

 

In 3GPP TS 44018:

 

 

Is there should be 1 octet to be the Channel Description IEI?, but in wireshark there is not.

 

 

The attachment is a sample.

Attachment (RSL_CHANNEL ACTIVATION.pcap): application/octet-stream, 114 bytes
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe
Peter Huber | 2 Aug 12:15 2011
Picon
Picon

time gaps in packet stream

Dear list,

this is a newbee question. We tried everything we came up with, but need help now.

We are running upstream data transfer over a high latency connection (170ms RTT, Internet2). 

In order to test the possible data rates we can get, we use 

   sudo tc qdisc add dev eth0 root netem delay 170ms

on a machine connected (1Gbit) to our local network. We experimented with different window sizes
sending/receiving between 3 and 30Mbytes.

In the test environment but identically also in the real data upstream case to the remote location, we see in
the wireshark IO statistics at 0.01 sec Tick interval that the data transfer only happens in short spikes
(see attached plot). And indeed there are many large (nearly-constant over the transfer) delays between
some packets, e.g. between packet 23822 and 23823

   23823 25.537234   0.155031

Is this normal? Is there anything we could do to improve the situation? Why does the window size not grow
although we do not have packet loss?

Any help would be greatly appreciated.

All the very best,

Peter

  No.   Time        Delta Time  Source         Destination    Protocol    Info 
  23800 25.380762   0.000109    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85134728
Win=2304000 Len=0
  23801 25.380812   0.000050    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85143416
Win=2304000 Len=0
  23802 25.380942   0.000130    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85149208
Win=2304000 Len=0
  23803 25.380955   0.000013    YYY.YYY.YY.YY  XXX.XXX.XX.XX  HTTP     Continuation or non-HTTP traffic[Packet
size limited during capture] 6912
  23804 25.380964   0.000009    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85153552
Win=2304000 Len=0
  23805 25.381068   0.000104    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85162240
Win=2304000 Len=0
  23806 25.381203   0.000135    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85175272
Win=2304000 Len=0
  23807 25.381303   0.000100    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85186856
Win=2304000 Len=0
  23808 25.381390   0.000087    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85195544
Win=2304000 Len=0
  23809 25.381445   0.000055    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85201336
Win=2304000 Len=0
  23810 25.381599   0.000154    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85207128
Win=2304000 Len=0
  23811 25.381660   0.000061    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85215816
Win=2304000 Len=0
  23812 25.381673   0.000013    YYY.YYY.YY.YY  XXX.XXX.XX.XX  HTTP     Continuation or non-HTTP traffic[Packet
size limited during capture] 6912
  23813 25.381688   0.000015    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85220160
Win=2304000 Len=0
  23814 25.381791   0.000103    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85224504
Win=2304000 Len=0
  23815 25.381812   0.000021    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85233192
Win=2304000 Len=0
  23816 25.381832   0.000020    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85241880
Win=2304000 Len=0
  23817 25.382139   0.000307    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85253464
Win=2304000 Len=0
  23818 25.382148   0.000009    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85250568
Win=2304000 Len=0
  23819 25.382151   0.000003    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85259256
Win=2302656 Len=0
  23820 25.382165   0.000014    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85256360
Win=2304000 Len=0
  23821 25.382194   0.000029    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85267944
Win=2304000 Len=0
  23822 25.382203   0.000009    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85270840
Win=2304000 Len=0

  23823 25.537234   0.155031    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85273736
Win=2304000 Len=0

  23824 25.537545   0.000311    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85283872
Win=2304000 Len=0
  23825 25.537556   0.000011    YYY.YYY.YY.YY  XXX.XXX.XX.XX  HTTP     Continuation or non-HTTP traffic[Packet
size limited during capture] 6912
  23826 25.537571   0.000015    XXX.XXX.XX.XX  YYY.YYY.YY.YY  TCP  46561 > http [ACK] Seq=153 Ack=85295456
Win=2304000 Len=0

--

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe
Anders Broman | 2 Aug 14:55 2011
Picon

Re: question about RSL(radio signalling link)

Hi,
You are right I have checked in a fix Committed revision 38310. If you are using Windows you can download a development build
in an hour or so from http://www.wireshark.org/download/automated/win32/ with the SVN number of 38310 or bigger.
Regards
Anders

From: wireshark-users-bounces <at> wireshark.org [mailto:wireshark-users-bounces-IZ8446WsY0/dtAWm4Da02A@public.gmane.org] On Behalf Of damker
Sent: den 2 augusti 2011 08:24
To: 'Community support list for Wireshark'
Subject: [Wireshark-users] question about RSL(radio signalling link)

Hi all:

 

In the "Channel Identification IE" in RSL, 3Gpp TS 48058 said that:

 

 

In 3GPP TS 44018:

 

 

Is there should be 1 octet to be the Channel Description IEI?, but in wireshark there is not.

 

 

The attachment is a sample.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe
Zaki Akhmad | 4 Aug 08:14 2011
Picon

Knowing What Exploit from .pcap File

Hello,

I just tried one of the CTF (Capture The Flag). On this CTF, they gave
a pcap file. I tried to analyze it with Wireshark. Any hint how do I
know what exploit is from the pcap file? How to identify the packet
with the exploit activity?

Thanks!

--

-- 
Zaki Akhmad
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

news.gmane.com | 4 Aug 13:51 2011
Picon
Picon

ICMP Redirect

I have observed a strange operation of a NAT router. There are two hosts 
(A,B) connected at the private network of the router (R). I observe that the 
NAT router "comments" a lot of packets with an ICMP redirect.

Example:

A=192.168.1.90
B=192.168.1.91
R=192.168.1.1

I choosed the corresonding identifier for the MAC column, so that usually 
the MAC and the IP column are identical. The MAC field shows, who has really 
sent the packet (see #52, #57).

pkt  MAC  IP   Packet content
#50  A->B A->B TCP,SYN, port:1502->800, seq:4048334798
#51  R->A R->B ICMP Redirect, Type:5, Code:1, Gateway address: B
               ICMP.IP identical with #50
               ICMP.TCP: src:1502, dst:800, seq:4048334798
#52  R->B A->B TCP,SYN, port:1502->800, seq:4048334798

I think this is really strange. Why in hell should the NAT router 'comment' 
any TCP communication when all packet are sent in the local network and 
without any router?

What does the router tells A that it should use "B instead of B" (the same) 
for the packet #50? Is this IP spoofing, what it does in packet #52?

Any ideas appreciated.

--

-- 
Andy

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

Marcelo Mandolesi | 4 Aug 15:34 2011
Picon

Re: Knowing What Exploit from .pcap File

Can you elaborate on this particular CTF? Perhaps provide us a link to it?

On Thu, Aug 4, 2011 at 2:14 AM, Zaki Akhmad <zakiakhmad <at> gmail.com> wrote:
Hello,

I just tried one of the CTF (Capture The Flag). On this CTF, they gave
a pcap file. I tried to analyze it with Wireshark. Any hint how do I
know what exploit is from the pcap file? How to identify the packet
with the exploit activity?

Thanks!

--
Zaki Akhmad
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users-IZ8446WsY0/dtAWm4Da02A@public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request-IZ8446WsY0/dtAWm4Da02A@public.gmane.org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe
Stephen Fisher | 4 Aug 19:37 2011

Re: Scanning subnetwork considered bad or not?

On Mon, Jul 25, 2011 at 02:25:29PM +0200, RUOFF, LARS (LARS)** CTR ** wrote:

> After setting up a trap, i finally found the guilty to be the Canon 
> Network Scanner utility. (The word "Scanner" here initially stands for 
> machines scanning sheets of paper, not networks! ;) )

It's trying to make a network connection of some sort to every IP 
address on the subnet.  If there isn't already an ARP entry for that IP 
address in the local machine's ARP cache, then it has to generate an ARP 
request to find it if it's there.

> Ok, so normal behaviour. But isn't this behaviour seriously violating 
> LAN netiquette??

Yes.

> Do a lot of services use this?

I don't think so, but many use almost-just-as-annoying broadcasts which 
reach every device anyway.

> I guess that this would be a NO GO in an enterprise environment?

I would say yes, but after years of experience working in such 
environments, it turns out that most don't care since it's more 
important that things "just work" (no matter how poorly they are 
implemented) than "do the right thing" :(.

It would be better to use multicasts and/or a standardized method of 
service discovery such as Simple Service Discovery Protocol (SSDP).
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe

Zaki Akhmad | 5 Aug 05:33 2011
Picon

Re: Knowing What Exploit from .pcap File

On Thu, Aug 4, 2011 at 8:34 PM, Marcelo Mandolesi
<rolldabass@...> wrote:

> Can you elaborate on this particular CTF? Perhaps provide us a link to it?

Well, it's OWASP AppSecUSA 2011 CTF #1[1] and the .pcap file is
here[2]. Although they had provided the answer[3] I still couldn't
understand how to identify the exploit.

[1]http://www.appsecusa.org/ctf.html
[2]http://www.appsecusa.org/challenges/dFF5R0lNcXFTS0xFeXgtSXd2N2VySWc6MQ.pcap
[3]http://www.appsecusa.org/challenges/a.txt

Thanks!
--

-- 
Zaki Akhmad
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@...>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@...?subject=unsubscribe


Gmane