פרוייקט משובצות: 802.15.4 sniffer

מגישים: משה אדטו, רם ניימרק, מולי אמזלג.

תיאור הפרוייקט: Wireshark integrated Tmote Telos Sky sniffer through com bridge

מהלך העבודה:

הקמת סביבת עבודה של zigbee על גבי לוחות raven

מערכת הלוחות כוללת 2 לוחות raven אשר עובדים באופן עצמאי מסוללה או ספק כוח חיצוני. הלוחות מורכבים משני microcontrollers: אחד מהם אחראי על ניהול תצוגת ה lcd בעוד השני מריץ את האפליקציה וכן שולט בשבבים האחרים המצויים בלוח כגון שבב ה RF.

כמו כן, נכלל במערכת גם usbstick המתחבר ל PC ומשמש כ coordinator למערכת התקשורת האלחוטית.

מטרתנו בהקמת סביבת העבודה הייתה להריץ אפליקציה על הלוחות שתשלח הודעות מבוקרות בפרוטוקול זיגבי. התלבטנו בין מספר סביבות ומערכות אותן ניתן להתקין על הלוחות ובחרנו בסביבה שנקראת BitCloud שהיא SDK של חברת Atmel המתאים למערכת ה raven.

סביבה זו מספקת אפליקציה לדוגמא בשם WSNDemo המאפשרת בניית רשת zigbee המורכבת מ usbstick בתור coordinator: שורש העץ של הרשת ולוחות ה raven בתור end point devices: עלים בעץ הרשת או router: צמתים פנימיים בעץ הרשת. במהלך האפליקציה end point devices (שבהם נכללים גם ה routers) שולחים הודעות למתאם הרשת המספקות מידע על הקלט של החישנים של הלוח וכן מידע כללי עליהן והרשת (ב data של ההודעות). בנוסף, מסופקת יחד עם האפליקציה אפליקציה ל PC שיודעת לתקשר עם ה usbstick המחובר ולהציג את מבנה הרשת וכן את המידע הנשלח ע"י כל אחד מהלוחות. שינינו את המידע הנשלח מהחיישנים על מנת להקל על המעקב שלנו אחר ההודעות כך שישלח incremental data אחריו נוכל לעקוב בסניפר (הסבר מפורט ותצוגה בהמשך).

את התכנית קימפלנו באמצעות סביבת העבודה הייעודית של המערכת AVR Studio 4.

מהלך העבודה

לאחר קומפילציה של הקוד (הקוד הכתוב והמקומפל מצורפים) צרבנו הן את שני המיקרו מעבדים של כל אחד מלוחות ה raven והן את ה usbstick באמצעות AVR dragon.

כפי שציינו, את הקוד של התכנית עצמה שינינו כך שנוכל לראות באפליקציה שינוי הדרגתי קבוע במידע הנשלח מהחישנים והסוללה, את הקוד של המיקרו מעבד השולט על ה LCD השארנו כפי שהוא וכך גם את הקוד של ה usbstick.

את הצריבות להתקנים ביצענו באמצעות AVR Dragon לחיבורי ה JTAG של המעבדים.

תאור מהלך הצריבה:

חיבור AVR Dragon לחיבורי ה JTAG של המיקרו מעבד הנדרש לתכנות דרך מתאם המרת הפינים המגיע עם הערכה וחיבור ה dragon ל PC.

התחברות להתקן ב AVR Studio (עבדנו עם גרסא 4)

בחירת הפלטפורמה: AVR Dragon, דרך פורט USB

בחירת ההתקן אותו בכוונתנו לצרוב מתוך רשימת ההתקנים של Atmel

לוח raven: מעבד ראשי ATmega1284P, מעבד lcd: ATmega3290P

USBStick: AT90USB1287

צריבת fuses על פי המתכון המופיע במסמך המערכת (מצורף), ייחודי לכל התקן שנצרב.

בחירת הקובץ הבינארי לצרוב (.hex) וצריבתו:

הקמת סביבת עבודה לtmote כתיבת הקוד של הsniffer והעלאתו למכשיר

יש מספר שיטות, אפרט את זו שנקטתי בה:

· הועלתה המערכת על פי-http://www.contiki-os.org/start.html- בעצם מערכת ubuntu וירטואלית שמכילה כבר את הספריות של contiki (דרוש vmware player).

נכתב הקוד בהתאם לתיכון הבא:

תצורת הרשת של Contiki בנויה ממספר שכבות אבסטרקציה של רשת שכל אחת ברת החלפה והמידע זורם דרכן:

שכבת הרדיו- (ברירת מחדל)- cc2420_driver

שכבת הrdc-(ברירת מחדל)- contikimac_driver

שכבת הmac- (ברירת מחדל)- csma_driver

כאשר ה rime (http://contiki.sourceforge.net/docs/2.6/a01798.html) הוא שמקבל את ההתראה על פקטה מוכנה בבאפרים (נכנסים או יוצאים) וגורם לשרשרת של callback.

המימוש שלנו מחליף את שכבת הRdc (https://github.com/contiki-os/contiki/wiki/Change-mac-or-radio-duty-cycling-protocols) שתפקידה להעלות את המידע אל ומהmac (הייעוד הראשי שלה הוא לחסוך בהספק- Radio Duty Cycling (RDC)), כאשר אנו מדפיסים את תוכן הפקטה למסך על פי רצון המשתמש (כרגע יש אפשרות debug שגם מפרססת חלק מהפקטות וגם מציגה בhex את המידע ויש אפשרות raw שפשוט מדפיסה את הבתים כמות שהם למסך- להעברתו לwireshark- ראה בהמשך).

הגרסא הועלתה למכשיר על ידי הפקודה:

Sudo make TARGET=sky Rdc_imp.upload

פיתוח ממשק לתיאום בין com לבין הwireshark

מכשיר הcontiki המסניף את תעבורת מכשירי הTelos sky מחובר למחשב דרך USB (המיקרו-פרוססור משדר דרך הuart אך המידע יוצא דרך הusb).

רצינו לממש interface (bridge) שיקשר בין המידע המגיע דרך הUSB לwireshark, למימוש bridge זה ישנם מס' שיטות בולטות:

1) שימוש ב Tunslip Interface , תוכנה זו מאפשרת לTmote sky המחובר דרך הUSB פורט להזדהות ככרטיס רשת ובכך מידע הזורם דרכו יקלט ע"י תוכנת wireshark.

לשיטה זו מספר חסרונות:

1) כדי לממש שיטה זו יש להקים שרת UDP על הContiki, כך שכל חבילת zigbee המוסנפת

Encapsulate בתוך חבילת udp.

בכמסה זו הינה חובה- ולא ניתן לשדר את החבילה כמו שהיא מכיוון שהחבילה המגיעה לwireshark חייבת להיות בעלת full wifi- etherenet stack.

בשלב השני יש להגדיר ב wireshark תמיכה בencapsulate ובפרוטוקלי zeegbe כמו שצויין.

לשיטה זו מספר חסרונות שגרמו לנו לא לבחור בה:

1) הקמת שרת udp על הcontiki צורכת משאבים די גדולים מהמעבד, דבר שעלול לפגוע במהות האפליקציה המסתמכת על הסנפת חבילות הzeegbe בזמן אמת.

2) בנוסף לכל חבילת zeegbe המוסנפת מכיוון שאנו משתמשים במנגנון ההכמסה יש להוסיף בתחילת החבילה header המציין פרטים בנוגע לאופי החבילה המוכמסת בתוך חבילת ה udp.

2) WSbridge: השיטה בה השתמשנו נעזרת ביכולת של wireshark להגדיר קובץ במחשב בתור interface ובשיטה של pipe הwireshark יוזן מהdata הנכתב לקובץ.

בנינו תוכנה הנקראת wsbridge , תוכנה זו יוצרת קובץ pipe זה, מגדירה את הפרמטרים הדרושים לצורך כך שwireshark יזהה את הקובץ כinterface חוקי (global header).

כמו כן התוכנה מזהה data היוצא על הusb, מנתחת אותו ומבצעת defragmentation לצורך איחוד הdata לחבילות zeegbe חוקיות, וכותב את החבילות בצירוף הheader הנדרש לקובץ הpipe.

לציין שתוכנה זו רצה על המחשב ואינה על מכשיר הcontiki מה ששומר על יעילות ההסנפה,ואמינות המידע .

הוראות הפעלה

בהנחה שהtmote לא צרוב יש להעלות את סביבת העבודה (ראה הקמת סביבת עבודה לtmote).

יש לאתחל את הsniffer:

Sudo make TARGET=sky login

נרסט את הboard

יופיע cli:

"Sniffer cli

type num: 1- start 0-stop 2-wireshark mode 3-debug mode 4- set channel 5-exit "

מכיוון שהקוד הותאם לrf channel של הraven ונועד כברירת מחדל לעבוד מול הwireshark לחיצה על 1 וenter תתחיל את ההסנפה (ניתן לראות את הבתים מודפסים למסך).

כעת נלחץ על ctrl+c בכדי לשחרר את הcom port על מנת שהbridge יוכל לקרוא אותו.

נעלה את הbridge:

Sudo ./wsbridge <com port> (typically /dev/ttyUSB0).

כעת הbridge ממתין להעלאת הwireshark והגדרת הpipe:

"Serial port connected. Waiting for wireshark connection

Open wireshark and connect to local interface:
 

נעלה את הwireshark המקומי.

נקנפג את הpipe:

נאפשר את הפרוטקול המתאים:

נבחר ב802.15.4 וגם נוסיף פרוטוקולי zigbee

נתחיל בהסנפה- ניתן לראות את הפקטות בצורת raw על הterminal של הwsbridge וכעת הפקטות יתחילו להופיע בwireshark.

הדגמת פעולת ה sniffer

את הדגמת פעולת ה snifferביצענו ע"י הרצת האפליקציה לדוגמא שתוארה על מערכת לוחות ה raven.

נציג את פעולת האפליקציה באמצעות ה GUI המסופק עם אפליקציית הדוגמא וכן נראה את הפקטות שהוסנפו ע"י צד שלישי.

ניסיון התחברות End Device (ללא Coordinator):

נפעיל את הסניפר ולאחריו נחבר את ה end device.

נוכל לראות את הכיתוב JOINING על צג ה lcd תוך הבהוב הלד האדום וכן אייקון זיג בי ואייקון שידור המעידים על שידור.

נוכל לראות את ההתקן שולח הודעות beacon request של פרוטוקול 802.15.4 ליעד broadcast

התחברות ותקשורת endDevice ו Coordinator

ראשית, נסתכל על המצב ההתחלתי בו מחובר ה coordinator בלבד:

נוכל לראות ב WSN Monitor את מבנה הרשת והפרטים של הצומת:

נסתכל על המידע הנשלח:

ניתן לראות הודעות link status הנשלחות כל כ 15 שניות.

הודעות link status הן חלק משכבת ה network של פרוטוקול זיגבי. הן מעבירות מידע בין נתבים בפרוטוקול המודיע על מצב הרשת כפי שרואה אותה הנתב.

ניתן לראות שערך ה link status הוא 0 משום שזהו הצומת היחיד ברשת.

כעת, נחבר התקן קצה (end device) אחד לרשת.

עם הפעלת הלוח הוא ינסה להתחבר עם כיתוב JOINING כפי שראינו לפני כן, לאחר שיזהה את הרשת יתחבר ויכתוב על המסך ENDDEVICE.

התקן הקצה ישדר הודעה הכוללת את הנתונים שלו כפי שהגדרנו אותם יחד עם נתונים שונים נוספים על הרשת פעם בשנייה בערך. עם השידור תדלק מנורת הלד האדומה וכן אייקון השידור יפעל. בשאר הזמן הלוח יהיה במצב שינה ונוכל לראות כי אייקון השידור אינו פעיל ואייקון השינה דולק.

עם ההתחברות, נוכל לראות את מבנה הרשת משתנה עם תוספת של התקן קצה המחובר ל coordinator.

נסתכל על ההודעות העוברות:

ניתן לראות הודעת beacon request הנשלחת עם הפעלת התקן הקצה (כפי שאינו שנשלח) ומיד לאחריה מענה beacon ששולח ה coordinator.

ניתן לשלוח כי PANId(0x0CF9) וכן מספר ההתקן (0x0000) הנשלחים חזרה מתאימים לאלו שראינו במוניטור.

לאחר מכן ניתן לראות הודעת rejoin request: הודעת בקשת התחברות לרשת ובעקבותיה rejoin response עם סטטוס הצלחה:

ניתן לראות כי הכתובות מתאימות לכתובות שראינו במוניטור.

בין הודעות הפרוטוקול זיגבי מופיעות הודעות פרוטוקול 802.15.4. ניתן לראות הודעות ack ו data request. מעתה והלאה נסנן הודעות אלה ונתעלם מהן.

לאחר ההתחברות נראה כי ההתקן שהתחבר שולח הודעת device announcement זוהי הודעה אותה שולח התקן שהתחבר לרשת בה הוא מודיע על התחברותו ועל 64 ביט כתובת ה IEEE שלו ו 16 ביט של כתובת הרשת שלו.

ניתן לראות כי הכתובות מתאימות לכתובות שראינו במוניטור.

לאחר מכן, מופיעה סדרה ארוכה של הודעות data, ack ו link status.

נסתכל על הודעת data:

נסתכל ראשית על ה header של שכבת הרשת זיגבי.

הוא כולל את כתובת ההודעה: 0x0000, זהו מתאם הרשת שלנו.

כתובת המקור: 0x3325, תואם את הכתובת במוניטור.

רדיוס: המרחק בקפיצות שמותר למסגרת לעבור ברשת.

וכן מספר סידורי של ההודעה.

בנוסף, נכללת כתובת IEEE המורחבת של המקור.

כעת, נסתכל על ה header של שכבת היישום של זיגבי:

ראשית, frame control field כולל את סוג ההודעה: data, סוג ההעברה: unicast, אבטחה: כבויה, בקשת ack: מופעלת.

Destination/ source endpoint: כתובת יעד הקצה אליו מיועדת ההודעה, במקרה שלנו 1.

Cluster: ה cluster אליו מיועדת ההודעה, בדומה לפרופיל אמורים לסייע בפענוח ההודעה.

Data:

מבנה ההודעה אותה שולחת האפליקציה הוא כדלקמן (מבוסס על מבנה ההודעה המתואר בסמך של bitcloud המתאר את האפליקציה לדוגמא):

· ערך בהודעה מופיע ב little endian (עבור כל שדה בנפרד) בהודעה עצמה.

תאור השדה	גודל בבתים	תאור	ערך בהודעה
סוג הודעה	1	סוג ההודעה- חייב להיות 0x01	0x01
סוג הצומת	1	0-coordinator 1-router 2-end device	0x02
כתובת IEEE מקור	8		000425ffff17c670
כתובת קצרה מקור	2		0x3325
גרסת האפליקציה	4	אמורה להיות 0x01010100	0x01010100
מסכת הערוץ	4	מסכת ערוץ השליחה	0x00008000
PAN ID	2		0x0cf9
ערוץ השליחה	1		0x0f
כתובת הורה	2	כתובת הורה בעת הרשת	0x0000
LQI	1	LQI אותו מזהה הצומת השולח LQI הוא link quality indicator הנמצא בשימוש ברשתות זיגבי ומייצג את איכות השידור עפ"י חוזק הסיגנל שהתקבל ומספר השגיאות	0xf2
RSSI	1	Received signal strength indication	0xc1
סוג שדה נוסף	1	1: מידע חישנים 2: שם צומת	0x01
גודל שדות נוספים	1		0x0c
שדה נוסף 1	4	מייצג את חיישן האור	0x16
שדה נוסף 2	4	מייצג את חיישן הטמפרטורה	0x02
שדה נוסף 3	4	מייצג את חוזק הסוללה	0x2ee0

בשדות הנוספים, במקום לשלוח את המידע המגיע מהחיישנים שינינו את הקוד כך שישלח מידע אינקרמנטלי עליו נוכל לעקוב בקלות הן במוניטור והן בהודעות.

עבור מצב הסוללה נוכל לראות במוניטור (כפי שמופיע בתמונה הנ"ל) את המידע עולה מ 10 ל 15 וחוזר חלילה. נשים לב שהמידע הנשלח אינו חח"ע עם המידע המופיע במוניטור (עבור הסוללה בלבד) התאמנו באפליקציה את המידע כך שיתאים לערכים הנ"ל.

עבור חיישן האור המידע יעל מ 20 עד 25 ויחזור חלילה, ניתן לזהות ערך זה בהודעה שנשלחה.

עבור חיישן הטמפרטורה ניתן לזהות עליות בין 0 ל 5 וחוזר חלילה.

הודעה עוקבת לנ"ל:

ניתן לראות כי הערך המייצג את חישן האור עלה מ 0x16 ל 0x17.

הערך המייצג את חיישן הטמפרטורה עלה מ 2 ל 3.

הערך המייצג את הסוללה עלה מ 0x2ee0 ל 0x32c8 (הפרש של 1000 בין כל יחידה במוניטור).

תמונות המייצגות את המוניטור עבור הטמפרטורה והאור: