Из терминала нельзя вычитать один ппп пакет тогда

Как узнать сколько байт читать из терминала ?

можно

Через разгребание каждого пакета и вычисление длины ?

Как в pptp ?

Нуэтопиздецвобще

весь фрейм, дисциплина гарантирует один фрейм на одно чтение

и на запись

либо все либо ничего

И давно это появилось ?

Когда я смотрел не было этого

всегда

Как называется константы которыми это можно включить ?

кудат не туда смотрел, pppsync.c

реализация дисциплины

Я прям даже в рассылку писал

Мне ответили что знают про этот прекол и делать не будут. Потому что ппп маст дай

ну чувак, оно с рождения есть

Ну нет же

может ты про что-то другое говоришь?

в общем какого либо совета я видимо так и не вижу

жаль

Щас попробую найти

ug here: https://github.com/torvalds/linux/blob/9a3c4145af32125c5ee39c0272662b47307a8323/drivers/net/ppp/ppp_synctty.c#L604 In short, when entire packet cannot be written to terminal, piece of packet will be written, and second piece will be thrown away. Next, see http://sourceforge.net/p/pptpclient/git/ci/master/tree/pptp_gre.c line 249 /* in synchronous mode there are no hdlc control characters nor checksum * bytes. Find end of packet with the length information in the PPP packet */ if ( syncppp ){ while ( start + 8 < end) { len = ntoh16(*(short int *)(buffer + start + 6)) + 4; /* note: the buffer may contain an incomplete packet at the end * this packet will be read again at the next read() */ if ( start + len <= end) if ((status = cb (cl, buffer + start, len)) < 0) return status; /* error-check */ start += len; } return 0; } So, they assume that when /dev/ptsxxx is set to PPP_SYNC line discipline, /dev/ptmx (opened previously) will be CONTINUOUS stream of PPP packets. Next, they extract length of each PPP packet via specific offset that is the same for all PPP control packets and IPv4 packets! This is a hack, but it works! until kernel decides to write big bunch of data into terminal :(. One way to trigger that - is to make "ping -s 6500". Kerne will split this one big ICMP to many MTU-bounded packets and tries to write each one to terminal. On some packet, this will fail since terminal buffer is 65536 (I guess). Next, entire sync-operation will FAIL..... If We just increase buffer - this will not help since this will be race-condition: if reader of master side of terminal will be slow, problem will appear again. What I want: 1. printk() if that happen 2. check if sending is possible before sending to terminal (i.e. check space in buffer before write) 3. Another decision - is to send second part of packet when terminal buffer drain. The most part of my misunderstanding - is "What is SYNC serial device?". man pppd: sync Use synchronous HDLC serial encoding instead of asynchronous. The device used by pppd with this option must have sync support. Currently supports Microgate SyncLink adapters under Linux and FreeBSD 2.2.8 and later. what is "sync support" ?! Linux's /dev/ptsxxx support PPP_SYNC line discipline (do not return error) but really does not (always) work. P.S. It will be nice if you forward my letter to someone, who can also help me in that question. Thanks.

с sync_ppp кароч hdlc фрейминг не нужен, но оно криво работает с пэйлоадом больше, чем 1500 + 200чототам

с sync_ppp кароч hdlc фрейминг не нужен, но оно криво работает с пэйлоадом больше, чем 1500 + 200чототам

Йа кросафчег. Эту проблему я и нашел

Это кстати мое письмо

да, но пробема преувеличена

нахрена писать целый пакет в 65535 байт, если стек его побил по mtu

Нифига. Если пакеты будут приходить из ядра в юзерспейс очень быстро, то пяка проявляется

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

В томто и прекол

на mtu > 1500 проявляется. sstp поддерживает до 4091

Да ну нет же

На мту 1500 проявляется же

Если слать большой айпи пакет

Оно фрагментирует на куски по 1500. И пепяка

ну нет же, т.к стек отфрагментирует и в pppsync валяться уже фрагменты с ff03 префиксом

у меня работало. но до mtu 1700, дальше начинали валиться куски

Правильно

Читай письмо

Дело не в мту

там чушь

А в размере отправляемого программой пакета

Мту у меня всегда и везде 1500 или меньше

одна из причин - в pppsync гвоздями прибито 1500 mtu, которое не меняется

Да ну жованный крот же

линус пишет о попытке запихать в syncppp fd слишком большой пакет

что его не разбить

Нет не так

Он сувает первый пакет в терминал

Потом второй

в sstp такого нет, там каждый ppp пакет меньше будет. точнее должен

И вот линукс не проверяет, можно ли всунуть текущий пакет в терминал целиком

гм

погоди, перечитаю

в общем какого либо совета я видимо так и не вижу

А что в дебиане вместо SElinux'a?

Может, оно не даёт всюду лезть?

И вот линукс не проверяет, можно ли всунуть текущий пакет в терминал целиком

В итоге если влезло полпакета -- оно и попадает в юзерспейс

А что в дебиане вместо SElinux'a?

Аппармор ?

Да, оно

момент про размер буфера я упустил. да, если оно не было выбрано ppp драйвером, то будет ошибка. если перед повторной попыткой записи очередного фрагмента прошло значительное фремя, дефрагментатор сфейлится

момент про размер буфера я упустил. да, если оно не было выбрано ppp драйвером, то будет ошибка. если перед повторной попыткой записи очередного фрагмента прошло значительное фремя, дефрагментатор сфейлится

Шта ?

крч. оно работает, работает быстро, но с ограничениями

Да

в итоге я все равно переделал на async

ERROR: S client not available

в итоге я все равно переделал на async

Аналогично

А у тебя есть сырцы на гитхабе ?

велосипедисты :)

есть, но там древняя версия с кривой sync обработкой

залью async, покажу

И да. Я подумывал о декапсулчторе ппп в юзерспейсе. В сстп используется полтора вида фреймов

залью async, покажу

Давай

И да. Я подумывал о декапсулчторе ппп в юзерспейсе. В сстп используется полтора вида фреймов

ethervpn получится :)

Дак да

он в tun пихает

Ну

Именно

и какое ж он говно внутри

А чо. Сжатия не надо. Авторизация ? Гм.

(кстати)

и какое ж он говно внутри

Боян

Да ты знатно упоролся кстати. Глобально.

:)

wireshark как раз и патчил пока этим занимался. томушта собирать его невыносимо

а про кроскомпиляцию они там не слышали

проще и быстрее было хакнуть в 4 байта

Наркоман. Точно.

Наркоман. Точно.

нет, они

https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html

Да вы все тут наркоманы в хлам упоротые

Хотя. Щас говорят вайн в виндозной убунте запустили

И тащатся

было бы от чего. там в этой "убунте" почти весь сетевой стек вырезан. с вытекающими

и пинг от рута, т.к рав сокеты на винде требуют доп привелегий

А кстати, это не годный ли способ писать трояны ? Каспер поди не умеет в анализ позиксвызовов

Как там это вобще работает

посикс не при чем