|
Adam Barber
|
Getting an adaptor into promiscuous mode
|
|
Adam Barber
01/28/2013 6:55 PM
post98844
|
Getting an adaptor into promiscuous mode
I'm using an Intel 82559 ethernet adapter and I want to get it into promiscuous mode to monitor traffic.
The adapter has been working for me fine, and I can do things like change the ip address with commands such as:
ifconfig en0 192.168.1.10
Pinging other devices on the network works fine, and directed traffic works fine.
However, I've been trying to put the adapter into promiscuous mode, and it seems that I need to do it when loading the
driver. I'm not sure if there's a boot script somewhere that is doing that already (I haven't been able to find it) but
when I try the command:
io-pkt-v4 -d /lib/dll/devn-speedo.so promiscuous
and then run ifconfig en0 I get:
"ifconfig: SIOCGIFFLAGS en0: No such device or address" so somehow that command is destroying my ability to access en0
and I can no longer do anything on the network.
I'm pretty lost as to what the problem is here, and I can't seem to find anyone else who has experienced this issue.
|
|
|
|
|
|
Hugh Brown
|
Re: Getting an adaptor into promiscuous mode
|
|
Hugh Brown
01/29/2013 8:12 AM
post98851
|
Re: Getting an adaptor into promiscuous mode
If you want to monitor network traffic, you can use the tcpdump utility,
as this will place the adapter in promiscuous mode. I don't know why you
are getting the error message when you try to set promiscuous on the
command line, so I will take a look at this. I see that you are running
devn-speedo.so, but have you tried devnp-speedo.so?
On 2013-01-28 6:55 PM, "Adam Barber" <community-noreply@qnx.com> wrote:
>I'm using an Intel 82559 ethernet adapter and I want to get it into
>promiscuous mode to monitor traffic.
>
>The adapter has been working for me fine, and I can do things like change
>the ip address with commands such as:
>ifconfig en0 192.168.1.10
>
>Pinging other devices on the network works fine, and directed traffic
>works fine.
>
>However, I've been trying to put the adapter into promiscuous mode, and
>it seems that I need to do it when loading the driver. I'm not sure if
>there's a boot script somewhere that is doing that already (I haven't
>been able to find it) but when I try the command:
>io-pkt-v4 -d /lib/dll/devn-speedo.so promiscuous
>
>and then run ifconfig en0 I get:
>"ifconfig: SIOCGIFFLAGS en0: No such device or address" so somehow that
>command is destroying my ability to access en0 and I can no longer do
>anything on the network.
>
>I'm pretty lost as to what the problem is here, and I can't seem to find
>anyone else who has experienced this issue.
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post98844
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Hugh Brown
|
Re: Getting an adaptor into promiscuous mode
|
|
Hugh Brown
01/29/2013 8:35 AM
post98854
|
Re: Getting an adaptor into promiscuous mode
I have tested both devn-speedo.so and devnp-speedo.so under 6.5.0 SP1 and
they both accept the promiscuous command line argument. What version of
the O/S are you running?
On 2013-01-28 6:55 PM, "Adam Barber" <community-noreply@qnx.com> wrote:
>I'm using an Intel 82559 ethernet adapter and I want to get it into
>promiscuous mode to monitor traffic.
>
>The adapter has been working for me fine, and I can do things like change
>the ip address with commands such as:
>ifconfig en0 192.168.1.10
>
>Pinging other devices on the network works fine, and directed traffic
>works fine.
>
>However, I've been trying to put the adapter into promiscuous mode, and
>it seems that I need to do it when loading the driver. I'm not sure if
>there's a boot script somewhere that is doing that already (I haven't
>been able to find it) but when I try the command:
>io-pkt-v4 -d /lib/dll/devn-speedo.so promiscuous
>
>and then run ifconfig en0 I get:
>"ifconfig: SIOCGIFFLAGS en0: No such device or address" so somehow that
>command is destroying my ability to access en0 and I can no longer do
>anything on the network.
>
>I'm pretty lost as to what the problem is here, and I can't seem to find
>anyone else who has experienced this issue.
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post98844
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Adam Barber
|
Re: Getting an adaptor into promiscuous mode
|
|
Adam Barber
01/29/2013 10:38 AM
post98864
|
Re: Getting an adaptor into promiscuous mode
I am running 6.5.0.
My guess is that the driver is being loaded somewhere before I'm trying to, and I don't know where. I may be wrong about
this also.
I haven't tried devnp yet, as it doesn't seem to have a promiscuous option in the documentation.
The weird thing is that after I try the devn command, en0 no longer appears under ifconfig, so somehow calling the
driver command is doing something to remove my ability to see en0.
|
|
|
|
|
|
Hugh Brown
|
Re: Getting an adaptor into promiscuous mode
|
|
Hugh Brown
01/29/2013 11:06 AM
post98865
|
Re: Getting an adaptor into promiscuous mode
Have you tried 'slay io-pkt-v4 io-pkt-v4-hc' and then re-starting the
driver?
On 2013-01-29 10:38 AM, "Adam Barber" <community-noreply@qnx.com> wrote:
>I am running 6.5.0.
>
>My guess is that the driver is being loaded somewhere before I'm trying
>to, and I don't know where. I may be wrong about this also.
>
>I haven't tried devnp yet, as it doesn't seem to have a promiscuous
>option in the documentation.
>
>The weird thing is that after I try the devn command, en0 no longer
>appears under ifconfig, so somehow calling the driver command is doing
>something to remove my ability to see en0.
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post98864
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Adam Barber
|
Re: Getting an adaptor into promiscuous mode
|
|
Adam Barber
01/29/2013 11:16 AM
post98866
|
Re: Getting an adaptor into promiscuous mode
I hadn't, but I think that worked!
Thanks so much, I had tried to slay just io-pkt-v4, not -hc, and thats what I needed to slay.
I very much appreciate your help.
|
|
|
|
|
|
Hugh Brown
|
Re: Getting an adaptor into promiscuous mode
|
|
Hugh Brown
01/29/2013 11:17 AM
post98867
|
Re: Getting an adaptor into promiscuous mode
No problem.
On 2013-01-29 11:16 AM, "Adam Barber" <community-noreply@qnx.com> wrote:
>I hadn't, but I think that worked!
>
>Thanks so much, I had tried to slay just io-pkt-v4, not -hc, and thats
>what I needed to slay.
>
>I very much appreciate your help.
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post98866
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Adam Barber
|
Re: Getting an adaptor into promiscuous mode
|
|
Adam Barber
01/31/2013 9:22 PM
post98961
|
Re: Getting an adaptor into promiscuous mode
So even after doing this, I am unable to read packets in my program. I have UDP packets being sent to another device,
and then using port mirroring on my switch I have those ports also showing up on the QNX port. I know QNX can see them
because tcpdump shows them. In fact, tcpdump can read them whether I set the adaptor into promiscuous mode on my own or
not.
However, I can't figure out how to read them in my code. Everything I've found online that seems like it would offer a
solution in another linux/unix environment is not available in 6.5.
I got it to work somewhat with the pcap library, the problem here is that there is some sort of timing issue. On the
real receiver, I see that the packets are ~4ms apart as I expect, but using the pcap library (or tcpdump, which is based
on the pcap library) the packets are either ~8ms apart or 0ms apart. They average out to the same period between
packets but the timing is important for my application.
I've done another test, where I direct packets to my QNX machine with a 4ms period and I can read those using the
standard socket calls very easily and the timing is right. This leads me to believe there is something going on with the
pcap functions, and I'm hoping someone can help me figure out how to read packets promiscuously another way.
|
|
|
|
|
|
Sean Boudreau(deleted)
|
Re: Getting an adaptor into promiscuous mode
|
|
Sean Boudreau(deleted)
01/31/2013 9:26 PM
post98962
|
Re: Getting an adaptor into promiscuous mode
8.4 ms is the granularity of the timestamp in io-pkt. The packets
aren't actually received at that interval since everything is
interrupt driven.
On Thu, Jan 31, 2013 at 09:22:12PM -0500, Adam Barber wrote:
> So even after doing this, I am unable to read packets in my program. I have UDP packets being sent to another device,
and then using port mirroring on my switch I have those ports also showing up on the QNX port. I know QNX can see them
because tcpdump shows them. In fact, tcpdump can read them whether I set the adaptor into promiscuous mode on my own or
not.
>
> However, I can't figure out how to read them in my code. Everything I've found online that seems like it would offer a
solution in another linux/unix environment is not available in 6.5.
>
> I got it to work somewhat with the pcap library, the problem here is that there is some sort of timing issue. On the
real receiver, I see that the packets are ~4ms apart as I expect, but using the pcap library (or tcpdump, which is based
on the pcap library) the packets are either ~8ms apart or 0ms apart. They average out to the same period between
packets but the timing is important for my application.
>
> I've done another test, where I direct packets to my QNX machine with a 4ms period and I can read those using the
standard socket calls very easily and the timing is right. This leads me to believe there is something going on with the
pcap functions, and I'm hoping someone can help me figure out how to read packets promiscuously another way.
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98961
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Adam Barber
|
Re: Getting an adaptor into promiscuous mode
|
|
Adam Barber
01/31/2013 9:59 PM
post98965
|
Re: Getting an adaptor into promiscuous mode
So that makes sense, but then why was I able to read packets faster than that using "recvfrom"? I'm guessing because
maybe it isn't interrupt driven?
If that isn't interrupt driven, how can I use that function (or recv) to read packets promiscuously?
|
|
|
|
|
|
Sean Boudreau(deleted)
|
Re: Getting an adaptor into promiscuous mode
|
|
Sean Boudreau(deleted)
01/31/2013 10:17 PM
post98966
|
Re: Getting an adaptor into promiscuous mode
recvfrom isn't timer driven.
tcpdump is receiving them faster than that as well via bpf, they're
just timestamped at that granularity.
There's no linux PF_PACKET in QNX so you can't get all packets
via recvfrom, you have to use bpf / libpcap.
On Thu, Jan 31, 2013 at 09:59:43PM -0500, Adam Barber wrote:
> So that makes sense, but then why was I able to read packets faster than that using "recvfrom"? I'm guessing because
maybe it isn't interrupt driven?
>
> If that isn't interrupt driven, how can I use that function (or recv) to read packets promiscuously?
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98965
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
Adam Barber
|
Re: Getting an adaptor into promiscuous mode
|
|
Adam Barber
01/31/2013 10:41 PM
post98967
|
Re: Getting an adaptor into promiscuous mode
Alright, I'll have to look into bpf.
Thank you for the help, I'm fairly new to networking.
|
|
|
|
|
|
Adam Barber
|
Re: Getting an adaptor into promiscuous mode
|
|
Adam Barber
01/31/2013 11:44 PM
post98969
|
Re: Getting an adaptor into promiscuous mode
So instead of using the timestamp, I'm testing timing between calls of my callback function from pcap_loop using
CLOCK_REALTIME and getting strange results still. The shortest time between packets is 0 (which happens for many
packets), and then 0.019 ms (this makes sense as my tick size is set to be 20us). However, no packets are close to 4ms
apart (as I know they should be). There are also plenty of packets that are very far apart, as far as 1.5 seconds apart.
The average time between packets is close to 4ms so I think its a matter of when the function is being called. I've
also boosted the priority of this program so I'm not really sure what else I can do.
Have you seen behavior like this? Or have some idea about the kind of thing I may be missing?
It is nice to be reading these packets though!
|
|
|
|
|
|
