I'am developing an industrial application based on an open source DHCP client.
I am setting a custom DHCP client class id (DHCP Option 77)
ipconfig /setclassid "Local Area Connection" "SOME_CUSTOM_CLASS_ID"
and in Wireshark I am capturing the DHCP handshake. The custom class id is present in the DHCP request, but wireshark has the Option 77 info highlighed with the error "malformed option".
Referring to RFC 3004 standard i found that each instance of user class data should have a 1 octet prefix of the length that can fixe the problem and dismiss DHCP all wireshark error.
The problem know is that some version of wireshark detect this error like version 1.10.6 other version can't detect like version 1.6.5.
Any ideas on this? Is it a bug in Wireshark ?
First:
Dissection of DHCP Option 77 was first included in Wireshark 1.10 so Wireshark 1.6 and Wireshark 1.8 don't know about this option and thus don't show any error specifically about that option.
Second:
I'm a bit unclear as to your question:
Are you asking why Wireshark 1.6 doesn't show an error which is correctly shown in
Wireshark-1.10 ?
If so, please see 'First' above.
if not please clarify.
Microsoft introduced an incompatible format which is described at 2.2.6.1 User Class Option Sent by DHCPv4 Client to DHCPv4 Server. The format is now:
Option Code (77)
Option Length
User_Class_Data (variable length)
Wireshark only supports the RFC 3004 format in Wireshark 2.0 (and I guess also the upcoming 2.2). For more details on various implementations, see this ask.wireshark.org.
Related
I set up a GNS3 topology with Asterisk and 2 softphones (Blink) and i tried to enable secure calls.(https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial)
TLS works, SRTP don't work .
In my Asterisk (last version), SRTP module is enable and running (https://imgur.com/HOlFFlH). Pjsip.endpoint.conf have "media_encryption = sdes" in GUI looks like this https://imgur.com/IAQM1Qt.
The the softphones configuration is this - https://imgur.com/NbjFqFG
[100]
type=endpoint
aors=100
auth=100-auth
tos_audio=ef
tos_video=af41
cos_audio=5
cos_video=4
allow=ulaw,alaw,gsm,g726,g722
context=from-internal
callerid=CEO <100>
dtmf_mode=rfc4733
transport=0.0.0.0-tls
aggregate_mwi=yes
use_avpf=no
rtcp_mux=no
ice_support=no
media_use_received_transport=no
trust_id_inbound=yes
media_encryption=sdes
timers=yes
media_encryption_optimistic=no
send_pai=yes
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
language=en
What seems strange to me is that although encryption is SDES mandatory, I can make calls, even if traffic is UDP.
https://imgur.com/8K370Ia It looks as if the settings in the asterisk match the ones on the softphone, but the traffic is not encrypted.
Where am I wrong? What am I missing? Thank you!
SRTP is function of endpoint.
So ALL your endpoints SHOULD support SRTP.
I think i found the answer.
In wireshark I enable RTP over UDP (rtp_udp) and now i see RTP trafic instead of UDP. When i listen the call is only noise, so is encrypted, but why wireshark don't show me SRTP traffic?
I have a setup having Ipsec Tunnel between two end systems. When I capture packets on outgoing interface e.g eth0 I can only see encrypted ESP packets going out of my system. I have to go and look at the receiving end to see what was actually transmitted i.e on the receiving end I can see packets after decryption. similarly for the ack sent by receiver. How it works actually in the linux kernel ? Is there a way to see the packets on sender side in tcpdump before they get encrypted ?
You have three questions in your question :
How to see outgoing ESP packets in tcpdump before they get encrypted ?
How it works actually in the linux kernel ?
Is there a way to see the packets on sender side in tcpdump before they get encrypted ?
The answer to the third question is
It depends on your kernel and which implementation you are using.
If you are using KLIPS in 2.4 Kernel as part of any of the *swan solutions, then Yes.
Otherwise if you are using the 2.6 kernel which uses the KAME / *BSD model then
No, unless you change your Ipssec or iptables configuration so that you send the packets to another interface unencrypted and then forward the unencrypted packets to an interface which they will be encrypted on.
The answer to the first question is change your iptables configuration and IPSec configuration.
To send the data from one interface to another interface on the same host.
To setup forwarding of data from that second interface to your destination
configure the ip address of the second interface in the security policy to create the tunnel on the second interface.
This way could can tcpdump on the encrypted interface without changing anything and before the data is encrypted.
For the KLIPS and 2.4 kernel it is just as simple as specific the interface in tcpdump as ipsec0 using the -i switch.
Other options to see the data unencrypted involve using tcpdump with -E flag and relevant parameters (see man page) which decrypts the data after it is encrypted or to use tcpdump to capture the encrypted data and then decrypt it in Wireshark (more information regarding ESP decryption of IPSec in Wireshark is located here).
Alternatively you can place instrumentation using printk or printk_times in the source code to xfrm or esp_input.
Regarding the second question, there are several pictures which explain how it works at a high level including the ones explaining the Solaris Implementation as part of Oracle's System Administration Guide: IP Services and Linux's Foundation Network Flow through the kernel diagram.
Also see the following reference. Basically either manual configuration using setkey or automatic configuration using an IKE daemon in userspace passes the information to the XFRM which then transforms the packet before it reaches netfilter prerouting.
See here for more information on the history of KLIPS and KAME.
Assuming you are on Linux:
My approach is to place iptables rule with NFQUEUE target on the correct place in the processing pipeline. Then use tshark with -i nfqueue to capture packets.
I am able to get the packets in the network by tcpdump.I want to get the device info like computer name,its model name ,OS running on it etc.
Is it possible by using tcpdump packets .
I got the mac address (by arp),IP but which layer protocol giving this above information what I want.
Can you tell me how to use this dumped data to get my required data.
Thanks
but which layer protocol giving this above information what I want
The details you mention aren't present in network data - for example there's no point in a TCP segment advertising "Windows XP emitted this.". At most you can use tools like nmap that try to guess the OS based on subtle network engine implementation differences.
I'm trying to use open source Java SIP client Jitsi to do video chat.
To eliminate all network and proxy issues, I've setup my own SIP proxy Asterisk and both the clients are on the same LAN. I also configured Asterisk to either relay the RTP packets or do direct communications between the peers.
The above error is from Asterisk and on chan_sip.c:8915 (asterisk-10.0.0-beta). The Asterisk code checks against port 0.
I was stuck with the above problem. I can try to modify Jitsi code to not use port 0, but wondering if there's a better way and if port 0 is a legal value to start with.
BTW, I was successful having 2 Xlite (commercial software from CounterPath) to transmit H263 videos between each other. I could not get Xlite to do so with Jitsi, nor to have both Jitsi clients send video.
I want to use a Java client as I'm much more adapt at Java. And I'm also hoping to be able to reuse the same codebase for Android in the future.
Port set to 0 is perfectly legal and part of SDP offer/answer model. In fact, it probably means that there was something wrong with your SDP offer. For example, if you support PCMA codec and the peer only support PCMU, he will reject the SDP offer with the port set to 0. There can be quite some reasons with the offer was rejected but codec incompatibility is probably the most common.
To really debug this if you want, you may need to look at the packets (with Wireshark for example).
You asked "... but wondering if there's a better way and if port 0 is a legal value to start with."
Port 0 is perfectly legal in SDP. In particular, SIP's offer/answer model in RFC 3264 section 5.1 says that
A port number of zero in the offer indicates that the
stream is offered but MUST NOT be used.
I have an issue where i have connected my linux server to a serial port. There is a continous flow of data from serial port which comes through epabx.
In Minicom i get first call's data and from second call it goes offline.
I dont see any data.
Can some one help me on this.
Thanks for all the help given by you. Finally i have got the error solved.
God knows how i started getting the data.
But still i am listing the steps i performed to get correct data.
Sometimes data from serial port wont be capturing in the processing form application.
It may be because of the following issues.
1.Serial port not connected properly.
2.Serial port cable not working.
3.Some pins on serial port are damaged or connection lost.
Note: For above all reasons contact the client person or person in charge of epabx systems.
4.Data not getting displayed on hypertiminal.
This is a common issue in linux which uses minicom as hyperterminal.
Sol: Check the version of the minicom before running it on linux. If the version is minocom 2.1 then some process would be blocking the incoming data.
Uninstall minicom 2.1 and reinstall minicom 2.0
It is said that gate 8 process would block the incoming data.
minicom may be responding to control characters in your data. I'd recommend something simple but effective like
od -t x1 -t a /dev/ttySomething
to dump your data in both hex and as text.
You should also check that your port settings are correct i.e. bitrate, parity, stop bits, flow-control. Sometimes, when your settings are not correct, you will end up with weird results. Also, you need to check that your protocol is only sending texts as Carl mentioned.