Skip to content

Commit 2a0015c

Browse files
WraithWirelessWraithWireless
authored andcommitted
v0.1.6 updated readme
1 parent 4d9403e commit 2a0015c

File tree

2 files changed

+125
-12
lines changed

2 files changed

+125
-12
lines changed

README.md

Lines changed: 124 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -539,24 +539,134 @@ def pymon(card, start=True, ch=None):
539539
if pyw.modeget(card) == 'monitor':
540540
raise RuntimeError("Card is already in monitor mode")
541541
newcard = pyw.devset(card, card.dev + 'mon')
542-
pyw.modeset(newcard, 'monitor')
543-
if ch: pyw.chset(w1, ch, None)
542+
pyw.modeset(newcard, 'monitor')
544543
pyw.up(newcard)
544+
if ch: pyw.chset(w1, ch, None)
545545
else:
546546
if pyw.modeget(card) == 'managed':
547547
raise RuntimeError("Card is not in monitor mode")
548-
newcard = pyw.devset(card, card.dev[:-3)
548+
newcard = pyw.devset(card, card.dev[:-3])
549549
pyw.modeset(newcard, 'managed')
550550
pyw.up(newcard)
551551
return newcard
552552
```
553553

554-
NOTE: After a recent kernel upgrade (see my post at
555-
https://wraithwireless.wordpress.com/2016/07/24/linux-kernel-bug/ for more details)
556-
devadd became unusable. ATT, I have "fixed" devadd. Basically the original used
557-
the physical index (iw phy <phy> interface add ...). Now, it uses the ifindex.
558-
The function phyadd which only accepts the physical index (phy) is now implemented
559-
to allow users whose systems start with any devs.
554+
##### o Virtual Interfaces and Issues in Kernel 4.x
555+
After recently upgrading my distro, my kernel was upgraded from 3.x to 4.x. I
556+
noticed that in some situations, adding a virtual interface (VIF) did not have
557+
the desired effect. Namely, new VIFs did not have the dev name I had specified.
558+
Furthermore, regardless of the naming convention I was currently using (old
559+
school like wlan0, eth0 etc or the newer predictable names i.e. wlp3s0) the
560+
new VIF would have a predictable name and the MAC address would be one up from
561+
that of the actual cards MAC address. For more details, check out my blog
562+
at https://wraithwireless.wordpress.com/2016/07/24/linux-kernel-bug/. This is
563+
an issue at the kernel and nl80211 level and not a PyRIC bug.
564+
565+
This situtation will only occur if you are attempting to (a) create a VIF with
566+
the same dev name as the original, (b) in managed mode and (c) there are currently
567+
other VIFs sharing the same phy.
568+
569+
```python
570+
>>> pyw.winterfaces()
571+
['alfa0']
572+
>>> card = pyw.getcard('alfa0')
573+
>>> card
574+
Card(phy=1,dev=alfa0,ifindex=5)
575+
>>> mcard
576+
Card(phy=1,dev=mon0,ifindex=6)
577+
>>> pyw.devdel(card)
578+
>>> pyw.winterfaces()
579+
['mon0']
580+
>>> pyw.devadd(mcard,'alfa0','managed')
581+
Card(phy=1,dev=alfa0,ifindex=7)
582+
>>> pyw.winterfaces()
583+
['mon0', 'wlx00c0ca59afa7']
584+
>>> pyw.devdel(pyw.getcard('wlx00c0ca59afa7'))
585+
>>> pyw.winterfaces()
586+
['wlan0mon', 'mon0']
587+
>>> pyw.phyadd(mcard,'alfa0','managed')
588+
Card(phy=1,dev=alfa0,ifindex=8)
589+
>>> pyw.winterfaces()
590+
['wlan0mon', 'mon0', 'wlx00c0ca59afa7']
591+
```
592+
593+
All three of the above most be True for this to occur. So, for example:
594+
595+
```python
596+
>>> pyw.winterfaces()
597+
['mon0']
598+
>>> pyw.devadd(mcard,'alfa0','monitor')
599+
Card(phy=1,dev=alfa0,ifindex=10)
600+
>>> pyw.winterfaces()
601+
['mon0', 'alfa0']
602+
```
603+
604+
works because case (b) is false.
605+
606+
Some things to note:
607+
* it does not matter if you are using devadd (creating a VIF via the ifindex) or
608+
phyadd (creating a VIF via the physical index)
609+
* nl80211 believes that new VIF has the name you specified so I believe this is
610+
something related to the kernel itself or possibly udev. If you look at the source
611+
code for phyadd or devadd, the returned card uses the indicators returned by the
612+
kernel.
613+
614+
I had considered several options of rectifying this for PyRIC but, doing so would
615+
require either mutliple checks on kernel version or breaking backward compatibility
616+
for users with kernel 3.x and possibly breaking forward compatibility (if this
617+
issue does get fixed at some future kernel version). Besides, being aware of
618+
the state that must be true for this to happen, users can easily workaround it.
619+
620+
One way, as we saw earlier, is to create a VIF in monitor mode and then set it
621+
to managed.
622+
623+
```python
624+
>>> pyw.winterfaces()
625+
['mon0']
626+
>>> pyw.devadd(mcard,'alfa0','monitor')
627+
Card(phy=1,dev=alfa0,ifindex=10)
628+
>>> pyw.winterfaces()
629+
['mon0', 'alfa0']
630+
>>> pyw.devdel(pyw.getcard('mon0'))
631+
>>> card = pyw.getcard('alfa0')
632+
>>> pyw.down(card)
633+
>>> pyw.modeset(card,'managed')
634+
>>> pyw.up
635+
<function up at 0x7f76339c99b0>
636+
>>> pyw.up()
637+
Traceback (most recent call last):
638+
File "<stdin>", line 1, in <module>
639+
TypeError: up() takes at least 1 argument (0 given)
640+
>>> pyw.up(card)
641+
>>> pyw.winterfaces()
642+
['wlan0mon', 'alfa0']
643+
>>> pyw.devinfo(card)
644+
{'wdev': 4294967302, 'RF': None, 'CF': None, 'mac': '00:c0:ca:59:af:a6',
645+
'mode': 'managed', 'CHW': None, 'card': Card(phy=1,dev=alfa0,ifindex=10)}
646+
```
647+
648+
But, I think this is sloppy. The better way is to use phyadd. Recall that
649+
phyadd accepts either a Card or the phy and that even though a card is deleted,
650+
some of its reference values are still valid. In the case of deleting a card,
651+
the phy is still present. So, you could use a phy or a Card that was previously
652+
deleted because the phy is still valid.
653+
654+
```python
655+
>>> pyw.winterfaces()
656+
['mon0']
657+
>>> phy = mcard.phy
658+
>>> pyw.devdel(mcard)
659+
>>> pyw.winterfaces()
660+
[]
661+
>>> card = pyw.phyadd(phy,'alfa0','managed')
662+
>>> card
663+
Card(phy=1,dev=alfa0,ifindex=12)
664+
>>> pyw.winterfaces()
665+
['alfa0']
666+
```
667+
668+
This works, but remember you have to delete all interfaces with the same phy
669+
as the one you are creating before creating it.
560670

561671
#### vi. STA Related Functions
562672
I have recently begun adding STA functionality to PyRIC. These are not necessarily
@@ -707,12 +817,13 @@ with (-) are not included in pip installs or PyPI downloads
707817
- \_\_init\_\_.py initialize distrubution PyRIC module
708818
- examples example folder
709819
+ pentest.py create wireless pentest environment example
710-
+ device_details.py display device information
820+
+ info.py display device information
711821
- tests (-) test folder
712822
+ pyw.unittest.py unit test for pyw functions
713823
- docs User Guide resources
714824
+ nlsend.png (-) image for user guide
715825
+ nlsock.png (-) image for user guide
826+
+ logo.png (-) pyric logo
716827
+ PyRIC.tex (-) User tex file
717828
+ PyRIC.bib (-) User Guide bibliography
718829
+ PyRIC.pdf User Guide
@@ -721,6 +832,7 @@ with (-) are not included in pip installs or PyPI downloads
721832
- MANIFEST.in used by setup.py
722833
- README.md this file
723834
- LICENSE GPLv3 License
835+
- CHANGES revision file
724836
- TODO todos for PyRIC
725837
- pyric package directory
726838
+ \_\_init\_\_.py initialize pyric module
@@ -745,12 +857,13 @@ with (-) are not included in pip installs or PyPI downloads
745857
- nl80211_h.py nl80211 constants
746858
- nl80211_c.py nl80211 attribute policies
747859
- rfkill_h.py rfkill header file
748-
- ieee80211_h.py ieee80211.h port (subset of)
860+
- wlan.py ieee80211.h port (subset of)
749861
+ lib library subpackages
750862
* \_\_init\_\_.py initialize lib subpackage
751863
* libnl.py netlink helper functions
752864
* libio.py sockios helper functions
753865
+ nlhelp netlinke documentation/help
866+
* \_\_init\_\_.py initialize nlhelp subpackage
754867
* nsearch.py nl80211 search
755868
* commands.help nl80211 commands help data
756869
* attributes.help nl80211 attributes help data

pyric/net/wireless/wlan.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@
1919
contributors may be used to endorse or promote products derived from this
2020
software without specific prior written permission.
2121
22-
Definition of constants et all found in IEEE Std 802.11-2012
22+
Definition of constants et al found in IEEE Std 802.11-2012
2323
2424
Std will refer to IEEE Std 802.11-2012
2525

0 commit comments

Comments
 (0)