Перейти к содержимому
Калькуляторы

Jaguar77

Активный участник
  • Публикации

    262
  • Зарегистрирован

  • Посещение

1 подписчик

О Jaguar77

  • Звание
    Студент
    Студент

Контакты

  • ICQ
    Array

Посетители профиля

2928 просмотров профиля
  1. Если по какой то причини старый контроллер согласует диски на 1.5 гбит/с значит это диски SATA III, 6 Гбит/с, на дисках можно поставить перемычку (схема нарисованна на некоторых дисках) для ограничения скорости.на дисках SATA II ограничит до 1.5, а на SATA III до 3Гбит/с
  2. глушат wifi ?

    Клиент тут выступает в качестве снифера. на картинке момоент когда к базе клиент не подключен( это bridge ). на картинке mac адрес базы. на базе был настроен watchdog на ip адрес клиента, и она должна была перезагрузиться. но данный трафик не пропадал. Клиент в это же время мог подключиться к базе, соединение устанавливалось на пару секунд и рвалось так как ccq 4%, но уровни сигнала отличные. В итоге в какое то время данный трафик пропал и всё заработало с ccq 99% . не понятно это у базы крышу сорвало или ктото глушил   И база действительно работала в nv2
  3. глушат wifi ?

    Здравствуйте, у меня бридж на микротике перестал работать нормально. уровни сигнала норм, но ccq 4%. Сниф трафика показывает вот такое (на картинке). Подскажите, это то что я думаю ? глушат что ли ?
  4. @Иван31 Скажите, а ночью у вас эти помехи уходят и SINR в норме ?
  5. Есть такая же проблемма, на пути дерево :-)
  6. Интернет для киберспорта

    Когда будете диагностировать где именно фриз - обратите внимание на программу LatencyMon (http://www.resplendence.com/). Её часто музыканты используют что б проверить latency компа и найти проблемный драйвер или устройство. Так же есть программа DPC latency checker(http://www.thesycon.de/). Потеря пакетов и микро фризы могут быть связанны с драйверами на компе.
  7. Loco m5 пропадает пинг

    У меня проблемма оказалась в сетевухе
  8. Loco m5 пропадает пинг

    Есть AirGrid M5 с такой же проблемой
  9. Всем привет, в связи с ростом http2 трафика DPI перестал нормально определять тип трафика. Поделитесь идеями, какие типы очередей делаете ? Нужно для улучшения Quality of Experience в ЧНН.
  10. нет прямой видимости нормальной, куча переотраженного сигнала, вот и и ошибки. поднимайте антенны выше
  11. Да вроде выключен он : [root@vps ~]# cat /proc/sys/net/ipv4/conf/eth0/proxy_arp 0 [root@vps ~]# cat /proc/sys/net/ipv4/conf/eth1/proxy_arp 0
  12. Здрарвствуйте, есть сервер с proxmox, настроен бридж стандартными средствами. В виртуалку приходит трафик не предназначенный для её mac адреса. пример : 18:14:26.786962b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3402176546>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:26.787425b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 66:62.183.54.28.916>193.34.133.80.2049:Flags[.],ack703684715,win8626,options[nop,nop,TSval261219643ecr1636892755],length 0 18:14:26.819355b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3418953762>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:26.820940b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3435730978>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:26.829235b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3452508194>193.34.133.80.2049:100getattrfh1419,477698/115408265 18:14:26.829793b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 174:62.183.54.28.3469285410>193.34.133.80.2049:104accessfh1419,477698/115408265002d 18:14:26.830218b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 198:62.183.54.28.3486062626>193.34.133.80.2049:128setattrfh1419,477698/115408265 18:14:26.869743b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 66:62.183.54.28.916>193.34.133.80.2049:Flags[.],ack621,win8626,options[nop,nop,TSval261219726ecr1636892798],length 0 18:14:26.967303b0:a8:6e:38:b1:9c>52:54:00:d4:4c:9a,ethertypeIPv4(0x0800),length 60:119.186.219.205.38898>62.183.54.90.22:Flags[S],seq1541813850,win38584,length 0 18:14:27.50306300:24:c4:c1:e4:94>01:80:c2:00:00:00,802.3,length 60:LLC,dsapSTP(0x42)Individual,ssapSTP(0x42)Command,ctrl0x03:STP802.1d,Config,Flags[none],bridge-id800b.00:24:c4:c1:e4:80.8014,length 43 18:14:27.707932b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 186:85.175.153.146.1648526012>193.34.133.80.2049:116accessfh1419,969867/101845270001f 18:14:27.708229b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 66:85.175.153.146.770>193.34.133.80.2049:Flags[.],ack3352235137,win24565,options[nop,nop,TSval450576972ecr3559426068],length 0 18:14:27.841580b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3502839842>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:27.841849b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 66:62.183.54.28.916>193.34.133.80.2049:Flags[.],ack737,win8626,options[nop,nop,TSval261220698ecr1636893809],length 0 18:14:27.874136b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3519617058>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:27.876039b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3536394274>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:27.884316b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3553171490>193.34.133.80.2049:100getattrfh1419,477698/115408265 18:14:27.884727b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 198:62.183.54.28.3569948706>193.34.133.80.2049:128setattrfh1419,477698/115408265 18:14:27.924852b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 66:62.183.54.28.916>193.34.133.80.2049:Flags[.],ack1233,win8626,options[nop,nop,TSval261220781ecr1636893852],length 0 18:14:28.413844d6:a8:ae:80:97:2b>ff:ff:ff:ff:ff:ff,ethertypeIPv4(0x0800),length 342:0.0.0.0.68>255.255.255.255.67:BOOTP/DHCP,Requestfromd6:a8:ae:80:97:2b,length 300 18:14:28.894413b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3586725922>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:28.894873b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 66:62.183.54.28.916>193.34.133.80.2049:Flags[.],ack1349,win8626,options[nop,nop,TSval261221751ecr1636894862],length 0 18:14:28.928352b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3603503138>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:28.930625b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3620280354>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:28.939119b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3637057570>193.34.133.80.2049:100getattrfh1419,477698/115408265 18:14:28.939536b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 198:62.183.54.28.3653834786>193.34.133.80.2049:128setattrfh1419,477698/115408265 18:14:28.979896b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 66:62.183.54.28.916>193.34.133.80.2049:Flags[.],ack1845,win8626,options[nop,nop,TSval261221836ecr1636894907],length 0 18:14:29.06084300:15:17:79:95:8b>ff:ff:ff:ff:ff:ff,ethertypeIPv4(0x0800),length 342:0.0.0.0.68>255.255.255.255.67:BOOTP/DHCP,Requestfrom00:15:17:79:95:8b,length 300 18:14:29.421442d6:a8:ae:80:97:2b>ff:ff:ff:ff:ff:ff,ethertypeIPv4(0x0800),length 342:0.0.0.0.68>255.255.255.255.67:BOOTP/DHCP,Requestfromd6:a8:ae:80:97:2b,length 300 18:14:29.50525100:24:c4:c1:e4:94>01:80:c2:00:00:00,802.3,length 60:LLC,dsapSTP(0x42)Individual,ssapSTP(0x42)Command,ctrl0x03:STP802.1d,Config,Flags[none],bridge-id800b.00:24:c4:c1:e4:80.8014,length 43 18:14:29.943273b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3670612002>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:29.943841b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 66:62.183.54.28.916>193.34.133.80.2049:Flags[.],ack1961,win8626,options[nop,nop,TSval261222800ecr1636895911],length 0 18:14:29.979425b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3687389218>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:29.981723b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3704166434>193.34.133.80.2049:100getattrfh1419,477698/112519001 18:14:29.989916b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 170:62.183.54.28.3720943650>193.34.133.80.2049:100getattrfh1419,477698/115408265 18:14:29.990360b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 174:62.183.54.28.3737720866>193.34.133.80.2049:104accessfh1419,477698/115408265002d 18:14:29.990770b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 198:62.183.54.28.3754498082>193.34.133.80.2049:128setattrfh1419,477698/115408265 18:14:30.031163b0:a8:6e:38:b1:9c>a0:36:9f:8d:7c:26,ethertypeIPv4(0x0800),length 66:62.183.54.28.916>193.34.133.80.2049:Flags[.],ack2581,win8626,options[nop,nop,TSval261222887ecr1636895958],length 0 вопросов к dhcp и stp нет, понятно почему их видно. но вот почему льётся трафик на мак a0:36:9f:8d:7c:26, хотя у этой сетевухи он совсем другой ?
  13. Здравствуйте, можно ли на БС mikrotik/ubnt сделать dhpc relay так что б на сервере видеть с какого клиента пришел запрос ? клиенты в бридже. Или на клиентах как то метить dhcp пакеты например по dscp, но как фильтровать по этому полю ? на клиентах релей не сделать тк на точках только vlan управления и порт в бридже, тоесть без IP адреса. По хорошему спасёт vlan на клиента....но блин у многих адреса на роутерах статикой прописанны