דף זה תורגם על ידי Cloud Translation API.

בניית רשת בפרוטוקול Thread עם לוחות nRF52840 ו-OpenThread

1. מבוא

פלטפורמת OpenThread של Google היא הטמעת קוד פתוח של פרוטוקול הרשת Thread®. במסגרת Google Nest הושקה OpenThread כדי שהטכנולוגיה שמשמשת את מוצרי Nest תהיה זמינה באופן נרחב למפתחים, כדי לזרז את הפיתוח של מוצרים לבית המחובר.

מפרט פרוטוקול Thread מגדיר פרוטוקול תקשורת אלחוטי, אמין ומבוסס-IPv6, עבור אפליקציות ביתיות. OpenThread מיישמת את כל שכבות הרשת של פרוטוקול Thread, כולל IPv6, 6LoWPAN, IEEE 802.15.4 עם אבטחת MAC, הגדרות קישור רשת וניתוב רשת.

ב-Codelab הזה אפשר לתכנת OpenThread בחומרה אמיתית, ליצור ולנהל רשת בפרוטוקול Thread ולהעביר הודעות בין צמתים.

מה תלמדו

פיתוח קבצים בינאריים של OpenThread CLI ופלאשים ללוחות פיתוח
פיתוח RCP שמורכב ממכונת Linux ולוח פיתוח
תקשורת עם RCP באמצעות OpenThread Daemon ו-ot-ctl
ניהול ידני של צמתים של פרוטוקולי Thread באמצעות מסך GNU ו-CLI של OpenThread
הזמנת מכשירים מאובטחת ברשת בפרוטוקול Thread
איך עובד Multicast של IPv6
העברת הודעות בין צומתי Thread באמצעות UDP

למה תזדקק?

חומרה:

3 לוחות פיתוח nRF52840 של מוליכים למחצה נורדיים
3 כבלי USB למיקרו USB כדי לחבר את הלוחות
מחשב Linux עם 3 יציאות USB לפחות

תוכנה:

שרשרת הכלים של GNU
כלי שורת הפקודה nRF5x נורדיים
תוכנת Segger J-Link
OpenThread
Git

2. תחילת העבודה

סימולציית OpenThread

לפני שמתחילים, כדאי להריץ את OpenThread Simulation Codelab כדי להכיר את העקרונות הבסיסיים של פרוטוקול Thread ואת ה-CLI של OpenThread.

מסופים של יציאות טוריות

חשוב לדעת איך להתחבר ליציאה טורית באמצעות מסוף. ה-Codelab הזה משתמש ב-GNU Screen ומספק סקירה כללית על השימוש, אבל אפשר להשתמש בכל תוכנת מסוף אחרת.

מחשב Linux

ה-Codelab הזה נועד להשתמש במחשב Linux מבוסס-i386 או x86 כדי לשמש כמארח של מכשיר Thread במעבד משותף (RCP) וכדי להבהב את כל לוחות הפיתוח של פרוטוקול Thread. כל השלבים נבדקו ב-Ubuntu 14.04.5 LTS (Trusty Tahr).

לוחות nRF52840 של מוליכים למחצה נורדיים

ב-Codelab הזה נעשה שימוש בשלושה לוחות nRF52840 PDK.

להתקנת SEGGER J-Link

אנחנו משתמשים ב-SEGGER J-Link כדי לתכנת את הלוחות nRF52840, שכוללים מודולים של JTAG. מתקינים אותה במחשב Linux.

מורידים את החבילה המתאימה למחשב ומתקינים אותה במיקום הנכון. ב-Linux, זה /opt/SEGGER/JLink.

התקנת כלי שורת הפקודה nRF5x

כלי שורת הפקודה nRF5x מאפשרים לעדכן את הקבצים הבינאריים של OpenThread ללוחות nRF52840. מתקינים את קובץ ה-nRF5x-Command-Line-Tools-<OS> המתאים. מבוססות על מכונת Linux שלכם.

מעבירים את החבילה שחולץ בתיקיית הבסיס ~/.

התקנת ARM GNU Toolchain

'צרור הכלים של ARM GNU' משמש לבנייה.

מומלץ למקם את הארכיון שחולץ ב-/opt/gnu-mcu-eclipse/arm-none-eabi-gcc/ במחשב Linux שלך. יש לפעול לפי ההוראות בקובץ readme.txt שבארכיון לקבלת הוראות התקנה.

התקנת מסך (אופציונלי)

המסך הוא כלי פשוט לגישה למכשירים שמחוברים באמצעות יציאה טורית. ב-Codelab הזה נעשה שימוש ב-Screen, אבל אפשר להשתמש בכל אפליקציית מסוף של יציאה טורית.

$ sudo apt-get install screen

3. שכפולים מאגרים

OpenThread

משכפלים ומתקינים את OpenThread. הפקודות script/bootstrap מוודאות שה-toolchain מותקן והסביבה מוגדרת כמו שצריך:

$ mkdir -p ~/src
$ cd ~/src
$ git clone --recursive https://github.com/openthread/openthread.git
$ cd openthread
$ ./script/bootstrap

בניית OpenThread Daemon:

$ script/cmake-build posix -DOT_DAEMON=ON

עכשיו אתם מוכנים לפתח את OpenThread ולעדכן אותו בלוחות מסוג nRF52840.

4. הגדרת ההצטרפות ל-RCP

יצירה ו-Flash

בונים את הדוגמה של OpenThread nRF52840 באמצעות Joiner ופונקציונליות USB מובנית. מכשיר משתמש בתפקיד 'הצטרפות' כדי לעבור אימות מאובטח ולהזמין אותו לרשת בפרוטוקול Thread. נייטיב USB מאפשר להשתמש ב-USB CDC ACM בתור העברה טורית בין ה-nRF52840 למארח.

תמיד צריך לנקות את המאגר של גרסאות build קודמות על ידי הרצה של rm -rf build.

$ cd ~/src
$ git clone --recursive https://github.com/openthread/ot-nrf528xx.git
$ cd ot-nrf528xx
$ script/build nrf52840 USB_trans

מנווטים לספרייה עם הקובץ הבינארי של OpenThread RCP וממירים אותו לפורמט הקסדצימלי (hex):

$ cd ~/src/ot-nrf528xx/build/bin
$ arm-none-eabi-objcopy -O ihex ot-rcp ot-rcp.hex

מחברים את כבל ה-USB ליציאת ניפוי הבאגים של מיקרו-USB ליד פין החשמל החיצוני בלוח nRF52840, ולאחר מכן מחברים אותו למחשב Linux. מגדירים את המתג מקור החשמל nRF בלוח nRF52840 לערך VDD. כשמחברים את המכשיר בצורה נכונה, LED5 פועלת.

אם זה הלוח הראשון שמחובר למחשב Linux, הוא מופיע כיציאה טורית /dev/ttyACM0 (כל לוחות nRF52840 משתמשים ב-ttyACM כמזהה היציאה הטורית).

$ ls /dev/ttyACM*
/dev/ttyACM0

שימו לב למספר הסידורי של הלוח nRF52840 שנעשה בו שימוש ב-RCP:

מנווטים למיקום של כלי שורת הפקודה nRFx ומריצים את קובץ ה-hex ההקסדצימלי של OpenThread RCP ללוח nRF52840 באמצעות המספר הסידורי של הלוח. לתשומת ליבכם: אם לא משמיטים את הדגל --verify, מוצגת הודעת אזהרה שלפיה תהליך ה-Flash עלול להיכשל ללא שגיאות.

$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924  --verify --chiperase --program \
       ~/src/ot-nrf528xx/build/bin/ot-rcp.hex --reset

הפלט הבא נוצר בעקבות הצלחה:

Parsing hex file.
Erasing user available code and UICR flash areas.
Applying system reset.
Checking that the area to write is not protected.
Programing device.
Applying system reset.
Run.

הוספת התווית 'RCP' ללוח כדי שיהיה אפשר להתבלבל בין התפקידים השונים של הלוח.

חיבור ל-USB מקורי

מאחר שגרסת ה-build של OpenThread RCP מאפשרת להשתמש ב-ACM ב-USB CDC מקורי כהעברה טורית, צריך להשתמש ביציאת nRF USB בלוח nRF52840 כדי לתקשר עם מארח ה-RCP (מכונת Linux).

מנתקים את הקצה של המיקרו-USB של כבל ה-USB מיציאת ניפוי הבאגים של לוח nRF52840 המהבהב. לאחר מכן מחברים אותו מחדש ליציאת ה-nRF USB של מיקרו-USB לצד הלחצן איפוס. מעבירים את המתג של מקור החשמל nRF למצב USB.

הפעלת OpenThread Daemon

בתכנון RCP, משתמשים ב-OpenThread Daemon כדי לתקשר עם מכשיר פרוטוקול Thread ולנהל אותו. מתחילים את ot-daemon עם הדגל הדרגתי של -v כדי לראות את פלט היומן ולאשר שהוא פועל:

$ cd ~/src/openthread
$ sudo ./build/posix/src/posix/ot-daemon -v \
    'spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=115200'

לאחר השלמת הפעולה, הפקודה ot-daemon במצב דרגת מלל יוצרת פלט שדומה לזה:

ot-daemon[12463]: Running OPENTHREAD/thread-reference-20200818-1938-g0f10480ed; POSIX; Aug 30 2022 10:55:05
ot-daemon[12463]: Thread version: 4
ot-daemon[12463]: Thread interface: wpan0
ot-daemon[12463]: RCP version: OPENTHREAD/thread-reference-20200818-1938-g0f10480ed; SIMULATION; Aug 30 2022 10:54:10

צריך להשאיר את חלון הטרמינל פתוח כדי שיהיה אפשר לצפות ביומנים מ-ot-daemon.

אפשר להשתמש ב-ot-ctl כדי לתקשר עם צומת ה-RCP. ה-CLI של ot-ctl זהה לזה של אפליקציית OpenThread CLI. לכן אפשר לשלוט בצמתים של ot-daemon באותו אופן כמו שאר מכשירי פרוטוקול Thread.

בחלון טרמינל שני, מפעילים את ot-ctl:

$ sudo ./build/posix/src/posix/ot-ctl
>

צריך לבדוק את state של צומת 2 (צומת ה-RCP) שהתחלת עם ot-daemon:

> state
disabled
Done

5. הגדרת תשלומי FTD

שני צומתי Thread האחרים שנמצאים בשימוש ב-Codelab הזה הם מכשירי Thread מלא (FTD) בעיצוב הסטנדרטי של מערכת על שבב (SoC). בסביבת ייצור, אפשר להשתמש ב-wpantund, מנהל התקן של ממשק רשת ברמת הייצור, כדי לשלוט במכונות NCP של OpenThread, אבל ב-Codelab הזה נשתמש ב-ot-ctl, ה-CLI של OpenThread.

מכשיר אחד משמש כנציבות לצורך אימות מאובטח של מכשירים והזמנתם ברשת הזו. המכשיר השני פועל כ-joiner שהנציב יכול לאמת מול רשת פרוטוקול Thread.

יצירה ו-Flash

יוצרים את דוגמה ל-OpenThread FTD בפלטפורמה nRF52840, כשהתפקידים 'נציב' ו-'הצטרפות' מופעלים:

$ cd ~/src/ot-nrf528xx
$ rm -rf build
$ script/build nrf52840 USB_trans -DOT_JOINER=ON -DOT_COMMISSIONER=ON

מנווטים לספרייה עם הבינארי של ה-CLI של OpenThread Full Thread ( FTD) וממירים אותו לפורמט הקסדצימלי (hex):

$ cd ~/src/ot-nrf528xx/build/bin
$ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex

מחברים את כבל ה-USB ליציאת המיקרו-USB ליד פיכת החשמל החיצונית בלוח nRF52840, ולאחר מכן מחברים אותו למחשב Linux. אם ה-RCP עדיין מחובר למחשב Linux, הלוח החדש צריך להופיע כיציאה טורית /dev/ttyACM1 (כל לוחות nRF52840 משתמשים ב-ttyACM כמזהה היציאה הטורית).

$ ls /dev/ttyACM*
/dev/ttyACM0  /dev/ttyACM1

כמו קודם, חשוב לשים לב למספר הסידורי של הלוח nRF52840 שנעשה בו שימוש ב-FTD:

מנווטים למיקום של כלי שורת הפקודה nRFx ומוציאים את קובץ ההקסדצימלי של OpenThread CLI FTD על לוח nRF52840 באמצעות המספר הסידורי של הלוח:

$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
       ~/src/ot-nrf528xx/build/bin/ot-cli-ftd.hex --reset

מסמנים את הלוח בשם 'נציב'.

חיבור ל-USB מקורי

מכיוון שגרסת ה-build של OpenThread FTD מאפשרת להשתמש ב-ACM מקורי של USB CDC כהעברה טורית, צריך להשתמש ביציאת nRF USB בלוח nRF52840 כדי לתקשר עם מארח ה-RCP (מכונת Linux).

אימות ה-build

כדי לוודא שה-build פועל, ניגשים ל-OpenThread באמצעות מסך GNU מחלון הטרמינל. בלוחות nRF52840 נעשה שימוש בקצב באוד של 115200.

$ screen /dev/ttyACM1 115200

בחלון החדש, לוחצים כמה פעמים על Return במקלדת כדי להציג את ההודעה > של OpenThread CLI. מציגים את ממשק IPv6 ומחפשים כתובות:

> ifconfig up
Done
> ipaddr
fe80:0:0:0:1cd6:87a9:cb9d:4b1d
Done

משתמשים ב-Ctrl+a ←

d כדי להתנתק מהמסך של FTD Commissioner CLI ולחזור לטרמינל Linux כדי שיהיה אפשר להבהב את הלוח הבא. כדי להיכנס מחדש ל-CLI בכל שלב, משתמשים ב-screen -r משורת הפקודה. כדי לראות רשימה של המסכים הזמינים, אפשר להשתמש בscreen -ls:

$ screen -ls
There is a screen on:
        74182.ttys000.mylinuxmachine        (Detached)
1 Socket in /tmp/uscreens/S-username.

הגדרת חיבור ל-FTD

חוזרים על התהליך שתואר למעלה כדי לבצע Flash את לוח nRF52840 השלישי, באמצעות ה-build הקיים של ot-cli-ftd.hex. בסיום, חשוב לחבר מחדש את הלוח למחשב באמצעות יציאת ה-USB של nRF ולהגדיר את המתג של מקור החשמל nRF ל-VDD.

אם שני הצמתים האחרים מחוברים למחשב Linux כשהלוח השלישי מחובר, הוא אמור להופיע כיציאה טורית /dev/ttyACM2:

$ ls /dev/ttyACM*
/dev/ttyACM0  /dev/ttyACM1  /dev/ttyACM2

מוסיפים את התווית 'להצטרפות'.

כשמבצעים אימות באמצעות Screen, במקום ליצור מופע חדש של Screen משורת הפקודה, מחברים מחדש את המופע הקיים ויוצרים חלון חדש שבו (שבו השתמשתם בשביל FTD Commissioner):

$ screen -r

יוצרים את החלון החדש במסך באמצעות Ctrl+a ← c.

תופיע הנחיה חדשה של שורת הפקודה. ניגשים ל-OpenThread CLI כדי להצטרף ל-FTD:

$ screen /dev/ttyACM2 115200

בחלון החדש הזה, לוחצים כמה פעמים על Return במקלדת כדי להציג את ההודעה > של OpenThread CLI. מציגים את ממשק IPv6 ומחפשים כתובות:

> ifconfig up
Done
> ipaddr
fe80:0:0:0:6c1e:87a2:df05:c240
Done

עכשיו, כש-FTD Joiner CLI נמצא באותו מופע של Screen כמו FTD Commissioner, אפשר לעבור ביניהם באמצעות Ctrl+a ← n.

משתמשים ב-Ctrl+a ←

d בכל שלב כדי לצאת מהמסך.

6. הגדרה של חלון הטרמינל

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

במצב אידיאלי, אמורים להיות לכם ארבעה חלונות זמינים:

שירות / יומנים של ot-daemon
RCP Joiner דרך ot-ctl
FTD Commissioner דרך OpenThread CLI
FTD Joiner דרך OpenThread CLI

אם ברצונך להשתמש בטרמינל / יציאה טורית או בכלי משלך, אפשר לדלג לשלב הבא. כדאי להגדיר את חלונות הטרמינל לכל המכשירים בדרך שהכי מתאימה לכם.

שימוש במסך

כדי שיהיה קל להשתמש, מומלץ להתחיל סשן מסך אחד בלבד. כשתגדירו את שני תשלומי ה-FTD, כבר אמורה להיות לכם יתרה.

כל הפקודות במסך מתחילות בהקשה על Ctrl+a.

פקודות מסך בסיסיות:

צירוף מחדש לסשן המסך (משורת הפקודה)	`screen -r`
יציאה מהפעלת המסך	Ctrl+a ← `d`
יצירת חלון חדש בסשן המסך	Ctrl+a ← `c`
מעבר בין חלונות באותו סשן מסך	Ctrl+a ← `n` (קדימה)Ctrl+a ← `p` (הקודם)
סגירת החלון הנוכחי בסשן המסך	Ctrl+a ← `k`

מסך מפוצל

באמצעות התכונה 'מסך', ניתן לפצל את הטרמינל לכמה חלונות:

אפשר לגשת לפקודות ב-screen באמצעות Ctrl+a. כל פקודה צריכה להתחיל בשילוב הזה של מקשי הגישה.

אם עקבתם בדיוק אחרי ה-Codelab, צריכים להיות לך שני חלונות (FTD Commissioner, FTD Joiner) באותו מופע מסך. כדי לפצל את המסך בין שני המכשירים, קודם צריך להיכנס לסשן הנוכחי של המסך:

$ screen -r

אתם צריכים להיות מחוברים לאחד ממכשירי FTD. מבצעים את השלבים הבאים במסך:

Ctrl+a ← S כדי לפצל את החלון לרוחב
Ctrl+a ← Tab להעברת הסמן לחלון הריק החדש
Ctrl+a ← n כדי להחליף את החלון החדש לחלון הבא
אם הוא זהה לחלון העליון, מקישים שוב על Ctrl+a ← n כדי להציג את מכשיר ה-FTD האחר

עכשיו שתיהן גלויות. אפשר לעבור ביניהם באמצעות Ctrl+a ← Tab. מומלץ לשנות את הכותרת של כל חלון באמצעות Ctrl+a ← A כדי למנוע בלבול.

שימוש מתקדם

כדי לפצל את המסך לריבועים נוספים ולצפות ביומנים של ot-daemon וב-RCP Joiner ot-ctl, צריך להפעיל את השירותים האלה בתוך אותו המופע של המסך. כדי לעשות זאת, צריך לעצור את ot-daemon ולצאת מ-ot-ctl, ולהפעיל אותם מחדש בחלונות חדשים במסך (Ctrl+a ← c).

ההגדרה הזו אינה נדרשת והיא נשארת לביצוע תרגול עבור המשתמש.

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

יצירת חלון חדש	Ctrl+a ← `c`
חלון פיצול אנכי	Ctrl+a ←
פיצול חלון לרוחב	Ctrl+a ← `S`
מעבר לחלון הבא שמוצג	Ctrl+a ← `Tab`
החלפת החלון המוצג קדימה או אחורה	Ctrl+a ← `n` או `p`
שינוי השם של החלון הנוכחי	Ctrl+a ← `A`

אפשר לצאת מהמסך בכל שלב באמצעות Ctrl+a ← d ולצרף אותו מחדש באמצעות screen -r משורת הפקודה.

מידע נוסף על Screen זמין במדריך המהיר למסך GNU.

7. יצירת רשת של פרוטוקול Thread

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

## FTD Commissioner ##
----------------------

> dataset init new
Done
> dataset
Active Timestamp: 1
Channel: 11
Channel Mask: 07fff800
Ext PAN ID: c0de7ab5c0de7ab5
Mesh Local Prefix: fdc0:de7a:b5c0/64
Network Key: 1234c0de7ab51234c0de7ab51234c0de
Network Name: OpenThread-c0de
PAN ID: 0xc0de
PSKc: ebb4f2f8a68026fc55bcf3d7be3e6fe4
Security Policy: 0, onrcb
Done

חשוב לשים לב למפתח הרשת 1234c0de7ab51234c0de7ab51234c0de, שייעשה בו שימוש בהמשך.

שומרים את מערך הנתונים הזה בתור מערך הנתונים הפעיל:

> dataset commit active
Done

מציגים את ממשק IPv6:

> ifconfig up
Done

התחלת פעולה של פרוטוקול Thread:

> thread start
Done

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

## FTD Commissioner ##
----------------------

> state
leader
Done
> rloc16
0c00
Done

בודקים את כתובות ה-IPv6 של המכשיר:

## FTD Commissioner ##
----------------------

> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:fc00        # Leader Anycast Locator (ALOC)
fdc0:de7a:b5c0:0:0:ff:fe00:c00         # Routing Locator (RLOC)
fdc0:de7a:b5c0:0:6394:5a75:a1ad:e5a    # Mesh-Local EID (ML-EID)
fe80:0:0:0:1cd6:87a9:cb9d:4b1d         # Link-Local Address (LLA)

הכלי Codelab הרשת גלויה עכשיו כשסורקים אותה ממכשירים אחרים בפרוטוקול Thread.

החל מ-ot-ctl בהצטרפות ל-RCP:

## RCP Joiner ##
----------------

> scan
| PAN  | MAC Address      | Ch | dBm | LQI |
+------+------------------+----+-----+-----+
| c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |

מ-OpenThread CLI ב-FTD Joiner:

## FTD Joiner ##
----------------

> scan
| PAN  | MAC Address      | Ch | dBm | LQI |
+------+------------------+----+-----+-----+
| c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |

אם הפונקציה Codelab הרשת לא מופיעה ברשימה, יש לנסות לסרוק שוב.

8. הוספת RCP Joiner

'ניהול שרשורים' לא פעיל ברשת. כלומר, נצטרך להוסיף את איחוד ה-RCP לרשת פרוטוקול Thread שיצרנו עכשיו באמצעות תהליך הזמנה מחוץ למסגרת.

ב-FTD Commissioner רשמנו לנו את מפתח הרשת, לדוגמה 1234c0de7ab51234c0de7ab51234c0de. כדי לחפש שוב את מפתח הרשת, מריצים את הפקודה הבאה ב-FTD Commissioner:

## FTD Commissioner ##

> dataset networkkey
1234c0de7ab51234c0de7ab51234c0de
Done

לאחר מכן, ב-RCP Joiner, מגדירים את מפתח הרשת הפעיל של מערך הנתונים שלו כמפתח הרשת של FTD Commissioner:

## RCP Joiner ##
----------------

> dataset networkkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

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

## RCP Joiner ##
----------------

> dataset
Network Key: 1234c0de7ab51234c0de7ab51234c0de

העלאת פרוטוקול Thread כדי שה-RCP Joiner יצטרף ל-Codelab עמוקה מאוד, ממתינים כמה שניות, ובודקים את המצב RLOC16 וכתובות ה-IPv6 שלו:

## RCP Joiner ##
----------------

> ifconfig up
Done
> thread start
Done
> state
child
Done
> rloc16
0c01
Done
> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:0c01         # Routing Locator (RLOC)
fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f    # Mesh-Local EID (ML-EID)
fe80:0:0:0:18e5:29b3:a638:943b          # Link-Local Address (LLA)
Done

כדאי לרשום את כתובת ה-IPv6 של Mesh-Local (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f כאן), והיא תשתמש בה מאוחר יותר.

חוזרים ב-FTD Commissioner, בודקים את טבלאות הנתבים ואת הטבלאות כדי לוודא ששני המכשירים הם חלק מאותה רשת. משתמשים ב-RLOC16 כדי לזהות את חיבור ה-RCP.

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  35 | 1ed687a9cb9d4b1d |

Done
> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|VER| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+---+------------------+
|   1 | 0x0c01 |        240 |         25 |     3 |   89 |1|1|1|  2| 1ae529b3a638943b |
Done

לעשות פינג לכתובת המקומית של חיבור RCP (כתובת הרשת המקומית שהתקבלה מפלט ipaddr של ה-RCP Joiner) כדי לאמת את הקישוריות:

## FTD Commissioner ##
----------------------

> ping fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f
> 8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=1 hlim=64 time=40ms

יש לנו עכשיו רשת של פרוטוקול Thread שמורכבת משני צמתים, כפי שמתואר בתרשים הטופולוגיה הבא:

דיאגרמות טופולוגיה

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

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

9. עמלה על הצטרפות ל-FTD

עכשיו נוסיף את מכשיר פרוטוקול Thread השלישי ל-Codelab עמוקה מאוד, הפעם נשתמש בתהליך ההזמנה המאובטח יותר בתוך הרצועה, ונאפשר רק למצטרפים ל-FTD.

בהצטרפות ל-FTD, מקבלים את הערך eui64 כדי שה-FTD Commissioner יוכל לזהות אותו:

## FTD Joiner ##
----------------

> eui64
2f57d222545271f1
Done

ב-FTD Commissioner, מפעילים את הנציב ומציינים את ה-eui64 של המכשיר שיכול להצטרף, יחד עם פרטי הכניסה של המצטרפים, לדוגמה J01NME. פרטי הכניסה להצטרפות הם מחרוזת ספציפית למכשיר שכוללת את כל התווים האלפאנומריים באותיות רישיות (0-9 ו-A-Y, לא כולל I, O, Q ו-Z), והאורך שלהם הוא בין 6 ל-32 תווים.

## FTD Commissioner ##
----------------------

> commissioner start
Done
> commissioner joiner add 2f57d222545271f1 J01NME
Done

עוברים אל FTD Joiner. מתחילים את תפקיד ההצטרפות עם פרטי הצירוף שהגדרתם כרגע אצל נציב ה-FTD:

## FTD Joiner ##
----------------

> ifconfig up
Done
> joiner start J01NME
Done

תוך כדקה תקבלו אישור לכך שהאימות בוצע בהצלחה:

## FTD Joiner ##
----------------

>
Join success

העלאת פרוטוקול Thread כדי שה-FTD Joiner יצטרף ל-Codelab רשת, ולבדוק מיד את המצב ואת RLOC16:

## FTD Joiner ##
----------------

> thread start
Done
> state
child
Done
> rloc16
0c02
Done

בודקים את כתובות ה-IPv6 של המכשיר. שימו לב שאין ALOC. הסיבה לכך היא שהמכשיר הזה לא ה-Leader, וגם אין לו תפקיד ספציפי ל-Anycast שמחייב ALOC.

## FTD Joiner ##
----------------

> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:c02         # Routing Locator (RLOC)
fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd    # Mesh-Local EID (ML-EID)
fe80:0:0:0:e4cd:d2d9:3249:a243         # Link-Local Address (LLA)

עוברים מיד ל-FTD Commissioner ובודקים את טבלאות הנתבים והצאצאים כדי לוודא ששלושה מכשירים קיימים ב-Codelab רשת:

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  50 | 1ed687a9cb9d4b1d |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0x0c01 |        240 |         25 |     3 |   89 |1|1|1|1| 1ae529b3a638943b |
|   2 | 0x0c02 |        240 |         15 |     3 |   44 |1|1|1|1| e6cdd2d93249a243 |
Done

על סמך RLOC16, ה-FTD Joiner הצטרף לרשת כמכשיר קצה (צאצא). הנה הטופולוגיה המעודכנת שלנו:

10. שרשור פעיל

מכשירי פרוטוקול Thread ב-Codelab הזה הם סוג ספציפי של מכשיר קצה שמשתמש בפרוטוקול Thread מלא (FTD) שנקרא 'מכשיר קצה' שעומד בדרישות של נתב (REED). כלומר, הם יכולים לפעול כנתב או כמכשיר קצה, ויכולים לקדם את עצמם ממכשיר קצה לנתב.

פרוטוקול Thread יכול לתמוך ב-32 נתבים לכל היותר, אבל מספר הנתבים צריך להיות בין 16 ל-23. אם REED מצורף כמכשיר קצה (ילד) ומספר הנתבים נמוך מ-16, לאחר פרק זמן אקראי בתוך שתי דקות הוא מקדם את עצמו באופן אוטומטי לנתב.

אם היו לכם שני ילדים ברשת של פרוטוקול Thread אחרי שהוספתם את חיבור ה-FTD, ממתינים לפחות שתי דקות ואז בודקים שוב את טבלאות הצאצא והנתב ב-FTD Commissioner:

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  50 | 1ed687a9cb9d4b1d |
| 46 | 0xb800 |       63 |         0 |     3 |      3 |   1 | e6cdd2d93249a243 |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0x0c01 |        240 |         61 |     3 |   89 |1|1|1|1| 1ae529b3a638943b |
Done

ה-FTD Joiner (Extended MAC = e6cdd2d93249a243) קידם את עצמו לנתב. הערה: ה-RLOC16 שונה (b800 במקום 0c02). הסיבה לכך היא ש-RLOC16 מבוסס על מזהה הנתב ומזהה הצאצא של מכשיר. במעבר מ'מכשיר קצה' לנתב, הערכים של מזהה הנתב ומזהה הצאצא שלו משתנים, וכך גם משתנה ה-RLOC16.

מאשרים את המצב החדש ואת RLOC16 ב-FTD Joiner:

## FTD Joiner ##
----------------

> state
router
Done
> rloc16
b800
Done

שדרוג לאחור של ההצטרפות ל-FTD

אפשר לבדוק את ההתנהגות הזו על ידי שדרוג לאחור של FTD Joiner מנתב בחזרה למכשיר קצה. משנים את המצב ל'ילד' ובודקים את ה-RLOC16:

## FTD Joiner ##
----------------

> state child
Done
> rloc16
0c03
Done

נחזור אל FTD Commissioner. עכשיו הוא אמור להופיע בטבלת הצאצא (מזהה = 3). הוא יכול להופיע גם בזמן המעבר:

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  50 | 1ed687a9cb9d4b1d |
| 46 | 0xb800 |       63 |         0 |     3 |      3 |   1 | e6cdd2d93249a243 |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0x0c01 |        240 |         61 |     3 |   89 |1|1|1|1| 1ae529b3a638943b |
|   3 | 0x0c03 |        240 |         16 |     3 |   94 |1|1|1|1| e6cdd2d93249a243 |
Done

אחרי כמה זמן הוא יחזור לנתב עם RLOC של b800.

הסרת הבכיר בארגון

המנהיג נבחר על עצמו מבין כל נתבי ה-thread. כלומר, אם ה-Lead הנוכחי יוסר מרשת ה-thread, אחד מהנתבים האחרים יהפוך למנהיג החדש.

ב-FTD Commissioner, משביתים את פרוטוקול Thread כדי להסיר אותו מרשת פרוטוקול Thread:

## FTD Commissioner ##
----------------------

> thread stop
Done
> ifconfig down
Done

תוך שתי דקות, ההצטרפות ל-FTD תהפוך למנהיגה החדשה של ה-threads. בודקים את המדינה ואת כתובות ה-IPv6 של FTD Joiner כדי לוודא:

## FTD Joiner ##
----------------

> state
leader
Done
> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:fc00       # Now it has the Leader ALOC!
fdc0:de7a:b5c0:0:0:ff:fe00:b800
fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd
fe80:0:0:0:e4cd:d2d9:3249:a243
Done

בודקים את טבלת הצאצא. שימו לב שיש RLOC16 חדש. זהו חיבור RCP, כפי שמצוין במזהה שלו וב-MAC המורחב. כדי שרשת ה-Thread תהיה משותפת, החברה החליפה את נתבי ההורה, מ-FTD Commissioner ל-FTD Joiner. התוצאה היא RLOC16 חדש ל-RCP Joiner (כי מזהה הנתב השתנה מ-3 ל-46).

## FTD Joiner ##
----------------

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0xb801 |        240 |         27 |     3 |  145 |1|1|1|1| 1ae529b3a638943b |
Done

יכול להיות שתצטרכו לחכות כמה דקות עד שה-RCP Joiner יצטרף ל-FTD Joiner כילד. בודקים את המדינה (State) ואת RLOC16 כדי לוודא:

## RCP Joiner ##
--------------

> state
child
> rloc16
b801

צירוף מחדש של נציב ה-FTD

חיבור לרשת של פרוטוקול Thread עם שני צמתים לא ממש כיף. בואו נחזיר את נציבות FTD.

ב-FTD Commissioner, מפעילים מחדש את Thread:

## FTD Commissioner ##
----------------------

> ifconfig up
Done
> thread start
Done

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

## FTD Commissioner ##
----------------------

> state
router
Done

בודקים את טבלאות הנתבים והצאצאים ב-FTD Joiner כדי לוודא:

## FTD Joiner ##
----------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |       63 |         0 |     3 |      3 |   0 | 1ed687a9cb9d4b1d |
| 46 | 0xb800 |       46 |         0 |     0 |      0 |  15 | e6cdd2d93249a243 |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0xb801 |        240 |        184 |     3 |  145 |1|1|1|1| 1ae529b3a638943b |
Done

רשת פרוטוקול Thread שוב מורכבת משלושה צמתים.

11. פתרון בעיות

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

סינון

אם אי פעם תאבדו את ההגדרות האישיות (יותר מדי חלונות מסך, או מסכים בתוך המסך), כדאי להמשיך לסגור חלונות מסך באמצעות Ctrl+a ← k עד שלא קיים שום דבר, ו-screen -ls בפלט של שורת הפקודה No Sockets found. לאחר מכן צריך ליצור מחדש חלונות מסך בכל מכשיר. מצבי המכשיר נשמרים גם כשהמסך מושבת.

צמתים של שרשורים

אם הטופולוגיה של רשת פרוטוקול Thread שונה מזו שמתוארת ב-Codelab הזה, או שצמתים מתנתקים מסיבה כלשהי (אולי כי מכונת Linux המעבירה אותם למצב שינה), מומלץ להוריד את פרוטוקול Thread, למחוק את פרטי הכניסה לרשת ולהתחיל שוב מהשלב יצירת רשת פרוטוקול Thread.

כדי לאפס את ה-FTD:

## FTD Commissioner or FTD Joiner ##
------------------------------------

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

אפשר לאפס את ה-RCP באותו אופן דרך ot-ctl:

## RCP Joiner ##
----------------

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

12. שימוש ב-Multicast

פרוטוקול Multicast משמש להעברת מידע לקבוצת מכשירים בבת אחת. ברשת בפרוטוקול Thread, כתובות ספציפיות שמורות לשימוש בריבוי שידורים בקבוצות שונות של מכשירים, בהתאם להיקף.

כתובת IPv6	היקף	נשלחה אל
`ff02::1`	קישור מקומי	כל סוגי ה-FTD וה-MED
`ff02::2`	קישור מקומי	כל ה-FTD ונתבי הגבולות
`ff03::1`	רשת מקומית	כל סוגי ה-FTD וה-MED
`ff03::2`	רשת מקומית	כל ה-FTD ונתבי הגבולות

מכיוון שאנחנו לא משתמשים בנתב גבול ב-Codelab הזה, נתמקד בשתי כתובות ה-FTD וה-MED בשידור מרובה משתתפים.

קישור מקומי

ההיקף 'קישור-מקומי' כולל את כל ממשקי Thread שניתן להגיע אליהם באמצעות שידור רדיו אחד, או צעד אחד. הטופולוגיה של הרשת קובעת אילו מכשירים יגיבו לפינג לכתובת Multicast ב-ff02::1.

שליחת פינג אל ff02::1 מ-FTD Commissioner:

## FTD Commissioner ##
----------------------

> ping ff02::1
> 8 bytes from fe80:0:0:0:e4cd:d2d9:3249:a243: icmp_seq=2 hlim=64 time=9ms

יש שני מכשירים נוספים ברשת (FTD Joiner ו-RCP Joiner), אבל נציב ה-FTD קיבל רק תגובה אחת, מכתובת הקישור המקומית (LLA) של מגיש ה-FTD. המשמעות היא שהמצור ל-FTD הוא המכשיר היחיד שאליו נציב ה-FTD יכול להגיע בצעד אחד.

עכשיו מתבצע פינג ל-ff02::1 דרך ההצטרפות ל-FTD:

## FTD Joiner ##
----------------

> ping ff02::1
> 8 bytes from fe80:0:0:0:1cd6:87a9:cb9d:4b1d: icmp_seq=1 hlim=64 time=11ms
8 bytes from fe80:0:0:0:18e5:29b3:a638:943b: icmp_seq=1 hlim=64 time=24ms

שתי תגובות! כשבודקים את כתובות ה-IPv6 במכשירים האחרים, אפשר לראות שהכתובת הראשונה (שמסתיימת ב-4b1d) היא ה-LLA של נציב ה-FTD והשנייה (שמסתיימת ב-943b) היא ה-LLA של ה-RCP Joiner.

המשמעות היא שהמצרף ל-FTD מקושר ישירות גם ל-FTD Commissioner וגם ל-RCP Joiner, כדי לאשר את הטופולוגיה שלנו.

רשת מקומית

ההיקף של Mesh-Local כולל את כל ממשקי ה-Thread שניתן להגיע אליהם דרך אותה רשת פרוטוקול Thread. בואו נראה את התשובות לשליחת נדנוד אל כתובת Multicast ב-ff03::1.

שליחת פינג אל ff03::1 מ-FTD Commissioner:

## FTD Commissioner ##
----------------------

> ping ff03::1
> 8 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:b800: icmp_seq=3 hlim=64 time=9ms
8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=3 hlim=64 time=68ms

הפעם קיבל נציב FTD שתי תגובות, אחת מ'מאתר הניתוב של FTD' (RLOC, שמסתיים ב-b800) ואחת מ-Mesh-Local EID של ה-RCP Joiner (ML-EID, מסתיימת ב-d55f). הסיבה לכך היא שההיקף המקומי ברשת כולל את כל רשת פרוטוקול ה-Thread. לא משנה איפה נמצא המכשיר ברשת, הוא יירשם לכתובת ff03::1.

מבצעים פינג לציון ff03::1 מה-FTD Joiner כדי לאשר את אותה ההתנהגות:

## FTD Joiner ##
----------------

> ping ff03::1
> 8 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00: icmp_seq=2 hlim=64 time=11ms
8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=2 hlim=64 time=23ms

חשוב לשים לב לזמן התגובה של ה-RCP Joiner בשני הפלט של הפינגים. ל-RCP Joiner נדרש הרבה יותר זמן להגיע לנציב ה-FTD (68 אלפיות השנייה) מאשר זמן להגיע ל-FTD Joiner (23 אלפיות השנייה). זה כי הוא צריך לעשות שני צעדים כדי להגיע לנציבות ה-FTD, בהשוואה לצעד אחד למצטרפים ל-FTD.

כמו כן, ייתכן שהבחנתם שהפינג לציון מספר העברות מקומי ברשת הגיב עם ה-RLOC רק לשני ה-FTD, ולא ל-RCP Joiner. הסיבה לכך היא שה-FTD הם נתבים בתוך הרשת, וה-RCP הוא מכשיר קצה.

בודקים את המצב של RCP Joiner כדי לוודא:

## RCP Joiner ##
----------------

> state
child

13. שליחת הודעות באמצעות UDP

אחד משירותי האפליקציות ש-OpenThread מספק הוא פרוטוקול User Datagram (UDP), שהוא פרוטוקול Transport Layer. אפליקציה שמבוססת על OpenThread יכולה להשתמש ב-API UDP כדי להעביר הודעות בין צמתים ברשת בפרוטוקול Thread, או למכשירים אחרים ברשת חיצונית (כמו האינטרנט, אם ברשת בפרוטוקול Thread יש נתב גבול).

שקעי UDP חשופים דרך CLI של OpenThread. נשתמש בו כדי להעביר הודעות בין שני ה-FTD.

מקבלים את כתובת ה-EID מסוג Mesh-Local ל-FTD Joiner. אנחנו משתמשים בכתובת הזו כי ניתן להגיע אליה מכל מקום ברשת של פרוטוקול Thread.

## FTD Joiner ##
----------------

> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:fc00        # Leader Anycast Locator (ALOC)
fdc0:de7a:b5c0:0:0:ff:fe00:b800        # Routing Locator (RLOC)
fe80:0:0:0:e4cd:d2d9:3249:a243         # Link-Local Address (LLA)
fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd    # Mesh-Local EID (ML-EID)
Done

מפעילים UDP ומקשרים אותו לשקע בכל כתובת IPv6:

## FTD Joiner ##
----------------

> udp open
Done
> udp bind :: 1212

עוברים אל FTD Commissioner, מפעילים UDP ומתחברים לשקע שהגדרתם ב-FTD Joiner באמצעות ה-ML-EID שלו:

## FTD Commissioner ##
----------------------

> udp open
Done
> udp connect fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd 1212
Done

חיבור ה-UDP צריך להיות פעיל בין שני הצמתים. שליחת הודעה מנציב ה-FTD:

## FTD Commissioner ##
----------------------

> udp send hellothere
Done

הודעת ה-UDP התקבלה ב-FTD Joiner!

## FTD Joiner ##
----------------

> 10 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00 49153 hellothere

14. מעולה!

יצרת רשת פיזית של פרוטוקול Thread!

עכשיו אתם יודעים:

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

השלבים הבאים

בהמשך ל-Codelab הזה, כדאי לנסות את התרגילים הבאים:

לעדכן את לוח ההצטרפות ל-FTD כ-MTD באמצעות הקובץ הבינארי של ot-cli-mtd, ולוודא שהוא אף פעם לא משדרג את עצמו ל-Router או מנסה להפוך למוביל
אפשר להוסיף עוד מכשירים (לנסות פלטפורמה אחרת!) לרשת ולשרטט את הטופולוגיה באמצעות שימוש בטבלאות נתבים וצאצאים, יחד עם פינגים לכתובות ה-Multicast
להשתמש ב-pyspinel כדי לשלוט ב-NCP
המרת ה-NCP לנתב גבול באמצעות OpenThread Border Router וחיבור של רשת פרוטוקול Thread לאינטרנט

קריאה נוספת

ב-openthread.io וב-GitHub יש מגוון משאבים ב-OpenThread, כולל:

פלטפורמות נתמכות – כאן מופיעות כל הפלטפורמות שתומכות ב-OpenThread
פיתוח OpenThread – פרטים נוספים על פיתוח והגדרה של OpenThread
Thread Primer – כל מושגי ה-Thread שמופיעים ב-Codelab הזה

הפניה: