главная форум чат фотогалерея ресурсы новости календарь игротека поиск почта


Страницы: (2) [1] 2  ( Перейти к первому непрочитанному сообщению ) ответить | новая тема | опрос

> Требуется, Инженер
motodimka
посетители



В АО "Связьтранснефть" Северо - Кавказское ПТУС на постоянную работу требуется инженер 1 категории диспетчерской группы Регионального центра управления.
Требования к соискателю:
Высшее техническое (в области связи) образование и стаж работы в должности инженера II категории или других инженерно-технических должностях, замещаемых специалистами с высшим профессиональным образованием, не менее 3 лет;
Необходимые базовые знания:
Принципы работы цифровых систем передачи информации, систем радиосвязи и спутниковой связи;
Понятие открытых систем и модели OSI, канальной инфраструктуры для глобальных сетей;
Принципы и механизмы объединения сетей на основе протокола сетевого и канального уровней, отображения локальных, сетевых и символьных адресов, использования масок и современных методов агрегирования IP – адресов;
Способы автоматического конфигурирования узлов;
Понятие о средствах анализа и управления сетями связи.

График работы: 09:00-18:00, понедельник - пятница, возможны выходы в сменном режиме работы.
З/п: оклад 36900+премия (70%).

Резюме направлять:
birukovdv@stn.transneft.ru
Вопросы по телефону: 88617-60-39-99, Бирюков Дмитрий Владимирович.
20.02.18 - 14:54 #6662083
motodimka
посетители



Требуется...
06.03.18 - 23:26 #6665453
motodimka
посетители



Требуется...
13.03.18 - 17:38 #6666724
onehalf3554
инквизитор
свои пацаны



Нафига?
А уж модель оси нафига?
15.03.18 - 23:51 #6667254
_Kuzmich_
посетители



QUOTE
А уж модель оси нафига?


Какэта нафига??? Первый вопрос на любом собеседовании =)
Я, кстатиговоря, резюме отправил....в личку хоть черканите, как чего.
16.03.18 - 20:16 #6667363
onehalf3554
инквизитор
свои пацаны



QUOTE (_Kuzmich_ @ 16.03.18 - 17:16)
QUOTE
А уж модель оси нафига?


Какэта нафига??? Первый вопрос на любом собеседовании =)
Я, кстатиговоря, резюме отправил....в личку хоть черканите, как чего.

На практике эта самая оси не более ч5м умозрительная модель.
16.03.18 - 21:32 #6667373
_Kuzmich_
посетители



QUOTE
На практике эта самая оси не более ч5м умозрительная модель.

Да вот не скажи.
Некоторые личности, не видя мак в пору и не имея понятия, как его там получить - усиленно винят протокол DHCP в ошибках.
Не имея понятия об очередности L2-L3-L4 этой самой модели OSI.
В мозгу всегда должна быть эта цепочка и осознание, что-за-чем следует =)
16.03.18 - 21:40 #6667377
onehalf3554
инквизитор
свои пацаны



QUOTE (_Kuzmich_ @ 16.03.18 - 18:40)
QUOTE
На практике эта самая оси не более ч5м умозрительная модель.

Да вот не скажи.
Некоторые личности, не видя мак в пору и не имея понятия, как его там получить - усиленно винят протокол DHCP в ошибках.
Не имея понятия об очередности L2-L3-L4 этой самой модели OSI.
В мозгу всегда должна быть эта цепочка и осознание, что-за-чем следует =)

По большому счёту достаточно знать стэк протоколов tcp/IP чтобы вообще не париться про все эти твои mac_и которые впрочем как выяснилось элементарно можно подделать в некоторых os, для этого есть инструментарий. Хошь узнать мак на пожалуйста
Arp -a . И всех делов. Можно проводить спуффинг Arp и получить массу полезной инфы.
В конце концов достаточно просто запустить tcpdump чтобы не париться.
А лучше написать miniport/protocol ndis driver ,чтобы всё понять изнутри, если уж совсем долбак всегда можно побаловаться с winsock.
Этим чудакам и нужен не спец а понты.
Спецы оси нафиг не нужен он просто структуру too/IP пакета всегда посмотреть может.
Протокол tcp/IP просто последовательность структур plain/data данных инвестирующих
Используемый устройством аппаратный протокол и всё.
17.03.18 - 08:13 #6667448
_Kuzmich_
посетители



2 onehalf3554

Ты вот опять ап теории, не об фактах.
Я говорил о том, что современные "шпециалисты-практики" не способны понять логику работы модели OSI.
А тебя опять понесло в структуру TCP\IP.
Этот протокол - это уже L3-L4.
А вот когда мака нет! Линк есть, а мака нет! Ты вот куда копать начнешь? В протокол TCP\IP??? Он тут будет не при чем! До него еще не дойдет дело т.к. не дошел уровень модели OSI!
17.03.18 - 21:18 #6667591
onehalf3554
инквизитор
свои пацаны



QUOTE (_Kuzmich_ @ 17.03.18 - 18:18)
2 onehalf3554

Ты вот опять ап теории, не об фактах.
Я говорил о том, что современные "шпециалисты-практики" не способны понять логику работы модели OSI.
А тебя опять понесло в структуру TCP\IP.
Этот протокол - это уже L3-L4.
А вот когда мака нет! Линк есть, а мака нет! Ты вот куда копать начнешь? В протокол TCP\IP??? Он тут будет не при чем! До него еще не дойдет дело т.к. не дошел уровень модели OSI!

Мака в пакете не быть не может. Мак это самый низкий уровень.скачай tcpdump посмотри как выглядят пакеты,.что ты подразумевает под линком?нет мака пакеты никуда не идут.
Протокол arp(wtf!!!!!!!!) просто не имеет соответствия между IP/mac адресом. Поэтому просто не знает куда слать пакет. Драйвер сетевухи и тоже н чего не знает о том,куда сдать пакет, если у машины нет мака-нет сетевого устройства. Через что ты будешь стать пакеты?
18.03.18 - 07:24 #6667644
motodimka
посетители



Требуется...
31.03.18 - 21:55 #6670998
W
посетители



>Мака в пакете не быть не может.
Может. Вас туда, наверное, не возьмут.
01.04.18 - 12:06 #6671055
_Kuzmich_
посетители



2 W
Ну хоть один здравомыслящий....
А то понаслушаешся:
QUOTE
нет мака пакеты никуда не идут.

...и потеряешь веру в бродкаст\мультикаст 0_о
01.04.18 - 14:37 #6671077
onehalf3554
инквизитор
свои пацаны



QUOTE (W @ 01.04.18 - 09:06)
>Мака в пакете не быть не может.
Может. Вас туда, наверное, не возьмут.

1.Можно пример дампа такого ip пакета , и ссылочку на соответствующее rfc?
Собственно если речь идёт про MPEG2
то вот rfc, там я не нашёл ничего по поводу отсутствия или очистки MAC адреса.:
https://tools.ietf.org/html/rfc4947#page-21
Есть ли какието предположения как ARP или SARP будет работать без MAC ?
Или как будет проходить AR без ARP или SARP?

2.Какбы я никуда и не прошусь мне до фонаря. Слишком я стар для геморроя.

2Кузьмич
QUOTE

..и потеряешь веру в бродкаст\мультикаст 0_о

Можешь верить а можешь нет, но даже в случае этих самых твоих кастов
ARP/SARP всё равно действуют.
Ну и что касается DVB

https://tools.ietf.org/html/rfc4947#section-4.2.1

4.2.1. IP/MAC Notification Table (INT) and Its Usage

The INT provides a set of descriptors to specify addressing in a DVB
network. The use of this method is specified for Multiprotocol
Encapsulation (MPE) [ETSI-DAT]. It provides a method for carrying
information about the location of IP/L2 flows within a DVB network.
A Platform_ID identifies the addressing scope for a set of IP/L2
streams and/or Receivers. A Platform may span several Transport
Streams carried by one or multiple TS Multiplexes and represents a
single IP network with a harmonized address space (scope). This
allows for the coexistence of several independent IP/MAC address
scopes within an MPEG-2 Network.

The INT allows both fully-specified IP addresses and prefix matching
to reduce the size of the table (and hence enhance signalling
efficiency). An IPv4/IPv6 "subnet mask" may be specified in full
form or by using a slash notation (e.g., /127). IP multicast
addresses can be specified with or without a source (address or
range), although if a source address is specified, then only the
slash notation may be used for prefixes.

In addition, for identification and security descriptors, the
following descriptors are defined for address binding in INT tables:

(i) target_MAC_address_descriptor: A descriptor to describe a
single or set of MAC addresses (and their mask).

(ii) target_MAC_address_range_descriptor: A descriptor that may be
used to set filters.

(iii) target_IP_address_descriptor: A descriptor describing a single
or set of IPv4 unicast or multicast addresses (and their mask).

(iv) target_IP_slash_descriptor: Allows definition and announcement
of an IPv4 prefix.

(v) target_IP_source_slash_descriptor: Uses source and destination
addresses to target a single or set of systems.

(vi) IP/MAC stream_location_descriptor: A descriptor that locates an
IP/MAC stream in a DVB network.

The following descriptors provide corresponding functions for IPv6
addresses:

target_IPv6_address_descriptor
target_IPv6_slash_descriptor
and target_IPv6_source_slash_descriptor
02.04.18 - 14:18 #6671257
_Kuzmich_
посетители



QUOTE
но даже в случае этих самых твоих кастов
ARP/SARP всё равно действуют.


ОМГ, ну и какой же dstMAC у пакета с запросом DHCPDISCOVER? А srcMAC?
Или ff-ff-ff-ff-ff-ff - ты тоже за реальный адрес посчитаешь?
02.04.18 - 15:19 #6671271
onehalf3554
инквизитор
свои пацаны



QUOTE (_Kuzmich_ @ 02.04.18 - 12:19)
QUOTE
но даже в случае этих самых твоих кастов
ARP/SARP всё равно действуют.


ОМГ, ну и какой же dstMAC у пакета с запросом DHCPDISCOVER? А srcMAC?
Или ff-ff-ff-ff-ff-ff - ты тоже за реальный адрес посчитаешь?

1.А можно точное определение словосочетания реальный mac? Желательно из rfc
Чтобы было о чём говорить.
2. Попробуй создать listen сокет на порту ну например 80, c IP адресом 192.168.1.1
И mac адресом ff:ff:ff:ff:ff:ff
Когда создашь такой сокет , попробуй прицепиться к нему с помощью telnet.
Потом расскажешь о содержимом arp, и о том, какой код будет у wsaerror.
3. Какое отношение вот это всё имеет к osi?
4.емнип dhcp discover запрос выполняется с IP src 0.0.0.0 и ip dst 255.255.255.255
Нихрена про mac в rfc вроде как нет.
К тому же dhcp это не tcp а вполне себе udp.
В чём разница объяснять?
5. IP адреса должны быть распознаваемы с помощью arp/sarp
Иначе dhcp можно выкинуть на свалку.

Очень плохо, что большинство админов никогда не заглядывать в rfc.
Именно поэтому этим занимаются разработчики.

И кстати да, я работаю сантехником меня устраивает.
02.04.18 - 19:05 #6671321
W
посетители



>Можно пример дампа такого ip пакета
Любой IP пакет между устройствами, соединенными не по Ethernet. Допустим, вот так.
Совсем другой L2/L1 по OSI, и все. Что с mac/arp/sarp/dhcp, догадываетесь?
02.04.18 - 20:50 #6671341
onehalf3554
инквизитор
свои пацаны



QUOTE (W @ 02.04.18 - 17:50)
>Можно пример дампа такого ip пакета
Любой IP пакет между устройствами, соединенными не по Ethernet. Допустим, вот так.
Совсем другой L2/L1 по OSI, и все тут.  Что с mac/arp/sarp/dhcp, догадываетесь?

Х.з. застал я ppp соединения уже очень давно.
обычное 6-и модовое оптоволокно подключалось через обычный медиаконвертер, соответственно 1-2 моды оптики втыкались конвертер а с него уже вываливался банальный ethernet, который втыкался в свитч.
Так что там с mac-ом проблем небыло.

По поводу ppp
по поводу arp, есть такая штука как wanarp. Детали её работы мне не известны.
Вот пацаны код смастерили простейший:
QUOTE

using System.Net.NetworkInformation;
foreach (NetworkInterface nic in NetworkInterface.GetAllNetworkInterfaces())
{
    PhysicalAddress mac = nic.GetPhysicalAddress();
    Console.WriteLine("{0} {1}", nic.Name, mac.ToString());
}

Ну и результат:
QUOTE

Interface: {FE9ABA8A-249D-4E45-A811-7B0F316F012B}
Name: SmartSurfer2000
Description: WAN (PPP/SLIP) Interface
Status: Up
MAC Address: 005345000000
Type: Ppp
Gateway Address:
Gateway entry: 217.184.36.122

Вот люди ipconfig запускали:
mac адрес всёравно какой-то зафикачивается.
Ipconfig /all output:
QUOTE

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 217.184.36.122
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 217.184.36.122
DNS Servers . . . . . . . . . . . : 213.20.148.205
193.189.244.205
NetBIOS over Tcpip. . . . . . . . : Disabled


QUOTE

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 217.184.36.122
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 217.184.36.122
DNS Servers . . . . . . . . . . . : 213.20.148.205
193.189.244.205
NetBIOS over Tcpip. . . . . . . . : Disabled




Ethereal capture:

Frame 973 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 01:00:01:00:00:00, Dst: b4:e1:20:00:01:00
Internet Protocol, Src Addr: 217.184.36.122 (217.184.36.122), Dst Addr: 68.142.197.57 (68.142.197.57)
Transmission Control Protocol, Src Port: 1194 (1194), Dst Port: http (80), Seq: 496, Ack: 565, Len: 0

I think the computer generates a random MAC for PPP connetion:

It is 01:00:01:00:00:00 , 02:00:02:00:00:00 or 03:00:03:00:00:00 and so on ....


GWIP = current IP !
02.04.18 - 23:15 #6671390
W
посетители



>>>Мака в пакете не быть не может.
>>Можно пример дампа такого ip пакета , и ссылочку на соответствующее rfc?
>6-и модовое оптоволокно ... wanarp ... пацаны ... люди ... M$DN ...
C темы не съезжаем: тут со ссылками на RFC все необходимое и достаточное для понимания, что в "IP/PoS/ STM-N" никакого MAC-а нет. Из "умозрительной" OSI следует наличие MAC адреса в пакетах только там, где Ethernet в L2/L1 или его инкапсулируют/эмулируют. Видения M$ ее личное интимное дело. IMHO дальнейший флуд не имеет смысла.
04.04.18 - 08:04 #6671653
habe-habe
посетители



ПИПЕЦ ПОМЕРИЛИСЬ И У КОГО ТОЛЩЕ ОКАЗАЛСЯ
Я так понимаю это форум програмёров
04.04.18 - 15:39 #6671715
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:

Topic OptionsСтраницы: (2) [1] 2  ответить | новая тема | опрос